Учим автотесты самостоятельно определять причину падения в Test IT
Автоматизация тестирования — великое достижение команды, которое ускоряет QA-процессы, освобождает QA-инженеров от рутины, помогает увеличить полноту тестового покрытия, понятность и достоверность результатов и многое другое. Пока автотесты полностью не заменили человека, но очень к этому стремятся, и мы можем им помочь.
Автоматизаторы, помимо разработки автотестов, очень большую часть времени тратят на анализ логов автотестов. После прогона автотестов мы можем получить гигабайты логов, и затем весь день сидеть и разбирать результаты, искать флакающие (нестабильные) тесты, перепроверять их работу.
В системе управления тестированием Test IT есть комплекс удобных фичей, способных облегчить жизнь автоматизаторам — категоризация ошибок автотестов. С ее помощью мы можем “научить” автотесты говорить сами за себя, помогая AQA в анализе.
Разберем в статье, как настроить категории, используя функциональность регулярных выражений (RegEx), откуда их брать, чтобы получить качественные отчеты о прогонах автотестов.
Открытый вебинар «Автоматизация тестирования в Test IT — API, webhooks и CI/CD» с Михаилом Рябовым
Учим автотест определять причину падения
Как правило, автотесты состоят из трех ключевых частей:
- A — Arrange. Подготавливаем продукт для тестирования
- A — Act. Делаем тестируемый шаг
- A — Assert. Проверяем результат
Конечная цель автотеста — автоматическая генерация понятного отчёта.
Пример из Test IT:
Ищем маркеры ошибок
Ключевые причины падения автотестов:
- Проблема в продукте — дефекты объекта тестирования;
- Проблема в автотесте — не поддержан, неверно написан;
- Проблема в окружении, инфраструктуре — железо, браузер и другие сторонние проблемы.
У каждой причины есть маркеры, ищем их в логах автотестов.
Проблемы продукта
Как определить на уровне кода, что причина падения автотеста в продукте?
FlowException
Можно регламентировать все ожидаемые результаты работы продукта. С этим нам помогают тест-кейсы. У каждого действия в тест-кейсе есть ожидаемый результат.
- После авторизации мы ожидаем открытия приложения
- После удаления сущности мы ожидаем, что она пропадает с экрана
Таким образом мы формируем спецификацию продукта. Чтобы автотест сам детектил отклонения от ожидаемого результата, ему надо дать вводные.
Что для этого нужно? Обеспечить атомарность наших Page Object’ов и их методы, т.е. они должны иметь:
- Логическое начало — не начинать работу, пока всё не будет загружено
- Логическое окончание — не отдавать управление дальше, пока работа не будет завершена.
Автоматизация тестирования desktop-приложений
Не начинаем работу до тех пор, пока элемент не будет загружен.
Не обрабатываем данные, если входные значения неудовлетворительные.
Нажимаем на кнопку — ждём, пока все операции пройдут, лоудеры исчезнут.
Если на этом пути происходит сбой, т.е. падает 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
Автоматизируем определение причин падения
Регулярные выражения (Regular expression, RegEx) — язык поиска в тексте, основанный на использовании метасимволов. Для поиска используется строка-образец, состоящая из символов и метасимволов и задающая правило поиска
Артефакты нашей работы — текст ошибок, результат наших прохождений. Чтобы система выдавала уже готовые результаты, необходимо вбить ключевые слова или правила определения категорий. В системе Test IT заходим в модуль автотесты в раздел “Категория ошибок”, где уже вбитые маркеры выглядят следующим образом:
Если нужно детально отследить каждую ошибку, частоту её повторения, можно декомпозировать эти категории:
Автоматизация
Использование регулярных выражений в Test IT работает следующим образом: в следующий раз, когда автотест упадет, например, с такой ошибкой:
Test IT обработает входящий текст, найдёт там ключевое слово и автоматически определит категорию ошибки. В примере выше это Автотест. И так с каждым упавшим тестом.
Если тест упадет по какой-то уникальной, редкой и неразмеченной причине, то такие инциденты намного удобнее исследовать — они будут выделяться. А если причина стандартная, но не попала под наши категории, необходимо прокачать категории. Так мы и пришли к нашему идеальному отчёту:
Источник: testit.software
Autotest что это за программа
Многие уверены, что работа программиста — писать код. Это не так. Работа программиста — приносить пользу, увеличивать прибыль и снижать издержки.
Автоматические тесты — инструмент снижения издержек. Есть тесты — смело и быстро добавляете фичи. Нет тестов — проверяете изменения вручную, теряете время и деньги.
Автотесты принято делить на три типа: модульные (юнит), сервисные и интеграционные ( UI , браузерные, end‑to‑end, E2E ) тесты.
Модульные тесты проверяют работу отдельно взятых модулей — функций, классов, моделей, контроллеров — кирпичиков, из которых построено приложение. Модульные тесты выполняют проверки за миллисекунды, потому что тестируют модуль в отрыве от остального приложения.
Интеграционные тесты проверяют приложение целиком, когда все модули в сборе. Их задача — убедиться, что модули правильно соединены друг с другом. Кроме того, ими проверяют те части приложения, которые не имеют права сломаться: биллинг, регистрацию, оформление заказа. Интеграционные тесты длятся секунды, а иногда и минуты: запускаем приложение, загружаем его в браузер или эмулятор и «прокликиваем» сценарии.
Сервисные тесты — среднее между интеграционными и модульными. Их задача — проверить функционал, который нельзя уверенно протестировать модульными тестами, а интеграционными тестировать «слишком жирно».
Такое разбиение тестов по уровню детализации программисты используют в «тестовой пирамиде» — визуальной метафоре, которая подсказывает, сколько каких тестов лучше иметь:
Чем выше тест, тем он медленнее и дороже в создании и поддержке
Идея простая: чтобы у приложения была быстрая и отзывчивая к изменениям тестовая база, большая её часть должна приходиться на модульные тесты, небольшая часть — на сервисные, малая часть — на интеграционные.
Покажу на примере. Представим, что нужно запрограммировать добавление комментариев к фотографиям. Если отказаться от модульных тестов и всё проверить интеграционными, мы получим очень медленную и хрупкую тестовую базу. Работать с такими тестами будет мучительно: любые изменения в коде будут проверяться минутами.
Если отказаться от интеграционных тестов и всё проверить модульными, может оказаться так, что тесты проходят, а добавление комментариев не работает из‑за ошибки на стыке модулей. Доверять таким тестам нельзя, придётся добавление комментариев проверять вручную.
Поэтому лучше начать с единственного интеграционного теста, который открывает фотографию в браузере, заполняет форму, нажимает «Отправить» и проверяет, что комментарий появился на странице. А затем добавить модульных и сервисных тестов, которые проверят всё остальное: автоматическое форматирование текста комментария, санитайзинг, валидацию и почтовое уведомление автору фотографии.
Источник: bureau.ru
Автоматизированное тестирование сайта — за и против. С расчетами
Тестирование — заключительный этап разработки сайтов и программного обеспечения. Он позволяет ответить на три важных вопроса: соответствует ли продукт изначальной задумке, все ли работает как надо и что нужно сделать, чтобы ответ на первые два вопроса был положительным.
Передача проекта тестировщику — по сути, репетиция финального согласования с клиентом и отправки продукта в массы. То есть тестировщик — это тот же клиент и пользователь, только на стороне агентства. И его задача — сделать так, чтобы на выходе получить качественный продукт, который соответствует ожиданиям или превосходит их.
Есть два типа тестирования: ручное и автоматизированное. В первом случае контроль качества производит человек — тестировщик (или QA-инженер) — посредством моделирования действий пользователя. Специальные программы для проверки сайта не применяются.
Во втором случае запуск, инициализация, выполнение, анализ и выдача результата производятся автоматически с помощью специальных инструментов. Тестировщик обрабатывает полученные результаты.
Рассмотрим оба типа подробнее.
Преимущества и недостатки ручного и автоматизированного тестирования
В маленьких компаниях тестированием занимаются сами менеджеры проектов. В компаниях побольше — тестировщики (QA-инженеры), которые применяют ручные методы проверки продуктов. Дальнейший рост компании подразумевает рост количества проектов, а значит есть 2 решения: или увеличить штат специалистов, или сделать так, чтобы при том же количестве тестировщиков сохранилось (а лучше — чтобы улучшилось) качество на выходе. Какое решение выбрать — дело за вами. Чтобы вам было проще сориентироваться, мы сравнили оба типа тестирования.
Источник: www.uplab.ru
Home
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Сегодня мы завершаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика, менеджера и технического директора. Пришло время ответить на пять самых интересных вопросов начинающих автоматизаторов — про флакования и баги с прода, нашу борьбу за стабильность и как не терять всеобщее доверие к автотестам.
Видеоверсию моих ответов можно посмотреть и послушать тут.
Вопрос 1. Мы пишем и прогоняем автотесты, а баги с прода все равно прилетают.
Начнем с того, что баги с прода продолжат прилетать в любом случае, и это совершенно нормально.
Пользователи могут совершать с вашим приложением невообразимые действия и проходить невероятные, непредсказуемые сценарии — открыли, перешли в другое приложение, заблокировали телефон, получили пуши, где-то полистали новости и решили вернуться в наше приложение. И вот тут-то баг его и поджидает. Частично такие кейсы можно автоматизировать — с помощью нагрузки, прерываний и выгрузки в фон и т.п. Но все возможные уникальные сценарии покрывать автотестами точно не стоит. Как минимум потому что ни один CI не выдержит такой загрузки, а время тестового прогона не будет того стоить.
Также могут быть девайс-зависимые баги, которые невозможно отловить автотестами, если вам не повезло тестировать именно на этом устройстве. Можно, конечно, попробовать настроить CI так, чтобы он создавал разные эмуляторы, или гонять автотесты на разных реальных девайсах, но это значительно увеличит сложность поддержки таких автотестов и скорее всего снизит их стабильность. И, опять же, это не будет стоить увеличенного времени на поддержку и прогоны, особенно с учетом, что находимые баги будут минорными.
Вопрос 2. Как сделать так, чтобы автотесты не заставляли всех страдать?
Чтобы автотесты не заставляли страдать всех вокруг, достаточно следовать некоторым правилам:
Правило 1. Писать понятный читаемый код, настроить отчеты.
Тесты должны быть понятны не только вам, но и другим тестировщикам и разработчикам. Если ваш тест упал, то человек не должен сидеть над ним полдня или сразу идти к автору автотеста с “помоги, посмотри почему он упал”, а должен сам понимать место и причину падения. Еще лучше, если у вас настроены человекочитаемые отчеты, в которых также видны шаги и место, где и почему упал тест.
Никому не хочется тратить время на то, чтобы понять, как автотест работает и что он там вообще проверяет — всё должно быть прозрачно.
Правило 2. Обязательное ревью.
Чтобы убедиться в том, что ваш тест действительно полезен и идеален, нужно, чтобы кто-то еще это подтвердил, и тогда можете спать спокойно.
У нас в hh для всех задач предусмотрено обязательное ревью. Для всех задач с автотестами предусмотрено обязательное ревью от QA. Это крайне важно, так как ревьювер может найти не только неправильный отступ, но и ошибки в логике, посоветовать добавить какие-либо дополнительные проверки, или указать на то, что вы запросто могли пропустить.
Правило 3. Сразу внедрять автотесты в ваш CI/CD
Очень важно, чтобы автотесты сразу приносили пользу, а не ждали лучших времен где-то в недрах кода. Чем быстрее все начнут привыкать, что их код теперь тестируется, тем проще всем станет жить. При этом важно не забывать, что выпускать автотесты нужно максимально стабильными. Перед тем, как вмержить свои тесты, лучше в прямом смысле 100 раз прогнать их на CI. И только убедившись на 100%, что тест не флакует, не падает неожиданно в разных местах, работает и работает как надо — сразу вперед!
Вопрос 3. Из-за чего тесты постоянно падают? Как можно им доверять?
Начнем с того, что какие-то автотесты в любом случае будут падать. Это совершенно нормально, так как если они в 100% случаев всегда зеленые, стоит задуматься — а проверяют ли они вообще что-то?
Но со своей стороны мы обязательно должны сделать максимум для того, чтобы падали они как можно реже. Для этого нужно научиться быстро понимать и устранять причины падений и улучшать слабые места.
За время работы с автотестами я выявила свой личный ТОП-4 проблем с автотестами:
1 — Кто-то что-то выкатил и все упало
Тут все просто — изменения в функционале должны идти рука об руку с правкой автотестов. На такие правки мы закладываем время при оценке и декомпозиции задачи. Когда разработчик изменяет что-то в функционале, который уже был покрыт автотестами, перед тем как вмержить свою ветку, он должен поправить автотесты, чтобы они продолжали проверять этот функционал. Очень важно наладить этот процесс, не игнорить тесты, а всегда поддерживать их актуальность.
2 — Тесты начали падать, но мы ничего не меняли
Тут интереснее. Разработчик ничего не менял, но в какой-то момент тесты начали падать. Возможно, что-то поменяли на бэке.
Почему наши UI-автотесты зависят от бэкенда?
Наши автотесты гоняются на тестовых стендах — это копия продового бэкенда (без продовой базы данных). Мы поддерживаем их актуальность — каждый день автотесты запускаются на актуальном бэкенде. Соответственно, если кто-то зарелизил что-то новое, наши автотесты об этом узнают и, как следствие, могут упасть. Мы в срочном порядке бежим смотреть: баг это или наша новая реальность, которую следует поддержать. И далее либо сообщаем команде о баге, либо правим тесты.
Тут важно заметить, что это случается не при каждом изменении на бэке. Всё-таки в основном, мы синхронизируемся командами по всем изменениям. Но реальность такова, что иногда какие-то моменты упускаются — кто-то не подумал, что может зааффектить мобильные приложения, например. Наши автотесты к такому чувствительны.
Каждый раз, когда такое случается, мы задумываемся о моках. Моки — это классно, если ими не злоупотреблять. Но всё-таки я думаю, что такая чувствительность автотестов к изменениям — это нормально, потому что там мы остаемся в курсе новых фич, которые влияют на наше приложение со стороны других команд. Плюс на моки тоже нужно выделять время на поддержку и актуализацию. Тут каждый сам выбирает, что ему больше хочется поддерживать.
3 — Баги
Моя любимая причина падения автотестов. Тут можно и без комментариев. Если ваш автотест нашел баг, то это очень хороший автотест, а вы — большой молодец.
4 — Флакование
А это самая нелюбимая причина. О ней поговорим далее.
Вопрос 4. Почему мои тесты флакуют?
Флакование как эмоциональные качели — ваши тесты то зеленые, то красные, всем то грустно, то радостно, и как с этим жить никто не знает. Чтобы отношения вашего приложения и автотестов были максимально здоровыми, советуем придерживаться нескольких правил о том, как избежать флакований и писать изначально более стабильные автотесты:
1. Уникальные тестовые данные
Для каждого автотеста должны создаваться новые уникальные тестовые данные, с которыми будет работать только этот тест. Нельзя надеяться на то, что на каком-то экране точно будет что-то, что мы сможем проверить и нам ок. Предсказуемость очень важна.
2. Не забывать дожидаться элементов на экране
Вы написали логичный тест, все четко по шагам, но тест не проходит и постоянно падает в разных местах. Скорее всего где-то он не успевает дождаться нужного элемента и тапает не туда, куда бы вам хотелось. Усугубляют ситуацию различные анимации, лоудеры загрузки и внезапные алерты.
Чтобы такого не случалось, перед каждым действием над элементом (тапы, свайпы и т.д.) или ассертом (проверкой, чеком) нужно дождаться, пока этот элемент точно появится на экране и будет доступен.
У Kaspresso для android есть встроенный механизм, который перед каждым действием под капотом дожидается элемент, делая ретраи на isVisible, и только потом совершает это действие. Благодаря этому, проблем с “тапами не туда” или “тапами раньше, чем нужно” в ваших автотестах больше не будет. Также этот вейтер можно настроить на нужное/необходимое вам количество времени, так как возможно дожидаться какой-то элемент по 10 секунд на экране — это уже баг.
В XCUITest на iOS также есть вейтеры из коробки, но проставлять их нужно вручную перед каждым действием. Либо стоит самим написать механизм, подобный каспрессовскому.
Главное не оставлять в коде вейты на конкретное количество секунд, так как это сильно увеличит время прохождения тестов. И взять за правило — прежде, чем что-то сделать с элементом, — убедитесь, что он есть на экране.
3. Настроить стабильную инфраструктуру
Если инфраструктура, на которой гоняются тесты, постоянно подводит, то стоит решать эту проблему как можно быстрее. Зависающие и тормозящие эмуляторы, падающие тестовые стенды — в такой атмосфере ваши прогоны тестов вряд ли будут зелеными, да и всем довольно быстро надоест разбирать причины их падений. Поэтому нужно обязательно выделить время и ресурсы команды на стабилизацию инфраструктуры. Если все оптимизировано по-максимуму, но все равно остаются проблемы, возможно вам стало не хватать существующего железа и пора лезть в бюджет за новым
Вопрос 5. Что делать, когда тестов стало очень много?
В самом начале вы писали коротенькие простые автотесты — открой в приложении такой-то экран и проверь, что он отобразился. Затем вы начинаете автоматизировать более сложные сценарии, более сложные проверки. Количество тестов растет. Время прогона увеличивается. А когда что-то ломается, вместо одного теста у вас падает целых десять, и все с одинаковой ошибкой.
При этом время упавшей сборки увеличилось в несколько раз, так как упавшие тесты еще и ретраились.
В такой ситуации важно не держаться за свои старые, пусть даже стабильные, тесты и уметь их отпускать. Удаляйте их, если такие же проверки появились в новом. Железо не резиновое, а тратить х2 времени на запуск приложения для каждого нового теста контрпродуктивно и не экономично.
Чтобы не закапываться в будущие объемные рефакторинги, может помочь правило — актуализируй старое прежде, чем писать новое. Если вы сразу начинаете этому правилу следовать, то такой проблемы у вас возникнуть не должно.
Вместо заключения:
Эта статья — заключительная из серии ответов на вопросы про автоматизацию. Но мы продолжим рассказывать про тестирование и автоматизацию в hh.ru, о том, как проходят наши релизы и еще много о чем полезном и интересном.
А чтобы не пропустить новые видео, статьи и прочие новости, подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube. Также вы можете задать вопросы нашим инженерам по любым темам в комментариях, в телеграм-чате с разработчиками hh или в личку.
Источник: www.software-testing.ru