企业官网建设流程全解析

简介：这份PPT来自复旦大学计算机学院2024年专题分享，面向软件测试工程师、AI应用研究者及高校师生，聚焦大语言模型在自动化测试中的落地实践。内容围绕背景介绍和四类典型案例展开：基于大语言模型的等价类划分测试、测试输入增强、场景测试用例生成、跨APP测试用例迁移，并在2205个开源方法上对比了与EvoSuite的覆盖效果和成本，同时讨论了可靠性、可解释性等挑战与展望。资源为54页PPT演示文稿，压缩包内含1个pptx文件，大小4.22MB，已有244人浏览学习。PPT目录清晰，按背景、案例、挑战分层组织，兼顾自学与课堂分享。读者可从中获得大模型在测试设计、用例生成、跨应用迁移中的具体思路和实验数据，为自动化测试选型与研究提供参考。

1. 大模型进入自动化测试：先看清它到底改变了什么

这两年“大语言模型赋能自动化测试”几乎成了测试圈最热门的议题。无论你是做接口测试、UI测试还是移动端自动化，都会发现身边人开始讨论怎么用LLM写用例、修脚本、生成断言。我自己也花了不少时间在真实项目里折腾这些方案，今天想把这套东西掰开揉碎讲清楚：哪些能力是实打实能落地的，哪些还停留在演示阶段，以及真正推动落地时会踩到哪些坑。

先说结论：大语言模型（LLM）在自动化测试里的价值，不是“替代现有框架”，而是把自动化测试链条里最耗人力的几个环节——用例设计、脚本编写、断言维护、缺陷分析——用自然语言的方式加速。传统自动化测试的本质是“规则驱动”，你写死选择器、写死预期结果、写死执行顺序；LLM加持后，整个链条可以变成“意图驱动”，你告诉模型你要测什么，它帮你拆成步骤、生成脚本、分析结果。这个转变听起来不大，但实际用起来，效率和维护成本的差别非常明显。

这份来自复旦大学的54页PPT材料，核心讲的也是这条主线：LLM在测试用例生成、测试脚本生成、测试断言与报告生成、缺陷定位与修复这些场景里的实践路径，以及当前面临的挑战。结合我自己折腾开源模型、商用模型、本地部署方案的实际经验，这篇文章会把这套体系尽量讲透，同时也会补上PPT里不会详细写的落地细节和避坑经验。

适合读这篇文章的人，我建议是这几类：已经有一定自动化测试基础、正在考虑引入AI能力的测试工程师；团队里负责测试工具链和测试平台建设的技术负责人；以及想了解LLM在垂直行业到底能干什么、不能干什么的开发者和技术管理者。

2. 测试智能化升级：从规则驱动到意图驱动

2.1 传统自动化测试的三座大山

动手聊LLM之前，我们先回到传统自动化测试本身。做了几年自动化的人应该都有体会：UI自动化里最耗时的不是写脚本，而是维护脚本。页面结构一改，xpath失效，脚本直接崩；接口自动化稍微好一点，但接口字段变动、登录态失效、数据污染，同样需要投入大量精力去排查。用例设计则完全依赖个人经验，同样的功能点，资深测试和新人写出来的覆盖度能差出一大截。

这三座大山——用例设计成本高、脚本维护工作量大、断言和报告分析费时——恰恰是LLM最擅长介入的地方。为什么？因为这三类工作本质上都是“文本处理任务”：需求文档是文本，页面DOM是文本，接口返回是JSON文本，测试报告是文本，缺陷描述也是文本。LLM恰好是一个超强的文本理解和生成引擎，把两者放在一起，逻辑上是顺畅的。

2.2 LLM在测试链路中的真实角色

我倾向于把LLM在自动化测试中的角色分成四个层次，这样比较好理解它的能力边界：

第一层是辅助生成，包括根据需求或页面信息生成测试用例和测试脚本，这是目前落地最广、最容易出效果的方向。第二层是智能维护，当页面元素变化导致脚本失败时，LLM能自动分析新旧DOM差异，推荐或直接修改定位器。第三层是结果分析，把执行日志、截图、接口返回喂给LLM，让它判断是Bug还是环境问题，并生成人类能读懂的报告。第四层是自主执行，让LLM以Agent的形式自己操作浏览器或调用接口完成整条测试链路。

前两个层次目前已经可以在真实项目里稳定使用，第三个层次效果也很不错，第四个层次最炫酷，但稳定性还有明显短板。后文我会专门说这个Agent的问题。

2.3 为什么本地部署大模型是测试团队绕不开的话题

搜热搜词的时候有句话很有意思：“大语言模型下载下来是什么”。很多团队一开始就是想知道这个。测试数据普遍敏感，业务信息、用户数据、内部系统地址都不能随便外传，直接调云上大模型接口在很多公司过不了合规关。所以本地部署一个开源模型，成了测试平台智能化改造的主流选择。

本地部署的性价比，需要认真盘算一下。7B级别量化后的模型（比如Qwen2.5-7B-Instruct的4bit量化版），一台带24G显存的消费级显卡就能跑起来，生成质量在测试用例和脚本推荐场景下够用。更大参数的模型如32B，需要两块24G显卡或者一块48G的卡，效果更好但成本翻倍。再往上走，70B级别基本就需要专业卡集群了，对大多数测试团队来说投入产出不划算。

我个人实测下来，测试场景里7B-14B这个区间是性价比最高的。原因在于，测试用例生成、脚本修复这类任务，不要求模型具备极强的逻辑推理和复杂的多步规划能力，反而更看重对上下文的理解和格式化输出。这个能力门槛，中小模型经过调优是能跨过去的。

3. 实践路径拆解：模型选型、Prompt设计与知识库增强

3.1 模型选型：从开源到商用的分层方案

模型选型是很多团队落地时面临的第一道选择题。大方向上不外乎三条路：直接调商用API、本地部署开源模型、或两者混合。

商用API的优势是省心和效果强。GPT-4级别的模型在理解复杂需求和生成高质量用例方面，确实比开源小模型要聪明不少。流程上你只需调用接口，不需要管部署和运维。缺点也明确：数据出境、单次调用成本随用量线性增长、以及接口服务不稳定时连带影响测试执行链路的稳定性。

本地部署的好处则是数据不外流、可离线运行、深度定制空间大。缺点是需要懂模型部署的工程师，还要解决显存、推理速度、模型效果调优等一系列问题。

对于多数中型团队，我比较推荐“混合模式”：常规的测试数据生成、用例推荐走本地私有化模型，涉及复杂语义理解的任务（比如跨多个需求的测试逻辑推导）可以走商用API，且传输前做脱敏。这个方案兼顾了成本、安全与效果，也是我目前在生产环境比较认可的组合。

3.2 提示词结构：直接决定生成结果的质量

很多人刚开始用LLM做测试用例生成，就随便写一句“帮我生成用户登录功能的测试用例”，得到的输出要么过于泛泛，要么根本不贴合你的系统。Prompt写得好不好，对结果质量的影响甚至超过模型本身。我测试过几次，同一个模型，精心设计的Prompt和随手写的Prompt，生成的用例覆盖度可以差一倍以上。

一个有效的测试Prompt，我认为至少要包含四块：角色设定、任务目标、输入信息、输出格式要求。举例来说，接口测试用例生成的Prompt可以这样组织：

你是一名资深测试工程师，擅长接口自动化测试。 请根据以下接口定义生成完整的测试用例： - 接口地址：/api/v1/user/login - 请求方法：POST - 请求参数：username（string，必填），password（string，必填），captcha（string，可选） - 业务规则：密码错误5次后账号锁定30分钟；同一IP每分钟最多尝试10次 输出要求： 1. 用例ID、用例名称、优先级 2. 前置条件 3. 请求参数（具体数值） 4. 预期结果（状态码、响应字段、数据库变化） 5. 按正常流程、异常流程、边界值、安全测试四类分组

这样生成的用例基本可以用，但距离“完美贴合业务”还有距离。真正要落地，还需要让LLM理解你的业务规则。比如登录场景里，“测试密码错误5次后的锁定机制”这类核心业务逻辑，Prompt里不写清楚，模型很难主动覆盖到。所以我的经验是：Prompt里业务规则描述得越细，生成用例的业务价值越高。这个工作不能省。

3.3 RAG增强：让模型理解你的业务，而不是泛泛的测试理论

如果说Prompt是教会模型怎么回答，RAG（检索增强生成）就是给模型装上一个能查阅项目资料的“智库”。大模型的参数里存储的是“通用知识”，你的业务知识、历史缺陷记录、系统架构信息，它一概不知。想让LLM生成贴合业务的测试方案，就需要把项目文档、接口文档、缺陷报告喂给它。

具体做法不复杂：把历史测试用例、需求文档、接口文档、缺陷记录进行切片和向量化，存入向量数据库（如Milvus、Qdrant、或轻量级的Chroma）。每次请求时先从向量库检索和当前任务相关的片段，把检索结果拼进Prompt上下文里，再让LLM生成。这一步效果非常明显，尤其适合历史缺陷回归测试用例推荐和需求变更影响分析两类场景。

