你让 AI 一夜生成千行代码，却发现一行都不敢上线。代码长得飞快，测试却纹丝不动。AI 帮你越跑越快，你却越来越慌：这些代码，凭什么相信它没问题？
构建红了，分不清是真 bug 还是 AI 幻觉；用例飘了，不知道是环境抽风还是逻辑真崩。你抱着 AI 这把锋利的刀，却找不到一把能验刀的尺。
本文拆解 AI 时代测试平台 AIQA 的架构。当 AI 能一夜生成万行代码，真正稀缺的不再是速度。
凌晨两点的失败
凌晨两点，调试失败了。
你盯着满屏的失败用例，分不清哪些是真 bug，哪些是脚本飘了，哪些是环境又抽风了。调日志、查截图、问值班开发，折腾到天亮，最后发现 80% 的失败，和你写的代码毫无关系。
这不是某一个人的故事，是一代测试人的集体记忆。
我们这行一直藏着一个心照不宣的尴尬：自动化测试的产出，很难被信任。计划状态写的是执行完毕，可谁也不敢据此说质量没问题。测试结果之上永远还得叠一层人工确认，人工确认之后再叠一层专家经验。层层补丁，层层心虚。
AI 来了，所有人都很兴奋。让 Agent 自动生成方案、自动写代码！可越是用 AI 包裹，AI 写的代码该如何测试这个问题反而更尖锐了。
测试到底要回答什么问题
做架构久了容易陷入一个陷阱：把怎么做想太多，把为什么做忘太干净。所以整改的第一步，我们强迫自己回到第一性原理，问一个问题：一个可信的测试系统，到底必须能回答哪些？
推演出六个。任何一个回答不上来，这个系统就配不上可信二字。
前五个问题，行业里大部分平台都声称能回答。真正稀缺的是第六个：凭什么相信。
这六条不变量，是整个 AIQA 架构的地基。后面的分层、协作、对象设计，都从它们长出来。
四个面组成的闭环
想理解 AIQA 的架构，不必先记住一堆组件名，先在脑子里建立一个画面：四个面围成一个闭环。
业务控制面决定测什么、凭什么测，管理业务事实和测试资产。执行控制面决定任务怎么跑，调度资源、管理租约、驱动 Agent。分布式执行面决定真正去测，在终端侧生产执行事实和证据。外部目标面是被测系统、浏览器、API、代码仓库、LLM，执行的对象也是事实的来源。
系统的输入是需求、规则、代码变化和人工经验；输出是用例、结果、证据和复盘结论。最关键的是那条反馈回路：结果会反哺需求知识、测试方案、用例生成，乃至 Agent 自身的能力治理。
好的架构不是把所有能力塞进一个服务，而是让每个逻辑层只承担它不可替代的那一份职责。闭环之所以重要，是因为测试从来不是一次性动作，而是一个持续校准的认知过程。没有反馈的测试是消耗，有反馈的测试才是积累。我们把复盘必须反哺上游写进了核心业务规则 BR-12。
六层架构：谁守住了哪道关
把闭环落到工程上，AIQA 用了一个清晰的六层逻辑架构。每一层对应那六问中的某几问。
这张表里最容易被忽视的一栏是“不做什么”。
很多架构的腐化不是因为缺能力，而是因为边界失守。当 Server 开始直接操控浏览器，当 Agent 开始自己决定测试范围，当 LLM 的话被当成需求真源，系统就开始失控。我们花了大量篇幅定义不做什么，因为一条清晰的边界比十个炫酷的功能更能守护系统的可信。
三条设计哲学
业务控制与执行控制分离
为什么要硬生生拆出 AiQaServer 和 aiQaEngine 两个控制面？
想象一座城市的治理：立法权和执行权绝不能握在同一只手里。Server 是立法者，定义测试的业务事实、范围边界和验收口径；Engine 是执行者，负责把目标变成可调度的任务，跑完把结果带回来。
如果两者合一呢？业务规则会被执行细节裹挟，今天为了跑得快改个规则，明天为了省资源放宽个边界。裁判同时是运动员，比赛的公正性就成了奢望。分离之后，业务真相才有了稳定的归属，执行调度有了清晰的输入。
目标委托，而非步步遥控
Server 不直接对 Agent 下指令，而是把目标和边界交给 Engine，让 Engine 去拆解、去调度。这叫目标委托。
为什么不直接让 Server 告诉每个 Agent 该点哪个按钮？因为那种方式有个致命缺陷：业务服务会被执行细节绑架。页面的控件会变，接口的字段会改，环境会波动。如果 Server 要为每一个变化负责，它将被无穷的细节淹没，再也没有精力守护真正的业务事实。
目标委托的本质是把做什么和怎么做解耦。Server 只承诺要验证这个证据需求，至于用浏览器点还是用接口调，由 Engine 和 Agent 在执行侧自主决定。这给了系统变化面前的韧性。
证据优先于状态
传统测试平台最爱的产出是什么？状态。执行完毕、全部通过、成功率 98%。可状态是会撒谎的。它告诉你流程走完了，却不告诉你每一步是不是真的验证了该验证的东西。
AIQA 在这里做了一个转向：计划状态只说明流程进度，质量结论必须回到用例级或任务级的证据。每一条用例的通过与否都要有截图、Trace、日志、断言结论来支撑；每一次失败都要分清是业务失败、环境失败、数据失败还是用例设计本身的问题（BR-09、BR-10）。状态回答跑完了吗，证据回答可信吗。宁可慢一点给出证据，也不要快一点给出结论。
这三条哲学互为因果：分离保证了真相有归属，委托赋予了执行的韧性，证据为一切结论兜底。
为什么不让一个 Agent 干完所有事
AI 时代架构师最常被问到的问题：既然大模型什么都能聊，为什么要拆出三个 Agent？一个全能的不香吗？
答案在一个朴素的工程规律里：全能往往是全不能的开始。
一个试图同时搞定 UI 操作、接口压测、代码差异分析的 Agent 会面临三个完全不同的执行语境。UI 自动化要的是对浏览器的精细操控、页面元素的实时观察、失败时的截图取证；API/性能测试要的是并发控制、窗口指标、多 Agent 时钟同步起压；代码影响分析要的是拉取版本、识别 diff、追踪调用链、生成可审计的影响事实。把三套截然不同的能力塞进一个 Agent，结果是每一个都做不深，每一个都背着一身用不上的包袱。
所以我们选了专业化分工：
一条用例从出生到归档
说了这么多架构哲学，跟着一条真实的用例从出生走到归档，看看可信是如何一步步被生产出来的。
需求沉淀到方案评审
一切始于一份 PRD、一些规则文档和测试人的经验。它们被沉淀成需求知识和知识项。原始文档不是真源，正式沉淀后的需求知识才是（BR-01），这是整条链路的第一道防漂移闸门。
接着基于需求事实制定测试方案：测什么、不测什么、优先级、覆盖深度。方案草案要过评审，范围不清、依据不足的方案进不了正式生成（BR-02、BR-03）。这里有一个反直觉的设计：故意给 AI 设了一道闸，AI 不能自由扩写测试范围（BR-05），只能在已评审方案的边界内工作。见过太多 AI 一兴奋就生成 500 条用例，其中 300 条根本不是这次要验的东西。没有边界的 AI 生成不是提效，是制造噪音。
用例生成到确认
已评审方案 + 模块信息 + 知识详情 + 人工用例经验，四股力量共同约束 AI 生成候选用例。这里引入了一个关键校验：人工经验匹配度。AI 生成的用例要和真人写的用例在颗粒度、组织方式上接近（BR-08）。
生成不是终点。候选用例还要过覆盖率检查（证据需求是否被覆盖，BR-04）、返修、人工评审才能升级为正式测试用例。每一条用例都要说清它覆盖了哪个需求、哪条规则、哪个风险。
执行编排与结果复盘
测试计划冻结范围、资源、账号、入口地址形成执行计划，下发给 aiQaEngine。Engine 把目标拆成 Run → Unit → Attempt 级别的任务，根据 Agent 画像（类型、能力、健康、负载）做能力匹配，下发、续约、回调。
每条用例的执行都会带回用例级结果和执行证据。失败被严格分类：业务断言失败、环境失败、数据失败、用例设计问题，泾渭分明（BR-10）。复盘要能识别问题出在需求、方案、用例、数据、环境还是系统质量，并形成改进项反哺回上游（BR-12）。一条用例的生命不该终结于执行完毕四个字。
把信任拆成可度量的指标
可信是个太软的词，软到容易变成口号。所以整改的最后一公里是把它拆成可度量的指标，让可信变成可以被检验、被追问的事实。
这九个指标就是凭什么相信的量化版回答。它们不是用来汇报好看的数字，而是用来逼问系统：你说可信，方案就绪率是多少？失败可诊断率是多少？拿不出数字，可信就只是 PPT 上的修辞。
人机协同：人的位置在哪里
写到这必须回答一个问题：这套架构里人是不是被边缘化了？
恰恰相反。AIQA 重新定义了人机的分工：AI 擅长的是解析需求、生成用例、评价差距、辅助执行、采集证据、归因分析，这些是生产事实的活。人不可让渡的是确认测试范围、评审方案、裁决业务风险、归因复杂失败、推动改进，这些是治理事实的活。
AI 负责把事实生产得又快又全，人为这些事实背书并决定它们如何影响质量决策。AI 是不知疲倦的执行者，人是最终的责任人。不让 AI 一条龙负责到底，因为质量本质上是一个需要有人为之负责的判断。没有人参与背书的质量结论无论多漂亮都无法在发布决策面前立足。AI 可以让测试覆盖得更广跑得更快，但能不能发这四个字，必须由看得见业务全貌、承担得起后果的人来落笔。
往回走了一步
回头看整个 AIQA 整改，最反常识的决定是在 AI 狂飙的浪潮里往回走了一步。
所有人都在喊让 AI 多生成、让流程更自动、让人更少介入，而我们花了最大的力气去重新定义边界、要求证据、重建闭环、把人的治理权请回中央。
这不是保守。因为我们终于想明白了一件事：测试的本质从来不是跑用例，而是建立信任。跑得再快的用例如果不能回答凭什么相信，就只是把不确定性从测试阶段推迟到了发布阶段，而发布阶段的不确定性代价要昂贵一万倍。
AI 给了我们前所未有的生产力。生产力越高，可信就越值钱。当 AI 能在一夜之间生成上万条用例，真正稀缺的不再是数量，而是每一条结论背后，那个站得住脚的“凭什么”。这就是做 AIQA 整改的全部理由。
不追求让系统看起来很 AI，追求让每一次测试结果都配得上被人相信。
在云栈社区，我们持续关注 软件测试 与 人工智能 领域的前沿实践，欢迎与更多同行交流质量保障与 Agent 架构的设计思路。
发表于 3 小时前
|
查看: 4|
回复: 0
