functional-test-case-standard

Dev Tools

Generate and evaluate functional test cases following standardized quality dimensions. Use when creating test cases, reviewing test case documents, analyzing test case quality, scoring test cases, or when the user mentions test case templates, test case evaluation, test case standards, or test case quality assessment. Supports Markdown and XMind mindmap output formats with version management.

Install

openclaw skills install functional-test-case-standard

Functional Test Case Standard

Overview

This skill provides standardized guidelines for writing high-quality functional test cases and an 8-dimension evaluation framework for assessing test case quality.

Core Features:

✅ Standardized test case design with 15+ design methods
✅ 8-dimension quality evaluation framework with scoring
✅ Deep requirement analysis using 5 analysis methods
✅ Dual output formats: Markdown (default) and XMind mindmap
✅ Two export modes: Review dimension and Execution dimension
✅ Timestamp-based version management for traceability

Requirement Analysis Methodology

Before designing test cases, perform deep requirement analysis using these 5 methods to extract all test details:

1. Sentence-by-Sentence Analysis Method

Analyze each sentence in the requirement document to identify:

Condition words: if, when, unless, only if, etc.
Action words: click, input, select, submit, delete, etc.
State words: display, hide, enable, disable, active, inactive, etc.
Data words: create, read, update, delete, calculate, validate, etc.

Output: Each identified element becomes a verification item.

Example:

Requirement: "When user clicks Submit button, if all required fields are filled, display success message and redirect to order list."
Extracted verifications:
- Condition: all required fields filled → test with valid/invalid combinations
- Action: click Submit button → verify button is clickable and responsive
- State: display success message → verify exact message text
- Data: redirect to order list → verify correct page navigation

2. Business Process Analysis Method

Identify the complete business flow from start to end:

Process nodes: Each step in the workflow
Decision branches: All if-else or switch conditions
Exception exits: Error handling, timeout, cancel, rollback
Parallel flows: Concurrent processes or independent branches

Output: Each node and branch becomes a test scenario.

Example (Order Flow):

Node 1: Create order → test with valid/invalid products
Node 2: Payment → test successful payment, payment failure, timeout
Node 3: Ship → test shipping with/without inventory
Branch: Payment failure → test retry, cancel, refund flows

3. Data Flow Analysis Method

Trace data through its complete lifecycle:

Data acquisition: Where does data come from? (user input, API, database, third-party)
Data processing: How is data transformed? (calculation, validation, formatting)
Data storage: Where is data saved? (database, cache, file, session)
Data display: How is data presented? (UI, report, export, notification)

Output: Each data transformation point becomes a verification item.

Example (User Registration):

Acquisition: user enters username, email, password
Processing: validate format, encrypt password, check uniqueness
Storage: insert into users table, send to CRM system
Display: show success message, send confirmation email

4. State Transition Analysis Method

Model the system as a finite state machine:

Identify all states: Draft, Pending, Approved, Rejected, Completed, Cancelled, etc.
Identify transition conditions: What triggers state changes?
Identify valid transitions: Allowed state changes
Identify invalid transitions: Disallowed state changes (should show error)
Identify self-transitions: Staying in the same state after action

Output: Each valid and invalid transition becomes a test case.

Example (Order Status):

Valid: Draft → Pending (submit), Pending → Approved (approve), Approved → Shipped (ship)
Invalid: Draft → Shipped (skip states), Shipped → Pending (reverse), Rejected → Approved (without revision)

5. User Scenario Analysis Method

Analyze from different user perspectives:

Different roles: Admin, Manager, Regular User, Guest, etc.
Normal scenarios: Happy path, typical usage
Exception scenarios: Error handling, edge cases, abnormal conditions
Extreme scenarios: High concurrency, large data volume, network failure, system timeout

Output: Each role-scenario combination becomes a test case.

Example (File Upload):

Admin + Normal: upload valid file within size limit
User + Exception: upload oversized file, wrong format
Guest + Extreme: upload during network timeout, concurrent uploads

Requirement Analysis Workflow

Read requirement document thoroughly (do not skip any section)
Apply all 5 analysis methods to extract test details
Organize results into:
- Functional module inventory
- Business rule inventory
- Exception scenario inventory
- Test data inventory
Map to test cases using design methods from Test Design Methodology section

