テストケース設計

要求仕様書に基づいてテストケースを設計し、受け入れ基準とテストケースのトレーサビリティを確立します。

言語規則

• 中国語と英語での質問をサポートします
• 中国語での統一された回答
• 中国語を使用してドキュメントを生成します

トリガー条件

• ユーザーが要求仕様書を完了している
• ユーザーがテストケースの設計を要求している
• ユーザーがテストカバレッジ戦略を必要としている

前提条件

• 要求仕様書：docs/devdocs/01-requirements.md
• システム設計書：docs/devdocs/02-system-design.md（UT/IT の設計時に、インターフェースの署名とモジュール分割を理解する必要があります）
• 存在しない場合は、前提段階を最初に実行することをお勧めします

核心理念

テストケースのソース

機能点 (F-XXX)
    │
    └── ユーザー ストーリー (US-XXX)
            │
            └── 受け入れ基準 (AC-XXX)
                    │
                    ├── ユニットテスト (UT-XXX)  ← 内部ロジックの検証
                    │
                    ├── 統合テスト (IT-XXX)  ← コンポーネントの連携の検証
                    │
                    └── E2E テスト (E2E-XXX) ← ユーザー シナリオの検証

重要な原則：

• テストケースは要求から導き出され、コードから導き出されるものではありません
• 各受け入れ基準は、少なくとも 1 つのテストケースでカバーされている必要があります
• テストタイプは、受け入れ基準の性質に応じて選択します

テストタイプの選択

番号付け規則

ワークフロー

1. 要求仕様書を読み込む
   │
   ▼
2. 機能点、ユーザー ストーリー、受け入れ基準を抽出する
   │
   ▼
3. 各受け入れ基準に対してテストタイプを選択する
   │
   ▼
4. ユニットテストケースを設計する (UT-XXX)
   │
   ▼
5. 統合テストケースを設計する (IT-XXX)
   │
   ▼
6. E2E テストケースを設計する (E2E-XXX)
   │
   ▼
7. トレーサビリティマトリックスを生成する
   │
   ▼
8. ユーザーによる確認

出力ファイル

メインファイル：docs/devdocs/03-test-cases.md

ドキュメント分割ルール

次の条件が満たされる場合は、ドキュメントを分割する必要があります。

• テストケースの総数が 30 個を超える
• ドキュメントが 300 行を超える
• 単一のテストタイプのケースが 15 個を超える

分割方法：

docs/devdocs/
├── 03-test-cases.md           # メインドキュメント：テスト戦略、カバレッジ要件、トレーサビリティマトリックス
├── 03-test-unit.md            # ユニットテストケース（UT-XXX）
├── 03-test-integration.md     # 統合テストケース（IT-XXX）
└── 03-test-e2e.md             # E2E テストケース（E2E-XXX）

分割内容の割り当て：

メインドキュメントに保持される内容：

• テスト戦略の説明
• カバレッジ目標
• 完全なトレーサビリティマトリックス（F → US → AC → テスト）
• 各サブドキュメントのケース範囲の説明

小規模プロジェクト：テストケースが少ない場合（< 30 個）、単一のファイル 03-test-cases.md にまとめることができます。

詳細なテンプレートについては、以下を参照してください。

• templates/test-cases-template.md
• templates/unit-test-template.md
• templates/integration-test-template.md
• templates/e2e-test-template.md

テストケース概要ドキュメント構造

# テストケース：<機能名>

## 1. テスト戦略
## 2. カバレッジ要件
## 3. トレーサビリティマトリックス
## 4. テストケースの概要

トレーサビリティマトリックス

トレーサビリティマトリックスは、要求とテスト、コードの完全な関連性を示す重要な成果物です。

基本形式（設計段階）

| 機能点 | ユーザー ストーリー | 受け入れ基準 | ユニットテスト | 統合テスト | E2Eテスト | 状態 |
|--------|----------|----------|----------|----------|---------|------|
| F-001 | US-001 | AC-001 | UT-001 | - | E2E-001 | ⏳ |
| F-001 | US-001 | AC-002 | UT-002 | - | E2E-001 | ⏳ |
| F-001 | US-002 | AC-004 | UT-003, UT-004 | IT-001 | - | ⏳ |

