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

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

Основные триггеры для запуска регрессионных тестов:

1. После исправления дефекта: Проверяется не только исправленный сценарий, но и связанная функциональность.
2. После добавления новой функциональности: Убеждаемся, что новая фича не сломала старые.
3. При слиянии веток (merge) в Git: Особенно важно при интеграции feature-веток в основную (main/develop).
4. После рефакторинга кода: Когда внутренняя структура меняется без изменения внешнего поведения.
5. Перед выпуском релиза (Release Candidate): Комплексная проверка стабильности всей системы.
6. После изменений в окружении: Обновление ОС, библиотек, серверов и т.д.

Практика:

• Автоматизация: Ключевые регрессионные тесты должны быть автоматизированы для частого и быстрого прогона.
• CI/CD: Регрессионные тесты интегрируются в пайплайн непрерывной интеграции (CI) и запускаются автоматически при каждом коммите или пулл-реквесте.

Пример сценария:

# Автоматизированный регрессионный тест для функции логина
def test_login_regression():
    # Проверяем, что базовый сценарий все еще работает
    assert login("valid_user@example.com", "SecurePass123!") == True
    # Проверяем, что старые баги не вернулись (регрессия)
    assert login("", "") == False  # Пустые поля
    assert login("user", "pass") == False  # Неверный пароль
    # Проверяем связанную функциональность (например, блокировка после N попыток)
    for _ in range(5):
        login("attacker", "wrong")
    assert login("valid_user@example.com", "SecurePass123!") == False  # Аккаунт должен быть временно заблокирован

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