Какие есть виды тестирования по знанию системы?

Виды тестирования по уровню знания системы

Классификация тестирования по уровню знания внутреннего устройства системы (или по доступу к коду и архитектуре) является одной из фундаментальных в теории QA. Она делится на три основных метода, каждый из которых имеет свою стратегию, цели и место в процессе разработки. Правильное их комбинирование позволяет достичь высокой эффективности и покрытия тестами.

1. Тестирование «Чёрного ящика» (Black Box Testing)

Тестирование «Чёрного ящика» — это стратегия, при которой тестировщик анализирует функциональность системы БЕЗ знания её внутреннего устройства, структуры кода или реализации. Тестировщик воспринимает систему как «чёрный ящик», имея на входе требования и спецификации, а на выходе — наблюдаемое поведение.

• Основной принцип: Тесты основываются на функциональных и нефункциональных требованиях. Мы проверяем, ЧТО делает система, а не КАК она это делает.
• Ключевые техники проектирования тестов:

    *   **Эквивалентное Разделение (Equivalence Partitioning):** Входные данные разбиваются на классы (валидные/невалидные), и тестируется по одному значению из каждого класса.
    *   **Анализ Граничных Значений (Boundary Value Analysis):** Тестирование на границах этих классов (минимум, максимум, чуть больше/меньше).
    *   **Таблица Решений (Decision Table):** Для логик, зависящих от комбинации условий.
    *   **Тестирование Переходов Состояний (State Transition Testing):** Для систем с конечным числом состояний (например, авторизация).
    *   **Сценарии использования (Use Case Testing):** Тестирование с точки зрения конечного пользователя.

• Преимущества:

    *   Тестирование проводится с позиции пользователя.
    *   Не требует глубоких знаний программирования.
    *   Тест-кейсы могут быть разработаны параллельно с написанием кода, сразу после готовности спецификаций.

• Недостатки:

    *   Возможно недостаточное покрытие кода (неизвестно, какие части кода остались непроверенными).
    *   Сложно найти причины обнаруженных дефектов.

• Пример (проверка поля ввода «Возраст» на форме):

  # Тест-кейс, основанный на техниках "Чёрного ящика"
  Сценарий: Валидация поля "Возраст"
    Дано: Пользователь находится на странице регистрации
    Когда: Он вводит значение "5" в поле "Возраст"
    Тогда: Отображается сообщение об ошибке "Возраст должен быть от 18 лет"
    И: Кнопка "Отправить" неактивна
  

    Здесь мы не знаем, какая функция на бэкенде (например, `validateAge()`) обрабатывает это поле и как она реализована. Мы проверяем только наблюдаемый результат.

2. Тестирование «Белого ящика» (White Box Testing) / Структурное тестирование

Тестирование «Белого ящика» — это противоположный подход, при котором тестировщик (чаще разработчик или инженер по автоматизации) имеет ПОЛНЫЙ ДОСТУП к исходному коду, знает алгоритмы, структуры данных и внутреннюю архитектуру. Тесты проектируются на основе этой информации.

• Основной принцип: Проверка внутренней логики работы приложения, качества кода и достижение определённого уровня покрытия кода (Code Coverage).
• Ключевые метрики покрытия:

    *   **Покрытие операторов (Statement Coverage):** Был ли выполнен каждый оператор кода?
    *   **Покрытие ветвей/решений (Branch/Decision Coverage):** Были ли протестированы все возможные результаты логических условий (true/false)?
    *   **Покрытие условий (Condition Coverage):** Были ли протестированы все элементарные условия внутри сложных логических выражений?

• Преимущества:

    *   Возможность найти скрытые ошибки, связанные с обработкой специфических путей выполнения.
    *   Помогает оптимизировать код.
    *   Позволяет точно измерить, какая часть кода протестирована.

• Недостатки:

    *   Требует высокого уровня квалификации и знания кодовой базы.
    *   Может быть очень затратным по времени.
    *   Не гарантирует, что система соответствует требованиям пользователя.

• Пример (проверка внутренней функции):

  # Функция для расчета скидки (код, который мы знаем и тестируем)
  def calculate_discount(amount, is_premium_user):
      discount = 0
      if amount > 1000:
          discount += 10
      if is_premium_user:
          discount += 5
      return discount
  
  # Юнит-тест ("Белый ящик") для проверки всех ветвей кода
  def test_calculate_discount():
      # Тест 1: amount > 1000 и is_premium_user = True (покрываем обе ветви 'if')
      assert calculate_discount(1500, True) == 15
      # Тест 2: amount <= 1000 и is_premium_user = False (покрываем обе ветви 'if' как false)
      assert calculate_discount(500, False) == 0
      # Тест 3: Покрываем комбинацию amount > 1000, но обычный пользователь
      assert calculate_discount(1500, False) == 10
      # Тест 4: Покрываем комбинацию amount <= 1000, но премиум-пользователь
      assert calculate_discount(500, True) == 5
  

    Здесь тесты написаны с полным знанием внутренней логики функции `calculate_discount`.

3. Тестирование «Серого ящика» (Gray Box Testing)

Тестирование «Серого ящика» — это гибридный подход, сочетающий элементы двух предыдущих. Тестировщик имеет ЧАСТИЧНОЕ знание внутренней структуры (например, знает архитектуру базы данных, API-эндпоинты или общую диаграмму компонентов), но тестирует на уровне функциональности, как при «Чёрном ящике».

• Основной принцип: Использование ограниченных знаний о внутреннем устройстве для более эффективного и целенаправленного проектирования тестов, особенно интеграционных.
• Типичное применение:

    *   **Интеграционное тестирование** (например, знаем, как модуль А взаимодействует с БД, и проверяем результат этого взаимодействия).
    *   **Тестирование безопасности** (знаем уязвимые места архитектуры).
    *   **Тестирование веб-сервисов и API.**

• Преимущества:

    *   Объединяет преимущества пользовательского подхода («Чёрный ящик») и возможности глубокой проверки («Белый ящик»).
    *   Позволяет создавать более комплексные и точные тест-кейсы.
    *   Эффективно для нахождения проблем, связанных с неправильным использованием компонентов.

• Пример (тестирование API с знанием его контракта):

  // Тестировщик знает структуру ответа API (серый ящик) и использует это для валидации
  // Известно, что эндпоинт GET /api/users/{id} возвращает JSON с полями id, name, email.
  
  const userId = 123;
  const response = await fetch(`https://api.example.com/users/${userId}`);
  
  // Проверка функциональности (чёрный ящик): статус код 200
  assert(response.status === 200);
  
  const userData = await response.json();
  
  // Проверка структуры ответа на основе известной спецификации API (серый ящик)
  assert(userData.hasOwnProperty('id'));
  assert(userData.hasOwnProperty('name'));
  assert(userData.hasOwnProperty('email'));
  assert(typeof userData.id === 'number');
  assert(typeof userData.name === 'string');
  // ... и т.д.
  

    Здесь мы не знаем код функции, обрабатывающей запрос на сервере, но знаем контракт API (формат запроса и ожидаемого ответа), что позволяет делать более умные проверки.

Заключение

На практике эффективная стратегия тестирования всегда включает комбинацию этих подходов. Unit-тестирование — это почти всегда «Белый ящик». Системное и приемочное тестирование (UAT) — классический «Чёрный ящик». Интеграционное тестирование, тестирование безопасности и производительности часто проводятся по методологии «Серого ящика». Понимание различий и сильных сторон каждого подхода позволяет QA-инженеру выбирать правильные инструменты и техники для каждой задачи, обеспечивая максимальное качество продукта.