Вайт-бокс — метод тестирования программного обеспечения¶
Вайт-бокс (white box testing, «белый ящик») — метод тестирования программного обеспечения, при котором тестировщик располагает полной информацией об архитектуре, исходном коде, внутренней структуре и логике тестируемой системы. В отличие от чёрного ящика, где проверяется только соответствие выходных данных входным, вайт-бокс предполагает проверку корректности внутренних алгоритмов, ветвлений, циклов и обработки исключений. Метод применяется преимущественно на уровне модульного и интеграционного тестирования.
¶Принцип работы
При выполнении вайт-бокс-тестирования тестировщик (или инструмент) анализирует исходный код и строит тестовые наборы, обеспечивающие определённую степень покрытия кода. Типичные цели:
- проверка всех исполняемых ветвей условий (
if,switch); - проверка корректности работы циклов при граничных значениях;
- проверка обработки исключений и ошибок;
- верификация внутренних структур данных.
Для оценки качества тестирования используют метрики покрытия кода: покрытие инструкций, ветвлений, условий, путей, функций. Инструменты покрытия (JaCoCo, Istanbul, Coverage.py, gcov) фиксируют, какие участки кода были выполнены в ходе прогона тестов.
¶Техники тест-дизайна
Основные техники, применяемые в вайт-бокс-тестировании:
| Техника | Описание |
|---|---|
| Тестирование на основе потоков управления | Построение графа потока управления (CFG) и выбор тестов, покрывающих все переходы |
| Тестирование на основе данных | Отслеживание потоков данных от входных параметров до выходных результатов |
| Покрытие базисных путей | Выбор минимального набора линейно независимых путей через CFG |
| Тестирование границ условий | Проверка истинности и ложности каждого условия с последующей комбинацией |
| Мутационное тестирование | Внесение синтаксических изменений в код (мутантов) и проверка, обнаружат ли тесты каждое изменение |
¶Уровни тестирования
Вайт-бокс применяется на нескольких уровнях тестовой пирамиды:
- Модульное (юнит) тестирование — проверка отдельных функций, классов и модулей. Наиболее естественная область применения метода: разработчик, написавший код, тестирует его с известной внутренней структурой. Используются фреймворки JUnit, pytest, Google Test, xUnit.
- Интеграционное тестирование — проверка взаимодействия модулей между собой, корректности вызовов API, обмена данными.
- Системное тестирование — применяется реже, поскольку на этом уровне доступ к внутренней структуре часто затруднён.
¶Преимущества и ограничения
Достоинства:
- высокая степень обнаружения дефектов логики;
- возможность оптимизации тестового набора на основе метрик покрытия;
- раннее выявление ошибок на этапе юнит-тестирования, когда стоимость исправления минимальна;
- объективная количественная оценка полноты тестирования.
Ограничения:
- требует доступа к исходному коду, что исключает тестирование сторонних компонентов и закрытых систем;
- высокая трудоёмкость: для сложных модулей число возможных путей растёт экспоненциально (проблема комбинаторного взрыва);
- риск «слепого» следования коду: тестировщик может подгонять тесты под фактическую реализацию, а не под требования;
- необходимость пересборки тестов при каждом изменении кода.
¶Отношение к другим методам
Вайт-бокс дополняет, а не замещает чёрный и серый ящики. Чёрный ящик проверяет соответствие требованиям без знания реализации, серый ящик сочетает доступ к коду с тестированием по внешнему поведению. Практически все зрелые процессы разработки сочетают все три подхода: юнит-тесты пишутся по белому ящику, интеграционные и системные — преимущественно по чёрному.
¶Автоматизация
Метод активно автоматизирован. CI-системы запускают тесты покрытия на каждом коммите, а отчётность по покрытию интегрируется в платформы код-ревью (SonarQube, Codecov). Пороговые значения покрытия (часто 70–80 %) нередко закрепляются как критерий приёмки изменений.
¶История
Идея тестирования по внутренней структуре восходит к работам 1960-х годов по верификации программ. Термин «белый ящик» закрепился в 1970-е годы в контексте структурного тестирования (structural testing). В 1979 году Гленфорд Майерс в книге «The Art of Software Testing» систематизировал подходы структурного тестирования, противопоставив их тестированию по функциональным требованиям.