テストマトリクスとは？作り方・サンプル表とパターン表の書き方

テストマトリクスとは、テスト対象とテスト観点、またはテスト条件とテストケースを縦横の表で交差させ、「どこを・どの観点で・どの組み合わせまで」テストするかを一枚で見えるようにするドキュメントです。交点の記号でテストの要否や選択する条件を示し、対応するケースの実施状態も記録すれば、実施済みと未実施の範囲を区別できます。この記事では、対象×観点の「観点マトリクス」と、条件×ケース番号の「パターン表」の2つの型を実物の表で示し、作り方の手順、記入漏れと組み合わせの抜けを機械的に見つける方法、観点の決め方、ケースを減らす下限までを順に扱います。

まとめ：テストマトリクスの要点

• テストマトリクスには2つの型がある。行に対象・列に観点を置く「観点マトリクス」は網羅状況の管理に、行に条件と値・列にケース番号を置く「パターン表」は組み合わせテストの設計に使う。
• 作り方は「テスト対象の洗い出し → テスト観点の決定 → セル記入 → レビューと更新」の4ステップ。1つの用途に1枚を守ると見やすさが保てる。
• パターン表は1列が1テストケースになる。粒度の大きい条件を上、小さい条件を下に並べ、記号は「左上から右下へ」流れるように置くと記入漏れが目で追える。
• 記入漏れ（ある列で1つの条件に記号が無い）と未網羅の組み合わせは、表をCSVで書き出せば掲載のPythonスクリプトで検出できる。
• 観点列に迷ったら、2025年12月22日に改正されたJIS X 25010:2025の9つの品質特性を出発点にする。
• 組み合わせが爆発するときはペアワイズ法で削減する。3因子3水準なら全27通りが9通りまで縮み、8通り以下では全ペアを網羅できない。ただしNISTの実測では、NASAのアプリケーションで2因子までに収まった不具合は93%だった。

テストマトリクスの定義と2つの型（観点マトリクスとパターン表）

テストマトリクス（テストマトリックス、マトリクス表とも呼ばれます。英語では test matrix）は、二次元の表で網羅性を管理するテスト設計ドキュメントです。この記事では、軸の取り方が異なる「観点マトリクス」と「パターン表」の2つを取り上げます。検索で見つかる解説の説明が食い違って見えるのは、どちらの型を指しているかが書き手によって違うためです。

観点マトリクス：対象×観点で網羅状況を見る表

行にテスト対象、列にテスト観点（正常系・異常系・境界値・ブラウザ差など）を並べ、交点にそのテストの要否を書きます。セルの記号は●（必須）、△（任意）、×（対象外）のように3種類ほどに絞ると、状況把握が速くなります。この記号だけでは実施済みかどうかは分かりません。例えばログインIDの「未入力」に●を付けたら、対応するケース番号と実施状態を別欄で管理します。

パターン表：条件×ケース番号で組み合わせを決める表

行に条件（会員種別、支払方法など）とその値（一般・会員・法人など）を並べ、列にケース番号を振ります。各列で、条件ごとに選ぶ値へ●を1つ付けると、その列がそのまま1件のテストケースになります。チェックボックスの組み合わせや検索条件の組み合わせなど、単体テストで入力の組み合わせを確かめるときに使われるのはこちらの型で、「パターン表」「組み合わせ表」とも呼ばれます。

テストマトリクスを使う目的とメリット・デメリット

最大の目的は網羅性の可視化です。どの対象がどの観点で、どの条件の組み合わせがどのケースでテストされているかを一覧にすると、抜けている部分が表の空白として現れます。口頭やテストケースの羅列では追えなくなる規模の開発ほど、この効果が大きくなります。

メリットは網羅性の確認に加え、進捗管理（実施・未実施・失敗をセルの色で管理）、関係者間の共通認識、レビュー時の議論の土台と広がります。一方でデメリットは更新コストに集中します。仕様変更が多い開発では最新化が後回しになりやすく、肥大化すると全体像がかえって見えなくなります。運用を始めるときは、まず網羅状況の確認に用途を絞り、仕様変更時の更新担当と更新時期を決めます。表の維持にかかる工数も見積もり、運用を続けられる範囲に分割します。

