Новый релиз Test IT Enterprise ver. 4.6 Chamaeleon уже на сайте!

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

118

Автоматизация тестирования — великое достижение команды, которое ускоряет 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 обработает входящий текст, найдёт там ключевое слово и автоматически определит категорию ошибки. В примере выше это Автотест. И так с каждым упавшим тестом. 

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

Была ли статья полезной?