Приведи пример Gray box

Пример тестирования методом Gray Box (серого ящика)

Gray Box Testing (тестирование серого ящика) — это гибридный подход, который сочетает элементы black box (функциональное тестирование без знания внутренней структуры) и white box (тестирование с полным доступом к коду и архитектуре). Тестировщик обладает частичным знанием внутренней работы системы — например, знает архитектуру, схемы данных или алгоритмы, но не имеет доступа к исходному коду или не анализирует его полностью. Это позволяет создавать более целенаправленные и эффективные тестовые сценарии.

Конкретный пример: Тестирование веб-приложения с известной схемой базы данных

Рассмотрим веб-приложение для управления пользователями (регистрация, аутентификация, профиль). Тестировщик знает:

• Структуру базы данных: таблицы users, roles, user_logs.
• Бизнес-правила: например, "пароль должен храниться в зашифрованном виде", "при неудачной попытке входа записывается лог".
• API-эндпоинты и ожидаемые форматы ответов (например, из документации).
• Но не имеет доступа к исходному коду серверной логики (например, к методу, который проверяет пароль).

Тестовый сценарий: "Проверка обработки неверного пароля при входе"

Шаги тестирования и применение знаний серого ящика:

1. Предварительное условие (используя знания структуры БД):

   -- Тестировщик знает структуру, поэтому может подготовить данные
   INSERT INTO users (id, email, password_hash) VALUES (100, 'test@example.com', '$2y$10$...hashedPassword');
   

    (В реальном тесте это делается через API или инструменты, но знание схемы позволяет понять, какие данные нужны.)

1. Выполнение теста (как в black box):

    *   Открыть интерфейс входа.
    *   Ввести email: `test@example.com`.
    *   Ввести **неверный пароль**: `wrong123`.
    *   Нажать "Войти".

1. Проверка результатов (используя знания бизнес-логики и БД):

    *   **На уровне UI (black box):** Проверить, что появилось сообщение "Неверный пароль".
    *   **На уровне данных (gray box):** Используя известную схему, проверить, что в таблице `user_logs` появилась запись о неудачной попытке.

```sql
-- Тестировщик может выполнить такой запрос (через тестовый инструмент или API для БД)
SELECT * FROM user_logs WHERE user_id = 100 AND action_type = 'LOGIN_FAILED';
```

    *   Проверить, что в записи есть корректные данные (timestamp, IP).
    *   **На уровне безопасности (gray box):** Убедиться, что в логе **не сохранился** введенный неправильный пароль (`wrong123`) — это известно из требований безопасности.

Почему это Gray Box, а не Black или White?

• Не Black Box, потому что мы использовали внутреннее знание:

    *   О существовании таблицы `user_logs`.
    *   О бизнес-правиле записи неудачных попыток.
    *   Мы активно проверяли данные в БД, что недоступно при чистом функциональном тестировании.

• Не White Box, потому что мы не:

    *   Анализировали код метода `LoginService.authenticate()`.
    *   Проверяли покрытие ветвей (branch coverage) этого метода.
    *   Знаем точную алгоритмическую реализацию хэширования или логирования.

Ключевые преимущества Gray Box Testing в этом примере:

• Повышенная эффективность: Мы создали тест, который проверяет функциональность (сообщение ошибки) и интеграцию с БД (запись лога) одним сценарием.
• Обнаружение сложных дефектов: Можно найти ошибки, которые не видны на UI. Например, если лог записывается, но с неправильным user_id, или если пароль случайно попадает в лог.
• Более умные тестовые данные: Знание схемы БД помогает создавать точные данные для тестов (например, имитировать ситуацию с заблокированным пользователем, если известно поле is_blocked).
• Тестирование безопасности и данных: Часто используется для тестирования безопасности (SQL:инъекции, валидация данных) и интеграционного тестирования, где важно знать, как компоненты взаимодействуют через данные.

Техники Gray Box Testing, которые применяются в подобных примерах:

• Тестирование на основе моделей (Model-Based Testing): Используя известные архитектурные модели или схемы состояния системы.
• Тестирование уязвимостей безопасности: Например, знание, что система использует параметризованные запросы, позволяет тестировать SQL-инъекции более целенаправленно.
• Манипуляция данными через известные интерфейсы: Использование API или прямых запросов к БД (в тестовой среде) для установки состояния и проверки результатов.

Таким образом, Gray Box Testing позволяет тестировщику, находясь "на границе" системы, использовать внутренние знания для создания мощных, целенаправленных тестов, которые проверяют не только "что делает система", но и "как она это делает и какие данные использует", значительно увеличивая глубину и ценность тестового покрытия.