# 测试与自成长层：让失败成为一再生长的资产

> **AI Harness Engineering 系列 · 第十一篇** · 王海涛（公众号：Jia言Yi行 · GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

二十世纪的科学哲学家卡尔·波普尔，在一本叫《猜测与反驳》的书里，推翻了一个流传了三百年的看法。

伽利略以来的科学，一直被讲成"一点点累积正确"：今天证明了一个，明天再证明一个，真理越攒越多。波普尔说不对。他说科学的进步，不是靠一次次的"做对"堆出来的，而是靠一次次的"做错被推翻"推着往前走的。 **一个再漂亮的理论，它的价值不在它能解释多少东西，而在它经不经得起人一次次伸手去把它打翻。打不翻，它才算留下；一打就翻，它反而帮你排掉了一个错误的可能。** "猜测—反驳"的核心论述，就是：我们不是从成功里积累知识，恰恰是从失败里。

这段话，特别适合用来描述"测试"工作的使命和愿景。 测试与其自成长的能力，是一套把**失败本身**当原料、当成资产、让它自己越长越厚的体系。

## 建立测试基线

![00-intro.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/ae83bf4d6c92d59443cc300ec0503222.jpg)

测试基线，是一个参考项目管理的“项目计划基线”，建立的属于测试迭代的概念和方法。当小到一个单元功能，大到一个模块或者软件准备交付的时候，会按照开发、数据、业务对接的需求，建立一个最小的测试样本集合，这个就是我们说的测试基线，所有后续的测试活动，都会以项目为单位，在该项目的测试基线上开展，原则上，测试基线是每一轮各种测试的最小集合，而且基线会随着功能迭代、需求调整或者错误数量进行适应性调整。

为什么用单独的概念，把一个简单的“抓Bug”的事儿搞得难以理解？
如果你的第一反应是太繁琐，那大概率，是因为你的测试工作主要依靠的还是人，还没有真正的交给AI 大模型和AI Agent。先讲一个我们真实经历过的、灰头土脸的困境。

当年团队修 bug，流程是这样的：Agent 改完代码，手头有印象的就跑几个用例，确认"没跑坏我刚改的那块"，就算过关。听起来每次都很认真。但所有人都心知肚明——**修好了 A，打坏了 B，全凭运气。**因为手头没有明确的“check list”，AI Agent也不知道涟漪分析的范围。

代码是一座冰山，你改的那一行只是露在水面的尖——可水面之下它隔着很多层，牵着很多你压根想不起来的模块。你跑了两个"记得"（直接关联）的用例，真正会被你这次改动波及的那个模块，你连想都没想起来。（详见本系列第十篇）

后果比"打坏了 B"更隐蔽：**打坏了 B，你根本不知道。** 于是每一次改代码，都是往黑暗里开一枪，赌它不炸。

可赌，成不了工程。而比"赌"更糟糕的，是另一件事：因为从来没有一条照妖镜式的流程，那些一直坏着却没被发现的请求，就被静默地吞了一天又一天。**你不仅没有基线，你连一本"这个系统到底有哪几类失败"的账都没有。**你不知道自己欠了多少，因为你从来没点数过。

基线的设计原则很朴素：它不追求包住所有边界，只要求做到一个最小闭环（保障功能好用的最小链路，并且有降级的backup），随项目开发，他能逐步完善，落成一条**随时能跑、跑完就知道答案**的流程。基线的意义，就是把"赌"换成"验"。

以这套理念作为核心，我们做了一个工具，叫 fulltest，对他的期望有两点，一是快，二是自成长。
数轮调教之后，fulltest一次全量回测，十秒跑完；同时，还能做到，无论是Agent自己发现还是HITL发现的问题，都能有效的被编排到fulltest中，保证同样的问题，不会在表层、在冰山水下、在已知涟漪范围重复出现。


## 自成长的测试体系

很多团队以为"自成长"就是"修一个 bug 补一条用例"。这话没错，但只碰着了皮毛。修 bug 补用例，补的是一条孤立的测试；真正让一个测试系统从"会跑"变成"会进化"的，是它开始认失败——认得某一类失败是第几次出现，认得它是老毛病还是新坑，认得它该不该算在你头上。

一个只会说"过了/挂了"的测试系统，在波普尔眼里是退化了的科学：它只知道绿灯多了几盏，却不知道黑板上的错误名单变厚了没有。我们要的不是交通灯，是"这份失败账，越记越全"。

于是 fulltest 在"跑用例"之外，设计了三个组成部分，才是一个测试系统真正值钱的内核。

### 一：失败先分类，再判断——"这笔失败，认不认得？"

fulltest 手边有一本账，一个记录失败模式的Jason文件。里面每一笔都是"这一类失败长什么样"的画像：一个识别的正则、一句话的根因、一段可执行的修复方案。

每一次全量回归跑出问题，系统先把失败的症状拿去这本账上对一对：

- 对上了某张画像——好，这是**认识的失败**，直接调修复方案，按老规矩办；
- 对不上——这才是金子。被标注为**不认识的失败**，用来扩充基线和自成长。

你可以感受到这个设计的反直觉处：**系统最怕的不是"认识的失败又来了"，而是"来了笔不认识的"——因为那意味着你的账，还有没覆盖到的洞。**认识的失败是已知债务，不认识的失败，是还没被发现的坑。所以程序把"不认识"当成头等大事，单独列册，等下一步处理。这一下，测试就从"检查机器好不好"，变成了"盘点自己对失败的认知覆盖有多全"。

### 二：喂食闭环——失败账是长出来的，不是写出来的

