t.me/atinfo_chat Telegram группа по автоматизации тестирования

Сколько раз можно/нужно перезапускать упавший UI-тест?

Теги: #<Tag:0x00007f7487954db0> #<Tag:0x00007f7487954ce8>
#1

Мы в проекте сделали повторный запуск упавших UI-автотестов. Есть возможность задавать количество перезапусков (хоть 0, хоть 10). Какое количество перезапусков вы посоветуете использовать? Были где-то интересные обсуждения на эту тему? Что можно почитать по этому поводу?

Я поискал на форуме темы про перезапуск failed-тестов, вроде бы сам подход используется. Но обсуждения количества попыток перезапуска не нашёл. Все подразумевают что достаточно 2х прогонов - одного основного запуска и одного перезапуска упавших в первом запуске тестов? Или кто-то использует более одного перезапуска?

У нас есть много UI-автотестов, они стабильно работают в ~90% запусков, но где-то в ~10% запусков они выдают ошибку. Над улучшением стабильности мы работаем, но 100% стабильности добиться вряд-ли получится. (Инструмент - Telerik Testing Framework, но в данном случае это не важно)

2 Симпатий
#2

Я считаю, что достаточно 1 запуска и 1-2 перезапусков. Оставшиеся после этого падения анализируются вручную. То есть перезапуск по сути используется в качестве дополнительной фильтрации, чтобы меньше тратить времени на ручной анализ. Не вижу смысла перезапускать до посинения

Количество перезапусков определяется, на мой взгляд, следующим:

  • количеством времени на прогон и анализ. Если прогнать тесты быстрее, чем вручную их разбирать, то можно перезапускать побольше
  • причинами нестабильности тестов. Бывает, что тестируется функционал продукта, использующий интеграцию с другими продуктами и потому стабильность тестов может порой “хромать” по причине стабильности тестируемого приложения. Если такое подозрение есть, то имеет смысл ещё разок перезапустить, убедившись, что на этот раз возможные причины исправлены. Если же причины зачастую в самих тестах, то имеет смысл больше времени потратить на их стабилизацию, чем на перезапуск

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

И стоит различать перезапуски автоматические (безусловные) и осознанные (после предварительного анализа падений). Безусловных быть либо не должно совсем (особенно, если время прогона тестов слишком велико), либо должен быть 1. Потом должна следовать стадия хотя бы поверхностного анализа и определение дальнейшего плана действий

1 Симпатия
#3

Когда-то добавлял фичу перезапуска в свой фрейм. Немного попользовался - понял, что польза от нее весьма сомнительна. Даже при однократном перезапуске могут быть кейсы, когда окружение просто лежит. В итоге весь suite будет долбиться x2 раз в мертвый env. Ну или если сам тест занимает много времени и падает из-за бага чуть ли не на последнем степе, а потом опять повтор. Т.е. общий execution time возрастает до неприличия. А команде нужен быстрый фидбэк.

В итоге, я пришел к тому, что качественный / вменяемый репортинг гораздо эффективней повторных перезапусков. Заглянул в репорт / лог - сразу увидел проблему, скопипастил степы в трекер / разослал имейл / смс с резолюцией по билду и все довольны.

С нестабильными тестами надо бороться. Если проблемы на стороне автомейшена, скорее всего они носят характер незнания основ языка / ООП / паттернов / каких-нибудь архитектурных моментов. А если виной тому - баги приложения, то об этом надо сразу же доносить на скрамах, ретроспективах и т.п. Пусть фиксят, если хотят качественных результатов. Не вижу смысла покрывать эти проблемы путем многократного перезапуска - авось повезет и запасится. У нас, к примеру, билд не выкатывают мануальщикам, пока unit / integration / smoke UI automation не будут 100% green.

8 Симпатий
#4

Полностью соглашусь с комментарием @ArtOfLife. Автоматический перезапуск можно попробовать использовать, но только если общее время выполнения тестового набора небольшое.
У нас, например, автотесты крутятся в continuous integration, поэтому позволить себе нестабильные тесты мы не можем: если билд “падает”, то мы должны быть уверены, что это кто-то что-то сломал, а не что очередной тест упал.

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

#5

Нужно запускать одни раз и перезапускать два и смотреть если один раз упал и два прошел, значит флаки тест, если два раза упал и один раз прошел, то нужно дебажить! Больше двух перезапусков = марна трата времени и сил.

1 Симпатия
#6

имеет смысл