Output Format Selection

This skill supports two output formats with user-selectable options:

Format Mode

Format	Trigger	Description
Markdown (default)	User does not specify format	Generate standard Markdown test case document
XMind Mindmap	User explicitly requests "mindmap format", "XMind format", or "both md and xmind"	Additionally generate XMind mindmap file for visual review

Export Dimension

Dimension	Use Case	Structure	When to Use
Review Dimension (default)	Quality evaluation, peer review, requirement coverage analysis	Organized by: Module → Feature → Test Point → Verification Items (focus on completeness and coverage)	When stakeholders need to review test case coverage, during requirement review meetings, for quality audits
Execution Dimension	Test execution, automation, step-by-step testing	Organized by: Module → Test Case → Steps → Expected Results (focus on executability and traceability)	When testers execute test cases, for automation script generation, during test execution phase

User Selection Guide

Ask user before generation:

"Which output format do you prefer? (Markdown only / Markdown + XMind mindmap)"
"Which export dimension? (Review dimension for coverage analysis / Execution dimension for test execution)"

Default behavior: If user does not specify, generate Markdown format with Review dimension.

XMind Mindmap Structure

Review Dimension Structure:

Product Requirement Name
├── I. Module Name
│   ├── 1.1 Sub-feature Name
│   │   ├── 1.1.1 Function Point
│   │   │   ├── Test Point: Condition Verification
│   │   │   │   ├── [ ] Verification Item 1
│   │   │   │   ├── [ ] Verification Item 2
│   │   │   │   └── [ ] Verification Item 3
│   │   │   └── Test Point: Business Rule Verification
│   │   │       ├── [ ] Verification Item 1
│   │   │       └── [ ] Verification Item 2

Execution Dimension Structure:

Product Requirement Name
├── I. Module Name
│   ├── 1.1 Sub-feature Name
│   │   ├── TC-001: [Module][Platform] Feature - Condition - Validation
│   │   │   ├── Precondition: ...
│   │   │   ├── Steps
│   │   │   │   ├── 1. ...
│   │   │   │   ├── 2. ...
│   │   │   │   └── 3. ...
│   │   │   ├── Expected Result
│   │   │   │   ├── 1. ...
│   │   │   │   ├── 2. ...
│   │   │   │   └── 3. ...
│   │   │   └── Priority: P0/P1/P2

Version Management

Timestamp-Based Versioning

Every test case generation creates a versioned file to enable traceability and historical comparison.

File Naming Convention:

{requirement-name}-v{MMdd_HHmmss}.md
{requirement-name}-v{MMdd_HHmmss}.xmind

Timestamp Format:

Format: MMdd_HHmmss (MonthDay_HourMinuteSecond)
Example: 0318_143052 means March 18, 14:30:52

Example:

Requirement: "User Registration Enhancement"
Generated files:
- user-registration-enhancement-v0318_143052.md
- user-registration-enhancement-v0318_143052.xmind (if XMind requested)

Version Management Benefits:

✅ All historical versions are preserved
✅ Easy comparison between different generations
✅ Trace test case evolution over time
✅ Support rollback to previous versions if needed

Version Comparison: When user requests comparison between versions:

List all available versions with timestamps
Show differences in: test case count, coverage changes, priority adjustments
Highlight added/modified/removed test cases

Design Principles

Functional Item as Unit

Design test cases by functional item. Group related functional points by business or operation type into "functional items" — each item contains one or more similar functional points. For a given functional item, input a specific set of data or operation sequence, and verify the unique output result for each functional point within that item.

Core Principles

Operation Granularity: Each case focuses on one group of similar functional items. Steps must be clear and the target explicit.
Input-Output One-to-One Mapping: Define a unique input set for the functional item, and strictly verify the corresponding output result. Ensure both test coverage and result judgment are unambiguous.
Clear Boundaries: Functional item boundaries are well-defined. Do not cross-item test. Avoid redundancy and duplicate operations.
Case Independence: Design each case to be self-contained with no inter-case dependencies. Clear boundaries between functional items minimize redundancy and maximize maintainability.

Layered Testing Strategy (Test Pyramid)

