В стратегии White Box (белый ящик) тестирования рассматривается внутренняя логика и структура кода. Его также называют стеклянным, структурным, открытым или прозрачным ящиком тестирования. Тесты, написанные на основе стратегии White Box тестирования включают покрытие написанного кода, ответвлений, путей, отчетности, внутренней логики кода и др.
В целях реализации метода тестирования белого ящика, тестировщик имеет дело с кодом, и, следовательно, ему необходимо владеть знаниями кодирования и логики т. е., внутренней работы кода. White Box тест также нужен в тестировщике, который взглянув на код может выяснить, какой блок/кусок кода работает неправильно.
Крайне важно, чтобы тестер имел «структурные» знания о том, как система была внедрена. Не только код, но даже поток данных и поток управления должны быть оценены.
Участки кода, которые тестируются с помощью White Box тестирования являются:
Есть три аспекта кодекса, которые проверяются в White Box тестировании, а именно:
Разработчик выполняет модульное тестирование, чтобы проверить, правильно ли работает конкретный модуль или блок кода. Модульное тестирование происходит на самом базовом уровне и осуществляется при разработке конкретного модуля или при встраивании определенной функции.
Статический анализ состоит в просмотре кода, чтобы выяснить любые возможные дефекты в коде, динамический анализ предполагает выполнение кода и анализ выходных данных.
В этом типе тестирования, код выполняется таким образом, что каждая строка приложения выполняется как минимум один раз. Это помогает в обеспечении, того что все инструкции выполняются без каких-либо побочных эффектов. Различные средства управления покрытиями используются, чтобы оценить процент исполняемых элементов, которые в настоящее время были протестированы. (Эти инструменты используются как строковые покрытия, а также как покрытие решений.)
Ни одно приложение не может быть написано в непрерывном режиме кодирования. В какой-то момент мы должны разветвить код для того, чтобы выполнить ту или иную функциональность. Тестирование покрытия решений помогает в проверке всех ветвей в коде, и помогает убедиться, что ветвление не приводит к непредсказуемому поведению приложения.
Когда код написан, есть вероятность, что в коде существует проблема утечки памяти, которая делает код неисправным. Поэтому, во время тестирования по методу белого ящика проверяется есть ли в коде утечка памяти. В случае утечки памяти, для программного обеспечения требуется больше памяти, и это влияет на скорость работы программного обеспечения, что делает его медленным.
Тестирование безопасности проводится для того, чтобы выяснить, насколько хорошо система может защитить себя от несанкционированного доступа, взлома (крекинг, любое повреждение кода и т.д.) которая имеет дело с кодом приложения. Этот тип тестирования требует сложных методов тестирования.
Это своего рода тестирование, в котором, приложение тестируется на код, который был изменен после фиксации определенного бага/дефекта. Оно также помогает выяснить, какой код и какая стратегия кодирования может помочь в разработке эффективной функциональности.
Кроме всех тех видов тестирования, которые приведенные выше, есть еще несколько типов, которые подпадают под оба вида стратегий тестирования черного и белого ящика, такие как: функциональное тестирование (что касается кода с целью проверки его эксплуатационных качеств), инкрементное тестирование интеграции (которая занимается тестированием добавленного в приложение кода), тестирование производительности и нагрузки (которая помогает выяснить, как тот или иной код управляет ресурсами и дает производительность) и др. Поскольку они подпадают под White Box, а также под Black Box трудно классифицировать их в любой из этих двух широких типов тестирования программного обеспечения.