回归用例选择与优先级：影响分析 TIA、测试最小化与风险驱动回归

压力一：时间成本
  1000 个 E2E 用例 × 8s = 2.2 小时；每天 50 个 PR → 要么排队
  （反馈延迟到天级），要么并行（需要 50 倍机器，成本爆炸）

压力二：信噪比下降
  用例越多 flaky 越多 → "红是常态" → 工程师忽略红色 → 门禁失效

压力三：维护成本
  每改一次 UI，几十个用例需同步更新，时间超过写新功能

关键洞察：回归测试的价值不来自"数量"，而来自"覆盖变更影响面的精准度"。

三者关系：
  选择（Selection）：从"可能受影响的"里挑 → 缩小范围
  最小化（Minimization）：从"能覆盖目标的"里挑最少的 → 去冗余
  排序（Prioritization）：给留下来的排个序 → 早失败早反馈

组合使用：
  全量 1000 个
    → 选择（TIA）：变更影响 120 个
    → 最小化：去冗余后 80 个
    → 排序：高风险 30 个先跑，5 分钟内给出第一波反馈
    → 剩余 50 个继续跑，总耗时从 2.2h 降到 12min

PR 门禁（快速反馈）  → 选择 + 排序（必须快）
夜间构建（深度覆盖）  → 全量 + 最小化（去掉冗余，省资源）
发版前（最高保障）    → 全量（不选择、不最小化，宁可慢）
主干合并后            → 选择 + 最小化 + 排序（平衡）

信号一：静态依赖（Static Dependency）
  从代码结构推导：改了 A 文件 → 哪些文件 import 了 A（传递闭包）
  优点：无需运行历史，冷启动可用
  缺点：动态语言/反射/依赖注入会漏；覆盖过宽

信号二：动态覆盖（Dynamic Coverage）
  用上一次运行的覆盖数据：某用例上次覆盖了 A → 本次改 A 要跑它
  优点：精准，反映真实执行路径
  缺点：需要上次的覆盖数据；新用例无历史

信号三：历史关联（Historical Association）
  从历史记录挖掘：改了 A 之后，历史上哪些用例失败过
  优点：能捕捉非代码耦合（配置、数据、时序）
  缺点：需要足够历史；新变更无记录

生产实践：三者加权融合，而非只用一个。

1. 计算变更集：git diff --name-only <base>...<head> → 变更文件列表
   进一步解析 AST，定位变更的函数/类（方法级粒度）
2. 展开影响面：静态（反向依赖闭包）+ 动态（谁覆盖了变更函数）
   + 历史（谁曾因这些文件变更而失败）三路信号
3. 映射到用例：受影响代码 → 覆盖它的测试用例集合
4. 合并去重：三路信号取并集 → 得到候选用例集
5. 兜底策略：配置/依赖升级等无法分析时回退全量；
   涉及公共库/核心模块时提高兜底比例

# tools/tia.py —— 基于覆盖数据的影响分析选择器
import json, subprocess, pathlib
from collections import defaultdict

COVERAGE_DB = pathlib.Path(".coverage-map.json")

def collect_coverage(test_ids: list[str]) -> dict[str, set[str]]:
    """运行指定测试并记录每个用例覆盖的文件集合。"""
    subprocess.run(["pytest", "--cov=src", "--cov-context=test",
                    "--cov-report=json:coverage.json", *test_ids], check=True)
    data = json.loads(pathlib.Path("coverage.json").read_text())
    mapping: dict[str, set[str]] = defaultdict(set)
    for file, info in data["files"].items():
        for ctx in info.get("contexts", {}):
            if ctx.startswith("test::"):
                mapping[ctx].add(file)
    return mapping

def changed_files(base: str = "origin/main") -> set[str]:
    out = subprocess.check_output(
        ["git", "diff", "--name-only", f"{base}...HEAD"], text=True)
    return {f"src/{p}" for p in out.splitlines() if p.startswith("src/")}

