公開：
組み合わせテストとは？主な手法や成功のポイントを解説
ソフトウェアテストでは、抜け漏れのないテスト設計が求められます。その一方で、多くのプロダクトでは機能・処理ごとに無数の入力条件が想定されるため、すべてのパターンを検証することは現実的ではありません。
こうしたジレンマの解決に向けた手段の1つとして有効なのが、組み合わせテストです。論理や統計的根拠に基づいて必要なテストケースを絞ることで、効率と品質の両立につなげられます。
本記事では、組み合わせテストの定義や必要性、主要な技法、実施手順、成功のポイントまで解説します。
目次
組み合わせテストとは
組み合わせテストとは、複数の「因子」（条件）とその「水準」（値）を組み合わせて、システムの動作を確認する手法です。
因子
プロダクトの処理に影響を与える入力条件のこと
例）OS、ブラウザ
水準
それぞれの因子に当てはめる具体的な値のこと
例）因子「OS」に対するWindows、macOS、「ブラウザ」に対するSafari、Chrome
すべての組み合わせを検証しようとするとテストケースが無限に増えてしまいますが、後述するような手法で検証すべき因子と水準の組み合わせを絞り込めば、効率的なテストの進行が期待できます。
組み合わせテストが必要な理由
組み合わせテストが必要とされる背景には、多くのプロダクトの仕様上、因子の組み合わせが際限なく広がってしまうという問題があります。
例えば、ECサイトの注文処理のテストで、次のような因子が関係するとします。
- OS（4水準）：iOS / Android / Windows / macOS
- ブラウザ（4水準）：Safari / Chrome / Edge / Firefox
- 会員ランク（5水準）：非会員 / 一般 / ブロンズ / シルバー / ゴールド
- 決済手段（5水準）：クレジットカード / コンビニ払い / 銀行振込 / PayPay / PayPal
- 配送方法（4水準）：日時指定なし / 日付のみ指定 / 日時指定 / お急ぎ便
これらをすべて組み合わせると、4×4×5×5×4=1600通りのテストケースが発生します。1ケースの確認に5分の時間を要する場合、合計で8,000分（130時間以上）必要となります。
このような「組み合わせ爆発」の問題を回避するため、多くの開発現場で組み合わせテストが採用されています。
組み合わせテストの主要な技法
組み合わせテストにはいくつかの技法があり、因子の数や因子間の依存関係、テストに割けるリソースなどに応じて技法を使い分ける必要があります。
ここでは、実務でよく用いられる4つの技法について解説します。
ペアワイズ法
ペアワイズ法は、2つの因子を組み合わせたパターン（ペア）を一度ずつカバーすることで、テストケース数を削減しながらも高い網羅性を保つテスト設計技法です。
アメリカ国立標準技術研究所（NIST）の研究によると、実際の障害の70〜90%は2因子の相互作用に起因するといわれています。この経験則に基づき、ペアワイズ法では、最小限のテストケースで、すべての2因子間の組み合わせを検証できるようにテストを設計します。
例えば、業務システムの帳票出力機能で、次のような3つの因子があるとします。
- 出力形式（3水準）：PDF / Excel / CSV
- 文字コード（3水準）：UTF-8 / Shift_JIS / UTF-16
- 権限（2水準）：一般 / 管理者
この場合、全組み合わせ（全網羅）でテストを行うと、3×3×2＝18パターンが必要となります。一方、ペアワイズ法を用いると、以下のように9通りまでテストケースが絞り込まれます。
| No. | 出力形式 | 文字コード | 権限 |
| 1 | UTF-8 | 一般 | |
| 2 | Shift_JIS | 管理者 | |
| 3 | UTF-16 | 一般 | |
| 4 | Excel | UTF-8 | 管理者 |
| 5 | Excel | Shift_JIS | 一般 |
| 6 | Excel | UTF-16 | 管理者 |
| 7 | CSV | UTF-8 | 一般 |
| 8 | CSV | Shift_JIS | 管理者 |
| 9 | CSV | UTF-16 | 一般 |
表中では「出力形式×文字コード」「文字コード×権限」「出力形式×権限」の各組み合わせが、すべて一度は登場しています。
このようにペアワイズ法を活用すれば、テストの網羅性を保ちつつ、工数やコストを抑えた効率的なテスト設計が可能になります。
少ないテストケースで一定の品質を確保できることから、多くのプロジェクトで採用されている代表的な組み合わせテスト技法の一つです。
直交表
直交表は、任意のn因子を選んだときに、水準の組み合わせが同数出現するように設計された表です。
例えば、ECサイトや動画配信アプリの検索やレコメンド機能では、次のような複数の因子が同時に関与します。
- ユーザー状態（2水準）：未ログイン / ログイン済み
- フィルタ（3水準）：なし / 単一フィルタ / 複数フィルタ併用
- 言語（3水準）：日本語 / 英語 / 日本語＋英語の混在
- キャッシュ状態（3水準）：キャッシュなし（初回利用） / キャッシュあり / キャッシュ不整合
そこで、以下のような直交表をもとにテストケースを作成することで、2因子の組み合わせパターンをバランスよく網羅できるようにします。
| No. | ユーザー状態 | フィルタ | 言語 | キャッシュ状態 |
| 1 | 未ログイン | なし | 日本語 | キャッシュなし（初回利用） |
| 2 | 未ログイン | なし | 英語 | キャッシュあり |
| 3 | 未ログイン | なし | 日+英混在 | キャッシュ不整合 |
| 4 | 未ログイン | 単一フィルタ | 日本語 | キャッシュなし（初回利用） |
| 5 | 未ログイン | 単一フィルタ | 英語 | キャッシュあり |
| 6 | 未ログイン | 単一フィルタ | 日+英混在 | キャッシュ不整合 |
| 7 | 未ログイン | 複数フィルタ併用 | 日本語 | キャッシュあり |
| 8 | 未ログイン | 複数フィルタ併用 | 英語 | キャッシュ不整合 |
| 9 | 未ログイン | 複数フィルタ併用 | 日+英混在 | キャッシュなし（初回利用） |
| 10 | ログイン済み | なし | 日本語 | キャッシュ不整合 |
| 11 | ログイン済み | なし | 英語 | キャッシュなし（初回利用） |
| 12 | ログイン済み | なし | 日+英混在 | キャッシュあり |
| 13 | ログイン済み | 単一フィルタ | 日本語 | キャッシュあり |
| 14 | ログイン済み | 単一フィルタ | 英語 | キャッシュ不整合 |
| 15 | ログイン済み | 単一フィルタ | 日+英混在 | キャッシュなし（初回利用） |
| 16 | ログイン済み | 複数フィルタ併用 | 日本語 | キャッシュ不整合 |
| 17 | ログイン済み | 複数フィルタ併用 | 英語 | キャッシュなし（初回利用） |
| 18 | ログイン済み | 複数フィルタ併用 | 日+英混在 | キャッシュあり |
※上記の表は、「L18」と呼ばれる、直交表の形式です。ほかにもL4、L8などの種類があり、因子・水準の数によって使い分けます。
直交表の場合、ペアワイズ法と比較してテストケース数は増える傾向にありますが、組み合わせの偏りをなくしたい機能（たとえば、複数の条件が複雑に絡み合うフィルタ処理やキャッシュ制御）では、直交表の均等性が品質の安定につながります。
対象機能の性質やコストに応じて、使い分けを検討するとよいでしょう。
組み合わせテストを成功させるためのポイント
組み合わせテストはテストの工数を抑えながら品質を確保できる優れた技法ですが、テストケースの絞り方を誤ると、かえって工数の増大や不具合の見逃しにつながります。
最後に、組み合わせテストを成功させるためのポイントを解説します。
因子ごとの水準を適切な粒度に保つ
まず注意したいのが、1つの因子に水準を詰め込み過ぎないことです。
ここでは、ECサイトの配送時間帯を因子とする場合の悪い例とよい例を見てみましょう。
【悪い例】
8～9時 / 9～10時……21～22時（14水準）
【よい例】
午前中 / 午後 / 夜間 / 指定なし（4水準）
NISTの記事には、多くとも10～12程度に抑えるべきだという見解が記載されています。一方で少なすぎても不具合の見過ごしにつながるため、4～6程度が適切である場合が多いとしています。
水準は客観的な基準で区切る
連続する値を水準に区切る場合、基準が主観的・抽象的なものにならないように注意が必要です。
例えば、ECサイトの検索フィルタの金額について、区切り方の悪い例とよい例を考えてみます。
【悪い例】
低 / 中 / 高
【よい例】
4,999円以下 / 5,000円～9,999円 / 10,000円以上
境界値分析や同値分割の手法を用いて客観的な基準に区切ることで、テストの再現性を確保し、確実な品質保証につなげられます。
※境界値分析・同値分割について、詳しくは以下の記事をご覧ください。
参考：境界値テストとは？定義やメリット、設計のポイントについて解説
リスクベースで優先度を検討する
テストケースを絞りながら品質リスクを抑えるためには、リスクベースでの優先度付けが有効です。
具体的には、以下のような基準をもとにテストケースの数を調整していきます。
- 機能の使用頻度
- 過去の不具合発生傾向
- 不具合による問題の大きさ
例えばログイン・会員登録といった日常的に使用される機能や、決済機能などの不具合発生時のリスクが大きい機能は、因子数を増やし重点的にテストする必要があります。一方で、年に数回しか使わないような機能・処理（勤怠管理アプリにおける、特殊な休暇の取得など）については、因子・水準を大まかに区切りながらテストケースを絞り込むとよいかもしれません。
このようにリスクベースで優先順位を考えていくことで、限られたリソースのなかでも十分な品質保証につなげられます。
組み合わせテストを使いこなし、品質と効率を両立するために
組み合わせテストは、効率と品質のバランスを取る効果的な技法です。「なぜこの組み合わせでテストケースが必要十分なのか」というロジックを理解して手法を使いこなすことで、テストケースの数を絞りながら品質リスクを最小限に抑えられます。
一方で、因子や水準の設定には専門的な知見が求められ、不適切なテスト設計により不具合の見落としが多発したり、テストケースが増大したりといった問題にもつながります。
テスト計画・設計に関して社内にナレッジが不足している場合は、外部のテスト支援会社と協業することも有効な手段の1つです。
AGESTでは、組み合わせテストを含む各種テストの効率化と標準化を支援しています。経験豊富なテストエンジニアが、社内のリソースやプロダクトの性質に応じた最適なテスト戦略を提案。テスト後の評価や改善活動まで一気通貫で支援します。
自社の品質保証体制に課題をお持ちの方は、ぜひお気軽にご相談ください。