fulltest是靠一套"喂食"机制，从实战里一口一口长出来的。

这套机制管自己叫“喂食”有三个来源：

- **未知失败日志**：就是一里那本——每次遇到"不认识的失败"，自动成为待喂食的候选；
- **已验明的 Issue**：一个 bug 查到底、定位了 L1/L2/L3 三层根因、也找到了解法之后，这条"根因→解法"的完整经验，喂进账里；
- **git 的修复提交**：凡是以 fix 开头的提交，说明了"改什么修好了什么"，同样值得收编。

进化过程同样是个整理过程，不属于任何一次测试运行，它属于这个工程组织本身。新项目接进来，不是从零开始踩坑，而是带着别的项目踩过的教训进门。

### 三：基线自己会爬——"比上次强了"，被写进版本号

fulltest 的基线是会**自己爬升**的。每次全量跑完，自动比较"这次的通过数"和"基线记的通过数"：

- **这次更强**（通过数涨了）——自动把新基线写下来，基线版本号 +1。它在说：底线抬高了，你以后退步都退不到低于这个水位；
- **这次退步**（通过数跌了）——触发回归告警，告诉你"你不仅没进步，还掉回去了"，点名是哪一类失败在返潮；
- **通过率没动、也没有失败**——那是最安静的好消息：全过，基线原地待命。

这里面藏着一个很高级的认知：**基线的意义不在"定一个永远的合格线"，而在"把每一次变好都固化成回不去的底线"。** 测试系统不是死守保底线，它是你在持续爬台阶时，每一步放下的一颗楔子——想退，得先把楔子撬开。

![04-anti-pattern.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/5aa5f19caf2981753b1d2c642ba16e3f.jpg)


## 测试不是万能的：失效分析，是给测不到的地方留的兜底

可就算你把 fulltest 这套账记到最全，也必须先承认一件事：**测试能兜住你"想得到并写得出来"的失败，兜不住你"没想到"的那一种。** 一套再厚的基线，每一行测试都是人（或模型）先想到了某个失败，才写下来防它的。可工程里最贵的故障，恰恰长在没人想到的角落。

讲个真实的小故事。

某次线上事故，事后复盘时全组人都下不来台：fulltest 六条门禁一路绿灯，62/62 集成测试全过，谁也没发现问题。可线上还是爆了——爆在一个**没有人写成测试的边界**上：某个第三方接口在某个极端时段返回了一种异常格式，触发了全链路里最深处的一个假象，一路乘上来，演成了事故。事后补测试，大家惊讶地发现：根本没法稳定复现——那个异常只在特定数据分布下才会出现，测试环境构造不出。

问题不在"测试写得不够多"。**在于你永远没法用"写得更多"去兜住"根本没被写出来"的失败。** 这个时候站出来的，不是 fulltest，是它隔壁的一位老同事——失效分析（FMEA）意义上的兜底：不去问"这个失败会不会来"，而去问"如果它来了，系统能不能不死"。边界异常格式来了——测不到，但能不能在解析层"容忍+降级"，先让核心链路活下来，把这个异常记进账里再说？

这就是 FMEA 干的事：它专盯"如果失败来了"这一类假设，把"拦不住"换成"扛得住"——对每一个想得到的那层兜底，给系统装一个降级的活门。fulltest 负责把测得到的失败变成陈账、让它们越记越全；FMEA 负责在测不到的地方给系统留一条退路，让意外到来时不至于就地阵亡，而是先活着、然后再被记进 fulltest 的账里。


## 第一天就能用的清单

循序渐进，别一上来就建全套。第一天先做三件事：

1. 先问一句：我的项目，有没有一条"一条命令、十秒级能跑完全部老功能"的基线？没有，这是你要建的第一堵墙。
2. 建那本"失败账"，一个个认着记——记它长什么样、根因在哪、怎么修。
3. 遇到"不认识的失败"，别急着抹平。单独记一本，它就是下一次喂食的原料。

一周之内再补三件事：

4. 把"基线定死"改成"灵活基线"。
5. 反馈从"过了/挂了"扩成多种状态，要有能力触发自动查涟漪。
6. 每月喂食一次，让失败到成功的经验账真正长下去。

## 下一篇预告

失败会认了、会喂了、基线会爬了——从战略到契约、从门禁到实现、从记忆到归因、从分工到测试，整套体系走到这里，也该抬起头，看看它自己站在什么位置。系列最后一篇，我们把前面十一座冰山叠起来看它的形状：**成熟度模型**——一个 AI 工程体系，从"能用"到"敢用"再到"依赖它"，到底要走过几级。

AI Harness Engineering 系列 · 第十一篇 · 王海涛（公众号：Jia言Yi行 · GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

驾驭 AI · AI Harness Engineering · 进击的测试

AI Coding给所有技术岗位带来的冲击加在一起都不如给测试带来的多，当产出远远大于传统流水线测试能力的时候，测试工作就同样的进化进击了，如果AI Coding是开发工程师的魔法，利用Agent构建一个自成长的Testing智能体就是测试工程师的魔法，老话说得好，能打败魔法的只有魔法~

 CTO

测试

人工智能

职业发展

建立测试基线并自成长，将失败转化为资产。通过失败分类、喂食闭环与基线自动爬升，系统越用越强。配合FMEA兜底，让测不到的风险也能可控。快速落地三步走，一周内见效，持续进化。

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

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

驾驭 AI · AI Harness Engineering · 进击的测试-腾讯云开发者社区-腾讯云

驾驭 AI · AI Harness Engineering · 进击的测试

驾驭 AI · AI Harness Engineering · 进击的测试

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