2.3 デシジョンテスト (Decision Testing)

「デシジョンテスト（Decision Testing）」 は、ソースコード内の制御フローの「判定（デシジョン）」に焦点を当てたホワイトボックステスト技法です。

このテストの目的は、if 文や switch 文、ループの制御文などの判定において、「真（True）」と「偽（False）」の両方の結果が、少なくとも1回は実行されるようにテストケースを設計することです。

デシジョンカバレッジの計算と優位性

デシジョンテストの網羅率は 「デシジョンカバレッジ（Decision Coverage）」 として測定されます。

計算式:

デシジョンカバレッジ＝（実行された判定結果の数／実行可能な全判定結果の数） × 100

ステートメントテスト（C0）との違い

前節のステートメントテストでは、「if ブロックの中を通らない（条件がFalseの）ルート」に隠れたバグを見逃してしまうという致命的な弱点がありました。

デシジョンテストでは、条件が「False」になった際に何も処理が行われない（空の else ルート）場合であっても、その「何もしないという判定結果」を1つの実行可能なルートとしてカウントし、必ずテストを通過させます。

重要な原則:

100%のデシジョンカバレッジは、100%のステートメントカバレッジを保証する。 （すべての判定のTrue/Falseを通れば、自然とすべての命令文も実行されるためです。しかし、その逆は成り立ちません。）

TTAが知っておくべき「限界」と「リスク」

デシジョンテストはステートメントテストよりも強力ですが、テクニカルテストアナリスト（TTA）は、この技法でも見逃してしまうバグの存在を認識しておく必要があります。

1. 複合条件（論理演算子）の隠れたバグ

if (A && B) のような、複数の条件が「AND」や「OR」で組み合わさった複合条件文の場合、デシジョンテストは「式全体としての True / False」しか評価しません。つまり、変数 A が原因で判定が切り替わったのか、変数 B が原因で切り替わったのかを区別しないため、個々の条件（サブコンディション）の評価ロジックに潜む欠陥を見逃すリスクがあります。

2. ループの境界エラー

デシジョンテストは「while や for ループの中に入るか（True）、入らないか（False）」はテストしますが、「ループを何回実行したか」は考慮しません。そのため、ループの境界条件（1回多い、1回足りない）に関するバグの検出には不十分です。

TTAとしての適用ガイドライン

業界標準のベースライン: セキュリティや信頼性が求められる多くの業界標準（自動車、医療機器、航空機などの機能安全規格）において、最低限クリアすべきカバレッジ基準として「100%のデシジョンカバレッジ」が要求されます。
複雑なロジックへの対応: デシジョンテストをクリアした上で、複合条件を含む複雑な判定文が存在するコンポーネントには、次節で解説するより高度な 「MC/DC（変更条件/デシジョンカバレッジ）」 や 「複合条件テスト」 をピンポイントで適用し、テストの費用対効果（ROI）を最適化することがTTAの重要な役割です。