test-guide-from-code

手动测试指南生成

根据代码变更自动生成结构化的手动测试指南，帮助测试人员精准验证变更的功能。

输入格式、输出模板和示例：请参阅 reference.md。

触发条件

• 「生成测试指南」「测试指南」「人工测试指南」「测试指引」
• 「test guide」
• 「根据代码生成测试」「从代码生成测试指南」
• 「从 MR 生成测试指南」「从 PR 生成测试指南」
• 支持参数：「生成测试指南：https://gitlab.example.com/merge_requests/123」

适用场景

• 提交 MR/PR 后，为测试人员提供验证指南
• 发布前，根据代码变更梳理手动回归测试范围
• 功能交付验收时，根据代码变更推导可测试的用户行为

执行流程

步骤 1：获取变更

1. 检测输入类型（参见 reference.md 中的输入格式表），选择相应的获取方式
2. 如果是 URL：尝试使用 CLI 获取差异；如果失败，则提示用户粘贴
3. 如果没有输入：使用 git diff（工作区）或 git diff HEAD~1（最新提交）
4. 确认已获取有效的差异

步骤 2：分析变更

1. 变更文件清单：按功能模块分组
2. 变更类型分类：🆕 新增 / 🔄 修改 / 🐛 修复 / ⚙️ 配置 / 🗑️ 删除
3. 用户可感知的行为变更：推断对用户/系统行为的影响
4. 识别隐式变更：配置文件、依赖项升级、数据库迁移、API 契约变更

步骤 3：生成测试指南

每个测试项包括：测试目标、前置条件、测试步骤（对非开发人员友好）、预期结果、优先级。

优先级：P0 核心业务/数据写入/安全性 → P1 辅助功能/UI/性能 → P2 样式/文案/内部重构

变更类型 → 测试策略：

• 🆕 → 正常流程 + 边界/边缘情况
• 🔄 → 验证变更点 + 回归现有功能
• 🐛 → 验证缺陷场景 + 回归相关功能
• ⚙️ → 验证配置是否生效 + 回归受影响的功能
• 🗑️ → 确认已移除 + 验证相关功能未受影响

步骤 4：补充回归验证

根据变更模块推导相关模块，列出需要回归的功能点及验证方法。

步骤 5：输出

使用 reference.md 中的模板格式生成测试指南，默认保存为 Markdown 文件到当前工作目录。

文件命名：<feature>_manual_test_guide_<YYYY-MM-DD>.md（命名规则和示例：请参阅 reference.md“文件命名规则”）

用户指定路径：用户可在触发时指定自定义路径或文件名；按指定内容保存。

对话输出：不要重复完整内容——仅输出简要摘要：保存路径、测试项统计（按 P0/P1/P2 分布）、3–5 个核心变更点、回归范围。完整测试项始终只写入文件（策略：请参阅 reference.md“对话输出策略”）。

注意事项

• ❌ 跳过隐式变更识别，只分析业务代码
• ❌ 测试步骤使用开发人员术语（例如“调用 API”“返回 200”）
• ❌ 修复缺陷时遗漏原始缺陷场景
• ❌ 将自动化测试混入手动测试指南
• ❌ 忽略回归验证范围
• ❌ 未获取差异时凭空生成测试项
• ❌ 未确认当前工作目录便写入文件，导致文件保存到错误位置
• ❌ 文件名包含空格或特殊文件系统字符（/ \ : * ? " < > |）
• ❌ 生成文件后未在对话中报告完整保存路径