Чёрный ящик
Black box
Доступа к коду нет. Смотришь на систему снаружи и сверяешь поведение с требованиями. Основной метод ручного тестировщика.
Проверяют: функции по требованиям, интерфейс, валидацию форм, обработку ошибок, соответствие ТЗ.
Пример. Форма входа: с верной парой пускает в кабинет, с неверной – показывает ошибку. Как проверяется пароль внутри, тебя не касается.
Опирается на: техники тест-дизайна – классы эквивалентности, границы, таблицы решений, попарное.
Серый ящик
Gray box
Частичный доступ: API, база, логи, очереди, конфиги. Действуешь снаружи, но результат проверяешь и внутри. Рабочая лошадка тестировщика на бэкенде.
Проверяют: контракты API, запись данных в базу, сообщения в очередях, идемпотентность, логику на стыке компонентов.
Пример. Регистрируешь пользователя через интерфейс, затем в базе проверяешь, что запись создана со всеми полями, пароль захеширован, а не лежит открытым текстом.
Опирается на: те же техники плюс знание схемы данных и контракта API.
Белый ящик
White box, structural
Полный доступ к исходному коду. Тесты строишь по внутренней структуре: по строкам и ветвлениям. Чаще всего этим занимаются разработчики.
Проверяют покрытие: покрытие операторов (statement) – выполнена ли каждая строка; покрытие ветвлений (branch, оно же decision) – пройден ли каждый исход условия. 100% ветвлений включает в себя 100% операторов, но не наоборот.
Пример. Unit-тесты для calculateDiscount(price, percent) на каждую ветку: обычная цена, ноль, отрицательное, граница скидки.
Опирается на: структуру кода и метрики покрытия из отчёта coverage.