テストマトリクスの作り方【4ステップ】

観点マトリクスもパターン表も、組み立ての順序は同じです。要件定義書や画面設計書を手元に置き、次の順で進めます。

ステップ1：テスト対象の洗い出し

最初に、テストすべき対象を漏れなく列挙します。要件定義書・仕様書・画面設計書・フローチャートを確認し、機能や画面、入力項目を粒度をそろえて並べます。ここで対象が曖昧だと表全体の精度が崩れるため、機能No・画面No・項目Noのように識別番号を振り、どの機能のどの項目かを後から追える形にしておきます。項目数が数百を超える表では、この番号列がフィルタと集計の軸になります。

ステップ2：テスト観点の決め方（正常系・異常系・境界値）

次に、各対象を「どの切り口で見るか」を決めます。観点が「入力チェック」のように抽象的だとテストケースに落とせないので、「未入力」「最大長超過」「禁止文字」「形式違い」のように具体化します。代表的な観点は正常系・異常系・境界値・状態遷移・権限差・ブラウザやデバイス差です。確認観点や試験観点と呼ばれることもありますが、要は「対象ごとに何を見れば品質を保証できるか」を分類する作業です。観点の定義はチームで統一し、用語の揺れをなくしておきます。観点そのものの決め方は後述の観点表の章で扱います。

ステップ3：Excel・スプレッドシートでのセル記入

テストマトリクスはExcelやGoogleスプレッドシートで作るのが一般的です。行と列を配置し、交点のセルに記号を入れていきます。実施状態は「未実施・成功・失敗・対象外」を色分け（成功＝緑、失敗＝赤、未実施＝黄）すると、進捗が一目で読み取れます。条件付き書式を使えば入力に応じて自動で色が変わり、見出し行と見出し列を固定すればスクロールしても軸を見失いません。記号を付ける列の幅はできるだけ狭くし、100%表示で横スクロールせずに見渡せる幅に収めると、レビューで見落としが減ります。

ステップ4：レビューと更新ルールの設計

作ったら必ずレビューにかけ、観点の漏れ・重複、粒度のばらつき、命名の不統一を開発者とテスト担当の両方の目で確認します。さらに重要なのが更新ルールです。仕様変更が起きたときに「誰が・いつ・どこを直すか」を決め、変更履歴を残します。Googleスプレッドシートなら変更履歴が自動で残り、Excelで管理するならファイルをGitのリポジトリに置いてチケット番号付きでコミットすると、どの仕様変更で列が増えたかを後から追えます。更新が止まったマトリクスは、実装とずれた瞬間に信頼性を失います。改修が続くシステムで、マトリクスの更新と回帰テストを開発チームと一緒に回す体制づくりは、保守運用・内製化支援でも扱っています。

観点マトリクスのサンプル（ログイン画面の例）

ログイン機能を例にした最小のサンプルです。行が入力項目、列が観点、セルがテストの要否です（●＝必須、△＝任意、×＝対象外）。

この一枚で、「ログインボタンのブラウザ差はテスト対象だが、パスワードのブラウザ差は任意」といった判断が共有できます。テストの要否は空欄にせず、対象外も×で明示します。空白を「要否が未判断」と「対象外」の両方に使わず、実施済みかどうかは対応するケースの実施状態で管理します。

パターン表の書き方とサンプル（組み合わせテストの例）

パターン表は、条件が複数絡む入力の組み合わせを、どのケースでどの値を選ぶかまで決めるための表です。観点マトリクスより記入量が多く、記号の付け忘れが起きやすい型なので、書き方の規則を決めてから埋めます。

購入画面のパターン表サンプル：因子・水準と9ケース

ECサイトの購入画面で、会員種別（一般・会員・法人）、支払方法（クレジット・コンビニ・電子マネー）、端末（PC・スマホ）の3条件を確かめる例です。総当たりなら 3×3×2＝18通りですが、どの2条件の組み合わせも最低1回は現れる9通りに絞っています（絞り方は後述のペアワイズ法の章で扱います）。

