Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Инструмент для управления запусками java автотестов через веб

selenium
webdriver
java
Теги: #<Tag:0x00007f7b62f092d8> #<Tag:0x00007f7b62f09198> #<Tag:0x00007f7b62f08fb8>

(Kirill Konoplev) #1

Привет!

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

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

как Вам инструмент в целом?
известны ли похожие аналоги?
Что остановило бы от внедрения у себя?
буду благодарен за ответ (kirill-konoplev@yandex.ru)
Заинтересованным предлагаю содействие в освоении :wink:

Спасибо,
Кирилл


(Sergey Pirogov) #2

Чем это круче jenkins или любого другого CI сервера?


(Sergey Korol) #3

Лейбл Community version с представленными ограничениями как бы с ходу отбивает все желание даже смотреть на продукт.

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

Если честно, мне пока слабо представляется сам workflow. Как же CI, version control и т.п.? Или тут все работает по принципу - сам себе накодил, запустил, перезапустил и все довольны?

Ну и касательно самой web-морды: имхо, я бы пригласил какого-то толкового UI-щика навести марафет и привести ее в товарный вид.


(Kirill Konoplev) #4

Сергей,

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

CI - это системы управления запуском серии ПРОЦЕССОВ через веб.

Bali tool - это система гибкого управления запуском ПОТОКОВ в параллельном режиме
с пулом ресурсом в одной JVM для исполнения тестов,
эффективным классификационным отчетом по ошибкам и узко заточена по бизнес-процессы тестирования итд.
В СI НЕТ:

  1. сканирование сорцов проекта и представление тестов в виде дерева
  2. запуск тестов в многопоточном режиме с синхронизированным внешним пулом ресурсов
  3. классификационный отчет об ошибках
  4. возможность контролировать работу потоков в процессе исполнения сюита (стоп, рестарт, пауза)
    и много много другого
    cм. ссылку http://test-execution.com/page95167.html

Для демонстрации этих возможностей см. страницу
Quick start demo
http://test-execution.com/page90455.html


(Kirill Konoplev) #5

ArtOfLife, добрый вечер,

как раз для демо есть ссылка с главной страницы
Quick start demo
http://test-execution.com/page90455.html

на ней представлена виртуальная демонстрация со скриншотами и шагами,
которые можно повторить самостоятельно на основе инструкции и архива.

в кратце о разнице концепций:
CI - управляет процессами и в голом выражении ничего не знает о “тестировании”, для него это просто вызов процесса, который генерит некие артефакты для публикации.

Bali - управляет потоками(workers) и пулами ресурсов в одной JVM для запуска тестов (любой жава код),
что открывает новые возможности за счет другого подхода.

  • много функциональности для бизнес-процессов тестирования.

В СI НЕТ:

  1. сканирование сорцов проекта и представление тестов в виде дерева (врзможность делать свой плагин)
  2. запуск тестов в многопоточном режиме с синхронизированным внешним пулом ресурсов
  3. классификационный отчет об ошибках
  4. возможность контролировать работу потоков в процессе исполнения сюита (стоп, рестарт, пауза)
    и много много другого
    cм. ссылку http://test-execution.com/page95167.html

И поэтому позволяет достигать цели тестирования более эффективно.

Спасибо


(Sergey Pirogov) #6

Имхо если бы там было норм ДЕМО, вопросов может быть было бы меньше. Полностью согласен с @ArtOfLife. Пока что смотрится как на коленке клепаное студентами


(Kirill Konoplev) #7

Сергей,

опишите, чем не нравиться текущее демо, я за улучшения. Как раз и нужна конструктивная критика.
Я описал шаги, повторив которые вы сможете воспроизвести использование тула и попробовать его возможности.
и каждый шаг снабжен скриншотом из реально работающего приложения.
Архив содержит все необходимое. Пока из ближайшего круга пользователей - у всех получалось без проблем.
Какой шаг из демо у Вас вызывает затруднение? и описание какой фичи не очень понятно?

Спасибо


(Eugene Tkachenko) #8

Топикстартеру, у меня лиш один вопрос: что заставит меня перейти на ваш сервис?

