生成式 AI 能全部替代传统软件测试吗？——偏差放大、代码膨胀与关键基础设施的验证之道

一句话结论：生成式 AI 不能全部替代软件测试，但会彻底重构测试——它最适合做“大量产出候选测试和候选代码”的一方，而“判定对错”的那一方必须独立于模型，并且尽量是确定性的。

用 AI 测 AI 确实会放大偏差。原因不是 AI “不够聪明”，而是同源：同一份理解、同一套训练数据、同一种思维盲区，写出的代码和测试会在同一个地方一起错（来源1、2、3）。

代码膨胀会把瓶颈从“写”推到“审”。出路不是让人读得更快，而是让需要人读的东西变少：人审规格与风险，机器做穷举、变异、差分与证明（来源6、7、11、13）。

对关键基础设施，本文判断：现阶段不应让生成式 AI 全盘生成核心代码；可行的路线是“人写规格、AI 写代码和证明、小型可信检查器把关”，责任始终由人和组织承担（本文分析）。

素材说明：本文依据软件工程经典实验、2024—2026 年的公开研究与行业报告、CrowdStrike 官方根因分析，以及航空软件标准 DO-178C/DO-330 的公开解读写成。各项数据的口径与限定条件在文中注明；凡属推论，标注“本文分析”。

一、先给结论：替代的不是“测试”，而是“测试中的体力活”

要回答“能不能全部替代”，先拆开测试到底在做什么。一次完整的测试活动至少包含五件事：

1. 理解意图：系统“应该”做什么？——需求、规格、业务规则。
2. 设计用例：从无穷多的输入中挑出最可能暴露问题的那些。
3. 执行与观察：运行程序，收集输出、日志、性能、资源消耗。
4. 判定对错：输出是对的还是错的？——这就是“测试预言”（test oracle）。
5. 承担责任：对“可以上线”这个结论签字负责。

本文分析：生成式 AI 在第 2、3 步已经很强，在第 1 步能当好助手，在第 4 步最危险，在第 5 步原则上不能替代。所以准确的说法是：AI 会替代测试中大量的体力劳动，但替代不了“独立判定”和“承担责任”——而这两件恰恰是测试存在的根本理由。

二、传统软件测试：人机协同了几十年，还有哪些问题没解决

传统测试已经是“人工 + 自动化”的协同体系：人负责探索性测试、业务验收和风险判断，机器负责单元测试、回归测试、接口测试、性能压测和静态扫描。但下面这些老问题，几十年来一直没有被根治。

1. 测试预言问题：知道“怎么跑”，不知道“对不对”

自动化可以生成无数输入，却很难自动知道每个输入的正确输出应该是什么。传统的自动生成工具（如 Randoop、EvoSuite）常把程序当前的实际行为直接写成断言——如果代码本身就错了，测试只会把错误“固化”下来（来源2）。这一点后面会成为理解“AI 放大偏差”的钥匙。

2. 穷尽不可能：测试只能证明有错，不能证明无错

计算机科学家 Dijkstra 的名言是：测试能证明缺陷存在，但永远不能证明缺陷不存在。即便是航空标准要求的 MC/DC 覆盖，一个含 6 个条件的判断有 64 种组合，满足 MC/DC 只需要 7 个测试（来源15）——覆盖是一种“有代表性的抽样”，不是穷举。

3. 需求本身就有歧义或缺失

很多缺陷不是“代码没按需求写”，而是“需求本来就没写清楚”。Knight 与 Leveson 的经典实验中，研究者事先专门消除了规格里的歧义，但 27 个独立团队仍然在相同的“难点”上犯了等价的逻辑错误（来源1）。规格不清，测试只能对着一个模糊的靶子开枪。

4. 覆盖率高 ≠ 测得好

2024 年 7 月 CrowdStrike 事件是最好的反面教材。根据其官方根因分析：新模板类型定义了 21 个输入字段，但调用代码只提供 20 个；用于测试的 12 个静态用例在第 21 个字段上全部使用了通配符，因此测试全部通过；内容校验器本身也有逻辑错误；直到一次更新首次对第 21 个字段使用非通配条件，传感器发生越界读并导致系统崩溃（来源10）。测试有、校验有、压测也有，但它们共享了同一个错误假设。

