2026/9/6 13:09:15
FEATURED · 精选文章 
简介《大语言模型赋能自动化测试实践、挑战与展望复旦大学 2024》PPT共54页是一份面向软件测试工程师、AI研发人员及质量管理团队的专题报告。内容聚焦大模型如何渗透软件测试全流程重点展开基于LLM的等价类划分测试技术、测试输入增强、场景测试用例生成及跨APP测试用例迁移四个实践案例并系统梳理了当前存在的挑战与未来发展方向兼顾技术原理与落地经验。整套资源为单个pptx文件大小4.22MB结构完整、图表丰富便于直接学习与二次整理。目前已有244人学习适合希望将大模型应用于自动化测试提效的读者参考。1. 先聊聊这份54页PPT的底子LLM凭什么改得了测试的命我啃完复旦这份54页PPT之后最大的感受不是“AI又要消灭一个岗位了”而是“自动化测试这潭水终于有人打算从源头换一遍了”。在测试行业摸爬滚打这些年大家心里都清楚真正拖垮自动化项目的从来不是工具不是框架而是无休止的脚本维护——页面改了要修定位符接口变了要改入参断言稍微写死一点版本一迭代就是成片飘红。为什么大语言模型偏偏在这个节点闯了进来因为它的核心能力——代码理解、代码生成、自然语言转结构化逻辑、上下文推理——恰好精准对应了自动化测试日常最耗人力的几个动作。以前写一个Selenium脚本从元素定位到断言设计纯手工、重复度高、枯燥但必须细。现在LLM可以把“用户输入用户名密码点击登录断言首页显示欢迎语”这句话直接翻译成一段可落地的代码。这背后不是简单的“AI会写代码”而是它理解了“登录”这个动作在业务语义上的含义并知道在自动化框架里应该怎么表达。PPT里有一页给了我很大触动它把自动化测试的演进分成了几个阶段脚本录制回放、关键字驱动、测试框架化、TestOps平台化然后就是现在的LLM原生测试。每个阶段解决的都是同一件事——“把测试人员的意图更快更准地变成可执行的产物”。只不过LLM这个阶段第一次让“意图”本身可以直接被机器理解中间不需要人手工翻译成代码这等于把整个生产效率的瓶颈从“写代码”挪到了“描述需求”。只要你能说清楚业务规则剩下的事情模型帮你干。当然PPT也不是光喊口号它给出了一套从需求分析到测试执行的闭环思路这也是我接下来要重点拆解的部分。它的核心主张可以概括成一句话大语言模型不是来替代测试工程师的而是把工程师从“翻译员”变成“审核员”和“架构师”人的精力从写代码转向了设计场景、评估质量、治理数据。2. 落地的四个方向用例生成、脚本修复、断言打磨与失败诊断这份PPT让我觉得靠谱的地方在于它没有停留在“LLM写测试代码”这个单点上而是把大语言模型在测试生命周期里能伸上手的地方逐段做了梳理。我结合自己的实践经验把里面最有价值的四个方向展开说说。2.1 测试用例生成从需求直接到场景而不是从代码到场景传统用例设计是“人读需求文档然后翻译成测试点”。这个过程有两大痛点一是需求文档和实际代码经常脱节二是不同测试人员对同一条需求的覆盖深度不一样。PPT里展示的做法是用RAG检索增强生成把历史用例、线上故障记录、业务术语表全部喂给模型让它在生成用例之前先把项目的“业务上下文”加载进来。实际做的时候我给团队配了一个小型的用例生成管道大致是这样先把需求说明、接口定义文档、变更影响分析结果拼装成上下文块然后用结构化输出的方式让模型返回用例列表每条用例强制包含前置条件、操作步骤、预期结果、优先级和关联需求编号。用JSON Schema约束输出格式这一步非常重要否则模型会自由发挥你后面根本没法跟测试管理系统对接。我实测下来的效果是对于一条中等复杂度的登录与权限模块需求人工设计可能需要两三个人各花半天LLM生成初版只需要几十秒质量上六成可以直接用另外四成需要调一下覆盖场景和边界值。省下来的时间不是让你躺平而是拿来补那些模型想不到的深水区用例——比如并发、权限矩阵、异常恢复这类的复杂交互。2.2 脚本修复把自动化最贵的那部分成本降下来自动化测试圈有一句老话“脚本写出来只是开始维护才是无底洞”。尤其是UI自动化前端结构一改一堆定位器集体失效修复工时经常超过写脚本的工时。PPT里有一章专门讲LLM辅助脚本修复核心思路是当测试用例失败后把失败截图、HTML源码、异常日志打包发给模型让它判断是产品真的出了bug还是脚本本身需要适配新页面结构然后给出修复建议。我自己搭过一个类似的回放修复实验拿的是一个中大型Web项目的回归套件两千多条用例。实验里故意让前端改了三个按钮的class名脚本按预期开始报错。传统做法是测试人员打开页面找到新属性再挨个改定位符一个报错快的话五分钟慢的话二十分钟。换LLM的方案我把报错前后两版页面HTML截取差异片段连同原定位符一起丢给它让它输出新的定位策略并附一段修正后的代码整体耗时大约两分钟其中有一处它判断需要从id定位改成xpath相对定位并给出了理由这个判断方向是对的。这个方向最打动我的不是“快”而是LLM能给出定位符失效的“原因解释”这是传统自动修复工具完全做不到的。团队里的初级测试同学通过看这些解释其实也在反过来提升自己的脚本编写水平。2.3 断言与测试数据最容易被低估的增效点多数人聊LLM测试应用时注意力全在生成用例和写脚本上忽略了断言和测试数据。但这恰恰是我认为实践落地性价比最高的两块。断言写得好不好直接决定用例有没有效——写松了bug溜过去写死了每轮回归都在误报中消耗信任。PPT里的思路是用模型分析接口返回报文或者页面渲染结果自动生成多维度断言建议不只判断“接口返回200”还会建议检查“金额字段精度是否符合规则”“关键列表是否按指定字段排序”“空数据场景下的兜底状态码”。我之前在一个电商项目里试过用LLM分析一次订单查询接口的返回样例它生成的断言里有一条特别有价值“当返回为空列表时是否有字段区分是查询无结果还是参数异常”。这条建议直接把这个接口的一个边界问题给暴露出来了而以前三版用例都没覆盖到。测试数据则是另一个好去处。造一条符合复杂业务规则的假数据以前要么写SQL硬凑要么用Faker碰运气。LLM可以从字段规则描述出发生成一份结构完整、业务逻辑自洽、字段之间互相匹配的Mock数据。比如我让它按“华东区VIP用户、近30天有3笔退款、信用分高于750”的规则生成用户数据它返回的JSON在字段交叉校验上完全符合规则拿来做接口联调非常顺手。2.4 失败诊断与测试报告把最繁琐的收尾环节交给模型每次全量回归跑完最头疼的不是找失败用例而是判断“这条失败是要紧的bug还是环境抖动”。以前靠有经验的人一条条看日志现在PPT里用LLM做失败归因的思路很清晰把失败用例的日志、截图、对应代码变更、历史失败记录汇总输入模型输出失败原因分类与置信度。我在实践里增加了两个细节一个是让模型输出“建议的下一个处理人”比如定位到是数据问题就转数据组定位到是前端改动就带上前端负责人另一个是让模型自然语言总结当日测试结论——总共跑了多少条、新增失败几条、哪些是历史遗留、哪些需要产品决策。这一个报告以前写起来至少要半小时现在人只需要审核一遍措辞和结论是否准确时间压缩到五分钟以内。3. 一个可复现的工程链路从Prompt设计到效果评估我踩过的坑PPT给出了方向和框架但要真跑通一个LLM辅助自动化测试的场景中间还有一堆工程细节。这一节我把自己的实操链路完整拆出来从Prompt怎么写、工程怎么搭到最后怎么评估LLM干得好不好一条线讲完。3.1 Prompt设计角色、上下文、格式三件套一个都不能少先说一个最容易踩的坑直接把“帮我写个登录测试用例”丢给模型出来的东西十有八九不能直接用。问题在于你没给它角色、没给它业务上下文、也没规定输出结构。合理的Prompt应该包含三个层次角色与目标让模型知道自己是资深测试工程师目标是产出符合项目规范的自动化测试用例。上下文信息把被测系统的接口文档、页面交互说明、历史用例片段、业务规则放进去。这一步直接决定生成结果是通用还是贴合项目。输出约束规定格式比如必须返回JSON数组字段包含用例ID、场景描述、前置条件、步骤列表、断言列表、关联需求编号。我试过用一套拼接好的Prompt模板对同一个模块的接口连续生成三批用例第一批没加历史用例上下文第二批加了三段历史高质量用例第三批在第二批基础上又加了业务规则文档。结果差异非常明显第一批内容是“对的但泛的”第二批明显开始模仿历史用例里的命名习惯和覆盖风格第三批则覆盖到了规则里提到的前两个容易漏的特殊场景。所以说LLM生成质量的天花板很大程度取决于你喂给它的上下文质量的“地板”。3.2 工程链路里最容易忽略的三个环节第一是去重。模型批量生成用例时经常用不同措辞描述同一个场景直接进用例库会产生大量重复。我在管道里加了一个轻量去重步骤通过语义向量做相似度计算超过阈值就自动合并效果不错。第二个是风险分级。模型生成的所有用例默认都是平等的这在实践中不可接受我把需求变更影响面分析的结果拼进上下文让模型对每条用例标注影响关联度最后人工复核这样可以优先执行跟改动相关的用例。第三个是人工审核闭环。不管模型多强大直接让生成结果无门槛进入测试集都是危险的。团队成员需要对生成结果做抽样评审尤其第一周抽样比例建议不低于50%等跑顺了再逐步降低。3.3 效果评估指标别只看生成量要看“可用率”PPT里在设计评估体系的时候用了好几页篇幅我觉得最值得借鉴的是它区分了“模型能力指标”和“工程收益指标”。模型能力指标包括用例格式合法率能否直接解析通过、规则覆盖率生成的用例覆盖了多少条业务规则、断言有效性断言本身是否能真实反映业务预期可以通过静态分析判断工程收益指标则包括用例编写人效提升比例、脚本修复时长下降比例、日常回归漏测数变化、人工介入修改次数。我实际操作后最推荐三个指标来评估LLM在这个场景有没有真的产生价值都很有用生成用例可直接入库率建议把基线目标定在60%以上达不到就是上下文或Prompt有问题。脚本自动修复成功率我实测稳定在70%到80%低于这个值建议调整日志和截图的拼接策略。人工修正平均耗时如果修正一条生成用例的成本接近从头写那说明模型没真正帮上忙。这组指标定期在团队周会上过一遍、分析趋势不要只看一次生成结果就下结论。4. 别被Demo骗了成本、幻觉、安全这三道坎的真实解法PPT的后半部分从“实践”转向了“挑战”我觉得这是他敢把问题摆到台面上说比很多只看光鲜一面讲AI测试的内容要实在得多。这里面的三道坎相信只要是真的跑过LLM应用的人都深有体会。4.1 成本账单次生成很便宜规模化之后是另一回事很多人刚开始试验LLM生成用例时觉得便宜一次调用几分钱但真到企业级规模化使用就不同了。PPT里算了一笔账假设一个测试团队每天要处理两百条需求变更、生成一千条用例、跑五十次失败归因分析再加上RAG检索和上下文拼装带来的token开销一个月下来是相当可观的数字。我在实践中验证过这个成本模型还得补一句上下文越长、单次调用token越多成本是指数级的感受。控制成本的几个实战方法优先用开源模型做本地部署尤其对标注、分类、初筛这类不需要顶级推理能力的任务7B到14B的模型在结构化输出上已经够用。对于代码生成、复杂断言设计这种难度高的任务再调更大规模的模型或云端API形成“大小模型混跑”的架构。Prompt里限制输出长度和格式重复内容直接在指令里禁止输出能减少不少无效token。做一层缓存和复用同一个模块生成过的用例结果缓存起来需求不变时直接命中不要每次都重新调用。4.2 幻觉问题用RAG和结构化约束去“逼”模型说实话LLM生成测试内容最危险的是“一本正经地胡说八道”比如它觉得订单金额应该是保留两位小数就直接用了没意识到业务那边的真实规则是部分场景保留三位。这种幻觉在测试场景下不是笑话它可能导致无效用例甚至误报比不写还糟。PPT给的解法和我实践后的结论是一致的靠RAG把真实业务规则和接口定义注入上下文让模型输出的依据来自资料而非“记忆”。为什么这个解法有效因为大模型训练数据里的通用规则跟你的业务规则经常打架但模型没有能力分辨哪个是哪个。RAG相当于告诉它“这个项目里我说的算”你说保留三位就是三位。配合结构化输出约束强制模型在固定schema里作答幻觉概率会再降一截。还有一招我自己加进去的让模型在生成断言时附上依据来源标注是参考了接口文档第几段还是历史用例里的哪一条。这样人工审核时可以直接溯源比对着模型生成的断言猜它从哪儿来的要省力得多。4.3 安全与数据合规代码出域这件事必须想清楚做LLM辅助测试本质上是把被测系统的代码、数据结构、业务逻辑发给模型。这里面涉及敏感信息出域的问题不做控制就不是成本多少的问题而是能不能做的问题了。现在行业的通行做法大致分三条路一是全内网部署开源模型数据和代码完全不出域安全性最高但对GPU资源和工程能力要求最高二是用API调用商用模型但做敏感信息脱敏在发送前用规则过滤和字段标记把代码里的变量名、IP、密钥全部替换成占位符模型返回后再映射回去三是混合模式一般模块用云端API核心交易等敏感链路走本地模型。我自己在带团队的时候会倾向把被测代码做局部脱敏后再调用API同时在API网关层做日志审计记录每一次请求对应的项目和模块这样出了问题能溯源。我在这里说一句可能会被部分人认为是保守的话如果安全条件不满足宁可先小范围试点也不要为了赶AI风口把核心业务代码直接落到外部平台这个风险不值得冒。5. 延伸思考多模态与Agent化会把自动化测试带到哪里去复旦这份PPT的最后一部分篇幅不长但给出的几个方向我很认可也在此展开说一下我的判断——这些不是遥远的未来而是未来两三年大概率会发生的事。5.1 多模态能力补上UI测试的“肉眼”短板目前多数LLM辅助测试的实践停留在接口层和代码层UI层主要靠读取HTML或JSON结构对视觉布局和交互反馈的感知比较弱。但多模态模型的成熟正在补上这块短板。测试里大量需要“看一眼”的场景比如图表展示是否符合预期、弹窗遮挡是否影响操作、移动端在小屏上的元素排布是否错乱以前只能靠人工或纯视觉差分工具现在多模态模型可以直接基于截图来做判断。我做过一个小实验把三层嵌套弹窗的页面截图丢给多模态模型让它描述层级关系和可交互区域它的回答基本准确能区分出遮罩层和弹窗主体。这说明测试场景里最耗人力的“视觉回归检查”有潜力被自动化捡起来。5.2 Agent化从“生成工具”到“测试执行体”PPT里展望了Agent化方向这也是我近期在关注的一个重点。所谓Agent不再是“模型回答完就结束”而是它自己会计划——分析需求、生成用例、执行测试、看结果、发现问题、修复脚本、再回归整个闭环自己跑只把关键决策点留给人工。这个方向拿来跑回归测试特别合适因为回归的特点是步骤固定、数据明确、判定标准清晰Agent在受限环境里完全可以按流程推进。当然离“全自动自主测试”还有不少距离现在更可行的形态是“人定方向、Agent跑细节”。比如你告诉它“这个版本重点回归支付流程”它会自己拆成权限、优惠、退款等子场景自己安排执行顺序然后汇总一份带证据链的报告给你。人在里面负责判断“这个风险能不能上线”这种需要业务认知的问题。5.3 平台化是最终形态PPT里反复提到测试平台建设我的理解是LLM真正发挥价值不是靠每个测试人员各自写Prompt调用API而是它成为一种平台能力嵌在用例管理、任务调度、数据工厂、报表中心这些模块里。在平台上模型帮你在“录入需求”的瞬间就生成初版用例在“定时回归”跑完后自动产出归因报告在“版本变更”时自动圈定受影响用例。这样LLM就从一个需要人主动去学去用的工具变成了整个测试交付流水线的基础设施。这也是我给团队做规划时的核心思路别一上来就铺一个全新的AI测试系统而是先把现有平台里最容易痛的三四个环节用模型替换掉比如失败工单的自动分类、回归报告的自动生成、用例描述的自动补全。每替换一个团队就多释放一点人力用这些人力去建设更高质量的测试数据体系和更精细的业务模型形成正循环。5.4 我的一些判断与建议最后以一个干了好几年自动化测试的老兵身份说几句实在话。大语言模型确实让自动化测试的“自动”两个字比过去任何时候都更接近本义但工具再强最终能不能用出效果取决于团队有没有把底子打好自动化测试的基础框架是否稳定、测试数据是否干净、脚本分层是否合理、CI流水线是否通畅。这些地基没弄好LLM给不了你质的飞跃它只会把一套本该推倒重来的烂工程更快地生成出更多同样烂的用例。反而是在底子相对扎实的团队里LLM的收益会非常明显。拿我自己团队来说今年引入LLM辅助之后接口测试用例的编写人均产能提升了差不多三倍脚本修复时间降了一半以上但最有价值的变化不是这些数字而是测试人员终于可以从繁琐重复的编码中解放出来重新把注意力放到业务逻辑和风险判断上。我觉得这才是这份PPT和这个方向最值得期待的地方。本文还有配套的精品资源点击获取
大语言模型重构自动化测试：用例生成、脚本修复与工程实践全解析
简介《大语言模型赋能自动化测试实践、挑战与展望复旦大学 2024》PPT共54页是一份面向软件测试工程师、AI研发人员及质量管理团队的专题报告。内容聚焦大模型如何渗透软件测试全流程重点展开基于LLM的等价类划分测试技术、测试输入增强、场景测试用例生成及跨APP测试用例迁移四个实践案例并系统梳理了当前存在的挑战与未来发展方向兼顾技术原理与落地经验。整套资源为单个pptx文件大小4.22MB结构完整、图表丰富便于直接学习与二次整理。目前已有244人学习适合希望将大模型应用于自动化测试提效的读者参考。1. 先聊聊这份54页PPT的底子LLM凭什么改得了测试的命我啃完复旦这份54页PPT之后最大的感受不是“AI又要消灭一个岗位了”而是“自动化测试这潭水终于有人打算从源头换一遍了”。在测试行业摸爬滚打这些年大家心里都清楚真正拖垮自动化项目的从来不是工具不是框架而是无休止的脚本维护——页面改了要修定位符接口变了要改入参断言稍微写死一点版本一迭代就是成片飘红。为什么大语言模型偏偏在这个节点闯了进来因为它的核心能力——代码理解、代码生成、自然语言转结构化逻辑、上下文推理——恰好精准对应了自动化测试日常最耗人力的几个动作。以前写一个Selenium脚本从元素定位到断言设计纯手工、重复度高、枯燥但必须细。现在LLM可以把“用户输入用户名密码点击登录断言首页显示欢迎语”这句话直接翻译成一段可落地的代码。这背后不是简单的“AI会写代码”而是它理解了“登录”这个动作在业务语义上的含义并知道在自动化框架里应该怎么表达。PPT里有一页给了我很大触动它把自动化测试的演进分成了几个阶段脚本录制回放、关键字驱动、测试框架化、TestOps平台化然后就是现在的LLM原生测试。每个阶段解决的都是同一件事——“把测试人员的意图更快更准地变成可执行的产物”。只不过LLM这个阶段第一次让“意图”本身可以直接被机器理解中间不需要人手工翻译成代码这等于把整个生产效率的瓶颈从“写代码”挪到了“描述需求”。只要你能说清楚业务规则剩下的事情模型帮你干。当然PPT也不是光喊口号它给出了一套从需求分析到测试执行的闭环思路这也是我接下来要重点拆解的部分。它的核心主张可以概括成一句话大语言模型不是来替代测试工程师的而是把工程师从“翻译员”变成“审核员”和“架构师”人的精力从写代码转向了设计场景、评估质量、治理数据。2. 落地的四个方向用例生成、脚本修复、断言打磨与失败诊断这份PPT让我觉得靠谱的地方在于它没有停留在“LLM写测试代码”这个单点上而是把大语言模型在测试生命周期里能伸上手的地方逐段做了梳理。我结合自己的实践经验把里面最有价值的四个方向展开说说。2.1 测试用例生成从需求直接到场景而不是从代码到场景传统用例设计是“人读需求文档然后翻译成测试点”。这个过程有两大痛点一是需求文档和实际代码经常脱节二是不同测试人员对同一条需求的覆盖深度不一样。PPT里展示的做法是用RAG检索增强生成把历史用例、线上故障记录、业务术语表全部喂给模型让它在生成用例之前先把项目的“业务上下文”加载进来。实际做的时候我给团队配了一个小型的用例生成管道大致是这样先把需求说明、接口定义文档、变更影响分析结果拼装成上下文块然后用结构化输出的方式让模型返回用例列表每条用例强制包含前置条件、操作步骤、预期结果、优先级和关联需求编号。用JSON Schema约束输出格式这一步非常重要否则模型会自由发挥你后面根本没法跟测试管理系统对接。我实测下来的效果是对于一条中等复杂度的登录与权限模块需求人工设计可能需要两三个人各花半天LLM生成初版只需要几十秒质量上六成可以直接用另外四成需要调一下覆盖场景和边界值。省下来的时间不是让你躺平而是拿来补那些模型想不到的深水区用例——比如并发、权限矩阵、异常恢复这类的复杂交互。2.2 脚本修复把自动化最贵的那部分成本降下来自动化测试圈有一句老话“脚本写出来只是开始维护才是无底洞”。尤其是UI自动化前端结构一改一堆定位器集体失效修复工时经常超过写脚本的工时。PPT里有一章专门讲LLM辅助脚本修复核心思路是当测试用例失败后把失败截图、HTML源码、异常日志打包发给模型让它判断是产品真的出了bug还是脚本本身需要适配新页面结构然后给出修复建议。我自己搭过一个类似的回放修复实验拿的是一个中大型Web项目的回归套件两千多条用例。实验里故意让前端改了三个按钮的class名脚本按预期开始报错。传统做法是测试人员打开页面找到新属性再挨个改定位符一个报错快的话五分钟慢的话二十分钟。换LLM的方案我把报错前后两版页面HTML截取差异片段连同原定位符一起丢给它让它输出新的定位策略并附一段修正后的代码整体耗时大约两分钟其中有一处它判断需要从id定位改成xpath相对定位并给出了理由这个判断方向是对的。这个方向最打动我的不是“快”而是LLM能给出定位符失效的“原因解释”这是传统自动修复工具完全做不到的。团队里的初级测试同学通过看这些解释其实也在反过来提升自己的脚本编写水平。2.3 断言与测试数据最容易被低估的增效点多数人聊LLM测试应用时注意力全在生成用例和写脚本上忽略了断言和测试数据。但这恰恰是我认为实践落地性价比最高的两块。断言写得好不好直接决定用例有没有效——写松了bug溜过去写死了每轮回归都在误报中消耗信任。PPT里的思路是用模型分析接口返回报文或者页面渲染结果自动生成多维度断言建议不只判断“接口返回200”还会建议检查“金额字段精度是否符合规则”“关键列表是否按指定字段排序”“空数据场景下的兜底状态码”。我之前在一个电商项目里试过用LLM分析一次订单查询接口的返回样例它生成的断言里有一条特别有价值“当返回为空列表时是否有字段区分是查询无结果还是参数异常”。这条建议直接把这个接口的一个边界问题给暴露出来了而以前三版用例都没覆盖到。测试数据则是另一个好去处。造一条符合复杂业务规则的假数据以前要么写SQL硬凑要么用Faker碰运气。LLM可以从字段规则描述出发生成一份结构完整、业务逻辑自洽、字段之间互相匹配的Mock数据。比如我让它按“华东区VIP用户、近30天有3笔退款、信用分高于750”的规则生成用户数据它返回的JSON在字段交叉校验上完全符合规则拿来做接口联调非常顺手。2.4 失败诊断与测试报告把最繁琐的收尾环节交给模型每次全量回归跑完最头疼的不是找失败用例而是判断“这条失败是要紧的bug还是环境抖动”。以前靠有经验的人一条条看日志现在PPT里用LLM做失败归因的思路很清晰把失败用例的日志、截图、对应代码变更、历史失败记录汇总输入模型输出失败原因分类与置信度。我在实践里增加了两个细节一个是让模型输出“建议的下一个处理人”比如定位到是数据问题就转数据组定位到是前端改动就带上前端负责人另一个是让模型自然语言总结当日测试结论——总共跑了多少条、新增失败几条、哪些是历史遗留、哪些需要产品决策。这一个报告以前写起来至少要半小时现在人只需要审核一遍措辞和结论是否准确时间压缩到五分钟以内。3. 一个可复现的工程链路从Prompt设计到效果评估我踩过的坑PPT给出了方向和框架但要真跑通一个LLM辅助自动化测试的场景中间还有一堆工程细节。这一节我把自己的实操链路完整拆出来从Prompt怎么写、工程怎么搭到最后怎么评估LLM干得好不好一条线讲完。3.1 Prompt设计角色、上下文、格式三件套一个都不能少先说一个最容易踩的坑直接把“帮我写个登录测试用例”丢给模型出来的东西十有八九不能直接用。问题在于你没给它角色、没给它业务上下文、也没规定输出结构。合理的Prompt应该包含三个层次角色与目标让模型知道自己是资深测试工程师目标是产出符合项目规范的自动化测试用例。上下文信息把被测系统的接口文档、页面交互说明、历史用例片段、业务规则放进去。这一步直接决定生成结果是通用还是贴合项目。输出约束规定格式比如必须返回JSON数组字段包含用例ID、场景描述、前置条件、步骤列表、断言列表、关联需求编号。我试过用一套拼接好的Prompt模板对同一个模块的接口连续生成三批用例第一批没加历史用例上下文第二批加了三段历史高质量用例第三批在第二批基础上又加了业务规则文档。结果差异非常明显第一批内容是“对的但泛的”第二批明显开始模仿历史用例里的命名习惯和覆盖风格第三批则覆盖到了规则里提到的前两个容易漏的特殊场景。所以说LLM生成质量的天花板很大程度取决于你喂给它的上下文质量的“地板”。3.2 工程链路里最容易忽略的三个环节第一是去重。模型批量生成用例时经常用不同措辞描述同一个场景直接进用例库会产生大量重复。我在管道里加了一个轻量去重步骤通过语义向量做相似度计算超过阈值就自动合并效果不错。第二个是风险分级。模型生成的所有用例默认都是平等的这在实践中不可接受我把需求变更影响面分析的结果拼进上下文让模型对每条用例标注影响关联度最后人工复核这样可以优先执行跟改动相关的用例。第三个是人工审核闭环。不管模型多强大直接让生成结果无门槛进入测试集都是危险的。团队成员需要对生成结果做抽样评审尤其第一周抽样比例建议不低于50%等跑顺了再逐步降低。3.3 效果评估指标别只看生成量要看“可用率”PPT里在设计评估体系的时候用了好几页篇幅我觉得最值得借鉴的是它区分了“模型能力指标”和“工程收益指标”。模型能力指标包括用例格式合法率能否直接解析通过、规则覆盖率生成的用例覆盖了多少条业务规则、断言有效性断言本身是否能真实反映业务预期可以通过静态分析判断工程收益指标则包括用例编写人效提升比例、脚本修复时长下降比例、日常回归漏测数变化、人工介入修改次数。我实际操作后最推荐三个指标来评估LLM在这个场景有没有真的产生价值都很有用生成用例可直接入库率建议把基线目标定在60%以上达不到就是上下文或Prompt有问题。脚本自动修复成功率我实测稳定在70%到80%低于这个值建议调整日志和截图的拼接策略。人工修正平均耗时如果修正一条生成用例的成本接近从头写那说明模型没真正帮上忙。这组指标定期在团队周会上过一遍、分析趋势不要只看一次生成结果就下结论。4. 别被Demo骗了成本、幻觉、安全这三道坎的真实解法PPT的后半部分从“实践”转向了“挑战”我觉得这是他敢把问题摆到台面上说比很多只看光鲜一面讲AI测试的内容要实在得多。这里面的三道坎相信只要是真的跑过LLM应用的人都深有体会。4.1 成本账单次生成很便宜规模化之后是另一回事很多人刚开始试验LLM生成用例时觉得便宜一次调用几分钱但真到企业级规模化使用就不同了。PPT里算了一笔账假设一个测试团队每天要处理两百条需求变更、生成一千条用例、跑五十次失败归因分析再加上RAG检索和上下文拼装带来的token开销一个月下来是相当可观的数字。我在实践中验证过这个成本模型还得补一句上下文越长、单次调用token越多成本是指数级的感受。控制成本的几个实战方法优先用开源模型做本地部署尤其对标注、分类、初筛这类不需要顶级推理能力的任务7B到14B的模型在结构化输出上已经够用。对于代码生成、复杂断言设计这种难度高的任务再调更大规模的模型或云端API形成“大小模型混跑”的架构。Prompt里限制输出长度和格式重复内容直接在指令里禁止输出能减少不少无效token。做一层缓存和复用同一个模块生成过的用例结果缓存起来需求不变时直接命中不要每次都重新调用。4.2 幻觉问题用RAG和结构化约束去“逼”模型说实话LLM生成测试内容最危险的是“一本正经地胡说八道”比如它觉得订单金额应该是保留两位小数就直接用了没意识到业务那边的真实规则是部分场景保留三位。这种幻觉在测试场景下不是笑话它可能导致无效用例甚至误报比不写还糟。PPT给的解法和我实践后的结论是一致的靠RAG把真实业务规则和接口定义注入上下文让模型输出的依据来自资料而非“记忆”。为什么这个解法有效因为大模型训练数据里的通用规则跟你的业务规则经常打架但模型没有能力分辨哪个是哪个。RAG相当于告诉它“这个项目里我说的算”你说保留三位就是三位。配合结构化输出约束强制模型在固定schema里作答幻觉概率会再降一截。还有一招我自己加进去的让模型在生成断言时附上依据来源标注是参考了接口文档第几段还是历史用例里的哪一条。这样人工审核时可以直接溯源比对着模型生成的断言猜它从哪儿来的要省力得多。4.3 安全与数据合规代码出域这件事必须想清楚做LLM辅助测试本质上是把被测系统的代码、数据结构、业务逻辑发给模型。这里面涉及敏感信息出域的问题不做控制就不是成本多少的问题而是能不能做的问题了。现在行业的通行做法大致分三条路一是全内网部署开源模型数据和代码完全不出域安全性最高但对GPU资源和工程能力要求最高二是用API调用商用模型但做敏感信息脱敏在发送前用规则过滤和字段标记把代码里的变量名、IP、密钥全部替换成占位符模型返回后再映射回去三是混合模式一般模块用云端API核心交易等敏感链路走本地模型。我自己在带团队的时候会倾向把被测代码做局部脱敏后再调用API同时在API网关层做日志审计记录每一次请求对应的项目和模块这样出了问题能溯源。我在这里说一句可能会被部分人认为是保守的话如果安全条件不满足宁可先小范围试点也不要为了赶AI风口把核心业务代码直接落到外部平台这个风险不值得冒。5. 延伸思考多模态与Agent化会把自动化测试带到哪里去复旦这份PPT的最后一部分篇幅不长但给出的几个方向我很认可也在此展开说一下我的判断——这些不是遥远的未来而是未来两三年大概率会发生的事。5.1 多模态能力补上UI测试的“肉眼”短板目前多数LLM辅助测试的实践停留在接口层和代码层UI层主要靠读取HTML或JSON结构对视觉布局和交互反馈的感知比较弱。但多模态模型的成熟正在补上这块短板。测试里大量需要“看一眼”的场景比如图表展示是否符合预期、弹窗遮挡是否影响操作、移动端在小屏上的元素排布是否错乱以前只能靠人工或纯视觉差分工具现在多模态模型可以直接基于截图来做判断。我做过一个小实验把三层嵌套弹窗的页面截图丢给多模态模型让它描述层级关系和可交互区域它的回答基本准确能区分出遮罩层和弹窗主体。这说明测试场景里最耗人力的“视觉回归检查”有潜力被自动化捡起来。5.2 Agent化从“生成工具”到“测试执行体”PPT里展望了Agent化方向这也是我近期在关注的一个重点。所谓Agent不再是“模型回答完就结束”而是它自己会计划——分析需求、生成用例、执行测试、看结果、发现问题、修复脚本、再回归整个闭环自己跑只把关键决策点留给人工。这个方向拿来跑回归测试特别合适因为回归的特点是步骤固定、数据明确、判定标准清晰Agent在受限环境里完全可以按流程推进。当然离“全自动自主测试”还有不少距离现在更可行的形态是“人定方向、Agent跑细节”。比如你告诉它“这个版本重点回归支付流程”它会自己拆成权限、优惠、退款等子场景自己安排执行顺序然后汇总一份带证据链的报告给你。人在里面负责判断“这个风险能不能上线”这种需要业务认知的问题。5.3 平台化是最终形态PPT里反复提到测试平台建设我的理解是LLM真正发挥价值不是靠每个测试人员各自写Prompt调用API而是它成为一种平台能力嵌在用例管理、任务调度、数据工厂、报表中心这些模块里。在平台上模型帮你在“录入需求”的瞬间就生成初版用例在“定时回归”跑完后自动产出归因报告在“版本变更”时自动圈定受影响用例。这样LLM就从一个需要人主动去学去用的工具变成了整个测试交付流水线的基础设施。这也是我给团队做规划时的核心思路别一上来就铺一个全新的AI测试系统而是先把现有平台里最容易痛的三四个环节用模型替换掉比如失败工单的自动分类、回归报告的自动生成、用例描述的自动补全。每替换一个团队就多释放一点人力用这些人力去建设更高质量的测试数据体系和更精细的业务模型形成正循环。5.4 我的一些判断与建议最后以一个干了好几年自动化测试的老兵身份说几句实在话。大语言模型确实让自动化测试的“自动”两个字比过去任何时候都更接近本义但工具再强最终能不能用出效果取决于团队有没有把底子打好自动化测试的基础框架是否稳定、测试数据是否干净、脚本分层是否合理、CI流水线是否通畅。这些地基没弄好LLM给不了你质的飞跃它只会把一套本该推倒重来的烂工程更快地生成出更多同样烂的用例。反而是在底子相对扎实的团队里LLM的收益会非常明显。拿我自己团队来说今年引入LLM辅助之后接口测试用例的编写人均产能提升了差不多三倍脚本修复时间降了一半以上但最有价值的变化不是这些数字而是测试人员终于可以从繁琐重复的编码中解放出来重新把注意力放到业务逻辑和风险判断上。我觉得这才是这份PPT和这个方向最值得期待的地方。本文还有配套的精品资源点击获取 