Вот ситуация, есть допустим Senior QA Automation, который на своем пути решал свои проблемы с запуском тестов, уже есть какие-то наработки, есть тулы к которым он привык, тут он натыкается на ваш продукт, первая асоциация - очередной CI. Нет и намека на то, что я захочу пересаживаться на платный сервис(в будущем) не имея никаких весомых плюсов данного проекта.

Все ваши пункты, чем отличается ваш продукт допустим от Jenkins не являются теми самыми причинами перехода, есть куча плагинов, плюс есть такие, кто и сам может написать плагинчик под свои нужды, или попросить выделить фирму на имплементацию addon-a, что будет значительнее дешевле.

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


(Sergey Korol) #9

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

Тут дело не в разнице в концепций, а в интеграции с основным циклом разработки. На данный момент данное решение выглядит совершенно оторванным от реальности. Вот будьте добры, опишите процесс взаимодействия с данным тулом у вас в команде. Я могу представить его использование только в водопадной модели. И уж никак не вижу его в agile. Вот вышел новый билд (эдак раз 5 в день). Ваши действия? Команда ждет от вас фидбэка по результатам финального смоука / регрешена. Завтра релиз.

Другой момент. Представим, что у вас команда из 10 автоматизаторов. Все активно что-то пишут, вполне возможно даже кое-где пересекаются в коде. Каким образом Bali получит актуальную версию кода от всей вашей команды?

Jenkins, к примеру, open source. Написать простенький плагин для него - это день-два разбирательства с нуля. Потом можно конвейером их клепать.

А как же TestNG + SeleniumGrid? Без учета управления процессами из web-морды эта связка делает то же самое. В целом, мониторить загрузку нодов можно из консоли грида, а останавливать процесс прямо из CI. Вопрос остановки отдельных потоков лично для меня выглядит весьма сомнительно. Если тесты у вас бегают очень быстро, то в этом не должно быть никакой необходимости.

Отчеты - штука весьма условная. Вот, к примеру, нужно мне будет добавить какую-то кастомную фичу или информацию - требование клиента. Каков эфорт в вашем случае?

Касательно визуального оформления - рекомендовал бы сделать опрос. Как по мне, проекту нужен вид посвежее. На фоне того же Allure смотрится слабовато.

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


(asolntsev) #10

Вот тут я прям не понял. В CI этого нет? А чем же вообще CI тогда занимается?

Jenkins запускает билд-скрипт (ant, maven или gradle), а тот, естественно, сканирует исходники проекта, находит и запускает тесты. И сюрприз-сюрприз, генерирует отчёт об ошибках. Мы работаем так уже много лет, и нас всё устраивает.

Чтобы продать мне тул, нужно описать, какие проблемы он решает. А у меня нет никаких проблем с запуском тестов в Jenkins. Или я их не вижу, но тогда уж помогите мне их увидеть.


(Kirill Konoplev) #11

Добрый вечер,

Я понял, что мне нужно расписать бизнес-процессы, их реализацию инструментом
и метрологию, тогда будет понятнее полезность его функциональности, и в каких “мелочах”
кроется дьявол)), займусь, спасибо за обратную связь.

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

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

Bali же является java процессом и заточён под глубокую бизнес-логику предметной области, стартует потоки исполнители и содержит пул ресурсов в этой же виртуальной машине, за счёт чего появляется много вкусных возможностей, которых мне не хватает в CI.

ЗАПУСК:

Было:

  1. запускаем обычно или предустановленное множество или по тэгам и
    все это надо держать в памяти (человеческий фактор)
    (когда кол-во сценариев идет на сотни, а тэгов на десятки - не очень удобно), нельзя выбрать точечно нужное множество.
  2. перед запуском проект строиться - может занимать несколько минут!
  3. не видна структура проекта визуально, по сути командная строка на вебе.

Стало:

  1. проект уже построен и загружен, исполнение начинается мгновенно,
    нет скучного ожидания сборки.
  2. выбор тестов в дереве, все структурировано по вашему представлению (сами определяете структуру, причем делайте это для любого фрэймворка, хоть сценарии из Сucumber)
  3. при наведении мышкой можно посмотреть информацию о тесте (по вашему дизайну, например
    разместите описание теста на языке герклин, или из аннотации TestDesc, если используете такую)
  4. отметить тэги (которые включат подмножество листьев дерева тестов)
  5. Или же выбрать готовый сохраненный сюит (такой же вид дерева).
  6. Запуск сюиты из внешней системы по http trigger link-e (например, из той же CI после сборки билда)