5. 测试的维护成本与“不稳定测试”

自动化测试本身也是代码，会过时、会脆弱、会随机失败。大型工程组织普遍要为不稳定测试（flaky tests）专门建隔离、重跑和统计机制；被噪声淹没的失败，可能正是真正的缺陷。

6. 环境、配置与集成的组合爆炸

单元测试全绿，系统照样可能在某个配置、某个版本组合、某种数据分布下出事。CrowdStrike 出问题的就不是传感器代码本身的一次发布，而是一份“配置内容”的更新（来源10）。

这些问题的代价是真实的：美国信息与软件质量联盟（CISQ）估算，2022 年美国劣质软件造成的成本至少 2.41 万亿美元（来源17）。

三、生成式 AI 写代码，偏差从哪里来

生成式 AI 本质上是在给定上下文下预测最可能的下一个 token。这带来三类结构性偏差：

本文分析：所以“生成的软件总会有偏差”这个判断是成立的。关键问题是：偏差能不能被一个独立的过程发现？

四、用生成式 AI 来测试，会不会放大偏差？

定义会——如果测试和代码来自同一个信息源、同一个模型、同一种理解。这是本文最核心的论点，有三组证据支持。

证据一：独立开发也会“一起错”（1986）

N 版本编程的设想是：让多个团队按同一规格独立开发，投票表决，假设它们会独立失效。Knight 与 Leveson 让两所大学的学生独立写出 27 个版本，用 100 万个输入测试。结果：每个版本单独看都极其可靠，但多个版本在同一输入上同时失效的次数远超独立假设，最极端的一个测试输入让 8 个版本同时失败（来源1）。后续分析发现，程序员会在问题的“难点”上犯等价的逻辑错误。

本文分析：人类团队尚且如此，同一个大模型写代码再写测试，“独立性”只会更差——它们几乎是同一个“程序员”。

证据二：LLM 写的断言主要“照抄”代码的实际行为（2024—2026）

卢森堡大学团队针对 24 个 Java 仓库做了对照实验，结论是：基于 LLM 的测试生成方法主要捕获的是程序的实际行为，而非预期行为，因此难以发现缺陷；同时 LLM 生成断言的能力强于判断断言对错的能力（来源2）。

这就是“镜子效应”：让 AI 读代码写测试，它很可能把 bug 当成功能写进断言。测试全绿，信心上升，缺陷被“认证”了。

证据三：LLM 评审偏爱自己写的东西（2024）

研究发现，GPT-4、Llama 2 等模型能以不低的准确率认出自己的生成内容，而且自我识别能力越强，自我偏好越强——在人类认为质量相同的情况下，模型会给自己的输出打更高分（来源3）。用同一个模型做“代码评审员”，存在系统性放水的风险。

放大是怎么发生的

本文分析：偏差放大通常经过四步循环——

1. 模型对需求产生一个误解；
2. 按误解写出代码；
3. 读着这份代码写出测试，测试与代码“完美一致”；
4. 覆盖率、通过率等指标全部漂亮，组织因此降低了人工审查力度。

第 4 步最致命：它不是让错误多了一个，而是让组织对错误的“免疫力”下降了。DORA 2024 报告的发现与此一致：AI 采用率每提高 25%，代码质量自评约提升 3.4%，但交付稳定性估计下降 7.2%（来源7）。

但 AI 测试并非必然放大偏差：关键在“谁当裁判”

Meta 的 TestGen-LLM 给出了另一种做法：LLM 只负责生成候选测试，候选必须依次通过一组与模型无关的确定性过滤器——能编译、能稳定通过、确实提高了覆盖率——才会被推荐给工程师。在 Instagram 的评估中，75% 的候选能正确构建，57% 稳定通过，25% 提高了覆盖率；在测试马拉松中，它改进了所应用类的 11.5%，73% 的推荐被工程师接受上线（来源4）。