Understand test layering to avoid over-reliance on a single test type. The pyramid guides resource allocation and test design focus for functional testing.

        /\
       /  \     E2E Tests (fewer, slower, high maintenance)
      /----\    ————————————————————————————————————————
     /      \   API / Integration Tests (moderate count, faster)
    /--------\  ————————————————————————————————————————
   /          \ Unit / Component Tests (most, fastest, cheapest)
  /------------\

Layer	Scope	Speed	Maintenance	When to Design Cases Here
Unit	Single function/class	<100ms	Low	Complex business logic, calculation rules, state machines
Integration	Module interactions	<1s	Medium	Database operations, message queues, third-party service calls
API	Interface contracts	<1s	Medium	Parameter validation, response structure, error codes, auth
E2E	Full user workflow	Seconds~minutes	High	Cross-module business flows, user-facing critical paths

Guidelines:

Push tests as low in the pyramid as possible.
E2E cases should cover only cross-module critical paths and user journeys.
API cases should validate all parameter combinations and error responses.
Unit tests should cover all branches and boundary conditions of business logic.

Test Case Granularity

Default adoption: Level 2 granularity.

Level	Definition	Characteristics	When to Use
Level 1	Validates a single, independent, indivisible functional point. The smallest functional verification unit with clear input and expected output.	Finest granularity; each case tests one boundary or rule.	When boundary values and independent rules need precise isolation.
Level 2 (Default)	Groups and merges multiple Level-1 points of the same type or related functional points into a small category.	Integrates similar points for systematic organization; easier management and maintenance.	Default choice for functional test cases. Balances coverage and maintainability.
Level 3	Further integrates Level-2 cases of the same type or business relation into a large category.	Broader business scenario focus; higher-level test perspective; lower maintenance cost.	When a high-level overview of module coverage is needed.

Level 2 Granularity Example

Requirement: Username restriction: length 6-20, lowercase English letters and digits only.

Level 2 case:

Name: [User Management][WEB] User Registration - Username Length Validation
Steps:
1. Enter username with length below 6 characters
2. Enter username with length above 20 characters
Expected Results:
1. Display error: "Username must be between 6-20 characters"
2. Display error: "Username must be between 6-20 characters"

For detailed granularity examples, see reference.md.

Naming Convention

Unified format: [Module][Platform] Feature - Condition - Validation Point

Module: The business module name (e.g., User Management, Order Processing)
Platform: WEB / APP / H5 / API
Feature: The functional item under test
Condition: The specific input condition or rule
Validation Point: The verification point or operation being tested

Naming principles:

Use the functional item's input condition as the naming description. Keep it concise.
Specific inputs should be included; expected results are optional to avoid overly long names.
Avoid vague words like "verify" or "test".

Examples:

[Feedback][APP] Feedback Creation - Content - Length Validation
[Promotion][WEB] Red Packet Campaign - Manual Stop - Impact Validation
[OOH Management][WEB] OOH File Import - Template - Sales Region3 Required Field

Case ID

Format: primary_module_secondary_module_sequence_number

Example: user_reg_001, order_create_014, product_import_005
Must be unique within the project
Should reflect module hierarchy for easy location

Required Fields

Field	Required	Description
Case Name	Yes	Follow naming convention; concise input-condition-based description
Case ID	Yes	`primary_module_secondary_module_sequence_number`
Precondition	No	Prerequisites, specific inputs, and materials needed for the test
Test Steps	Yes	Clear, executable operation steps with specific UI elements
Expected Result	Yes	Unique, clear output result for the functional item, including state changes
Case Type	Yes	Functional / Smoke / Main-Flow / Single-API / API-Flow
Priority	Yes	P0(blocking/high) / P1(core/medium) / P2(normal/low)
Project	Yes	The project this case belongs to
Version	Yes	The version this case belongs to
Module	Yes	The module this case belongs to
Postcondition	No	Impact scope; fill when requirements change

Case Type Definitions

Type	Description
Functional Test Case	Precisely designed for specific functional points with clear input and output. Example: verify username length limits, covering max, min, and empty boundary cases.
Smoke Test Case	Selected P0 cases from the test suite. Quickly validates whether critical main functions are available to determine if deeper testing can proceed.
Main-Flow Business Case	Designed according to business processes, covering the full lifecycle from start to end. Example: User A creates an order -> B processes it -> C approves -> D completes payment.
Single-API Case	Validates interface input parameters: required fields, empty values, wrong types, length overflow, etc.
API Business Flow Case	Uses interface operations to flow through the entire business process from start to end, validating business process integrity.

Test Design Methodology

Design methods are categorized into 5 groups. Select methods based on the functional item's characteristics.

1. Input Domain Methods

Equivalence Class Partitioning: Divide input domain into valid and invalid equivalence classes. Test one representative from each class.
Boundary Value Analysis: Test values at boundaries (min, max, min-1, max+1, typical values, empty/null).

Best for: Form fields, numeric ranges, length limits, date ranges, enum values.

2. Combination Methods

Decision Table: Use when multiple conditions interact to produce different actions. List all condition combinations.
Cause-Effect Graphing: Map causes to effects with constraint relationships (AND, OR, NOT, M, O, R, I).
Orthogonal Testing: Use orthogonal arrays to reduce N-dimensional combination explosion to representative subsets.
Pairwise Testing: Test all possible pairs of parameter values (Pairwise / n-wise).

Best for: Multi-field forms, configuration combinations, filter combinations, permission matrices.

3. Flow & State Methods

Scenario-Based Testing: Design test scenarios based on business processes (normal flow, alternative flows, exception flows).
State Transition Testing: Model system as a finite state machine. Test all valid transitions, invalid transitions, and self-transitions.
Business Process Diagram Method: Derive test paths from business process diagrams (BPMN).

Best for: Approval workflows, order lifecycles, stateful entities, multi-step operations.

4. Experience-Based Methods

Error Guessing: Based on past defect data and experience, predict likely failure points and design targeted test cases.

Best for: Complex legacy systems, areas with high historical defect density, regression testing of fixed defects.

5. Modern Methods

Risk-Based Testing: Assign risk score = Impact × Probability. Prioritize test effort by risk. Use FMEA for systematic analysis.
Data-Driven Testing: Separate test logic from test data. Store data in CSV/Excel/DB. Same case runs with multiple data sets.
Keyword-Driven Testing: Abstract operations as reusable keywords (e.g., "Login", "Search", "Verify").
Model-Based Testing: Generate tests from state machines, decision trees, or AI models.
Fuzzing: Design test cases using random, malformed, or unexpected inputs as test data to cover edge cases.
Property-Based Testing: Design invariant properties (e.g., "sorting output must be ordered") and generate test data to verify them.

Best for: Regression test case design, complex stateful system test design.

Method Selection Guide

Functional Item Characteristic	Recommended Methods
Input forms with multiple fields	Equivalence class + Boundary value + Decision table
Business workflows with approvals	Scenario + State transition + Error guessing
Configuration / permission matrix	Pairwise + Decision table
API parameter validation	Boundary value + Equivalence class + Error guessing
Complex calculation logic	Equivalence class + Boundary value + Property testing
Unknown / new features	Risk-based testing + Error guessing

Field Rules

Precondition

Not required if none. Only fill when prerequisites are necessary.
Must include: account role, permissions, system data state, or specific test data.
If the case cannot execute without certain conditions, they must be documented.

Test Steps

Number sequentially: 1. 2. 3.
Be specific to button names, menu paths, field names.
Input data must specify exact values.
For Level 2 granularity: each step tests one boundary/condition within the same functional item.
Keep 2-5 steps per case; split if exceeding 7 steps.

Expected Result

Must be specific, observable, and verifiable.
Each step has a corresponding expected result.
Include state changes during the operation.
Avoid vague phrases like "display correctly" or "function normally".
For errors: include exact error message text.
Must be independently judgeable as pass/fail.

Priority Assignment

P0 / High: Core business paths, blocking issues, main workflows
P1 / Medium: Important features, frequently used functions
P2 / Low: General features, secondary functions, edge scenarios
Never assign all cases to a single priority level

Test Data Strategy

Data-Driven Testing

Separate test logic from test data. Store data in external files (CSV, Excel, JSON, DB). The same test case executes with multiple data sets.

When to use: Login with multiple account types, form submission with various valid/invalid inputs, bulk import with different file formats.

