上周五下午，我正对着Excel发呆，隔壁工位的老王探过头来：“还手动写呢？”

我抬头看他一眼，没说话，但表情大概写了几个字：不然呢？

老王笑了笑，扔过来一个链接：“看看我们组这周的数据。”

我点开一看，是他们组的周报。标题写着：AI辅助测试试点周报。下面是几行加粗的数据：

• 测试用例编写时间：平均减少52%
• 用例覆盖率：提升37%
• 测试设计人力投入：降低60%
• 上线后缺陷率：同比下降15%

我盯着这几行数字，沉默了三秒。然后抬头问老王：“你们组是不是偷偷招人了？”

老王乐了：“招什么人，就是给AI加了几个工作流。走，下午没事的话，我给你看看怎么弄的。”

那天下午，我坐在老王旁边，看他演示了一整套“AI写用例”的流程。看完之后，我只有一个感受：2026年了，还在手动写测试用例，确实有点说不过去了。

今天把老王的这套方法整理出来，希望能让和我一样还在Excel里挣扎的同学，找到点新思路。

一、传统写用例的痛，你中了几个？

先说说我们为什么还在手动写。

不是不想用工具，是试过几轮都不太满意。市面上的用例生成工具，要么太死板（只能根据接口文档生成，业务逻辑一复杂就抓瞎），要么太贵（按用例条数收费，测一个稍微大点的项目几千块钱就没了）。

所以我们一直沿用老办法：产品出需求文档，测试对着文档写Excel。写完了评审，评审完了修改，改完了再评审……一个版本下来，光写用例就花掉三分之一的时间。

这周接到一个需求：一个电商促销活动，满减+优惠券+会员折扣可以叠加，还有互斥规则。按正常节奏，我至少需要两天时间写用例：

• 第一天：读文档、画脑图、列测试点（半天）
• 第二天：把测试点转成Excel用例，写前置条件、步骤、预期结果（一天）
• 第三天上午：评审、修改（半天）

两天半，这还只是“写”，还没开始“测”。

老王他们组，同样的需求，半天就搞定了。

二、隔壁团队的“AI写用例”流水线

老王给我演示的这套流程，分四个步骤。我用那天下午看到的内容，一步步拆解出来：

第一步：喂需求文档

老王把产品的需求文档PDF扔进一个对话框。不是普通的ChatGPT，是他们自己搭的一个工作流，底层接的是大模型，但做了几个定制：

• 上传的文档会自动切片、向量化
• 系统里预置了“测试专家”的角色提示词
• 支持多轮对话，可以追问细节

老王先发了一条指令：“请分析这份需求文档，提取所有功能点和业务规则，按模块分类输出。”

等了大概一分钟，AI返回了一个结构化的列表：

【模块一：满减活动】
- 满200减20
- 满300减40
- 满500减100
- 不可与部分特价商品叠加

【模块二：优惠券】
- 新用户注册送10元无门槛券
- 满100减10元券
- 满200减30元券
- 券的有效期7天

【模块三：会员折扣】
- 普通会员：无折扣
- 黄金会员：95折
- 铂金会员：9折
- 钻石会员：85折

【叠加规则】
- 满减和会员折扣可叠加
- 优惠券和会员折扣可叠加
- 满减和优惠券互斥（不可同时使用）
- 特价商品不参与任何优惠

我一看，这提取得比我读两遍文档还全。

第二步：生成测试点

老王又发了一条指令：“基于这些功能点和规则，列出所有需要测试的场景，按功能、异常、边界、组合、性能分类。”

AI这次思考的时间长一点，大概两分钟，然后输出了一份“测试点清单”：

【功能测试】

• 满200减20是否正确计算
• 满300减40是否正确
• 满500减100是否正确
• 新用户10元券是否到账
• 券在有效期内能否使用
• 会员折扣计算是否正确

【异常测试】

• 订单金额刚好199（不满200），不触发满减
• 优惠券过期后不可用
• 会员等级不满足时不享受折扣
• 特价商品叠加优惠，应自动失效

【边界测试】

• 订单金额=200，正好触发满减
• 订单金额=200.01，触发满减
• 订单金额=9999.99，大额订单计算
• 同时拥有多张券，只能选一张