列を縦に読むと、No.1は「一般・クレジット・PC」、No.9は「法人・電子マネー・PC」というテストケースになります。観点マトリクスと違い、パターン表のセルの空白は「その値を選ばない」という意味なので、×で埋める必要はありません。代わりに、各列で条件ごとに●がちょうど1つあることが正しさの条件になります。

記入漏れを防ぐ並べ方のルール

条件ごとにケースをまとめて並べると、記号の抜けやずれを目視で確認しやすくなります。並べ方とシート分割の規則は次の4つです。

• 粒度の大きい条件を上（または左）に、細かい条件を下（または右）に置く。上の条件でケースの塊が決まり、下の条件で塊の中を割る形になる。
• ケース番号は、上の条件の値が切り替わる順に振る。サンプルのように●が左上から右下へ階段状に流れるので、1つ抜けたりずれたりすると目で分かる。
• テキストボックスの入力値チェックとチェックボックスの組み合わせ確認のように、見たいものが違う表は1枚に混ぜずシートを分ける。混ぜると、片方にしか関係しない行が大量の空白になる。
• 大分類・機能No・画面No・項目Noの列を左端に持ち、フィルタで画面単位・機能単位に絞れるようにする。実施状況の集計もこの列で行う。

パターン表をテストケースに落とす手順

パターン表が完成したら、1列を1件のテストケースとしてテストケース表（テスト仕様書）に書き写します。ケース番号はそのまま引き継ぎ、選んだ値を前提条件と入力値の欄に書き、仕様書から導いた期待値を期待値の欄に対応付けます。期待値が不明な組み合わせは、ケースを確定する前に仕様を確認します。条件の組み合わせごとにシステムの動作を定めること自体が目的なら、パターン表ではなく後述のデシジョンテーブルで条件と動作を対にして整理します。

記載例（説明用の仮仕様）として、サンプルのNo.1は「一般・クレジット・PC」です。前提条件は購入可能な商品がカートにあること、操作は一般利用者としてPCから有効なカード情報を入力して購入を確定すること、期待結果は注文が1件作成され注文番号が表示されることです。実案件の期待結果は仕様書に合わせます。

Pythonによるパターン表の記入漏れ・ペア網羅チェック

パターン表の目視レビューで見落としやすいのは、「ある列で1つの条件に●が無い」記入漏れと、「ある2条件の値の組み合わせがどの列にも出てこない」網羅の抜けです。表をCSVで書き出せば、どちらも機械的に見つけられます。上のサンプルを、1行目にケース番号を持つ次の形で保存します。

因子,水準,1,2,3,4,5,6,7,8,9
会員種別,一般,●,●,●,,,,,,
会員種別,会員,,,,●,●,●,,,
会員種別,法人,,,,,,,●,●,●
支払方法,クレジット,●,,,●,,,●,,
支払方法,コンビニ,,●,,,●,,,●,
支払方法,電子マネー,,,●,,,●,,,●
端末,PC,●,,●,,●,,●,,●
端末,スマホ,,●,,●,,●,,●,

CSVをpattern.csv、次のスクリプトをcheck_pattern.pyとしてUTF-8で保存し、同じフォルダで「python3 check_pattern.py pattern.csv」を実行します。Python 3.6以降の標準ライブラリだけで、記入漏れ・二重記入と未網羅ペアを確認できます。

import csv, sys
from itertools import combinations

def load(path):
    with open(path, encoding="utf-8") as f:
        rows = list(csv.reader(f))
    case_ids = rows[0][2:]
    if not case_ids or any(not cid.strip() for cid in case_ids):
        raise ValueError("ケース番号が空です")
    if len(set(case_ids)) != len(case_ids):
        raise ValueError("ケース番号が重複しています")
    levels = {}
    cases = {cid: {} for cid in case_ids}
    for row_no, row in enumerate(rows[1:], start=2):
        if len(row) != len(case_ids) + 2:
            raise ValueError(f"{row_no}行目: 列数がヘッダーと一致しません")
        factor, level, *marks = row
        levels.setdefault(factor, []).append(level)
        for cid, mark in zip(case_ids, marks):
            if mark.strip() == "●":
                if factor in cases[cid]:
                    raise ValueError(f"No.{cid}: {factor} に●が複数あります")
                cases[cid][factor] = level
    return levels, cases

