Вайтбокс — метод тестирования программного обеспечения¶
Вайтбокс (от англ. white box — «белый ящик»; также известен как прозрачный ящик, стеклянный ящик, структурное тестирование) — метод тестирования программного обеспечения, при котором тестировщик обладает полной информацией об архитектуре, исходном коде, внутренней структуре и алгоритмах тестируемой системы. В отличие от чёрного ящика, где проверяется только соответствие выходных данных входным, вайтбокс-тестирование предполагает анализ логики работы программы «изнутри».
¶Основные принципы
Вайтбокс-тестирование строится на нескольких ключевых принципах:
- Доступ к исходному коду — тестировщик (или инструмент) может читать и анализировать код программы.
- Проверка внутренней логики — тесты составляются на основе понимания алгоритмов, ветвлений, циклов и потоков данных.
- Метрики покрытия — эффективность тестов измеряется количеством элементов кода, задействованных при прогоне (покрытие строк, ветвлений, путей, условий).
- Тестовые случаи строятся на основе структуры — тестовые данные подбираются так, чтобы пройти через максимальное число внутренних путей выполнения.
¶Классификация методов
Существует несколько техник вайтбокс-тестирования, различающихся глубиной анализа:
| Техника | Описание |
|---|---|
| Тестирование на основе инструкций | Каждая инструкция исходного кода выполняется хотя бы один раз |
| Тестирование на основе управляющих потоков | Проверяется выполнение всех возможных путей управления (ветвлений, циклов) |
| Тестирование на основе потоков данных | Проверяется корректность обработки данных на всех этапах их прохождения через программу |
| Тестирование на основе базисных путей | Выбирается минимальный набор линейно независимых путей, покрывающих все рёбра графа управления |
| Тестирование на основе условий | Проверяется истинность и ложность каждого логического условия |
| Тестирование на основе граничных значений | Проверяются граничные значения переменных и условий |
¶Метрики покрытия кода
Для оценки полноты вайтбокс-тестирования используются метрики покрытия:
- Покрытие инструкций (statement coverage) — доля строк кода, выполненных при тестировании.
- Покрытие ветвлений (branch coverage) — доля логических ветвлений, по которым прошли оба исхода (true и false).
- Покрытие путей (path coverage) — доля всех возможных путей выполнения программы. Полное покрытие путей практически недостижимо для программ с циклами, так как число путей растёт экспоненциально.
- Покрытие условий (condition coverage) — проверка всех возможных комбинаций значений подусловий составных логических выражений.
- Покрытие функций (function coverage) — доля вызванных функций модуля.
¶Инструменты
Для автоматизации вайтбокс-тестирования и измерения покрытия используются специализированные инструменты:
- JaCoCo — инструмент для измерения покрытия кода на платформе JVM (Java, Kotlin, Scala).
- Istanbul / nyc — инструмент покрытия для JavaScript и TypeScript.
- coverage.py — модуль для Python.
- gcov / lcov — инструменты GNU для языков C и C++.
- dotCover, OpenCover — инструменты для .NET.
- Средства интеграции в IDE — IntelliJ IDEA, Visual Studio, PyCharm и другие поддерживают встроенный анализ покрытия.
¶Применение
Вайтбокс-тестирование применяется на уровне модульного (юнит) тестирования и интеграционного тестирования. На уровне приёмочного и системного тестирования, как правило, используется чёрный ящик, так как тестировщик не имеет доступа к коду конечной системы.
Основные сценарии применения:
- Разработка библиотек и фреймворков — проверка корректности всех внутренних алгоритмов.
- Критичное ПО — медицинское, авиационное, банковское программное обеспечение, где требуется документированное подтверждение полноты тестирования.
- Рефакторинг — проверка того, что изменения кода не сломали существующую логику.
- Написание unit-тестов — разработчик, создавая тесты, естественно использует вайтбокс-подход.
¶Достоинства и ограничения
Достоинства:
- Высокая глубина тестирования — выявляются ошибки логики, недостижимые при чёрном ящике.
- Объективная метрика качества тестов (покрытие кода).
- Возможность оптимизации набора тестов при тестировании на базисных путях.
Ограничения:
- Требуется доступ к исходному коду, что ограничивает применимость на этапе приёмки.
- Высокая трудоёмкость — полное покрытие путей невозможно для программ с циклами.
- Тестировщик может «зациклиться» на существующей логике и не заметить ошибок в самих требованиях: если код реализует неверное требование, вайтбокс-тесты, построенные на этом коде, его не обнаружат.
- Тесты чувствительны к изменениям кода — рефакторинг ломает множество тестов.
¶Связь с другими методами
Вайтбокс-тестирование дополняет чёрный ящик (black box) и серый ящик (grey box). Серый ящик — промежуточный подход, при котором тестировщик частично знает внутреннее устройство системы (документацию, архитектуру), но не имеет доступа к исходному коду. В реальной практике юнит-тестирование почти всегда является вайтбокс-подходом, а системное тестирование — чёрным ящиком.
Источники:
- ГОСТ Р ИСО/МЭК 12207-2010 «Информационные технологии. Процессы жизненного цикла программных систем»
- Myers, G. J. The Art of Software Testing
- Beizer, B. Software Testing Techniques
- Sommerville, I. Software Engineering
- Практика DevOps и CI/CD: измерение покрытия кода (JaCoCo, Istanbul, coverage.py)