# White Box Testing
### Содержание:
* [Что такое тестирование “белого ящика”?](#what-is-white-box-testing)
* [Плюсы и минусы тестирования “белого ящика”](#white-box-testing-pros-and-cons)
* [Тестирование “черного ящика” и “белого ящика”](#black-box-and-white-box-testing)
* [Типы тестирования “белого ящика”](#types-of-white-box-testing)
* [На что направлено тестирование “белого ящика”?](#what-does-white-box-testing-focus-on)
* [Покрытие кода](#testing-techniques-and-code-coverage)
* [Покрытие операторов](#statement-coverage)
* [Покрытие ветвей](#branch-coverage)
* [Покрытие путей](#path-coverage)
* [Что такое RASP?](#imperva-runtime-application-self-protection)
### Что такое тестирование “белого ящика”
**Тестирование “белого ящика”** – это подход, который позволяет тестировщикам проверять внутреннюю работу приложения – его код, инфраструктуру и взаимодействие с внешними системами.
Тестирование “белого ящика” часто используется в статическом тестировании безопасности приложений (SAST, Static Application Security Testing) – подходе, который автоматически проверяет исходный код и предоставляет информацию о наличии ошибок и возможных уязвимостей.
Тестирование “белого ящика” анализирует входные и выходные данные с учетом внутренней работы кода.
### Плюсы и минусы тестирования “белого ящика”
| | Плюсы | Минусы |
| -- | ------------------------------------------------------------ | ------------------------------------------------------- |
| 1. | Помогает достичь полного покрытия кода | Требует опытных специалистов в области программирования |
| 2. | Легко автоматизировать | Чувствительно к изменениям в коде |
| 3. | Сокращает коммуникацию между тестировщиками и разработчиками | Может быть довольно сложным и дорогостоящим |
| 4. | Позволяет постоянно совершенствовать код | Невозможно тестировать с точки зрения пользователя |
### Тестирование “черного ящика” и “белого ящика”
White Box Testing и Black Box Testing – два разных подхода к тестированию приложений:
* **Тестирование “белого ящика”** позволяет обнаружить скрытые ошибки и проблемы внутри приложения.
* **Тестирование “черного ящика”** проверяет, что система работает так, как ожидается.
### Типы тестирования “белого ящика”
Виды тестирования “белого ящика”:
* **Юнит-тестирование** – тестирование, которое проверяет, что каждый компонент системы работает так, как ожидается.
* **Мутационное тестирование** – тип модульного тестирования, который проверяет надежность кода. Тестировщики вносят небольшие случайные изменения в код, проверяя, проходят ли тесты.
* **Интеграционное тестирование** – специально разработанные тесты, которые проверяют, как внутренние компоненты программы взаимодействуют друг с другом и с внешними системами.
* **Тестирование на проникновение** – когда этичный хакер пытается атаковать приложение на основе подробного знания его кода и среды.
* **Статический анализ кода** – это автоматическое обнаружение уязвимостей или ошибок в коде, которое происходит без запуска программы.
### На что направлено тестирование “белого ящика”?
Тестирование “белого ящика” может быть направлено на обнаружение следующих проблем в приложении:
* **Уязвимости в безопасности** – проверка безопасности кода приложения на наличие уязвимостей и эксплойтов; соответствует ли код программы стандартам безопасности.
* **Ожидаемый результат** – проверка того, всегда ли функция возвращает ожидаемый результат при использовании всех возможных входных данных.
* **Тестирование потока данных (DFT)** – отслеживание переменных и их значений в коде для поиска ошибок, таких как неправильная инициализация, неиспользуемые переменные.
* **Тестирование циклов** – проверка отдельных и вложенных циклов на эффективность, условную логику и правильную обработку локальных и глобальных переменных.
### Покрытие кода (Code Coverage)
Одной из основных целей тестирования “белого ящика” является максимальное покрытие исходного кода. Покрытие кода – это метрика, которая показывает, какая часть кода приложения была протестирована модульными тестами.
Покрытие кода позволяет узнать, насколько тщательно модульные тесты проверяют функционал и логику приложения. Для этого используются показатели, такие как покрытие операторов, ветвей и путей. Они будут рассмотрены далее с более подробным описанием.
### Покрытие операторов (Statement Coverage)
**Покрытие операторов** – это метод тестирования “белого ящика”, который гарантирует, что каждая команда в коде будет выполнена и проверена хотя бы один раз. Например, если в блоке кода есть несколько условий, которые используются для разных входных данных, тест должен проверить все случаи, чтобы убедиться, что все строки кода действительно выполняются.
Покрытие операторов помогает найти код или ветвления, которые не используются; недостающие операторы и неактивный код, оставленные после предыдущих версий.
### Покрытие ветвей (Branch coverage)
**Покрытие ветвей** – это когда проверяются все возможные пути в коде, где есть условные операторы. Это полезно для того, чтобы обнаружить те ветви в коде, которые не были протестированы или проверены.
Например, если есть несколько вложенных условных операторов:
if X then..if Y then..ABelseif Z then..Celse..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.
* Проверяет, как система реагирует на неожиданные входные данные.
* Предоставляет детальный анализ о слабых местах и уязвимостях в приложении. Это помогает быстрее реагировать на возможные атаки.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://qabook.gitbook.io/start/teoriya-testirovaniya/osnovy-testirovaniya/vidy-testirovaniya/metody-testirovaniya-yashikami/white-box-testing.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
