上周五下午，我正对着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生成用例。这样来回两三轮，质量会越来越高。
我们现在的流程是：
- AI生成测试点清单
- 人工补充“历史缺陷场景”和“本次变更重点”
- AI基于补充后的清单生成用例
- 人工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 私教服务，用于个性化能力提升与工程实践指导。
