Перейти к основному содержимому

Стратегия автоматизированного тестирования

1. Цель​

Обеспечить раннее обнаружение дефектов и регрессий до поставки изменений в релиз.

2. Контур автоматических проверок​

В обязательный контур входят:

  1. BDD-сценарии.
  2. Дымовые тесты.
  3. Unit тесты.
  4. Синтаксический контроль.

Проверки запускаются на подготовленной и инициализированной тестовой ИБ. Правила подготовки данных описаны в отдельном регламенте Инициализация тестовой ИБ.

3. Назначение каждого уровня тестов​

BDD-сценарии​

Проверяют бизнес-сценарии и пользовательские цепочки действий.

Дымовые тесты​

Проверяют критический минимум работоспособности после обновления.

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

В минимальный набор рекомендуется включать:

  1. Тесты на открытие форм ключевых объектов.
  2. Тесты на создание и запись элементов (справочники, документы, другие прикладные объекты).
  3. Тесты на запуск критических отчетов и проверку отсутствия аварийных ошибок.

Unit-тесты​

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

Таймауты в тестах​

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

Допускается увеличивать таймаут только при выполнении всех условий:

  1. причина ожидания описана в тесте или настройке запуска;
  2. тест проверяет состояние в цикле с ограничением времени, а не выполняет фиксированную паузу;
  3. при превышении ожидания ошибка сообщает, какого состояния не удалось дождаться;
  4. увеличение таймаута не заменяет исправление медленного или нестабильного сценария.

Синтаксический контроль​

Обнаруживает технические дефекты сборки и кода на ранней стадии.

4. Требования к входу в автоматические тесты​

  1. База создана и загружена корректной конфигурацией.
  2. Выполнена загрузка необходимых расширений для тестового контура.
  3. Выполнена инициализация ИБ.
  4. Подготовлены настройки запуска (env.json, tools/runner-settings.json, tools/VAParams.json и связанные файлы).

5. Результаты и артефакты​

По итогам прогона должны сохраняться:

  1. Отчеты в формате jUnit.
  2. Отчеты Allure для сценарных проверок.
  3. Журналы исполнения шагов.
  4. При необходимости — архив тестовой ИБ для диагностики.

6. Правила повторной проверки​

  1. Любая правка по дефекту запускает повторный прогон затронутых тестов.
  2. Для критических исправлений выполняется повторный прогон полного обязательного контура.
  3. Результаты повторной проверки фиксируются в задаче и/или MR.

7. Критерии успешного автоматизированного тестирования​

  1. Обязательные этапы выполнены без критических падений.
  2. Отчеты и артефакты доступны для анализа.
  3. Неуспешные сценарии классифицированы: дефект, нестабильный тест или инфраструктурная ошибка.