testcase-planner

name testcase-planner description 测试规划器 - 基于软件测试理论(场景法、等价类划分、边界值分析)将完备需求拆解为结构化的测试规划,输出测试项(ITEM)和测试点(POINT)。当用户执行 /testcase-plan 命令或需要生成测试规划时使用。 allowed-tools Read, Write, Bash 测试规划 Skill 1. 目标 识别测试项（ITEM）和测试点（POINT），生成结构化测试规划。 2. 输入输出 输入： clarified-requirements/ 目录（主要读取 index.md ） 输出： test-case/plan.md 3. 核心原则 场景优先：基于场景法识别测试点，而非等价类 独立性：每个 POINT 是独立的操作路径 完整性：覆盖所有业务模块和关键场景 风险导向：评估风险等级，指导用例生成 4. 执行流程 4.1 层级定义 三层结构： ITEM（测试项） ： 业务模块或需求章节 示例：登录功能、订单管理、用户设置 POINT（测试点） ： 独立的操作路径（场景） 示例：用户名密码登录、手机验证码登录、第三方登录 备注 ： 风险等级：Critical / High / Medium / Low 测试关注点：边界值、异常情况、业务规则等 4.2 ITEM 识别 按以下方式划分： 方式1：按需求章节 需求文档有明确章节结构时使用 示例：第3章"用户管理" → ITEM "用户管理" 方式2：按业务实体 需求文档无明确章节时使用 示例：涉及订单的所有功能 → ITEM "订单管理" 方式3：按功能模块 跨章节的功能集合 示例：所有登录相关功能 → ITEM "登录功能" 4.3 POINT 识别 基于场景法识别独立操作路径： 判断标准 ： 是否是独立的用户操作流程？ 是否有不同的前置条件或触发条件？ 是否有不同的业务规则？ 正确示例 ： "用户名密码登录"、"手机验证码登录"、"第三方登录" → 3 个 POINT（不同操作路径） 错误示例 ： "密码长度 <8"、"密码长度 8-20"、"密码长度 >20" → 不是 3 个 POINT（同一场景的不同数据） 正确做法：合并为 1 个 POINT "用户名密码登录"，在用例生成时覆盖密码长度的等价类 4.4 风险等级评估 4 个等级： Critical ：核心业务流程，影响系统可用性 High ：重要功能，影响用户体验 Medium ：辅助功能，影响局部功能 Low ：边缘功能，影响较小 4.5 测试关注点提炼 从以下维度提炼： 边界值：长度、数量、时间等限制 异常情况：失败、超时、冲突等 业务规则：权限、状态、约束等 数据约束：格式、范围、依赖等 4.6 输出格式 # 测试规划 ## ITEM 名称 ### POINT 名称 > 风险等级: Critical/High/Medium/Low > 测试关注点: 具体关注点1、具体关注点2 ### POINT 名称 > 风险等级: Critical/High/Medium/Low > 测试关注点: 具体关注点1、具体关注点2 5. 示例 示例1：正确的 ITEM/POINT 划分 # 测试规划 ## 登录功能 ### 用户名密码登录 > 风险等级: Critical > 测试关注点: 密码错误次数限制（5次）、账户锁定（30分钟）、密码长度边界（8-20位） ### 手机验证码登录 > 风险等级: High > 测试关注点: 验证码过期（60s）、错误次数限制（5次）、手机号格式验证 ### 第三方登录（微信/支付宝） > 风险等级: Medium > 测试关注点: 授权失败处理、token过期处理、首次登录绑定流程 示例2：错误的 POINT 划分 ## 登录功能 ### 密码长度小于8位 > 风险等级: High > 测试关注点: 提示"密码长度不足" ### 密码长度8-20位 > 风险等级: High > 测试关注点: 登录成功 ### 密码长度大于20位 > 风险等级: High > 测试关注点: 提示"密码长度超限" 为什么错误 ：这3个不是独立场景，而是同一场景（用户名密码登录）的不同数据。应该合并为1个 POINT "用户名密码登录"，在用例生成时覆盖密码长度的等价类。 6. 检查清单 所有业务模块都已识别为 ITEM 所有独立操作路径都已识别为 POINT 没有将等价类误识别为 POINT 每个 POINT 都有风险等级 每个 POINT 都有测试关注点 风险等级评估合理 测试关注点具体明确（有数值、有条件） 格式符合规范（## ITEM、### POINT、> 备注）