举个例子，你有一个老系统，积累了上千条缺陷记录。现在产品迭代改了订单模块的逻辑，你问LLM“订单模块这次改动应该重点回归哪些功能”，它只凭常识回答会很空。但如果你把历史缺陷记录向量化并检索出“订单价格计算”、“优惠券叠加”、“库存扣减”相关的历史Bug描述，LLM就能告诉你：这几个地方历史上出过问题，这次改动要重点关注。这种能力，没有RAG是做不到的。

3.4 接口与UI自动化中的LLM落地细节

接口自动化是我认为LLM落地效果最好的领域。原因很简单：接口定义结构化程度高，参数、返回结构、状态码都是清晰的文本，LLM几乎没有理解负担。目前比较成熟的用法是：解析Swagger/OpenAPI文档，让LLM直接生成Python的requests调用代码及断言，或者生成Postman/Apifox 的批量测试数据。

UI自动化的难度会高一个量级。难点在于定位器的生成与维护。一个很实用的方案是：把页面DOM解析结果（标签、属性、文本、层级关系）传给LLM，让它输出元素的定位路径。实测下来，对常见按钮、输入框、下拉框，效果不错；但对动态渲染的组件（比如表格里的某些列、弹窗里的某些元素），准确性会明显下降。原因是这些元素的属性通常没有语义信息，纯靠DOM文本推断，即使人看也未必能一次猜准。

另一个UI里的有效场景是脚本修复。页面改版后，大量的定位器失效。把旧定位器、失败的DOM快照、新的DOM结构一起发给LLM，让它找出新的定位方式。实测这个场景的成功率能做到60%-80%，能节省大量人工修脚本的时间。

4. 工程化落地：搭建AI自动化测试平台的五个关键环节

4.1 平台架构：从单点工具到测试中台

如果你只是个人写几个脚本用LLM辅助，那不涉及平台问题。但要在团队层面把AI测试能力固化下来，就需要一个相对完整的平台架构。我的搭法通常是四层：

数据层，负责管理需求文档、接口定义、历史用例、缺陷记录，处理它们的文本清洗、切片和向量化。模型层，部署和管理多个模型（本地开源模型+商用API），设计统一的调用接口，实现模型路由和热切换。服务层，提供用例生成、脚本生成、智能断言、缺陷分类等原子能力，向上以API形式暴露。应用层，对接现有的测试管理平台或CI/CD流水线，把AI能力嵌入测试研发流程。

这个架构其实并不复杂，关键是要想清楚每一层的输入输出接口，不要做成烟囱式的工具集合。

4.2 关键实现：Prompt模板管理与用例版本控制

平台化之后，有个细节容易被忽视：Prompt模板管理。团队里不同人写的Prompt风格差异很大，如果不统一管理，生成的用例质量会参差不齐。我的做法是把Prompt模板当作代码来管理，有版本、有评审、有变更记录。每个模板对应一类任务（用例生成、脚本修复、缺陷分类），模板参数从调用方传入，这样既保持了灵活性，又能保证质量的稳定性。

用例生成后也不能直接当成正式用例入库，需要经过人工评审和标注。这里我建议引入“AI生成用例的反馈机制”：评审人标注出哪些用例可用、哪些需要修改、哪些是误报，这些反馈定期回流用于优化Prompt和RAG检索策略。迭代几轮之后，生成质量会有明显提升。

4.3 自建Agent进行自动化测试：能做，但别期待完美

“自己搭建Agent进行自动化测试”是最近热度很高的方向。架构上，Agent的核心是一个决策循环：理解任务、拆解步骤、调用工具（浏览器操作、接口请求、断言执行）、观察结果、调整下一步行动。理论上，它能做到“你只告诉它测什么，它自己点完整个流程并汇报结果”。

实测感受是：Demo效果惊艳，生产环境还很勉强。问题出在两个方面，第一是步骤稳定性，长流程中偶尔某一步出现非预期弹窗或加载慢，Agent就很容易走偏，且纠错能力远不如人类。第二是断言准确性，Agent在判断“当前页面状态是否符合预期”时会出现幻觉，把实际正常的页面判定为异常，或者反过来漏掉真正的Bug。我目前只建议在高价值冒烟测试场景里引入Agent，且需要有完善的人机协同机制兜底。

4.4 数据安全与合规：本地部署的真正理由

前面提到过本地部署，这里展开说一下数据安全的重要性。测试环境里流转的数据往往包含线上脱敏后的真实业务数据、账号体系、内部API结构。这些数据一旦通过公网传输到第三方大模型服务，就存在泄露风险，在很多行业这是严重的安全事故。

本地部署开源模型后，所有推理都发生在内网，数据不出域，合规压力小很多。另一个容易被忽视的点是：本地部署的模型可以通过微调或LoRA，在你自己的历史测试用例数据上做领域适配，生成的用例更贴合团队的表达习惯和业务逻辑。这一点是商用API给不了的。

