Е2е тестирование что это
End-to-end или E2E-процесс: что это? Сквозное тестирование
и другие поведенческие факторы.
К примеру, компания Гугл при разработке своих продуктов следует правилу «70-20-10», цифры которого показывают процентное соотношение от общего количества тестов, то есть:
70% занимают юнит-тесты;
20% занимают интеграционные тесты;
Нет единого алгоритма сквозного тестирования, так как многое будет зависеть от сложности самого проекта и что конкретно нужно тестировать. Е2Е — это лишь название процесса тестирования, а не его метод или алгоритм. Но при этом выделяют два основных типа сквозного тестирования, на которых мы немного остановимся.
Любой сквозной тест — это:
в первую очередь тестирование UI;
тяжелый и медленный тест;
применение метода «черного ящика» и найм сторонних тестировщиков, никак не связанных с разработкой программы;
тяжелый «отлов» найденной проблемы;
тестирование всех модулей и всех систем целиком, поэтому требуется сложный и эффективный софт или работа «руками»;
Заключение
нагрузку на каждый трос или балку;
поведение моста при наводнении, землетрясении, пожаре или аварии на нем;
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Про пользу E2E тестирования
В пирамиде тестирования End-to-End (E2E) тесты занимают одну из верхних ступеней. Написав один E2E тест, можно быть уверенным в результатах работы логики приложения, проверить интеграции с другими системами и создать «контракт» для вашего приложения.
К сожалению, многие из коллег, с которыми я работал, не писали E2E тесты. Отчасти потому что с головой ушли в модульное тестирование и посчитали, что оно лучше по ряду причин, включая моду на TDD. Отчасти потому что верили, что E2E тесты сложно писать, они долго исполняются, да и с инструментарием есть проблемы.
Разберемся с этими мнениями и посмотрим на плюсы, которые предлагает E2E тестирование.
Терминология
Под E2E тестами положим вид автотестов. Эти автотесты должны покрывать все функции сервиса с точки зрения клиента. Добиваются они этого, симулируя реальное взаимодействие клиента, будь это HTTP-запрос или нажатие на кнопку в UI.
Подход модульного тестирования лучше
Написание модульных тестов, по моему опыту, занимает куда больше времени, чем E2E тестов. Да, на первых порах придется разобраться как E2E тесты лучше писать, но ведь то же было верно и для модульных тестов.
Зато, в результате один E2E тест покрывает больше кода, чем один Unit-тест, хотя может занимать меньшее количество строк по сравнению с аналогичным модульным test suite.
Можно не тратить время на понимание того, как правильно мокировать зависимости, ведь ими становятся в E2E тестах внешние системы, а взаимодействие с тестируемым сервисом строится по принципу «черного ящика».
Не нужно проверять все граничные условия для отдельного метода класса. Это повышает гибкость работы с кодом, так как нет необходимости рефакторить весь test suite при малейшем изменении внутренней логики работы приложения.
Невозможно попасть в ситуацию, когда ты боишься выкинуть старый код, потому что придется пройтись по набору из 100 модульных тестов (написанных даже не тобой), которые так или иначе были завязаны на этот код.
Инструментарий и скорость прогона тестов
На сегодняшний день большинство backend-разработчиков пишут сервисы, представляющие API с помощью HTTP (возможно GraphQL) или некоторым подобием MQ. В таком случае достаточно обычного клиента HTTP, доступного в большинстве mainstream ЯП.
Frontend-разработчики пишут, в основном, для Web-платформ (браузеров) или для мобильных в виде нативных приложений. Тут ситуация немного сложнее, так как инструментарий требует более детального изучения, но не дольше любого остального инструмента, с которым Вам придется столкнуться при разработке приложений.
E2E тесты действительно требуют в среднем больше времени для прогона, нежели модульные. При этом они завязаны на скорость работы Вашей системы. Т.е. они становятся метрикой производительности отдельных операций. При необходимости, они могут просто преобразовываться в нагрузочные тесты.
Дополнительные плюсы E2E тестирования
Каждый отдельный тест покрывает реальный сценарий использования приложения и дает куда больше понимания другим разработчикам, в том числе и будущим, как именно и зачем все это работает.
По результатам работы Вы получаете «настоящий» code-coverage. Если есть код и его невозможно исполнить, выполняя клиентские запросы в реальном окружении, то, скорее всего, это лишний код. Если он проверяет граничные условия или ловит маловероятный exception, задумайтесь, возможны ли такие условия в принципе?
В целом, использование только E2E тестирования для приложения заставляет задуматься об упрощении структуры Вашей системы и улучшения документации.
E2E тесты могут использоваться как контракты API и взаимодействия с Вашим сервисом. К примеру, для backend, как только Ваш E2E тест меняется, необходимо убедиться, что frontend будет готов к таким изменениям.
Заключение
В целом, на мой взгляд, E2E тестирование предоставляет большие гарантии корректной работы системы, чем unit-тесты, большую гибкость в работе с кодом с точки зрения рефакторинга и отражает реальную суть работы приложения.
Спасибо Вам за внимание! А как Вы считаете, можно ли использовать только E2E тесты?
Сквозное тестирование (end-to-end): что, зачем, почему
Тестирование в больших компаниях, в enterprise, чаще всего дело сложное и неблагодарное. Разрыв между бизнес-подразделениями и IT огромный: когда разработчик имеет видение на уровне кода, а проверку – на уровне модульных тестов, а заказчик мыслит работающими или неработающими даже не услугами, а целыми процессами, выходящими за рамки одной команды разработки, а то и целого подразделения\компании. И просит организовать бизнес-тестирование, или сквозное тестирование, или тестирование на основании сценариев от начала и до конца (end 2 end).
Давайте начнём с самого начала – с двух столпов, откуда появилось это пресловутое «сквозное бизнес-тестирование», а именно с пирамиды тестирования и со стандарта ISO9000.
Пирамида тестирования
С пирамидой тестирования, наверняка знаком любой тестировщик, поднаторевший в своей профессии и набившей шишек при общении со смежными подразделениями. Особенно часто к ней приходится апеллировать при обосновании автоматизации тестирования. Какие тесты дешевле и важнее разработать? А запустить?
Суть пирамиды тестирования не хитрая: в основе тестирования следует использовать самые простые и самые быстрые в написании и исполнении тесты – модульные тесты. Конечно, проверка интерфейсов классов и функций вряд ли та вещь, которую можно показать заказчику, но без этого прочного, монолитного, безотказного фундамента вряд ли что-то получится выстроить выше. Как правило несколько десятков функций, методов, классов реализуют какую-либо функциональность для заказчика, и по сути десяток модульных тестов можно свести к каким-то верхнеуровневым тестам. Заказчику нужна уже красивая квартира с отделкой, но при этом вряд ли он останется довольным, когда перекошенные окна в его квартире перестанут открываться, а пол и потолок пойдёт трещинами от первого подувшего ветерка. Однако самому заказчику зайти в квартиру и проверить её качество может быть не самой лучшей идеей. Согласитесь, сложно пользователю проверить качество бетона в фундаменте, так и воспроизвести все погодные условия. Так и в тестировании, конечно, верхнеуровневое тестирование нужно, то только тогда, когда у нас отработали модульные тесты, так и тесты уже более высокого уровня.
Сложнее в разработке и дольше в исполнении более высокоуровневые тесты – интеграционные тесты, которые проверяют корректность работы одновременно работающих модулей, над которыми трудилась вся команда, выпуская свой продукт (систему). То есть проверяется интеграция кода, тестируется система без учёта взаимодействия со внешними системами. Такие тесты уже подразумевают проверку высокоуровневую, скорее всего через обращение к систему через системное API или даже GUI (фронт). Работа с таким типом тестов сложнее – чтобы покрыть все ветки и нюансы кода нужно, скорее всего, задействовать большое количество сильно пересекающихся проверок на различных тестовых данных, а при автоматизации зачастую разрабатывать целый ворох условий и ветвлений в скриптах. То есть, с одной стороны мы уже приблизились к пользователю, усложнив себе жизнь, но с другой стороны, нам ещё сложно находить общий язык, нам это обходится дороже, а качества проверок всё ещё недостаточно. То есть мы можем запустить заказчика в новую квартиру, он может всё проверить, но без учёта взаимодействия с другими жильцами, погодными условиями и коммунальными службами. Согласитесь, толка от идеального мира, модели, в реальной жизни, как правило, немного.
Если мы добавим и эти условия – посмотрим как наша система взаимодействует со внешними системами – поставщиками и потребителями, с нашим окружением, то есть проведём системное тестирование, то легко увидим, что сложность тестирования тоже возрастёт. Нам нужно будет добиваться одновременной работоспособности всех взаимодействующих систем, хотя и без привлечения специалистов по ним. Нам пока что достаточно просто принять какие-то данные от наших поставщиков и передать наши данные нашим потребителям. В правильной последовательности и формате. Дальнейшая судьба данных нас не волнует. Главное – наша система работает правильно в правильном окружении. И всё бы тут хорошо – для нашего заказчика мы можем провести уже полномасштабную демонстрацию, да только в реальной жизни это ещё не все критерии успеха для нашей разработки. Конечно хорошо, что у заказчика появилась его квартира в прочном доме, но если от неё надо добираться, перелезая через колючую проволоку, затем на каноэ по озеру с крокодилами в шалаши, кишащие змеями, то, возможно, мы что-то не то и не там сделали?
Поэтому тут первая идея для сквозного тестирования – проверять не только наше окружение, но и все взаимосвязанные системы, через которые проходят данные принимаемые или отправляемые нашей системой. А это, в свою очередь, означает, что мы должны будем совместить несколько таких «пирамид тестирования» между собой. Постройка хрупкого моста, по которому мы проведём за ручку данные, ценные для пользователя.
Вот только вопрос как это делать? Кому это делать? Как собирать воедино?
ISO9000
Серия стандартов, описывающих системы менеджмента качества, в том числе говорит о том, что любой процесс в организации должен быть описан, задокументирован, даже если это процесс выдачи граблей по осени дворнику. А раз так, что ни один процесс, который проходит внутри ПО, используемого и разрабатываемого в организации, не может не быть описан. Вопрос в том, как это делать? Конечно, лучшее описание, с точки зрения BDD — это описание поведения тестами, под которыми будет лежать пирамида тестирования. Но мы сразу же вернёмся к нашей дилемме с объединением нескольких пирамид тонкими канатами от верхушки к верхушке, по которым без страховки будет ходить наш канатоходец-заказчик и его пользователи.
Process approach is a management strategy that requires organisations to manage its processes and the interactions between them. Thus you need to consider each major process of the company and their supporting processes.
All processes have:
• inputs;
• outputs;
• operational control;
• appropriate measurement & monitoring.
Each process will have support processes that underpin and enable the process to become realised
Для этой цели лучше всего подходят бизнес-диаграммы, и чаще всего используются стандарты вроде UML, BPMN, ARIS и пр. А сами процессы становятся блок-схемами с нанизанными на них «кубиками». Между «кубиками» происходит взаимодействие, в стандарте BPMN — это поток действий и поток сообщений. И вот это как раз то, что нам нужно!
Любая компания, которая хочет иметь сертификат и следует стандарту ISO9000, скорее всего, обзавелась такими схемами, и они являются неотъемлемой частью верхнеуровневых требований. Если в компании работают хорошие аналитики, то, скорее всего, к низкоуровневым требованиям будут спускаться ссылки-требования на отдельные действия из схем. Они-то нам и нужны.
Фактически, на схемах мы можем увидеть процесс целиком, и понять, какой сценарий нам нужно построить, и к какой системе\команде бежать с какими данными в какой момент.
Я тут не преуменьшаю труд разработчиков, которые пишут грамотный код, который пересылает сообщения между разными частями программно-аппаратных комплексов, но всё держать в уме невозможно. И когда процесс используется во множестве других процессов, лучше иметь такую «карту» при себе для проведения грамотного тестирования, и, тем более для построения тестовой модели.
Что на практике
Итак, мы имеем две вводных – у каждой команды\системы должна быть подготовлена пирамида из тестов – от самых мелких, модульных тестов, до сложных системных тестов, а так же тот факт, что в рамках организации у нас обязаны быть описаны требования в виде бизнес-процессов. Этот факт нам позволит быстро ответить заказчику, какой бизнес-процесс как работает, и на каком моменте из-за чего ломается, а самим, при получения дефектов с промышленной эксплуатации быстро произвести root cause analysis (анализ корневых причин возникновения дефектов). В теории.
А на практике всё опять ложится на тестировщика – как из вороха тестов, тем более чужих, выбрать нужные, выстроить их в цепочку, а на вход каждой из систем подать нужные данные и сверить с корректно определённым ожидаемым результатом?
Самый простой вариант – изначально разрабатывать тесты на основании бизнес-моделей, а деление команд делать по проектам, реализующим тот или иной бизнес-процесс. Для этого в некоторых инструментах управления тестированием есть уже возможность загружать BPMN-схемы (например для HPE ALM – поддерживается загрузка в формате XPDL). HP ALM сам разобьет схему на набор требований (действий), а при желании создаст иерархию требований (модуль Requirements->Business Models). Далее наше дело покрыть требования тестами, а далее выстроить требования, а значит и тесты в цепочки, покрывающие наш бизнес-процесс. Эти цепочки в HPE ALM называются «путями» (path), и позволяют увидеть все комбинации последовательностей. При желании требования, цепочки можно сразу сконвертировать в тесты.
Но даже если не использовать инструменты тестирования, всё равно придётся из бизнес-процесса составлять цепочки. Тем более учитывая несовершенство инструментов (не всё так радужно), а так же тот факт, что, скорее всего, тестовую модель нужно будет собирать пост-фактум, а исполнять и вовсе в виде регресса «общей командой», не прилепленной к новым проектам.
Сколькими путями может дойти белочка до шишки?
В этом случае нам нужно будет открыть тесты каждой из команд, найти привязанные к фигурирующим в бизнес-модели требованиям, и выстроить из них цепочки, сохранив в «общем пространстве». Создание общего пространства – это какой-то суррогат, но в любом случае оно должно быть, пусть в виде амбарной книги, excel, или проектной области в инструменте управления тестированием. Если снова говорить о HPE ALM, то за данный функционал отвечает модуль BPT (Business Process Testing), заодно позволяющий передавать результаты одного теста в параметры другого. Впрочем, при желании и упорном труде на HPE ALM это возможно и реализовать через перестроения тестовых наборов (Test set) в поток выполнения (Execution flow). Тогда при запуске полного набора будут по очереди вызываться тестировщики, ответственные за прохождения каждой из компонент сквозного сценария.
И, увы, одним лишь средством управления тестирования не обойтись. Из моей практики, почти что все инструменты имеют какие-то фатальные недостатки, и поэтому, если вы дойдёте до этапа автоматизации тестирования по бизнес-процессу – то придёте к созданию скрипта, который будет дёргать в нужной последовательности тесты.
В итоге, можно сделать два вывода:
1) для сквозных сценариев используются с большой долей вероятности уже ранее разработанные тесты для каждой из систем, входящей в цепочку (сценарий) бизнес-процесса
Можно все полные тестовые наборы компании представить в виде разреженной матрицы, где по столбцам распределены тесты для каждой системы (для простоты – системные), а по строкам – бизнес-процессы. То есть для тех или иных бизнес-процессов надо выбрать\создать тесты, покрывающие бизнес-процесс, установить взаимосвязи. Если покрытия нет – это повод восполнить пробелы в тестовой модели, либо удостовериться, что качество обеспечивается другими уровнями тестирования (интеграционное тестирование, модульное тестирование, ревью кода и прогон его через анализаторы).
2) Необходим инструмент наблюдения, трассирования и актуализации бизнес-процесса на предмет синхронизации с тестовой моделью.
И если с созданием тестовой модели инструменты тестирования более-менее сносно справляются, то с актуализацией всё в действительности очень плохо, зачастую проще модель пересоздать заново, чем пытаться увидеть изменения в процессе и тестовой модели. И опыт реальных команд говорит о том, что лучше создавать живую визуализацию архитектуры. Проще всего это сделать в общей зоне, воспользовавшись простой маркерной доской и стикерами. Тогда, команды, которые участвуют в бизнес-процессе могут наглядно видеть, как видоизменяется процесс (убираются и добавляются связи, убираются и добавляются действия). Главное – чтобы все имели доступ к доске. Плюс, обратите внимание, что если в процессе подразумевается сообщений между системами, то, как правило, хотя бы должно быть два теста от каждой системы – на отправку и на приём данных. Впрочем, вместо стикеров можно использовать целый лего-город (из крупных блоков), или что-то ещё более креативное. Главное тут – один язык и одно информационное пространство, чего очень в enterprise не хватает.
В заключение
Организация наглядного и правильного тестирования по бизнес-процессам – сложная и очень дорогая вещь. Обратите внимание, что E2E тестирование – это не просто приёмка, пользовательское тестирование, которое будет выполнять заказчик, это выстраивание мостика, с учётом всех возможных ситуаций, по которому пойдёт заказчик и поведёт за собой в ногу пользователей.
Ещё раз – E2E – это не прогулка на Ладе-Калине через мост, и даже не проезд на двух камазах. Это сложная инженерная работа, обвешивание мостов датчиками и проведение всех возможных проверок и ситуаций — по крайней мере описание этих сценариев.
Нужно или нет вашей компании такой идеальный чистовой прогон – дело исключительно ваших целей и потребностей. Всегда, как и при любом тестировании, следует оценить потенциальные риски от пропущенных дефектах на этой стадии, так и стоимость работ по подготовке и проведения сквозного тестирования. Оценить, что из этого обойдётся вам дороже и только потом действовать. Но в случае сквозного тестирования по бизнес-процессам следует помнить, что оно не имеет смысла без прочного фундамента в виде 100% passrate unit-тестов (
90-100% coverage), без интеграционных тестов (
60-80% coverage, 90-100% passrate), без системных тестов (20-40% coverage, 80-100% passrate). Устанавливать критерии успешности (quality gates) – это больше требования к качеству выпускаемого продукта, главное здесь помнить, что объем E2E тестов – лишь верхушка пирамиды (1-2% coverage,
99% passrate), которая не должна быть больше его основания, не быть при этом затычкой дыр с предыдущих этапов. Это – дополнение, которое априори считается закрытым на предыдущих этапах.
Организация подобного тестирования – главным образом работа по подготовке и синхронизации тестовых случаев и данных (тест-аналитика), а так же комплекс организационных мероприятий, синхронизация команд в одном месте в одно время на работоспособном тестовом полигоне. Помня это, не следует пробовать показывать заказчику «сквозное тестирование» раньше срока, чтобы не тратить время сразу большого количества людей без всех работающих компонентов, собранных воедино.
Цена регресса. Как мы организовали инфраструктуру для Е2Е-тестов
Мы, команда автоматизации Страхового Дома ВСК, подготовили небольшой рассказ о нашей инфраструктуре. Эта статья может быть входной точкой для специалистов, желающих внедрить автотестирование у себя в компании. Расскажем, какие системы, паттерны и фреймворки можно использовать, а также как интегрировать это в релизный цикл. Материал подойдёт как юным автоматизаторам, так и тем, кто желает поближе познакомиться с темой. Большое внимание уделим не только абстрактным вопросам, но и организации кода проекта. Добро пожаловать под кат.
Изложение поделено на две логические части. В первой опишем инфраструктуру и процесс, а во второй рассмотрим некоторые детали написания кода. Но для начала немного обрисуем рабочую среду:
задачи ведём в Jira;
тест-кейсы и тест-планы готовим в TestRail;
очередь запускаемых тестов определяется Sprut;
за деплой отвечает Azure DevOps;
за виртуалки в докере — Selenoid;
Кому и зачем нужна команда автоматизаторов
Очевидно, что компании стремятся к уменьшению релизного цикла разрабатываемого ПО. Для достижения этой цели команды разработчиков прибегают к различным гибким методологиям. Однако всё равно отделу контроля качества приходится раз за разом выполнять регрессионное тестирование, занимающее от нескольких дней до нескольких недель. Именно поэтому существуют такие команды, как наша, стремящиеся сократить время регресса за счёт автоматизации.
Т. к. команда ручного тестирования является нашим заказчиком, мы постарались максимально прозрачно интегрироваться в их процесс.
Страховой Дом ВСК использует TestRail как систему управления тестированием. Выполнение регрессионного тестирования сводится к следующим простым этапам:
Создание тестового плана, где выбирается необходимый список тестов. Сюда попадают как обычные, так и автоматизированные кейсы.
Запуск тестов. После создания плана наша система (о ней чуть позже) распознаёт автоматизированные кейсы, ставит их в очередь и результат прогона возвращает обратно в TestRail.
Получение результатов. После завершения всех тестов тестлид видит общий отчёт по состоянию ручного и автоматического тестирования.
Анализ результатов. В том случае, если автотест упал по неизвестной причине, пользователь может посмотреть результат и при необходимости пройти кейс вручную, либо дождаться исправления.
Инфраструктура и автотестовый дашборд
Как уже упоминалось, процессом запуска автотестов руководит отдельная система. Многие компании предпочитают разрабатывать подобную инфраструктуру самостоятельно, чтобы лучше контролировать процесс. Мы не исключение, поэтому знакомьтесь со Sprut.
В первую очередь на Sprut возложена работа с очередью запускаемых тестов, мониторингом и управлением процессами. (За деплой отвечает Azure DevOps, а за виртуалки в докере — Selenoid. В будущем планируем внедрить автодеплой при запуске.) Также Sprut выполняет постобработку результатов прогонов: классификацию и кластеризацию. Из-за того, что тестам свойственно падать пачками, Sprut предоставляет прогон тестплана в сгруппированном по ошибкам виде. Автотестеру проще работать с такой системой, чем с TestRail.
Для каждого упавшего теста можно посмотреть логи, скриншоты и другие артефакты. Если тест упал из-за Assert, система относит инцидент к категории «Ошибка ПО» (т. е. не прошла целевая проверка). В силу природы самих Е2Е-тестов падения, которые случились не в секции Assert, попадают в отдельную категорию, где дежурный разработчик тестов уже проводит анализ, т. к. нельзя однозначно определить, это «Ошибка в автотесте» или «Ошибка ПО».
В ходе анализа Sprut позволяет сразу создать тикет в Jira и назначить ответственного. После исправления автотестов система позволяет выполнить перезапуск не прошедших ранее кейсов, а результат аккумулируется с предыдущим раном в тестовом плане. Так за несколько итераций мы можем разобрать все проблемы.
О сложности Е2Е-тестов
Проект автотестов — это такой же программный продукт, код которого нужно писать и поддерживать. И этот код следовало бы тоже тестировать, но тогда мы войдём в бесконечную рекурсию (тесты, которые тестируют тесты, которые тестируют. ). Е2Е-тесты по своей сути обеспечивают самый высокий уровень защиты от багов, но являются очень хрупкими и нестабильными. Поэтому мы подошли к архитектуре со всей ответственностью и разработали структуру, о которой дальше пойдёт речь.
Наш способ организации проекта позволяет бороться с усложнением системы, возникающим из-за увеличения числа автоматизированных тестов.
Для наглядности предлагаю разработать автотест для следующего упрощённого кейса:
Пользователь заходит на страницу поиска авто.
Вбивает несуществующий, но валидный номер паспорта ТС (транспортного средства).
Указывает регистрационный номер ТС.
Ожидаемый результат: появляется сообщение с предупреждением «Автомобиль не существует в базе».
Модель данных
В нашей системе модель содержит всю необходимую для выполнения теста информацию. Мы выделяем два основных типа моделей:
Являются композицией общих моделей и включают некоторую служебную информацию теста и специфичные данные для конкретного тестового метода (например, TestID).
Создадим для нашего примера общую модель:
Обратите внимание, что значение свойства по умолчанию генерируется случайным образом. Такой подход позволяет нам избегать коллизий и тестировать систему с широким диапазоном входных данных.
А регистрационный номер не является обязательным и, раз не задан, не станет подставляться в поле поиска по умолчанию. Модель менеджера будет включать в себя только одно свойство:
ModelBase содержит определение служебных полей: TestID, Login, Password. Но прежде чем мы перейдём к написанию теста — ещё пара слов о модели.
Для каждого тестового метода мы подготавливаем отдельный XML-файл, который будет десериализоваться в конкретный объект, переопределяя интересующие свойства. Так, для нашего теста создадим файл, где будет переопределённый ID теста:
В большинстве случаев нас будут устраивать значения свойств по умолчанию. Но если тесты похожи, мы можем переиспользовать тестовый метод путём вставки в XML дополнительных блоков. В XML мы указываем только специфичные для данного теста свойства. Этот трюк во многом облегчает поддержку: для изменения входных данных не требуется знаний языка программирования и можно безболезненно расширять модели CarFindData и CarData.
Например, в следующем примере, указав дополнительные наборы данных в той же XML, мы получили новые тесты, ничего не меняя в коде, и можем запускать их отдельно при необходимости.
Тестирование UI
Мы выделяем три основных типа объектов:
Тестовый класс. Содержит тестовые методы, схожие по шагам и тестовым параметрам.
Менеджер. Предоставляет набор законченных логических операций — шагов теста в конкретной области приложения или отдельных проверок результатов.
FormObject/PageObject/APIObject. Инкапсулируют сложность взаимодействия с интерфейсом, предоставляя атомарные действия над элементами страницы. Для APIObject это может быть поиск конкретных значений по тегам в ответе сервиса.
Теперь напишем код теста для нашего примера:
Мы разбиваем тестовый метод на два этапа. Этап подготовки данных читает XML-файл, который мы создали ранее, и возвращает список десериализованных моделей. Метод NotFoundWarningWhenNotFoundCarTest будет запущен для каждой модели из списка, что позволяет автоматизировать сразу несколько похожих тест-кейсов, используя один и тот же код.
Для описания последовательности шагов мы пользуемся Fluent-синтаксисом, что в совокупности с IntelliSense делает написание кода таким же лёгким, как и его чтение. Main.Manager является точкой входа для работы с любыми другими менеджерами. Код в нём может содержать действия корректной инициализации и будет специфичен для каждого отдельного приложения. Его мы рассматривать не будем и перейдём сразу к созданию менеджера страницы поиска автомобиля:
Менеджеры должны отделять действия от проверок, предоставляя для этого различные методы. Метод принимает модель данных и сам определяет, какие свойства ему нужны. Допускается, что менеджер может изменять модель для того, чтобы передать какую-либо информацию другой части теста.
Реализация CarFindPage зависит от конкретного типа приложения. В наших проектах мы используем два богатых фреймворка: Selenium (для работы с браузером) и FlaUI (для тестирования WinForm). Более подробно о них вы можете узнать в других статьях на Хабре.
Итак, мы рассмотрели в общем виде структуру наших проектов. Хороший автотест должен содержать простой, понятный и стабильный код. А каждый метод — писаться с мыслью о повторном использовании в будущем. Такая архитектура позволяет успешно масштабировать количество тестов за счёт переиспользования кода. Чтобы с ростом проекта код оставался таким же чистым, нужно не забывать о таких практиках, как:
обязательное code review,
единый code style и конвенция наименования типов.
Пишем логи правильно
Ещё одна важнейшая характеристика автотеста — его максимальная прозрачность и понятность. Т. к. с результатами прогона теста работают не только его создатели, требуется, чтобы ошибка была понятна и тестировщику, и разработчику без дополнительных пояснений. Это экономит гигантское количество времени для всей компании.
Добиваемся данной цели следующими способами:
отделяем целевые проверки от шагов,
автоматически делаем скриншот в момент падения теста,
логируем каждое действие теста.
Первые два пункта более-менее очевидны, а про третий мы бы хотели рассказать поподробнее. Вот так выглядит наш файл с логом:
Помимо этого лога формируется лог для Allure
Такой лог очень легко прочесть. Как можно заметить, в него попадают шаги вышеупомянутых менеджеров и действия с FormObject. Чтобы наглядно продемонстрировать, как в коде выглядит объявление этих шагов, модифицируем наш предыдущий пример:
Нам всего лишь пришлось добавить один атрибут и обычные комментарии к методам. Атрибут TraceAspect сообщает, что для данного класса нужно сгенерировать код, отвечающий за логирование шагов. Такой трюк возможен с помощью NuGet-пакета Aspect Injector. А сам текст шага будет взят из XML-документации, которую можно сгенерировать на этапе билда.
Аналогичным способом реализуются и другие часто повторяющиеся операции. Например, есть аспект для проверки передаваемых аргументов на null в методы страницы.
Для добавления этого функционала к любому PageObject необходимо прописать аннотацию [NotNullArgumentAspect] к этому классу.
Алгоритм работы следующий:
Если применено не к наследнику PageBase — будет вызвано исключение.
Если метод не публичный, или тип результата метода не совпадает с PageObject, в котором хранится метод, или если это вообще не метод, а LINQ-запрос — управление передаётся методу без дополнительных проверок.
Проверяются все аргументы, переданные в метод. Если хотя бы один из них равен null — записывается сообщение в лог и метод не выполняется (возвращается корректный PageObject). Если с аргументами всё хорошо — метод выполняется.
Подводим итоги
Суть автоматизации, как и разработки любого продукта, — сделать систему, позволяющую упростить и ускорить работу пользователей. Мы считаем, что успешно справились с данной задачей, т. к. построили инструмент, которому тестировщики доверяют и который активно используют. На этом наша работа ещё не закончена: в ближайших планах есть много интересных задач по улучшению. Например, чтобы в момент запуска теста в Docker-контейнере автоматически стартовало динамическое развёртывание и тестовый проект сразу подстраивался под среду, указанную в параметрах запуска.
Мы постарались показать вертикальный срез нашей инфраструктуры тестирования. Невозможно в рамках одной статьи рассказать обо всех нюансах. Мы готовы ответить на ваши вопросы в комментариях и будем рады, если вы расскажете о своих техниках: как справляетесь с теми или иными проблемами.