Автоматизированное Тестирование

Подготовка пакета SpecFlow для написания тестов

Для начала работы нужно скачать и добавить референс на библиотеку SpecFlow. Это можно сделать через NuGet Package Manager.

Создание SpecFlow Feature File для описания сценариев

Далее при создании нового айтема будет доступен айтем SpecFlow Feature File с расширением .feature выбираем и создаем



После создания SpecFlow Feature файла мы можем видеть такую заготовку под описание сценариев
Писать сценарии в этих файлах могут как тестировщики так и аналитики и продакт овнеры. Главное чтобы учитывался подход в описании сценариев, используя такие ключевые слова как:

• Given
• When
• And/But
• Then

Читать дальше →

В наше время все чаще веб приложения пишутся активно используя JavaScript и JQuery и бывает что в автотесте один обьект нужно перетащить в другое место на странице

Для таких случаев в Selenium Webdriver существует класс Actions который в свою очередь имеет нужные нам методы DragAndDrop() и DragAndDropToOffset()

Для начала нам нужно 2 локатора: 1й — обьекта который нужно перетащить и 2й — локатор поверхности куда нужно этот объект перетащить

Для выполнения такой операции нам нужно написать:

var actions = new Actions(Driver);
var random = new Random();
int x = random.Next(-75, 75);
int y = random.Next(-75, 75);
actions.DragAndDrop(this.objectToDrag, this.fieldArea)
           .DragAndDropToOffset(this.objectToDrag, x, y)
           .Perform();

x и y — это координаты в пикселях поверности, куда именно нужно перетащить объект, расчитывается от центра (в данном случае высота и ширина задается рандомно, в пределах от -75 до 75)
this.objectToDrag — это элемент самого объекта
this.fieldArea — это элемент поверхности

Подробнее изображено на рисунке:


Читать дальше →

Атрибуты NUnit для Тест сьюта и тест кейсов

Все классы в проекте, помеченные атрибутом [TestFixture] означают что данный класс содержит автотесты и фактически это тест сьют. Внутри данного класса должны размещаться методы с атрибутами [Test] которые в свою очередь и означают что данные методы это тест кейсы (автотесты)

[TestFixture]
public class Tests
{
 [Test]
 public void Test1() { }

 [Test]
 public void Test2() { }
}

Атрибуты NUnit для выполнения перед и после Тест сьюта

Бывают случаи когда требуется выполнение какого либо действия перед и после выполнения всего тест сьюта. Для этого используют атрибуты [TestFixtureSetUp] — выполняется перед запуском всех тестов из всего тестового класса и [TestFixtureTearDown] — выполняется после выполнения всех тестов в тестовом наборе. В коде это будет выглядеть таким образом:

[TestFixture]
public class Tests
{
 [TestFixtureSetUp]
 public void BeforeTestSuit() { }

 [TestFixtureTearDown]
 public void AfterTestSuit() { }
}

Читать дальше →

Настройка конфигурации для автотестов в тимсити позволит вам без вашего участия запускать тесты по расписанию или после любых изменений в коде и деплоймента, просто настроив билд конфигурацию и прописав зависимости и триггеры в билд конфигурации.

В статье предполагается что у вас уже созданы билдагенты и настроен Version Control Settings

Для начала следует создать темплейт в тимсити для вашей конфигурации

1) Для этого нужно перейти в раздел Администрирования

2) Заполнить имя и нажать «Создать»

3) Приаттачить VCS Root и Выбрать билд агент в Agent Requirements

4)Заполнить General Settings и Build Step (создать 2 степа на ребилд проекта и на запуск)


Этого будет достаточно для самой простой конфигурации. Далее можно настроить зависимости от выполнения других конфигураций и триггерры для автозапуска автотестов

Читать дальше →

Первый вопрос, на который следует ответить беспристрастно и непредвзято звучит так: «Насколько целесообразно использование автоматизированного тестирования для данного программного продукта». При положительном ответе на поставленный вопрос, нужно определить выдвигаемые к проекту требования и спланировать шаги по разработке тестов для автоматизации проверок.



Подробное перечисление тестов, предназначенных для проверки каждой функции, совершенно бессмысленно. Отталкиваться будем от перечисления того, какие именно места в проэкте, общие для ряда категорий программ, следует подергать автоматическому тестированию в первую очередь.

Какие модули и места следует подвергать автоматизации?