levels, cases = load(sys.argv[1])
for cid, case in cases.items():
    for factor in levels:
        if factor not in case:
            print(f"No.{cid}: {factor} が未記入")

missing = []
for f1, f2 in combinations(levels, 2):
    seen = {(c.get(f1), c.get(f2)) for c in cases.values()}
    for l1 in levels[f1]:
        for l2 in levels[f2]:
            if (l1, l2) not in seen:
                missing.append(f"{f1}={l1} x {f2}={l2}")

print(f"ケース数 {len(cases)} / 未網羅ペア {len(missing)}")
for m in missing:
    print("  ", m)

サンプルのCSVを渡すと「ケース数 9 / 未網羅ペア 0」と出ます。試しにNo.9の列を削って8ケースにすると、出力は次のように変わります。

ケース数 8 / 未網羅ペア 1
   会員種別=法人 x 支払方法=電子マネー

No.2の「スマホ」の●を消した場合は、「No.2: 端末 が未記入」と、それによって生じた「会員種別=一般 x 端末=スマホ」の未網羅が両方出ます。数百列のパターン表をレビューで1セルずつ追うより、レビュー前にこのチェックを通しておく方が確実です。なお、このスクリプトはCSVに記載された全水準の組み合わせが有効であることを前提に、2条件の組み合わせまでを確認します。業務上禁止される組み合わせを除外する制約処理は含みません。3条件以上の組み合わせが効く領域は、後述の「ペアワイズ法（オールペア法）によるケース削減」で説明する残存リスクを踏まえて判断してください。

テスト観点表の作り方と観点列の決め方

観点マトリクスの精度は、列に何を並べるかで大きく変わります。対象は仕様書の機能一覧や画面一覧から拾えますが、観点の一覧は仕様書に無いことが多く、担当者の経験に加えて品質モデルや過去の不具合記録から洗い出します。ここを個人の記憶に任せないための土台が、観点だけを一覧化したテスト観点表です。

JIS X 25010:2025の9つの品質特性と観点列の骨格

観点を思いつきで並べると、機能の正常系・異常系ばかりが厚くなり、性能や互換性が丸ごと落ちます。これを防ぐ最短路は、国際規格の品質特性を列の骨格に借りることです。ISO/IEC 25010は2023年11月に第2版が発行され、製品品質モデルを9つの品質特性（characteristics）で定義しています。国内規格もこれに追随し、JIS X 25010は2025年12月22日付でJIS X 25010:2025へ改正され、2013年版から置き換えられました（官報掲載日：令和7年12月22日）。

改正で変わった点は観点表にそのまま影響します。JIS X 25010:2025の序文によると、安全性が品質特性として追加され、副特性に運用制約性・リスク識別性・フェールセーフ・危険警告性・統合時安全性が置かれました。また使用性はインタラクション容易性（対話性）へ、移植性は柔軟性へ置き換えられています。2013年版の8特性で作った観点表をそのまま使っていると、安全性の列が存在しないことになります。

9列すべてを毎回使う必要はありません。互換性と柔軟性を同じ列で管理する場合も、他製品との共存・情報交換と、環境変化への適応は分けて確認します。安全性の要否は金銭の取扱いではなく、人命・健康・財産・環境への危険を評価して決めます。規格を使う狙いは列を増やすことではなく、「今回は落とす」という判断を意識的に下せる状態を作ることです。落とした列と理由をシートの隅に書いておけば、レビューでの説明がそのまま済みます。

観点表からテストマトリクスへ落とし込む手順

観点表とテストマトリクスは別物です。観点表は「見るべき切り口の辞書」で、対象を持ちません。テストマトリクスは、その辞書から今回の対象に効く観点だけを選んで列に並べた実装です。観点表は共通部分と業務・製品固有の部分を分けて管理し、案件ごとに必要な観点を選んでマトリクスを作成します。

