Комментарии 6
Сейчас нас интересует вкладка «Сценарий».
А распознавание {code} - это стандартная фишка Allure или надо писать свой класс "annotation expander"?
Это стандартная фишка, работает и c Allure Report
Интересная статья, спасибо!
Хотелось бы подробнее прочитать про то, как именно анализируете, насколько в этом помогает Allure TestOps?
Так-же, есть ли смысл вот так соотносить вручную тест-кейс и автоматизацию, не думали над генерацией тест-кейсов из таких же лейблов и прочей обёртки?
как именно анализируете, насколько в этом помогает Allure TestOps?
Очень хороший вопрос и ответ на него тянет на отдельный пост, нюансов много :) Если попытаться рассказать коротко: Allure TestOps играет роль централизованного хранилища истории теста, из этой истории можно посчитать сколько раз за промежуток времени тест "прошел" или "упал". Поделив одно на другое, получаем некий коэффициент стабильности, и из общей картины определяем, какой коэффициент нас устраивает, а какой - нет.
не думали над генерацией тест-кейсов из таких же лейблов и прочей обёртки
Об этом в статье и шла речь, мы не храним тест-кейсы отдельно от автотестов, они могут существовать в кратком виде до того как появятся сами автотесты, а дальше все генерируется автоматически.
Мы используем Robot Framework для написания автотестов, тесты гоняем в GitlabCi и результаты через robotframework listener отправляем в БД.
При использовании Allure для каждого теста нужно прописать название теста, шаги теста и прочее, а это, учитывая кол-во тестов (больше 10 000 штук) очень много работы) Как решали проблему: правили готовые тесты, а новые писали сразу используя Allure? Рассматривали вариант использовать систему отчёта со встроенными Listener-ами (например, Reportpotal умеет, не сильно отличается от Allure по функционалу)?
До использования Allure Test Ops мы пользовались Allure Report, то есть привычка развешивать аннотации для степов и классов в компании уже была. Тем не менее, даже если бы пришлось внедрять систему сейчас, мы могли бы передавать в степ преобразованное имя java-метода, используя те же листенеры, эту же логику мы сейчас используем, чтобы не приходилось вручную писать имя теста. А что касается самих листенеров, мы используем кое-какие из JUnit5 (там вместо листенеров экстеншены) или AspectJ (который идет вместе с Allure, и хоть это и не совсем листенер, но суть в контексте та же) для того, чтобы, например, автоматически прокидывать методы с @BeforeEach как самостоятельные степы.
Интеграция с Allure: структурировать, упростить, стабилизировать