Управление артефактами

Updated Jul 2026

Почему артефакты важны

Каждый запуск тестов должен создавать артефакты, помогающие диагностировать сбои без повторного запуска пайплайна. Когда браузерный тест падает в 2 часа ночи при ночном запуске, вы должны иметь возможность скачать трейс, скриншот и логи утром и точно понять, что произошло, — не запуская заново 20-минутный пайплайн.

Основные типы артефактов

Отчёты о тестировании

Отчёты о тестировании — основные артефакты. Они показывают, что прошло, что упало, и предоставляют детали по каждому сбою.

# Generate JUnit XML for CI platform integration
- run: npx playwright test --reporter=junit
  env:
    PLAYWRIGHT_JUNIT_OUTPUT_NAME: results.xml

# Generate HTML for human consumption
- run: npx playwright test --reporter=html

# Generate both
- run: npx playwright test --reporter=junit,html

Совет: настройте ваш тестовый фреймворк генерировать JUnit XML по умолчанию (для парсинга CI-платформой) и HTML-отчёты по запросу (для ручного исследования).

Скриншоты и видео

Сбои браузерных тестов практически невозможно диагностировать без визуальных доказательств. Настройте ваш тестовый фреймворк для захвата скриншотов при сбоях и опционально записи видео.

// playwright.config.ts
export default defineConfig({
  use: {
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'retain-on-failure',
  },
});

Трейсы Playwright особенно ценны. Трейс фиксирует таймлайн каждого действия, сетевого запроса, DOM-снимка и записи консоли. Вы можете открыть их в Trace Viewer и пошагово пройти выполнение теста, как в отладчике.

- uses: actions/upload-artifact@v4
  if: failure()
  with:
    name: playwright-traces
    path: test-results/
    retention-days: 14

Отчёты о покрытии

Отчёты о покрытии отслеживают, какие строки кода были задействованы во время тестирования. Они полезны для:

• Выявления непротестированных путей кода
• Отслеживания трендов покрытия со временем
• Проверки того, что новый код покрыт тестами

- run: npm run test:unit -- --coverage --coverageReporters=lcov --coverageReporters=text
- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: coverage-report
    path: coverage/

Важно: отслеживайте тренды покрытия, а не абсолютные числа. Порог покрытия в 80% бессмыслен, если непокрытые 20% содержат самую критичную бизнес-логику. Лучше: требуйте покрытия нового кода, а не достижения порога по всей кодовой базе.

Логи

Логи приложения из тестовых контейнеров, логи консоли браузера и сетевые HAR-файлы предоставляют контекст, который одни лишь отчёты о тестировании дать не могут.

# Capture Docker container logs
- name: Capture service logs
  if: failure()
  run: |
    docker logs test-db > postgres.log 2>&1
    docker logs test-app > application.log 2>&1

- uses: actions/upload-artifact@v4
  if: failure()
  with:
    name: service-logs
    path: |
      postgres.log
      application.log

HAR-файлы (сетевой трафик)

HAR-файлы (HTTP Archive) фиксируют каждый сетевой запрос и ответ во время теста. Они незаменимы для отладки сбоев тестов, связанных с API.

// Capture HAR file in Playwright
const context = await browser.newContext({
  recordHar: { path: 'test-results/network.har' }
});
// ... run tests ...
await context.close(); // HAR file is saved on close

Политики хранения

Артефакты потребляют хранилище. Установите политики хранения, балансирующие потребности отладки и затраты.

# GitHub Actions retention configuration
- uses: actions/upload-artifact@v4
  with:
    name: test-report
    path: test-results/
    retention-days: 14  # Override default (90 days)

Организация артефактов

Когда матричная стратегия создаёт несколько артефактов, называйте их понятно, чтобы вы могли найти нужный.

# Bad: generic names
name: test-results  # Which browser? Which shard?

# Good: descriptive names with matrix values
name: traces-${{ matrix.browser }}-${{ matrix.shard }}
# Produces: traces-chromium-1, traces-chromium-2, traces-firefox-1, etc.

Для многозадачных пайплайнов добавляйте префикс с именем задачи:

# Job: unit-tests
name: unit-coverage

# Job: integration-tests
name: integration-report

# Job: browser-tests
name: browser-traces-${{ matrix.browser }}

Потребление артефактов

В pull request

Большинство CI-платформ могут парсить JUnit XML и отображать результаты тестов прямо в PR:

• GitHub Actions: используйте action dorny/test-reporter для добавления результатов тестов как проверок PR
• GitLab CI: используйте artifacts:reports:junit для отображения результатов в виджете merge request
• Jenkins: плагин JUnit парсит XML и показывает результаты на странице сборки

# GitHub Actions: Show test results in PR
- uses: dorny/test-reporter@v1
  if: always()
  with:
    name: Playwright Tests
    path: results.xml
    reporter: java-junit

Скачивание для локальной отладки

# GitHub CLI: Download artifacts from a specific run
gh run download 12345678 -n playwright-traces

# Open Playwright traces locally
npx playwright show-trace test-results/trace.zip

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

Для анализа трендов отправляйте результаты тестов во внешнюю систему:

• Allure TestOps: агрегирует результаты по запускам и показывает тренды
• Grafana + InfluxDB: пользовательские дашборды для метрик тестирования
• TestRail / Zephyr: загрузка результатов через API для трассировки

Антипаттерны в управлении артефактами

Практическое упражнение

1. Настройте ваш тестовый фреймворк для создания JUnit XML, HTML-отчётов и скриншотов при сбоях
2. Добавьте шаги загрузки артефактов в пайплайн с соответствующими условиями if
3. Намеренно сломайте тест и скачайте артефакты для локальной отладки
4. Настройте политики хранения, различающиеся для успешных и неуспешных запусков
5. Настройте аннотации PR с помощью action для test reporter, чтобы сбои были видны без необходимости заходить в пайплайн