Добрый вечер,
Я понял, что мне нужно расписать бизнес-процессы, их реализацию инструментом
и метрологию, тогда будет понятнее полезность его функциональности, и в каких “мелочах”
кроется дьявол)), займусь, спасибо за обратную связь.
На пока раскрою детали вкратце - а именно, где можно получить улучшения.
Далее пришлю более развернутый ответ (см. выше.
CI стартует внешний процесс и все что в нём, уже само по себе, возможности управлять например его потоками отсутствует, заточён под очень широкий диапазон, а значит дальше уже надо искать составные части.
Bali же является java процессом и заточён под глубокую бизнес-логику предметной области, стартует потоки исполнители и содержит пул ресурсов в этой же виртуальной машине, за счёт чего появляется много вкусных возможностей, которых мне не хватает в CI.
ЗАПУСК:
Было:
- запускаем обычно или предустановленное множество или по тэгам и
все это надо держать в памяти (человеческий фактор)
(когда кол-во сценариев идет на сотни, а тэгов на десятки - не очень удобно), нельзя выбрать точечно нужное множество.
- перед запуском проект строиться - может занимать несколько минут!
- не видна структура проекта визуально, по сути командная строка на вебе.
Стало:
- проект уже построен и загружен, исполнение начинается мгновенно,
нет скучного ожидания сборки.
- выбор тестов в дереве, все структурировано по вашему представлению (сами определяете структуру, причем делайте это для любого фрэймворка, хоть сценарии из Сucumber)
- при наведении мышкой можно посмотреть информацию о тесте (по вашему дизайну, например
разместите описание теста на языке герклин, или из аннотации TestDesc, если используете такую)
- отметить тэги (которые включат подмножество листьев дерева тестов)
- Или же выбрать готовый сохраненный сюит (такой же вид дерева).
- Запуск сюиты из внешней системы по http trigger link-e (например, из той же CI после сборки билда)
Ускорение за счет распараллеливания с учетом пула ресурсов:
БЫЛО:
- распараллеливание поддерживается в testNG и вроде как в последних версиях junit.
Но в реализации cucumber - нет, не говоря о других фреймворках.
Так же это уже не территория CI, а внешнего к нему процесса.
- допустим, есть подход! но чего не хватает?
а) Дело в том, что могут быть тесты в сюите, которые не могут запускаться в параллель - будут ошибки. Например: 1 тест проверяет аварийное восстановление нод, в этот момент не будет работать определенная функциональность, которая завалит другие тесты (хотя они на самом деле они - passed)
б) у вас ограниченное кол-во ресурсов необходимого тестам (браузеров, каналов, агентов, пользователей, и.т.д.) и Вы не хотите, чтобы система позволяла запускать тест, если в пуле все
подходящие заняты в использовании другими тестами, а запускала его, когда наконец освободятся, то современные фрэймворки не поддерживают этот механизм.
с) Более того, несколько пользователей могут запустить тесты одновременно в системе,
потоки то работать будут, ускорение будет, это хорошо, но потенциально будут “мешать” друг другу в доступе к необходимым ограниченным ресурсам.
СТАЛО на Bali:
-
вы можете запустить в параллель любой жава код (testNG, классический Java Main, jUnit, сценарии на Cucumber c точностью до подсценариев) причем сделать это оригинальным движком фрэймворка, здесь есть свой механизм TestExecutor-ов, т.е. задача решена универсально.
см. страницу фичи: http://test-execution.com/page97470.html
-
Реализован механизм пула ресурсов. Каждый тест помечает, какие ресурсы ему нужны в
работе. Движок запускает тест в обработку, если есть свободные ресурсы в пуле,
сначала блокирует их, после выполнения теста - разблокирует.
Несколько человек может запустить несколько сюит одновременно - все корректно отработают, даже если используют схожий тип ресурса.
см. страницу фичи: http://test-execution.com/page96209.html
-
кол-во потоков тоже регулируется и можно смотреть детальную информацию на веб странице в процессе, какой поток чем занят
Детализация информации о прогоне и управление им:
БЫЛО:
- на CI виден запуск процесса и можно сделать так, чтобы видеть сводку базовую
запущенно, пройдено, завалено ( примерно в таком стиле),
скорее всего это сделано на основе обмена через файл между процессами
- Отчет-артифакт строиться в конце, необходимо ждать (если прогон длинный - до нескольких часов)
- прогон можно отменить (убить процесс) только сразу целиком, нельзя убрать определенное подмножество из запуска
СТАЛО:
cм. фичу http://test-execution.com/page96177.html
- В онлайн доступна максимально подробная обновляемая (ajax) информация о запущенном сюите, список тестов, в каком статусе каждый (ждет, запущен, прошел, завален, сколько ошибок,
какие ресурс из пула необходимы и использует), суммарная статистка.
- Сразу доступ к актуальным 3-м видам отчетов: классификационный об ошибках,
отчет о шагах теста(как правило screenshot flow, сами выбираете что и как туда вставлять), отчет по метрикам (можно пушить цифры и видеть их в графиках)
- любой тест из сюита можно выключить из списка прогона
- rerun: отправить тест на перезапуск сначала в рамках сюита (его ошибки удаляются из отчета по ошибкам )
- wait of error: сказать, чтобы поток вставал на паузу при достижении тестом ошибки, потом после отладки нажать resume и продолжить работу потока исполняющего тест.
(удобно использовать при воспроизведении длинных сценариев)
- Soft Stop (мягкая остановка): тестовому контексту поставить признак мягкой остановки, и тест
в определенной точке смотрит его, понимает что нужно завершить себя изнутри.
если такой нет, на всякий случай есть функция
- Жесткая остановка: послать потоку Thread.stop(), не рекомендуется использовать депрекейтед , но в основном работает, хотя и не всегда
Предпочитаю использовать soft stop.
- так же вызвать soft stop для всего сюита целиком
Управление запуском напрямую с отчета по ошибкам:
Было:
- есть статический отчет,
если необходимо перезапустить какие-либо тесты, например по причине,
что ночью сетка упала на час, и 20% попадало, то
нужно либо перезапустить все (что плохо, т.к долго и повторно), либо запоминать
эти 20% тестов (300 * 20% = 60 названий) и готовить для них руками отдельный build.xml
Стало: см шаг 17, 18 (из Quick Start Demo)
прямо из классификационного отчета по ошибкам вы можете отправить тесты,
блокируемые определенной причиной (находятся в одном классе) на перезапуск
- в текущем сюите в один клик, ошибка уйдет из отчета и будут уже добавлены свежие
- в новом сюите, но уже на выбранных окружениях из списка тоже в пару кликов
Нагрузочное тестирование:
http://test-execution.com/page95167.html (cм. пункт Load Testing)
Стало:
- в дереве тестов включите Load Mode
- напротив каждого runnable item появится поле для ввода кол-ва
потоков (пользователей), который дожен делать сценарий.
- введите длительность и период rumpUP между стартом потоков и
нажмите старт.
- в режиме контекста loadMode тесты не делают тяжелых и длинных ассертов, логируют например время открытия страницы, либо тест-измеритель собирает информацию о памяти и процессоре, кладет в отчет по метрикам (Bali Metrics API)
Таким образом ваши еще вчерашние функциональные тесты, в один поворот слали работать в контексте нагрузочных! В отдельной статье напишу о положительных кейсах использования
на реальном проекте (1500 phantomjs браузеров, 1500 реальных потоков-пользователей, где из-за
насыщенного Vaadin-а во фронтэнде традиционный jmeter скриптинг не подходил).
Остальные 10-ки плюсов обещаю позже, воскресенье все-таки, да и еще не один час нужен.
Если интересно, можно созвониться по скайпу.
CI cистемы я использую в своей практике для деплоя билдов, запуска юнит тестов, запуска сюиты
на Бали по ссылке-стартеру, там где не очень нужны гибкие возможности управления.
Для управления запуском более менее же сложных интеграционных тестов - с 2012 выбираю Bali, по необходимости добавляю новые фичи, идеи.
Спасибо,
Кирилл
testomat.io управление авто тестами
Сходу не понятно, что и зачем. Тут я полностью соглашусь с ArtOfLife