1. 手工用例的智能化生成 San Meng 2025.5 、 1

2. 目录 1 序章 2 Agent介绍 3 技术实现 4 未来展望 CONTENTS 2

3. 序章-为什么要写手工用例？ 传统手工用例 AI时代下的手工用例挑战 用例生成Agent特性 未来变化 传统手工用例系统是对专家测 挑战： 1、快：低成本一键生成需求用 QA的工作善于利用Agent补充 试经验的沉淀，提供结构化管 • AI-coding不确定性带来更 例 用例、校准用例、确认结果。 高的质量风险和排查难度 2、准：根据业务特性自适应调 QA测试效率有可能跟不上 整用例的范围，精准测试。 研发开发效率 3、灵：用例的执行过程能够根 理及流程性支撑。挑战有： • 维护成本高 • 一致性差：不同QA的经验导 致用例质量参差不齐 • 灵活性不足：传统用例系统 难以适应需求的快速变化， 复用性低 • 难以自动化：手工用例的结 构和描述无法直接转化成自 动化 • 赋能： 据需求变化、专家输入、测试 • 提升用例生产效率，达到小 覆盖度、测试日志、缺陷情况 动态补充/调整用例。 时级别 • 手工用例的标准化和一致性 4、转：用例描述更加标准，能 将促进自动化快速生成 够快速转化成自动化用例(UI、 • AI强大推理能力和知识域将 接口等) 会提升测试覆盖度 3

4. 02 Agent介绍

5. 02Agent介绍-产品演示 基于PRD测试用例智能生成 基于专家经验的用例智能膨胀 5 用例智能检测

6. 02Agent介绍-功能介绍 产品能力 1 产品能力 3 基于PRD理解的一键生成用例 智能化用例治理 基于PRD的测试用例生成，可快速将文档转化为可执行用例，显著提升测试 通过大模型自动检测用例的规范性，包括步骤完整性、预期结果明确性等 准备效率。系统支持与现有用例系统融合，快速补充其他维度用例，内置的 关键要素，并给出优化建议。该功能可识别重复、冗余的用例，帮助团队 Chat交互模式让用例调整过程更加直观高效，降低测试人员的学习成本。 建立标准化用例库，确保测试资产的质量一致性，易于用例理解及自动化 转化 。 产品能力 2 产品能力 4 基于专家经验的用例智能膨胀 风险用例智能识别 结合用户沉淀的专家测试方法膨胀是系统自动分析当前用例验证点、功能及 对例进行语义分析，自动标记资损相关、高频变更等高风险场景用例，形 维度，智能补充边界值、异常场景等用例。基于用户故事上下文的学习能力 成重点回归测试集。通过建立风险等级标签体系，帮助团队优化测试资源 ，使膨胀的用例更贴合业务实际描述，降低个人经验不足的漏测问题。 分配，确保核心质量问题的能被少量用例发现，大幅提升回归测试效率。 6

7. 02Agent介绍-产品设计思路 已 实 现 FIRST 1 已 2 实 实 现 规 划 一 现 SECOND 半 THIRD 3 中 FOUR 4 基于PRD理解的用例生成 基于人机交互式用例生成 基于历史经验学习的持续迭代 基于过程反馈实时用例优化 通过大模型解析软件需求/技术 通过实时人机交互设计 ，用户 大模型结合历史测试数据调整 根据模型生成的测试用例在执行 文档，自动提取关键测试对象和 可动态调整生成策略，显著提升 用例生成策略，适应需求变 过程中的测试覆盖情况、过程结 场景，直接转化成手工用例。 用户在用例生成过程的的参与 化。例如基于历史用例、COE、 果动态更新、扩充当前用例测 度。 业务图谱等系信息进行用例生 试集合。 成。 自动化高 依赖文档质量 优 自我学习能力 需要有效的反馈 机制 用例迭代快 理解强 一致性 用户参与强 依赖解析方案 挑战 接受度高 优 数据依赖 运行成本低 模型对错误反馈 敏感 适应动态变化 挑战 优 7 用例持续迭代 反馈系统构建成 本 缺陷快速识别 复杂度增加 挑战 覆盖率高 优 处理反馈的效率 挑战

