Ответ
Gray box тестирование (тестирование «серого ящика») предполагает частичное знание внутренней структуры приложения. Используемые инструменты позволяют анализировать как внешнее поведение, так и внутренние данные.
1. Инструменты для работы с API и сетевым трафиком:
- Postman / Insomnia — для отправки запросов к API с проверкой статус-кодов, заголовков и структур тел ответов, о которых известно из документации или логики.
- Charles Proxy / Fiddler / Burp Suite — для:
- Перехвата и анализа HTTP/HTTPS трафика между клиентом и сервером.
- Модификации запросов и ответов «на лету».
- Проверки безопасности (например, с Burp Suite).
2. Инструменты для анализа клиентской части:
- Браузерные DevTools (Chrome, Firefox) — для:
- Отладки JavaScript.
- Анализа сетевых запросов (вкладка Network).
- Проверки манипуляций с DOM и CSS.
- Просмотра данных в Local Storage / Session Storage.
3. Инструменты для проверки данных:
- SQL-клиенты (DBeaver, DataGrip, pgAdmin) — для прямых запросов к базе данных с целью проверки корректности сохранения или изменения данных после выполнения тестовых сценариев.
4. Системы мониторинга и логирования:
- Kibana (ELK-стек), Grafana Loki, Splunk — для поиска и анализа логов приложения при возникновении ошибок, что помогает понять внутреннее состояние системы в момент сбоя.
Пример gray box теста на Python (проверка API и логики данных):
import requests
# Тестируем эндпоинт, зная, что он возвращает список пользователей
response = requests.get("https://api.example.com/users", params={"is_active": "true"})
assert response.status_code == 200
users = response.json()
# Проверяем бизнес-правило: все возвращенные пользователи должны быть активны
assert all(user["is_active"] for user in users), "Найдены неактивные пользователи!"Ответ 18+ 🔞
Ну, слушай, а вот gray box тестирование — это такая, блядь, золотая середина, понимаешь? Не слепой, как чёрный ящик, но и не вскрываешь кишки на операционном столе, как белый. Как будто смотришь на движок через запотевшее стекло — общие очертания видно, но детали расплываются. Идеально для того, чтобы не быть полным идиотом, но и не заебаться с изучением каждой строчки кода.
1. Чем будем тыкать в API и смотреть, что летит по проводам:
- Postman / Insomnia — ну, классика жанра, ебать мои старые костыли. Кидаешь запрос, зная примерно, что должно прилететь в ответ (документацию же читал, пидор?), и смотришь — совпадает или сервер тебе какую-то дичь втирает.
- Charles Proxy / Fiddler / Burp Suite — вот это уже серьёзные игрушки, ёпта. Сидишь себе, как паук, и ловишь весь трафик между приложением и сервером. А потом начинается магия: подменил запрос, посмотрел, как сервер обосрался; добавил лишний нолик в сумму — проверил, не проёбывается ли валидация. Burp — это вообще, блядь, тяжёлая артиллерия для параноиков, там можно дохуя чего по безопасности наковырять.
2. Чем ковырять фронтенд, который у пользователя в браузере:
- Браузерные DevTools (Chrome, Firefox) — о, это наш лучший друг, когда что-то на странице ебётся. Сеть смотрим (вкладка Network), чтобы понять, не хуйню ли нам бэкенд шлёт. В консоли дебажим скрипты, когда они ведут себя как пьяные мартышки. Залезаем в Local Storage — а не оставил ли наш скрипт там пароли на видном месте, дурак?
3. Чем лазить прямо в базу данных и тыкать в неё палкой:
- SQL-клиенты (DBeaver, DataGrip, pgAdmin) — а вот это, сука, самое интересное! Нажал кнопку в интерфейсе «Удалить аккаунт». А потом открыл базу и такой: «Ну-ка, ёбта, проверим... Ага, запись-то удалилась, но связанные заказы остались висеть сиротами! Пиздец, разработчики, нашли брешь!» Прямой доступ к данным — это волшебная таблетка от доверия к внешнему интерфейсу.
4. Куда смотреть, когда всё уже сломалось и в логах надо рыться:
- Kibana (ELK-стек), Grafana Loki, Splunk — представь, тест упал с ошибкой «500 Internal Server Error». А что там внутри произошло? Какой мудак-метод вызвал исключение? Лезишь в эти системы, ищешь по ID запроса или времени — и вот она, вся подноготная, блядь. Стек-трейс, переменные, состояние. Почти как читать мысли сервера, только легально.
Ну и примерчик, чтобы не быть голословным, на Python (проверяем API и логику):
import requests
# Тестируем эндпоинт, зная, что он возвращает список пользователей
response = requests.get("https://api.example.com/users", params={"is_active": "true"})
assert response.status_code == 200
users = response.json()
# Проверяем бизнес-правило: все возвращенные пользователи должны быть активны
assert all(user["is_active"] for user in users), "Найдены неактивные пользователи!"Вот смотри: мы знаем из логики (серый ящик же!), что параметр is_active=true должен фильтровать. Отправили запрос, получили список. А потом, блядь, проходимся по каждому юзеру и смотрим — а не втирают ли нам тут неактивного под видом активного? Если нашли — сразу кричим «Подстава!» и падаем с ассертом. Красота, ёперный театр!