抜き出すときの判断軸は対象の性質です。入力項目が行なら未入力・桁数超過・禁止文字が効き、画面遷移が行なら状態遷移・戻る操作・多重送信が効きます。ここを機械的に全列コピーすると、×で埋まった無意味なセルが増え、後述の形骸化に直行します。

なお、観点の網羅とテスト量の妥当性は別の問題です。テスト件数の妥当性を検討する際は、IPAが公開する実績データを参考にできます。ただし、工程・規模の測定方法・開発種別などの条件をそろえて比較し、一律の合否基準にはしません。テスト密度・バグ密度の目安はバグ密度・テスト密度の目安｜IPA基準値・品質指標値と計算式、ゾーン分析で整理しています。

テストパターンの洗い出しと削減（組み合わせ爆発への対処）

パターン表が本領を発揮するのは、条件が複数絡んでテストパターンが膨れ上がる場面です。ここを設計せずに総当たりすると、工数が現実的でなくなります。

実行環境4因子による300通りの組み合わせ

先のサンプルは3条件で18通りでしたが、条件が1つ増えるたびに掛け算で膨らみます。実行環境の組み合わせはその典型で、Google Cloudのgcloud firebase test android run のリファレンスには、端末5機種・OSバージョン6種・ロケール5種・画面の向き2種を指定すると、合計300件の実行候補からなる test matrix が生成される例が載っています。ただし、実際に実行されるのは端末とOSなどの組み合わせが有効なものだけです。300ケースを手作業で実行できるかは、1件あたりの所要時間と担当人数、期限によって変わります。まず因子・水準・制約と総ケース数を整理し、必要に応じて削減します。

洗い出し技法の選び分け（同値分割・境界値分析・状態遷移）

「テストパターンをどう洗い出すか」に単一の答えはありません。何を減らしたいかで使う技法が変わります。入力値の個数なら同値分割と境界値分析、条件分岐の漏れを防ぐならデシジョンテーブル、画面や業務のフローなら状態遷移テスト、因子の組み合わせ数そのものを削るならペアワイズ法です。

同値分割は同じ挙動になる入力をひとまとめにして代表値だけを取る考え方、境界値分析は順序付けできる同値パーティションの境界とその隣接値を選ぶ考え方（1〜5を受け付ける項目なら0・1・5・6）で、いずれもブラックボックステストの基本技法です。技法の位置づけはブラックボックステストとホワイトボックステストの違い｜技法・カバレッジ基準・使い分けで整理しています。パターン表の「値」の行は、同値分割と境界値分析で選んだ代表値にしておくと、なぜその値を選んだかを説明する手間が減ります。

ペアワイズ法（オールペア法）によるケース削減【27通りが9通りへ】

ソフトウェアの不具合の多くは、1つまたは2つの因子の組み合わせで起きます。これは調査対象の障害データから得られた経験則で、米国国立標準技術研究所（NIST）のSP 800-142 Practical Combinatorial Testing（Kuhn・Kacker・Lei、2010年10月）は次のように定式化しています。

「Interaction Rule: Most failures are induced by single factor faults or by the joint combinatorial effect (interaction) of two factors, with progressively fewer failures induced by interactions between three or more factors.（ほとんどの障害は単一因子の欠陥か、2因子の組み合わせ効果によって引き起こされ、3因子以上の相互作用による障害は段階的に少なくなる）」

この法則を根拠に、すべての2因子ペアの水準組み合わせを最低1回ずつ網羅することで、全組み合わせより少ないケースで2因子間の網羅性を確保するのがペアワイズ法（オールペア法）です。ただし、その網羅基準が対象システムに十分かは別に判断します。3因子3水準のケースなら、全組み合わせ27通りが9通りまで減ります。

この9通りという数字は、次のコードで確認できます。網羅すべき2因子ペアは全27組で、L9直交表の構成（第3因子を第1・第2因子の和の剰余で決める）はそれを過不足なく覆います。

from itertools import product, combinations

levels = [0, 1, 2]
factors = 3
all_cases = list(product(levels, repeat=factors))

def pairs_of(case):
    return {(i, j, case[i], case[j]) for i, j in combinations(range(factors), 2)}

target = set()
for case in all_cases:
    target |= pairs_of(case)

