При регулярном регрессионном автоматическом тестировании и при больших объемах запусков функциональных автоматических тестов, становится актуальной проблема стабильности этих тестов и проблема «падений» на уже известных, но не исправленных дефектах тестируемого продукта.
Существует множество причин и факторов приводящих к ложным «падениям» автоматических тестов, таких как — перегрузка тестовых серверов, повышенная сетевая активность, рейс-кондишины при использовании внешних сервисов, а также нестабильность под нагрузкой самого тестируемого продукта или библиотек в нем используемых.
Другой стороной проблемы являются баги в продукте, исправление которых занимает длительное время. Такие баги приводят к падениям одних и тех же тестов на протяжении нескольких циклов тестирования.
Все это приводит к лишним затратам времени инженеров на разбор «упавших» тестов и оценке реальной картины происходящего. Так, к примеру, на стадии стабилизации продукта, когда процесс разработки новых фичей завершен, и львиная доля багов исправлена, процент ложных срабатываний тестов может превышать 50%. И напротив, при активном девелопменте новой функциональности, инженеры вынуждены анализировать изо дня в день падения одних и тех же тестов, баги по которым уже заведены и ожидают своей очереди на исправление.
В данном докладе отражен объем «бедствий», вызванный этими проблемами, при регулярном регрессионном тестировании линейки продуктов Parallels Plesk Panel. И описаны два решения, призванные свести к минимуму влияние обеих проблем на регулярное автоматическое тестирование.
Презентация:
Запись выступления:
