简介：《大语言模型赋能自动化测试实践、挑战与展望（复旦大学 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和这个方向最值得期待的地方。
本文还有配套的精品资源，点击获取
