Пирамида тестирования — модель распределения автоматизированных проверок по ширине охвата. В её основании обычно находятся многочисленные узкие проверки, выше — проверки взаимодействия компонентов, а на вершине — небольшой набор сквозных сценариев. Смысл модели в быстрой и понятной обратной связи.
Пирамида не задаёт обязательные проценты для любой команды. Мобильный клиент, расчётная библиотека и интеграционный шлюз имеют разные риски. Для QA полезнее понимать стоимость обнаружения и локализации дефекта, чем пытаться получить красивую диаграмму из количества тестов.
Что означает ширина проверки
Узкая проверка контролирует небольшую часть поведения и ограниченное число зависимостей. Например, функция расчёта комиссии получает сумму и тип клиента, а возвращает число. Широкая проверка проходит через несколько слоёв: интерфейс, HTTP, бизнес-сервис и хранилище.
Термины в командах различаются. Где-то service test поднимает настоящий сервер с базой, где-то вызывает обработчик с заглушенными зависимостями. Поэтому рядом с названием уровня фиксируют, какие компоненты реальны и какие заменены. Без этого сравнение наборов между проектами вводит в заблуждение.
Почему основание обычно широкое
Узкие тесты позволяют подробно перебирать граничные значения и правила без запуска полного окружения. При отказе легче понять, какая обязанность нарушена. Они особенно полезны для расчётов, переходов состояний, преобразований данных и сложной валидации.
Но большое количество unit-тестов не гарантирует правильную сборку системы. Можно идеально проверить каждый преобразователь отдельно и ошибиться в настройке сериализации между сервисами. Основание работает, когда проверки связаны с важным поведением, а не только повторяют устройство методов.
Зачем нужен средний слой
Интеграционные и сервисные проверки подтверждают взаимодействие: формат HTTP-ответа, запись в хранилище, транзакцию, обработку ошибки зависимости. Они ловят проблемы, которые не проявятся при полностью подставленных ответах.
Средний слой часто даёт наиболее полезный компромисс для бизнес-приложения. Через API удобно проверять роли, ограничения заказа и негативные данные, не открывая браузер. Однако если сервисные тесты заменяют все реальные зависимости, нужно отдельно проверить контракты и критические соединения с ними.
Что оставить на вершине
Сквозные проверки подтверждают, что пользовательская цепочка собрана и доступна через настоящий вход в продукт. Например, человек может выбрать товар, оформить заказ и увидеть его в истории. Такой тест обнаруживает ошибочную маршрутизацию, сломанную авторизацию или неподключённую кнопку.
Вершина становится дорогой, когда через неё перебирают всю матрицу бизнес-правил. Каждый дополнительный слой добавляет возможные причины отказа. При этом удалять все E2E ради скорости тоже опасно: отдельные компоненты могут работать, а пользователь не сможет завершить действие.
Практическое разложение возврата товара
Предположим, товар можно вернуть в течение четырнадцати календарных дней после получения, если он не относится к исключениям. Правила времени и исключений сначала согласуют с владельцем продукта. Для упражнения используют тестовые заказы и управляемую дату, а не ждут реального наступления срока.
На узком уровне проверяют день получения, последний допустимый день, следующий день и исключённую категорию. На сервисном уровне отправляют возврат от владельца и другого пользователя, проверяют статус заявки и отсутствие повторной записи. На сквозном уровне оставляют один разрешённый возврат и видимость результата в личном кабинете.
Ожидаемый эффект — подробная проверка правил без десятков длинных UI-цепочек. Чтобы убедиться в качестве распределения, временно изменяют правило в учебной ветке: узкий тест должен упасть по конкретной границе, а сквозной сохранить роль проверки соединения слоёв.
Где появляется перевёрнутая пирамида
Если почти все проверки запускают браузер, команда часто ждёт долго и получает много связанных падений. Один недоступный сервис способен окрасить сотню сценариев. Диагностика становится повторяющейся работой, и люди начинают игнорировать красный статус.
Причина может быть организационной: QA имеет доступ только к UI, а разработчики не участвуют в автоматизации. Исправление требует совместной работы над тестируемостью. Простое требование «напишите больше unit-тестов» не поможет, если бизнес-логика спрятана в монолитном обработчике без управляемых зависимостей.
Когда форма набора отличается
У приложения с тонким клиентом и важными интеграциями значительная часть проверок может находиться на сервисном уровне. У библиотеки почти весь полезный набор может состоять из узких тестов. Сложный визуальный редактор требует дополнительных компонентных и визуальных проверок.
Это допустимо, если команда понимает, какие риски покрывает и где остаются пробелы. Модель используют как повод спросить, нельзя ли получить тот же сигнал дешевле, а не как норматив количества. Приоритетом остаётся обнаружение существенных ошибок.
Как улучшать существующий набор
Возьмите несколько самых медленных и шумных сценариев. Для каждого выпишите проверяемое правило, реальные зависимости, длительность и причины последних отказов. Затем перенесите детальную матрицу туда, где правило можно наблюдать непосредственно, сохранив нужный сквозной пример.
Критерий улучшения — сокращение времени полезного сигнала и расследования при сохранении контроля рисков. Сравнивайте результат на реальных изменениях. Уменьшение числа UI-тестов само по себе не является успехом, если вместе с ним исчезли проверки критического пути.
Типичные ошибки и выводы
Ошибка — считать покрытие строк доказательством правильной пирамиды. Другая ошибка — дублировать одинаковые данные во всех слоях и получать несколько падений на один дефект. Слабая стратегия также проверяет только положительные цепочки и забывает об отказах зависимостей.
Пирамида помогает распределять ответственность проверок. Подробные правила проверяют близко к месту их реализации, взаимодействие — через подходящие границы, а важные пользовательские цепочки — сквозным образом. Такое распределение нужно регулярно пересматривать вместе с архитектурой продукта.
Отдельно сохраняйте явное описание непокрытых рисков: форма диаграммы сама по себе ничего не говорит об их допустимости.