Как было устроено тестирование на последнем проекте со стороны CI/CD?

Организация тестирования в CI/CD на последнем проекте

На последнем проекте (крупный fintech-сервис) мы выстроили многоуровневую стратегию автоматизированного тестирования, полностью интегрированную в CI/CD пайплайн. Основная цель — обеспечить непрерывную обратную связь о качестве каждой сборки и минимизировать риски при деплое в production.

Архитектура CI/CD пайплайна

Мы использовали GitLab CI/CD с модульной конфигурацией, разделённой на стадии:

# .gitlab-ci.yml (упрощённая структура)
stages:
  - build
  - static-analysis
  - unit-tests
  - integration-tests
  - api-tests
  - ui-e2e-tests
  - performance-tests
  - deploy-staging
  - smoke-staging
  - deploy-production

Ключевые этапы тестирования в пайплайне

1. Статический анализ и юнит-тесты

• SonarQube для анализа кода на уязвимости и code smells
• Pytest (для Python-микросервисов) и JUnit (для Java-сервисов) выполнялись параллельно на этапе unit-tests
• Покрытие кода фиксировалось и сравнивалось с порогом (минимум 80% для критичных модулей)

# Пример конфигурации Pytest в GitLab CI
unit_tests:
  stage: unit-tests
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest --cov=app --cov-report=xml --junitxml=report.xml
  artifacts:
    reports:
      junit: report.xml
    paths:
      - coverage.xml

2. Интеграционные тесты

• Запускались в изолированном окружении с TestContainers для поднятия зависимостей (БД, message brokers)
• Проверяли взаимодействие между модулями внутри одного сервиса
• Выполнялись на этапе integration-tests с использованием тех же фреймворков, но с другими тестовыми наборами

3. API-тесты (ядро автоматизации)

• Использовали Python + Pytest + Requests для REST API и Kafka-python для тестирования асинхронных событий
• Автотесты делились на три категории:
  • Контрактные тесты (Pact) — проверка совместимости между сервисами
  • Функциональные тесты — проверка бизнес-логики
  • Нагрузочные тесты (на ранней стадии) — базовые сценарии с Locust
• Запускались на этапе api-tests против стенда, развёрнутого в Kubernetes

4. UI E2E-тесты

• Playwright для кросс-браузерного тестирования (Chrome, Firefox)
• Запускались на этапе ui-e2e-tests только для merge request в main ветку
• Использовали артефакты сборки для развёртывания временного окружения

// Пример конфигурации Playwright в CI
test: {
  retries: 1,
  workers: 3,
  timeout: 30000,
  reporter: [['html'], ['junit', { outputFile: 'results.xml' }]]
}

Стратегия запуска и оптимизации

1. Параллельное выполнение — независимые наборы тестов запускались параллельно в нескольких джобах
2. Кеширование зависимостей — ускорение сборки через кеш Docker-образов и виртуальных окружений
3. Сегментация тестов:
   • Smoke-тесты (3-5 мин) — запускались на каждый коммит
   • Регрессионные тесты (20-30 мин) — запускались ночью по расписанию
   • Полный прогон (2+ часа) — только перед релизом
4. Flaky-тесты мониторинг — автоматическое детектирование нестабильных тестов через анализ истории прогонов

Инфраструктура и мониторинг

• Все тесты выполнялись в Docker-контейнерах в Kubernetes кластере GitLab Runner
• Отчётность: Allure-отчёты генерировались после каждого прогона и публиковались как артефакты
• Интеграция с мониторингом: результаты тестов отправлялись в Prometheus + Grafana для отслеживания трендов
• Уведомления: автоматические алерты в Slack при падении критичных тестов

Подход к тестовым данным

• Использовали комбинацию подходов: Factory Boy для генерации, изолированные БД на каждый прогон, резервные копии для E2E
• Фикстуры Pytest для управления состоянием тестовых данных

Основные метрики и критерии прохода

• Критерий "зелёного" пайплайна: 100% прохождение smoke-тестов, 95%+ прохождение регрессии
• Performance-деградации: тесты падали при отклонении >15% по перцентилям p95/p99
• Quality Gates в SonarQube: отсутствие critical issues, coverage не ниже установленного порога

Такая организация позволяла обнаруживать 85%+ дефектов до попадания в staging, а среднее время feedback loop составляло 12-15 минут для типового MR.