Урок 07 — White Box и Black Box тестирование

Название: White Box vs Black Box — тестирование изнутри и снаружи
Описание: Разбираем два фундаментальных подхода к тестированию: «чёрный ящик» (тестируем без знания кода) и «белый ящик» (тестируем с доступом к коду). Объясняем, когда применять каждый подход и как они дополняют друг друга.
Почему это важно для QA: Это базовая классификация методологий тестирования. Понимание этих подходов помогает выбрать правильную стратегию, писать более полные тест-кейсы и эффективно общаться с командой разработки.

1. Аналогия для понимания

Представь, что ты проверяешь кофемашину.

Black Box (Чёрный ящик):
Ты не знаешь, как она устроена внутри. Ты просто нажимаешь кнопки и смотришь, правильно ли варится кофе. Нажал «Эспрессо» — получил эспрессо. Это и есть тестирование «снаружи».

White Box (Белый ящик):
Ты открываешь машину, смотришь на все провода, трубки и механизмы. Проверяешь, что каждый узел работает правильно, что давление в нужном диапазоне, что вода нагревается до точной температуры. Это тестирование «изнутри».

Grey Box (Серый ящик):
Ты не разбираешь машину полностью, но у тебя есть схема: знаешь, что внутри есть помпа и нагревательный элемент. Тестируешь снаружи, но с пониманием внутреннего устройства.

2. Black Box Testing — «Чёрный ящик»

Black Box Testing — это тестирование без знания внутреннего устройства системы. Тестировщик знает только входные данные и ожидаемые выходные данные (требования).

Ключевые характеристики

• Тестировщик не видит код
• Фокус на поведении системы с точки зрения пользователя
• Основа — требования и спецификации
• Не нужны знания программирования

Что проверяем

ВХОД → [ЧЁРНЫЙ ЯЩИК] → ВЫХОД

Пример:
Ввод: email="user@test.com", password="Secret123"
Ожидание: пользователь авторизован, редирект на /dashboard

Преимущества Black Box

Недостатки Black Box

• Не знаем, какие части кода покрыты
• Могут быть непроверенные внутренние пути
• Сложно тестировать сложные алгоритмы

Когда применяем

• Приёмочное тестирование (UAT)
• Системное тестирование
• Регрессионное тестирование
• Тестирование API (проверяем входы/выходы)

Пример тест-кейсов (Black Box)

Тестируем поле «Возраст» при регистрации (допустим: 18–99 лет):

TC-001: Ввести возраст 25 → Ожидаем: принято, регистрация продолжается
TC-002: Ввести возраст 17 → Ожидаем: ошибка «Вам должно быть 18+»
TC-003: Ввести возраст 100 → Ожидаем: ошибка «Введите реальный возраст»
TC-004: Ввести текст "abc" → Ожидаем: ошибка «Введите число»
TC-005: Оставить поле пустым → Ожидаем: ошибка «Поле обязательно»

Мы не знаем, как система проверяет возраст — мы просто проверяем поведение.

3. White Box Testing — «Белый ящик»

White Box Testing — это тестирование с полным доступом к исходному коду. Тестировщик знает, как работает система изнутри, и проверяет конкретные пути выполнения кода.

Ключевые характеристики

• Тестировщик видит код
• Фокус на внутренней логике и структуре кода
• Нужны знания программирования
• Используется разработчиками и SDET-инженерами

Что проверяем

// Видим код функции calculateDiscount:
function calculateDiscount(price, userType) {
  if (userType === "premium") {
    return price * 0.8;   // ← ветка 1: скидка 20%
  } else if (price > 1000) {
    return price * 0.9;   // ← ветка 2: скидка 10% при сумме > 1000
  } else {
    return price;          // ← ветка 3: без скидки
  }
}

При White Box тестировании мы напишем тесты для каждой ветки кода.

Техники White Box тестирования

Преимущества White Box

Недостатки White Box

• Требует знания программирования
• Трудозатратно при большом кодовой базе
• Не выявляет отсутствующий функционал
• Тесты нужно обновлять при каждом рефакторинге

Пример тест-кейсов (White Box)

// Тестируем функцию calculateDiscount
// Ветка 1: premium user
test("должен вернуть скидку 20% для premium пользователя", () => {
  const result = calculateDiscount(1000, "premium");
  expect(result).toBe(800);
});

// Ветка 2: price > 1000, но не premium
test("должен вернуть скидку 10% при сумме > 1000", () => {
  const result = calculateDiscount(1500, "regular");
  expect(result).toBe(1350);
});

// Ветка 3: regular user, price <= 1000
test("должен вернуть полную цену без скидки", () => {
  const result = calculateDiscount(500, "regular");
  expect(result).toBe(500);
});

4. Grey Box Testing — «Серый ящик»

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

Когда применяется

• Тестирование API (знаем структуру запросов/ответов)
• Интеграционное тестирование
• Тестирование безопасности
• Большинство практической работы QA-автоматизаторов

Пример Grey Box

Знаем: API POST /api/users создаёт пользователя и записывает в таблицу users
Тест: отправляем запрос → проверяем ответ → проверяем запись в БД

Это не чистый Black Box (знаем про БД) 
и не чистый White Box (не видим код обработчика)

5. Сравнительная таблица

6. Как выглядит на реальном проекте

Возьмём функцию «Забыл пароль» в веб-приложении:

Black Box тесты (без знания кода):

• Ввести существующий email → получить письмо
• Ввести несуществующий email → сообщение «Если email зарегистрирован, письмо отправлено»
• Ввести невалидный email → сообщение об ошибке формата
• Использовать ссылку из письма → открыть форму смены пароля
• Использовать ссылку повторно (уже использованную) → ошибка «Ссылка недействительна»

White Box тесты (со знанием кода):

• Токен генерируется с помощью crypto.randomBytes(32)
• Токен сохраняется в БД с временем жизни 15 минут
• При использовании токен помечается как used = true
• Старые токены очищаются задачей cron каждый час

Grey Box тесты (знаем структуру API и БД):

• POST /api/auth/forgot-password → проверяем, что запись в password_resets создана
• Если время жизни токена истекло → проверяем 401 в ответе API

7. Частые вопросы на собеседовании

Q: Что лучше — Black Box или White Box?
A: Нет правильного ответа. Они дополняют друг друга. Black Box проверяет поведение с точки зрения пользователя, White Box обеспечивает полноту покрытия кода.

Q: Какой метод использует обычный QA-инженер?
A: В основном Grey Box: знает API-контракты, структуру БД, понимает общую архитектуру — но не читает весь исходный код.

Q: Может ли тестировщик без знания программирования делать White Box тестирование?
A: Нет. White Box требует чтения и понимания кода. Для этого нужен SDET или разработчик.

Итог

BLACK BOX  → тестируем поведение снаружи, как пользователь
WHITE BOX  → тестируем внутреннюю логику, видим код
GREY BOX   → гибрид: знаем часть структуры, тестируем системно

В реальной работе QA чаще всего работает в режиме Grey Box:
понимает архитектуру, знает API, но не читает каждую строку кода.