test-case-designer

テストケース設計

PHP/CakePHP アプリケーションの要件と機能を包括的に網羅するテストケースを設計するための、特化型スキルです。

主な責務

1. テストケースの構成

標準的なテストケース形式：

Test Case:
  id: TC-[number]
  requirement_id: REQ-[number]
  type: unit|integration|system|e2e
  priority: high|medium|low

  description: [What is being tested]

  preconditions:
    - [Required setup]
    - [Initial state]

  test_steps:
    1. [Action to perform]
    2. [Next action]

  expected_results:
    - [Expected outcome]
    - [Verification point]

  postconditions:
    - [Cleanup needed]
    - [State after test]

  test_data:
    - [Required test data]

2. テストの分類

単体テスト：

/**
 * 単体テスト設計
 *
 * 対象: Individual methods/functions
 * 目的: Logic verification in isolation
 * モック: External dependencies
 */
Unit Test Criteria:
  - Single class/method focus
  - No database access
  - No external API calls
  - Fast execution (< 100ms)
  - Deterministic results

統合テスト：

/**
 * 結合テスト設計
 *
 * 対象: Component interactions
 * 目的: Verify integrations work
 * 実行: With real dependencies
 */
Integration Test Criteria:
  - Multiple components
  - Database interactions
  - Service integrations
  - Realistic scenarios

システムテスト：

/**
 * システムテスト設計
 *
 * 対象: End-to-end workflows
 * 目的: Full feature validation
 * 環境: Production-like
 */
System Test Criteria:
  - Complete user workflows
  - All components integrated
  - Performance validation
  - Security verification

3. CakePHP のテスト形式

PHPUnit のテスト構成：

/**
 * [機能名]のテスト
 *
 * 保証対象:
 * 1. [具体的な保証内容1]
 * 2. [具体的な保証内容2]
 * 失敗時の損失:
 * - [ビジネスへの影響]
 * - [ユーザーへの影響]
 */
public function test[MethodName](): void
{
    // Arrange (準備)
    // テストデータのセットアップ

    // Act (実行)
    // テスト対象の実行

    // Assert (検証)
    // 結果の確認
}

4. テストケース設計パターン

境界値分析：

Input: age (1-120)
Test Cases:
  - TC-001: age = 0 (below minimum)
  - TC-002: age = 1 (minimum)
  - TC-003: age = 60 (typical)
  - TC-004: age = 120 (maximum)
  - TC-005: age = 121 (above maximum)

同値分割：

Input: user_type
Partitions:
  - admin: Full access
  - user: Limited access
  - guest: Read-only

Test Cases:
  - TC-001: Admin can delete
  - TC-002: User cannot delete
  - TC-003: Guest cannot modify

状態遷移：

States: draft → submitted → approved → completed

Test Cases:
  - TC-001: draft to submitted (valid)
  - TC-002: draft to approved (invalid)
  - TC-003: approved to submitted (invalid)
  - TC-004: approved to completed (valid)

5. テストドキュメントのテンプレート

# Test Design Document: [Feature]

## Test Scope
### In Scope
- [What will be tested]

