テスト技法一覧｜ブラックボックス・ホワイトボックスの種類と選び方早見表

テスト技法は、テストケースを「勘」ではなく「理由のある選び方」で作るための方法です。 JSTQB（ISTQB の日本の団体）の Foundation Level シラバス 4.0 は、テスト技法を ブラックボックス・ホワイトボックス・経験ベース の3つに分けています。

確認環境：カバレッジの比較は、Python 3.11.15・pytest 9.1.1・coverage.py 7.16.2（Linux）で測りました。条件カバレッジと MC/DC は、coverage.py では測れないため、真理値表を数える Python のスクリプトで確かめています。選び方のフロー図は Mermaid 12.1.0 で描画できることを確かめました。技法の定義は ISTQB CTFL シラバス v4.0 の第4章で確かめています（確認日 2026年10月12日）。

テスト技法の早見表

表の「件数の目安」は、その技法で「最低限そろえるテストケースの数」の考え方です。 実際の件数は、条件や値の数で決まります。

ブラックボックス技法

ホワイトボックス技法

経験ベースの技法

各技法の詳しいやり方は、次の関連記事で扱っています。

• 同値分割・境界値：関連記事「同値分割・境界値分析｜テストケース表とpytestコード例で解説」で扱っています。
• デシジョンテーブル：関連記事「デシジョンテーブルの書き方と例5題｜条件の簡単化とテストケースの作り方」で扱っています。
• 状態遷移：関連記事「状態遷移図と状態遷移表の書き方｜テスト設計とMermaid・PlantUML」で扱っています。
• ペアワイズ：関連記事「ペアワイズテストのやり方｜108通りを12件にする手順」で扱っています。

ブラックボックス技法のポイント

ブラックボックス技法は、仕様書だけでテストケースを作れます。 そのため、コードができる前にテストを設計できます。

• 同値分割法と境界値分析は、ほぼいつも一緒に使います。 同値分割で「どの区分を試すか」を決め、境界値分析で「区分の端のどの値を試すか」を決めます。ISTQB のシラバスでは、境界値分析に 2値（境界の値と、隣の区分のいちばん近い値）と 3値（境界の値と、その両隣）の2つがあり、3値のほうが厳しいとされています。たとえば x <= 10 が誤って x == 10 になっていると、2値の 10・11 では見つからず、3値で加わる 9 で見つかります。
• デシジョンテーブルは「条件の組み合わせで結果が決まる」ものに使います。 カバレッジは「試したルール（列）の数 ÷ 実現できるルールの数」です。
• 状態遷移テストには、3つのカバレッジがあります。 全状態（すべての状態を通る）、有効遷移（すべての正しい遷移を通る。0スイッチとも呼ぶ）、全遷移（無効な遷移も試す）です。シラバスでは、有効遷移が最も広く使われ、全遷移は有効遷移と全状態の両方を含むとされています。無効な遷移は、1つのテストケースで1つだけ試します（不具合が隠れるのを防ぐため）。

ホワイトボックス技法：カバレッジを小さなコードで比べる

カバレッジの種類の違いは、条件が複数ある if 文で比べると分かりやすくなります。 送料を決める次の関数で、4つのテストの組（a〜d）を試しました。

# fee.py
def shipping_fee(total, is_member, has_coupon):
    fee = 500
    if is_member and (total >= 5000 or has_coupon):
        fee = 0
    return fee

判定は1つ（if）、条件は3つ（is_member、total >= 5000、has_coupon）です。下の表の「T／F」は、3つの条件の真（T）・偽（F）を順に並べたものです。

coverage.py で測った結果

ステートメントとブランチは、coverage.py で測りました。テストの組 a（1件）の結果です。

$ coverage run -m pytest -q test_a.py && coverage report -m --include=fee.py
Name     Stmts   Miss  Cover   Missing
--------------------------------------
fee.py       5      0   100%
--------------------------------------
TOTAL        5      0   100%

$ coverage run --branch -m pytest -q test_a.py && coverage report -m --include=fee.py
Name     Stmts   Miss Branch BrPart  Cover   Missing
----------------------------------------------------
fee.py       5      0      2      1    86%   3->5
----------------------------------------------------
TOTAL        5      0      2      1    86%

