Тестирование является важным этапом разработки ПО, гарантирующим качество и надежность создаваемых приложений. Одним из подходов к тестированию является метод “белого ящика”, который позволяет глубоко исследовать внутренние компоненты системы и обнаруживать проблемы и ошибки в приложениях.
В этой статье мы рассмотрим основы тестирования “белого ящика”, его преимущества и ключевые принципы, которые помогут вам стать хорошим тестировщиком.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
Содержание:
- Что такое тестирование “белого ящика”?
- Плюсы и минусы тестирования “белого ящика”
- Тестирование “черного ящика” и “белого ящика”
- Тестирование “серого ящика”
- Типы тестирования “белого ящика”
- На что направлено тестирование “белого ящика”?
- Покрытие кода
- Покрытие операторов
- Покрытие ветвей
- Покрытие путей
- Что такое RASP?
Что такое тестирование “белого ящика”
Тестирование “белого ящика” – это подход, который позволяет тестировщикам проверять внутреннюю работу приложения – его код, инфраструктуру и взаимодействие с внешними системами.
Тестирование “белого ящика” часто используется в статическом тестировании безопасности приложений (SAST, Static Application Security Testing) – подходе, который автоматически проверяет исходный код и предоставляет информацию о наличии ошибок и возможных уязвимостей.
Тестирование “белого ящика” анализирует входные и выходные данные с учетом внутренней работы кода.
Плюсы и минусы тестирования “белого ящика”
| Плюсы | Минусы | |
|---|---|---|
| 1. | Помогает достичь полного покрытия кода | Требует опытных специалистов в области программирования |
| 2. | Легко автоматизировать | Чувствительно к изменениям в коде |
| 3. | Сокращает коммуникацию между тестировщиками и разработчиками | Может быть довольно сложным и дорогостоящим |
| 4. | Позволяет постоянно совершенствовать код | Невозможно тестировать с точки зрения пользователя |
Тестирование “черного ящика” и “белого ящика”
White Box Testing и Black Box Testing – два разных подхода к тестированию приложений:
- Тестирование “белого ящика” позволяет обнаружить скрытые ошибки и проблемы внутри приложения.
- Тестирование “черного ящика” проверяет, что система работает так, как ожидается.
Тестирование “серого ящика”
Тестирование “белого ящика” означает, что тестировщик полностью разбирается во внутренней работе системы, в то время как тестирование “черного ящика” не требует этого. Тестирование “серого ящика” представляет собой смешанный подход, так как оно основано на частичном понимании внутренней работы системы. Чаще всего оно используется в интеграционном тестировании, сквозном тестировании системы и тестировании на проникновение.
Тестирование “серого ящика” – это совместная работа тестировщиков и разработчиков . Они используют свои знания о системе, чтобы проверить ключевые функции и возможности приложения.
Тестирование “серого ящика” сочетает в себе преимущества тестирования “черного ящика” и “белого ящика”:
- Помогает проверить, насколько удобным и функциональным приложение является для конечного пользователя, также как и в тестировании “черного ящика”.
- Позволяет выявить и исправить проблемы во внутренней работе системы, как и в тестировании “белого ящика”.
Подход к тестированию методом “серого ящика” называется интерактивным тестированием безопасности приложений (IAST – Interactive Application Security Testing ). IAST включает:
- SAST (Static Application Security Testing) – выполняет тестирование “белого ящика”, проводя статический анализ кода.
- DAST(Dynamic Application Security Testing ) – выполняет тестирование “черного ящика”, находит ошибки и уязвимости в приложении, так же, как это делает обычный пользователь или злоумышленник.
Типы тестирования “белого ящика”
Виды тестирования “белого ящика”:
- Юнит-тестирование – тестирование, которое проверяет, что каждый компонент системы работает так, как ожидается.
- Мутационное тестирование – тип модульного тестирования, который проверяет надежность кода. Тестировщики вносят небольшие случайные изменения в код, проверяя, проходят ли тесты.
- Интеграционное тестирование – специально разработанные тесты, которые проверяют, как внутренние компоненты программы взаимодействуют друг с другом и с внешними системами.
- Тестирование на проникновение – когда этичный хакер пытается атаковать приложение на основе подробного знания его кода и среды.
- Статический анализ кода – это автоматическое обнаружение уязвимостей или ошибок в коде, которое происходит без запуска программы.
На что направлено тестирование “белого ящика”?
Тестирование “белого ящика” может быть направлено на обнаружение следующих проблем в приложении:
- Уязвимости в безопасности – проверка безопасности кода приложения на наличие уязвимостей и эксплойтов; соответствует ли код программы стандартам безопасности.
- Ожидаемый результат – проверка того, всегда ли функция возвращает ожидаемый результат при использовании всех возможных входных данных.
- Тестирование потока данных (DFT) – отслеживание переменных и их значений в коде для поиска ошибок, таких как неправильная инициализация, неиспользуемые переменные.
- Тестирование циклов – проверка отдельных и вложенных циклов на эффективность, условную логику и правильную обработку локальных и глобальных переменных.
Покрытие кода (Code Coverage)
Одной из основных целей тестирования “белого ящика” является максимальное покрытие исходного кода. Покрытие кода – это метрика, которая показывает, какая часть кода приложения была протестирована модульными тестами.
Покрытие кода позволяет узнать, насколько тщательно модульные тесты проверяют функционал и логику приложения. Для этого используются показатели, такие как покрытие операторов, ветвей и путей. Они будут рассмотрены далее с более подробным описанием.
Покрытие операторов (Statement Coverage)
Покрытие операторов – это метод тестирования “белого ящика”, который гарантирует, что каждая команда в коде будет выполнена и проверена хотя бы один раз. Например, если в блоке кода есть несколько условий, которые используются для разных входных данных, тест должен проверить все случаи, чтобы убедиться, что все строки кода действительно выполняются.
Покрытие операторов помогает найти код или ветвления, которые не используются; недостающие операторы и неактивный код, оставленные после предыдущих версий.
Покрытие ветвей (Branch coverage)
Покрытие ветвей – это когда проверяются все возможные пути в коде, где есть условные операторы. Это полезно для того, чтобы обнаружить те ветви в коде, которые не были протестированы или проверены.
Например, если есть несколько вложенных условных операторов:
if X then..
if Y then..
A
B
else
if Z then..
C
else..
D A, C и D – условные ветви, потому что они выполняются только при определенных условиях. B – это безусловная ветвь, поскольку она всегда выполняется после A. При тестировании методом Branch Сoverage тестировщик определяет все условные и безусловные ветви и пишет код, чтобы выполнить максимальное количество ветвей.
Покрытие путей (Path Coverage)
Покрытие путей – это проверка различных путей в коде. Это означает, что тестировщики стараются проходить по разным путям в коде, чтобы проверить их выполнение.
Тестировщики создают диаграмму потока кода, как показано на примере ниже:
В этом примере есть несколько путей, по которым может быть выполнен код:
- 1, 2
- 1, 3, 4, 5, 6, 8
- 1, 3, 4, 7, 8
- и т.д.
При подходе с Branch Coverage тестировщик пишет модульные тесты, чтобы пройти максимальное количество путей в программе. Цель – выявить нарушенные, избыточные или неэффективные пути.
Что такое RASP?
RASP (Runtime Application Self Protection) дополняет тестирование методом “белого” и “черного” ящика. Он даёт дополнительный уровень защиты, когда приложение уже находится в продакшене.
RASP имеет следующие преимущества:
- Помогает тестировать приложения при методологии Agile.
- Проверяет, как система реагирует на неожиданные входные данные.
- Предоставляет детальный анализ о слабых местах и уязвимостях в приложении. Это помогает быстрее реагировать на возможные атаки.
Перевод статьи «White Box Testing».