完全な形式（開発段階、コードの場所を含む）

コードの場所は、/devdocs-sync --trace によって自動的に入力されます。これは、コード内の @satisfies/@verifies アノテーションのスキャンに基づいています。

| AC 编号 | 受け入れ基準 | テスト编号 | エントリーコード | テストコード | 状態 |
|---------|----------|----------|----------|----------|------|
| AC-001 | メールアドレスの形式検証 | UT-001 | `src/user.ts:15` | `tests/user.test.ts:20` | ✅ |
| AC-002 | パスワードの強度検証 | UT-002 | `src/user.ts:15` | `tests/user.test.ts:35` | ✅ |
| AC-003 | ユーザー名のユニーク性 | UT-003 | `src/user.ts:15` | `tests/user.test.ts:50` | ⏳ |
| AC-004 | 検証メールの送信 | IT-001 | - | - | ❌ |

コードの場所フィールドの説明

状態の説明

マトリックスのメンテナンスフロー

設計段階                    開発段階                     同期段階
    │                          │                           │
    ▼                          ▼                           ▼
基本マトリックスの生成          スケルトンコードの生成（アノテーション付き）        /devdocs-sync --trace
(AC → テスト编号)       (エントリー + テスト)                      │
                                                        ▼
                                                 コードアノテーションのスキャン
                                                        │
                                                        ▼
                                                 コードの場所列の入力
                                                        │
                                                        ▼
                                                 状態列の更新

テストケース形式

ユニットテストケース

| 编号 | 受け入れ基準 | テスト対象 | シナリオ | 入力 | 期待される出力 | 優先度 |
|------|----------|----------|------|------|----------|--------|
| UT-001 | AC-001 | validateEmail() | 有効なメールアドレス | "test@example.com" | true | P0 |
| UT-002 | AC-002 | validateEmail() | 無効な形式 | "invalid" | false | P0 |

統合テストケース

| 编号 | 受け入れ基準 | テストシナリオ | 関連コンポーネント | 期待される結果 | 優先度 |
|------|----------|----------|----------|----------|--------|
| IT-001 | AC-004 | パスワードの暗号化ストレージ | UserService + DB | パスワードは bcrypt 形式で保存される | P0 |

E2E テストケース

| 编号 | ユーザー ストーリー | 受け入れ基準 | 操作手順 | 期待される結果 | 優先度 |
|------|----------|----------|----------|----------|--------|
| E2E-001 | US-001 | AC-001~AC-003 | 1. 登録ページを開く<br>2. メールアドレスとパスワードを入力する<br>3. 登録をクリックする | 登録が成功し、検証メールが届く | P0 |

カバレッジ要件

制約

トレーサビリティ制約

• [ ] 各受け入れ基準は、少なくとも 1 つのテストケースでカバーされている必要があります
• [ ] トレーサビリティマトリックスを生成する必要があります
• [ ] トレーサビリティマトリックスは、すべての AC をカバーする必要があります

ケース設計制約

• [ ] テストケースは、受け入れ基準编号に関連付けられている必要があります
• [ ] 各ケースには、明確な期待される結果が必要です
• [ ] 優先度をマークする必要があります (P0/P1/P2)

カバレッジ制約

• [ ] P0 受け入れ基準は、100% テストでカバーされている必要があります
• [ ] P0 ユーザー ストーリーには、E2E テストが必要です
• [ ] ユニットテストの行カバレッジ目標 ≥ 80%

品質制約（/testing-guide を参照）

• [ ] テスト名は、期待される動作を記述する必要があります
• [ ] 弱いアサーションは禁止されています（toBeDefined、toBeTruthy は唯一のアサーションとして使用できません）
• [ ] Mock は外部依存関係にのみ使用されます

Skill 連携

(原文はここで切り捨てられています)