8. 02Agent介绍-核心挑战及实践方案 核心挑战 实践方案 问题 1、如何掌握全面的测试与业务知识，实现相对完整测试覆盖 1、 全面性 ： - 通过预训练、微调及RAG技术，将测试领域知识（如边界值分析、等价类划 - 基于150万+用例清洗业务知识图谱，结合RAG技术提升生成用例的完整性。 分）和业务文档（如PRD/用户手册）融入AI，使其理解系统逻辑 - 结合业务知识图谱技术，构建业务实体关系网络，增强复杂场景覆盖能力，避 免遗漏核心测试路径 VS 2、如何像测试专家一样精准设计用例，减少用例过渡生成(泛滥) - 通过人工反馈闭环优化用例生成。 - 通过专家用例建立功能与校验点的关联关系，提升设计准确性。 - 采用过拟合标记与修正机制进一步优化结果。(如未采纳的修正) - 引用专家设计的标杆用例，引导AI学习精准的测试模式。 - 结合对抗性训练，自动识别并修正冗余或重复场景。 2、 精准性： 改进 8

9. 03 技术实现

10. 03技术实现-整体架构 1 需求 功能 1 用例 3 评测 5 需求理解与功能实体生成 结合业务知识图谱解析rich-text文档，提取功能、业务对象及用户故事等关键信息。功能实体需与业 务图谱保持一致，确保数据关联性。同时结合测试风险分析，识别潜在缺陷场景为后续用例设计提供 依据。 2 4 技术 3 用例设计与分类规划 基于业务图谱和测试领域知识，对功能实体及测试风险进行用例设计。用例需覆盖正向、异常场景等 6 业务图谱 参考 4 设计方法 自定义 7 6 RAG 等，并按功能模块、分类规划提升用例的完整性和易读性。 用例模板 自定义 用户故事 COE 参考4 BUG 目前知识库主要包含了用例规范、测试领域、业务知识、 4 终端用户流分析 业务知识图谱的建立 历史用例蕴含丰富的业务功能、用户故事及测试要点，是构建业务图谱的核心数据源。通过分析历史 模型微调 RAG知识体系 用户故事等知识。 避坑点 用例提炼高频业务产品形态。 2 7 实现中。 5 AI生成用例与专家用例对比评测 通过对比AI生成用例与专家设计用例，评估AI在场景覆盖、逻辑严谨性等方面的表现。评测结果可指 导AI模型优化，提升测试用例的整体质量。 10

11. 03技术实现-RAG知识体系 历史知识 实时知识 测试规划 知识库设计思路 通用经验 历史缺陷/COE 文档 基于需求的用例生成，除「文档解析」中获取功能和 用户场景，通过「实时知识」输入和「业务图谱」， 测试理论 PRD 测试对象 模块1 测试专项方案 模块2 让AI能够更加完整理解需求设计，降低PRD质量带来 的潜质“幻觉”问题 。通用的测试经验及基于业务历史 模块… UI 业务图谱 用例等能够快速进行增量用例的设计(few-shot)，也会 产生“专家经验”避免用例 生成“过渡泛滥”。 技术方案 用例设计规范 用户故事/场景 功能1 功能2 功能… 测试方案 技术架构 RAG技术方式 在知识管理上支持向量化、业务知识图谱两种管理方 实时用例 校验点1 校验点2 式及混合召回能力。在检索技术上采用 前置query拆 分、意图改写，后置校准的等方式提升整体的意图识 校验点… 历史用例 别和精准召回能力。 11

12. 03技术实现-需求文档智能解析 核心思路 通过智能解析需求文档，提取关键信息如项目背景、测试对象、功能模块及其依赖关系，以及技 术实现方式。目标是构建结构化数据模型 ，为测试分析提供全面支持，确保测试覆盖率和精准度。 01 挑战 文档解析器需要能够识别rich-text的 大纲结构（标题层级）、内容元素（表格、代码块等）、视觉标 02 记（加粗/高亮）及上下文语义 。通过关系挖掘和语境分析，揭示功能模块间的依赖，避免测试遗漏。 分析内容 测试分析涵盖功能模块、接口、数据流等实体，需标注其属性与交互路径。例如，电商系统的“支付 03 模块”可能关联订单、风控等子模块，解析时需识别这些边界与数据传递规则。用户故事则需从文档中 提取对象-动作-结果三元组。 风险与测试重点 04 风险点常隐藏于技术实现描述或非功能性需求中 ，如“高并发场景下消息队列延迟”。解析器需结合技 术架构关键词（如“分布式锁”“缓存穿透”）标记潜在风险，并关联到性能测试或容灾测试方案 12