l9 = [(a, b, (a + b) % 3) for a in levels for b in levels]
covered = set()
for case in l9:
    covered |= pairs_of(case)

print(len(all_cases), len(l9), covered == target)

実行結果は「27 9 True」です。任意の2因子だけに注目しても3×3＝9組の水準ペアがあり、1ケースで覆えるのはそのうち1組なので、全ペアの網羅には少なくとも9ケース必要です。つまり3因子3水準では9本が下限で、それ以上削ると必ずどこかのペアが未検証になります。削減目標を立てるときは、この下限を割り込んでいないかを確認してください。

ここで注意したいのが、ペアワイズを万能視しないことです。同じNISTの文書は、NASAのアプリケーションでは単一因子で67%、2因子までで93%、3因子までで98%の不具合が検出できたと報告し、「pairwise testing is not sufficient（ペアワイズテストは十分ではない）」と明記しています。同じ文書の要旨は、ペアワイズテストが「may miss 10% to 40% or more of system bugs（システムの不具合の10%から40%以上を見逃し得る）」とし、ミッションクリティカルなソフトウェアには十分でないと述べています。2因子まででは検出できない障害の割合は対象によって異なるので、決済や権限のように失敗コストが高い領域では、その残存リスクを評価する必要があります。リスクの高い因子群だけは3因子まで網羅する、といった使い分けが現実解です。

似た技法に直交表がありますが、強さ2の直交表が任意の2因子の水準の組み合わせを同じ回数ずつ出現させるのに対し、ペアワイズは各組み合わせが1回以上現れることを求めます。3因子3水準では直交表（L9）も9通りで同数です。因子や水準が増えるとペアワイズの方がケース数は少なくなるとされますが、実際の削減幅は因子構成に依存するのでツールで生成して確かめてください。定番はマイクロソフトが公開するPICT（Pairwise Independent Combinatorial Tool）で、GitHub APIで2026年10月に確認した時点では、最新リリースはv3.7.4（2022年3月31日公開）で、リリースは古いもののリポジトリには2026年9月にもpushがあり、アーカイブされていません。生成した組み合わせをパターン表に写したら、前章のスクリプトで未網羅ペアが0であることを確かめておくと、写し間違いも同時に検出できます。

削減してよいケースの線引き

削減には品質リスクが伴います。線引きの基準は、利用頻度・障害が起きたときの影響度・変更の入りやすさです。決済や管理者権限の変更など、障害の影響が大きい組み合わせは利用頻度が低くても残します。削減候補は、利用実績と障害影響の両方を確認し、サポート対象や要求された網羅基準に反しないものから選びます。そして削ったケースは「なぜ外したか」を、パターン表の備考列に記録します。後の見直しや、外部レビューで判断の根拠を示すときに、この記録が効いてきます。

テストマトリクスと他のテスト設計手法の違い

「マトリクス」と名の付く表は複数あり、混同されがちです。デシジョンテーブル、トレーサビリティマトリクス、テスト観点表、テストマップは、整理する軸も目的も別物です。

デシジョンテーブル（決定表）は、条件の組み合わせとそのときの動作を表にしたもので、仕様の分岐ロジックを漏れなく確認するために使います。パターン表が「どの組み合わせを試すか」を決めるのに対し、デシジョンテーブルは「ある条件群でシステムがどう振る舞うべきか」を定義します。入力の組み合わせを選ぶ目的ならパターン表、対象と観点の対応を管理する目的なら観点マトリクスを使います。期待値が可否の2値でも、複数条件による判定規則を整理するならデシジョンテーブルが向きます。トレーサビリティマトリクス（RTM）は、要求と設計・コード・テストケースの対応を追跡し、仕様変更の影響範囲を押さえる表です。いずれもテストマトリクスの代わりではなく、目的に応じて併用するものと捉えると整理がつきます。

テストの種類そのものを整理したいなら、実行を伴わない検証との対比も押さえておくと選択を誤りません。コードを動かさずに欠陥を見つける手法との違いは静的テストとは？レビューと静的解析の違い・動的テストとの使い分けを比較で扱っています。

テストマトリクスが向かない場面と失敗パターン

