 本文是"AI 重塑软件研发"系列的第五篇。第一篇讲认知升级与分工瓦解，第二篇讲个人工作流，第三篇讲需求规格化，第四篇讲架构决策，本篇聚焦研发下游——当架构定好、代码生成后，测试环节如何被 AI 重构。

第四篇结尾，你手里有一份退款流程的 ADR（架构决策记录）——选了异步消息方案，定了组件边界、通信方式、消息体格式。

接下来自然的问题是：这些设计对不对？代码实现有没有 bug？集成后能不能跑通？

传统答案是测试工程师——写单元测试、集成测试、回归测试。但在 AI 时代，测试的工作方式正在被重构。AI 能帮你生成测试用例、自动执行测试、甚至自动定位 bug 根因，但它无法替你回答”这个场景值不值得测”“验收标准是什么”。

测试人员从”写用例的人”，正在变成”定义测试策略和验收标准的人”。

1. 从代码和契约自动生成单元测试

把第四篇的退款服务代码和第三篇的需求契约丢给 AI，让它输出： - 单元测试：针对每个 Service 方法的单元测试 - 边界条件测试：金额为 0、金额为 null、金额超限等 - 异常分支测试：超时、重试、熔断等场景

AI 产出的不是”最终测试集”，而是一份可执行的初稿——你在基础上补充业务场景，比从零写用例快得多。

“退款服务调用积分服务，如果积分服务超时怎么办？”

AI 可以根据组件接口定义和 ADR 中的架构约束，自动生成： - Mock 下游服务的测试桩 - 超时、重试、熔断的集成测试场景 - 消息队列的端到端测试（生产消息 → 消费消息 → 验证结果）

这是 AI 时代最有价值的测试场景之一。

AI 可以根据第三篇的需求契约（接口定义、输入输出规范），自动生成消费者驱动的合同测试： - 退款服务（消费者）声明它期望收到什么格式的消息 - 积分服务（提供者）验证自己的输出是否符合合同 - 不兼容的变更在集成前就被拦截

基于代码变更 diff，AI 可以自动分析： - 哪些测试用例需要更新 - 哪些新增代码没有对应测试 - 哪些测试用例已经过期（测试的代码逻辑已经被删了）

二、AI 做不了什么——测试决策中的”人味”

AI 可以生成 100 个测试用例，但它不知道哪些场景对用户最重要。

比如退款场景： - “退款成功后积分回退”——必须测，涉及钱 - “退款时用户同时修改收货地址”——可能不需要测，两个功能不相关 - “退款金额正好等于订单金额时的浮点精度”——必须测，财务场景

这个判断 AI 给不了，因为它不懂你的业务风险和用户影响面。

“退款功能做到什么程度算合格？”

这些验收标准不是技术问题，是业务决策。AI 可以建议，但不能替你决定。

AI 可以测试”接口返回对不对”，但它测试不了：

 - “用户操作流程是否顺畅” 

- “错误提示用户看得懂吗” 

- “页面加载速度用户能接受吗”

“我随便点点看会发生什么”——这种基于经验和直觉的探索性测试，AI 做不了。很多线上 bug 都是测试人员在自由探索中发现的，而不是按用例跑出来的。

核心观点：AI 提供测试执行力和覆盖率，人定义测试策略和验收标准。测试人员的不可替代性不在于”写用例”，而在于”知道该测什么、什么时候该放过”。

第一步：从契约和架构定义测试策略

拿到第三篇的契约和第四篇的 ADR，确定：

 - 测试层级：单元测试、集成测试、契约测试、E2E 测试分别覆盖什么 

- 验收标准：每个关键场景的通过条件 

- 风险优先级：哪些场景必须 100% 覆盖，哪些可以放低优先级

根据这份退款契约和退款服务的代码，生成 JUnit 5 单元测试，覆盖正常流程和所有异常分支。同时生成集成测试，Mock 积分服务和发票服务。

第三步：人补充探索性测试和验收标准

AI 生成的测试是”已知未知”——它知道哪些场景可能有问题，但不知道”未知的未知”。

 - 探索性测试：基于经验自由探索 - 定义验收标准：什么算”通过” 

- 用户场景验证：从用户角度走一遍流程

- 识别测试代码中的坏味道（重复、硬编码、脆弱测试）

AI 时代，测试用例不仅是验证工具，更是活的文档。

传统的做法：产品写 PRD → 开发看 PRD 写代码 → 测试看 PRD 写用例。三份文档，三种理解。

AI 时代的做法：契约 → AI 生成代码 + AI 生成测试用例。测试用例本身就是需求的可执行版本——跑过测试用例，就等于验证了需求。

契约测试的输出本身就是 API 文档：输入什么、输出什么、什么情况下报错、错误码含义。比 Swagger 更可靠，因为它是可执行的。

集成测试和契约测试的结果，直接反映架构设计是否合理： 

- 如果集成测试很难写 → 可能耦合度太高 

- 如果契约测试频繁失败 → 可能接口设计不稳定 

- 如果 E2E 测试太慢 → 可能测试策略需要调整

和架构决策一样，重要的测试决策也应该有记录：

TDR-001：退款流程采用契约测试验证

 退款流程涉及多个服务，同步调用链路过长，需要异步解耦。集成测试难以覆盖所有异常场景。

 采用消费者驱动的契约测试（Pact），在 CI 流水线中自动验证。

好处：服务间接口变更可提前发现，减少集成时 bug

代价：需要学习 Pact 框架，增加 CI 流水线复杂度

风险：契约测试只能验证格式，不能验证业务逻辑正确性

AI 能让覆盖率轻松到 90%+，但覆盖率不是目的。关键场景 100% 覆盖，非关键场景适当放过。别被覆盖率数字绑架。

加入 AI 辅助测试环节：代码提交 → AI 生成/更新测试 → 自动执行 → 生成覆盖率报告 → 人工审查关键测试。注意控制流水线时长，别因为跑测试拖慢发布节奏。

AI 可以自动生成测试数据，但测试数据也需要治理：脱敏、版本化、按需生成。别让测试数据成为新的技术债。

嵌入敏捷流程：Sprint 规划时定义测试策略，Sprint 开发时 AI 生成测试，Sprint 结束时契约测试自动跑。Retrospective 时复盘：这次哪个 bug 如果让 AI 提前测能发现？

下一篇（系列之六）将聚焦部署与运维——当代码测试通过后，AI 如何辅助做灰度发布、流量切换、线上监控和故障恢复？我们继续拆解。

系列定位： 本文是"AI 重塑软件研发"系列的第五篇。第一篇讲认知升级与分工瓦解，第二篇讲个人工作流，第三篇讲需求规格化，第四篇讲架构决策，本篇聚焦研发下游——当架构定好、代码生成后，测试环节如何被 AI 重构。

从人找 Bug 到 AI 找 Bug：AI 重塑下的测试新范式

人工智能

测试

职业发展

AI重构软件研发下游测试流程，覆盖单元测试、集成测试与契约测试自动生成，辅助测试人员从写用例转向定义策略与验收标准。强调AI提供执行覆盖率，人负责业务判断与探索性测试。测试用例即文档，TDR记录决策。落地清单包括AI生成测试、Pact验证、验收标准定义，为部署运维篇预热。

数据一致性

消息队列

人机协作

单元测试

集成测试

回归测试

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

从人找 Bug 到 AI 找 Bug：AI 重塑下的测试新范式

从人找 Bug 到 AI 找 Bug：AI 重塑下的测试新范式

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