Skills
skills/skills.netease.im/test-case-generator

test-case-generator

SKILL.md

Test Case Generator Skill

核心原则

以资深系统测试工程师视角生成测试用例，不只覆盖正向流程，必须系统性地评估并覆盖各类测试场景。 参考文件：

  • references/testing_methodology.md：测试类型 Checklist、优先级策略、用例编写规范
  • references/test_case_schema.md：JSON Schema 及字段规则

工作流程

Step 1：信息收集

获取输入文档（按优先级）：

  1. 用户直接粘贴文档内容 → 直接解析
  2. 用户提供本地文件路径 → 读取文件内容
  3. 用户提供 MCP 文档链接 → 使用 getContentByUrl 工具获取内容

必须确认的信息：

  • 业务名称（用于文件命名）
  • 版本号（格式如 V1.0.0，用于文件命名和 Tag）
  • 输出目录（不提供则输出到当前工作目录）

确认顺序（强制）：

  1. 获取文档后，若用户未明确说明业务名称，必须主动询问："请问这个功能的业务名称是什么？（用于文件命名，如"闹钟"、"消息推送"）"
  2. 若用户未明确说明版本号，必须主动询问："请问当前版本号是多少？（格式如 V1.0.0）"
  3. 以上两项不可自行猜测或从文档中推断，必须由用户确认。
  4. 输出目录可选，不提供则默认当前工作目录。

Step 2：文档分析

读取 references/testing_methodology.md 了解测试方法论。

2.1 判断端侧类型（必须先做）

根据文档内容判断属于哪种端侧，并明确告知用户：

  • 服务端（Server）：文档涉及 REST API、微服务、数据库、消息队列、服务治理
  • 客户端SDK（Client SDK）：文档涉及 Android/iOS/Windows SDK、Native库、音视频、前后台
  • C端产品（Consumer App）：文档涉及 App 界面、用户交互流程、UI设计、用户体验
  • 混合类型：分模块分别按对应端侧视角设计，在 Suite 层级中加以区分

判断后，立即向用户输出端侧分析摘要，格式如下：

? 端侧类型识别：[服务端 / 客户端SDK / C端产品 / 混合]
? 将覆盖的测试维度：
  - [维度1]
  - [维度2]
  - ...
⚠️ 需要特别关注：[根据文档内容指出高风险点，如"涉及并发写入，需重点覆盖竞态场景"]

用户确认或无异议后，再继续 Step 2.2。

2.2 分析文档内容

  • 功能模块列表与层级关系（用于设计 Suite 结构）
  • API 接口定义（判断是否可 Automation）
  • 业务规则与约束（边界值、权限、状态机）
  • 数据流与依赖关系
  • 端侧专项关注点（如：服务端的依赖服务、SDK的音频路由、C端的UI交互）
  • 非功能需求（性能指标、稳定性要求）

Step 3：生成 JSON 测试用例

读取 references/test_case_schema.md 了解字段规则。

生成策略：

  1. 为每个功能模块规划 Suite 层级（最多5级）
  2. 按端侧类型选用对应的测试 Checklist（服务端/客户端SDK/C端产品），对每个功能点逐一评估覆盖维度
  3. 生成测试用例，确保标题遵循 [对象]_[操作]_[预期关键词] 格式
  4. 分配优先级（P0:P1:P2:P3 ≈ 5%:30%:45%:20%），参考对应端侧的优先级策略；P0 即代表冒烟用例，备注中不要额外标注"冒烟用例"
  5. 判断执行模式：
    • 整个流程可纯 API 调用完成 → Automation
    • 涉及UI/硬件/主观判断 → Manual
  6. 生成 tags：格式为 V{版本号},{Manual|Automation}，多个 Tag 之间用英文逗号 , 分隔，无空格，无业务名前缀
    • 示例：V1.2.4,Automation 或 V1.2.4,Manual,Stability

JSON 文件写入规范（重要）：

  • 必须将完整 JSON 写入文件，不得只输出到对话框
  • 使用 run_terminal_cmd 执行 Python 脚本或 cat 命令写入，确保文件完整性
  • 用例数量较多时（预计 >50 条），采用分批追加策略：
    1. 先创建包含元信息和空 test_cases: [] 的 JSON 骨架并写入文件
    2. 按 Suite 模块分批生成，每批完成后通过脚本追加到文件
    3. 全部完成后统一计算并更新 summary 字段
  • 写入后验证文件是否可正常读取（python3 -c "import json; json.load(open('文件路径'))")

JSON 文件路径：{输出目录}/{业务}-{版本号}.json

生成 JSON 后，先告知用户用例统计概要（总数、按Suite分布、按级别分布），再继续下一步。

Step 4：生成 Excel 文件

使用提供的 scripts/generate_excel.py 脚本（依赖 openpyxl，若未安装先执行安装命令）：

# 如未安装依赖，先执行：
pip3 install openpyxl

# 生成 Excel：
python3 ~/.codemaker/skills/test-case-generator/scripts/generate_excel.py <json_file> <excel_file>

Excel 文件路径：{输出目录}/{业务}-{版本号}.xlsx

Step 5：交付产物

告知用户：

  1. 生成的文件路径（JSON + Excel）
  2. 用例统计：总数、P0/P1/P2/P3 分布、Manual/Automation 分布
  3. 覆盖的测试维度
  4. 如有建议补充的测试场景，列出说明

用例质量标准

必须覆盖（每个功能模块）

  • 正向主流程（P0）
  • 关键反向场景（P1）
  • 边界值（P2）

按需覆盖（根据端侧类型和文档内容判断）

服务端专项：

  • 参数边界值与特殊字符过滤
  • 并发/竞态写入验证
  • 依赖服务异常降级/熔断
  • 网络劫持、请求重放攻击
  • 数据库主从切换、宕机恢复
  • 大数据量查询性能

客户端SDK专项：

  • 网络类型切换（WiFi/4G/5G/弱网）
  • 音频路由切换（涉及音频时）
  • 视频规格与弱网画质（涉及视频时）
  • 前后台切换、锁屏解锁
  • 主流机型兼容性
  • 功耗/内存/CPU

C端产品专项：

  • UI 元素与文案正确性
  • 用户操作反馈与加载状态
  • 页面流畅度（列表滚动/转场动画）
  • 机型适配与折叠屏
  • 系统打断（来电/通知）后恢复

通用：

  • 权限/鉴权（有权限体系时）
  • 异常恢复（有持久化/状态时）
  • 重启/断电恢复（有硬件/持久化时）
  • 稳定性（长期运行类功能）

数量参考

  • 小功能（1-3个接口）：20-50 条
  • 中等模块（4-10个功能点）：50-150 条
  • 完整系统：150-500+ 条

注意事项

  • 预期结果必须可量化，避免"正常显示"、"操作成功"等模糊描述
  • 执行步骤每步只做一件事，API 步骤包含完整请求信息
  • Suite 最多5级，命名用名词短语
  • Tag 多个时用英文逗号 , 分隔（无空格），如 V1.2.4,Automation,Stability
  • 前置条件字段默认为空；前置条件内容应整合到执行步骤的开头，以"【准备】"标注，例如"1.【准备】已创建账号并登录"
  • 备注中不要标注"冒烟用例"；备注仅用于记录设计限制、已知问题、待确认事项等
  • 若文档信息不足以生成某类测试用例，在备注中标注"待确认：{具体问题}"
Installs
5
Source
skills.netease.…4a38b032
First Seen
Apr 1, 2026