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

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

В системе управления тестированием Test IT есть комплекс удобных фичей, способных облегчить жизнь автоматизаторам — категоризация ошибок автотестов. С ее помощью мы можем «научить» автотесты говорить сами за себя, помогая AQA в анализе. 

Разберем в статье, как настроить категории, используя функциональность регулярных выражений (RegEx), откуда их брать, чтобы получить качественные отчеты о прогонах автотестов.

Учим автотест определять причину падения

Как правило, автотесты состоят из трех ключевых частей:

1. A — Arrange. Подготавливаем продукт для тестирования

2. A — Act. Делаем тестируемый шаг

3. A — Assert. Проверяем результат

Конечная цель автотеста — автоматическая генерация понятного отчёта. 

Пример из Test IT:

Ищем маркеры ошибок

Ключевые причины падения автотестов:

1. Проблема в продукте — дефекты объекта тестирования;

2. Проблема в автотесте — не поддержан, неверно написан;

3. Проблема в окружении, инфраструктуре — железо, браузер и другие сторонние проблемы.

У каждой причины есть маркеры, ищем их в логах автотестов.

Проблемы продукта

Как определить на уровне кода, что причина падения автотеста в продукте? 

• FlowException

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

Пример:

1. После авторизации мы ожидаем открытия приложения

2. После удаления сущности мы ожидаем, что она пропадает с экрана

Таким образом мы формируем спецификацию продукта. Чтобы автотест сам детектил отклонения от ожидаемого результата, ему надо дать вводные. 

Что для этого нужно? Обеспечить атомарность наших Page Object’ов и их методы, т.е. они должны иметь:

1. Логическое начало — не начинать работу, пока всё не будет загружено

2. Логическое окончание — не отдавать управление дальше, пока работа не будет завершена.

Не начинаем работу до тех пор, пока элемент не будет загружен.

Не обрабатываем данные, если входные значения неудовлетворительные.

Нажимаем на кнопку — ждём, пока все операции пройдут, лоудеры исчезнут.

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

• Asserts

Все шаги теста выполнены, все поля заполнены, все кнопки были прожаты, а финальный результат не сошёлся — 98%, что проблема в продукте. Если бы какие-то кнопки не прожались или что-то не было загружено, у нас бы упала ошибка раньше.

Проблемы автотестов:

• Плохие или неподходящие теги

Теги могут устаревать, перемещаться, изменяться. При написании селекторов могут допускаться опечатки, ошибки. Всё это характеризуется следующими маркерами:

• NoSuchElementException

• NotFoundException

• InvalidSelectorException

• ElementNotVisibleException

• Автотест не смог кликнуть, промазал, кликнул по некликабельному элементу

В интерфейсе часто встречаются движущиеся элементы, элементы могут перекрывать друг друга. Бывает такое, что в момент клика кнопка имеет координаты отличные от момента инициализации. 

Маркеры:

• ElementClickInterceptedException

• ElementNotVisibleException

• ElementNotSelectableException

• ElementNotInteractableException

• Обратился к старому элементу

И, конечно же, любимая ошибка — это элемент устарел (StaleElementReferenceException). Эта ошибка говорит нам о том, что элементы в DOM-дереве обновляются динамичнее, чем мы успеваем заметить. И необходимо их инициализировать непосредственно перед использованием. 

Маркер:

• StaleElementReferenceException

Проблемы инфраструктуры:

Проблемы инфраструктуры могут быть самые разнообразные. Но как правило мы знаем их в лицо:

• Нет свободных браузеров, Selenium Grid

• Браузер устарел

• Закончилась память
• Закончились лицензии
• Нет доступа к тестовому стенду
  • Этот хост неизвестен. ---> System.Net.Sockets.SocketException: Этот хост неизвестен..
  • OpenQA.Selenium.WebDriverException: unknown error: net::ERR_NAME_NOT_RESOLVED
• RemoteDriverServerException
• SessionNotCreatedException
• WebDriverException
• ConnectionClosedException
• NoSuchSessionException
• NotConnectedException
• DriverServiceNotFoundException

Автоматизируем определение причин падения

Регулярные выражения (Regular expression, RegEx) — язык поиска в тексте, основанный на использовании метасимволов. Для поиска используется строка-образец, состоящая из символов и метасимволов и задающая правило поиска

Артефакты нашей работы — текст ошибок, результат наших прохождений. Чтобы система выдавала уже готовые результаты, необходимо вбить ключевые слова или правила определения категорий. В системе Test IT заходим в модуль автотесты в раздел «Категория ошибок», где уже вбитые маркеры выглядят следующим образом:

Если нужно детально отследить каждую ошибку, частоту её повторения, можно декомпозировать эти категории:

Автоматизация

Использование регулярных выражений в Test IT работает следующим образом: в следующий раз, когда автотест упадет, например, с такой ошибкой:

Test IT обработает входящий текст, найдёт там ключевое слово и автоматически определит категорию ошибки. В примере выше это Автотест. И так с каждым упавшим тестом. 

Если тест упадет по какой-то уникальной, редкой и неразмеченной причине, то такие инциденты намного удобнее исследовать — они будут выделяться. А если причина стандартная, но не попала под наши категории, необходимо прокачать категории. Так мы и пришли к нашему идеальному отчёту: