
## 引言：那个困扰了测试人二十年的问题`
凌晨两点，调试失败了。
你盯着满屏的失败用例，分不清哪些是真 bug，哪些是脚本飘了，哪些是环境又抽风了。你调日志、查截图、问值班开发，折腾到天亮，最后发现——80% 的失败，和你写的代码毫无关系。

这不是某一个人的故事，这是一代测试人的集体记忆。

我们这行，其实一直藏着一个心照不宣的尴尬：**自动化测试的产出，很难被信任**。计划状态写的是"执行完毕"，可谁也不敢据此说"质量没问题"。于是测试结果之上，永远还得再叠一层人工确认；人工确认之后，还得再叠一层专家经验。层层补丁，层层心虚。

AI 来了，所有人都很兴奋。让 Agent 自动生成方案、自动写代码！可越是用 AI 包裹，AI写的代码改如何测试反而更尖锐了！

## 一、回到第一性原理：测试，到底要回答什么问题
做架构久了，容易陷入一个陷阱：**把"怎么做"想得太多，把"为什么做"忘得太干净**。所以整改的第一步，我们强迫自己回到第一性原理，问一个最朴素的问题：

  一个"可信"的测试系统，到底必须能回答哪些问题？
  
我们推演出六个。任何一个回答不上来，这个系统就配不上"可信"二字。
| 问题 | 系统必须提供的能力 |
|:---:|---|
| **为什么测？** | 能追溯到需求、规则、风险、代码变化或测试目标 |
| **测什么？** | 能形成清晰的测试范围、方案、执行目标和任务边界 |
| **谁来测？** | 能根据任务类型选择 UI、API、性能或代码分析类执行终端 |
| **怎么测？** | 能把目标转成可执行任务，并在真实目标环境中执行 |
| **结果是什么？** | 能区分通过、业务失败、环境失败、数据失败、取消和系统异常 |`
| **凭什么相信？** | 能提供可复盘的证据、日志、报告、指标和分析依据 |

读到这里你可能已经察觉：前五个问题，行业里大部分平台都"声称"能回答；**真正稀缺的，是第六个——"凭什么相信"**。这六问，像一把尺子，量出了我们和"可信"之间的真实距离。它也直接导出了整改后整个系统必须守住的六条系统不变量

> 💡 一个测试系统的可信度，不取决于它能产出多少用例，而取决于每一条结论背后，是否站得起来"凭什么"。

这六条不变量，是整个 AIQA 架构的地基。后面所有的分层、协作、对象设计，都从它们长出来。


## 二、看见系统：一个由四个"面"组成的闭环
想理解 AIQA 的架构，不必先记住一堆组件名，而要先在脑子里建立一个画面——**四个"面"，围成一个闭环**。

![99.PNG](https://developer.qcloudimg.com/http-save/yehe-12426137/84f632062ead018f4010f89c8ed11961.png)

- **业务控制面**：决定"测什么、凭什么测"，管理业务事实和测试资产。
- **执行控制面**：决定"任务怎么跑"，调度资源、管理租约、驱动 Agent。
- **分布式执行面**：决定"真正去测"，在终端侧生产执行事实和证据。
- **外部目标面**：被测系统、浏览器、API、代码仓库、LLM——执行的对象，也是事实的来源。

系统的输入是需求、规则、代码变化和人工经验；输出是用例、结果、证据和复盘结论；而**最关键的，是那条反馈回路**——结果会反哺需求知识、测试方案、用例生成，乃至 Agent 自身的能力治理。

> 💡 好的架构不是把所有能力塞进一个服务，而是让每个逻辑层，只承担它不可替代的那一份职责。

闭环之所以重要，是因为测试从来不是一次性动作，而是一个**持续校准的认知过程**。没有反馈的测试，是消耗；有反馈的测试，才是积累。这也是为什么，我们把"复盘必须反哺上游"写进了核心业务规则（BR-12）。

## 三、拆解六层架构：谁，守住了哪道关
把闭环落到工程上，AIQA 用了一个清晰的六层逻辑架构。每一层，都对应第一性原理里那六问中的某几问。

| 层级 | 核心组件 | 第一性职责 | 它"不做"什么（同样重要） |
|---|---|---|---|
| 访问协同层 | **AiQaClient** | 承载用户工作台、评审、确认、复盘 | 不保存业务真源，不直接调度 Agent |
| 平台业务控制层 | **AiQaServer** | 管理业务事实、测试资产、执行目标、结果聚合 | 不维护 Agent 长连接，不直接驱动浏览器 |
| 执行调度控制层 | **aiQaEngine** | 接收目标、拆分任务、管理租约、调度 Agent | 不生成测试方案，不保存业务决策真源 |
| 专业化执行层 | **aiQaAgent** | UI 自动化：驱动浏览器、采集证据 | 不决定测试范围，不做全局调度 |
| 专业化执行层 | **AiApiAgent** | API/性能：采接口指标和压测结果 | 不决定业务风险，不生成质量结论 |
| 专业化执行层 | **AiCodeAgent** | 代码分析：生成结构化影响事实 | 不裁决回归范围，不判发布风险 |
| 外部目标与能力层 | 浏览器/被测系统/API/代码仓库/LLM/对象存储 | 提供执行目标与能力 | **不作为业务规则权威来源** |

注意那张表里最容易被忽视的一栏——**"不做"什么**。

很多架构的腐化，不是因为缺能力，而是因为**边界失守**。当 Server 开始直接操控浏览器，当 Agent 开始自己决定测试范围，当 LLM 的话被当成需求真源——系统就开始在不知不觉中失控。我们花了大量篇幅定义"不做什么"，因为**一条清晰的边界，比十个炫酷的功能更能守护系统的可信**。

> 💡 架构的成熟，是从"拼命加功能"走向"勇敢划边界"。敢说"不归我管"，比敢说"我都能做"难得多。

## 四、三大设计哲学：为什么是这套架构

架构选型，本质是在回答“为什么是它，而不是别的”。AIQA 的这套架构，背后站着三条相互咬合的设计哲学。理解了它们，你就理解了每一个组件的存在理由。

### 哲学一：业务控制与执行控制，必须分离

为什么要硬生生拆出 AiQaServer 和 aiQaEngine 两个控制面？

想象一座城市的治理：**立法权和执行权，绝不能握在同一只手里**。Server 是“立法者”，它定义测试的业务事实、范围边界和验收口径；Engine 是“执行者”，它只负责把目标变成可调度的任务，跑完把结果带回来。

如果两者合一，会发生什么？业务规则会被执行细节裹挟，今天为了跑得快改个规则，明天为了省资源放宽个边界。**当裁判同时是运动员，比赛的公正性就成了奢望。**

分离之后，业务真相有了稳定的归属，执行调度有了清晰的输入。各司其职，互不越界。

### 哲学二：目标委托，而非步步遥控

Server 不直接对 Agent 下指令，而是把“目标”和“边界”交给 Engine，让 Engine 去拆解、去调度。这叫**目标委托**。

为什么不用更“直接”的方式——Server 直接告诉每个 Agent 该点哪个按钮？因为那种方式有个致命缺陷：**业务服务会被执行细节绑架**。页面的控件会变，接口的字段会改，环境会波动——如果 Server 要为每一个变化负责，它将被无穷的细节淹没，再也没有精力守护真正的业务事实。

目标委托的本质，是**把“做什么”和“怎么做”解耦**。Server 只承诺“要验证这个证据需求”，至于用浏览器点还是用接口调，由 Engine 和 Agent 在执行侧自主决定。这给了系统在变化面前的**韧性**。

### 哲学三：证据优先于状态

这是整套架构里，我最想说的一条。

传统测试平台最爱的产出是什么？是**状态**：执行完毕、全部通过、成功率 98%。可“状态”是会撒谎的。它告诉你流程走完了，却不告诉你每一步是不是真的验证了该验证的东西。

AIQA 在这里做了一次决绝的转向：**计划状态，只说明流程进度；质量结论，必须回到用例级或任务级的证据**。每一条用例的通过与否，都要有截图、Trace、日志、断言结论来支撑；每一次失败，都要分清是业务失败、环境失败、数据失败，还是用例设计本身的问题（BR-09、BR-10）。

> 💡 状态回答“跑完了吗”，证据回答“可信吗”。一个成熟的测试系统，宁可慢一点给出证据，也不要快一点给出结论。

这三条哲学不是孤立的，它们互为因果：**分离**保证了真相有归属，**委托**赋予了执行的韧性，**证据**则为一切结论兜底。三者咬合，才撑得起“可信”二字。

---

## 五、三个专业 Agent：为什么不让一个 Agent 干完所有事

这是 AI 时代架构师最常被问的问题：**既然大模型什么都能聊，为什么要拆出 aiQaAgent、AiApiAgent、AiCodeAgent 三个终端？一个全能 Agent 不香吗？**

答案藏在一个朴素的工程规律里：**全能，往往是全不能的开始**。

一个试图同时搞定 UI 操作、接口压测、代码差异分析的 Agent，会面临三个完全不同的执行语境：

- **UI 自动化**要的是对浏览器的精细操控、页面元素的实时观察、失败时的截图取证；
- **API/性能测试**要的是并发控制、窗口指标、多 Agent 时钟同步起压；
- **代码影响分析**要的是拉取版本、识别 diff、追踪调用链、生成可审计的影响事实。

把这三套截然不同的能力塞进一个 Agent，结果是：每一个都做不深，每一个都背着一身用不上的包袱，每一次升级都要牵动全身。

所以我们选择了**专业化分工**——

| Agent | 它擅长的事 | 它绝不越界的事 |
|---|---|---|
| **aiQaAgent** | 浏览器驱动、LLM 辅助观察/规划/定位/断言/诊断、截图与 Trace 采集 | 不决定测试范围，不调度别的 Agent |
| **AiApiAgent** | 接口请求、压测并发、阶段窗口指标、多 Agent 时钟协同 | 不维护业务资产，不生成最终质量报告 |
| **AiCodeAgent** | 拉取版本、识别差异、生成影响候选与风险信号、采集调用链证据 | 不裁决回归范围，不判发布风险 |

每一个 Agent 只生产它“专业范围内的事实”，把决策权交还给业务层。这是**单一职责**在 AI 时代的回响，也是防止 Agent 膨胀成不可维护的“怪物”的唯一办法。

> 💡  AI 时代，Agent 的能力边界，就是系统的可信边界。让每个 Agent 只说自己确定的事，系统的谎言才会变少。

---

## 六、从需求到证据：一条主链路的自白

说了这么多架构哲学，让我们跟着一条真实的用例，从出生走到归档，看看“可信”是如何一步步被生产出来的。

### 阶段 1-3：需求沉淀 → 方案制定 → 方案评审

一切始于一份 PRD、一些规则文档，和测试人的经验。它们被沉淀成**需求知识**和**知识项**——请注意，原始文档不是真源，**正式沉淀后的需求知识才是**（BR-01）。这是整条链路的第一道防漂移闸门。

接着，基于需求事实，制定测试方案：测什么、不测什么、优先级、覆盖深度。方案草案要过**评审**这一关——范围不清、依据不足的方案，根本进不了正式生成（BR-02、BR-03）。这里有一个反直觉的设计：**我们故意给 AI 设了一道闸**。AI 不能自由扩写测试范围（BR-05），它只能在已评审方案的边界内工作。

为什么？因为我们见过太多“AI 一兴奋就给你生成 500 条用例，其中 300 条测的根本不是这次要验的东西”。**没有边界的 AI 生成，不是提效，是制造噪音。**

### 阶段 4-5：用例生成 → 用例确认

已评审方案 + 模块信息 + 知识详情 + 人工用例经验，四股力量共同约束 AI，生成候选用例。这里我们引入了一个关键校验——**人工经验匹配度**：AI 生成的用例，要和真人写的用例在颗粒度、组织方式上接近（BR-08）。

生成不是终点。候选用例还要过覆盖率检查（证据需求是否被覆盖，BR-04）、返修、人工评审，才能升级为正式测试用例。**每一条用例，都要能说清它覆盖了哪个需求、哪条规则、哪个风险。**

### 阶段 6：执行编排

测试计划冻结范围、资源、账号、入口地址，形成执行计划，下发给 aiQaEngine。Engine 把目标拆成 Run → Unit → Attempt 级别的任务，根据 Agent 画像（类型、能力、健康、负载）做能力匹配，下发、续约、回调。

### 阶段 7：结果复盘

这是整条链路的高光时刻，也是“可信”最终兑现的地方。

每条用例的执行，都会带回**用例级结果**和**执行证据**。失败被严格分类：业务断言失败、环境失败、数据失败、用例设计问题，泾渭分明（BR-10）。复盘不是走过场，它要能识别问题出在需求、方案、用例、数据、环境还是系统质量，并形成**改进项**，反哺回上游（BR-12）。

> 💡 **金句**：一条用例的生命，不该终结于“执行完毕”四个字，而该终结于“它让系统变得更好了一点”。

---

## 七、把信任，拆成可度量的指标

“可信”是个太软的词，软到容易变成口号。所以整改的最后一公里，是把它**拆成可度量的指标**，让“可信”变成可以被检验、被追问的事实。

| 指标 | 它在衡量什么 |
|---|---|
| 方案生成就绪率 | 测试方案本身的质量 |
| 证据需求覆盖率 | 用例是否真的服从了方案 |
| 用例返修率 | 生成质量的稳定性 |
| 人工经验匹配度 | AI 用例是否“像人写的” |
| 高优先级场景覆盖率 | 重点风险是否被关注 |
| 模块信息完整率 | 用例可执行性的基础 |
| 用例级结果完整率 | 执行闭环是否真的闭合 |
| 失败可诊断率 | 复盘的质量 |
| 改进项关闭率 | 持续改进是否真的发生 |

这九个指标，就是“凭什么相信”的量化版回答。它们不是用来汇报好看的数字，而是用来**逼问系统**：你说可信，那你的方案就绪率是多少？失败可诊断率是多少？拿不出数字，“可信”就只是 PPT 上的修辞。

> 💡 没有被度量的信任，只是偏爱；能被度量的信任，才是工程。

---

## 八、人机协同：AI 时代，人的位置在哪里

写到这里，必须回答一个敏感的问题：**这套架构里，人是不是被边缘化了？**

恰恰相反。AIQA 重新定义了人机的分工，而结论是——**人，比以往任何时候都更重要**。

我们把工作分成两类：

- **AI 擅长的**：解析需求、生成用例、评价差距、辅助执行、采集证据、归因分析。这些是“生产事实”的活。
- **人不可让渡的**：确认测试范围、评审方案、裁决业务风险、归因复杂失败、推动改进。这些是“治理事实”的活。

AI 负责把“事实”生产得又快又全，人负责为这些事实“背书”，并决定它们如何影响质量决策。**AI 是不知疲倦的执行者，人是最终的责任人。** 这条边界（系统不变量第六条），是我们刻意守护的。

为什么不让 AI 一条龙负责到底？因为**质量，本质上是一个需要有人“为之负责”的判断**。一个没有人参与背书的质量结论，无论多漂亮，都无法在真正的发布决策面前立足。AI 可以让测试覆盖得更广、跑得更快，但“能不能发”这四个字，必须由一个看得见业务全貌、承担得起后果的人来落笔。

> 💡 AI 让测试更高效，但只有人，能让测试结果更可信。我们不是在用 AI 替代人，而是在用 AI，把人从机械劳动里解放出来，去做真正需要人的判断。

---

## 结语：往回走的那一步

回头看整个 AIQA 整改，最反常识的决定，其实是在 AI 狂飙的浪潮里，**往回走了一步**。

所有人都在喊“让 AI 多生成、让流程更自动、让人更少介入”，而我们花了最大的力气，去重新定义边界、去要求证据、去重建闭环、去把人的治理权郑重地请回中央。

这不是保守，这是清醒。

因为我们终于想明白了一件事：**测试的本质，从来不是“跑用例”，而是“建立信任”**。跑得再快的用例，如果不能回答“凭什么相信”，就只是把不确定性，从测试阶段，推迟到了发布阶段——而发布阶段的不确定性，代价要昂贵一万倍。

AI 给了我们前所未有的生产力。但生产力越高，“可信”就越值钱。当 AI 能在一夜之间生成上万条用例，**真正稀缺的，不再是数量，而是每一条结论背后，那个站得住脚的“凭什么”**。

这，就是我们做 AIQA 整改的全部理由。

我们不追求让系统看起来很 AI，我们追求让每一次测试结果，都配得上被人相信。

> 💡 愿你写的每一行代码，都不再是凌晨两点的心虚；愿你交付的每一个功能，都能经得起客户的考验。这是 AI 时代，开发人最该守住的体面。

---


凌晨两点，调试失败了。你盯着满屏的失败用例，分不清哪些是真 bug，哪些是脚本飘了，哪些是环境又抽风了。你调日志、查截图、问值班开发，折腾到天亮，最后发现——80% 的失败，和你写的代码毫无关系。

AI 时代，我们如何重建一座可信的测试堡垒

你让 AI 一夜生成千行代码,却发现——一行都不敢上线。

代码长得飞快,测试却纹丝不动。AI 帮你越跑越快,你却越来越慌:这些代码,凭什么相信它没问题?构建红了,分不清是真 bug 还是 AI 幻觉;用例飘了,不知道是环境抽风还是逻辑真崩。你抱着 AI 这把锋利的刀,却找不到一把能验刀的尺。

本文拆解 AI 时代测试平台 AIQA 的架构——当 AI 能一夜生成万行代码,真正稀缺的,不再是速度

架构总监

测试

人工智能

架构设计

自动化测试20年痛点：80%失败与代码无关，结果难被信任。AIQA架构提出6大可信测试标准，强调证据优先于状态，分离业务与执行控制，专业化Agent分工。通过需求沉淀、方案评审、用例生成、执行复盘全流程闭环，量化9大指标确保可信度。AI负责生产事实，人负责治理事实，让测试结果真正经得起考验。

2026上云采购 | AI焕新·智启新局

tcap

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI 时代，我们如何重建一座可信的测试堡垒-腾讯云开发者社区-腾讯云

AI 时代，我们如何重建一座可信的测试堡垒

AI 时代，我们如何重建一座可信的测试堡垒

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