Ускорение за счет распараллеливания с учетом пула ресурсов:

БЫЛО:

  1. распараллеливание поддерживается в testNG и вроде как в последних версиях junit.
    Но в реализации cucumber - нет, не говоря о других фреймворках.
    Так же это уже не территория CI, а внешнего к нему процесса.
  2. допустим, есть подход! но чего не хватает?
    а) Дело в том, что могут быть тесты в сюите, которые не могут запускаться в параллель - будут ошибки. Например: 1 тест проверяет аварийное восстановление нод, в этот момент не будет работать определенная функциональность, которая завалит другие тесты (хотя они на самом деле они - passed)
    б) у вас ограниченное кол-во ресурсов необходимого тестам (браузеров, каналов, агентов, пользователей, и.т.д.) и Вы не хотите, чтобы система позволяла запускать тест, если в пуле все
    подходящие заняты в использовании другими тестами, а запускала его, когда наконец освободятся, то современные фрэймворки не поддерживают этот механизм.
    с) Более того, несколько пользователей могут запустить тесты одновременно в системе,
    потоки то работать будут, ускорение будет, это хорошо, но потенциально будут “мешать” друг другу в доступе к необходимым ограниченным ресурсам.

СТАЛО на Bali:

  1. вы можете запустить в параллель любой жава код (testNG, классический Java Main, jUnit, сценарии на Cucumber c точностью до подсценариев) причем сделать это оригинальным движком фрэймворка, здесь есть свой механизм TestExecutor-ов, т.е. задача решена универсально.
    см. страницу фичи: http://test-execution.com/page97470.html

  2. Реализован механизм пула ресурсов. Каждый тест помечает, какие ресурсы ему нужны в
    работе. Движок запускает тест в обработку, если есть свободные ресурсы в пуле,
    сначала блокирует их, после выполнения теста - разблокирует.
    Несколько человек может запустить несколько сюит одновременно - все корректно отработают, даже если используют схожий тип ресурса.
    см. страницу фичи: http://test-execution.com/page96209.html

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

Детализация информации о прогоне и управление им:

БЫЛО:

  1. на CI виден запуск процесса и можно сделать так, чтобы видеть сводку базовую
    запущенно, пройдено, завалено ( примерно в таком стиле),
    скорее всего это сделано на основе обмена через файл между процессами
  2. Отчет-артифакт строиться в конце, необходимо ждать (если прогон длинный - до нескольких часов)
  3. прогон можно отменить (убить процесс) только сразу целиком, нельзя убрать определенное подмножество из запуска

СТАЛО:
cм. фичу http://test-execution.com/page96177.html

  1. В онлайн доступна максимально подробная обновляемая (ajax) информация о запущенном сюите, список тестов, в каком статусе каждый (ждет, запущен, прошел, завален, сколько ошибок,
    какие ресурс из пула необходимы и использует), суммарная статистка.
  2. Сразу доступ к актуальным 3-м видам отчетов: классификационный об ошибках,
    отчет о шагах теста(как правило screenshot flow, сами выбираете что и как туда вставлять), отчет по метрикам (можно пушить цифры и видеть их в графиках)
  3. любой тест из сюита можно выключить из списка прогона
  4. rerun: отправить тест на перезапуск сначала в рамках сюита (его ошибки удаляются из отчета по ошибкам )
  5. wait of error: сказать, чтобы поток вставал на паузу при достижении тестом ошибки, потом после отладки нажать resume и продолжить работу потока исполняющего тест.
    (удобно использовать при воспроизведении длинных сценариев)
  6. Soft Stop (мягкая остановка): тестовому контексту поставить признак мягкой остановки, и тест
    в определенной точке смотрит его, понимает что нужно завершить себя изнутри.
    если такой нет, на всякий случай есть функция
  7. Жесткая остановка: послать потоку Thread.stop(), не рекомендуется использовать депрекейтед , но в основном работает, хотя и не всегда :wink: Предпочитаю использовать soft stop.
  8. так же вызвать soft stop для всего сюита целиком

Управление запуском напрямую с отчета по ошибкам:

