当迭代速度越来越快,你的手工用例还跟得上需求变更吗?
一、问题背景:迭代越快,用例越“旧”
在敏捷开发模式下,每个迭代都有新需求上线、旧功能下线、业务规则调整。但与之对应的手工测试用例库,却往往停留在几个月甚至一年前的状态。
你遇到过这些场景吗?
功能逻辑已经改了,用例里写的“预期结果”还是老逻辑
某个功能已经下架了,用例库里还有几十条相关用例
一个“登录”功能,被不同人写了N条高度相似的用例
传统做法是定期人工Review——但面对成百上千条用例,人工Review不仅耗时,还极易遗漏。更麻烦的是,每个迭代的需求文档只覆盖“改了什么”,并不会告诉你“哪些旧用例失效了”。
AI能不能帮上忙?
二、核心思路:不是“全量扫描”,而是“精准打击”
很多人在尝试用AI做用例维护时,第一个想法是:把全量用例和全量需求丢给AI,让它找出过时的。
这个思路有两个致命问题:
需求文档从来不是全量的——每个迭代只有增量需求,没有“全量需求”这回事
全量扫描会让AI输出几百条噪音——老功能没变但措辞老了,AI会误报,你根本看不过来
正确的做法是模块化精准打击:
只用“本次迭代涉及的功能模块”去圈定“对应的用例子集”,然后拿这些用例与“当前线上真实现状”比对,而非与“需求文档”比对。
为什么是“线上真实现状”而不是“需求文档”?因为开发可能改了接口字段但没写进需求,产品可能调整了规则但更新滞后——只有线上环境/接口文档才是“事实标准”。
三、WorkBuddy Skill:把经验固化成“数字资产”
在WorkBuddy中,Skill(技能)就是你手把手教AI做一件具体事情的“教程说明书”。
你可以把“用例过时检测”的逻辑固化为一个Skill——配置好后,每月1号自动运行,你只需要看结果就行。
Skill的核心价值在于:
| 对比维度 | 直接对话AI | 固化Skill |
|---|---|---|
| 记忆 | 聊完就忘 | 经验永久固化 |
| 工具权限 | 手动复制粘贴 | 自动读取Excel/接口文档 |
| 输出格式 | 每次不一样 | 标准化表格 |
| 自动化 | 每次手动触发 | 定时自动执行 |
四、实操落地:三层筛选流程
整个Skill的执行逻辑分为三层筛选,确保输出结果精准、可操作。
第一层:范围圈定(从5000条→50条)
读取本次迭代的TAPD需求,提取核心功能模块关键词(如“优惠券”、“退款”),只在Excel用例的“所属模块”列进行匹配筛选。
关键原则:未命中的用例直接忽略,不进行分析。
第二层:基线比对(从50条→5条)
拿筛选出的用例的“预期结果”和“断言字段”,去调用MCP连接当前测试环境的接口文档(Swagger)或线上页面。
比对逻辑:
用例中的字段名在最新接口文档中已不存在 → 标记【字段废弃】
用例中的业务规则与当前接口逻辑相悖 → 标记【逻辑冲突】
当前环境该功能已完全不存在 → 标记【功能下架】
第三层:人工兜底(最终输出5条)
只把有冲突的用例推送给测试人员确认,并附上AI建议(如“用例#102的断言字段‘status=1’在当前环境已改为‘state=SUCCESS’,建议修改”)。
最终工作量只有5条,而不是5000条。
五、Skill完整配置(可直接复制使用)
以下是在WorkBuddy中创建该Skill的完整配置:
Skill名称:月度用例过时检测(变更影响圈定版)
Skill描述:自动提取本迭代需求变更模块,圈定关联用例,比对线上真实验证逻辑,输出待维护清单。
系统提示词(System Prompt):
markdown
你是一位拥有10年经验的测试资产治理专家。请严格按照以下"三步法"执行任务,严禁发散: ### 第一步:读取需求,提取变更锚点(探照灯) 1. 通过MCP读取我提供的【当前迭代需求文档链接/TAPD ID】。 2. 提取需求中明确提到的**核心功能模块名**(例如:"优惠券中心"、"退款审批流")和**关键业务实体**(例如:"订单状态"、"折扣率")。 3. 忽略需求中未提及的任何模块。输出提取到的关键词列表,作为后续筛选的【锚点】。 ### 第二步:圈定关联用例(精准命中) 1. 通过MCP读取我指定的【主用例Excel文件路径】。 2. 只扫描Excel中"所属模块"列包含【锚点】关键词的那些行。 3. 未命中的行(全量系统中的其他模块),直接忽略,不进行分析。 ### 第三步:二次校验——与"线上真实现状"比对 1. 对于第二步圈定出来的所有用例,提取它们的"用例标题"和"预期结果"中的**断言字段**(如:状态码、返回字段名、界面按钮文字)。 2. 通过MCP调用【当前测试环境接口文档(Swagger链接)或线上页面截图】。 3. 执行逻辑比对: - 如果用例中的字段名在最新接口文档中已不存在,标记为【字段废弃】 - 如果用例中的业务规则描述与当前接口文档中的注释逻辑相悖,标记为【逻辑冲突】 - 如果当前环境下该页面/接口已完全不存在,标记为【功能下架】 ### 最终输出格式(强制要求) 请只输出以下Markdown表格,不得添加任何开场白或结束语: | 序号 | 用例ID/行号 | 原预期结果/断言 | 当前线上真实逻辑 | 问题类型 | AI建议操作 | |------|------------|----------------|-----------------|---------|-----------| | 1 | [行号] | [原文] | [实际] | 字段废弃/逻辑冲突/功能下架 | 建议修改为/建议删除 |
六、使用前需要填写的3个配置项
| 配置项 | 说明 | 示例 |
|---|---|---|
【当前迭代需求文档链接/TAPD ID】 | 本次迭代的需求来源 | https://tapd.woa.com/.../story/1010... |
【主用例Excel文件路径】 | 全量手工用例存放位置 | D:\测试资产\全量手工用例_v2026.xlsx |
【当前测试环境接口文档】 | Swagger/API文档地址 | http://test-api.xxx.com/v2/api-docs |
七、落地节奏建议
| 阶段 | 时间 | 动作 |
|---|---|---|
| 配置 | 第1天 | 填写3个配置项,在WorkBuddy中创建Skill |
| 验证 | 第2天 | 手动点击“运行”,检查输出是否只针对相关模块(5-15条为佳) |
| 自动化 | 下个月1号 | 将Skill挂到Automations定时任务,设置每月1号9:00自动执行 |
八、总结
手工测试用例的“过时”问题,本质是“资产维护速度跟不上需求变更速度”。通过WorkBuddy Skill,我们可以把“变更影响面分析”这一测试专家的核心能力固化为可自动执行的数字资产。
核心方法论就一句话:
拿“迭代变更点”当探照灯,只照相关的用例;拿“线上真实现状”当标尺,只量有冲突的细节。
这套方案的价值在于:
精准:不搞全量扫描,只处理变更影响的模块
低成本:AI自动完成90%的分析工作,人工只需确认5-15条结果
可沉淀:Skill一旦写好,就是团队的永久资产,换人也不怕
AI赋能的本质,不是用AI替代人,而是把人的经验固化为可重复、可扩展的自动化能力。用例维护这件事,值得让AI替你“先跑一遍”。