Сценарии E2E#

Документ задает целевые end-to-end сценарии для poultry-кейсов на уровне бизнес-потока.

1. Scope#

  • Контур: poultry.broiler, poultry.layer.

  • Модули: climate, flock, feedwater, production, alarms.

  • Системные зависимости: status, modules, app/context, industry alarm-bus.

2. Общие предусловия#

  • Активная отрасль в контексте: poultry.

  • Площадка и птичник заведены (tenant_id, site_id, house_id).

  • Включены целевые poultry-модули на площадке (site-policy).

  • Создан и опубликован нормативный профиль poultry (минимум climate + alarms).

  • В тестовом стенде доступны симуляторы источников telemetry (климат, вода, корм).

3. Сценарий E2E-BR-01: полный цикл партии бройлера#

Цель: подтвердить корректность age/phase-driven управления микроклиматом и тревог.

Шаги:

  1. Создать batch для broiler и привязать age-фазы (day_1, day_7, day_21).

  2. Опубликовать профиль climate_profile с уставками по фазам.

  3. Подать telemetry в нормальном диапазоне для day_1.

  4. Переключить фазу до day_7 и проверить обновление целевых setpoint.

  5. Подать telemetry с критическим превышением температуры.

  6. Проверить создание события в poultry alarm-bus и bridge в status.

  7. Подтвердить обработку тревоги оператором и восстановление в норму.

  8. Проверить расчет KPI цикла (минимум: сохранность, feed conversion proxy).

Критерии приемки:

  • Фазовый переход меняет активные уставки без ручного патча профиля.

  • Критическое отклонение создает severity=critical и priority=P1.

  • В status появляется агрегированное событие с тем же correlation_id.

  • После нормализации формируется закрывающее/нормализующее событие.

4. Сценарий E2E-LY-01: продуктивность несушки#

Цель: подтвердить связку программ света/воды/корма с KPI продуктивности несушки.

Шаги:

  1. Создать batch типа layer и профиль световой программы.

  2. Подать baseline telemetry по климату, воде и корму.

  3. Записать производственные данные смены (яйценоскость, процент брака).

  4. Смоделировать снижение водопотребления ниже порога.

  5. Проверить генерацию тревоги high/medium (по policy) и создание задачи оператору.

  6. Выполнить корректирующее действие и повторно подать telemetry.

  7. Проверить восстановление KPI до целевого диапазона.

Критерии приемки:

  • KPI продуктивности рассчитываются на окне смены/суток.

  • Аномалия воды/корма вызывает тревогу по согласованному правилу.

  • Действия оператора отражаются в аудите и влияют на следующую оценку KPI.

5. Данные и фикстуры#

  • Базовые фикстуры:

    • tenant_id=tenant-e2e-poultry

    • site_id=site-e2e-01

    • house_id=house-a1

    • industry_code=poultry

  • Наборы данных:

    • telemetry_normal.json

    • telemetry_heat_stress.json

    • telemetry_feedwater_anomaly.json

    • production_shift_layer.json

6. Наблюдаемость и артефакты прогона#

  • Для каждого прогона сохранять:

    • логи запросов API (ключевые endpoint-ы);

    • снимки status/list и poultry alarm-list;

    • итоговый отчет KPI до/после инцидента;

    • таблицу step -> expected -> actual.

  • Минимальный отчет по сценарию:

    • scenario_id

    • run_started_at

    • result (pass|fail)

    • failed_step (если есть)

    • links на логи/артефакты.

7. Очередь автоматизации#

  1. Подготовить backend test-fixtures и deterministic seed для poultry.

  2. Добавить contract checks envelope/meta/error для poultry endpoint-ов.

  3. Собрать Playwright e2e flow:

    • smoke path для BR-01 (критичный инцидент + восстановление),

    • smoke path для LY-01 (продуктивность + аномалия).

  4. Подключить в CI как nightly poultry-e2e.