Тесты "моргают" и в Гугле. Интересный доклад. Радует, что у нас используются похожие методы определения и борьбы с "моргунчиками", хотя сравнение объемов и масштабов может вызвать лишь сочувственную, по отношению к нам, улыбку.
"Моргающие" тесты - неизбежность (1.5% от запусков)
Интересная дока из доклада https://pdfs.semanticscholar.org/02da/46889ee3c6bc44bfa0fc45071195781b99ce.pdf
На каждое изменение запускается 3.5М тестов. Все результаты в базу и там уже хранятся данные за 2 года.
Не позднее, чем через 2 (хотя иногда 3) часа разработчик узнает о том как прошли тесты по его изменению
Каждый фейл анализируется с предыдущим по целому ряду параметров (все берется из базы результатов), чтобы понять действительно ли это "моргание" в том же самом месте или что то новое.
В течении 6 месяцев один из докладчиков анализировал 2-летние результаты прогонов тестов, а также полную историю изменений исходников, которые этими тестами проверялись.
Результаты анализов планируется использовать для быстрого определения "моргающего" теста, в т.ч. без его перезапуска
Наблюдения:
- Чем чаще тест переключается из "зеленого" в "красный", тем с большей уверенностью мы можем считать его "моргающим" (разработчик не может так часто ломать код)
- Если у тестов совпадает история, то скорее всего причина не в "моргании", а в поломанном коде.
Анализ по корреляции изменений в исходниках:
Корреляция "поломок" по авторству изменений исходников (чем выше процент, тем меньше шансов, что тест отвалился из-за "моргания")
Чем больше людей меняет файл, тем меньше шансов на то, что fail был из-за "моргания".
В конце 15 минут интересных вопросов-ответов.
PS если кому то интересно, то они ищут еще желающих проанализировать их данные.
PS2 остальные доклады на сайте конфы и в плейлисте.
PS3 рекомендую эти "Using Test Run Automation Statistics to Predict Which Tests to Run" и "Need for Speed - Accelerate Automation Tests From 3 Hours to 3 Minutes"
Комментарии
Отправить комментарий