Автоматизация тестирования
Пирамида тестирования: что это и как её читать
Пирамида тестирования – модель из автоматизации, которая показывает, сколько тестов держать на каждом уровне. В основании много быстрых и дешёвых модульных (unit) тестов, в середине меньше интеграционных и API-тестов, на вершине меньше всего медленных и дорогих тестов через графический интерфейс и сквозных (E2E). Чем выше слой, тем дольше тест пишется и выполняется и тем дороже обходится, поэтому таких тестов держат меньше.
- Unit → API → GUI
- снизу вверх тестов всё меньше, а каждый дороже
- Рожок мороженого
- перевёрнутая пирамида, когда почти всё проверяют через интерфейс
- Бесплатно
- урок с заданиями в моём базовом курсе
Что такое пирамида тестирования
Пирамида тестирования связана с уровнями тестирования, но относится в первую очередь к автоматизации: она показывает, сколько тестов должно быть на каждом уровне. Уровни снизу вверх такие: модульный (unit), интеграционный, системный и приёмочный. Вместо приёмочного на вершине схем часто пишут E2E, то есть сквозное тестирование. Сквозной тест проходит путь пользователя от первого шага до последнего, в интернет-магазине от регистрации до заказа, и получается одним большим тестом на все этапы работы.
Главная мысль модели в том, что тестов на вершине должно быть меньше всего: они самые медленные, дорогие и трудоёмкие. В основании лежат самые быстрые и дешёвые тесты, и их больше всего.
Пирамиду предложил Майк Кон в книге "Succeeding with Agile" 2009 года. В исходной модели три слоя: unit-тесты, сервисные тесты и тесты пользовательского интерфейса.
Unit, API и GUI: три слоя пирамиды
Системный уровень на схемах иногда опускают, потому что системные и приёмочные тесты чаще всего идут через графический интерфейс. Так получается вторая популярная схема из трёх слоёв, и запомнить стоит именно её.
Unit (модульные тесты)
Проверяют отдельные функции и методы кода. Их проще всего написать и быстрее всего запустить, а стоят они меньше остальных, поэтому их больше всего. Пишут их обычно разработчики.
API (интеграционные тесты)
Проверяют, как работают вместе несколько компонентов, чаще всего через API, то есть программный интерфейс, по которому части приложения обмениваются данными. Писать их сложнее, потому что приходится учитывать связи между компонентами. Обычно это код, но ручной тестировщик может проверять API и в Postman без программирования. Таких тестов меньше, чем unit, но всё равно много.
GUI и E2E (тесты через интерфейс)
Системные и приёмочные проверки через графический интерфейс. Автоматизатор тратит на них больше всего времени, потому что нужно прописывать селекторы и учитывать взаимодействие разных компонентов страницы. Выполняются они дольше всех, и вручную такие проверки тоже самые долгие. Без них не обойтись, но они закрывают только основные сценарии работы пользователя, и их меньше всего.
Почему наверху тестов меньше
Программа ISTQB Foundation Level 2023 года описывает пирамиду так: чем выше слой, тем крупнее тесты, тем меньше они изолированы и тем дольше выполняются. Тесты внизу маленькие и быстрые, каждый проверяет небольшой кусок функциональности, поэтому для хорошего покрытия их нужно много. Тесты наверху сложные и медленные, каждый проверяет большой кусок системы, и их нужно немного. Число и названия слоёв в разных моделях отличаются. В программе 2018 года пирамиды нет, она описана в отдельной программе для тестировщиков в Agile.
Я объясняю то же через деньги и время. Unit-тест проще всего написать и быстрее всего запустить, и почти ничего он не стоит. Интеграционный тест сложнее, потому что нужно учитывать связь нескольких компонентов. Тест через интерфейс пишется и выполняется дольше всех и считается самым дорогим. Это касается и ручного тестирования: приёмочные проверки руками тоже идут дольше остальных.
Если упал unit-тест, ошибка сидит в одной функции. Если упал сквозной тест, причина может быть где угодно на пути от регистрации до оплаты, и её ещё предстоит найти. К тому же тесты через интерфейс ломаются от правок вёрстки, даже когда функциональность работает.
Точных пропорций модель не задаёт: у каждой команды они свои, и заучивать числа не нужно.
Пример: заказ в интернет-магазине на трёх слоях
Допустим, в интернет-магазине проверяют оформление заказа со скидкой по промокоду.
Unit
Функцию, которая считает сумму корзины, проверяют на многих наборах данных: пустая корзина, один товар, несколько товаров, скидка в процентах, скидка больше суммы заказа. Каждый тест выполняется за доли секунды, и неверное округление сразу видно в конкретной функции.
API
Запрос на создание заказа должен вернуть успешный ответ и сохранить заказ с правильной суммой. Отдельные запросы проверяют, как сервер отвечает на несуществующий товар и просроченный промокод. Интерфейс для этого не нужен.
GUI и E2E
Один-два сквозных сценария, как в моём примере: войти, найти товар, положить его в корзину, применить промокод, оплатить и увидеть подтверждение заказа. Все варианты скидок через интерфейс не перебирают, их уже проверили слои ниже.
Если пирамида перевёрнута
Те же варианты скидок проверяют только через браузер. Прогон растягивается, тесты падают от правок вёрстки, а чтобы понять, где ошибка в расчёте, приходится разбирать весь путь пользователя.
Рожок мороженого и другие перекосы
На проектах пирамиду часто нарушают. По моим наблюдениям, на курсах по автоматизации учат в основном тестам через интерфейс, про API рассказывают меньше, про unit иногда не говорят вовсе. Поэтому многие начинают сразу с GUI-тестов, и я считаю это неверным.
Перевёрнутую пирамиду называют рожком мороженого (ice cream cone). Unit-тестов в ней почти нет, а сверху шапка из тестов через интерфейс и ручных проверок. Регресс в таком проекте идёт долго, а тесты получаются хрупкими. Другой перекос называют песочными часами: unit- и UI-тестов много, интеграционный слой почти пустой, и ошибки на стыке модулей ловят только дорогие сквозные тесты.
Форма зависит от продукта. У сервиса без интерфейса верх почти пуст, а некоторые команды делают упор на интеграционные тесты. Общий принцип при этом сохраняется: медленных и дорогих тестов меньше, чем быстрых и дешёвых.
Ручного тестировщика пирамида тоже касается. Он работает в основном на верхних слоях, и если весь регресс проходят руками через интерфейс, это повод предложить API-тесты. Собрать их можно и без программирования, в Postman.
Например, в приложении доставки еды перед каждым релизом руками проверяют стоимость доставки для двадцати адресов в разных зонах. Те же двадцать случаев можно собрать в коллекцию Postman к запросу расчёта доставки, и прогон займёт минуты, а через интерфейс останутся два-три сценария оформления заказа.
Видеоурок, шпаргалка и задания
Пирамиду я объясняю в коротком ролике на YouTube сразу после разбора уровней тестирования. В бесплатном базовом курсе по тестированию пирамида входит в урок "Уровни тестирования. Позитивные и негативные тесты", и после теории в нём идут задания.
Шпаргалка показывает уровни на интерактивной пирамиде и разбирает перекосы, о которых спрашивают на собеседовании. В тренажёре классификации тесты нужно разложить по уровням, видам и методам.
Курсы по теме
Вопросы и ответы
Что такое пирамида тестирования простыми словами?
Схема, которая показывает, сколько автотестов держать на каждом уровне. Внизу много быстрых и дешёвых unit-тестов, в середине меньше API- и интеграционных, наверху меньше всего медленных и дорогих тестов через интерфейс и сквозных.
Почему UI-тестов должно быть меньше всего?
Они дольше всех пишутся, потому что приходится прописывать селекторы и учитывать взаимодействие компонентов. Выполняются они тоже дольше всех, ломаются от правок вёрстки и стоят дороже остальных. Поэтому через интерфейс проверяют основные сценарии пользователя, а остальное переносят на нижние слои.
Какие слои у пирамиды тестирования?
В исходной модели Майка Кона три слоя: unit, сервисные тесты и UI. Часто рисуют unit, API и GUI или четыре уровня: модульный, интеграционный, системный и приёмочный либо E2E. Число и названия слоёв различаются, а смысл везде один.
Что такое рожок мороженого в тестировании?
Перевёрнутая пирамида: unit-тестов почти нет, а основная проверка идёт через интерфейс и руками. Прогон в таком проекте долгий, тесты хрупкие, а причину падения приходится искать по всей системе.
Нужна ли пирамида ручному тестировщику?
Да. Ручной тестировщик работает в основном на верхних слоях, и пирамида объясняет, почему не всё стоит проверять через интерфейс. О ней спрашивают на собеседованиях, а API-тесты можно делать и без кода, например в Postman.
Есть ли пирамида тестирования в ISTQB?
В программе Foundation Level 2023 года пирамиде посвящён отдельный раздел: чем выше слой, тем крупнее и медленнее тесты и тем их меньше. В программе 2018 года её нет, она описана в программе для тестировщиков в Agile.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.