开源智能测试平台该分哪几层：数据采集、用例编排到质量归因的选型地图

一家 200 人规模的研发团队，决定自建「AI 时代的测试平台」。leader 把测试架构师叫过去，给了两周：出一份选型建议。架构师打开浏览器一搜，用例管理有一堆、执行调度有一堆、数据工厂有一堆、评测编排又有一堆，每个都号称「一站式」「智能化」，README 里的 star 数一个比一个高。

两周后交上去的报告，很可能是一份「工具名气排行榜」：哪个火就选哪个，拼在一起就叫平台。这是自建测试平台最常见、也最致命的错误。拼出来的东西看着热闹，真跑起来才发现——用例管理工具导出的数据，执行调度工具读不进去；执行结果落到了 A 系统，质量归因又只在 B 系统里看得到；某一层压根没人负责，慢慢成了三不管地带。

本篇借「测试正在平台化、智能化」这个行业趋势做个引子，但不聊任何厂商跑分或谁登顶——那是另一类文章的事。这里只给一张分层选型地图：把测试平台拆成五层，每层讲清它解决什么、选开源时该看哪三个指标、常见的坑在哪。核心观点就一句：选型不是列清单，而是定契约。

一、趋势是真的，但选型最容易犯的错是「拼盘」

先承认趋势：AI 时代测试确实在平台化。用例越来越多来自 AI 生成、执行越来越依赖弹性调度、结果越来越需要智能归因，这些变化都在推着团队把散落的工具收敛成一个平台。这个方向没错。

错的是收敛的方式。大多数团队的选型是「工具导向」的：先看到某个明星开源项目，再反过来想「它能塞进我们平台的哪个位置」。这种自下而上的拼盘，本质是先有锤子再找钉子。结果是每个单点工具都不差，但工具之间的接口口径对不上，集成成本在后期集中爆发，越接越乱。

正确的顺序应该反过来：先定义平台要分哪几层、每层的职责边界和交付契约是什么，再往每一层里填候选工具。工具是可替换的，分层职责和接口契约才是稳定的骨架。骨架定错了，换再多名牌工具都救不回来。

二、把测试平台拆成五层

按职责自下而上，一个 AI 时代的测试平台可以拆成五层。

第一层是数据采集层，负责把线上真实世界的信息收上来：线上流量录制、日志与 Trace 回流、历史缺陷记录。它是整个平台的数据源头，采不上来，后面几层都是无米之炊。第二层是测试数据与 fixtures 层，把采上来的原始数据加工成可版本化、已脱敏、可回滚的测试数据集。第三层是用例资产层，管用例本身，以及需求-用例-缺陷之间的追溯关系。第四层是执行编排层，负责调度、并发、环境门禁和 CI 集成，把用例真正跑起来。第五层是质量归因与评测层，做结果聚合、flaky 隔离，以及对 AI 用例和模型的评测编排。

这五层是有严格上下依赖的：数据从下往上流，归因层要同时消费执行层的结果和采集层的原始上下文。理清依赖方向，是后面所有选型的前提——依赖一旦成环，平台就跑不起来了。

三、五层选型地图：职责、候选、三指标、坑

把五层的职责、典型开源候选、选型该看的三个指标、以及最常踩的坑，整理成一张地图：

这张表最该盯的不是「候选」那一列，而是「选型三指标」那一列。候选工具随时会更新换代，但你选任何一层工具时该问的三个问题基本不变。比如执行编排层，不管你用 Jenkins 还是 Argo，都要问 p95 跑多久、并发利用率多高、门禁可不可配置——指标恒定，工具可换。

四、选型不是列清单，而是定契约

上面那张表如果只停在「看」的层面，还是清单。要让选型真正落地，得把每层的职责、依赖、接口契约、owner 和 SLA 写成机器能校验的东西。下面这份 YAML 就是干这个的：

# platform-architecture.yaml —— 测试平台五层架构与选型契约
version: "1.0"
team_size: 200
layers:
  - id: L1_collection
    name: 数据采集层
    depends_on: []
    owner: quality-data-group
    sla:
      metric: trace_ingest_lag_seconds
      target: 30
    candidates: [OpenTelemetry Collector, GoReplay, tcpcopy]
    contract:
      output: "标准化流量/日志/缺陷事件流（JSON Lines，落对象存储）"

  - id: L2_fixtures
    name: 测试数据与 fixtures 层
    depends_on: [L1_collection]
    owner: test-platform-group
    sla:
      metric: dataset_rollback_minutes
      target: 5
    candidates: [testcontainers, 数据工厂类, 开源脱敏方案]
    contract:
      output: "可版本化、已脱敏、可回滚的数据集快照"

  - id: L3_cases
    name: 用例资产层
    depends_on: [L2_fixtures]
    owner: qa-leads
    sla:
      metric: requirement_case_traceability_ratio
      target: 0.9
    candidates: [MeterSphere, TestLink, Kiwi TCMS]
    contract:
      output: "需求-用例-缺陷可追溯的用例资产库"

  - id: L4_execution
    name: 执行编排层
    depends_on: [L3_cases, L2_fixtures]
    owner: ci-group
    sla:
      metric: pipeline_p95_minutes
      target: 20
    candidates: [Jenkins, GitLab CI, Argo Workflows]
    contract:
      output: "带环境门禁的并发调度与执行结果流"

  - id: L5_attribution
    name: 质量归因与评测层
    depends_on: [L4_execution, L1_collection]
    owner: quality-engineering
    sla:
      metric: flaky_quarantine_recall
      target: 0.85
    candidates: [ReportPortal, Allure, Ragas 类评测]
    contract:
      output: "结果聚合、flaky 隔离、AI 用例/模型评测归因看板"