【组合测试】

• 满减+会员折扣叠加
• 优惠券+会员折扣叠加
• 满减+优惠券互斥（只能选一个）
• 会员折扣+满减+优惠券（三种同时存在时的互斥逻辑）

【性能测试】

• 高并发下优惠计算是否准确
• 库存扣减一致性

我数了数，一共87个测试点。比我平时自己列的多了将近一倍。

第三步：测试点转用例

这一步最让我惊讶。

老王说：“把这些测试点转成标准测试用例，包含前置条件、测试步骤、预期结果，按优先级排序，输出Excel格式。”

AI这次真的输出了一张Excel表，每一行是一条用例：

用例ID	模块	测试点	前置条件	测试步骤	预期结果	优先级
TC001	满减	满200减20	用户已登录，购物车有商品总价220元	1.进入结算页 2.选择优惠 3.查看订单金额	订单金额显示200元	P0
TC002	满减	满199不触发	购物车商品总价199元	同上	订单金额显示199元，无减免	P1
TC003	优惠券	新用户10元券	新注册用户，购物车有50元商品	1.进入结算页 2.选择优惠券 3.使用10元券	订单金额显示40元	P0
…	…	…	…	…	…	…

一共87条，整整齐齐。

老王点了下载，文件直接保存到本地。从扔文档到拿到Excel，整个过程不到半小时。

第四步：人工review和微调

当然，AI生成的用例不能直接用。老王花了半天时间，一条一条过：

• 删掉了一些“逻辑上存在但实际不可能”的场景（比如“用户未登录状态下领券”，实际系统里未登录根本进不到领券页面）
• 合并了一些重复的用例（比如满减门槛测了200、300、500，其实逻辑一样，不需要三条）
• 补充了几个AI漏掉的、历史版本出过问题的场景
• 调整了优先级，把最核心的P0用例标出来

半天时间，87条用例变成65条，但每一条都是精的。

三、数据对比：到底提效多少？

老王给我看了他们组试点两周的数据：

时间对比：

• 试点前：一个中型需求，测试设计+用例编写平均耗时2.5人天
• 试点后：同样的需求，0.5人天（AI生成0.5天 + 人工review 0.5天）
• 提效：约60%

覆盖率对比：

• 试点前：人工编写的用例，平均覆盖测试点约45个（以这个需求为例）
• 试点后：AI生成的测试点87个，人工review后保留65个
• 覆盖率提升：约44%

缺陷率对比：

• 试点前：上线后缺陷率基线值设为100%
• 试点后：上线后缺陷率降至85%
• 缺陷减少：15%

我问老王：“这个数据能稳定吗？还是只是这个需求特殊？”

老王说：“试点了两周，跑了5个需求，数据基本稳定。当然，不是每个需求都能提效这么多，那种特别简单、重复性高的需求，提效更明显；特别复杂、需要大量业务判断的需求，提效就少一些。但平均下来，50%左右是有的。”

四、这套方法能复制吗？需要什么条件？

看完演示，我最大的问题是：我们组能这么干吗？需要什么条件？

老王给我列了几个必要条件：

1. 需要一个能“理解业务”的AI

普通的ChatGPT也能干，但效果差很多。因为普通ChatGPT没有“上下文”，你每次问它都要重新解释一遍业务规则。他们用的是自己搭的工作流，把公司内部的业务文档、历史缺陷、需求模板都喂给AI做知识库，AI才能生成符合公司规范的用例。

替代方案：如果没有能力自己搭，也可以用现有的工具。比如通义灵码、文心快码都支持上传文档生成测试用例，虽然没他们定制的好，但也能用。

2. 需要一套“提示词模板”

老王给我看了他们的提示词库，针对不同场景有不同的模板：

• 功能测试生成模板
• 异常测试生成模板
• 边界值生成模板
• 组合场景生成模板
• 性能测试点生成模板

这些模板都是试错试出来的。比如最开始他们让AI“生成测试用例”，结果AI生成的太泛；后来改成“按功能、异常、边界、组合分类生成”，质量就好多了。

建议：可以先用通用提示词试，然后根据AI的产出不断优化提示词，慢慢积累自己的模板库。

3. 需要人工review的环节