def select_tests() -> list[str]:
    mapping = json.loads(COVERAGE_DB.read_text())
    changed = changed_files()
    # 兜底：核心模块变更时回退全量
    if any(f.startswith("src/core/") for f in changed):
        return ["<ALL>"]
    return sorted(t for t, files in mapping.items() if set(files) & changed)

方式一：从 CI 覆盖率报告自动构建（推荐）
  每次 CI 运行产出 coverage.xml / lcov.info
  解析后写入 coverage-map 表：test_id ↔ file/function
  增量更新：每次运行合并覆盖信息

方式二：从测试注解声明
  # @covers OrderService::create
  def test_create_order(): ...
  优点：显式、可读；缺点：需人工维护，易过期

方式三：从历史失败记录挖掘
  SELECT test_id, code_area FROM test_failures
  WHERE commit_sha IN (...changed areas...)
  优点：捕捉非代码耦合；缺点：需要历史积累

-- 覆盖映射表：谁覆盖了什么
CREATE TABLE test_coverage_map (
  test_id      TEXT NOT NULL,
  source_file  TEXT NOT NULL,
  symbol       TEXT,              -- 函数/方法名，NULL 表示文件级
  last_seen_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (test_id, source_file, symbol)
);
CREATE INDEX idx_cov_by_file ON test_coverage_map (source_file);

-- 历史失败关联表：谁曾经因为什么而失败
CREATE TABLE test_failure_history (
  test_id     TEXT NOT NULL,
  commit_sha  TEXT NOT NULL,
  changed_files TEXT[] NOT NULL,
  failed_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_fail_files ON test_failure_history USING GIN (changed_files);

-- 查询：改了 src/order.py 应该跑哪些用例
SELECT DISTINCT test_id FROM test_coverage_map WHERE source_file = 'src/order.py';

风险分 = 变更相关性 × 业务关键度 × 历史失败率 × 执行成本倒数

  变更相关性（0~1）  该用例覆盖的代码与本次变更的重合度
  业务关键度（1~5）  该用例覆盖功能对业务的重要程度（人工标注/收入关联）
  历史失败率（0~1）  该用例过去 30 天的失败比例
  执行成本（秒）     用例耗时，成本高的适当降权

示例：checkout_flow（相关性 1.0 × 关键度 5 × 失败率 0.1 ÷ 耗时 30s）
     排在 format_currency（相关性 0.2 × 关键度 1 × 失败率 0 ÷ 0.1s）之前
     → 5 分钟内给出最有价值的反馈

// tools/prioritize.ts —— 风险驱动的用例排序
export interface TestCase {
  id: string;
  relevance: number;      // 0~1 变更相关性
  businessWeight: number; // 1~5 业务关键度
  failureRate: number;    // 0~1 近 30 天失败率
  durationSec: number;    // 执行耗时
}

export function riskScore(t: TestCase): number {
  const speedFactor = 1 / Math.log2(t.durationSec + 2); // 耗时的对数降权
  return (
    t.relevance *
    t.businessWeight *
    (1 + t.failureRate * 2) *      // 失败率加权，但不过度
    speedFactor
  );
}

export function prioritize(tests: TestCase[]): TestCase[] {
  return [...tests].sort((a, b) => riskScore(b) - riskScore(a));
}

// 分阶段执行：先跑 Top 30%，通过后继续跑剩余
export function stagedPlan(tests: TestCase[]) {
  const ordered = prioritize(tests);
  const split = Math.ceil(ordered.length * 0.3);
  return { fast: ordered.slice(0, split), rest: ordered.slice(split) };
}

输入：
  · 候选用例集 T = {t1, t2, ..., tn}
  · 目标集合（如：所有被变更影响的代码行）R
  · 覆盖关系：每个 ti 覆盖 R 的一个子集

输出：T 的最小子集 T'，使得 ∪ cover(ti for ti in T') ⊇ R

本质：集合覆盖问题（Set Cover），NP-hard
  → 工业上用贪心近似，近似比 O(ln n)，足够好

