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

1. Read requirement document thoroughly (do not skip any section)
2. Apply all 5 analysis methods to extract test details
3. Organize results into:
• Functional module inventory
• Business rule inventory
• Exception scenario inventory
• Test data inventory
4. 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

Export Dimension

User Selection Guide

Ask user before generation:

1. "Which output format do you prefer? (Markdown only / Markdown + XMind mindmap)"
2. "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:

1. List all available versions with timestamps
2. Show differences in: test case count, coverage changes, priority adjustments
3. 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

1. Operation Granularity: Each case focuses on one group of similar functional items. Steps must be clear and the target explicit.
2. 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.
3. Clear Boundaries: Functional item boundaries are well-defined. Do not cross-item test. Avoid redundancy and duplicate operations.
4. 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)
  /------------\

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 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:
3. Display error: "Username must be between 6-20 characters"
4. 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

Case Type Definitions

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

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

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:

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:

1. Ask User Preferences:
• Output format: Markdown or Markdown + XMind?
• Export dimension: Review or Execution?

1. 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

1. Design Test Cases:
• Select appropriate design methods from Test Design Methodology section
• Follow Level 2 granularity by default
• Apply naming convention and field rules

1. 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)

1. Self-Review:
• Run through Writing Checklist
• Verify 8-dimension quality criteria
• Ensure requirement coverage ≥ 95%

Evaluation Workflow

When evaluating test cases:

1. Read the test case file and identify all authors
2. Analyze per author across the 8 dimensions using quantitative metrics
3. Score each dimension 0-10 with evidence
4. Calculate composite score
5. 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

• [ ] Naming follows [Module][Platform] Feature - Condition - Validation Point format
• [ ] Case ID follows primary_module_secondary_module_sequence_number format
• [ ] Precondition filled as needed (don't blindly write "None")
• [ ] Each step specifies button/field/menu names
• [ ] Each step has a corresponding expected result
• [ ] Expected results are specific and verifiable (no "correctly"/"normally")
• [ ] Priority distribution is reasonable (not all same level)
• [ ] Both positive and negative cases are covered
• [ ] Specific test data values are provided
• [ ] Cases are independent (running order does not affect results)
• [ ] Default Level 2 granularity (2-5 steps per case)
• [ ] Use consistent terminology (Create/Query/Edit/Delete/Submit)

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