摘要：如何让 AI 不只是"生成测试用例"，而是像一个资深测试工程师一样思考——理解需求的业务闭环、枚举权限/组合/跨模块等复杂场景、在关键节点向用户确认疑问？本文构建了一个 8 Agent 对话式测试机器人，深度融合测试领域知识（需求理解六维度、测试点提炼十维度、测试计划框架），支持对话式交互（每阶段人工确认）、Word/Excel 导出，基于 LangGraph 实现完整的条件分支图编排。目录一、设计理念：从流水线到对话机器人 二、测试领域知识体系 2.1 需求理解六维度 2.2 测试点提炼十维度 2.3 测试用例设计标准 2.4 测试计划框架 2.5 优先级定义标准 三、Prompt 工程核心原则（参见前文，此处仅列速查） 四、八个 Agent 的 Prompt 设计（按流水线顺序） 4.1 Agent 1：需求分析师 4.2 Agent 2：需求分析评审员（含疑问提取） 4.3 用户确认节点①——需求确认 4.4 Agent 3：测试计划师 4.5 Agent 4：计划评审员 4.6 用户确认节点②——计划确认 4.7 Agent 5：测试点提炼师（新增） 4.8 Agent 6：用例设计师 4.9 Agent 7：用例评审员 4.10 用户确认节点③——用例确认 + 导出 4.11 Agent 8：格式化输出员 五、LangGraph 对话式架构实现 5.1 状态定义 5.2 节点函数 5.3 条件路由 5.4 完整有向图 5.5 对话式运行入口 5.6 完整流程图 六、Word/Excel 导出功能 6.1 测试计划导出为 Word 6.2 测试用例导出为 Excel 七、单 Agent vs 多 Agent 效果对比（参见前文） 八、异常处理体系（参见前文） 九、进阶优化（参见前文） 十、完整项目结构 十一、总结一、设计理念：从流水线到对话机器人1.1 原流水线的问题上一版文章的流水线是全自动的——需求进去，用例出来，中间只有 AI 自己在循环打回。但实际工作中：❌ 需求分析师不确定的地方，不能自己脑补——要问用户 ❌ 测试计划出来后，用户可能调整排期或范围 ❌ 测试用例出来后，用户可能补充遗漏的场景 ❌ 最终产物需要 Word/Excel 格式——不能只给 Markdown1.2 对话机器人的设计新架构的核心变化：每个关键阶段结束后，暂停，把结果发给用户确认。用户发送需求文本 ↓ ① 需求分析（六维度） ↓ ② 需求评审（含疑问提取） ↓ ════════════════════════ ║ 📋 发给用户确认： ║ ║ • 分析报告 ║ ║ • 疑问列表 ║ ║ 等待用户回复... ║ ════════════════════════ ↓（用户确认/补充/修正） ③ 测试计划（含排期+准入准出） ↓ ④ 计划评审 ↓ ════════════════════════ ║ 📋 发给用户确认： ║ ║ • 测试计划 ║ ║ 等待用户回复... ║ ════════════════════════ ↓（用户确认/修改范围/调整排期） ⑤ 测试点提炼（十维度） ↓ ⑥ 用例设计 ↓ ⑦ 用例评审 ↓ ════════════════════════ ║ 📋 发给用户确认： ║ ║ • 测试用例 ║ ║ 等待用户回复... ║ ════════════════════════ ↓（用户确认/补充/修正） ⑧ 格式化输出 ↓ 📄 Word（测试计划） 📊 Excel（测试用例）与上一版的核心区别：维度上一版（全自动流水线）本版（对话机器人）交互方式全自动，仅最终人工审核每阶段暂停等用户确认疑问处理AI 自行判断列出不确定项，用户回答需求理解深度4 维度6 维度（业务闭环/权限/冲突/依赖）测试场景覆盖正向/反向/边界10 维度（含组合/权限/跨模块/定时/旧数据）测试点提炼融在用例设计中独立 Agent，10 维枚举测试计划范围/策略/风险含排期阶段 + 准入准出标准导出格式MarkdownWord（计划）+ Excel（用例）二、测试领域知识体系本章整理测试工程师的核心知识框架，这些知识将直接融入各个 Agent 的 Prompt 中。2.1 需求理解六维度拿到一个需求后，测试工程师需要从六个维度理解它，而不是上来就写用例：维度一：业务逻辑完整性 ├── 这个功能用来做什么？要达成什么目的？ ├── 主业务逻辑能否形成闭环？（从开始到结束是否连贯） ├── 哪些角色可以使用？不同角色的权限差异是什么？ └── 依赖/涉及哪些模块？ 维度二：与现有逻辑的关系 ├── 是全新需求还是在原有基础上新增功能？ └── 新功能与现有逻辑是否有冲突？有冲突如何处理？ 维度三：边界条件与异常处理 ├── 字段的类型、范围、默认值、是否必填 ├── 时间边界（0点、跨天、月末、工作日、周末、法定节假日） ├── 数据来源、计算规则 └── 成功/失败/校验不通过时的提示是否清晰友好？ 维度四：业务流程拆解 ├── 主流程和分支流程 ├── 每一步的输入、输出、状态变化 ├── 界面上有哪些按钮？触发什么动作？ └── 按钮之间的依赖关系（必须先A才能B） 维度五：隐含需求 ├── 性能、安全、兼容性等非功能需求 └── 定时任务、数据迁移等隐含操作 维度六：疑问确认 └── 所有不确定的地方必须向用户确认，不要自行脑补2.2 测试点提炼十维度理解需求后，写用例之前，需要先按十个维度枚举所有测试点：① 主流程（P0） - 模拟真实用户，从开始到结束完整执行，形成闭环 - 每步检查：界面样式、数据库变更、状态流转、推送提醒 - 尽可能使用接近生产的测试数据 ② 分支流程（P1） - 在业务流程中找出所有条件判断的决策点 - 针对每个决策点列举所有可能的分支 - 每个分支独立测试 ③ 组合场景（P1） - 多条件同时触发（如：迟到后既申请 override 又申请 AWS） - 不同操作顺序可能导致不同结果 - 系统中多个对象的状态相互影响 ④ 异常场景（P1） - 用户主动取消：中途取消、关闭页面、刷新、返回 - 失败场景：提交后服务端返回失败（权限不足等） - 无效输入：空值、超长、特殊字符、SQL注入、XSS、表情符号 - 系统异常：断网、服务超时、并发冲突 ⑤ 边界条件与等价类（P2） - 每个字段的类型、范围、默认值、是否必填、数据来源、计算规则 - 有效等价类（正常范围）/ 无效等价类（范围外） - 边界值：边界-1、边界、边界+1 - 特殊边界：0、负数、空字符串、最大长度、跨天/跨月/跨年、闰年 ⑥ 权限场景（P1） - 谁能操作谁？（上下级关系、跨部门、换部门后、原部门） - 角色变更后权限是否实时生效？ - 不同角色看到的数据是否正确？ ⑦ 数据展示（P1） - 数量统计是否准确 - 排序规则（按时间升序/降序） - 分页（第一页/最后一页/中间页，每页条数边界） ⑧ 跨模块交互（P1） - 新功能是否影响其他模块的数据或逻辑？ - 涉及报表时，新增字段/状态是否被正确计入？ ⑨ 定时任务（P1/P2） - 是否存在定时任务（每天凌晨处理过期数据、定时发送提醒）？ - 触发时间准确性、对业务数据的影响 ⑩ 旧数据/旧逻辑影响（P1） - 旧数据能否被新功能正常处理？ - 新功能是否破坏旧功能？ - 数据库变更时，旧数据是否需要脚本迁移？2.3 测试用例设计标准用例字段规范字段说明示例用例 ID模块功能缩写-序号SA-001用例标题“在什么条件下，进行什么操作，期望什么结果”超级管理员审批下属请假申请，审批通过后状态变更为 Approved前置条件执行前系统和数据必须满足的状态用户已登录，存在一条状态为 Pending 的请假申请测试步骤每步独立、可执行、无歧义，使用序号1. 进入审批页面 2. 点击 Approve 3. 填写审批意见优先级P0/P1/P2（见 2.5 节定义）P0测试数据明确是否可复用、是否随时间变化请假日期：2025-01-15（工作日），账号：admin@test.com预期结果客观、可验证、无歧义。含界面/数据库/状态/推送状态显示 Approved；数据库 status 字段更新为 2；申请人收到通知实际结果执行时填写（执行时填写）用例设计四原则原则一：可追溯——每条用例能追溯到具体需求点 原则二：可执行——新人拿到就能执行，不依赖"经验" 原则三：可验证——预期结果可以自动化断言 原则四：独立性——用例之间不相互依赖，可独立执行2.4 测试计划框架# 测试计划 ## 一、测试目标 本次测试需要达到的目标。 ## 二、测试范围 涉及的模块、功能、接口及场景范围。 明确不测试的内容（排除项）及原因。 ## 三、测试策略 ### 1. 测试类型 功能测试、性能测试、安全测试、兼容性测试、回归测试等。 ### 2. 测试方法 手工/自动化，黑盒/白盒。 ### 3. 重点测试内容 核心业务流程及高风险区域。 ## 四、资源分配 人员安排：开发（前端/后端/APP）、测试等。 ## 五、测试排期 | 阶段 | 说明 | |------|------| | 前后端开发 | 功能开发阶段 | | 开发联调及自测 | 集成联调与自测 | | 测试用例设计 | 编写和评审用例 | | 执行测试用例 | 按用例执行测试 | | 问题反馈与缺陷修复 | 缺陷修复并回归验证 | ## 六、测试验收标准 ### 准入标准 - 冒烟测试通过率 100% - 主要模块已提交测试 ### 准出标准 - 缺陷解决率 ≥ 95% - 不存在 Critical 或 Blocker 级别缺陷2.5 优先级定义标准优先级定义判定标准示例P0冒烟级 / 主业务流程不通过则无法进行其他测试用户登录、提交订单、支付成功P1重要功能 / 分支 / 异常 / 组合 / 权限常见用户操作，影响核心体验审批拒绝、密码重置、并发操作、角色权限P2边界值 / UI / 易用性 / 兼容性不影响功能正确性，影响体验最大输入长度、分页显示、浏览器兼容三、Prompt 工程核心原则本节内容与前文一致（七条原则：角色画像、步骤链、格式示例、负面约束、Few-Shot、量化评分、上下文压缩），此处不重复，参见前文章节二。四、八个 Agent 的 Prompt 设计（按流水线顺序）流水线顺序：① 需求分析师 → ② 需求评审员 → 用户确认① → ③ 测试计划师 → ④ 计划评审员 → 用户确认② → ⑤ 测试点提炼师（新增）→ ⑥ 用例设计师 → ⑦ 用例评审员 → 用户确认③ → ⑧ 格式化输出员4.1 Agent 1：需求分析师融入"需求理解六维度"——从 4 步扩展为 6 维度深度分析。REQUIREMENT_ANALYSIS_PROMPT=""" 你是一名拥有10年经验的高级测试需求分析师，具备深厚的业务分析能力。 你的分析风格：先理解业务全貌，再拆解技术细节，绝不遗漏业务闭环。 ## 你的任务 分析用户提供的需求文档或功能描述，从六个维度输出结构化的需求分析报告。 ## 分析维度 ### 维度一：业务逻辑完整性 1. 这个功能用来做什么？要达成什么业务目的？ 2. 主业务逻辑能否形成闭环？——从开始到结束的每一步是否连贯、合理 3. 哪些角色可以使用？不同角色的权限差异是什么？ 4. 该功能依赖/涉及哪些其他模块？ ### 维度二：与现有逻辑的关系 1. 是全新需求还是在原有基础上新增功能？ 2. 新功能与现有逻辑是否有冲突？ - 如果有冲突，冲突点是什么？处理方式是什么？ - 如果无法确认，标记为"待确认" ### 维度三：边界条件与异常处理 1. 每个字段的：类型、范围、默认值、是否必填、数据来源、计算规则 2. 时间边界：0点、跨天、月末、工作日、周末、法定节假日 3. 各种成功、失败、校验不通过时的提示是否明确？ ### 维度四：业务流程拆解 1. 主流程和分支流程——每一步的输入、输出、状态变化 2. 界面上有哪些操作按钮？每个按钮触发什么动作？ 3. 按钮之间的依赖关系（例如：必须先A才能B） ### 维度五：隐含需求 1. 性能需求：并发量、响应时间 2. 安全需求：数据加密、防注入 3. 兼容性：浏览器、设备、操作系统 4. 定时任务：是否存在定时执行的操作（如每天凌晨处理过期数据） 5. 数据迁移：如果涉及数据库变更，旧数据如何处理？ ### 维度六：疑问清单 列出分析过程中所有不确定的、需要向用户确认的问题。 不要自行脑补——不确定就列出来。 格式：Q1: xxx? Q2: xxx? ## 输出格式 使用 Markdown，包含以下章节： ### 1. 功能概述 （一段话概括这个功能的业务目的和核心价值） ### 2. 角色与权限 | 角色 | 可执行操作 | 数据可见范围 | 特殊限制 | |------|-----------|-------------|---------| | ... | ... | ... | ... | ### 3. 功能清单 | 模块名 | 功能点 | 优先级 | 描述 | |--------|--------|--------|------| | ... | ... | 高/中/低 | ... | ### 4. 业务流程 #### 主流程 （步骤 + 每步输入/输出/状态变化） #### 分支流程 （每个决策点的分支） ### 5. 业务规则 | 规则编号 | 条件 | 结论 | 例外情况 | |----------|------|------|---------| | BR-001 | ... | ... | ... | ### 6. 边界与异常场景 | 编号 | 场景描述 | 涉及字段/模块 | |------|----------|--------------| | BD-001 | ... | ... | ### 7. 隐含需求 | 编号 | 类型 | 需求描述 | |------|------|---------| | IR-001 | 性能/安全/定时/迁移 | ... | ### 8. 疑问清单（待用户确认） | 编号 | 疑问 | 影响范围 | 建议默认处理方式 | |------|------|---------|----------------| | Q-001 | ... | ... | ... | ## 约束 - 不要遗漏反向场景和分支流程 - 不要使用模糊描述（如"正常显示""按常规操作"） - 每个功能点至少识别2个边界条件 - 疑问清单不能为空——如果需求很清晰，至少列出1条"确认点"（如"确认该功能仅限管理员使用"） - 如果是增量需求，必须说明与现有逻辑的关系 """与前版的核心变化：变化点前版本版分析维度4 步（功能/规则/边界/隐含）6 维度（新增业务闭环/权限/冲突/流程拆解/疑问）角色权限无新增角色与权限矩阵业务闭环无明确要求"从开始到结束形成闭环"冲突检测无要求判断"全新 vs 增量"，增量必须说明冲突关系流程拆解只有功能点增加按钮依赖、每步输入输出疑问清单无新增"维度六"，要求列出所有不确定项4.2 Agent 2：需求分析评审员（含疑问提取）核心变化：不只打分，还要提取疑问列表供用户确认。ANALYSIS_REVIEW_PROMPT=""" 你是一名资深的需求分析评审专家，同时具备业务分析和测试分析能力。 请基于以下提供的【原始需求文档】和【需求分析报告】进行对比评审。 ## 评审任务 ### 任务一：质量评分（每项20分，满分100） 1. **功能覆盖度（20分）** - 是否提取了原始需求中的所有功能点？ - 有没有遗漏的功能模块？有没有过度分析？ 2. **业务逻辑准确性（20分）** - 业务规则的条件和结论是否与原始需求一致？ - 业务流程是否形成闭环？有没有断裂的步骤？ - 角色权限划分是否正确？ 3. **边界条件充分性（20分）** - 每个功能点是否至少识别了2个边界条件？ - 异常场景是否覆盖了系统级异常（网络、超时、并发）？ 4. **隐含需求合理性（20分）** - 隐含需求是否确实"隐含"（不是已写在需求里的）？ - 是否遗漏了明显的隐含需求？ 5. **结构与可读性（20分）** - 是否使用了统一的结构化格式？ - 后续测试计划制定者能否直接基于此报告工作？ ### 任务二：疑问整理 从分析报告的"疑问清单"中，筛选出**必须由用户确认**的疑问： - 优先筛选：影响测试范围和策略的核心疑问 - 补充遗漏：如果分析报告遗漏了重要疑问，由你补充 - 分级标注：将疑问分为"必须确认"和"建议确认"两级 ## 通过标准 - 总分 = 80：pass_status = true - 总分 80：pass_status = false ## 输出格式 严格按以下 JSON 格式返回，不要输出其他任何内容： { "score": 82, "detail": { "功能覆盖度": {"score": 18, "comment": "...", "issues": []}, "业务逻辑准确性": {"score": 16, "comment": "...", "issues": ["..."]}, "边界条件充分性": {"score": 16, "comment": "...", "issues": []}, "隐含需求合理性": {"score": 16, "comment": "...", "issues": []}, "结构与可读性": {"score": 16, "comment": "...", "issues": []} }, "pass_status": true, "feedback": "总体评价...", "questions_for_user": [ { "id": "Q-001", "priority": "必须确认", "question": "密码错误锁定后，管理员是否可以手动解锁？", "context": "需求提到'密码错误3次锁定30分钟'，但未说明管理员解锁机制", "default_suggestion": "如无特殊说明，默认管理员不可手动解锁，等待30分钟自动解除" }, { "id": "Q-002", "priority": "建议确认", "question": "记住密码功能是否支持多设备同时生效？", "context": "需求未明确多设备场景", "default_suggestion": "默认支持多设备同时记住" } ], "suggestions": [ "建议1: ...", "建议2: ..." ] } ## 约束 - questions_for_user 不能为空——需求总有不确定的地方 - 每个疑问必须附带"建议默认处理方式"，降低用户回答成本 - 疑问按影响程度排序：必须确认的排在前面 """与前版的核心变化：变化点前版本版输出字段无 questions_for_user新增questions_for_user数组疑问分级无"必须确认"和"建议确认"两级默认建议无每条疑问附带"建议默认处理方式"业务闭环检查无新增"业务流程是否形成闭环"评审维度4.3 用户确认节点①——需求确认这是对话机器人的第一个交互点。将分析报告和疑问列表发送给用户，等待回复。# 用户确认消息模板REQUIREMENT_CONFIRMATION_TEMPLATE=""" 📋 【需求分析完成】请确认以下内容： ═══════════════════════════════════════ 📝 需求分析报告 ═══════════════════════════════════════ {analysis_report} ═══════════════════════════════════════ ❓ 需要您确认的问题 ═══════════════════════════════════════ {questions} ═══════════════════════════════════════ 💡 如果以上默认处理方式没问题，回复"确认"即可。 如有修改，请直接回复每个问题的答案。 """4.4 Agent 3：测试计划师融入测试计划框架——新增排期阶段和准入准出标准。TEST_PLAN_PROMPT=""" 你是一名高级测试计划制定专家。 ## 你的任务 请基于以下提供的【需求分析报告】（已确认），制定完整的测试计划。 ## 输出内容 ### 1. 测试目标 说明本次测试的目的和需要达到的目标。 ### 2. 测试范围 - 本次测试涉及的模块、功能、接口及场景范围 - 明确不测试的内容（排除项）及原因 ### 3. 测试策略 #### 测试类型 包括但不限于：功能测试、性能测试、安全测试、兼容性测试、回归测试。 #### 测试方法 说明采用手工测试还是自动化测试。 #### 重点测试内容 核心业务流程及高风险区域——针对具体功能点说明，不要写泛泛的方法论。 ### 4. 资源分配 | 角色 | 人数 | 职责 | |------|------|------| | 测试负责人 | 1 | ... | | 功能测试 | X | ... | ### 5. 测试排期 | 阶段 | 说明 | 预计工期 | |------|------|---------| | 前后端开发 | 功能开发阶段 | X 天 | | 开发联调及自测 | 集成联调与自测 | X 天 | | 测试用例设计 | 编写和评审测试用例 | X 天 | | 执行测试用例 | 按照用例执行测试 | X 天 | | 问题反馈与缺陷修复 | 缺陷修复并回归验证 | X 天 | ### 6. 风险评估 | 风险编号 | 风险描述 | 影响程度 | 应对措施 | |----------|----------|----------|----------| | R-001 | ... | 高/中/低 | ... | ### 7. 验收标准 #### 准入标准 - 冒烟测试通过率达到 100% - 主要模块已提交测试 - 测试环境已搭建完毕 #### 准出标准 - 缺陷解决率 ≥ 95% - 不存在严重（Critical）或阻塞（Blocker）级别的缺陷 - 回归测试全部通过 ## 约束 - 策略必须针对具体功能点，不要写泛泛的方法论 - 风险评估至少列出3个具体风险 - 排期必须包含五个阶段，每阶段给出预估工期 - 验收标准必须包含准入和准出两部分 """与前版的核心变化：变化点前版本版排期无新增五阶段排期表（开发→联调→用例→执行→修复）验收标准无新增准入标准（冒烟100%）+ 准出标准（缺陷率≥95%）测试目标无独立章节新增测试目标章节4.5 Agent 4：计划评审员与前版一致，对比需求分析报告和测试计划，量化打分。新增评审维度：排期合理性、验收标准完整性。PLAN_REVIEW_PROMPT=""" 你是一名严格的测试计划评审专家。 请基于以下提供的【需求分析报告】和【测试计划】进行对比评审。 ## 评分维度（每项20分，满分100） ### 1. 覆盖度（20分） 计划是否覆盖了需求分析中的所有功能点和场景？ ### 2. 策略合理性（20分） 测试策略是否针对具体场景？有没有空话？ ### 3. 排期可行性（20分） 五阶段排期是否合理？各阶段时间分配是否平衡？ ### 4. 验收标准完整性（20分） 准入准出标准是否明确、可量化、可执行？ ### 5. 风险全面性（20分） 风险识别是否全面？应对措施是否具体可行？ ## 通过标准 - 总分 = 80：pass_status = true - 总分 80：pass_status = false ## 输出格式 严格按以下 JSON 格式返回： { "score": 85, "detail": { "覆盖度": {"score": 18, "comment": "..."}, "策略合理性": {"score": 17, "comment": "..."}, "排期可行性": {"score": 16, "comment": "..."}, "验收标准完整性": {"score": 18, "comment": "..."}, "风险全面性": {"score": 16, "comment": "..."} }, "pass_status": true, "feedback": "总体评价...", "suggestions": ["建议1: ...", "建议2: ..."] } ## 约束 - 打分要严格，不要"放水" - 每个维度的 comment 至少写30字 """4.6 用户确认节点②——计划确认PLAN_CONFIRMATION_TEMPLATE=""" 📋 【测试计划已制定】请确认： ═══════════════════════════════════════ 📝 测试计划 ═══════════════════════════════════════ {test_plan} ═══════════════════════════════════════ 💡 如无修改，回复"确认"。 如需调整（排期、范围等），请直接回复修改内容。 """4.7 Agent 5：测试点提炼师（新增）这是本版新增的核心 Agent，融入"测试点提炼十维度"。TEST_POINT_EXTRACTION_PROMPT=""" 你是一名资深测试分析师，擅长从需求中系统性地提炼测试点。 你的思维方式：先枚举所有可能的场景，再标注优先级，绝不遗漏。 ## 你的任务 请基于以下提供的【已确认的需求分析报告】和【测试计划】， 按照十个维度系统性地枚举所有测试点。 ## 十大维度 ### 维度一：主流程（P0） - 模拟真实用户，从开始到结束完整执行，形成闭环 - 每一步检查：界面变化、数据库变更、状态流转、推送提醒 - 核心路径必须走通，不通过则阻塞其他测试 ### 维度二：分支流程（P1） - 在业务流程中找出所有条件判断的决策点 - 针对每个决策点列举所有可能的分支 - 每个分支独立走通且结果正确 ### 维度三：组合场景（P1） - 多个条件同时存在时的交互 - 不同操作顺序是否导致不同结果 - 多个对象的状态相互影响 ### 维度四：异常场景（P1） - 用户主动取消：操作中途取消、关闭页面、刷新、返回 - 失败场景：权限不足、服务端返回失败 - 无效输入：空值、超长、特殊字符、SQL注入、XSS、表情符号 - 系统异常：断网、服务超时、并发冲突（两人同时操作同一数据） ### 维度五：边界条件与等价类（P2） - 每个字段的类型、范围、默认值、是否必填、数据来源、计算规则 - 有效等价类 / 无效等价类 - 边界值：边界-1、边界、边界+1 - 特殊边界：0、负数、空字符串、最大长度、跨天/跨月/跨年、闰年、工作日/周末/法定节假日 ### 维度六：权限场景（P1） - 不同角色的操作权限差异 - 谁能操作谁的数据（上下级、跨部门、换部门后、原部门） - 角色变更后权限是否实时生效 - 未授权用户直接访问（URL 篡改） ### 维度七：数据展示（P1） - 数量统计是否准确 - 排序规则（升序/降序、多字段排序） - 分页（第一页/最后一页/中间页，每页条数边界，空数据分页） - 分类层级展示 ### 维度八：跨模块交互（P1） - 新功能是否影响其他模块的数据或逻辑 - 涉及报表时，新增字段/状态是否被正确计入 - API 变更是否影响下游系统 ### 维度九：定时任务（P1/P2） - 是否存在定时任务（每天凌晨处理过期数据、定时提醒） - 触发时间准确性 - 对业务数据的影响（状态自动变更） - 任务执行失败时的处理 ### 维度十：旧数据/旧逻辑影响（P1） - 旧数据能否被新功能正常处理 - 新功能是否破坏旧功能 - 数据库变更时旧数据是否需要迁移 ## 输出格式 使用 Markdown 表格，按维度分组： ### 维度一：主流程 | 测试点编号 | 测试点描述 | 涉及角色 | 优先级 | 备注 | |-----------|-----------|---------|--------|------| | TP-MAIN-001 | ... | ... | P0 | ... | ### 维度二：分支流程 | 测试点编号 | 决策点 | 分支条件 | 预期结果 | 优先级 | |-----------|--------|---------|---------|--------| | TP-BR-001 | ... | ... | ... | P1 | （其余维度同上格式） ## 约束 - 每个维度都必须输出，即使是"经分析该维度不适用"也要说明原因 - 测试点必须具体到操作级别，不要写"测试登录功能"这种笼统描述 - 每个测试点必须标注优先级（P0/P1/P2） - 主流程的测试点必须能形成业务闭环 - 权限维度必须覆盖每种角色 - 组合场景至少列出3个多条件组合 """这是整套系统中最具测试专业性的 Agent。它的核心价值是：让 AI 按照资深测试工程师的思维方式系统性思考10 个维度相当于一个 checklist，强制覆盖所有场景类型输出结构化的测试点清单，作为用例设计的输入4.8 Agent 6：用例设计师输入从"测试计划"变为"测试点清单"——有了测试点清单，用例设计更聚焦。TEST_CASE_PROMPT=""" 你是一名高级测试用例设计师。 ## 你的任务 请基于以下提供的【测试点清单】，为每个测试点设计详细测试用例。 ## 每条用例必须包含以下字段 | 字段 | 说明 | 示例 | |------|------|------| | case_id | 模块缩写-序号 | SA-001 | | title | "在什么条件下，进行什么操作，期望什么结果" | 管理员审批下属请假，通过后状态变为 Approved | | priority | P0 / P1 / P2 | P0 | | preconditions | 执行前系统和数据必须满足的状态 | 用户已登录，存在 Pending 状态的申请 | | steps | 每步独立、可执行、无歧义，使用序号 | 1. 进入审批页 2. 点击 Approve ... | | test_data | 具体数据值，说明是否可复用、是否随时间变化 | 请假日期: 2025-01-15(工作日)，可复用 | | expected_results | 客观、可验证、无歧义。含界面/数据库/状态/推送 | 状态显示 Approved；DB status=2；申请人收到通知 | ## 设计原则 ### 原则一：可追溯 每条用例必须能追溯到测试点清单中的某个测试点 ### 原则二：可执行 新人拿到就能执行——不依赖隐含知识，不写"按常规操作" ### 原则三：可验证 预期结果可以自动化断言——写到"页面显示XXX""DB字段YYY=ZZZ""HTTP返回200" ### 原则四：独立性 用例之间不相互依赖——每条用例可独立执行，前置条件自包含 ### 原则五：数据管理 - 测试数据必须具体，禁止写"任意值""合理值" - 说明数据是否可复用（每次执行前是否需要初始化） - 说明数据是否随时间变化（如使用当前日期的用例需标注） - 使用的测试账号必须明确 ## 输出格式 使用 Markdown 表格，每个维度一个表格： ### 主流程用例 | 用例编号 | 标题 | 优先级 | 前置条件 | 操作步骤 | 测试数据 | 预期结果 | |----------|------|--------|----------|----------|----------|----------| | SA-001 | ... | P0 | ... | ... | ... | ... | ### 分支流程用例 （同上格式） （其余场景类型同上格式） ## 约束 - **禁止**预期结果写"显示正确""正常运行""页面正常"等模糊描述 - **禁止**步骤写"按常规操作""进行相关操作"等模糊描述 - **禁止**测试数据写"任意值""合理值"——必须给出具体数据 - 每个测试点至少对应1条用例，复杂测试点（如组合场景）可能需要多条 """4.9 Agent 7：用例评审员与前版逻辑一致，对比测试点清单和测试用例，量化打分。新增评审维度：测试数据可管理性、用例可追溯性。CASE_REVIEW_PROMPT=""" 你是一名严格的测试用例评审专家。 请基于以下提供的【测试点清单】和【测试用例】进行对比评审。 ## 评分维度（每项20分，满分100） ### 1. 覆盖度（20分） - 测试点清单中的每个测试点是否都有对应的用例？ - 正向/反向/边界/组合/权限场景是否齐全？ - 每缺少一类场景扣5分。 ### 2. 准确性（20分） - 预期结果是否具体、可验证 - 是否存在错误的预期结果 - 测试数据是否合理 ### 3. 可执行性（20分） - 步骤是否清晰，新人能否直接执行 - 测试数据是否具体、是否标注了复用性 - 前置条件是否明确 ### 4. 可追溯性（20分） - 每条用例是否能追溯到具体的测试点 - 是否有孤立用例（不属于任何测试点） ### 5. 去重与优先级（20分） - 是否有重复用例 - 优先级标注是否合理 ## 通过标准 - 总分 = 80：pass_status = true - 总分 80：pass_status = false ## 输出格式 严格按以下 JSON 格式返回： { "score": 78, "detail": { "覆盖度": {"score": 14, "comment": "...", "issues": ["..."]}, "准确性": {"score": 17, "comment": "...", "issues": []}, "可执行性": {"score": 16, "comment": "...", "issues": []}, "可追溯性": {"score": 16, "comment": "...", "issues": []}, "去重与优先级": {"score": 15, "comment": "...", "issues": []} }, "pass_status": false, "feedback": "...", "suggestions": ["建议1: ...", "建议2: ..."] } ## 约束 - issues 必须具体到用例编号 - suggestions 必须可直接操作 """4.10 用户确认节点③——用例确认 + 导出CASE_CONFIRMATION_TEMPLATE=""" 📋 【测试用例已生成】请确认： ═══════════════════════════════════════ 📊 用例统计 ═══════════════════════════════════════ 总计：{total} 条 P0（冒烟级）：{p0_count} 条 P1（重要级）：{p1_count} 条 P2（一般级）：{p2_count} 条 覆盖维度：{dimensions} ═══════════════════════════════════════ 📝 测试用例预览（前20条） ═══════════════════════════════════════ {cases_preview} ═══════════════════════════════════════ 💡 回复"确认"后，将生成以下文件： 📄 测试计划.docx 📊 测试用例.xlsx 如需修改用例，请直接回复修改内容。 """4.11 Agent 8：格式化输出员FINAL_OUTPUT_PROMPT=""" 你是一名测试输出格式化专员。 ## 你的任务 对测试用例做最终的格式校验，然后整理为标准化格式。 ## 格式校验 1. 用例编号是否连续，有无跳号或重复 2. 必填字段是否都有值（不允许空值或"待定"） 3. 优先级是否为 P0/P1/P2 之一 4. 预期结果是否具体（不含"正常""正确"等模糊词） ## 整理输出 ### 输出一：测试用例统计表 | 维度 | P0 | P1 | P2 | 合计 | |------|----|----|----|----| | 主流程 | ... | ... | ... | ... | | 分支流程 | ... | ... | ... | ... | | ... | ... | ... | ... | ... | | **合计** | ... | ... | ... | **XX** | ### 输出二：完整用例列表 按场景类型分组，每组一个表格。 ### 输出三：如发现格式问题，自行修正后输出 ## 约束 - 格式必须整齐统一 - 统计数据要准确（数量和占比要对得上） """十个维度与 Agent 的映射关系你的测试领域知识 → 对应的 Agent ───────────────────────────────────────────────────── 需求理解六维度 → Agent 1 需求分析师 疑问清单提取 → Agent 2 需求评审员 用户确认① → 用户确认节点 测试计划框架(排期+准出) → Agent 3 测试计划师 用户确认② → 用户确认节点 测试点提炼十维度 → Agent 5 测试点提炼师 ⭐ 新增 测试用例设计标准 → Agent 6 用例设计师 优先级定义(P0/P1/P2) → 融入所有 Agent 用户确认③ → 用户确认节点 Word/Excel 导出 → Agent 8 + 导出模块五、LangGraph 对话式架构实现5.1 状态定义fromtypingimportTypedDict,Annotatedfromlanggraph.graphimportStateGraph,ENDimportoperatorclassPipelineState(TypedDict):"""对话式流水线全局状态"""# 输入requirement:str# Step 1-2: 需求分析 + 评审analysis:stranalysis_review:dictanalysis_retry_count:intquestions_for_user:list# 待用户确认的疑问列表# 用户确认①的回复user_confirmation_1:str# "确认" 或具体修改内容# Step 3-4: 测试计划 + 评审plan:strplan_review:dictplan_retry_count:int# 用户确认②的回复user_confirmation_2:str# Step 5: 测试点提炼（新增）test_points:str# Step 6-7: 用例设计 + 评审cases:strcase_review:dictcase_retry_count:int# 用户确认③的回复user_confirmation_3:str# Step 8: 最终输出final_output:strexport_plan_docx:str# Word 文件路径export_cases_xlsx:str# Excel 文件路径# 追踪logs:Annotated[list[str],operator.add]error:str5.2 节点函数与前版相同的节点（call_llm_with_retry、validate_state_field 等）参见前文 5.2 节，此处仅列出变更和新增的节点。# ============================================================# 常量定义# ============================================================MAX_ANALYSIS_RETRY=3MAX_PLAN_RETRY=3MAX_CASE_RETRY=3LLM_MAX_RETRIES=3LLM_TIMEOUT=120PIPELINE_TIMEOUT=600# 截断展示长度（用户确认节点）PREVIEW_MAX_CHARS=3000# ============================================================# 生产级 LLM 调用（与前版一致，完整保留）# ============================================================defcall_llm_with_retry(agent:TestAgent,input_text:str,max_retries:int=LLM_MAX_RETRIES)-str:"""带指数退避的 LLM 调用，覆盖所有常见异常。"""last_error=Noneforattemptinrange(1,max_retries+1):try:returnagent.run(input_text)exceptRateLimitErrorase:wait=2**attempt logger.warning(f"[{agent.name}] 限流，{wait}s 后重试 ({attempt}/{max_retries})")time.sleep(wait)last_error=eexceptAPITimeoutErrorase:wait=2**attempt logger.warning(f"[{agent.name}] 超时，{wait}s 后重试 ({attempt}/{max_retries})")time.sleep(wait)last_error=eexceptAPIConnectionErrorase:wait=2**attempt logger.warning(f"[{agent.name}] 网络连接失败，{wait}s 后重试")time.sleep(wait)last_error=eexceptBadRequestErrorase:error_msg=str(e)if"context length"inerror_msg.lower()or"maximum"inerror_msg.lower():ifattemptmax_retries:truncation_point=int(len(input_text)*0.7)input_text=input_text[:truncation_point]+"\n\n... [输入过长，已截断至70%] ..."continueelif"content_policy"inerror_msg.lower()or"moderation"inerror_msg.lower():raiseelse:raiselast_error=eexceptAuthenticationErrorase:raiseexceptExceptionase:last_error=eifattempt=max_retries:breaktime.sleep(2**attempt)raiseRuntimeError(f"[{agent.name}] 调用失败，已重试{max_retries}次。最后错误:{last_error}")defcall_llm_json_with_retry(agent:TestAgent,input_text:str,max_retries:int=LLM_MAX_RETRIES)-dict:"""带重试 + JSON 解析容错 + 字段校验的调用。"""last_raw=""forattemptinrange(max_retries):raw=call_llm_with_retry(agent,input_text,max_retries=2)last_raw=rawtry:if"```json"inraw:raw=raw.split("```json")[1].split("```")[0]elif"```"inraw:raw=raw.split("```")[1].split("```")[0]parsed=json.loads(raw.strip())required_fields=["score","pass_status"]missing=[fforfinrequired_fieldsiffnotinparsed]ifmissing:input_text+=f"\n\n【重要提醒】上次输出缺少字段{missing}，请确保包含 score、pass_status、feedback、suggestions。"continuereturnparsedexceptjson.JSONDecodeError:input_text+="\n\n【重要提醒】上次输出无法解析为 JSON，请务必只输出合法 JSON。"return{"score":0,"pass_status":False,"feedback":f"JSON 解析失败，原始输出前500字：{last_raw[:500]}","suggestions":["请检查 Prompt 是否要求了严格的 JSON 格式"]}defvalidate_state_field(state:dict,field:str,field_type=str,node_name:str="")-bool:"""校验状态字段：是否存在、类型是否正确、是否为空。"""value=state.get(field)ifvalueisNone:logger.error(f"[{node_name}] 状态字段 '{field}' 为 None")returnFalseifnotisinstance(value,field_type):logger.error(f"[{node_name}] 状态字段 '{field}' 类型错误")returnFalseiffield_type==strandlen(value.strip())==0:logger.error(f"[{node_name}] 状态字段 '{field}' 为空字符串")returnFalsereturnTrue# ============================================================# Step 1: 需求分析# ============================================================defnode_analyze(state:PipelineState)-dict:ifnotvalidate_state_field(state,"requirement",str,"Step1"):return{"analysis":"","error":"输入的需求文档为空","logs":["[Step1] ❌ 需求分析失败：输入为空"]}result=call_llm_with_retry(requirement_agent,state["requirement"])return{"analysis":result,"error":"","logs":["[Step1] 需求分析完成"]}# ============================================================# Step 2: 需求分析评审（含疑问提取）# ============================================================defnode_review_analysis(state:PipelineState)-dict:ifnotvalidate_state_field(state,"analysis",str,"Step2"):return{"analysis_review":{"score":0,"pass_status":False,"feedback":"分析报告为空"},"questions_for_user":[],"error":"分析报告为空","logs":["[Step2] ❌ 需求评审跳过：分析报告为空"]}review_input=(f"--