本文分析：这组数字说明两件事。第一，多数 AI 产出会被过滤掉——如果没有过滤器，这些就是噪声甚至错误。第二，过滤器只能保证“有改进”，不能保证“断言正确”，所以人对断言语义的把关仍不可少。

“去相关化”五原则

五、AI 代码量大、不简洁，人类读不过来怎么办

这个担心有数据支撑。GitClear 分析了 2020—2024 年 2.11 亿行代码变更：重构（移动）行从 2021 年约 25% 降到 2024 年不足 10%，复制粘贴行从 8.3% 升到 12.3%，2024 年含 5 行以上重复块的提交频率增长约 8 倍（来源6）。METR 2025 年的随机对照实验中，16 位资深开源开发者在自己熟悉的大型仓库上使用 AI 后，完成任务反而慢了 19%，而他们自己以为快了 20%（来源8）。

需要说明的是，METR 在 2026 年 2 月表示，这一结果反映的是 2025 年初的工具；新一轮实验显示开发者“很可能已被加速”，但由于样本选择偏差，数据只是很弱的证据（来源9）。也就是说：生成速度在快速提升，但“审查与验证”的成本并没有同步下降。

本文分析：解决办法不是“让人读得更快”，而是从四个方向让“必须由人逐行阅读的代码”变少。

1. 在生成侧控制体积：把简洁写进验收标准

• 设定复杂度和变更体积预算：单次变更超过阈值，直接要求拆分。
• 强制复用：先检索已有函数与组件，禁止“另起炉灶”的重复实现。
• 鼓励删除：把“删掉了多少代码”与“新增了多少功能”同等计入评价。
• 小批量提交：DORA 指出 AI 容易导致更大的变更批次，而批次越大越难审、越不稳定（来源7）。

2. 在审阅侧分级：人审风险，不审字符

• 按后果分级：涉及资金、权限、数据删除、并发、加密的代码必须人工深审；样板代码、UI 文案、测试脚手架可抽查。
• 审规格与差异，而不是审全文：先确认“它应该做什么”的规格，再看实现是否偏离。
• 让 AI 做审阅的“分诊员”：解释变更、标出可疑点、列出受影响的调用链——但结论由人下。

3. 用机器去“读”代码：变异测试进入代码评审

Google 把变异测试做成了代码评审的一部分：只对本次改动的代码生成变异体，过滤掉开发者不关心的变异，每行、每次评审限量展示。该系统覆盖超过 24,000 名开发者、1,000 多个项目；评估涉及 76 万次代码变更，从近 1,700 万个变异体中只向评审展示了约 200 万个（来源11）。另一项研究显示，被展示的变异体中有 38% 通过修改代码或增加测试得到解决；被评审者认可的变异体中，60% 得到解决（来源12）。

这是一种很好的“注意力分配”：机器从海量可能的缺陷里挑出少数“你的测试没抓住的”，人只需要回应这几个。

4. 让 AI 证明，而不是让人阅读

剑桥大学的 Martin Kleppmann 在 2025 年 12 月提出：与其让人审查 AI 生成的代码，不如让 AI 证明它生成的代码是正确的——证明检查器是一小段本身经过验证的代码，AI 编造的无效证明会被直接拒绝（来源13）。他给出的历史成本对比是：2009 年 seL4 微内核约 8,700 行 C 代码，证明其正确性用了约 20 人年、20 万行 Isabelle 证明——相当于每行实现需要 23 行证明、半个人日（来源13）。

这一方向正在变得可行。2025 年 9 月发布的“vericoding”基准包含 12,504 个形式化规格，现成大模型的成功率在 Lean 中为 27%、Verus/Rust 中为 44%、Dafny 中为 82%；纯 Dafny 验证任务的成功率在一年内从 68% 升至 96%（来源14）。

Kleppmann 同时提醒：证明自动化之后，难点转移到规格本身是否正确——你证明的性质是不是你真正关心的性质（来源13）。本文分析：这恰好把人放回了最该在的位置：人不再逐行读实现，而是读一份短得多、精确得多的规格。

