Пирамида автоматизации тестирования
Тестирование может быть ручным или автоматизированным. В этой статье мы обсудим пирамиду автоматизации тестирования — идею, с которой часто знакомят новичков.
Пирамида тестирования
Это концепция, согласно которой автоматизированные тесты делятся на три уровня в зависимости от охвата тестируемой системы.
Концепцию ввёл Mike Cohn в 2009 году в статье The Forgotten Layer of the Test Automation Pyramid. Он выделил три уровня тестов:
На каждом из уровней тесты пишутся по-разному — отличаются технические средства, подходы к написанию тестовых сценариев и шаблоны проектирования.
Предпосылки
Автоматизированные тесты могут разрабатываться:
- Программистом — Software Engineer
- Специалистом по контролю качества — QA Engineer, где QA — сокращение от Quality Assurance
Цель написания тестов — уверенность в том, что программа пригодна для решения поставленных задач и достигает нужного уровня качества.
Тестирование не доказывает корректность
Тесты не могут доказать отсутствие дефектов в программа, поскольку:
- Никакой набор тестов не сможет проверить все возможные пути выполнения кода.
- Ничем не доказывается корректность самих тестов
Таким образом, запуск тестов имеет два возможных исхода:
- Некоторые тесты провалены → программа и/или тесты содержат дефекты
- Все тесты пройдены → программа и/или тесты всё ещё могут содержать дефекты.
Несмотря на неспособность доказать отсутствие дефектов, тестирование имеет смысл — хорошие тесты дают уверенность, что программа способна решать поставленные задачи.
Тестовые сценарии
Автотесты проверяют набор тестовых сценариев (англ. test case), часто называемых просто тест-кейсами.
- Правильно написанный test case даёт уверенность, что проверяемый им сценарий работает
- Неправильно написанный test case может создать ложную уверенность — он не выявляет возможных проблем или вовсе доказывает наличие дефекта вместо его отсутствия
Написание тестовых сценариев перед написанием кода кратно снижает вероятность появления неправильного теста. Такой подход применяется в TDD, где используется цикл Red-Green-Refactor.
Рост цены исправления ошибки
В книге «Совершенный код» Стив МакКоннел приводит данные о стоимости исправления дефектов в зависимости от того, на каком из этапов дефект был внесён в программу и на каком этапе был обнаружен.
Ниже показана матрица, в которой:
- по вертикали указаны этапы, на которых внесён дефект
- по горизонтали указаны этапы, на которых дефект исправлен.
- на пересечениях указана относительная стоимость исправления дефекта
| Анализ | Проектирование | Разработка | Тестирование | После выпуска | |
|---|---|---|---|---|---|
| Анализ | 1 | 3 | 5—10 | 10 | 10—100 |
| Проектирование | — | 1 | 10 | 15 | 25—100 |
| Разработка | — | — | 1 | 10 | 10—25 |
Таким образом, разработка через тестирование кратно снижает стоимость исправления дефектов программы.
Уровень 1: модульные тесты
Модульные тесты (англ. unit tests) состоят из быстрых тестовых сценариев, запускающих отдельные модули программы в полной изоляции от внешнего мира и других сценариев.
Что такое модуль? Это единица кода, предоставляющая некую функциональность. Размер модуля может быть произвольным — начиная от функции/файла/класса.
Обычно модульные тесты запускают модули небольшого или среднего размера. Ниже показаны примеры того, что считают небольшими и средними модулями в разных языках программирования:
| Язык | Небольшой модуль | Средний модуль |
|---|---|---|
| C, C++ | Пара файлов u.h / .cpp | Библиотека (статическая или динамическая) |
| C# | Класс или файл .cs | Сборка (Assembly) |
| Go | Файл | Пакет (package) |
| JavaScript | Файл .js | Каталог с кодом |
| Python | Файл .py | Пакет python (каталог с кодом) |
| PHP | Файл | Каталог с кодом |
Все перечисленные модули могут быть объектом тестирования для модульных тестов.
Уровень 2: интеграционные тесты
Интеграционные тесты (англ. integration tests) проверяют компонент, состоящий из интегрированных друг с другом модулей и связанный с внешним миром. Поэтому их также называют компонентными (англ. component tests). Разные источники используют разные термины, однако по сути компонентные и интеграционные тесты — одно и то же.
Компонентом в этом случае называют крупномасштабный модуль программной системы, например:
- Распространяемый пакет (NuGet, NPM, PIP)
- Библиотеку, у которой есть самостоятельный API
- Микросервис или сервис в составе более крупной системы
Интеграционный (компонентный) тест проверяет компонент в изоляции от остальных компонентов, но в сочетании с некоторыми зависимостями — прежде всего с СУБД и файловой системой.
Уровень 3: сквозные тесты
Сквозные тесты (англ. end-to-end tests, или E2E tests) состоят из тестовых сценариев, каждый из которых проверяет полный сценарий использования приложения в реалистичном окружении.
- Часто сквозные тесты пишут тестировщики (QA-инженеры) и запускают на тестовых стендах (в окружении QA).
- Сквозной тест должен проверять продукт целиком, со всеми смежными компонентами, включая СУБД, взаимосвязанные сервисы и сторонние API
- Следует стремиться к тому, чтобы окружение для запуска сквозных тестов было максимально похожим на Production окружение — конечно, отклонения от этого правила могут снизить стоимость сквозных тестов, но также они снижают полезность
Для Web-приложений сквозные тесты обычно выполняются в фоновом браузере (англ. headless browser). Для этого используются специальные фреймворки, самый известный — Selenium.