Блог

Я пытаюсь улучшить процесс тестирования, в котором я работаю, но без корректировки структуры.

Что у нас есть: VSTS, Selenium IDE, тестировщики, которые пишут тестовые примеры, но не код.

Что я хотел бы сделать, так это найти способ объединить нашу непрерывную интеграцию TFS с тестами Selenium, которые мы пишем. Это НЕ тесты selenium, управляемые кодом, а скорее версия IDE, в которой пользователи переходят по ссылке и устанавливают утверждения с помощью IDE (все это просто тесты пользовательского интерфейса). Я знаю, что мы можем экспортировать эти планы тестов в виде файла .SIDE, но чего я не могу понять, так это как заставить наш сервер TFS выполнять их как часть конвейера развертывания или сборки.

В идеале разработчики / devops должны с самого начала настраивать проекты в TFS с любым решением, имеющим смысл для выполнения этих Selenium.ПОБОЧНЫЕ файлы, но впоследствии тестировщики будут управлять добавлением / изменением этих тестов в другом месте.

Реальная цель здесь — не заставлять тестировщиков писать код или проверять код. Только написание этих тестов Selenium пользовательского интерфейса, но выполнение TFS как части CI.

Изучение этого в Интернете в основном всегда приводит меня к чему-то, что требует от тестировщиков написания кода.

Я не думаю, что он может автоматизировать тестирование без кода, по крайней мере, вам нужен тестовый проект, содержащий ваши автоматические тесты.

Как правило, в Azure DevOps мы используем Visual Studio Test task для запуска тестов. Эта задача поддерживает использование следующих тестов:

• Тестовая сборка: используйте этот параметр, чтобы указать одну или несколько тестовых сборок, содержащих ваши тесты. Вы можете дополнительно указать критерии фильтрации для выбора только определенных тестов.
• План тестирования: используйте этот параметр для запуска тестов из вашего плана тестирования, с которым связан метод автоматического тестирования. Чтобы узнать больше о том, как связать тесты с рабочим элементом тестового набора, см. раздел Связать автоматические тесты с тестовыми наборами.
• Тестовый запуск: используйте этот параметр при настройке среды для запуска тестов из планов тестирования. Этот параметр не следует использовать при выполнении тестов в конвейере непрерывной интеграции / непрерывного развертывания (CI / CD).

У меня тоже был этот вопрос, и я думаю, что нашел несовершенное, но лучшее решение.

Я не смог запустить свои тесты Selenium IDE с помощью Jenkins, но я смог запустить их с TeamCity, другим CI. Я создал шаг сборки, подобный следующему :

• Тип бегуна: командная строка
• Рабочий каталог: где selenium IDE.боковой файл находится
• Запуск: пользовательский скрипт
• С содержимым сценария сборки, который я обычно использую для запуска тестов Selenium IDE, таких как selenium-side-runner sidefile.side
• Я также добавил следующее, чтобы я мог выводить результаты в Junitor в другой форме: --output-directory=results --output-format=junit
• Вы также можете добавить следующее, чтобы тесты запускались без головы, это работает только в Chrome : -c "goog:chromeOptions.args=[--headless,--nogpu] browserName=chrome"
• Наконец, я также использую --filter для запуска одного набора тестов за раз, но это тоже необязательно.
• Затем я использовал еще один шаг сборки для экспорта результатов в наш менеджер по тестированию, xray, но я думаю, что это выходит за рамки этого вопроса.

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