六、重要基础设施软件，到底应该怎么测

关键基础设施（电力、通信、金融清算、交通、医疗、航空）的共同特征是：失效后果不可接受，且难以快速回滚。对这类软件，测试的目标不是“发现大部分缺陷”，而是“为不存在不可接受的缺陷提供充分证据”。

1. 先看航空业怎么做：DO-178C 与 DO-330

航空机载软件按失效后果分为 A—E 五级。A 级软件除语句覆盖和判定覆盖外，必须达到 MC/DC 覆盖，即证明每个条件都能独立影响判断结果（来源15）；验证活动还包括基于需求的测试、鲁棒性测试，以及与级别相称的独立性要求。

更关键的是工具鉴定。按照 DO-178C 与配套的 DO-330，如果某个工具取代、减少或自动化了保证过程，而其输出又没有被验证，就必须对工具本身进行鉴定（来源16）。工具按三类标准区分：输出成为机载软件一部分、可能引入错误的工具（标准1）；自动化验证、可能漏检错误的工具（标准2、3）。用于生成 A 级软件的工具需要最严格的 TQL-1 鉴定。

本文分析：把生成式 AI 放进这个框架，它属于“标准1”工具——它的输出直接成为软件的一部分。而一个非确定性、无法完整说明其需求与行为的大模型，现实中几乎不可能按 TQL-1 被鉴定。因此唯一可行的路径是：不信任工具，而是对其输出进行与人工代码同等甚至更严格的完整验证。这已经回答了“能不能全盘生成”的一半。

2. 再看 CrowdStrike 教训：配置也是代码，测试器也要被测试

定义CrowdStrike 事后采取的措施几乎就是一份关键系统测试清单（来源10）：

• 在编译期校验模板输入字段数量；
• 在运行时增加数组边界检查；
• 对每个字段使用非通配条件的自动化测试；
• 修复并扩充内容校验器自身的检查；
• 对模板实例进行模糊测试；
• 分阶段、分环发布，每一环都有观察期，并把发布控制权交给客户。

本文分析：这份清单的共同精神是“不要只有一道防线，而且各道防线不能共享同一个假设”。这与第四节的“去相关化”原则是同一回事。

3. 关键基础设施软件的纵深验证框架（本文分析）

七、能不能用生成式 AI 全盘生成代码？

本文分析：答案取决于软件的风险等级，可以分成三档。

第一档：低风险软件——可以大比例生成。 内部工具、原型、一次性脚本、营销页面。失效代价小、容易回滚，“生成 + 自动化测试 + 抽查”即可。

第二档：一般业务系统——AI 生成，强验证兜底。 电商、办公、一般业务应用。可以让 AI 承担大部分编码，但必须配套：独立于实现的测试生成、变异测试、安全扫描、小批量提交、按风险分级的人工评审。Veracode 的 45% 数据意味着，不做安全验证就上线是不可接受的（来源5）。

第三档：关键基础设施——现阶段不应全盘生成核心代码。 理由有三：

1. 无法鉴定：生成式 AI 作为“输出即软件”的工具，无法满足 DO-330 这类最严格的工具鉴定要求（来源16）。
2. 无法独立：AI 测 AI 存在同源偏差，而关键系统恰恰最依赖验证的独立性（来源1、2、3）。
3. 无法问责：事故发生时，监管、法律和公众要求的是一条清晰的责任链，而“模型生成的”不是一个可接受的答案。

但这不等于关键系统要拒绝 AI。在关键系统里，AI 最有价值的位置是验证侧而非生成侧：生成海量测试候选、构造模糊测试输入、辅助写形式化证明、做静态分析告警的分诊、维护需求与测试的追溯关系。

一条值得押注的路线：可验证的生成

把 Kleppmann 的设想与 vericoding 的进展合在一起，可以得到一条面向关键软件的新路线（来源13、14）：