# tools/minimize.py —— 贪心集合覆盖去冗余
def greedy_minimize(coverage: dict[str, set[str]], targets: set[str]) -> list[str]:
    """coverage: test_id -> 它覆盖的目标集合。返回覆盖全部 targets 的最小子集。"""
    uncovered = set(targets)
    chosen: list[str] = []

    while uncovered:
        # 每轮选"覆盖未覆盖目标最多"的用例
        best, best_gain = None, 0
        for test_id, covered in coverage.items():
            if test_id in chosen:
                continue
            gain = len(covered & uncovered)
            if gain > best_gain:
                best, best_gain = test_id, gain
        if best is None:
            break  # 存在无法覆盖的目标 → 需人工补齐用例
        chosen.append(best)
        uncovered -= coverage[best]

    return chosen

# 使用示例
if __name__ == "__main__":
    coverage = {
        "test_a": {"order.py:10", "order.py:11", "pay.py:5"},
        "test_b": {"order.py:10", "order.py:11"},
        "test_c": {"pay.py:5", "pay.py:9"},
        "test_d": {"pay.py:9"},
    }
    targets = {"order.py:10", "order.py:11", "pay.py:5", "pay.py:9"}
    print(greedy_minimize(coverage, targets))   # ['test_a', 'test_c']  ← 4 个压到 2 个

风险：最小化会删掉"冗余"用例，而冗余往往是安全网。
  用例 A 和 B 覆盖同样的代码，但 A 断言返回值、B 断言副作用
  → 只按代码覆盖去冗余可能删掉 B，导致副作用缺陷漏测

控制手段：
  1. 最小化只在"夜间/发版前深度回归"使用，PR 门禁用选择而非最小化
  2. 去冗余以"覆盖目标集合"为准，目标集合应包含断言维度
  3. 保留每个目标至少 2 个用例（冗余度 2），抵抗 flaky
  4. 定期用突变测试验证最小化后的套件突变检出率是否下降

name: Regression
on: [pull_request]

jobs:
  impact-analysis:
    runs-on: ubuntu-latest
    outputs:
      selected: ${{ steps.tia.outputs.tests }}
      fallback: ${{ steps.tia.outputs.fallback }}
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: 影响分析选例
        id: tia
        run: |
          python tools/tia.py > selected.txt
          echo "tests=$(paste -sd, selected.txt)" >> $GITHUB_OUTPUT
          # 兜底判定：核心模块变更 → fallback=true
          if grep -q '^src/core/' changed.txt; then
            echo "fallback=true" >> $GITHUB_OUTPUT
          else
            echo "fallback=false" >> $GITHUB_OUTPUT
          fi

  fast-regression:
    needs: impact-analysis
    if: needs.impact-analysis.outputs.fallback == 'false'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx playwright test --grep-invert @slow
        env: { TESTS: ${{ needs.impact-analysis.outputs.selected }} }

  full-regression:        # 兜底：核心变更时跑全量
    needs: impact-analysis
    if: needs.impact-analysis.outputs.fallback == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx playwright test

# 回归选择的效果度量
tia_selected_tests_total / tia_total_tests_total   # 选择率（期望 5%~15%）
tia_fallback_total                                 # 兜底回退次数
tia_escaped_defects_total                          # 逃逸缺陷（TIA 漏掉的）
regression_duration_seconds{phase="fast"}          # 快速回归耗时
regression_duration_seconds{phase="full"}          # 全量回归耗时

# 告警：逃逸缺陷上升 → 选择策略有漏；选择率 > 0.5 → 映射过粗

每周复盘：本次选例漏掉的缺陷有多少？
  逃逸缺陷 = 生产/预生产发现，但 PR 时 TIA 没选中的用例本可覆盖
  对每个逃逸缺陷反查"为什么没选中" → 补映射规则

三种典型漏因：
  1. 动态耦合未建模（配置/环境变量/schema 变更）→ 配置变更纳入影响面
  2. 新用例无历史覆盖数据 → 新用例默认全跑一轮后进入映射
  3. 跨语言/跨进程调用未被静态分析捕获
     → 补充 API 契约级映射（接口变更 → 消费方用例）