1. Участки кода, исполнение которых трудно визуализировать и получить осязаемую информацию о протекающих процессах (back-end процессы, занесение в базу данных, занесение логов в файл).
2. Функциональность продукта, которая будет использоваться наиболее часто и возникновение ошибок которой связано с достаточно высоким риском. Автоматизированное тестирование узловых моментов функциональности потребует меньше времени для поиска ошибок. И соответственно, сократит время на их устранение.
3. Типовые часто выполняемые операции, которые обычно связаны с обработкой данных. Например – формы, в которых количество заполняемых граф и полей довольно значительное. Цель – автоматизировать занесение требуемых данных в нужное поле и проверить правильность выполнения задачи после сохранения результата.
4. Сообщения об ошибках. Требуется автоматизация разнесения некорректных данных по соответствующим полям и тестирование корректности проверки правильности данных и сообщений об ошибках.
5. Комплексная проверка поведения всей системы, как целостного объекта (end-to-end testing).
6. Проверка числовых массивов, нужных для достоверных математических операций.
7. Тестирование корректности отображаемых результатов поиска в ответ на запрос по нужным данным.
8. Предложенный список только ориентировочный. Всё зависит от предъявляемых к проверяемой системе требований, возможностей, которые позволяет реализовать выбранный для автоматического тестирования инструмент.

Читать дальше →

Автоматизация тестирования

Тестирование программного продукта, в процессе которого главные этапы проверки осуществляются при помощи автоматических инструментов (запуск, инициация, проведение, обработка результатов и оформление выводов) в английском варианте выглядит как “functional automation testing”. По-русски – автоматизированное тестирование программного обеспечения.

Предпосылки для автоматизации

Как и все узконаправленные продукты, автоматизация тестирования ПО, имеют свои плюсы и минусы. Соответственно, есть случаи, когда автоматическое тестирование проводить можно, и варианты, когда ручной режим более полезен.

К неоспоримым достоинствам автоматического тестирования относятся:

• Цикличность – гарантия того, что созданные автотесты всегда будут соблюдать один алгоритм проверок, который не пропустит предусмотренного теста при одном из случаев применения.
• Быстрый результат – отпадает необходимость во времени, которое нужно человеку для сверки промежуточных итогов, подтверждения безошибочности при выполнении требований.
• Дешевизна – однократно созданный софт для тестирования требует меньше усилий для анализа полученных данных, в итоге, заменяя те же объёмы ручного тестирования без потерь в качестве.
• Простор в отчётности – готовые результаты легко обрабатывать, а сами отчёты нетрудно распространить по заинтересованным лицам.
• Свободные руки – человек-тестер, во время работы программы, может выполнять другую полезную деятельность, которая автоматизации не подвержена. Позволительно проводить тестирование в то время, когда нагрузка на числовые ресурсы снижена (в нерабочее время).

Минусы автоматического тестирования ПО

• Цикличность (да-да) – однообразные тесты не могут зацепить другие элементы, чем те, для которых они написаны. Человек же способен заметить мелкие нестыковки и на уровне тестирования сделать выводы о природе ошибки или внести исправления.
• Поддержка – хоть и затраты на ручное тестирование больше, автоматические тесты также нужно обновлять и доводить, чтоб функциональность проверок соответствовала уровню тестируемого приложения (с повышением сложности проверяемого ПО, возникает потребность в обновлении кода автотестов).
• Разработка – написание, а главное – отладка и тестирование автотестов требует много времени. Ведь, по сути, софт для тестирования программного обеспечения – не что иное, как то же самое программное обеспечение. Только функционал очень узкий.
• Стоимость – лицензионный экземпляр фрейворка для автоматизации может обойтись в приличную сумму. И хоть бесплатные варианты тоже, как правило широко используются, их функциональность часто оставляет желать много лучшего, а лицензия должна помочь при возникновении проблемы, описанной в п.2 данного списка.
• Мелкие ошибки – автотесты могут не замечать мелких дефектов, не наносящих вреда функциональности кода, но портящих визуальный интерфейс и затрудняющих работу конечного пользователя (сдвиг окон, грамматические ошибки…).

Читать дальше →

Пример конфигурирования Testng.xml:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >

<suite name="SeleniumTest" verbose="1">
    <test name="RozetkaTest">
       <parameter name="browser" value="chrome" />
        <classes>
            <class name="Tests.SmokeTest" />
            <class name="Tests.MenuTests" />
            <class name="Tests.AuthorizationTests" />
            <class name="Tests.OnlineOrderTests" />
        </classes>
    </test>
</suite>

В этом xml файле перечисляются классы, которые будут запускаться при нажатии на «test» в мавен панели.
Также могут быть перечислены отдельные методы и передаваться параметры, которые можно использовать в автотестах.

Чтобы пользоваться TestNG, Selenium Webdriver и Maven Surefire Plugin в IntelliJ IDEA
нужно прописать соответствуюшие зависимости и плагины в соответствии с синтаксисом XML в pom.xml:



Читать дальше →