1. 人用形式化或半形式化的语言写出规格：系统必须满足的安全性、活性和业务不变量；
2. AI 同时生成实现代码与正确性证明；
3. 一个小型、可信、经过验证的检查器判定证明是否成立；
4. 人审查的对象从数万行实现，缩小为几百行规格。

在这条路线上，AI 越“会编”越没关系——编造的证明过不了检查器。真正需要警惕的风险变成了一个：规格写错了。所以未来关键软件工程师最核心的能力，很可能不是写代码，而是写规格、审规格。

八、对银行与金融 IT 的启示（本文分析）

银行核心系统、支付清算、反洗钱与风控模型，都是事实上的关键基础设施。几点建议：

• 建立分级清单：明确哪些系统允许 AI 大比例生成，哪些只允许 AI 参与测试与审查；把这一分级写进研发制度，而不是留给各团队自行判断。
• 把“独立验证”制度化：AI 生成的代码，测试必须由不同来源生成，验收用例由业务与测试团队定义；禁止同一模型“自写自测自评”。
• 度量要换：不再只看覆盖率和通过率，引入变异得分、缺陷逃逸率、变更失败率、回滚次数。
• 配置与规则即代码：风控规则、参数表、路由配置的变更，与代码变更执行同等的测试、灰度与回滚要求——CrowdStrike 就是前车之鉴。
• 培养“规格工程师”：投资形式化方法与属性测试能力，从清算对账、额度控制、利息计算这类规则清晰的模块开始试点。

九、结语

生成式 AI 让“写出代码”变得几乎免费，于是软件工程中真正稀缺的东西浮出水面：知道什么是对的，并能证明它是对的。测试的本质从来不是“跑用例”，而是在开发者之外建立一个独立的判断。AI 可以让这个判断更快、更全面，但不能让它不再独立。

所以，与其问“AI 能不能替代测试”，不如问：在我的系统里，谁来当那个不会被说服的裁判？ 对普通软件，它可以是编译器、测试和抽查；对关键基础设施，它应该是规格、证明检查器，以及愿意签字负责的人。

事实来源

1. Knight & Leveson（1986）（来源1）：27 个独立版本、100 万次测试、同时失效远超独立假设、最多 8 个版本同时失败。
2. Konstantinou 等（2024/2026）（来源2）：LLM 测试生成主要捕获实际行为；传统工具断言镜像实际行为。
3. Panickssery 等（2024）（来源3）：LLM 自我识别与自我偏好。
4. Meta TestGen-LLM（2024）（来源4）：75%/57%/25%/11.5%/73% 等数据。
5. Veracode（2025）（来源5）：45% 不安全实现、Java 超 70%、CWE-80 失败率 86%、模型变大未改善安全性。
6. GitClear（2025）（来源6）：2.11 亿行变更，重构行与复制粘贴行变化，重复块增长约 8 倍。
7. DORA 2024（来源7）：AI 采用率与交付稳定性、吞吐量、代码质量的关系。
8. METR（2025、2026）（来源8、9）：19% 变慢及其后续更新与局限。
9. CrowdStrike 根因分析（2024）（来源10）：21 与 20 个输入不匹配、12 个通配测试用例、校验器逻辑错误及整改措施。
10. Google 变异测试（2021—2023）（来源11、12）：规模与变异体解决比例。
11. Kleppmann（2025）（来源13）：AI 推动形式化验证主流化、seL4 成本数据。
12. vericoding 基准（2025）（来源14）：12,504 个规格及各语言成功率。
13. DO-178C/DO-330 解读与 FAA AC 20-115D（来源15、16）：MC/DC 要求与工具鉴定。
14. CISQ（2022）（来源17）：劣质软件成本 2.41 万亿美元。

本文推论部分（非来源表述）：第一节测试五要素拆解、第四节“放大循环”与“去相关化五原则”、第五节四个方向的建议、第六节第 1 条中关于生成式 AI 工具鉴定的判断及纵深验证框架、第七节三档划分与“可验证的生成”路线、第八节与结语。

本文不构成任何工程认证、合规或投资建议；关键系统的验证方案应以所在行业的适用标准与监管要求为准。

（内容由AI生成，仅供参考）