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

Результаты выполнения автоматических тестов могут быть импортированы в систему на одном из этапов подготовки и выпуска сборки.

Обычно этим занимаются сборочные серверы (или сборщики), такие как Jenkins или TeamCity. Команда для импорта тестового отчета указана в подсказке в модуле "Тестовые отчеты". Для проверки возможности импорта вашего отчета используйте действие "Импортировать отчет".


Форматы отчетов средств автоматизированного тестирования, доступные для импорта:

  • JUnit - файл с результатами тестирования в формате xml
  • NUnit - файл с результатами тестирования в формате xml
  • TestNG - файл с результатами тестирования в формате xml
  • Allure - архив каталога с результатами тестирования в формате zip


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


Разрабатывайте функциональные и интеграционные автотесты на основе тестовой документации. Затем, после реализации соответствующего тест-класса или тест-метода, добавьте аннотацию Description, в которой укажите идентификатор автоматизированного сценария. Таким образом, в результатах тестирования вы сможете просмотреть как текст сценария, так и результат его тестирования.

@Test(description="S-1685")
public void myTestMethod() {
// ...
}

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

Ручной запуск автотестов

При помощи пользовательских действий вы можете настроить ручной запуск требуемых автотестов. В примере ниже показано, как может выглядеть такое пользовательское действие для конкретной сборки (версии) продукта.


При выборе пункта меню "Провести регресс", выполняется Веб-хук запуска задачи на сборочном сервере, в рамках которой:

  • создается тестовое окружение;
  • запускается заданный автотест, например, регрессионный;

Настройка такого веб-хука может выглядеть следующим образом:


Можно создать пользовательское действие для конкретного тест-плана или тестового сценария. Для этого у сценария необходимо создать пользовательские атрибуты, в которых будут храниться необходимые данные для запуска авто-теста, например имя класса автотеста и название метода. Теперь, в адресной строке URL у пользовательского действия можно обратиться к атрибутам сценария.

В данном примере:

  • ClassName - пользовательский атрибут сценария, содержащий имя класса автотеста;
  • MethodName - пользовательский атрибут сценария, содержащий название метода автотеста.


Перетестирование

Для перетестирования (ретеста) позиций тестового отчета или отдельного теста, которые ранее были добавлены в систему, можно создать соответствующее пользовательское действие.


Данные о классе автотеста и метода автотеста импортируются вместе с тестовым отчетом.


Для настройки пользовательского действия используются атрибуты теста:

  • ClassName - Класс автотеста
  • MethodName - Метод автотеста

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


Тестовые среды

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


Для создания информации о тестовой среде используется Devprom REST API. Можно указать название среды, существенные параметры (например, порты различных сервисов), версию ПО, развернутую в среде, специфические особенности (например, используемую СУБД).

При автоматическом импорте тестового отчета (результатов тестирования), вы можете указать среду, на которой осуществлялось тестированием. Таким образом, система свяжет тестовую среду с результатами тестирования.


Пользовательскими действиями можно настроить ручное создание тестовой среды с нужными настройками и версией ПО, а также остановку тестовой среды.


Применение BDD

BDD (Behavior Driven Development) - практика разработки кода на основе приемочных сценариев (так называемых исполняемых спецификаций). Приемочный сценарий пишется на специальном языке (Gherkin), который позволяет автоматически создавать заглушки программного кода. Эти заглушки реализуют программисты, вызывая при этом программный код. Получаются такие автотесты, сценарии по которым пишут не программисты, а реализуют их программисты.


Существует много фреймворков для реализации этого подхода, под разные языки программирования. Сложность у всех одна: кто и где пишет эти самые сценарии, где они хранятся, как отслеживается их актуальность в соответствии с требованиями. Devprom ALM позволяет разрешить эту проблему.


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

Результаты поиска