Template:

| Data Set | Input | Expected Result |
|----------|-------|-----------------|
| Valid-1  | "user01" | Success |
| Valid-2  | "user123456" | Success |
| Invalid-1| "" | Error: username required |
| Invalid-2| "ab" | Error: min length 6 |

Parameterization Design

For cases that differ only in input values, design one case with parameters:

Use placeholders like {username}, {password}, {amount}
Record parameter constraints in the "Test Data" field
Specify value ranges and boundary values

Mock / Stub Strategy

When dependencies are unavailable or unstable during test design:

Document which external systems are mocked
Specify mock response data for positive and negative scenarios

Case Lifecycle

Create -> Review -> Maintain -> Archive

Stage	Key Activities	Decision Criteria
Create	Write case following standard; self-review before submission	Completeness of fields, design rationale clear
Review	Peer review or group review; focus on coverage gaps and design clarity	Coverage ≥ 90% of requirements; no empty fields; steps clear and specific
Maintain	Update case when requirements change; add cases for new defects	Review within 1 sprint of requirement change
Archive	Archive obsolete cases; do not delete (for audit trace)	Case no longer applicable for 2+ versions

Maintenance Triggers

Requirement changes (functional or UI)
Defect found in production not covered by existing cases
Test data or environment changes
Process optimization (merge/split cases)

Common Word Constraints

Use consistent terminology across the team:

Preferred	Alternatives to Avoid
Create	Add, New, Insert
Query	Filter, Search
Edit	Modify, Update
Delete	Remove, Clear
Submit	Save, Confirm
Import	Upload (file scenarios only)
Export	Download (file scenarios only)

8-Dimension Quality Evaluation Framework

Evaluate each test case author across these 8 dimensions (0-10 scale):

1. Naming Convention

9-10: >90% follow [Module][Platform] Feature - Condition - Validation Point format
7-8: 60-90% follow format, some inconsistency
5-6: 30-60% follow format, mixed styles
3-4: <30% follow format, mostly free-form
0-2: No format consistency, names unclear

2. Structural Integrity

9-10: All cases have steps + expected result with substance; preconditions filled when needed
7-8: >80% complete, minor omissions
5-6: 50-80% complete, noticeable gaps
3-4: <50% complete, many empty fields
0-2: Mostly template shells without content

3. Step Executability

9-10: Steps specific to buttons/fields/menus, directly executable by anyone
7-8: Mostly specific, some vague descriptions
5-6: Mix of specific and vague steps
3-4: Mostly vague, hard to execute consistently
0-2: Steps are empty or meaningless

4. Expected Result Verifiability

9-10: Each step has specific, quantifiable, observable expected result
7-8: Most have substance, some are vague
5-6: About half are specific, half vague or empty
3-4: Mostly vague like "display correctly"
0-2: Expected results empty or missing

5. Test Design Method Diversity

9-10: Uses 4+ methods from the 5 categories above
7-8: Uses 3 methods with good coverage
5-6: Uses 2 methods
3-4: Uses 1 method primarily
0-2: No discernible design method

6. Positive/Negative Coverage

9-10: Balanced ratio (1:1 to 3:1), good exception coverage
7-8: Ratio 3:1 to 5:1, some exception coverage
5-6: Ratio 5:1 to 10:1, limited exceptions
3-4: Mostly positive cases, rare negatives
0-2: Almost exclusively positive cases

7. Priority Rationality

9-10: Well-distributed across P0/P1/P2 or High/Medium/Low
7-8: Mostly reasonable, minor imbalances
5-6: Noticeable imbalance (e.g., 70%+ in one level)
3-4: Severe imbalance (e.g., 90%+ in one level)
0-2: All cases same priority, no differentiation

8. Test Data Specificity

9-10: >50% cases include specific input values
7-8: 30-50% include specific values
5-6: 10-30% include specific values
3-4: <10% include specific values
0-2: No specific test data, all vague descriptions

Scoring Formula

Composite Score = round(average of 8 dimensions, 1)

Grade Mapping:

8.0-10.0: Excellent (Benchmark)
6.0-7.9: Good
4.0-5.9: Needs Improvement
0-3.9: Poor

Generation Workflow

