Пирамида Автоматизации Тестирования: Версия 2021 года

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

Вот несколько причин, почему:

• Модульные тесты создаются быстро, особенно для команды, занимающейся разработкой через TDD.
• Тесты более низкого уровня (модульные, функциональные, компонентные) выполняются намного быстрее, чем e2e тесты, особенно UI тесты.
• UI и e2e тесты, которые полагаются на внешние системы, могут завершиться с ошибкой из-за проблем со средой.

Существуют десятки различных версий пирамиды автоматизации тестирования, и хотя все они концептуально одинаковы, терминология может отличаться (компонентный vs функциональный; сквозной vs системный), а также существуют тестовые фреймворки и инструменты, появившиеся в последние пару лет, которые ввели новые "типы" тестов. Ниже приведена пирамида автоматизации тестирования, которую реализовала моя команда.

Объяснение нашей пирамиды:

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

Не существует “правильного” или “магического” количества тестов для любого уровня пирамиды. Он будет отличаться для каждой команды и каждого приложения. Важно то, что вы следуете подходу построения прочной основы тестирования с помощью модульных тестов, функциональных тестов — по сути, тестов, которые ближе к коду приложения и не зависят от каких-либо других систем для их запуска.

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

Контрактные тесты позволяют вам смоделировать состояния поставщика и потребителя для взаимодействия с вашим приложением, не полагаясь на то, что этот поставщик или потребитель будут доступны и находятся в хорошем состоянии для тестирования вашего приложения. Он удаляет зависимости тестовой среды, позволяя как провайдерским, так и потребительским приложениям запускать тесты в соответствии с контрактом. Контракт согласовывается обеими сторонами, и если одно приложение вносит изменение, которое нарушает контракт, то тест падает.

Тестирование контрактов требует тесной координации и сотрудничества между командами. Но в больших разрозненных организациях вы можете столкнуться с серьезными препятствиями при их успешной реализации.

Я бы порекомендовал заглянуть на https://docs.pact.io, чтобы получить более подробное объяснение тестирования контрактов.

Визуальные тесты пользовательского интерфейса с использованием таких инструментов искусственного интеллекта, как Percy и Applitools, используют сравнение снимков экрана для обнаружения визуальных различий в пользовательском интерфейсе приложения. Эти инструменты используются вместе с фреймворками автоматизации, такими как Cypress, WebDriverIO, Selenium и большинством других популярных фреймворков. Они легко интегрируются в существующие системы автоматизации и устраняют необходимость в обслуживании, которое сопровождает традиционная автоматизация тестирования. Вы сэкономите время, избавившись от необходимости обновлять селекторы CSS, изменять ассерты и добавлять/удалять шаги тестирования при изменении функциональности приложения.

Но такие инструменты, как Percy и Applitools, стоят дорого; визуальное тестирование пользовательского интерфейса довольно ново, и пока существует не так много вариантов с открытым исходным кодом.

Что это за облака наверху?

Я считаю важным включить ручное и исследовательское тестирование в пирамиду, даже если она предназначена для автоматического тестирования. Автоматизация может быть творчески реализована за пределами нашей структуры, чтобы помочь в ручном тестировании, и, несмотря на успехи в автоматизации тестирования за последнее десятилетие, до сих пор нет надежной замены человеческому глазу и человеческому мозгу. Команды могут чрезмерно автоматизировать и думать, что им вообще не нужно ручное тестирование, но это не так! Компьютер будет повторять только то, что мы ему говорим; используйте ручное тестирование и эффективное исследовательское тестирование, чтобы дополнить вашу автоматизацию.

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.