菜单
Testing pyramid and test writing standards for UT/IT/ST/E2E. Supports ISTQB and Industry Pyramid frameworks. Use when: writing tests, discussing test coverage, test strategy, or test naming. Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT, 測試, 單元, 整合, 端對端.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ValorVie/custom-skills --skill testing-guide命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
為目標、範圍與授權已明確的非簡單 Agent 工作選擇互動模式、能力層級、風險、派工形狀、審查與有限備援。適用於需要在主 Agent 直接處理、單一工作代理與有限平行之間選擇，或需要依複雜度與風險決定能力層級及審查強度的工作；Codex 專案缺少已驗證的 Agent 設定時，也用本 Skill 引導使用者選擇建立、預覽或略過。簡單問答、唯讀確認與可直接驗證的小修改不要使用。
以統一格式撰寫計畫、報告、指南、教學、紀錄、規範等文件，並依專案慣例決定知識庫放置路徑、主題分類與索引更新。 Use when: 使用者要求撰寫或起草文件，或需要整理 docs 目錄、文件分類、主題索引與知識庫結構。包含但不限於：計畫書（新功能/重構/遷移）、報告（調查/階段/分析）、指南、教學、會議紀錄、事件紀錄、決策紀錄、規範文件。 觸發方式: /custom-skills-doc-writer [type] [variant] Keywords: 撰寫文件, 文件模板, 文件分類, 文件目錄, 知識庫, 主題索引, 計畫書, 報告, 指南, 教學, 紀錄, 規範, document writer, plan, report, guide, tutorial, record, standard, 寫文件, 起草, draft
CRITICAL PROTOCOL: 本技能是所有任務或其他技能的底層依賴。嚴禁在未讀取auto-skill/skill.md的情況下啟動任何開發任務。這不是建議，而是必須執行的初始化程序。任何跳過此步驟的行為都將被視為任務失敗。任何任務都必須同時啟用 auto-skill（即使其他技能已觸發）。每次對話自動檢查知識庫並調用最佳實踐；同時建立跨技能經驗記憶層，讓下次使用同技能時能主動提醒。當用戶表達滿意時，必須詢問是否記錄經驗。適用於所有任務型對話。
正在显示 SKILL.md
| name | testing-guide |
| scope | uds-specific |
| description | Testing pyramid and test writing standards for UT/IT/ST/E2E. Supports ISTQB and Industry Pyramid frameworks. Use when: writing tests, discussing test coverage, test strategy, or test naming. Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT, 測試, 單元, 整合, 端對端. |
Language: English | 繁體中文
Version: 1.2.0 Last Updated: 2026-04-18 Applicability: Claude Code Skills
This skill provides testing pyramid standards and best practices for systematic testing, supporting both ISTQB and Industry Pyramid frameworks.
UDS provides 6 testing-related skills. Use this decision tree to find the right one:
What do you want to do? | 你想做什麼？
├── Measure code coverage (lines/branches/functions) → /coverage
├── Track which requirements have tests (AC traceability) → /ac-coverage
├── Develop with Test-Driven Development (Red-Green-Refactor) → /tdd
├── Write BDD scenarios (Given-When-Then) → /bdd
├── Define acceptance tests with stakeholders → /atdd
└── Learn testing standards and best practices → /testing (this skill)
| Skill | Focus | 焦點 |
|---|---|---|
/testing | Standards and best practices reference | 測試標準與最佳實踐參考 |
/coverage |
| Code-level coverage analysis |
| 程式碼層級覆蓋率分析 |
/ac-coverage | Requirement-level AC traceability | 需求層級 AC 可追蹤性 |
/tdd | Red-Green-Refactor development cycle | 紅-綠-重構開發循環 |
/bdd | Behavior scenarios with Given-When-Then | Given-When-Then 行為場景 |
/atdd | Acceptance criteria with stakeholders | 與利害關係人定義驗收條件 |
| Framework | Levels | Best For |
|---|---|---|
| ISTQB | UT → IT/SIT → ST → AT/UAT | Enterprise, compliance, formal QA |
| Industry Pyramid | UT (70%) → IT (20%) → E2E (10%) | Agile, DevOps, CI/CD |
Note on Integration Testing abbreviation:
┌─────────┐
│ E2E │ ← 10% (Fewer, slower)
─┴─────────┴─
┌─────────────┐
│ IT/SIT │ ← 20% (Integration)
─┴─────────────┴─
┌─────────────────┐
│ UT │ ← 70% (Unit)
└─────────────────┘
| Level | Scope | Speed | Dependencies |
|---|---|---|---|
| UT | Single function/class | < 100ms | Mocked |
| IT/SIT | Component interaction | 1-10s | Real DB (containerized) |
| ST | Full system (ISTQB) | Minutes | Production-like |
| E2E | User journeys | 30s+ | Everything real |
| AT/UAT | Business validation (ISTQB) | Varies | Everything real |
| Metric | Minimum | Recommended |
|---|---|---|
| Line | 70% | 85% |
| Branch | 60% | 80% |
| Function | 80% | 90% |
For complete standards, see:
For AI assistants, use the YAML format files for reduced token usage:
ai/standards/testing.ai.yamlai/options/testing/istqb-framework.ai.yamlai/options/testing/industry-pyramid.ai.yamlai/options/testing/unit-testing.ai.yamlai/options/testing/integration-testing.ai.yamlai/options/testing/system-testing.ai.yamlai/options/testing/e2e-testing.ai.yamlai/options/testing/security-testing.ai.yamlai/options/testing/performance-testing.ai.yamlai/options/testing/contract-testing.ai.yaml[ClassName]Tests.cs # C#
[ClassName].test.ts # TypeScript
[class_name]_test.py # Python
[class_name]_test.go # Go
[MethodName]_[Scenario]_[ExpectedResult]()
should_[behavior]_when_[condition]()
test_[method]_[scenario]_[expected]()
| Type | Purpose | When to Use |
|---|---|---|
| Stub | Returns predefined values | Fixed API responses |
| Mock | Verifies interactions | Check method called |
| Fake | Simplified implementation | In-memory database |
| Spy | Records calls, delegates | Partial mocking |
test('method_scenario_expected', () => {
// Arrange - Setup test data
const input = createTestInput();
const sut = new SystemUnderTest();
// Act - Execute behavior
const result = sut.execute(input);
// Assert - Verify result
expect(result).toBe(expected);
});
# === ISTQB FUNDAMENTALS ===
terminology:
error: "Human mistake in thinking"
defect: "Bug in code (caused by error)"
failure: "System behaves incorrectly (caused by defect)"
chain: "Error → Defect → Failure"
oracle_problem:
definition: "How do we know the expected result is correct?"
approaches:
- specification_oracle: "Compare against spec"
- reference_oracle: "Compare against reference impl"
- consistency_oracle: "Same input → same output"
- heuristic_oracle: "Reasonable approximation"
# === STATIC vs DYNAMIC ===
static_testing:
definition: "Examine without executing"
techniques: [reviews, walkthroughs, inspections, static_analysis]
finds: "Defects before runtime"
examples: [ESLint, SonarQube, code_review]
dynamic_testing:
definition: "Execute and observe behavior"
techniques: [unit, integration, system, acceptance]
finds: "Failures during execution"
# === TEST DESIGN TECHNIQUES ===
black_box:
equivalence_partitioning:
principle: "Divide inputs into equivalent classes"
example: "Age: [<0 invalid], [0-17 minor], [18-64 adult], [65+ senior]"
boundary_value:
principle: "Test at boundaries of partitions"
example: "Age: test -1, 0, 17, 18, 64, 65"
decision_table:
principle: "Combinations of conditions → actions"
use: "Complex business rules"
state_transition:
principle: "Valid sequences of states"
use: "Workflow, state machines"
white_box:
statement_coverage: "Every statement executed once"
branch_coverage: "Every decision branch taken"
condition_coverage: "Every condition T/F"
path_coverage: "Every possible path (often impractical)"
# === RISK-BASED TESTING ===
risk_assessment:
likelihood: "How likely to fail?"
impact: "How bad if fails?"
priority: "likelihood × impact"
risk_matrix:
high_high: "Test extensively, first priority"
high_low: "Good coverage"
low_high: "Good coverage"
low_low: "Basic coverage"
# === DEFECT MANAGEMENT ===
defect_lifecycle:
states: [new, assigned, in_progress, fixed, verified, closed]
reopen_trigger: "Verification fails"
severity_vs_priority:
severity: "Technical impact (critical/major/minor/trivial)"
priority: "Business urgency (high/medium/low)"
example: "Typo on login page: low severity, high priority (brand)"
# === TEST ENVIRONMENT ===
isolation_levels:
unit: "In-memory, mocked deps"
integration: "Containerized DB (Docker)"
staging: "Production-like, isolated"
production: "Real, feature flags for testing"
test_data_strategies:
fixtures: "Static predefined data"
factories: "Dynamic generation (faker)"
snapshots: "Sanitized production copy"
synthetic: "Algorithm-generated edge cases"
This skill supports project-specific configuration.
CONTRIBUTING.md for "Disabled Skills" section
CONTRIBUTING.md for "Testing Standards" sectionIf no configuration found and context is unclear:
CONTRIBUTING.md:## Testing Standards
### Coverage Targets
| Metric | Target |
|--------|--------|
| Line | 80% |
| Branch | 70% |
| Function | 85% |
In project's CONTRIBUTING.md:
## Testing Standards
### Coverage Targets
| Metric | Target |
|--------|--------|
| Line | 80% |
| Branch | 70% |
| Function | 85% |
### Testing Framework
- Unit Tests: Jest
- Integration Tests: Supertest
- E2E Tests: Playwright
After /testing completes, the AI assistant should suggest:
測試標準與最佳實踐已掌握。建議下一步 / Testing standards and best practices understood. Suggested next steps:
- 執行
/tdd開始測試驅動開發（紅-綠-重構循環） ⭐ Recommended / 推薦 — 將測試知識立即轉化為實踐 / Turn testing knowledge into practice immediately- 執行
/coverage分析目前程式碼覆蓋率 — 找出測試缺口 / Identify testing gaps- 執行
/bdd撰寫行為驅動的 Given-When-Then 場景 — 從使用者角度定義測試 / Define tests from user perspective
| Version | Date | Changes |
|---|---|---|
| 1.2.0 | 2026-04-18 | Added: Testing Skills Navigator, testing-theory.md, test-skeleton-templates.md, additional AI YAML options, Next Steps Guidance |
| 1.1.1 | 2026-01-30 | Patch updates |
| 1.1.0 | 2025-12-29 | Added: Testing Theory Essentials YAML section |
| 1.0.0 | 2025-12-24 | Initial: Standard sections (Purpose, Related Standards, Version History, License) |
This skill is released under CC BY 4.0.
Source: universal-dev-standards