Было:

  1. есть статический отчет,
    если необходимо перезапустить какие-либо тесты, например по причине,
    что ночью сетка упала на час, и 20% попадало, то
    нужно либо перезапустить все (что плохо, т.к долго и повторно), либо запоминать
    эти 20% тестов (300 * 20% = 60 названий) и готовить для них руками отдельный build.xml

Стало: см шаг 17, 18 (из Quick Start Demo)
прямо из классификационного отчета по ошибкам вы можете отправить тесты,
блокируемые определенной причиной (находятся в одном классе) на перезапуск

  1. в текущем сюите в один клик, ошибка уйдет из отчета и будут уже добавлены свежие
  2. в новом сюите, но уже на выбранных окружениях из списка тоже в пару кликов

Нагрузочное тестирование:
http://test-execution.com/page95167.html (cм. пункт Load Testing)

Стало:

  1. в дереве тестов включите Load Mode
  2. напротив каждого runnable item появится поле для ввода кол-ва
    потоков (пользователей), который дожен делать сценарий.
  3. введите длительность и период rumpUP между стартом потоков и
    нажмите старт.
  4. в режиме контекста loadMode тесты не делают тяжелых и длинных ассертов, логируют например время открытия страницы, либо тест-измеритель собирает информацию о памяти и процессоре, кладет в отчет по метрикам (Bali Metrics API)

Таким образом ваши еще вчерашние функциональные тесты, в один поворот слали работать в контексте нагрузочных! В отдельной статье напишу о положительных кейсах использования
на реальном проекте (1500 phantomjs браузеров, 1500 реальных потоков-пользователей, где из-за
насыщенного Vaadin-а во фронтэнде традиционный jmeter скриптинг не подходил).

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

CI cистемы я использую в своей практике для деплоя билдов, запуска юнит тестов, запуска сюиты
на Бали по ссылке-стартеру, там где не очень нужны гибкие возможности управления.

Для управления запуском более менее же сложных интеграционных тестов - с 2012 выбираю Bali, по необходимости добавляю новые фичи, идеи.

Спасибо,
Кирилл


(Black Box Blues) #12

Имхо, задумка интересная. Далеко не все прльзуются CI и навороченный контроллер тестов имеет право на место под солнцем.

Что смущает:

  • очень много буков :slight_smile: Сходу не понятно, что и зачем. Тут я полностью соглашусь с ArtOfLife

  • не ясно, как этим пользоваться, если тестовый фреймворк написан не на Java.

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

Если это все же опен-сорц, то (имхо) было бы эффективней делать это как расширение к тому же Jenkins. Вы бы сразу попали внутрь огромного сообщества, шансы на качественное тестирование и фидбэки резко б возрасли.


(Kirill Konoplev) #13

Добрый день,

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

Порог вхождения - достаточно низкий, quick start demo можно сделать минут за 15.
И тут же продолжать demo проект в своих целях. 5 потоков достаточно, чтобы уже получать
хорошее ускорение.

Тул использовался уже давно с 2012 года в 3-х компаниях: Informatica Corp, Deutsche Bank, Trans IT.
И прожил не один проект. Не сказать, что он сырой, но какие-то может баги и будут.

это самостотельное веб приложение, а не приложение к какой-либо платформе.
Да, поэтому на хвост не сядешь )

Спасибо,
Кирилл


(Kirill Konoplev) #14

Евгений,

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

Спасибо


(Kirill Konoplev) #15

Добрый день,

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

Кстати, установка и запуск quick start demo занимает минут 20, ни о каких усилиях в множество
часов речи не идет. Про видео хорошая идея, кашу маслом не испортишь, может потом и сделаю.

Спасибо


(Kirill Konoplev) #16

Добрый день,

Был в отпуске некоторое время, ответ к сожалению затянулся.

Добавил на сайт статью, где описал новые возможности инструментария по сравнению
с классическим подходом по разным категориям:
“What Bali brings to your process implementation in compare with common CI based”
http://test-execution.com/page100421.html

Сейчас готовлю блог с парой статей о примерах внедрения и использования из моей практики
(нагрузочное тестирование на 1500+ реальных phantomJs браузерах, запуск тестов Cucumber JVM итд).


(Sergey Pirogov) #17

Сайт реально круче чем тул =)) Скриншоты и UI представление инструмента навеваем совком. Пока что совсем не хочется его даже просто скачать и попробовать дома.