и почему изучение тесткомплит ограничивает выбор и рост

Прочитай текст на своей аватаре.

как сказать, а особенности...

Поведение вебдрайвера - языконезависимый протокол, описанный в W3C. Особенности могут быть у драйвера конкретного браузера (или версии оного), или же у обвязки над этим драйвером (напр. селениум).

Поведение вебдрайвера - языконезависимый протокол, описанный в W3C. Особенности могут быть у драйвера конкретного браузера (или версии оного), или же у обвязки над этим драйвером (напр. селениум).

ВО!!! Лучше и не скажешь, я об этом и имел ввиду, говоря об особенностях...

Если говорить об актуальных версиях браузеров, то я бы не сказал, что там много особенностей. 99% задач в пределах одного инструмента (напр. селениум) решаются абсолютно идентично, с поправкой на синтаксис языка.

Прочитай текст на своей аватаре.

интересное замечание?

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

Всем привет, Такой вопрос Есть Jenkins - подключили плагин Allure И в Allure показываются результаты прогона, накапливая тесты за все прогоны. Это очень неудобно, если хочешь увидеть результаты именно последнего прогона. Сталкивался кто?

Всем привет, Такой вопрос Есть Jenkins - подключили плагин Allure И в Allure показываются результаты прогона, накапливая тесты за все прогоны. Это очень неудобно, если хочешь увидеть результаты именно последнего прогона. Сталкивался кто?

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

вы куда складываете результаты на прогон? Они должны собираться на один билд и в дальнейшем там и оставаться, а не ложиться в отдельную от билда папку

Да и обычно maven clean чистить папку, и старые результаты не отображаются

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

Купить за 100р. симку и не париться?...

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

Заказала через менеджера 10 симок, засунула в тестовые девайсы

++

вы куда складываете результаты на прогон? Они должны собираться на один билд и в дальнейшем там и оставаться, а не ложиться в отдельную от билда папку

у нас есть только папки с джобами.. билдов там не вижу в этой папке для джобы есть папка allure-results - куда и складываются все результаты прогонов..

Сброщик maven?

В билд идут результаты после обработки allure-cli, а xml результаты по умолчанию в /target/allure-results

Если у вас другой сборщик или язык, то просто чистите папку allure-results перед запуском

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

Если настроен плагин jenkins для allure, то он сохраняет обработанную версию результатов allure в информацию о билде, и allure results уже не нужны

таким образом у нас останется только результат последнего прогона? результаты прошлых прогонов будут автоматом удаляться? верно понимаю? как по мне это тоже не самое красивое решение

что мешает вам указать папку для генерации отчета, примешав в ее название build-specific информацию, например, ревизию в Teamcity или Jenkins

каждый раз у вас будет создаваться новая папка на новый прогон. Если у вас один и тот же билд прогоняется и нужно делать отчеты per build и не per run - придумайте перезатирание папки уже существующей. Комнадная строка, интерфейс аллюра + системные проперти позволяют сделать как хочется.

кто знает как в draw.io увеличить размер холста?

Перетащи элемент за холст

на правой панели "Paper size" -> "Custom" -> размер в дюймах

на правой панели "Paper size" -> "Custom" -> размер в дюймах

да, спасибо!

Всем привет! Подскажите пожалуйста инструменты для сравнения прогонов автотестов? Если прогон состоит из нескольких тысяч тестов, в каждом произвольное количество шагов? Динамика одного и того же теста на протяжении нескольких тестранов, прилинкованные дефекты, вот это все? Встроенные diffы логов может где-то есть?

Пока единственный известный мне кандидат это https://github.com/reportportal/reportportal/releases/tag/3.0.5

динамика тестов - это все есть в CI, например, Teamcity

Что-то есть в TestRail, XRAY для Jira, но когда дело доходит до разгребания 500 фейлов из 3000, да ещё и гуляющих, хотелось бы какой максимально автоматизированный комбайн. Чтобы известные проблемы заполнялись автоматом, например, из предыдущих n прогонов... Из этой оперы

Testrail это жизнь

динамика тестов - это все есть в CI, например, Teamcity

А он репорты умеет строить cо списком проблем и дефектов? То что сегодня зафейлилось 915 а вчета 867 тестов само по себе не так интересно ) Что стабильно валится, что новое, что туда-сюда, надо исследовать, вот тебе шаг лога, давай по кнопке приведу стенд в нужное состояние, сомжешь руками потыкать?

В списке ваших требований не хватает ещё, чтобы он сам чинил тесты или код, а потом сам деплоил на прод. :/

ну вот пример. Упали два теста на первой странице. Проваливаешься в один из них и смотришь истрию его падений

ERROR: S client not available

ну да, на тест кликаешь и получаешь логи и прочую подробную инфу

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

А к описанию тескейса у вас првязка сделана?

нет, в самом ТС ты привязки не найдешь. Описание кейса - в эксель таблице, которая заодно является провайдером тестовых данных

это решение не для эффективных менеджеров, а для инженеров ?

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

Но тоже не идеально. Епамовская приблуда выглядит интересно

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

эксель - это очеловеченный шаг по работе с базой данных и хранением сценария\данных в одном месте.

короче возвращаясь к вопросу о том, "почему тесты упали". Если они упали по вине тестировщика - это задача тимлида понять, кто косячит - делает кейсы Error. и выписать ему приветы. Для этого хватает истории Teamcity по коммитам и тому, какие сборки эти коммиты триггернули.

Если это проблема разработчиков - это проблема тимлида, найти тех, по чьей вине тесты Failed и выписать им приветы при отклонении от нормы.

Род ошибок, пропущенная запятая - это от лукавого. Оно частично пролечивается грамотным тегированием в джире\багтрекере и проставлением компонентов. Для выявления ошибкоопасных мест. Низкоуровневые штуки c месседжами NoneType object is not callable и другие популярные фразы компилляторов не дадут сколько-нибудь красивой метрики и руководства к действию. Моё имхо: находить виноватые компоненты и косячащих разработчиков. Находить зоны ответсвенности, а не ЧТО валит твои тесты. Твои тесты валит говнокод, это же очевидно.

Ох, спасибо за развернутый ответ.

В моем случае, к сожалению, очевидный подход не работает

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

Каждый релиз )

Соответственно, чтобы найти зону ответственности, сначала нужно локализовать проблему

Найти всю историю, связанную с этой фичей, как легаси, так и то что находится на стадии аналитики