测试效能度量：DORA 四指标、逃逸缺陷率与测试 ROI 的完整度量体系

度量的三种正当用途：
  诊断（哪里是瓶颈？）、验证（改动有没有效果？）、
  沟通（向管理层说明质量投入的价值）

度量的三种危险用途：
  考核（用指标发奖金 → 立刻被博弈）、排名（横向对比 → 数据造假）、
  表演（为报表好看而优化数字 → 与真实质量脱钩）

Goodhart 定律："当一个度量指标成为目标，它就不再是好的度量指标。"

DORA 的核心洞察（来自 Accelerate 研究）：
  这四个指标不是权衡关系，而是正相关——
  高效能团队四项都优秀，低效能团队四项都差。

  关键结论：速度与稳定不是取舍。
  真正拉开差距的是"小批量、频繁交付、自动化验证"。

测试在这四个指标中的位置：
  · LT  ← 测试反馈速度直接决定提交到可发布的时长
  · CFR ← 测试有效性直接决定变更失败率
  · MTTR ← 测试（尤其是回滚演练）影响恢复速度
  · DF  ← 测试足够快足够可信，才敢高频部署

# 部署事件采集（GitHub Actions → 事件流）
- name: 上报部署事件
  if: github.ref == 'refs/heads/main'
  run: |
    curl -X POST "$METRICS_ENDPOINT/deployments" -H 'Content-Type: application/json' -d '{
      "service": "payment-api",
      "version": "${{ github.sha }}",
      "deployed_at": "'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'",
      "commit_at": "'"$(git log -1 --format=%cI ${{ github.sha }})"'",
      "status": "success",
      "deployer": "${{ github.actor }}"
    }'

-- 从事件表计算 DORA 四指标（按周聚合）
WITH deploys AS (
  SELECT service, deployed_at, commit_at, status,
         EXTRACT(EPOCH FROM (deployed_at - commit_at)) / 3600 AS lead_hours
  FROM deployment_events
  WHERE deployed_at >= now() - interval '7 days'
)
SELECT
  service,
  count(*)                                              AS deploy_frequency,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY lead_hours) AS lead_time_p50_hours,
  avg(CASE WHEN status <> 'success' THEN 1.0 ELSE 0 END) * 100 AS change_failure_rate_pct
FROM deploys
GROUP BY service;

假设：测试反馈时间（CI 时长）是变更前置时间的关键构成

  提交 → CI 通过 → 部署到生产
       └─ 这一段通常占 LT 的 40%~70%

  因此：把 CI 从 40 分钟压到 8 分钟，LT 直接缩短半小时以上。
  这也解释了为什么"测试慢"是交付能力的头号瓶颈。

反过来说：
  CFR 高 → 通常是测试有效性不足（逃逸缺陷多）
  MTTR 长 → 通常是回滚能力与可观测性不足（而非测试数量不足）

定义：逃逸缺陷率 = 生产环境发现的缺陷数 / 缺陷总数
      （缺陷总数 = 各阶段发现的缺陷之和）

为什么它是最好的质量指标：
  · 直接反映"测试有没有挡住问题"
  · 无法通过"多写测试"来优化（只能通过"写对测试"）
  · 与用户感知直接相关

按检出阶段拆解（缺陷检出阶段分布）：
  编码阶段（IDE/本地）     → 最便宜
  静态扫描（CI）           → 便宜
  单元测试                 → 便宜
  集成测试                 → 中等
  端到端 / 预生产          → 较贵
  生产环境                 → 最贵（用户受影响）

健康团队的典型分布（左移成功）：
  60% 在编码与静态扫描阶段发现
  25% 在单元与集成测试阶段发现
  10% 在 E2E / 预生产发现
  5%  逃逸到生产

-- 逃逸缺陷归因：这些缺陷本应被哪个阶段拦住？
SELECT d.root_cause_area,
       count(*)                                               AS escaped_count,
       count(*) FILTER (WHERE d.severity IN ('critical','high')) AS severe_count,
       round(avg(EXTRACT(EPOCH FROM (d.detected_at - e.introduced_at)) / 86400), 1)
                                                              AS avg_escape_days
FROM defects d
JOIN defect_intro e ON e.defect_id = d.id
WHERE d.detected_phase = 'production'
  AND d.detected_at >= now() - interval '30 days'
GROUP BY d.root_cause_area
ORDER BY severe_count DESC;

-- 解读：某模块逃逸多 → 该模块测试策略有洞（缺集成/契约测试？）
--       avg_escape_days 大 → 反馈周期长，缺陷潜伏久

测试 ROI = (测试避免的损失 - 测试的总成本) / 测试的总成本

测试的总成本：
  · 编写成本：写用例的工时
  · 运行成本：CI 机器时长 + 云资源
  · 维护成本：用例随产品演进而更新的工时（往往被低估）
  · 机会成本：CI 阻塞导致的等待时间

测试避免的损失：
  · 生产事故的修复成本（人力 + 停机损失）
  · 事故的声誉与客户流失成本
  · 缺陷越晚发现成本越高的放大系数（1x → 100x）

关键陷阱：
  维护成本通常占总成本的 50%~70%，
  只算"编写成本"会让 ROI 严重虚高。

# tools/test_roi.py —— 用例级 ROI 分析，识别高价值与僵尸用例
from dataclasses import dataclass
from datetime import datetime, timedelta

