問題20
問題 #20
Section titled “問題 #20”フードオーダーシナリオをユースケーステストで検証します。
メインシナリオ（正常フロー）
Section titled “メインシナリオ（正常フロー）”| ステップ | 説明 |
|---|---|
| 1 | 顧客がアプリを開いてログインする |
| 2 | 顧客がメニューを閲覧し、注文する商品を選ぶ |
| 3 | 顧客が選んだ商品をカートに追加する |
| 4 | 顧客がチェックアウトに進む |
| 5 | アプリが注文サマリー（商品・数量・合計金額）を表示する |
| 6 | 顧客が注文を確定する |
| 7 | アプリが保存済み支払い方法を使うか確認する |
| 8 | 顧客が保存済み支払い方法を確認する |
| 9 | アプリが支払いを処理する |
| 10 | アプリが顧客に確認通知を送る |
| 11 | アプリが注文をレストランに転送する |
| 12 | アプリが注文ステータスを「確認済み」に更新する |
代替シナリオ
Section titled “代替シナリオ”| ID | 発生ステップ | 内容 |
|---|---|---|
| 4A | 4 | 顧客がメニュー閲覧に戻る → ステップ2に戻る |
| 6A | 6 | 顧客がメニュー閲覧に戻る → ステップ2に戻る |
| 7A | 7 | 支払い方法が未登録 → システムがクレジットカード情報を要求 → 顧客が入力 → ステップ9へ |
| 7B | 7 | 支払い方法が複数登録済み → システムが選択を促す → 顧客が選択 → ステップ9へ |
例外シナリオ
Section titled “例外シナリオ”| ID | 発生ステップ | 内容 |
|---|---|---|
| 9A | 9 | 支払い処理が失敗 → システムがエラーを通知 → ユースケース終了 |
テスト戦略の制約
Section titled “テスト戦略の制約”- メインシナリオ・すべての代替シナリオ・すべての例外シナリオをテストする
- 1つのテストケースに複数の代替シナリオを含めることができる
- 例外が発生するテストケースには、代替シナリオを含めることができない
このユースケースのすべてのシナリオをカバーするために必要な最小テストケース数はいくつか？
- a) 2
- b) 3
- c) 4
- d) 5
カバーすべきシナリオの整理
Section titled “カバーすべきシナリオの整理”以下の6つのシナリオをすべてカバーする必要があります。
| シナリオ | 種類 | 発生ステップ |
|---|---|---|
| メインシナリオ | メイン | 1〜12（全完了） |
| 4A | 代替 | 4 |
| 6A | 代替 | 6 |
| 7A | 代替 | 7 |
| 7B | 代替 | 7 |
| 9A | 例外 | 9 |
制約1：9A（例外）は単独テストケースが必要
Section titled “制約1：9A（例外）は単独テストケースが必要”例外が発生するテストケースには代替シナリオを含めることができません。9A はステップ9で失敗してユースケースが終了するため、他の代替シナリオ（4A、6A、7A、7B）とは別のテストケースが必要です。
制約2：7A・7B は排他関係
Section titled “制約2：7A・7B は排他関係”7A と 7B はどちらもステップ7で発生しますが、システムの状態（登録済み支払い方法の数） によって決まります。
| 状態 | 実行されるシナリオ |
|---|---|
| 支払い方法 = 0件 | 7A |
| 支払い方法 = 1件 | メインシナリオのステップ7→8 |
| 支払い方法 ≥ 2件 | 7B |
7A と 7B は同じテストケースで同時に発生させることができません。
制約3：メインシナリオは独立したカバレッジが必要
Section titled “制約3：メインシナリオは独立したカバレッジが必要”メインシナリオではステップ7→8（保存済み1件の支払い方法を確認）とステップ9→12（支払い成功・通知・転送・ステータス更新）がすべて完了する必要があります。9A テストケースはステップ9で失敗するためステップ10〜12に到達できず、メインシナリオを代替できません。
最小テストケースの設計
Section titled “最小テストケースの設計”上記の制約から、ステップ7での分岐（メイン・7A・7B）がそれぞれ別テストケースを必要とするボトルネックになります。
| テストケース | カバーするシナリオ | テスト経路 |
|---|---|---|
| TC1 | メイン（＋4A＋6A） | 1→2→3→4→（4A）→2→3→4→5→6→（6A）→2→3→4→5→6→7→8→9→10→11→12 |
| TC2 | 7A | 1→2→3→4→5→6→7→（7A：カード入力）→9→10→11→12 |
| TC3 | 7B | 1→2→3→4→5→6→7→（7B：支払い方法選択）→9→10→11→12 |
| TC4 | 9A（例外） | 1→2→3→4→5→6→7→8→9→（9A：失敗） |
TC1 に代替シナリオ 4A・6A を組み込むことで、4つのテストケースで全6シナリオをカバーできます。
カバレッジの確認
Section titled “カバレッジの確認”| シナリオ | TC1 | TC2 | TC3 | TC4 |
|---|---|---|---|---|
| メインシナリオ | ✓ | |||
| 4A | ✓ | |||
| 6A | ✓ | |||
| 7A | ✓ | |||
| 7B | ✓ | |||
| 9A | ✓ |
3件に削減できない理由
Section titled “3件に削減できない理由”3件に減らすには、いずれか2つのテストケースを統合する必要があります。
| 統合の試み | 結果 |
|---|---|
| TC1（メイン）+ TC2（7A） | ✗ ステップ7での分岐が排他で不可 |
| TC1（メイン）+ TC3（7B） | ✗ ステップ7での分岐が排他で不可 |
| TC2（7A）+ TC3（7B） | ✗ ステップ7での分岐が排他で不可 |
| TC1〜TC3 のいずれか + TC4（9A） | ✗ 代替シナリオと例外の共存が禁止 |
すべての統合パターンが制約に違反するため、3件以下にはできません。
c) 4
ボトルネックとなる「排他的分岐」を探す
Section titled “ボトルネックとなる「排他的分岐」を探す”テストケース数の下限は、排他的に発生するシナリオの数によって決まります。この問題ではステップ7に3つの排他的な分岐（メイン・7A・7B）があり、これらは必ず別々のテストケースになります。さらに9A（例外）が加わり、最小4件となります。
代替シナリオの効率的な組み合わせ
Section titled “代替シナリオの効率的な組み合わせ”代替シナリオ 4A・6A はどのテストケースにも組み込める柔軟性があります。TC1 に 4A と 6A を両方含めることで、余分なテストケースの追加なしに全代替シナリオをカバーできます。
例外テストケースの設計
Section titled “例外テストケースの設計”9A はステップ9で強制終了するため、後続ステップ（10〜12）のカバレッジに貢献しません。例外テストケースは「エラーが正しく通知されるか」を確認する目的に特化し、正常系のカバレッジは別途確保する必要があります。