testcase-planner

Test Planning Skill

1. Objective

Identify test items (ITEM) and test points (POINT), and generate structured test planning.

2. Input and Output

Input:clarified-requirements/ Directory (mainly reads index.md）
Output:test-case/plan.md

3. Core Principles

Scenario first: Identify test points based on the scenario method, not equivalence classes
Independence: Each POINT is an independent operation path
Completeness: Cover all business modules and key scenarios
Risk-oriented: Evaluate risk levels to guide test case generation

4. Execution Process

4.1 Hierarchy Definition

Three-layer structure:

ITEM (Test Item)：

Business module or requirement section
Examples: Login feature, Order management, User settings

POINT (Test Point)：

Independent operation path (scenario)
Examples: Username-password login, Mobile verification code login, Third-party login

Notes：

Risk level: Critical / High / Medium / Low
Test focus: Boundary values, exceptional situations, business rules, etc.

4.2 ITEM Identification

Divide in the following ways:

Method 1: By requirement section

Used when the requirements document has a clear section structure
Example: Chapter 3 "User Management" → ITEM "User Management"

Method 2: By business entity

Used when the requirements document has no clear sections
Example: All features involving orders → ITEM "Order Management"

Method 3: By functional module

A collection of features across sections
Example: All login-related features → ITEM "Login Feature"

4.3 POINT Identification

Identify independent operation paths based on the scenario method:

Criteria：

Is it an independent user operation flow?
Does it have different preconditions or trigger conditions?
Does it have different business rules?

Correct Example：

"Username-password login", "Mobile verification code login", "Third-party login" → 3 POINTs (different operation paths)

Incorrect Example：

"Password length <8", "Password length 8-20", "Password length >20" → Not 3 POINTs (different data for the same scenario)
Correct approach: Merge into 1 POINT "Username-password login", and cover the equivalence classes of password length when generating test cases

4.4 Risk Level Assessment

4 levels:

Critical: Core business process, affects system availability
High: Important feature, affects user experience
Medium: Auxiliary feature, affects local functionality
Low: Edge feature, minor impact

4.5 Test Focus Extraction

Extract from the following dimensions:

Boundary values: Limits on length, quantity, time, etc.
Exceptional situations: Failures, timeouts, conflicts, etc.
Business rules: Permissions, states, constraints, etc.
Data constraints: Format, range, dependencies, etc.

4.6 Output Format

# 测试规划

## ITEM 名称

### POINT 名称
> 风险等级: Critical/High/Medium/Low
> 测试关注点: 具体关注点1、具体关注点2

### POINT 名称
> 风险等级: Critical/High/Medium/Low
> 测试关注点: 具体关注点1、具体关注点2

5. Examples

Example 1: Correct ITEM/POINT division

# 测试规划

## 登录功能

### 用户名密码登录
> 风险等级: Critical
> 测试关注点: 密码错误次数限制（5次）、账户锁定（30分钟）、密码长度边界（8-20位）

### 手机验证码登录
> 风险等级: High
> 测试关注点: 验证码过期（60s）、错误次数限制（5次）、手机号格式验证

### 第三方登录（微信/支付宝）
> 风险等级: Medium
> 测试关注点: 授权失败处理、token过期处理、首次登录绑定流程

Example 2: Incorrect POINT division

## 登录功能

### 密码长度小于8位
> 风险等级: High
> 测试关注点: 提示"密码长度不足"

### 密码长度8-20位
> 风险等级: High
> 测试关注点: 登录成功

### 密码长度大于20位
> 风险等级: High
> 测试关注点: 提示"密码长度超限"

Why it is incorrect: These 3 are not independent scenarios, but different data for the same scenario (username-password login). They should be merged into 1 POINT "Username-Password Login", and the equivalence classes of password length should be covered during test case generation.

6. Checklist

All business modules have been identified as ITEMs
All independent operation paths have been identified as POINTs
No equivalence classes have been mistakenly identified as POINTs
Every POINT has a risk level
Every POINT has test focus points
Risk level assessments are reasonable
Test focus points are specific and clear (with values and conditions)
The format complies with the specification (## ITEM, ### POINT, > Note)