上周五下午，我正对着 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 表，每一行是一条用例：

一共 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 年了，确实不该再手动写测试用例了。

关于我们

霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。