• 1件でステートメントは 100% になりました。 if の中の fee = 0 も通るからです。
• --branch を付けると 86% に下がり、3->5（3行目の if から5行目へ飛ぶ、つまり「条件が偽」の道）を通っていないことが分かります。 coverage.py のドキュメントでは、Missing の 3->5 のような表記は「遷移元->遷移先」の分岐を通っていないことを表すと説明されています。
• 86% は、ステートメント5つと分岐2つのうち、通った6つの割合（6 ÷ 7）です。coverage.py は --branch のとき、分岐の割合も合計のカバー率に含めます。
• テストの組 b・c・d は、どれもブランチ 100% でした。coverage.py では、b と d の差（条件・MC/DC）は見えません。

coverage report --fail-under=100 を付けると、基準に届かないときにコマンドが失敗します。テストの組 a では「Coverage failure: total of 86 is less than fail-under=100」と表示され、終了コードは 2 でした。CI で基準を割ったときに止めるのに使えます。pytest とカバレッジの設定は、関連記事「pytest 使い方｜導入からfixture・mock・カバレッジまで実行結果つき」で扱っています。

条件カバレッジと MC/DC を数える

条件カバレッジは「各条件が真と偽の両方をとったか」、MC/DC は「各条件が、ほかの条件を変えずに、それだけで判定の結果を変えられることを示したか」を見ます。 次のスクリプトで、真理値表から数えました。

from itertools import product, combinations

def dec(a, b, c):           # a=is_member, b=total>=5000, c=has_coupon
    return a and (b or c)

def decision_cov(ts):  return {dec(*t) for t in ts} == {True, False}
def condition_cov(ts): return all({t[i] for t in ts} == {True, False} for i in range(3))
def mcdc(ts):
    if not (decision_cov(ts) and condition_cov(ts)):
        return False
    for i in range(3):     # 条件 i だけが違い、判定の結果も違う2件があるか
        if not any(all(x[j] == y[j] for j in range(3) if j != i)
                   and x[i] != y[i] and dec(*x) != dec(*y)
                   for x, y in combinations(ts, 2)):
            return False
    return True

ALL = list(product([True, False], repeat=3))
for name, f in [("判定", decision_cov), ("条件", condition_cov), ("MC/DC", mcdc)]:
    k = next(k for k in range(1, 9) if any(f(list(s)) for s in combinations(ALL, k)))
    print(name, "の最小件数:", k)

判定 の最小件数: 2
条件 の最小件数: 2
MC/DC の最小件数: 4

テストの組 d（4件）が MC/DC を満たす理由は、次の3つのペアがあるからです。

テストの組 c（TTT・FFF）は、条件カバレッジは満たしますが、MC/DC は満たしません。 たとえば has_coupon を False に固定する誤りがあっても、TTT は total >= 5000 が真なので送料0のまま、FFF は is_member が偽なので送料500のままで、どちらのテストも通ってしまいます。実際に has_coupon を False に置き換えた関数で試すと、テストの組 c の2件は期待どおりの値を返し、テストの組 d では TFT（期待は送料0）が送料500になって、誤りが見つかりました。

注意：Python の and・or は「短絡評価」です。 左の条件で結果が決まると、右の条件は評価されません。FFF では is_member が偽なので、total >= 5000 と has_coupon は実際には評価されません。上の表は、真理値表の上で数えたものです。実際に評価された値で数えると、テストの組 c では has_coupon が一度も評価されず、条件カバレッジも満たしません。MC/DC が求められる分野では、短絡評価を考えたツールで測ります。

MC/DC は、NIST の用語集で「米国連邦航空局（FAA）が求める強いカバレッジ基準」と説明されています。 条件が n 個のとき、すべての組み合わせ（2^n 件）より少ない件数（この例では 8件ではなく4件）で、各条件が効いていることを示せるのが利点です。

経験ベースの技法

経験ベースの技法は、仕様から作ったテストの「すき間」を埋めるために使います。 シラバスでは、エラー推測を体系的に行う方法として「フォールトアタック」（起こりそうな誤りのリストを作り、それを起こすテストを設計する）が挙げられています。

エラー推測のリスト（システム開発の例）

過去のバグ報告から、このリストを増やしていくと、チームの「よくある誤り」が分かります。バグの記録の項目は、関連記事「バグ管理表の項目とテンプレート｜優先度・重要度とステータス遷移」で扱っています。

探索的テストのチャーター（テンプレート）

探索的テストは、テストの設計・実行・評価を同時に進めながら、対象について学んでいくテストです。 シラバスでは、時間を区切った「セッション」で行い、目的を書いた「テストチャーター」を指針にして、終わったあとに振り返る（デブリーフィング）進め方が紹介されています。

## 探索的テスト チャーター

- 対象：注文の確定画面（v2.3 の変更分）
- 目的：決済サービスが遅いとき・失敗したときの注文の状態を探る
- 時間：60 分
- 使うもの：テスト用カード（承認・拒否・遅延）、管理画面
- 見るところ：二重決済、在庫の戻し、画面に出るメッセージ

