一键导入
test-plan-format
Test plan structure, naming conventions, edge case generation rules, and file saving conventions for QA test plans.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Test plan structure, naming conventions, edge case generation rules, and file saving conventions for QA test plans.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Backend testing patterns — API request construction, response verification, database state checks, error handling testing, and adaptive tool detection.
Frontend testing patterns using Playwright — navigation, interaction, assertions, screenshots on failure, and common UI testing scenarios.
Test report format with QA-XXX issue IDs compatible with code-review plugin. Defines report structure, severity levels, issue format with canonical fields, and detailed results.
Enforces AppVerk Swift coding standards across all code.
Structured concurrency and thread safety patterns in modern Swift.
Data persistence patterns for Swift apps using SwiftData, CoreData, UserDefaults, and Keychain.
| name | test-plan-format |
| description | Test plan structure, naming conventions, edge case generation rules, and file saving conventions for QA test plans. |
| activation | Load when creating or formatting QA test plans |
docs/testing/plans/YYYY-MM-DD-<topic>-test-plan.md where <topic> is a slugified summary (lowercase, hyphens, no spaces)mkdir -p docs/testing/plansEvery test plan MUST follow this exact structure:
# Test Plan: <title>
## Source
- Type: <PR #N / branch <name> / last N commits / staged changes>
- Base: <main/master>
- Date: <YYYY-MM-DD>
## Changes Summary
<Brief description of what changed and what needs testing. List affected areas.>
## Detected Tools
- Playwright: <available/unavailable>
- HTTP client: <curl/httpie/unavailable>
- Database access: <psql/sqlite3/mysql/unavailable>
## FE Test Scenarios
### FE-01: <scenario name>
- **Area:** <component/page>
- **Preconditions:** <what must be true before test>
- **Steps:**
1. <action>
2. <action>
3. <verification>
- **Expected:** <expected result>
- **Edge cases:**
- <edge case 1>
- <edge case 2>
## BE Test Scenarios
### BE-01: <scenario name>
- **Area:** <endpoint/service>
- **Method:** <HTTP method> <path>
- **Headers:** <required headers, e.g. Authorization: Bearer TOKEN>
- **Payload:** `<JSON body>`
- **Expected:** <status code>, <response body description>
- **DB Check:** `<SQL query>` — <expected state>
- **Edge cases:**
- <edge case with expected response>
FE-01, FE-02, ... FE-NN (zero-padded two digits)BE-01, BE-02, ... BE-NN (zero-padded two digits)For EVERY scenario, consider and include relevant edge cases from:
## BE Test Scenarios section entirely## FE Test Scenarios section entirely## Detected Tools and mark dependent scenarios with (skip — <tool> unavailable) in the scenario nameBefore saving the plan, verify: