Ответ
Различие основано на уровне знания внутреннего устройства тестируемой системы.
Тестирование "белого ящика" (White-box / Structural Testing)
Тестировщик имеет доступ к исходному коду и внутренней структуре. Тесты проектируются на основе анализа логики, путей выполнения и структуры кода.
- Цель: Проверить корректность внутренней логики, покрыть код (ветви, условия, пути).
- Кто выполняет: Разработчики, инженеры по автоматизации.
- Примеры: Модульное (unit), интеграционное тестирование, анализ покрытия кода.
Пример модульного теста (Python):
def calculate_discount(price, is_member):
if is_member and price > 100: # Ветвь 1
return price * 0.9
elif is_member: # Ветвь 2
return price * 0.95
else: # Ветвь 3
return price
# White-box тест, знающий о внутренних условиях
def test_calculate_discount():
# Проверяем все ветви логики
assert calculate_discount(150, True) == 135 # Ветвь 1
assert calculate_discount(50, True) == 47.5 # Ветвь 2
assert calculate_discount(100, False) == 100 # Ветвь 3Тестирование "черного ящика" (Black-box / Functional Testing)
Тестировщик не знает внутреннего устройства. Система рассматривается как "черный ящик", тесты строятся на основе спецификаций, требований и интерфейсов.
- Цель: Проверить соответствие функциональным требованиям, корректность работы с точки зрения пользователя.
- Кто выполняет: Тестировщики, аналитики.
- Примеры: Функциональное, приемочное (UAT), системное тестирование.
Пример теста "черного ящика" для API:
# Тестировщик знает только спецификацию API:
# "POST /api/login должен вернуть токен при корректных учетных данных"
POST /api/login HTTP/1.1
Content-Type: application/json
{"username": "test", "password": "secret"}
# Ожидаемый ответ (проверяется только выход):
HTTP/1.1 200 OK
{"token": "some_jwt_token"}
# Внутренняя реализация аутентификации (база данных, хэши) не известна.| Сводная таблица: | Критерий | Белый ящик | Черный ящик |
|---|---|---|---|
| Знание внутренностей | Да (код, архитектура) | Нет | |
| Уровень тестирования | Низкий (модули, интеграция) | Высокий (система, приемка) | |
| Критерии проектирования тестов | Покрытие кода, пути выполнения | Спецификации, требования, сценарии использования | |
| Основная сильная сторона | Нахождение логических ошибок, оптимизация кода | Проверка соответствия требованиям, пользовательского опыта |
Ответ 18+ 🔞
А, ну вот, опять про эти ваши ящики, блядь! Слушай, давай разберёмся, пока ты не начал путать белое с чёрным, как какой-нибудь дальтоник в тёмной комнате.
Представь себе, блядь, два подхода к разбору полётов твоего свеженаписанного говнокода.
Тестирование "белого ящика" (White-box)
Это когда ты, сука, залезаешь внутрь движка, как хирург-извращенец. У тебя есть доступ ко всему: к исходникам, к этим твоим кривым условиям if, к циклам, которые могут зациклиться нахуй. Ты смотришь на код и думаешь: "Ага, щас я тебя, мудень, проверю по всем веткам, чтобы ни одна else не осталась непротестированной, блядь!"
- Смысл: Убедиться, что внутренняя логика не ебёт мозг и работает как часы. Проверить ВСЕ пути, даже те, до которых пользователю, как до Луны.
- Кто этим страдает: Ты сам, разработчик, или твой коллега-автоматизатор, который тоже в теме.
- Примеры: Модульные тесты (unit), интеграционные — вся эта низкоуровневая движуха.
Вот, смотри, пример белого ящика на Python:
def calculate_discount(price, is_member):
if is_member and price > 100: # Ветвь 1
return price * 0.9
elif is_member: # Ветвь 2
return price * 0.95
else: # Ветвь 3
return price
# Белый ящик: мы ВИДИМ эти три ветки и долбим по каждой!
def test_calculate_discount():
assert calculate_discount(150, True) == 135 # Бьём по первой ветке
assert calculate_discount(50, True) == 47.5 # Ловим вторую
assert calculate_discount(100, False) == 100 # И добиваем третьюТестирование "чёрного ящика" (Black-box) А это уже, блядь, магия! Ты подходишь к системе как обычный юзер-лох. Ты не знаешь, что там внутри: база данных, микросервисы или гномы с молоточками. Ты знаешь только, что если тыкнуть сюда — должно высраться туда, согласно бумажке под названием "Требования".
- Смысл: Убедиться, что эта штука в принципе работает для пользователя, а не только для твоего продвинутого IDE.
- Кто этим занимается: Тестировщики, аналитики, иногда сами заказчики (и тогда начинается ад, блядь).
- Примеры: Функциональное тестирование, приемочное (UAT), когда заказчик говорит "ой, а можно вот так?".
Пример чёрного ящика для какого-нибудь API:
// Тестировщик видит только интерфейс: "Эй, API, прими логин и пароль, отдай токен!"
// А как ты там внутри пароль хэшируешь — ему похуй, это твои проблемы.
POST /api/login HTTP/1.1
Content-Type: application/json
{"username": "test", "password": "secret"}
// И он ждёт ЧЁТКО ЭТОТ ОТВЕТ:
HTTP/1.1 200 OK
{"token": "some_jwt_token"}
// Всё! Никаких подробностей про "белый ящик", только вход и выход.Короче, сводка для тех, кто в танке:
| Критерий | Белый ящик | Чёрный ящик |
|---|---|---|
| Видишь внутренности? | Да, как свои грязные носки. | Нет, как чужую жену в душе. |
| Уровень | Низкий, под капотом. | Высокий, с точки зрения юзверя. |
| От чего пляшем? | От кода, его веток и условий. | От требований, ТЗ и сценариев использования. |
| Сильная сторона | Найти логические косяки, проверить ВСЁ. | Убедиться, что фича в принципе работает как задумано. |
Вот и вся разница, ёпта. Один ковыряется в кишках, другой щупает снаружи. И оба, блядь, нужны, чтобы твой продукт не развалился на первом же юзере, который нажмёт не ту кнопку.