这是最重要的。AI生成的用例，绝对不能直接用。

老王强调了三遍：AI是助手，不是替代者。它负责干“累活”——读文档、列清单、写模板，但最后拍板的必须是人。

• 删掉那些“逻辑上成立但实际上不存在”的用例
• 合并重复的用例
• 补充AI漏掉的、历史版本踩过的坑
• 调整优先级

这一步省不了。但他们组的数据显示，即使加上人工review的时间，总耗时还是比原来少了50%以上。

五、我们也试了一下：第一次就翻车

回到自己工位，我迫不及待地想试试。

找了个最近的需求文档，扔给ChatGPT，用老王的提示词模板：“列出所有测试场景，按功能、异常、边界、组合分类。”

AI很快返回了一份清单，看起来挺全。我照着清单转成Excel，越转越不对劲：

• “用户未登录状态下购买商品”——这个场景，系统里未登录根本进不到购买流程，无效
• “订单金额为负数”——这个输入框前端已经限制了只能输正数，无效
• “同时使用三张优惠券”——系统规则是最多只能用一张，无效

我这才明白老王为什么强调“人工review”这么重要。AI不懂你的系统长什么样，它只能根据文档“逻辑推理”，但文档里不会写“前端已经限制了什么”、“历史上哪些场景出过事”、“这次开发改了哪些代码”。

第一次尝试，我删了大概30%的无效用例。

但剩下的70%，确实帮我省了大量时间。原来要花两天写用例，这次从生成到review完，花了大概四个小时。

提效大概60%？差不多。

六、一些实用的技巧（踩坑总结）

试了两周，我自己也总结了几条小技巧：

技巧1：文档质量决定用例质量

AI生成用例的质量，很大程度上取决于你喂的文档质量。

如果文档写得乱七八糟、逻辑不清、前后矛盾，AI生成出来的用例也会乱七八糟。所以，如果发现AI生成的用例质量不行，先别怪AI，先看看是不是文档的问题。

有一次产品给的需求文档只有三行字，AI生成的用例全是“用户点击按钮，系统响应”这种废话。后来让产品补了详细的规则说明，再生成的质量就好多了。

技巧2：多轮对话比一次性生成更好

不要指望一次提示就能得到完美结果。

老王的做法是：先让AI列测试点，review一遍，把漏掉的重点场景补充进去，再让AI生成用例。这样来回两三轮，质量会越来越高。

我们现在的流程是：

1. AI生成测试点清单
2. 人工补充“历史缺陷场景”和“本次变更重点”
3. AI基于补充后的清单生成用例
4. 人工review、微调

技巧3：建一个“坏例子”库

我们开始收集那些AI生成得不好的例子：

• 生成了无效用例（比如“未登录下购买”）
• 漏掉了关键场景（比如并发场景）
• 优先级乱标（把P3标成P0）

把这些“坏例子”喂给AI，告诉它“下次不要这样写”，效果比单纯夸它好得多。

七、写在最后：不是取代，是提效

试点两周后，我们组也准备全面推广这套方法。

但有一个问题一直在讨论：AI会不会取代测试工程师？

我现在的看法是：不会取代，但会重新定义“测试工程师”的工作。

以前，测试的大部分时间花在“怎么写”上——怎么把需求转成用例，怎么把用例写清楚，怎么覆盖所有场景。现在，这部分可以让AI干，我们腾出手来干更重要的：

• 判断哪些场景真的重要（而不是逻辑上存在）
• 回忆历史版本踩过的坑（AI不知道这些）
• 和产品、开发对齐业务理解（AI理解不了“潜规则”）
• 设计复杂的组合场景（AI的逻辑推理还有限）

换句话说，测试工程师从“写手”变成了“主编” ——不再是亲手写每一行用例，而是把关AI写的用例，决定哪些该留、哪些该删、哪些该调。

这个转变，需要的技能不一样了，但价值更高了。

老王走之前说了一句话，我记在本子上了：

“以前我花80%的时间写用例，20%的时间思考。现在反过来，20%的时间写，80%的时间思考。”

这大概就是提效50%的真正含义——不是让工作变少，是让工作变值钱。

2026年了，确实不该再手动写测试用例了。