テストマトリクスは万能ではありません。次の場面では、無理に使うとかえって品質管理を鈍らせます。

第一に、用途が異なる表の混在を避け、前述の並べ方のルールに従ってシートを分けます。第二に、条件分岐そのものの仕様確認が目的なら、デシジョンテーブルを選びます。第三に、更新体制を用意できないプロジェクトでの運用は避けます。直す担当とルールがないと、表はすぐ実装とずれ、形だけ残って誰も見ない資料になります。

第四に、自動テストが主戦場になっている開発では、マトリクスの守備範囲を意識的に狭めるべきです。テストコードそのものが実行可能な網羅の記録になるため、同じ内容を表でも管理すると二重メンテナンスになります。この場合は、テストコードから得られるケース一覧や実行結果を再利用し、マトリクスでは要求・観点との対応や未自動化の範囲など、コードだけでは追いにくい情報を管理します。テスト全体の配分をどう考えるかはTesting Trophy（テスティングトロフィー）とは？Kent C. Doddsの4層とテストピラミッドとの違いが参考になります。

粒度をそろえ、用途を絞り、更新し続けられる範囲で作る。この三点を守れないなら、チェックリストなど軽い手段に切り替えた方が実務は回ります。

よくある質問（FAQ）

テストマトリクスとテストケースの違いは？

テストケースは「特定の条件で何を入力し、どんな結果を期待するか」を記した個別の手順書です。テストマトリクスは、それらのケースがどの対象・どの観点・どの組み合わせに対応しているかを俯瞰する一覧表です。マトリクスで網羅すべき範囲を設計し、パターン表なら1列ずつ、観点マトリクスなら1セルずつ中身を具体化したものがテストケース、という関係になります。

テストマップとテストマトリクスは何が違いますか？

テストマップは観点や機能の関連を階層的に描いた地図で、テスト分析の段階で「何を考えるべきか」を広げるために使います。テストマトリクスは、広げ終わった観点を対象と掛け合わせて「どこまでやるか」を決める表です。マップで発散させ、マトリクスで収束させる、と順序で捉えると使い分けを間違えません。

結合テストでもテストマトリクスは使える？

使えます。単体テストでは機能や画面の項目を対象に取りますが、結合テストでは「連携する機能の組み合わせ」や「データの受け渡し経路」を対象に置き換えれば、同じ構造で網羅を管理できます。テストレベルごとの考え方は単体テストと結合テストはもう古い？Google流「テストサイズ」とは（Small/Medium/Large）もあわせて参考にしてください。

Excelのテンプレートはどう作る？

1枚目にテスト対象の一覧、2枚目に観点の一覧を置き、3枚目で両者を掛け合わせたマトリクスを作る構成が扱いやすいです。パターン表を使う場合は、用途ごとに4枚目以降へ分けます。状態管理用のプルダウン（未実施・成功・失敗・対象外）と条件付き書式での色分けを入れておくと、進捗の集計まで一つのファイルで完結します。2枚目の観点一覧を案件間で使い回す前提にすると、テンプレートとしての価値が出ます。

英語の test matrix も同じ意味ですか？

重なりますが、英語圏では要件とテストケースの対応表や、ブラウザ・OS・端末の組み合わせ表を指すことが多く、日本の「対象×観点」の表より範囲が広い言葉です。クラウドのテストサービスでは別の意味でも使われ、Firebase Test Labでは指定した端末・OS・ロケールの組み合わせから生成される一連のテスト実行の単位を test matrix と呼びます。英語の資料を読むときは、どの軸の表を指しているかを先に確かめると混乱しません。

関連記事

• ブラックボックステストとホワイトボックステストの違い｜技法・カバレッジ基準・使い分け
• バグ密度・テスト密度の目安｜IPA基準値・品質指標値と計算式、ゾーン分析
• 静的テストとは？レビューと静的解析の違い・動的テストとの使い分けを比較
• 単体テストと結合テストはもう古い？Google流「テストサイズ」とは（Small/Medium/Large）
• Testing Trophy（テスティングトロフィー）とは？Kent C. Doddsの4層とテストピラミッドとの違い