### Out of Scope
- [What won't be tested]

## Test Strategy
### Unit Tests
| Test ID | Description | Type | Priority |
|---------|-------------|------|----------|
| UT-001 | Validate email format | Unit | High |
| UT-002 | Calculate order total | Unit | High |

### Integration Tests
| Test ID | Description | Components | Priority |
|---------|-------------|------------|----------|
| IT-001 | User login flow | Auth + DB | High |
| IT-002 | Order processing | Order + Payment | High |

### System Tests
| Test ID | Description | Workflow | Priority |
|---------|-------------|----------|----------|
| ST-001 | Complete purchase | End-to-end | High |
| ST-002 | User registration | Full flow | Medium |

## Test Data Requirements
### Database State
- Users: 10 test users with various roles
- Products: 50 test products
- Orders: 100 test orders in various states

### Test Fixtures
```php
protected $fixtures = [
    'app.Users',
    'app.Products',
    'app.Orders',
    'app.OrderItems'
];

リスクベーステスト

高リスク領域

• 決済処理
• ユーザー認証
• データセキュリティ

中リスク領域

• レポート機能
• メール通知

低リスク領域

• 静的コンテンツの表示
• ヘルプドキュメント

## Test Case Generation Process

### Step 1: Requirement Analysis

各要件について：

1. テスト可能な条件を特定する
2. 必要なテストの種類を判断する
3. 成功基準を定義する
4. エッジケースを特定する

### Step 2: Test Case Creation

各条件について：

1. 正常系テストケースを作成する（ハッピーパス）
2. 異常系テストケースを作成する（エラーパス）
3. 境界値テストケースを作成する
4. 該当する場合は、パフォーマンステストケースを作成する

### Step 3: Test Data Design

各テストケースについて：

1. 入力データを定義する
2. 期待される出力を定義する
3. データベースの状態を定義する
4. 外部依存関係を定義する

### Step 4: Test Prioritization

優先度マトリックス： 影響度 高 低 リスク 高 P1 P2 低 P2 P3

P1：必ずテストする（ブロッカー） P2：テストするべき（重要） P3：テストしてもよい（実施が望ましい）

## CakePHP Specific Test Cases

### Controller Tests
```php
/**
 * Controller action test template
 */
public function testIndex(): void
{
    // 保証対象1: 認証が必要
    $this->get('/users');
    $this->assertRedirect('/login');

    // 保証対象2: 認証後アクセス可能
    $this->session(['Auth.User.id' => 1]);
    $this->get('/users');
    $this->assertResponseOk();

    // 保証対象3: データ表示
    $this->assertResponseContains('User List');
}

モデルテスト

/**
 * Model validation test template
 */
public function testValidation(): void
{
    // 保証対象1: 必須フィールド
    $user = $this->Users->newEmptyEntity();
    $user = $this->Users->patchEntity($user, []);
    $this->assertFalse($this->Users->save($user));
    $this->assertNotEmpty($user->getErrors());

    // 保証対象2: 正常データ
    $user = $this->Users->patchEntity($user, [
        'email' => '[email protected]',
        'password' => 'SecurePass123'
    ]);
    $this->assertTrue($this->Users->save($user));
}

コンポーネントテスト

/**
 * Component behavior test template
 */
public function testComponentMethod(): void
{
    // 保証対象1: 正常系
    $result = $this->Component->process($validData);
    $this->assertTrue($result);

    // 保証対象2: 異常系
    $result = $this->Component->process($invalidData);
    $this->assertFalse($result);
}

テストカバレッジの基準

コードカバレッジの目標

Minimum Coverage:
  - Unit Tests: 80%
  - Integration Tests: 60%
  - Overall: 70%

Critical Components:
  - Authentication: 95%
  - Payment Processing: 95%
  - Data Validation: 90%

要件カバレッジ

Functional Requirements:
  - All MUST requirements: 100%
  - All SHOULD requirements: 80%
  - All COULD requirements: 50%

Non-Functional Requirements:
  - Performance: All critical paths
  - Security: All auth points
  - Usability: Key workflows

出力例

例1：ログインのテスト設計

Test Suite: User Authentication

Unit Tests:
  - UT-001: Password hashing algorithm
  - UT-002: Token generation
  - UT-003: Session validation

Integration Tests:
  - IT-001: Database authentication
  - IT-002: LDAP authentication
  - IT-003: OAuth authentication

System Tests:
  - ST-001: Complete login flow
  - ST-002: Password reset flow
  - ST-003: Two-factor authentication

例2：注文処理のテスト設計

Test Suite: Order Management

Unit Tests:
  - UT-001: Calculate item total
  - UT-002: Apply discount rules
  - UT-003: Validate inventory

Integration Tests:
  - IT-001: Create order with payment
  - IT-002: Update inventory on order
  - IT-003: Send order notifications

System Tests:
  - ST-001: Complete purchase workflow
  - ST-002: Order cancellation workflow
  - ST-003: Return/refund workflow

ベストプラクティス

1. 早期テスト：要件と同時にテストを設計する
2. テストの独立性：各テストを単独で実行できるようにする
3. 明確な命名：テスト名からテスト内容がわかるようにする
4. アサーションは1つ：1つのテストにつき、論理的なアサーションを1つにする
5. 迅速なフィードバック：実行の速いテストを優先する
6. 保守性：テストをシンプルで読みやすい状態に保つ

適切なテスト設計により、バグが本番環境に到達する前に検出できます。