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

«Как было устроено тестирование на последнем проекте со стороны CI/CD?» — вопрос из категории CI/CD и DevOps, который задают на 24% собеседований AQA / Automation. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

На последнем проекте мы использовали GitLab CI для полной автоматизации тестирования. Pipeline был настроен по принципу «чем раньше найден баг, тем дешевле его исправить».

Структура pipeline выглядела так:

  1. Стадия lint (валидация кода):

    • Запускался flake8 для Python-кода приложения и самих автотестов.
    • При обнаружении критичных нарушений стиля сборка останавливалась.
  2. Стадия unit (модульные тесты):

    • Запускались быстрые юнит-тесты приложения (pytest).
    • Сборка падала, если покрытие падало ниже заданного порога (например, 80%).
      unit-test:
      stage: unit
      script:
      - pytest --cov=app --cov-fail-under=80 tests/unit/
      artifacts:
      reports:
        junit: report.xml
      paths:
        - coverage/
  3. Стадия api-test (интеграционное тестирование API):

    • Запускался набор API-тестов, написанных на pytest + requests, против развернутого на тестовом стенде приложения.
    • Для изоляции использовалась отдельная тестовая БД, которая наполнялась фикстурами перед прогоном.
  4. Стадия ui-test (UI-тестирование):

    • Запускались end-to-end тесты на Playwright в headless-режиме в Docker-контейнере.
    • Видеозапись прохождения тестов и скриншоты при падении сохранялись как артефакты для упрощения отладки.
  5. Стадия performance (тесты производительности):

    • Запускалась по расписанию (например, ночью) или вручную перед релизом.
    • Использовался k6 для нагрузочного тестирования ключевых сценариев.

Ключевые практики:

  • Параллельное выполнение: Стадии unit, api-test и ui-test запускались параллельно на разных раннерах для скорости.
  • Артефакты и отчеты: Все стадии генерировали JUnit-отчеты, которые агрегировались в GitLab UI. Для UI-тестов также генерировался Allure-отчет.
  • Уведомления: При падении любой стадии в корпоративный Slack приходило оповещение с ссылкой на упавший пайплайн.
  • Тегирование и ручной запуск: Критичные, но долгие тесты (например, полный регресс) можно было запустить вручную с тегом manual для определенных веток.