★ FEATURED ARTICLE 这两年我观察和测试同行聊AI落地发现一个很有意思的分化一部分人已经把AI用成了“深度搜索引擎”搜索资料、问知识点、查报错含义遇到具体任务还是自己动手另一部分人停留在“问一嘴就跑”的尝鲜阶段得到的回答时好时坏慢慢就觉得AI没用。真正的差别其实不在工具选得有多前沿也不在Prompt写得有多花哨而在于有没有把自己手头的工作设计成一条“工作流”。在测试这个岗位上我们每天真正消耗时间的地方极其固定写用例、分析Bug、写自动化脚本、出测试报告。这四个场景有一个共同特点——输出物标准化程度高、上下文重复性强、质量要求明确。而大语言模型这类通用AI工具恰恰最擅长处理“输入相对固定、输出有明确规则”的活儿。问题在于绝大多数人每次都是从零开始跟AI对话上下文支离破碎跑出来的结果自然忽好忽坏。这篇文章想分享的是我目前在用的四套AI工作流模板分别对应上面四个高频场景。每一套都包含输入规范、处理链路、输出校验三部分。你拿回去改改就能用适合从手工测试转向自动化、或者刚接手质量平台的测试工程师参考。我会把踩过的坑和绕过的弯路也一并写出来。1. 为什么测试工程师的AI应用总卡在“问一嘴”阶段1.1 即兴式提问的四个通病我见过很多刚接触AI的测试同事第一周热情很高什么都想让它干。两周后热情骤降原因是同样的请求AI今天给出的结果能直接用明天给出的就完全不能看。这种“不稳定感”让人很没底。抛开模型本身的随机性这种不稳定主要来自四个使用习惯问题。上下文一次性。每次对话都是新的开始AI不知道你的项目背景、不知道你用的技术栈、不知道你们团队的用例格式规范。你问它“帮我写一个登录功能的测试用例”它默认写成“输入用户名、输入密码、点击登录、验证登录成功”——这种正确的废话不需要AI网上随便都能搜到。输出无结构。提问的时候自己都没想清要什么AI就给一堆泛泛而谈的要点。你要的是能直接粘贴进用例管理系统的标准格式它给你一份散文。没有校验环节。AI生成的用例覆盖度够不够它自己说的“已完成”是真的完成还是漏掉一半没有任何人拦一道。AI有一个惯性就是倾向于给你一份看起来很完整、实际漏掉细节的东西。不做沉淀。这次问得好下次还是从零开始。好的问题、好的上下文描述、好的输出示例全都随对话窗口关闭而消失。这四个通病叠加在一起结果就是AI在测试工程师手里变成了“高配版搜索引擎”——用是能用但没有带来效率的指数级提升。1.2 工作流设计到底是什么工作流设计本质上就是把“和AI的一次性对话”改造成“一条可重复执行的流水线”。我常用一个比喻即兴提问是自己在家里炒菜每次从洗菜切菜开始菜谱全靠手感工作流设计是开中央厨房把菜谱标准化、配料定量化、出锅有检查单。具体到AI上就是三段式结构。输入规范。每次进入工作流先要求用户按固定结构投喂信息。该填版本填版本该给日志给日志该贴数据结构贴数据结构。缺了什么AI先反问不全不给结果。处理链路。把一个大任务拆成几个串行的小步骤每步都有明确的输入输出。不让AI一口气生成“最终成品”而是让它先出中间产物你校验后让它继续。输出校验。每个工作流在最后都有一个检查清单让AI对照清单自检或者由你抽检。不符合要求就让它返工而不是直接拿走用。这套三段式结构四个模板共通只是每段的细节不同。1.3 值不值得做成模板先看“三高”标准也有同事问我是不是所有工作都能套个工作流我的判断标准很简单一个场景值不值得模板化看“三高”。高频是不是每周都要做写用例、修Bug、报告这些是测试工作的肌肉记忆天天都在做。而“用AI帮我想个团建方案”这种半年一次的事不值得建流程。高重复输入输出结构是不是很像同一类任务的输入场景和输出物格式类似才有标准化空间。比如每次写Bug分析都是“描述日志期望实际”的组合。高标准化产出物是不是有明确的合格标准测试用例、Bug报告、测试总结这些都有相对固定的模板和要求AI有据可依。三个条件都满足就值得花一两个小时把工作流设计出来。设计一次长期复用。2. 模板一用例设计工作流——从需求碎片到评审清单一条龙2.1 输入预处理先让需求“瘦身”以前我拿到PRD、需求文档、甚至一段用户故事直接整段复制给AI让它“写测试用例”。效果很差因为需求文档里充斥着背景铺垫、竞品分析、术语解释真正对测试有用的信息可能就三五行。后来我把输入环节改了先让AI从原始需求里提取一份结构化摘要把“角色、动作、规则、期望结果”四个要素单独拎出来。比如一份订单退款的需求整理后变成这样角色普通用户、商家、系统管理员核心动作发起退款申请、商家审核、系统自动退款业务规则仅限支付后30天内申请已发货订单需先确认收货退款金额不得大于实付金额期望结果退款成功后订单状态变更为“已退款”库存回补优惠券返还已知边界部分退款、多次退款、退款并发这一步做完后面生成用例的质量立刻上了一个台阶。因为AI在“写用例”之前先被强制阅读了一遍关键信息不会再凭空脑补业务规则。2.2 处理链路四步生成链我的用例生成链路固定四步每步之间我会停一下看一眼再继续。第一步功能点拆解。让AI基于结构化需求列出“功能模块 / 用户场景 / 系统规则”三个维度的拆解清单。这一步的目的不是出用例而是校准理解。如果拆出来的模块跟你的认知对不上这时候纠正成本最低。第二步生成主用例。按典型场景和等价类生成正向用例。要求必须包含用例编号、前置条件、测试步骤、期望结果四列并且用表格输出方便直接贴进用例管理系统。第三步补充边界和异常。我一般会指定几个角度让AI扩展特殊字符和超长输入、重复提交和并发操作、网络中断和超时恢复、数据状态异常。对测试来说异常流往往比主流程更能体现价值但也是人最容易漏的。第四步评审模式。我把这一步叫“让AI给自己找茬”。让AI站在测试负责人的角度审查上面生成的用例集找出需求中可能被遗漏的业务规则补充缺失场景。比如订单退款流程里AI初审时可能漏掉“退款超过原路返回时效后转人工处理”的规则评审模式下它会自己发现并补上。四个步骤的Prompt示例我放在下面你可以直接替换成自己的需求结构。【输入模块】 请按以下结构整理这份需求 用户/角色 核心动作 业务规则 期望结果 已知边界/约束 【生成模块】 基于以上需求请按步骤执行每完成一步等待我确认后再继续 1. 列出该功能的用户场景清单按使用频率排序 2. 为每个场景生成测试用例字段包含编号、前置条件、测试步骤、期望结果 3. 补充异常流和边界用例覆盖特殊字符/超长输入/重复操作/并发/断网恢复/数据状态异常 4. 以测试负责人身份评审上述用例指出遗漏场景并补充完整。2.3 实测效果与AI生成的典型偏差老实说这套流程不是一次跑通就完美的但收益非常明显。以前写一个小功能的用例人工大概要40分钟到1小时现在大约20分钟主要时间花在第一步的整理和最后一步的评审补充上。用例的完整性也比纯人工要好——AI在“穷举边界值”这件事上几乎不会喊累。但它有两个典型偏差必须人工拦一下。偏差一容易生成“标准答案型”用例。比如登录功能不管你的页面是手机验证码登录还是扫码登录AI都会按“用户名密码”的老套路生成。这种时候唯一有效的办法就是输入阶段把业务规则写具体别给它自由发挥的空间。偏差二过度设计。AI倾向于把用例拆得特别细一条用例只验证一个极小动作导致用例数量爆炸。我的控制办法是在生成模块里加上一句“在保证场景覆盖的前提下控制用例粒度和总条数重复场景合并”。这句话不加你拿到的用例数量可能是实际需要的两倍。3. 模板二Bug分析工作流——把“一句话报障”变成“半小时定位”3.1 为什么大多数Bug描述经不起AI推敲测试群里最常出现的Bug描述是“某某页面打不开”“这里报错了”“点了按钮没反应”。这类描述如果直接扔给AI它只能礼貌地回复一些“建议检查网络、建议刷新页面”之类的废话因为信息量实在少得可怜。问题根源不在AI而在采集侧。很多团队的缺陷管理工具里Bug描述栏默认是开放的文本框反馈人怎么方便怎么填。而这个习惯在工作流设计里是致命的——没有结构化的输入就没有稳定的分析输出。所以我给Bug模板加了一个前置动作在任何分析之前先补全五要素。我把这个阶段叫“信息采集链”它逼着AI以提问的方式把缺失信息补齐而不是在信息残缺的情况下硬着头皮给出一个不可靠的答案。3.2 用“五要素”补全信息缺口五要素具体是环境、前置数据、操作路径、期望结果、实际结果。环境系统版本、浏览器/设备型号、网络类型、是否灰度前置数据账号类型、订单状态、金额大小、缓存情况操作路径一步步的操作序列最好包含时间点比如“13:30打开页面13:31点击提交”期望结果你的预期是什么实际结果实际发生了什么包括错误码、报错文案、截图或日志位置我的做法是拿到一条Bug先让它“提问”生成一份补充信息清单转回给反馈人填写比让反馈人对着空表格填要友好得多。AI问的问题会比较具体比如“账号是普通用户还是白名单用户”“订单此时是否已发货”“复现概率是必现还是偶现”。补全信息之后分析才真正开始。AI会根据补充后的信息按照下面这个思路输出1. 问题复现步骤清单按序排列含必要的前置数据准备 2. 初步根因假设从五个维度展开 A. 前端交互问题 B. 请求参数传递问题 C. 后端逻辑/数据处理问题 D. 环境配置差异 E. 数据状态异常 3. 每个假设给出概率排序和验证方法注明验证所需的日志、接口或权限 4. 明确标注“此处信息仍不充分最可能的下一步排查动作”就是这个“明确标注信息不充分”的设计让AI不会装懂。它把不确定的地方摊开由测试工程师凭经验决定往哪个方向深挖。3.3 根因假设排序与验证闭环这套Bug分析工作流我用了大概三个月最大的收获还不是节省时间而是让新人具备了老手的排查思路。以前带新测试同学他们遇到一个Bug容易东查一下西查一下没有章法。现在把Bug描述规范化之后直接让AI按五个维度给出假设排序新人顺着验证就行。举一个实际例子。某次线上反馈“支付成功后订单状态仍是待支付”。如果按老办法可能先去翻支付回调日志再查订单服务缓存逻辑是乱的。但五要素补全后发现用户使用的是某旧版本客户端且支付方式是一张被冻结的卡——那么“前端未刷新状态”和“支付通道回调异常”的概率排序就完全不同。这个判断AI给出的假设清单帮了大忙。验证闭环同样重要。每一条被人工确认的根因我建议你回填到模板库里形成一个“历史根因知识库”。下次遇到类似BugAI会参考历史结论直接给出“与历史案例某条相似建议优先排查某模块”。这种沉淀是AI工作流区别于“临时问一句”的最大价值。4. 模板三自动化脚本生成工作流——让AI写“能跑的代码”而不是“像代码的东西”4.1 分步生成的顺序让代码“可校验”写自动化测试脚本是最多人让AI帮忙的场景也是翻车最惨烈的场景。经常是AI一口气生成两百行代码贴进去一跑报错。把它喂回去修零件没问题了配件又不对。来回几轮最后还是自己动手重写的。所以我定了条铁律绝不一次性让AI生成完整脚本而是按定位层、操作层、断言层、数据层四步分开生成每步确认后再进行下一步。顺序是有讲究的。先让AI输出元素定位和页面对象这部分依赖页面结构是后面所有代码的地基。如果地基不对后面全白搭。确认定位信息准确后再让它写操作逻辑把点击、输入、等待这些动作串起来。操作逻辑确认后再写断言——这时候它知道你前面选了哪些元素、暴露了哪些方法断言的写法才跟你的页面结构匹配。最后才补测试数据和异常恢复逻辑。分步生成的好处是每一步的产物都很小出错容易定位。不会出现“复制了一整段代码也不知道哪段有问题”的窘境。另外还有一个好处分步生成时每轮对话都处于同一上下文里。AI记住前面步骤产生的方法名、变量名下一步生成的代码才跟前面保持衔接。如果一上来就让它写完整脚本它内部自己“脑补”一个还不存在的页面对象自然就跑不起来。4.2 上下文打包先给AI“元件清单”很多人在让AI写脚本的时候什么都不给只说“用这个框架写个登录测试”。AI只能按最通用的Web登录页面来写跟你的实际系统八竿子打不着。我的做法是先打包三份“元件清单”技术栈说明语言、测试框架、断言库、等待策略元素定位清单关键控件的定位方式比如“登录按钮idloginBtn”“验证码输入框namecaptcha”接口文档或页面操作说明如果脚本需要准备数据明确接口的入参出参这三份材料可能看起来多准备了两分钟但极大概率能避免后面二十分钟的来回返工。大语言模型生成代码的质量跟上下文信息量强相关你给的信息越准确它越不可能自由发挥。另外一定要在上下文里声明限制条件。比如禁止使用固定sleep统一用显式等待遵循POM分层结构定位器优先使用可读性高的稳定属性用例失败后清理测试数据这些限制条件不写AI大概率会给你发出“全局最稳但最慢”的实现方式——固定等待2秒在所有代码里随处可见。4.3 让AI自己审代码脚本生成完之后我现在还会强制加一道“AI自审”环节。让它以代码评审者的身份审自己刚写的脚本。具体复盘清单是这样的请对刚生成的脚本执行代码审查重点检查 1. 定位器是否稳定是否存在动态ID、隐藏元素、iframe未切换问题 2. 等待条件是否贴合业务等待的是“元素出现”还是“接口响应完成” 3. 断言是否合理是否避免了硬编码等待、是否断言了状态变化而非只断言URL 4. 异常恢复用例失败后是否可能残留脏数据、未清理的系统状态 5. 并发与重复执行脚本能否在数据已存在的情况下重复跑 对每个问题给出修改后的代码片段并说明修改理由。这一步的思路是人审代码容易碍于“自己刚刚生成的思路”而漏掉问题但AI审AI可以换个视角抓到一些自己没注意到的边界。实测下来AI自审最大的贡献是有效减少了“第一次跑就卡在定位器超时”这类低级问题。不过丑话说在前面AI生成的自动化脚本定位器质量通常只能算“能跑”离“抗变更”还有距离。页面一改版部分定位器必挂。指望AI彻底替代自动化维护是不现实的它的价值在于把你从“打字员”变成“审稿人”——你花在检查、调整、维护上的时间远少于从空白页开始敲代码的时间。5. 模板四质量报告工作流——从数据堆砌到风险结论5.1 喂给AI的数据必须有“可计算结构”测试报告是测试工程师向团队和领导展示价值的窗口。但很多报告停留在“本轮执行用例120条通过104条失败16条通过率86.7%”这个层面——这只是数据堆砌不是结论。我设计质量报告模板时第一步是定义“可计算输入”。每次跑完测试我会把数据整理成一张固定结构的表喂给AI指标本轮上轮环比用例总数12010020%通过率86.7%92%-5.3%失败用例分布模块A 6条、模块B 4条、模块C 2条模块A 2条、模块B 1条-缺陷等级致命1、严重3、一般5、轻微2致命0、严重1、一般3、轻微4-阻塞风险未知--这里的设计要点是所有字段必须是数值或明确分类不能是模糊描述。因为AI最擅长的是比较和排序只要给它结构化数据它就能算出趋势和波动。一旦喂进去的是“很多、一些、部分”这类词它的分析就失去了根基。5.2 推理链指标→风险→建议数据只负责“描述发生了什么”结论才负责“告诉团队该怎么办”。我在模板里强制要求AI按下面这个推理链输出质量趋势结论整体在变好还是变差依据是什么通过率、缺陷数、阻塞项异常波动定位哪些模块的失败数或缺陷数较上轮明显上升可能原因是什么发布风险评估基于当前数据给出“可发布 / 条件发布 / 建议阻塞”三档判断并列出判断依据下轮测试建议优先级最高的三个补充测试动作这里有个写法上的小心机要让AI输出“为什么是这个结论”而不是只给结论。比如“通过率从92%降至86.7%主要原因是模块A回归失败集中出现”这个归因比“通过率有所下降”有价值得多。实测下来报告工作流能帮我把一份报告的成稿时间从1小时压缩到20分钟。省下来的时间主要花在数据整理阶段——你必须人工把原始执行记录清洗成上面的表结构。AI没办法替你从一堆杂乱的日志里提取准确数字这个现实要接受。5.3 同源数据、两种受众因为关心指标的人不同报告表达方式也得跟着变。我让AI基于同一份数据输出两个版本团队周报版要求详细每个失败用例给出模块归属、初步原因分析、负责人建议。这个版本用于周一晨会大家要基于它对齐问题和排期。管理层月报版要求极简、结论先行。第一句话就是“本月质量整体平稳两个模块存在风险”后面只用加粗列出关键指标和风险项。管理层不关心细节只关心“能不能发版、需要什么支持”。同一个模板设置两个输出风格参数。我只需要在前面加上“本报告受众是详细版/简洁版”即可。因为底层数据一致两个版本的结论不会打架——这一点很重要避免向上汇报时口径不一致。另外建议加一句约束“所有结论必须基于输入数据不要推测未提供的指标”。没有这句话AI偶尔会脑补出一些你没测过的模块的结论这属于幻觉在报告中是硬伤。6. 模板库怎么搭、怎么避坑——我踩过的三个大坑6.1 模板库的目录与版本管理四套模板设计出来后如果只是散落在聊天记录里价值会大打折扣。我建议建一个独立的模板目录比如在个人知识库或代码仓库里建一个ai-workflow-templates文件夹每个模板一个Markdown文件。我自己的目录结构是这样的ai-workflow-templates/ ├── README.md # 总览每个模板的触发条件和入口 ├── test-case-design.md # 模板一用例设计工作流 ├── bug-analysis.md # 模板二Bug分析工作流 ├── auto-script-gen.md # 模板三自动化脚本生成工作流 └── test-report.md # 模板四质量报告工作流每个模板文件里除了Prompt内容我还建议留两个字段区变量占位符说明哪些地方需要每次替换和更新记录什么时候改过哪个环节、为什么改。模板是活物你会根据实测不断调整它更新记录能帮你回忆特定设计背后的原因避免改来改去。6.2 触发时机与半自动运行模板设计好之后不是所有任务都要走一遍完整流程。我会分三级触发轻量级临时查个东西、问个知识、报错信息翻译直接对话解决。标准级常规用例设计、常规报告生成。打开对应模板按模板里的输入规范填信息走标准链路。重量级高危模块的用例评审、线上问题的根因分析、版本发布前的质量决策。这种场景我会让AI多轮生成不同假设并且每一步都亲自确认宁可慢一点。我个人还做了一个很小的辅助脚本它本质上是把模板里的变量提取出来用命令行交互方式问你一遍需求文档贴哪里、测试数据填什么。填完之后拼装成一个完整上下文发给AI。这样连复制粘贴模板的步骤都省了。当然这一步不是必须的你完全可以手动操作。6.3 三个必须人工把关的环节这可能是全篇最想强调的部分。AI工作流再顺有三个环节我是雷打不动人工把关的第一事实性断言。版本号、缺陷编号、统计数值、发布时间这类“硬事实”AI有概率说错或凭空编造。凡是报告里出现的数字和编号我会逐一跟原始数据核对。因为AI没有“诚实”约束它的目标是“生成看起来合理的文本”。第二高风险结论。涉及“是否阻塞发布”“是否存在数据安全风险”“是否属于重大线上故障”这类结论我不会让AI一锤定音。它给出的结论我会当作“探索方向”而不是“最终判断”。最终拍板一定由具备业务和系统全局视野的人来做。第三发散型创造。比如从需求生成用例、从Bug描述推测原因AI会“合理发散”。但发散过头就是跑偏。这里的人为校验动作是问自己一句“这个场景在真实业务里可能出现吗这个边界值用户真会触达吗”如果答案不确定就回到输入阶段补充信息而不是在AI的产出上打补丁。我现在的使用习惯是让AI承担“大量重复的生成和处理”把“事实核对、经验判断、最终拍板”牢牢留在自己手里。这套模式跑了大半年效率确实翻倍但前提是你要清楚每一份AI产出的边界在哪里——它帮你承担了80%的机械重复剩下20%的判断和校验才是测试工程师真正不可替代的部分。最后再分享一个小技巧每个周末花十分钟做一次“模板复盘”。看看这周哪次输出偏离预期是哪一步的Prompt写得不够具体改完把新版本覆盖进模板库。模板迭代得越勤你依赖它的底气就越足。与其追逐各种新工具不如先把这四套流程打磨到顺手。
阅读完成 · 觉得有帮助？
