Пирамида тестирования​

уровни тестирования

Пирамида тестирования

группировка тестов по уровню детализации и их назначению
3 уровня
оригинальная пирамида тестов Майка Кона

Пирамида тестов Майка Кона

оригинальная пирамида тестов Майка Кона
«Scrum: гибкая разработка ПО» (Succeeding With Agile. Software Development Using Scrum)

Юнит-тесты
Сервисные тесты
Тесты пользовательского интерфейса

по ISTQB

(wiki)
модульное тестирование (юнит)
интеграционное тестирование
системное тестирования
приемочное тестирования
4 уровня
(снизу вверх)
ISTQB
3 уровня
модификация пирамиды тестов Майка Кона

вариации..

(блог semaphore)
модульное тестирование (юнит)
интеграционное тестирование (включает в себя системное)
сквозное тестирования
принципы

Принципы, вытекающие из пирамиды:

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

Важно помнить!

— Тест (ручной, на высоких уровнях, или автотест, на низких уровнях) должен быть на том же уровне, что и тестируемый объект.
например:

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

— Тесты уровнем выше не проверяют логику тестов уровнем/уровнями ниже
— Чем выше тесты уровнем, тем они:
сложней в реализации, и соответственно, дороже
важнее для бизнеса и критичней для пользователей
замедляют скорость прохождения тестовых наборов, например, регресса
уровни тестирования

Пирамида тестирования детально

unit testing

Компонентный уровень

тестируют атомарные части кода (классы, функции или методы классов)
метод белого ящика
юнит тесты выполняются быстрее всех и требуют меньше ресурсов
integration testing

Интеграционный уровень

проверки API, работы сервисов (проверка логов на сервере, записи в БД) и т.п.
метод серого / черного ящика
system testing

Системный уровень

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

Приемочное тестирование

E2E тесты (End-2-End) или сквозные (проверка работы ПО в целом)
автоматизируются сложнее, дольше, стоят дороже, сложнее поддерживаются и трудно выполняются при регрессе.
Значит таких тестов должно быть меньше
нравится контент?

Если хочешь поощрить за труд, жми кнопку

Прокрутить вверх