一家 200 人规模的研发团队，决定自建「AI 时代的测试平台」。leader 把测试架构师叫过去，给了两周：出一份选型建议。架构师打开浏览器一搜，用例管理有一堆、执行调度有一堆、数据工厂有一堆、评测编排又有一堆，每个都号称「一站式」「智能化」，README 里的 star 数一个比一个高。
两周后交上去的报告，很可能是一份「工具名气排行榜」：哪个火就选哪个，拼在一起就叫平台。这是自建测试平台最常见、也最致命的错误。拼出来的东西看着热闹，真跑起来才发现——用例管理工具导出的数据，执行调度工具读不进去；执行结果落到了 A 系统，质量归因又只在 B 系统里看得到；某一层压根没人负责，慢慢成了三不管地带。
本篇借「测试正在平台化、智能化」这个行业趋势做个引子，但不聊任何厂商跑分或谁登顶——那是另一类文章的事。这里只给一张分层选型地图：把测试平台拆成五层，每层讲清它解决什么、选开源时该看哪三个指标、常见的坑在哪。核心观点就一句：选型不是列清单，而是定契约。
一、趋势是真的，但选型最容易犯的错是「拼盘」
先承认趋势：AI 时代测试确实在平台化。用例越来越多来自 AI 生成、执行越来越依赖弹性调度、结果越来越需要智能归因，这些变化都在推着团队把散落的工具收敛成一个平台。这个方向没错。
错的是收敛的方式。大多数团队的选型是「工具导向」的：先看到某个明星开源项目，再反过来想「它能塞进我们平台的哪个位置」。这种自下而上的拼盘，本质是先有锤子再找钉子。结果是每个单点工具都不差，但工具之间的接口口径对不上，集成成本在后期集中爆发，越接越乱。
正确的顺序应该反过来：先定义平台要分哪几层、每层的职责边界和交付契约是什么，再往每一层里填候选工具。工具是可替换的，分层职责和接口契约才是稳定的骨架。骨架定错了，换再多名牌工具都救不回来。
二、把测试平台拆成五层
按职责自下而上，一个 AI 时代的测试平台可以拆成五层。
第一层是数据采集层，负责把线上真实世界的信息收上来：线上流量录制、日志与 Trace 回流、历史缺陷记录。它是整个平台的数据源头，采不上来，后面几层都是无米之炊。第二层是测试数据与 fixtures 层，把采上来的原始数据加工成可版本化、已脱敏、可回滚的测试数据集。第三层是用例资产层，管用例本身，以及需求-用例-缺陷之间的追溯关系。第四层是执行编排层，负责调度、并发、环境门禁和 CI 集成，把用例真正跑起来。第五层是质量归因与评测层，做结果聚合、flaky 隔离，以及对 AI 用例和模型的评测编排。
这五层是有严格上下依赖的：数据从下往上流，归因层要同时消费执行层的结果和采集层的原始上下文。理清依赖方向，是后面所有选型的前提——依赖一旦成环，平台就跑不起来了。
三、五层选型地图：职责、候选、三指标、坑
把五层的职责、典型开源候选、选型该看的三个指标、以及最常踩的坑，整理成一张地图：
层
解决什么
典型开源候选
选型三指标
常见的坑
① 数据采集层
把线上流量、日志/Trace、缺陷历史收上来
OpenTelemetry Collector、GoReplay、tcpcopy
采集延迟、数据完整率、存储成本
只采不回灌，攒了一堆用不上的原始日志
② 数据与 fixtures 层
提供可版本化、脱敏、可回滚的测试数据
testcontainers、数据工厂类、开源脱敏方案
回滚速度、脱敏合规性、数据复用率
直接连生产库，或数据造完就脏、不可回滚
③ 用例资产层
用例管理与需求-用例-缺陷追溯
MeterSphere、TestLink、Kiwi TCMS
追溯覆盖率、检索效率、协作成本
用例库变成只写不跑的文档坟场
④ 执行编排层
调度、并发、环境门禁、CI 集成
Jenkins、GitLab CI、Argo Workflows
p95 时长、并发利用率、门禁可配置性
环境无门禁，脏环境跑出一堆假红灯
⑤ 质量归因与评测层
结果聚合、flaky 隔离、AI 用例/模型评测
ReportPortal、Allure、Ragas 类评测
归因准确率、flaky 召回率、看板可用性
只出报告不做归因，红灯还得人去查
这张表最该盯的不是「候选」那一列，而是「选型三指标」那一列。候选工具随时会更新换代，但你选任何一层工具时该问的三个问题基本不变。比如执行编排层，不管你用 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 与量化指标兜底
可验证性
靠评审会拍脑袋
脚本能校验依赖不成环、字段齐备
最关键的差别在「交付物」和「可验证性」这两行。拼盘式交上去的是一份名词清单，评审会上谁也说服不了谁，最后靠嗓门大的人拍板；契约式交上去的是一份能被脚本校验的架构，依赖成环、字段缺失这类硬伤在提交前就被机器挡掉了，评审只需要讨论真正需要人判断的取舍。
六、落地时的三个建议
第一，先画分层再选工具，顺序不能反。骨架稳定、工具可换，这是整套方法论的地基。第二，每层必须有唯一 owner 和一个能数字化的 SLA，没有 owner 的层就是未来的三不管地带，没有 SLA 的层就没法判断它到底做得好不好。第三，把接口契约写死在配置里、用脚本校验，别停留在文档里——文档会被遗忘，脚本报错不会。
还要提醒一点：五层不是刻在石头上的教条。团队小、业务简单的时候，采集层和 fixtures 层完全可以先合并，归因层甚至可以先拿一个现成的报告工具顶着；等业务复杂了、数据量上来了，再把它们拆开。分层的意义不在于「必须凑够五层」，而在于让你在任何阶段都能清楚地回答三个问题——每一层谁负责、交付什么、依赖谁。哪怕你当前只有三层，只要每层的契约是清楚的、owner 是明确的，它就比一份五层名牌工具的拼盘要健康得多。
两周时间给一份选型建议，与其列一张长长的工具清单，不如交一张五层地图加一份能跑通的契约校验。前者看着丰满，后者才是能落地、不烂尾的东西。
本篇不聊任何厂商的跑分或登顶对比，也不碰 Agent/MCP/Skills 那套工具契约——那是另一个话题。这里只回答一个架构层面的问题：一个 AI 时代的测试平台，到底该分哪几层、每层怎么选。
平台不是把名牌工具拼在一起，而是把分层职责和接口契约定清楚。