配套的校验脚本，读取这份 YAML，检查层间依赖不成环、每层都有 owner 和可量化 SLA：

# validate_platform_arch.py —— 校验五层架构：依赖不成环 + 每层有 owner 与 SLA
# 依赖安装：pip install pyyaml
# 用法：python validate_platform_arch.py platform-architecture.yaml
import sys
import yaml


def load_arch(path):
    with open(path, "r", encoding="utf-8") as f:
        return yaml.safe_load(f)


def detect_cycle(layers):
    """用 DFS 拓扑检测层间依赖是否成环，返回 (是否有环, 环路径)。"""
    graph = {l["id"]: l.get("depends_on", []) for l in layers}
    state = {nid: 0 for nid in graph}  # 0=未访问 1=访问中 2=已完成
    stack = []

    def dfs(node):
        state[node] = 1
        stack.append(node)
        for dep in graph.get(node, []):
            if dep not in graph:
                raise ValueError(f"依赖了不存在的层：{node} -> {dep}")
            if state[dep] == 1:
                return stack[stack.index(dep):] + [dep]  # 找到回边即成环
            if state[dep] == 0:
                found = dfs(dep)
                if found:
                    return found
        stack.pop()
        state[node] = 2
        return None

    for nid in graph:
        if state[nid] == 0:
            cycle = dfs(nid)
            if cycle:
                return True, cycle
    return False, []


def validate(arch):
    layers = arch["layers"]
    errors = []

    has_cycle, cycle = detect_cycle(layers)
    if has_cycle:
        errors.append(f"层间依赖成环：{' -> '.join(cycle)}")

    for l in layers:
        if not l.get("owner"):
            errors.append(f"层 {l['id']} 缺少 owner")
        sla = l.get("sla") or {}
        if not sla.get("metric") or sla.get("target") is None:
            errors.append(f"层 {l['id']} 缺少可量化 SLA（metric/target）")
        if not l.get("candidates"):
            errors.append(f"层 {l['id']} 没有候选开源组件")

    return errors


def main():
    path = sys.argv[1] if len(sys.argv) > 1 else "platform-architecture.yaml"
    arch = load_arch(path)
    errors = validate(arch)
    if errors:
        print("[架构校验未通过]")
        for e in errors:
            print(f"  - {e}")
        sys.exit(1)
    print(f"[架构校验通过] 共 {len(arch['layers'])} 层，依赖无环，owner/SLA/候选齐备")
    sys.exit(0)


if __name__ == "__main__":
    main()

这份 YAML 加校验脚本想说明一件事：选型不是列清单，而是定契约。清单谁都会列，把叫得出名字的工具堆到一起就叫选型报告，但堆出来的东西往往跑不通。真正让平台立起来的是三样——层与层之间的依赖关系（谁产出、谁消费）、每层的接口契约（contract.output 那行说清交付什么）、每层的 owner 和 SLA（谁负责、拿什么指标衡量）。校验脚本干的活，就是把这三样从「文档里的一句话」变成「机器能检查的约束」：依赖成环立刻报错，某层没 owner 或没量化 SLA 也报错。踩过的坑是——很多团队的平台烂尾，不是因为工具选错，而是因为某一层压根没人负责、也没指标，慢慢就成了三不管地带。

五、拼盘式 vs 分层契约式

把两种选型思路正面对照，差别就清楚了：

最关键的差别在「交付物」和「可验证性」这两行。拼盘式交上去的是一份名词清单，评审会上谁也说服不了谁，最后靠嗓门大的人拍板；契约式交上去的是一份能被脚本校验的架构，依赖成环、字段缺失这类硬伤在提交前就被机器挡掉了，评审只需要讨论真正需要人判断的取舍。

六、落地时的三个建议

第一，先画分层再选工具，顺序不能反。骨架稳定、工具可换，这是整套方法论的地基。第二，每层必须有唯一 owner 和一个能数字化的 SLA，没有 owner 的层就是未来的三不管地带，没有 SLA 的层就没法判断它到底做得好不好。第三，把接口契约写死在配置里、用脚本校验，别停留在文档里——文档会被遗忘，脚本报错不会。

还要提醒一点：五层不是刻在石头上的教条。团队小、业务简单的时候，采集层和 fixtures 层完全可以先合并，归因层甚至可以先拿一个现成的报告工具顶着；等业务复杂了、数据量上来了，再把它们拆开。分层的意义不在于「必须凑够五层」，而在于让你在任何阶段都能清楚地回答三个问题——每一层谁负责、交付什么、依赖谁。哪怕你当前只有三层，只要每层的契约是清楚的、owner 是明确的，它就比一份五层名牌工具的拼盘要健康得多。

两周时间给一份选型建议，与其列一张长长的工具清单，不如交一张五层地图加一份能跑通的契约校验。前者看着丰满，后者才是能落地、不烂尾的东西。

本篇不聊任何厂商的跑分或登顶对比，也不碰 Agent/MCP/Skills 那套工具契约——那是另一个话题。这里只回答一个架构层面的问题：一个 AI 时代的测试平台，到底该分哪几层、每层怎么选。

平台不是把名牌工具拼在一起，而是把分层职责和接口契约定清楚。