AgentSkillsCN

generate-qa-test-cases

根据项目代码分析生成繁体中文的QA测试用例。

SKILL.md
--- frontmatter
name: generate-qa-test-cases
description: Generate QA test cases in Traditional Chinese from project code analysis.

Generate QA Test Cases

Analyze project code and generate comprehensive test cases for QA testing.

Important: Reports should be written in Traditional Chinese.

Arguments

  • •$ARGUMENTS - Target path to analyze (e.g., libs/mxsecurity/account-page)

Analysis Process

Step 1: Locate and Read Files

Read all relevant files from the target path:

  • •**/*.ts - TypeScript files (components, services, models)
  • •**/*.html - Template files
  • •**/*.model.ts - Data models
  • •**/*.def.ts - Constants and definitions
  • •**/*.api.ts - API service files

Step 2: Extract Form Fields and Validation Rules

From TypeScript files, extract:

  1. •

    Form Group Definitions

    • •this.fb.group({...}) or new FormGroup({...})
    • •this.fb.nonNullable.group({...})
  2. •

    Form Controls with Validators

    • •Validators.* usage
    • •OneValidators.* usage
    • •Custom validators
  3. •

    Conditional Validators

    • •setValidators() / clearValidators() calls
    • •Dynamic validation logic

Output Format:

markdown
## Form Fields and Validation Rules

### Form: {formName}

| Field Name | Type     | Required | Validators                                 | Conditions       |
| ---------- | -------- | -------- | ------------------------------------------ | ---------------- |
| username   | text     | Yes      | required, maxLength(32), pattern(alphanum) | Always           |
| password   | password | Yes      | required, minLength(8), complexity         | Create mode only |

Step 3: Extract Error Messages

From HTML templates, extract:

  1. •

    mat-error elements

    • •Error conditions (*ngIf / @if)
    • •Translation keys for error messages
  2. •

    Error message mappings

    • •hasError('required') → message
    • •hasError('minlength') → message
    • •Custom error keys
  3. •

    oneUiFormError directive usage

    • •Auto-generated error messages

Output Format:

markdown
## Validation Error Messages

### Field: {fieldName}

| Validation Rule | Error Condition         | Error Message (Translation Key)     |
| --------------- | ----------------------- | ----------------------------------- |
| required        | `hasError('required')`  | `COMMON.VALIDATION.REQUIRED`        |
| minLength(8)    | `hasError('minlength')` | `COMMON.VALIDATION.MIN_LENGTH`      |
| pattern         | `hasError('pattern')`   | `ACCOUNT.VALIDATION.INVALID_FORMAT` |

Step 4: Extract Conditional Field Visibility

From templates and components, extract:

  1. •

    Conditional rendering

    • •@if (condition) / *ngIf="condition"
    • •[hidden]="condition"
    • •[disabled]="condition"
  2. •

    Mode-based visibility

    • •Create vs Edit mode differences
    • •Role-based field visibility
  3. •

    Dependent field logic

    • •Field A value affects Field B visibility
    • •Cascading selections

Output Format:

markdown
## Conditional Field Visibility

### Trigger: {triggerField} = {value}

| Affected Field  | Visibility | Enabled | Notes                            |
| --------------- | ---------- | ------- | -------------------------------- |
| passwordField   | Hidden     | -       | Only shown in create mode        |
| confirmPassword | Shown      | Enabled | Appears when password is entered |

Step 5: Extract API Payload Format

From API service files, extract:

  1. •

    POST/PUT endpoints

    • •Method signatures
    • •Payload interfaces
  2. •

    Request payload structure

    • •Required fields
    • •Optional fields
    • •Field types
  3. •

    Data transformations

    • •Form data → API payload mapping

Output Format:

markdown
## API Payload Format

### Endpoint: POST /auth/accountSet

#### Create Account (mode: 1)

```json
{
  "userName": "string (required)",
  "mode": 1,
  "userEnable": "number (0|1)",
  "authority": "number (1|2)",
  "new_pw": "string (required)",
  "confirm_pw": "string (required)"
}
```

Edit Account (mode: 2)

json
{
  "userName": "string (required)",
  "mode": 2,
  "userEnable": "number (0|1)",
  "authority": "number (1|2)"
}
code

### Step 6: Generate Boundary Test Cases

Based on extracted validation rules, generate test cases:

1. **String Length Boundaries**
   - minLength: test with (min-1), min, (min+1)
   - maxLength: test with (max-1), max, (max+1)

2. **Numeric Range Boundaries**
   - min: test with (min-1), min, (min+1)
   - max: test with (max-1), max, (max+1)

3. **Pattern Validation**
   - Valid pattern examples
   - Invalid pattern examples
   - Edge cases (empty, special chars)

4. **Required Fields**
   - Empty string
   - Whitespace only
   - Null/undefined

**Output Format:**

```markdown
## Boundary Test Cases

### Field: username

| Test Case ID | Input Value | Expected Result | Validation Rule |
|--------------|-------------|-----------------|-----------------|
| TC-USER-001 | "" (empty) | Error: Required | required |
| TC-USER-002 | "   " (spaces) | Error: Required | required |
| TC-USER-003 | "a" (1 char) | Error: Min length | minLength(4) |
| TC-USER-004 | "abcd" (4 chars) | Valid | minLength(4) |
| TC-USER-005 | "a".repeat(32) | Valid | maxLength(32) |
| TC-USER-006 | "a".repeat(33) | Error: Max length | maxLength(32) |
| TC-USER-007 | "user@123" | Error: Invalid char | pattern(alphanum) |
| TC-USER-008 | "user_123" | Valid | pattern(alphanum) |

Step 7: Generate Interaction Test Cases

Based on conditional visibility and mode logic:

  1. •

    Mode Switching

    • •Create mode field states
    • •Edit mode field states
    • •Transition between modes
  2. •

    Dependent Fields

    • •Trigger field changes
    • •Expected field state changes
  3. •

    Form Submission

    • •Valid submission
    • •Partial validation errors
    • •Server error handling

Output Format:

markdown
## Interaction Test Cases

### Scenario: Create New Account

| Step | Action                               | Expected Result                    |
| ---- | ------------------------------------ | ---------------------------------- |
| 1    | Click "Create" button                | Dialog opens with empty form       |
| 2    | Leave all fields empty, click Submit | Show required errors on all fields |
| 3    | Enter username "admin"               | Show "username exists" error       |
| 4    | Enter valid username                 | Error clears                       |
| 5    | Enter password "123"                 | Show "min length" error            |
| 6    | Enter password "ValidPass1!"         | Error clears                       |
| 7    | Enter mismatched confirm password    | Show "password mismatch" error     |
| 8    | Enter matching confirm password      | Error clears                       |
| 9    | Click Submit                         | Account created, dialog closes     |

Output

Generate a comprehensive test case document at: {target}/domain/src/lib/docs/QA-TEST-CASES.md

Document Structure

markdown
# QA Test Cases - {Feature Name}

Generated: {current_date}
Source: {target_path}

## Table of Contents

1. [Form Fields and Validation Rules](#form-fields-and-validation-rules)
2. [Validation Error Messages](#validation-error-messages)
3. [Conditional Field Visibility](#conditional-field-visibility)
4. [API Payload Format](#api-payload-format)
5. [Boundary Test Cases](#boundary-test-cases)
6. [Interaction Test Cases](#interaction-test-cases)

---

{Generated sections from Steps 2-7}

Notes

  • •Reports should be written in Traditional Chinese
  • •Focus on extracting actual validation rules from code, not assumptions
  • •Include translation keys for error messages to help QA verify correct text
  • •Cross-reference form field names with API payload field names
  • •Highlight any discrepancies between form validation and API expectations