13. 03技术实现-业务知识图谱 业务知识图谱的核心价值 -业务知识图谱以「功能」为中心，构建了业务、页面、模块、功能、验证点之间的多层关联关 系。这种结构化设计能够为AI技术在用例设计领域的辅助生成和质量评估提供全面的知识支撑，例 如通过图谱自动推导测试场景或识别功能覆盖盲区。 01 实体定义的层级关系 -实体分为业务、页面、模块、功能、验证等维度。业务表示独立业务模型，页面是独立视图载体 ，模块由功能聚合而成，功能作为最小可测试单元直接面向用户，验证点则聚焦具体测试实例。 02 这种分层建模能清晰映射真实业务场景。 功能校验点的设计 -校验点则是对功能正向、逆向、异常、边界等处理逻辑正确性和合理性校验 。通过few- shot推导如何进行新功能用例设计，例如“检查支付接口返回状态码200”即为一个校验点。 03 知识图谱的应用场景 -该方案能有效提升测试用例智能生成的范围和准确性 。根据“订单业务→支付页面→风控 模块→指纹验证功能”的图谱路径，减少人工编写遗漏，同时保障核心业务场景的覆盖完整 性。 13 04 源于用例库(主) 源于需求文档库(辅)

14. 03技术实现-用例生成过程 用户故事及步骤设计 需求理解与风险评估 通过知识图谱补全功能细节，例如支付模块需包含金额计 从用户视角补充场景故事细节(故事主要来源于业务图谱) 算、风控规则等子项。评估修改影响范围时，需标记关联 ，例如“新用户首次使用优惠券下单”，明确前置条件（ 模块（如登录逻辑变更可能影响会话管理），并识别高风 如已登录且余额充足）。操作步骤需细化至原子级，并定 险点（如第三方接口调用），最终根据风险等级排序测试 义可验证的预期结果（如订单状态变更、扣款通知）。 优先级，确保核心链路优先覆盖。 01 02 03 需求拆解与关联分析 用例校验点设计 首先需将PRD中的核心功能功能模块逐项拆解，例如登录、 复用历史用例校验点，并从业务知识图谱中提取常见验证 支付等，并绘制功能依赖关系图，明确模块间的交互逻辑。 范围和验证点提升用例的针对性和覆盖率。 例如输入框边 例如支付功能依赖订单系统，需重点标注此类强依赖关系， 界值测试或用户从购物车到支付的完整流程。 同时区分前后端测试层级，确保接口和组件的全覆盖测试。 14 04

15. 03技术实现-评测方案 指标1：AI生成校验点的召回率(recall) 召回率衡量的是AI生成用例校验点覆盖真 实需求的能力，即“找全”的能力。高召回率 意味着系统能尽可能减少遗漏关键校验点 的情况 指标 小项目 小项目 大项目 大项目 无知识图谱 有知识图谱 无知识图谱 有知识图谱 85.8% 94.7% 69.7% 81.1% 46.2% 59.2% 55.3% 64.2% AI生成校验点的召 回率 AI生成校验点的精 确率 AI生成耗时 4~6min 12~20min 指标2：AI生成校验点的精确率(precision) 精准率反映AI生成校验点的正确性，即“找 对 ”的能力。高精确率能有效降低用例生成 “泛滥”。 指标3：耗时评估 观察指标：用例详情描述准确性 生成用例的平均耗时直接影响测试效率。 用例详情中包含条件、步骤、期望，决定 需要考虑小项目和大项目的差异性。 了用例的可执行性。使用知识图谱的效果 非常明显，基本符合应用的描述。 相对专家人工编写，AI生成小项目表现不错，同时需要重点优化大项目分析准确性及知识库的完整性，提升大项 目的生成召回率。思路上会走”人机交互”模式可以有效提升参与度和覆盖准确性。 15

16. 04 未来展望

17. 04未来展望 应用层 服务层 需求PRD优化 测试方案 需求分析 评估 风险识别 需求分析完整度 需求用例生成 测试用例生成规划 测试方案规划 风险覆盖率 AI COT FewShot 文档切割 RAG 数据层 测试用例执行规划 风险准确率 提示词工程 处理 需求用例智能评审 用例采纳率 多模态处理 知识库管理 用例覆盖度 需求用例库治理 知识图谱更新 性能评估 后处理 自定义 文本理解 流程图理解 标准化输出 干预配置 提示词调优 UI稿理解 跳转链接 异常处理 自定义知识库 文档清洗 测试对象提取 向量/业务图谱存储 检索策略 ReAct 知识管理 Embedding-Query-Retriver-Reranker-Reader 测试物料 用例资产 知识资产 标准规范 需求分析 测试用例 风险识别及应对 用例编写规范 技术方案 缺陷库 通用测试设计 测试代码 故障库 专项测试设计 规划中 用例设计完整性规范 现有能力 产品化解决方案 大模型 17

18. Q&A 更多技术干货 欢迎关注“美团技术团队” 18