Одна ось: насколько крупный кусок системы под тестом. От одной функции до всего пути
пользователя. Пирамида показывает, как разложить проверки по уровням, чтобы прогон был
быстрым и дешёвым. Ткни в уровень – справа разбор.
Уровень – это масштаб, а не вид проверки. Функциональное тестирование живёт
на всех уровнях сразу: и в unit, и в системном. Уровень отвечает на "какого размера кусок я
проверяю", а не "что именно проверяю".
Интерактивная пирамида
Снизу вверх: тесты крупнее, медленнее и дороже, а их число должно падать. Чем ниже
уровень, тем больше на нём тестов.
Ткни в любой уровень – справа появится разбор.
Четыре уровня
Пирамида распределяет усилия по уровням. Основание – быстрые дешёвые unit-тесты, их много. К вершине тесты крупнее, медленнее и дороже, поэтому их держат меньше.
Кто проводит
Что ловит
Когда пирамида ломается
Форма пирамиды – не украшение, а баланс. Если тесты сползают наверх, прогон становится
медленным и хрупким. Два типовых перекоса, про которые спрашивают на собеседовании.
Рожок мороженого
Ice cream cone
Пирамида перевёрнута: сверху шар из ручных E2E, unit почти нет. Каждую регрессию гоняют руками через весь интерфейс.
Чем плохо: прогон долгий, тесты хрупкие и падают от любой мелочи в вёрстке, причину бага ищут через всю систему. Так выглядит проект, где автотесты начали писать поздно и сверху.
Песочные часы
Hourglass
Толстый низ из unit и толстый верх из E2E, а интеграционный слой почти пустой. Середина провалена.
Чем плохо: баги на стыке модулей проскакивают мимо unit и всплывают только в дорогих E2E. Лечится наращиванием интеграционных и API-тестов, которые дешевле E2E и точнее unit.
Пирамида – модель, а не закон. У бэкенда без интерфейса форма другая, а сторонники "trophy"
ставят в центр интеграционные тесты. Важен принцип: дорогих медленных тестов держи меньше,
чем дешёвых быстрых.
Как отвечать и где не путать
На собеседовании
Назови четыре уровня снизу вверх и скажи, кто на каком работает: unit и интеграционные – чаще разработчики, системное и приёмочное – тестировщики.
Смысл формы: чем выше, тем дороже, медленнее и хрупче, поэтому таких тестов меньше.
Держи наготове два перекоса – рожок мороженого и песочные часы – и чем каждый вреден.
Не путай уровень с видом. "E2E – это вид тестирования" – неточно: E2E это уровень, а функциональным оно может быть на любом.
На проекте
Ручной тестировщик живёт в основном на системном и приёмочном уровне. Про unit полезно знать, чтобы говорить с разработчиками на одном языке.
Заметил, что регресс гоняется только руками через интерфейс – это рожок мороженого. Повод предложить API-тесты.
Абсолютные пропорции не заучивай. Проверяй направление: дешёвых тестов больше, дорогих меньше.
Уровень – это масштаб, а не цель проверки. Функциональное, регресс, нагрузка, безопасность –
виды по цели, они лежат на другой оси и встречаются на любом уровне.
Подробно – шпаргалка "Виды тестирования".
Чёрный, серый и белый ящик – отдельная ось: степень доступа к коду. Unit чаще делают белым
ящиком, приёмочное – чёрным, но жёсткой связки нет.
Подробно – шпаргалка "Методы тестирования".