### 記録（終わったあとに書く）
- 試したこと：
- 見つかった不具合：（バグ報告の番号）
- 気になったこと・次に試すこと：

見つかった不具合の書き方は、関連記事「バグ報告の書き方｜コピペ用テンプレートと重大度判定表」で扱っています。

テスト技法の選び方

選ぶときは「対象の特徴」から考えます。 1つの機能に、複数の技法を組み合わせることがほとんどです。

flowchart TD
  q0{仕様書に入力と出力が書かれているか}
  q0 -- いいえ --> x1[探索的テスト・エラー推測で試し、<br>分かったことを仕様に戻す]
  q0 -- はい --> q1{入力に範囲や区分があるか}
  q1 -- はい --> t1[同値分割法＋境界値分析]
  q1 -- 続けて確かめる --> q2{複数の条件の組み合わせで<br>結果が決まるか}
  q2 -- はい・ルールが決まっている --> t2[デシジョンテーブル]
  q2 -- はい・独立した条件が多い --> t3[ペアワイズ]
  q2 -- 続けて確かめる --> q3{状態や順番で<br>動きが変わるか}
  q3 -- はい --> t4[状態遷移テスト]
  q3 -- 続けて確かめる --> q4{業務の流れとして<br>確かめるか}
  q4 -- はい --> t5[ユースケーステスト]
  t1 & t2 & t3 & t4 & t5 --> w1[コードのカバレッジを測り、<br>通っていない分岐を確かめる]
  w1 --> e1[エラー推測・探索的テストで<br>すき間を埋める]

修正後に流すテストの範囲は、関連記事「リグレッションテストの範囲の決め方｜影響範囲の調べ方」で扱っています。

テストレベルとの対応

単体テストと結合テストの違いは、関連記事「単体テストと結合テストの違い｜pytestの実例と実行結果で比較」で扱っています。

よくある質問

Q. カバレッジは何%を目標にすればよいですか。 A. 目標の値は、対象の重要さに合わせてプロジェクトで決めます。この記事の例のように、ステートメント 100% でも分岐の片方を通っていないことがあるため、目標は「ブランチカバレッジで何%」と種類まで決めておくと、意味がそろいます。

Q. ブラックボックスとホワイトボックスは、どちらを先にやりますか。 A. 多くは、仕様からブラックボックスでテストケースを作り、実行したあとにカバレッジを測って、通っていない分岐をホワイトボックスの観点で足します。仕様から作ったテストで通らない分岐は、「仕様の漏れ」か「要らないコード」のどちらかであることが多く、確かめる価値があります。

Q. 探索的テストと、手当たり次第のテスト（アドホックテスト）は違いますか。 A. 探索的テストは、チャーターで目的と時間を決め、試したことと見つかったことを記録します。記録があるので、何を確かめたかを後で説明できます。

Q. テストケースの作成に生成AIを使えますか。 A. 技法の名前と条件を指示すると、下書きは作れます。ただし、境界の値や組み合わせが正しいかは、この記事のスクリプトのような方法で確かめます。関連記事「生成AIでテストケースを作るプロンプト集｜同値分割・境界値対応」で扱っています。

まとめ

• テスト技法は ブラックボックス・ホワイトボックス・経験ベース の3つに分かれる
• ブラックボックスは 同値分割・境界値・デシジョンテーブル・状態遷移・ペアワイズ・ユースケース。対象の特徴で選び、組み合わせる
• カバレッジは ステートメント ＜ ブランチ ＜ 条件/判定 ＜ MC/DC ＜ 複数条件 の順に厳しい。例では 1件でステートメント 100%、ブランチは 86%、MC/DC は 3条件で最小4件
• coverage.py で測れるのは ステートメントとブランチまで。条件・MC/DC は別の方法で確かめる
• 経験ベースの エラー推測・探索的テスト で、仕様から作ったテストのすき間を埋める

参考・出典

確認日はいずれも 2026年10月12日です。

• JSTQB「テスト技術者資格制度 Foundation Level シラバス Version 4.0」：https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf
• ASTQB「CTFL v4.0 Chapter 4: Test Analysis and Design」：https://study.astqb.org/?p=22
• coverage.py 7.16.2「Branch coverage measurement」：https://coverage.readthedocs.io/en/latest/branch.html
• NIST CSRC Glossary「modified condition decision coverage」：https://csrc.nist.gov/glossary/term/modified_condition_decision_coverage

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。