Что такое регрессивное тестирование

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

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

Программный продукт — это сложная система, где модули и компоненты связаны между собой. Одно исправление может затронуть участок кода, который используется другими функциями. Например, если в интернет-магазине исправить баг с изменением количества товара в корзине, это может сломать изменение цвета товара, если оба действия обращаются к одному и тому же методу или переменной. Такие непреднамеренные побочные эффекты называются регрессиями.

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

Пример

Рассмотрим простой пример на Python. Допустим, есть функция, которая рассчитывает стоимость заказа с учётом скидки:

def calculate_total(price, quantity, discount=0):
    subtotal = price * quantity
    return subtotal - (subtotal * discount / 100)

После исправления бага, связанного с округлением, код меняется:

def calculate_total(price, quantity, discount=0):
    subtotal = price * quantity
    return round(subtotal - (subtotal * discount / 100), 2)

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

Отличие от подтверждающего тестирования

Подтверждающее тестирование (или повторное тестирование) проверяет, что конкретный баг действительно исправлен. Регрессионное тестирование идёт дальше: оно проверяет, что исправление не нарушило работу других частей продукта. Например, если баг был в форме регистрации, подтверждающее тестирование проверит, что форма теперь отправляет данные, а регрессионное — что после исправления не сломалась, скажем, валидация пароля или восстановление пароля.

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

• Регрессионное тестирование может быть трудоёмким, особенно если выполняется вручную. Автоматизация помогает сократить время, но требует первоначальных затрат на написание и поддержку тестов.
• Необходимо тщательно выбирать набор регрессионных тестов: он должен покрывать критический функционал, но не быть избыточным, иначе время прогона растёт.
• Регрессии могут возникать не только после исправлений, но и после изменения конфигурации, обновления библиотек или операционной системы.

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

Регрессионное тестирование обязательно проводится:

• после каждого исправления дефекта;
• при добавлении нового функционала;
• перед релизом продукта;
• при интеграции с новыми версиями сторонних сервисов.

Коротко

• Регрессионное тестирование проверяет, что изменения в коде не сломали существующий функционал.
• Оно отличается от подтверждающего тестирования: последнее проверяет сам баг, а регрессионное — его побочные эффекты.
• Регрессии возникают из-за связанности кода: одно изменение может повлиять на другие части системы.
• Для эффективности регрессионное тестирование часто автоматизируют, но критично правильно выбрать набор тестов.