Что проверял в регрессии

Регрессионное тестирование: ключевые области проверки

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

1. Основные функциональные требования

• Работа ключевых пользовательских сценариев (Critical Paths): Все основные пути, которые пользователь использует для достижения цели (например: регистрация → добавление товара в корзину → оформление заказа → оплата).
• Функциональность, напрямую связанная с изменённым модулем: Если изменения касались модуля оплаты, я тщательно тестирую все связанные с ним процессы.
• Функциональность модулей, интегрированных с изменённым кодом: Тестирование "соседних" модулей, которые могут использовать API или данные изменённой части системы.

// Пример теста ключевого сценария в виде фрагмента кода (JUnit)
@Test
public void criticalPath_UserRegistrationAndPurchase() {
    // 1. Регистрация нового пользователя
    User newUser = userService.register("test@email.com", "password123");
    assertNotNull(newUser);
    assertTrue(newUser.isActive());

    // 2. Добавление товара в корзину
    Cart cart = cartService.addItemToCart(newUser.getId(), productId);
    assertEquals(1, cart.getItems().size());

    // 3. Оформление и оплата заказа
    Order order = orderService.createOrder(cart);
    PaymentResult payment = paymentService.processPayment(order.getId());
    assertEquals(PaymentStatus.SUCCESS, payment.getStatus());

    // 4. Проверка финального состояния
    assertTrue(order.isPaid());
    assertEquals(OrderStatus.DELIVERING, order.getStatus());
}

2. Интеграционные взаимодействия

• Работа API endpoints (REST, GraphQL): Проверяю, что все публичные и внутренние API продолжают возвращать корректные статусы (200 OK, 404 Not Found, etc.), данные и структуры JSON.
• Интеграция с внешними сервисами (платежные системы, email/SMS провайдеры, аналитика): Убеждаюсь, что изменения не сломали отправку запросов или обработку ответов.
• Взаимодействие между микросервисами или слоями приложения (Frontend ↔ Backend ↔ Database).

3. Бизнес-логика и данные

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

4. Нефункциональные требования (NFR)

• Performance (Производительность):

    *   **Не увеличилась ли нагрузка на систему** (CPU, Memory, I/O).
    *   **Не ухудшились ли ключевые метрики** (Time to First Byte - TTFB, Latency, Throughput).
    *   Проверяю, что изменения не сломали существующие **индексы** или **оптимизации запросов** в БД.

• Security (Безопасность):

    *   **Не появились новые векторы атаки** (инъекции, несанкционированный доступ).
    *   **Роли и права доступа (RBAC)** продолжают работать корректно.
    *   Проверяю **аутентификацию и авторизацию** на всех изменённых и связанных endpointах.

• Usability (Пользовательский опыт):

    *   **UI/UX изменения не сломали существующий интерфейс** (кнопки, формы, валидация).
    *   Проверяю, что **контент** (тексты, изображения) отображается корректно.
    *   Тестирую **кросс-браузерную и кросс-платформенную совместимость**, если изменения касались фронтенда.

# Пример быстрой проверки производительности API (используя requests)
import requests
import time

def test_api_response_time_regression():
    endpoint = "https://api.example.com/v1/products"
    
    # Базовый benchmark (замеряем до изменений)
    start_time = time.time()
    response = requests.get(endpoint)
    baseline_latency = time.time() - start_time
    
    # После изменений — повторный замер
    # Если latency увеличилась значительно (> 20%), это регрессия
    assert response.status_code == 200
    assert baseline_latency * 1.2 > time.time() - start_time, "Latency regression detected!"

5. Устойчивость и обработка ошибок (Robustness)

• Работа системы в граничных условиях и при ошибках: Проверяю, что изменения не сломали механизмы обработки исключений.
• Корректность ответов системы на некорректные данные или запросы (валидация).
• Состояние системы после сбоя (например, после падения транзакции в БД).

6. Совместимость (Compatibility)

• Backward compatibility (Обратная совместимость):

    *   Проверяю, что **новые версии API** не сломали клиентов, использующих **старые версии** (если это не было преднамеренным breaking change).
    *   Тестирую работу с **старыми форматами данных** или протоколами.

• Обновление и миграция данных: Если изменения включали миграцию БД, проверяю, что процесс прошёл успешно и данные доступны в новой схеме.

7. Автоматизированные сценарии и мониторинг

• Работа существующих автоматизированных тестов (CI/CD): Убеждаюсь, что изменения не сломали сами тесты или их окружение.
• Корректность логов и метрик мониторинга: Проверяю, что изменения не привели к "загрязнению" логов ложными ошибками или потере важных метрик.

Стратегия выбора тестов для регрессии

В реальных проектах полный регресс часто невозможен из-за временных ограничений. Поэтому я применяю risk-based подход, фокусируясь на:

• Функционал с самым высоким риском (финансы, данные пользователей).
• Модули, наиболее тесно связанные с изменениями (используя анализ зависимостей кода — impact analysis).
• Сценарии с самой высокой частотой использования (данные из analytics).
• Тесты, которые уже ломались ранее при похожих изменениях (история из базы знаний).

Регрессионное тестирование — это не просто "перетестирование всего", а целенаправленная и стратегическая проверка стабильности системы, которая защищает бизнес от незапланированных сбоев и деградации качества после каждого изменения.