5. 常见问题与排查技巧实录

5.1 LLM生成用例不准确怎么办

这是大家最常遇到的问题。排查方向我建议按顺序来：

先检查Prompt，看业务规则描述是否完整、输出格式要求是否明确。再检查输入信息，看上传的接口文档或页面描述是否过时、是否遗漏关键业务流程。然后检查RAG检索效果，用关键词直接搜索向量库，看检索到的历史用例和信息是否相关。最后才是换模型，如果你的任务本身是强逻辑推理（比如复杂的业务流转规则推导），小模型的先天性不足确实会出现，只能换更大参数模型。

这里面最隐蔽也最常见的坑是输入信息过时。很多团队的接口文档维护不及时，模型基于旧文档生成的用例，当然和现网不一致。排查时先对齐文档和现网接口的差异，能快速定位不少问题。

5.2 模型输出格式不稳定

LLM是概率模型，同样的Prompt下输出格式可能有细微差异。解决思路是提升解析容错和增加约束。提升解析容错指写出能够容忍格式误差的解析器，比如用正则抽关键字段而不是全量解析。增加约束指让模型输出JSON或Markdown并用Schema校验。实测在System Prompt里明确“必须输出JSON，不要输出任何其他内容”，并且给出一个期望的JSON示例，格式违规的概率能大幅下降。

5.3 脚本修复误报率高

AI推荐的定位器中有一些是错的，执行后可能点到错误元素，带来比定位失败更严重的隐患。我的处理办法是：AI推荐的定位器不直接采用，而是先在测试环境里做一次预执行验证，只有验证通过的才允许合入。同时在执行日志中记录每次定位使用的路径，方便回溯问题。简单说，AI给出建议，人来决策，别让AI直接修改生产测试脚本。

5.4 推理速度慢影响测试效率

模型推理速度是本地部署绕不开的痛。7B模型在普通单卡上生成一段测试脚本可能需要几秒到十几秒，如果用例多，耗时积少成多。我的应对策略有三点：批量请求合并，把多条用例生成任务合并到一个Prompt里，减少模型调用次数；异步化，生成任务放进消息队列，CI流程不阻塞等待；用更轻量的模型，对简单任务（比如页面元素定位）用更小的模型，复杂任务才用大模型，按任务难度分级调用。

6. 下一步演进与实用建议

6.1 多模态模型在UI测试中的潜力

视觉大语言模型（VLM）的快速发展，我认为会给UI自动化测试带来新的解法。传统UI测试的痛点在于：页面结构千变万化，DOM解析费力且不稳定。而VLM可以直接“看”页面截图，理解页面上有什么、元素在哪里，从而以人类浏览页面的方式做测试。这个方向的进展很快，但目前定位精度还没达到工业级要求，直接用于断言判断还需要时间。

过渡期的思路是“图文结合”：用传统DOM解析做元素定位，用VLM做页面状态判断和异常识别。比如页面加载完成后截一张图，让VLM判断是否出现了预期的弹窗、按钮状态是否变化。这种方式比纯文本判断更接近人眼的验证方式。

6.2 测试数据生成与脱敏：被低估的场景

很多团队忽略了LLM在测试数据生成上的价值。造数据一直是测试里的老大难：手工构造数据费时，线上数据又不能直接用。LLM能根据数据表结构生成一批符合业务规则的仿真数据，也能基于真实数据生成脱敏版本。我用下来感觉，这个方向比用例生成更能立刻见效，投入产出比非常高。

6.3 给测试工程师的几点个人建议

最后说几点个人体会。第一，别等“完美方案”落地再行动。现在就可以用开源模型在本机把单点场景跑通，比如输入一段需求文本生成用例，先体验一下效果和边界。第二，重视Prompt和RAG，不要过度关注模型参数大小。同样的模型，Prompt和知识库设计得好，效果会完全不一样。第三，人机协同是长期状态。AI生成的用例、脚本、断言，在多数场景下需要人来把关，这个认知在团队里越早建立，后面就越不容易陷入“AI生成结果不可靠”的失望情绪。

我自己在这条路上的经验是：从单点场景切入，不要一开始就铺开做平台。选一个团队痛点最强烈的场景（通常是接口用例生成或脚本修复），把效果做到被团队认可，再逐步扩展。这比一开始就追求“全流程AI化”要稳妥得多，也更容易拿到支持。

这条路还在快速演进中，但核心逻辑没变：工具越强大，测试人员越需要具备判断力。大语言模型帮我们省去那些重复性的文本工作，而构造有价值的问题、判断结果的正确性，依然是我们这个职业不可替代的价值所在。

本文还有配套的精品资源，点击获取