@dataclass
class TestStat:
    test_id: str
    last_failed_at: datetime | None    # 上次失败时间
    run_count_90d: int                 # 近 90 天运行次数
    avg_duration_sec: float            # 平均耗时
    flaky_rate: float                  # flaky 比例
    defects_caught: int                # 历史捕获的缺陷数

def maintenance_cost(t: TestStat) -> float:
    """粗估维护成本：运行时长 + flaky 造成的排查成本"""
    run_cost = t.run_count_90d * t.avg_duration_sec / 60      # 分钟
    flaky_cost = t.flaky_rate * t.run_count_90d * 15          # 每次排查 15 分钟
    return run_cost + flaky_cost

def classify(t: TestStat) -> str:
    """把用例分为四象限"""
    never_failed = (t.last_failed_at is None or
                    t.last_failed_at < datetime.now() - timedelta(days=180))
    high_cost = maintenance_cost(t) > 120   # 季度维护成本 > 2 小时
    if never_failed and high_cost:
        return "僵尸用例"        # 180 天没失败过 + 维护成本高 → 候选删除
    if never_failed:
        return "低价值但便宜"    # 保留，成本可忽略
    if t.defects_caught >= 3:
        return "高价值"          # 捕获过多次缺陷 → 重点保护
    return "常规"

def report(stats: list[TestStat]) -> dict[str, list[str]]:
    buckets: dict[str, list[str]] = {}
    for t in stats:
        buckets.setdefault(classify(t), []).append(t.test_id)
    return buckets

# CI 成本度量（按流水线阶段拆解）
sum(ci_job_duration_seconds_total{stage="unit"})      # 单元测试总耗时
sum(ci_job_duration_seconds_total{stage="e2e"})       # E2E 总耗时
sum(ci_runner_minutes_total) * 0.008                  # 估算成本（美元）
sum(ci_queue_wait_seconds_total)                      # 排队等待（机会成本）

# 关键派生指标
#   e2e_cost_share = e2e 成本 / 总 CI 成本
#     → 若 E2E 占 70% 成本却只覆盖 10% 场景 → 结构失衡

             高维护成本            低维护成本
经常失败     需重构/拆分（太慢太复杂）  高价值，保留（便宜且有效）
（有检出）
从不失败     僵尸候选（删除或合并）      便宜，可保留（不必优化）
（无检出）

注意：从不失败 ≠ 无用。有些用例是"防回归"的，永远不失败正说明它
工作正常。判定僵尸用例要看"代码是否还在变化"+"是否真的无检出价值"，
最可靠的验证手段是故意注入缺陷（突变）看它是否变红。

# 对某模块做突变测试，检出率低的模块说明用例无效
npx stryker run --mutate "src/order/**/*.ts" --reporters html,json

# 关键输出解读：
#   mutation score = 被杀死的突变 / 总突变
#     > 80%  → 用例有效
#     50~80% → 用例存在但断言不足
#     < 50%  → 覆盖率可能虚高（有执行无断言）

识别条件（需同时满足）：
  1. 180 天内从未失败
  2. 所覆盖的代码在这 180 天内被修改过至少 3 次
  3. 维护成本（耗时 + flaky 排查）高于阈值

处置流程（不可直接删）：
  Step 1  先做突变测试：对该用例覆盖的代码注入突变
  Step 2  若突变未被检出 → 说明用例断言不足，先补断言
  Step 3  若补齐后仍无检出价值 → 标记为候选删除
  Step 4  删除前跑一次全量，确认无其它用例依赖其副作用
  Step 5  删除并在 PR 中说明理由，保留可追溯记录

原则一：趋势优于绝对值 —— 不看"覆盖率 85%"，看"近 12 周覆盖率与
  逃逸率的走势"；单点数字无意义，趋势才能暴露问题

原则二：成对呈现 —— 覆盖率 + 突变检出率（防"有执行无断言"）；
  回归时长 + 逃逸缺陷率（防"砍用例换速度"）；
  部署频率 + 变更失败率（防"为快牺牲稳"）

原则三：可下钻到行动 —— 看到"E2E 失败率高"能下钻到"哪 10 个用例
  贡献了 60% 的失败"，直接指向行动

原则四：不做个人排名 —— 只做团队/服务维度，一旦排名数据必然失真

# 每日聚合任务：把原始事件汇总为看板数据
name: Metrics Rollup
on:
  schedule:
    - cron: '0 1 * * *'     # 每日凌晨 1 点

jobs:
  rollup:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 计算 DORA 四指标
        run: python tools/metrics/dora.py --window 7d --out metrics/dora.json
      - name: 计算逃逸缺陷率与阶段分布
        run: python tools/metrics/escaped.py --window 30d --out metrics/escaped.json
      - name: 计算用例有效性
        run: python tools/metrics/test_effectiveness.py --out metrics/effectiveness.json
      - name: 推送至看板
        run: |
          curl -X POST "$DASHBOARD_API/ingest" \
            -H 'Content-Type: application/json' \
            -d @metrics/combined.json

纪律一：先定义口径，再采集数据
  什么算"缺陷"？什么算"逃逸"？什么算"flaky"？
  口径不一致的数据无法横向比较。

纪律二：指标与激励解耦
  指标用于诊断与改进，绝不直接挂钩绩效。

纪律三：每个指标配一个"反指标"
  想优化 X，就必须同时监控"优化 X 会不会伤害 Y"。

纪律四：定期审视指标本身
  每季度问：这个指标还在引导正确的行为吗？
  过期的指标要从看板移除，否则会持续误导。

纪律五：数据透明但解读权在团队
  数据对所有人可见，但结论由最了解上下文的团队做出。