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

Тестовая матрица

Цели​

  • Проверить, что management не меняет исходные доменные факты.
  • Проверить расчёт, хранение и показ метрик.
  • Проверить lifecycle dashboards, plans, tasks, alerts и data quality issues.
  • Проверить permissions для чувствительных метрик и drill-down.
  • Проверить устойчивость к задержкам, неполным данным и повторной доставке событий.

Unit tests​

Metrics​

  • создание metric требует owner, source domain, formula, grain и sensitivity;
  • изменение formula создаёт новую version;
  • deprecated metric нельзя добавить в новый dashboard без явного allow;
  • metric value валидирует period и segment;
  • sensitivity mapping требует правильного permission.

Plans​

  • draft -> review -> approved -> active -> closed;
  • cancel требует reason для active plan;
  • target с range требует rangeMin и rangeMax;
  • plan-fact правильно считает variance;
  • closed plan нельзя редактировать без reopen/amendment.

Tasks​

  • task status transitions;
  • done требует completedAt;
  • task без assignee не может перейти в in_progress;
  • duplicate deduplicationKey не создаёт вторую задачу;
  • комментарий к задаче пишет history/audit.

Alerts​

  • condition evaluation: gt, gte, lt, lte, eq, change_percent;
  • alert deduplication;
  • acknowledged/resolved lifecycle;
  • create task from alert only once;
  • dismissed critical alert требует reason.

Data quality​

  • failed ingestion создаёт issue;
  • partial ingestion помечает metric values как partial;
  • stale source создаёт warning;
  • resolved issue требует resolvedAt.

Integration tests​

Ingestion​

  1. Получить CRM payment events.
  2. Сохранить ingestion run.
  3. Рассчитать revenue metric.
  4. Создать metric value.
  5. Показать значение в dashboard.

Ожидание: повторная доставка тех же events не меняет значение дважды.

Dashboard​

  1. Создать metric.
  2. Создать dashboard.
  3. Добавить widget.
  4. Опубликовать dashboard.
  5. Получить dashboard пользователем с правом.

Ожидание: пользователь без права на financial metric не получает значение widget.

Plan-fact​

  1. Создать plan и target.
  2. Утвердить plan.
  3. Пересчитать metric value.
  4. Создать plan fact.
  5. Проверить status on_track или off_track.

Alert-to-task​

  1. Создать alert rule.
  2. Рассчитать metric value, нарушающий threshold.
  3. Создать alert.
  4. Создать task из alert.
  5. Повторить расчёт.

Ожидание: второй task не создаётся.

Drill-down​

  1. Пользователь открывает dashboard.
  2. Нажимает drill-down в CRM.
  3. Management проверяет локальные права.
  4. CRM проверяет свои права.

Ожидание: отсутствие CRM permission не раскрывает данные, даже если dashboard видим.

E2E scenarios​

Руководитель смотрит executive dashboard​

  • dashboard загружается;
  • KPI показывают freshness;
  • critical alerts видны;
  • export доступен только при permission;
  • drill-down работает с правами.

Product owner ведёт запуск​

  • создаёт plan;
  • добавляет targets;
  • связывает задачи;
  • видит plan-fact;
  • закрывает plan с итогами.

Operations lead закрывает риск​

  • видит alert;
  • создаёт task;
  • назначает исполнителя;
  • исполнитель переводит task в done;
  • alert закрывается вручную или автоматически.

Аналитик меняет формулу​

  • создаёт новую metric version;
  • запускает пересчёт;
  • видит recalculation run;
  • dashboard показывает значения с новой версией без потери истории.

Security tests​

  • пользователь без management.metrics.read_financial не видит financial widgets;
  • пользователь без management.metrics.read_personal не видит персональные сегменты;
  • пользователь с task read видит только задачи в своём scope;
  • dashboard visibility не раскрывает restricted metric;
  • export пишет audit и не содержит скрытые поля;
  • drill-down не обходит права исходного домена;
  • audit logs доступны только management.audit.read.

Data quality tests​

  • source unavailable создаёт issue и stale status;
  • schema mismatch не ломает весь dashboard;
  • partial data явно помечается в UI;
  • late event пересчитывает affected metric period;
  • изменение source contract требует review.

Regression checklist​

  • npm run docs:build для документации;
  • API contract snapshots;
  • permission matrix snapshots;
  • SQL migrations apply/rollback;
  • event payload schema validation;
  • e2e сценарии dashboards/plans/tasks/alerts.

Acceptance gates​

  • Все state transitions покрыты unit tests.
  • Все write endpoints проверяют permission и audit.
  • Все sensitive widgets имеют negative tests.
  • Все ingestion сценарии идемпотентны.
  • В UI есть состояния loading, empty, no access, stale и partial data.