When generating test cases from requirements:

Ask User Preferences:
- Output format: Markdown or Markdown + XMind?
- Export dimension: Review or Execution?
Perform Requirement Analysis:
- Apply all 5 analysis methods (Sentence-by-Sentence, Business Process, Data Flow, State Transition, User Scenario)
- Extract: functional modules, business rules, exception scenarios, test data
Design Test Cases:
- Select appropriate design methods from Test Design Methodology section
- Follow Level 2 granularity by default
- Apply naming convention and field rules
Generate Output Files:
- Create timestamp-based filename: {name}-v{MMdd_HHmmss}.md
- If XMind requested: also generate {name}-v{MMdd_HHmmss}.xmind
- Structure according to selected dimension (Review or Execution)
Self-Review:
- Run through Writing Checklist
- Verify 8-dimension quality criteria
- Ensure requirement coverage ≥ 95%

Evaluation Workflow

When evaluating test cases:

Read the test case file and identify all authors
Analyze per author across the 8 dimensions using quantitative metrics
Score each dimension 0-10 with evidence
Calculate composite score
Write evaluation report with:
- Score table per author
- Strengths per author
- Improvement suggestions per author
- Team-wide common issues
- Actionable recommendations

Case Template

| Field | Value |
|-------|-------|
| Case ID | order_create_014 |
| Case Name | [Order Management][WEB] Order Creation - Product Quantity - Boundary Validation |
| Project | E-Commerce Platform |
| Version | V2.3.0 |
| Module | Order Processing |
| Case Type | Functional Test Case |
| Priority | P1 |
| Precondition | 1. User logged in with valid credentials<br>2. Products available in inventory |
| Test Steps | 1. Navigate to Order Management > Create Order<br>2. Select product and enter quantity as 0<br>3. Click Submit button<br>4. Enter quantity as 999<br>5. Click Submit button |
| Expected Result | 1. Order creation page loads successfully<br>2. Display error: "Quantity must be at least 1"<br>3. Display error: "Maximum order quantity is 100" |
| Postcondition | None |

Writing Checklist

Before submitting test cases, verify:

Pre-Generation Questions

Confirm output format with user: Markdown only or Markdown + XMind?
Confirm export dimension: Review dimension or Execution dimension?
Apply all 5 requirement analysis methods before designing cases

Basic Completeness

Design Quality

At least one design method is consciously applied (equivalence, boundary, scenario, etc.)
Input-output mapping is one-to-one (no ambiguous expected results)
Boundary values are covered for numeric/length/date fields
Empty/null/whitespace inputs are tested for text fields
Cross-field validation is covered (e.g., start date > end date)
Error messages include exact text, not just "error prompt"
State changes are documented (before/after states)
Data persistence is verified (create -> query -> update -> delete cycle)

Layering & Types

Test pyramid is considered during design (not all cases are E2E-level design)
API cases cover all parameter combinations and error codes
UI cases cover only cross-module critical paths
Smoke cases are marked as P0 and cover main workflows

Maintainability

Case is traceable to a requirement ID
Postcondition records impact scope when applicable
Test data can be reproduced (not dependent on random production data)
Case does not contain hard-coded values that change per environment

Review Checklist (For Peer Review)

Reviewers use this checklist to verify case quality:

Review Item                              Pass  Fail  Notes
─────────────────────────────────────────────────────────
Naming follows standard format            □    □
ID is unique and reflects module hierarchy □    □
Preconditions adequately described        □    □
Steps executable (specific to UI elements) □    □
Expected results verifiable (specific)     □    □
Priority reasonably assigned               □    □
Granularity appropriate (Level 2 default)  □    □
Positive/negative coverage balanced        □    □
Test data specific                         □    □
Design method identifiable                 □    □
Traceable to requirements                  □    □
─────────────────────────────────────────────────────────
Review Conclusion: Pass / Needs Revision / Fail
Reviewer: __________  Date: __________

Additional Resources

For detailed scoring rubrics per dimension, see reference.md
For example evaluations of real test cases, see examples.md
For XMind format specifications and version management guidelines, see reference.md sections: XMind Format Specification, Version Management
For requirement analysis examples, see reference.md section: Deep Requirement Analysis Examples