Приведи пример тестирования методом серого ящика

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

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

Контекст примера: Веб-приложение для онлайн-банкинга

Рассмотрим модуль "Перевод средств между счетами". Тестировщику известно:

• Входы и выходы (черный ящик): интерфейс веб-формы (поля: сумма, счёт-отправитель, счёт-получатель) и сообщения об успехе/ошибке.
• Внутренняя структура (белый ящик): схема базы данных (таблицы accounts, transactions), бизнес-правила (проверка достаточности баланса, лимиты на перевод), взаимодействие через REST API между фронтендом и бэкендом.

Практический сценарий тестирования

Тест-кейс: Проверка корректности списания и зачисления средств с учётом бизнес-логики.

Предпосылки:

1. Счёт A (ID: 1001) имеет баланс 5000 у.е.
2. Счёт B (ID: 1002) имеет баланс CSA 1000 у.е.
3. Известно бизнес-правило: минимальная сумма перевода — 10 у.е., максимальная — 10000 у.е.

Шаги тестирования:

1. Через веб-интерфейс выполнить перевод 1500 у.е. со счёта A на счёт B.
2. Проверить сообщение об успешной операции в UI.
3. Используя знания о БД, выполнить прямой запрос для верификации данных.

-- Проверка балансов после транзакции
SELECT account_id, balance FROM accounts WHERE account_id IN (1001, 1002);

-- Проверка записи транзакции
SELECT * FROM transactions 
WHERE from_account_id = 1001 AND to_account_id = 1002 
ORDER BY created_at DESC LIMIT 1;

Ожидаемый результат:

• Баланс счёта A: 3500 у.е. (5000 - 1500)
• Баланс счёта B: 2500 у.е. (1000 + 1500)
• В таблице transactions создана запись с корректными суммой, счетами и статусом.

Преимущества подхода в этом примере:

• Обнаружение "пограничных" дефектов: Понимая правила лимитов, тестировщик может целенаправленно проверить граничные значения (перевод на 9.99, 10, 10000, 10000.01), включая проверку через API или БД, что повышает覆盖率.
• Эффективность и точность: Не требуется тратить время на исследование всех возможных путей в коде (как в white-box), но и нет слепого перебора входов (как в black-box). Тесты более целенаправленны.
• Проверка целостности данных: Прямая проверка в БД позволяет обнаружить расхождения, которые могут не отображаться в UI (например, если списание прошло, а зачисление — нет, что привело бы к потере денег).
• Тестирование интеграции: Зная о взаимодействии через API, можно сымитировать сбои на уровне сети или проверить валидацию данных на стороне сервера, отправив запрос с некорректным телом прямо в эндпоинт.

# Пример скрипта для проверки API-интерфейса перевода (имитация частичного знания)
import requests

api_url = "https://bank-api.example.com/transfer"
payload = {
    "from_account": 1001,
    "to_account": 1002,
    "amount": 1500,
    "currency": "USD"
}
headers = {"Authorization": "Bearer <token>"}

response = requests.post(api_url, json=payload, headers=headers)
print(f"Status Code: {response.status_code}")
print(f"Response Body: {response.json()}")

# Тестировщик знает структуру успешного ответа и возможные коды ошибок
assert response.status_code == 200
assert response.json()["status"] == "success"

Типичные техники серого ящика, применяемые в примере:

• Матрица решений: Протестировать комбинации условий (достаточный/недостаточный баланс, валидный/невалидный счёт, сумма в пределах/вне лимитов).
• Тестирование на основе моделей: Понимая диаграмму состояний перевода (инициирован → проверен → выполнен/отклонён), тестировать переходы между состояниями.
• Тестирование архитектуры: Проверить, как модуль перевода взаимодействует с модулями уведомлений (отправка чека) и журналирования (логирование операций).

Таким образом, тестирование серым ящиком в данном контексте позволяет не только проверить видимую функциональность, но и гарантировать целостность данных на уровне БД и корректность интеграции между компонентами, что существенно повышает надежность проверок по сравнению с чистым black-box подходом, оставаясь при этом менее затратным и требующим меньшей экспертизы, чем глубокий white-box анализ.