Тестирование методом белого ящика (White Box Testing)

Тестирование методом белого ящика (white-box testing): Тестирование, основанное на анализе внутренней структуры компонента или системы (ISTQB).

Тестирование на основе структуры (structure-based testing): Динамическое тестирование, для которого тесты являются результатом анализа структуры элемента тестирования. Примечание. Тестирование на основе структуры не ограничено использованием на уровне компонентов, а может использоваться на всех уровнях, например при покрытии пункта меню, как части тестирования системы. (ГОСТ 56920)

Тестирование методом белого ящика (также: прозрачного, открытого, стеклянного ящика; основанное на коде или структурное тестирование) - метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тому, кто её тестирует. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации - обязательны для этой техники. Тестирование белого ящика - углубление во внутреннее устройство системы, за пределы ее внешних интерфейсов.

Техника белого ящика применима на разных уровнях тестирования - модульном, интеграционном и системном, но чаще применяется для юнит-тестирования этого участка кода самим разработчиком или SDET. Тестирование белого ящика - это больше, чем тестирование кода: это тестирование путей.​ Обычно тестируемые пути находятся внутри модуля (модульное тестирование). Но мы можем применить эту же методику для тестирования путей между модулями внутри подсистем, между подсистемами внутри систем, и даже между целыми системами.

Тестирование белого ящика - это покрытие требований в коде:

• Code coverage;

• Segment coverage: каждый оператор кода выполняется один раз;

• Branch Coverage or Node Testing: покрытие каждой ветки кода из всех возможных было выполнено;

• Compound Condition Coverage: Для нескольких условий проверяется каждое условие с несколькими путями и комбинацией разных путей для достижения этого условия;

• Basis Path Testing: каждый независимый путь в коде взят на тестирование;

• Data Flow Testing (DFT): в этом подходе вы отслеживаете конкретные переменные посредством каждого возможного вычисления, тем самым определяя набор промежуточных путей через код. DFT имеет тенденцию отражать зависимости, но в основном это происходит через последовательности манипуляций с данными. Короче говоря, каждая переменная данных отслеживается, и ее использование проверяется. Этот подход имеет тенденцию обнаруживать ошибки, такие как переменные, которые используются, но не инициализируются, или объявлены, но не используются, и т.д. (компиляторы/линтеры/IDE уже вполне способны на это сами);

• Path Testing: тестирование пути - это определение и покрытие всех возможных путей прохождения через код;

• Loop Testing: эти стратегии относятся к тестированию одиночных циклов, составных (concatenated) циклов и вложенных циклов;

Используя покрытие Statement и Branch, вы обычно достигаете 80-90% покрытия кода, что является достаточным.

Процесс White box testing:

• Анализируется реализация программы;

• В программе определяются возможные маршруты;

• Выбираются такие входные данные, чтобы программа выполнила выбранные пути. Это называется сенсибилизацией путей. Заранее определяются ожидаемые результаты для входных данных;

• Тесты выполняются;

• Результаты анализируются;

Преимущества White box testing:

• тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса;

• можно провести более тщательное тестирование, с покрытием большого количества путей выполнения программы;

Недостатки White box testing:

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

• Выбранные тест-кейсы могут не содержать данные, которые будут чувствительны к ошибкам. Например: p=q/r; может выполняться корректно, за исключением случая, когда r=0. y=x^2; тест не выявит ошибок в случаях, когда x=0, y=0 и x=2, y=4;

• Тестирование белого ящика предполагает, что поток управления правильный (или близок к правильному). Поскольку эти тесты основаны на существующих путях, с помощью нельзя обнаружить несуществующие пути;

• Тестировщик должен обладать навыками программирования для того, чтобы понять и оценить тестируемое программное обеспечение;

White box testing нужно:

Чтобы убедиться, что:

• Все независимые пути в модуле были проверены хотя бы один раз;

• Все логические решения проверены на их истинное и ложное значения;

• Все циклы выполняются на своих границах и в пределах своих рабочих границ валидности внутренних структур данных;

Чтобы обнаружить следующие типы ошибок:

• Логическая ошибка имеет тенденцию закрасться в нашу работу, когда мы разрабатываем и реализуем функции, условия или элементы управления, которые не входят в программу;

• Ошибки проектирования из-за разницы между логическим потоком программы и фактической реализацией;

• Типографические ошибки и проверка синтаксиса.

Источники:

• White Box Testing: A Complete Guide With Techniques, Examples, & Tools

• Ли Копланд - “A Practitioner's Guide to Software Test Design”, Секция II. Методы тестирования белого ящика