测试规划 Skill
- 目标
识别测试项（ITEM）和测试点（POINT），生成结构化测试规划。
- 输入输出
-
输入：clarified-requirements/ 目录（主要读取 index.md ）
-
输出：test-case/plan.md
- 核心原则
-
场景优先：基于场景法识别测试点，而非等价类
-
独立性：每个 POINT 是独立的操作路径
-
完整性：覆盖所有业务模块和关键场景
-
风险导向：评估风险等级，指导用例生成
- 执行流程
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
- 示例
示例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 "用户名密码登录"，在用例生成时覆盖密码长度的等价类。
- 检查清单
-
所有业务模块都已识别为 ITEM
-
所有独立操作路径都已识别为 POINT
-
没有将等价类误识别为 POINT
-
每个 POINT 都有风险等级
-
每个 POINT 都有测试关注点
-
风险等级评估合理
-
测试关注点具体明确（有数值、有条件）
-
格式符合规范（## ITEM、### POINT、> 备注）