Расскажи про уровни тестирования

Уровни тестирования — это классификация тестов по степени укрупнения тестируемого объекта: от отдельной функции до всей системы в целом. Эта классификация помогает распределить усилия: чем ниже уровень, тем больше должно быть тестов, и наоборот. Основной принцип: тест должен находиться на том же уровне, что и тестируемый объект, и не дублировать проверки, уже покрытые на более низких уровнях.

Как это работает

Уровни тестирования часто представляют в виде «пирамиды тестов» — метафоры, которая показывает не только иерархию, но и рекомендуемое количество тестов на каждом уровне. В основании пирамиды — много быстрых и дешёвых модульных тестов, выше — меньше интеграционных, ещё выше — системные, и на вершине — небольшое количество приёмочных тестов.

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

Уровни тестирования

1. Модульное тестирование (Unit / Component / Program / Module testing) — тестируется минимально-атомарный модуль программы, чаще всего одна функция или метод. Таких тестов должно быть больше всего, так как они самые быстрые и стабильные.
2. Интеграционное тестирование (Integration testing) — несколько модулей программы тестируются вместе, проверяется корректность их взаимодействия.
3. Системное тестирование (System testing) — вся программа тестируется полностью, как единое целое, проверяется соответствие функциональным и нефункциональным требованиям.
4. Приёмочное тестирование (Acceptance testing) — программа принимается заказчиком на соответствие заявленным требованиям, либо тестировщики проходят end-to-end сценарии с точки зрения пользователя.

Пример

Рассмотрим простой пример на Python: функция calculate_discount и её использование в приложении.

# Модульный тест: проверяем только функцию calculate_discount
def test_calculate_discount():
    assert calculate_discount(100, 10) == 90
    assert calculate_discount(100, 0) == 100
    assert calculate_discount(100, 100) == 0

# Интеграционный тест: проверяем, что функция корректно работает с БД
def test_order_total_with_discount():
    order = create_order(amount=100, discount=10)
    assert order.total == 90

# Системный тест: проверяем полный сценарий оформления заказа
def test_checkout_flow():
    # создаём заказ, применяем скидку, оплачиваем
    assert checkout() == "success"

В этом примере модульный тест покрывает все пограничные случаи функции, интеграционный проверяет связку с БД, а системный — весь процесс.

Подводные камни

• Дублирование тестов: если вы пишете на каждом уровне одинаковые проверки, это увеличивает время выполнения и стоимость поддержки. Следуйте принципу: каждый уровень тестирует только то, что относится к его зоне ответственности.
• Неправильное распределение количества: если модульных тестов меньше, чем системных, пирамида «переворачивается», что приводит к медленным и хрупким тестам.
• Игнорирование приёмочных тестов: без них нельзя гарантировать, что продукт соответствует ожиданиям заказчика, даже если все остальные тесты прошли.

Когда использовать

Пирамида тестов — это ориентир, а не строгое правило. Для небольших проектов можно ограничиться модульными и системными тестами, а для крупных — добавить интеграционные и приёмочные. Главное — помнить о цели: быстрая обратная связь и уверенность в качестве.

Коротко

• Уровни тестирования: модульный, интеграционный, системный, приёмочный.
• Чем ниже уровень, тем больше должно быть тестов.
• Тест должен быть на том же уровне, что и тестируемый объект, и не дублировать нижележащие проверки.
• Пирамида тестов — метафора для распределения количества тестов по уровням.