Что такое тестирование серого ящика?
Тестирование серого ящика (grey-box testing) находится между тестированием чёрного и белого ящика. Тестировщик обладает частичным знанием внутреннего устройства системы — достаточным для проектирования более умных тестов, чем при чистом black-box, но без полной видимости исходного кода, как при white-box.
Grey-box тестировщик может знать:
- Архитектуру системы (какие сервисы взаимодействуют между собой)
- Схему базы данных (структуру таблиц, связи)
- Контракты API (endpoints, форматы запросов/ответов)
- Поток данных между компонентами
- Технологический стек (фреймворк, СУБД, очередь сообщений)
Но обычно не имеет:
- Доступа к полному исходному коду
- Знания конкретных реализаций алгоритмов
- Построчного понимания бизнес-логики
Представьте автомеханика, который знает общее устройство двигателя (цилиндры, впрыск топлива, выхлоп), но не читал детальные инженерные чертежи. Он может диагностировать проблемы эффективнее, чем человек без технических знаний, даже без полной документации.
Когда применяется Grey-Box Testing
Grey-box тестирование естественно возникает в нескольких распространённых сценариях:
Интеграционное тестирование
При тестировании взаимодействия двух сервисов тестировщик часто знает API-контракт между ними, формат сообщений и, возможно, таблицы БД, куда попадают данные. Это частичное знание помогает проектировать тесты, проверяющие не только «успешен ли запрос?», но и «корректно ли данные попали в базу?»
API-тестирование
API-тестировщики обычно знают структуру endpoints, ожидаемые payload, механизмы аутентификации и, возможно, схему базы данных. Они тестируют API как чёрный ящик (отправить запрос, проверить ответ), но используют знание БД для проверки сохранения данных.
Тестирование безопасности
Тестировщики безопасности часто знают технологический стек, поток аутентификации и типичные паттерны уязвимостей. Они тестируют извне (как атакующий), но используют внутренние знания для фокусировки на наиболее вероятных векторах атак.
Тестирование миграции
При миграции с одной системы на другую тестировщики знают структуры данных источника и приёмника. Они используют это знание для проверки правил трансформации и полноты данных.
Техники серого ящика
Матричное тестирование
Изучите документацию архитектуры для выявления всех взаимодействий между компонентами. Создайте матрицу связей и протестируйте каждую:
| Компонент A | Компонент B | Интерфейс | Приоритет |
|---|---|---|---|
| Web App | Auth Service | REST API | Высокий |
| Auth Service | User DB | SQL | Высокий |
| Web App | Payment Gateway | REST API | Критический |
| Order Service | Email Service | Очередь сообщений | Средний |
Тестирование паттернов
Используйте знание технологического стека для проверки типичных паттернов уязвимостей:
- SQL базы данных → Тест на SQL injection
- REST API → Тест на IDOR (Insecure Direct Object References)
- Очереди сообщений → Тест на порядок и дубликаты сообщений
- Кэширование → Тест на устаревшие данные
Тестирование состояния с проверкой базы данных
Выполните действие чёрного ящика (например, отправка формы) и затем проверьте результирующее состояние в БД:
- Проверить начальное состояние базы данных
- Выполнить пользовательское действие через UI или API
- Выполнить запрос к БД для проверки корректного сохранения
- Проверить обновление связанных таблиц (foreign keys, логи аудита)
- Проверить инвалидацию кэшей
Реальные примеры
Пример 1: Оформление заказа в интернет-магазине. Grey-box тестировщик знает, что checkout затрагивает Order Service, Payment Service и Inventory Service. Он тестирует позитивный сценарий через UI (black-box), но также проверяет уменьшение остатков в БД (grey-box).
Пример 2: Регистрация с подтверждением email. Тестировщик знает, что система отправляет письма через SMTP и хранит токен верификации в БД. Регистрирует пользователя (black-box), затем ищет токен в БД (grey-box).
Пример 3: Функция поиска. Тестировщик знает, что используется Elasticsearch. Он использует это знание для проверки специфических граничных случаев: спецсимволы, стемминг, пороги нечёткого поиска.
Grey-Box vs. Black-Box vs. White-Box
| Аспект | Чёрный ящик | Серый ящик | Белый ящик |
|---|---|---|---|
| Доступ к коду | Нет | Нет или ограниченный | Полный |
| Знание архитектуры | Нет | Да | Полное |
| Доступ к БД | Нет | Часто да | Полный |
| Знание API | Только endpoints | Контракты + поток данных | Полная реализация |
| Кто выполняет | QA, пользователи | QA, SDET | Разработчики |
| Основа тестов | Требования | Требования + архитектура | Исходный код |
| Лучше всего для | Функциональное, UAT | Интеграционное, API, безопасность | Юнит-тесты |
Преимущества над чистыми подходами
Над black-box:
- Может проверять целостность данных на уровне базы данных
- Может нацеливать тесты на известные архитектурные слабые места
- Может проверять асинхронные операции через очереди сообщений или БД
- Сокращает избыточные тесты благодаря пониманию внутренних путей данных
Над white-box:
- Не требует глубоких навыков программирования
- Тесты остаются относительно независимыми от деталей реализации
- Более точно моделирует перспективу реального атакующего или продвинутого пользователя
- Меньше поддержки тестов при изменении внутреннего кода
Упражнение: Определите возможности для Grey-Box Testing
Вы тестируете веб-приложение для платформы доставки еды. Вам предоставлена архитектурная документация:
Архитектура системы:
- React frontend, взаимодействующий с REST API Gateway
- Микросервисы: Restaurant Service, Order Service, Delivery Service, Payment Service
- Базы данных PostgreSQL:
restaurants_db,orders_db,users_db - Redis cache для меню ресторанов и геолокации курьеров
- RabbitMQ для обновлений статуса заказов
- Stripe API для платежей, Google Maps API для маршрутов
Схема базы данных (частичная):
-- orders_db
orders (id, user_id, restaurant_id, status, total_amount, created_at)
order_items (id, order_id, menu_item_id, quantity, price)
delivery_assignments (id, order_id, driver_id, status, pickup_time, delivery_time)
Часть 1: Классифицируйте каждый сценарий как black-box, grey-box или white-box:
- Пользователь делает заказ и проверяет экран подтверждения
- После заказа запрос к
orders_dbдля проверки записей - Ревью кода Order Service для проверки алгоритма скидок
- Сделать заказ и проверить сообщение в RabbitMQ
- Тестировать поиск ресторанов, вводя ключевые слова
- Проверить обновление Redis при принятии заказа курьером
Часть 2: Спроектируйте 5 grey-box сценариев для потока заказа.
Часть 3: Команда заметила расхождения между суммами на экране и в БД. Опишите ваш подход к расследованию.
Подсказка
Для Части 1 ключевой фактор — какое знание использует тестировщик. Если только UI — black-box. Если архитектурное знание (БД, очередь, кэш) — grey-box. Если читает исходный код — white-box.Решение
Часть 1: Классификация
- Black-box — Тестировщик взаимодействует только с UI и проверяет видимый результат.
- Grey-box — Действие пользователя + проверка в базе данных.
- White-box — Прямой обзор исходного кода.
- Grey-box — Действие пользователя + проверка в очереди сообщений.
- Black-box — Только UI поиска и оценка видимых результатов.
- Grey-box — Действие курьера + проверка состояния кэша.
Часть 2: Grey-Box сценарии
Сценарий 1: Консистентность цен
- Действие: Добавить 3 позиции в корзину и оформить заказ
- Проверка: Запросить
order_itemsи сравнить цены сrestaurants_db - Обнаруживает: Расхождение из-за устаревшего кэша меню
Сценарий 2: Конкурентные заказы
- Действие: Два пользователя одновременно заказывают последний доступный товар
- Проверка: Проверить
orders_dbдля обоих заказов - Обнаруживает: Race condition с ограниченным остатком
Сценарий 3: Распространение статуса
- Действие: Сделать заказ, ресторан подтверждает
- Проверка: Проверить RabbitMQ и
delivery_assignments - Обнаруживает: Сбой очереди, когда UI показывает подтверждение, но служба доставки не уведомлена
Сценарий 4: Атомарность оплаты-заказа
- Действие: Оформить заказ (Stripe обрабатывает платёж)
- Проверка: Если списание в Stripe прошло, запись должна существовать в
orders_db - Обнаруживает: Частичный сбой — деньги списаны, но заказ не создан
Сценарий 5: Назначение курьера
- Действие: Сделать заказ в часы пик
- Проверка: Проверить
delivery_assignmentsи данные геолокации в Redis - Обнаруживает: Назначение по устаревшим данным местоположения из кэша
Часть 3: Подход к расследованию
- Воспроизвести и зафиксировать сумму на экране vs
orders.total_amount - Суммировать
quantity × priceизorder_itemsи сравнить сtotal_amount - Сравнить цены
order_itemsс текущими ценами вrestaurants_db - Проверить кэш Redis vs цены в БД
- Проверить применение скидок/промокодов
- Захватить payload API-запроса и сравнить с сохранённым значением
Наиболее вероятные причины: устаревший Redis-кэш цен, race condition между обновлением цен и оформлением заказа, или несогласованный расчёт скидок между frontend и backend.
Ключевые выводы
- Grey-box тестирование использует частичное знание системы для проектирования более качественных тестов, чем при чистом black-box
- Это естественный подход для интеграционного, API и тестирования безопасности
- Grey-box тестировщики проверяют не только внешнее поведение, но и внутреннюю целостность данных
- Подход комбинирует тестирование с позиции пользователя с внутренней верификацией системы
- Распространённые техники: матричное тестирование, тестирование паттернов и проверка состояния БД
- Обнаруживает баги, которые пропускает black-box, без необходимости полного доступа к исходному коду