Какие знаешь типы Regression?

Типы регрессионного тестирования (Regression Testing)

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

Существует несколько классификаций типов регрессионного тестирования, основанных на стратегии отбора тестов, объёме проверок и времени выполнения. Вот основные типы:

1. По стратегии отбора тестов (Scope-Based)

• Полная регрессия (Full/Complete Regression):

    *   **Суть:** Выполняются **все существующие тесты** для всего приложения или его крупной части. Это самый надежный, но и самый ресурсоемкий метод.
    *   **Когда применять:** После крупных изменений в архитектуре, при смене ключевых библиотек или фреймворков, перед критичными релизами (например, мажорными версиями).
    *   **Пример сценария:** Компания мигрирует базу данных с MySQL на PostgreSQL. Необходимо убедиться, что все модули, от UI до отчетности, работают корректно с новой СУБД.

• Частичная/Выборочная регрессия (Partial/Selective Regression):

    *   **Суть:** Запускается **подмножество тестов**, отобранных на основе анализа рисков и изменений. Используются методы анализа воздействия (Impact Analysis) для определения затронутых модулей.
    *   **Когда применять:** Стандартная практика для большинства спринтов в Agile, когда изменения локализованы.
    *   **Пример отбора:** Исправлена ошибка в модуле "Корзина покупок". Анализ показывает, что изменения затронули классы `CartCalculator` и `DiscountApplier`. Запускаются:
        *   Все модульные тесты для этих классов.
        *   Интеграционные тесты API корзины.
        *   Критические end-to-end сценарии оформления заказа.

• Прогрессивная регрессия (Progressive Regression):

    *   **Суть:** При добавлении новой функциональности **создаются новые тесты**, а старые, если они не релевантны, могут быть модифицированы или удалены. Акцент на тестировании нового кода в контексте существующего.
    *   **Когда применять:** В проектах с быстро развивающейся кодовой базой, где некоторые старые сценарии теряют актуальность.

2. По времени и частоте выполнения

• Периодическая/Плановая регрессия (Scheduled Regression):

    *   Выполняется по расписанию (например, каждую ночь, в конце спринта). Часто автоматизирована и является частью CI/CD пайплайна.

• Регрессия по требованию (On-Demand Regression):

    *   Запускается вручную по решению команды после конкретного события (мерж большой feature-ветки, хотфикс в прод).

3. По уровню тестирования и автоматизации

• Юнит-регрессия (Unit Regression):

    *   Быстрая проверка на уровне отдельных функций/методов. Основа CI.

```java
// Пример: После рефакторинга метода нужно убедиться, что он всё ещё возвращает корректный результат.
@Test
public void testCalculateTotalWithDiscount() {
    Cart cart = new Cart();
    cart.addItem(new Item("Book", 50));
    cart.addItem(new Item("Pen", 10));
    double total = cart.calculateTotal(10); // 10% скидка
    assertEquals(54.0, total, 0.01); // (50+10)*0.9 = 54
}
```

• Функциональная регрессия (Functional Regression):

    *   Проверка бизнес-логики и пользовательских сценариев через API или UI.

```python
# Пример API-теста (pytest + requests)
def test_order_creation_after_payment_gateway_update():
    # После обновления библиотеки платежного шлюза проверяем ключевой сценарий
    order_data = {"items": [1, 2], "payment_method": "card"}
    response = requests.post(API_URL + "/orders", json=order_data)
    assert response.status_code == 201
    assert response.json()["status"] == "paid"
```

• Автоматизированная регрессия (Automated Regression):

    *   **Идеал современной разработки.** Набор автотестов (чаще всего в CI/CD), покрывающий критические пути, который запускается при каждом изменении кода. Позволяет быстро получать обратную связь.
    *   **Инструменты:** Selenium, Cypress, Playwright (для UI), Postman/Newman, REST Assured (для API), JUnit, pytest (для юнитов).

• Ручная регрессия (Manual Regression):

    *   Выполняется тестировщиком вручную. Применима для сложных сценариев, проверки UX/UI, или когда автоматизация экономически нецелесообразна. Часто используется вместе с автоматизацией в виде **санitary-проверок**.

4. Специализированные виды

• Регрессия исправления дефекта (Bug Fix Regression):

    *   Целенаправленная проверка исправленного бага и его окружения. Сначала проверяется, что баг устранен, затем — что исправление не сломало смежную функциональность.

• Конфигурационная регрессия (Configuration Regression):

    *   Проверка работы приложения при изменении конфигураций (ОС, версия браузера, разрешение экрана, настройки сервера).

Ключевой вывод для практики: Не существует одного "правильного" типа. Эффективная стратегия — это комбинация подходов. Например, можно использовать:

1. Автоматизированную выборочную регрессию в CI при каждом пулл-реквесте (быстрая обратная связь).
2. Полную автоматизированную регрессию каждую ночь на staging-окружении.
3. Целенаправленную ручную регрессию для проверки сложных пользовательских сценариев и UX перед релизом.

Выбор стратегии зависит от зрелости проекта, степени автоматизации, частоты релизов и приемлемого уровня риска.