Рейтинг
0.00

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

1 читатель, 8 топиков

Создание автотестов используя SpecFlow (Cucumber для C#) для BDD подхода разработки

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

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

Nuget SpecFlow

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

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

SpecFlow Feature File

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

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

Как перетащить объект в браузере используя Selenium Webdriver?

В наше время все чаще веб приложения пишутся активно используя 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 — это элемент поверхности

Подробнее изображено на рисунке:
Drag and Drop Selenium WebDriver

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

Основные Атрибуты NUnit для написания автотестов на C#

Атрибуты 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() { }
}


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

Как прикрутить NUnit автотесты к Тимсити (TeamCity)

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

В статье предполагается что у вас уже созданы билдагенты и настроен 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 в IntelliJ IDEA

Пример конфигурирования 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 с помощью pom.xml

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

IntelliJ IDEA - pom.xml

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