このページでは、同値分析・限界値分析などのブラックボックステスト、命令網羅・条件網羅とサイクロマチック数、ドライバとスタブを使う結合テストがわかります。
- 一言で言うと：
- プログラムが仕様どおりに動くかを確かめるために、テストケースをどう作るかと、モジュールをどの順でつないでテストするかの話
- 中身を見ないで作るのがブラックボックステスト、中身（論理）を見て作るのがホワイトボックステスト
中を見ないで確かめる（ブラックボックステスト）→ 中を見て確かめる（ホワイトボックステスト）→ つなぎながら確かめる（モジュール集積テスト技法）→ その他のテスト
覚え方の軸
- テストケースの作り方は「中を見るか、見ないか」の2つ
- ブラックボックステストは、中を見ない。外部仕様から作る（入力に対して正しい出力が出るか）
- ホワイトボックステストは、中を見る。内部の論理構造（制御の流れ）から作る
- ブラックボックスの4つは「何を工夫するか」で分ける
- どの値を選ぶかは、同値分析（グループの代表）と限界値分析（グループの端）
- 条件の組合せをどう整理するかは、原因結果グラフ（→ デシジョンテーブル）
- 組合せの数をどう減らすかは、実験計画法（直交表）
- ホワイトボックスの網羅は「判定（分岐の結果）」と「条件（判定の中の部品）」のどちらを真偽にするか
- 弱い順に、命令網羅 → 判定条件網羅（分岐網羅）→ 条件網羅 → 判定条件／条件網羅 → 複数条件網羅
- 判定条件網羅は「判定」の真偽、条件網羅は各「条件」の真偽、複数条件網羅は「条件の全組合せ」
- 結合テストは「どっちから積むか」で、代わりの部品が決まる
- 下から積む（ボトムアップ）なら、上の代わりのドライバ（呼び出す側）
- 上から積む（トップダウン）なら、下の代わりのスタブ（呼び出される側）
- その他のテスト（システム結合テストなど）は、V字モデルの右側に並ぶ
- システム結合テストはシステム方式設計と、システム適格性確認テストはシステム要件定義と対になる
前置き：テスト手法の全体像
| 分類 | 別名 | 手法 |
|---|---|---|
| ブラックボックステスト | 機能テスト | 同値分析、限界値分析、原因結果グラフ、実験計画法 |
| ホワイトボックステスト | 構造テスト | 命令網羅、判定条件網羅、条件網羅、判定条件／条件網羅、複数条件網羅 |
ブラックボックステスト：中を見ないで、仕様から確かめる（★）
- ブラックボックステスト（機能テスト）：
- プログラムの内部構造や論理構造には一切着目しない。プログラムをブラックボックス（中の見えない箱）と考える
- 外部仕様に基づいてテストケースを作り、入力に対して正しい出力が得られるか（機能）に着目してテストする
- ブラックボックステストの短所：
- プログラムに冗長なコード（むだなコード）があっても、それを見つけられない
- ブラックボックステストの使いどころ：
- 単体テストからシステムテストまで、すべてのテスト工程で使える
- ユーザの立場から見た機能のテストに向いている
- ブラックボックステストの例え：
- 自動販売機に、お金を入れてボタンを押し、正しいジュースが出るかだけを見る。中の機械の仕組みは見ない
① 同値分析（★）
- 同値分析（同値分割ともいう）：
- 入力データを、同じ特性を持ついくつかのクラスに分け、各クラスを代表する値をテストデータにする方法
- 同値クラス：
- 同じ特性を持つクラス（グループ）
- 有効同値クラス：
- 正しい値を持つクラス
- 無効同値クラス：
- 正しくない値を持つクラス
- テストデータの選び方：
- 有効同値クラスと無効同値クラスに分け、それぞれのクラスから1つずつテストデータを選ぶ
- 例（注文数が1〜50なら受け付け、それ以外はエラーを表示する数字項目）：
- 有効同値クラスは「1〜50」
- 無効同値クラスは「−∞〜0」と「51〜∞」
- 各クラスの代表値として、例えば「−5、25、80」を使えばよい
- 同値分析の例え：
- 味見で、鍋の真ん中から一口すくえば、その鍋全体の味がわかる、という考え方
② 限界値分析（★）
- 限界値分析：
- それぞれのクラスの境界値（端の値）をテストデータにする方法
- 例（1〜50が正しいとき）：
- 「0、1、50、51」をテストデータにする
- 限界値分析が効くミス：
- 判定条件で「A≧a」とすべきところを「A＞a」としてしまったミスを見つけるには、限界値分析が有効
- 試験での出方（試験）：
- 限界値分析と同値分析は、午後試験でも用語問題として出る
- 例題（同値分析・限界値分析）：
- 「18歳以上65歳以下なら申込みOK、それ以外はエラー」という入力項目（整数）がある
- 同値分析と限界値分析で、それぞれどんなテストデータを選ぶか
- 例題の答え：
- 同値クラスは、無効「〜17」、有効「18〜65」、無効「66〜」の3つ
- 同値分析では、代表値を1つずつ選ぶ。例えば「10、40、70」
- 限界値分析では、境界の両側を選ぶ。「17、18、65、66」
③ 原因結果グラフ
- 原因結果グラフ（因果グラフともいう）：
- 入力（原因）と出力（結果）の論理関係をグラフにしたもの
- 記号を使ってグラフにし、それをもとにデシジョンテーブルを作って、テストケースを決める
- 原因結果グラフの副次的効果：
- 仕様の不備や曖昧さを指摘できる
- 大きな仕様では扱いにくいので、扱いやすいように仕様を分割するのが一般的
| 論理関係 | 意味 |
|---|---|
| 同値 | ①であれば、②が起こる |
| 否定 | ①でなければ、②が起こる |
| 和（OR、∨） | ①又は②であれば、③が起こる |
| 積（AND、∧） | ①かつ②であれば、③が起こる |
- デシジョンテーブル（決定表）：
- ある問題で起こり得るすべての条件と、各条件に対する動作や結果の関係を表にしたもの
- プログラム制御の条件漏れなどのチェックに効果がある
- 複雑な条件判定を伴う要求仕様を書く手段としても有効
例：ネットショップの送料判定
- 送料無料の条件：
- 「会員である」「購入金額が5,000円以上」のうち、少なくとも1つを満たせば送料無料。そうでなければ送料あり
- 原因結果グラフ：
- 原因①は「会員である」、原因②は「購入金額が5,000円以上」
- 結果③「送料無料」は、①又は②（③＝①∨②）
- 結果④「送料あり」は、①でも②でもない（④＝¬①∧¬②。会員ではなく、かつ購入金額が5,000円未満）
| ケース1 | ケース2 | ケース3 | ケース4 | |
|---|---|---|---|---|
| 原因① 会員である | Y | Y | N | N |
| 原因② 購入金額が5,000円以上 | Y | N | Y | N |
| 結果③ 送料無料 | X | X | X | − |
| 結果④ 送料あり | − | − | − | X |
- デシジョンテーブルの読み方：
- Yは条件を満たす、Nは満たさない
- Xはその結果になる、−はならない
- この4つの列が、そのまま4つのテストケースになる
④ 実験計画法
- 実験計画法：
- 検証項目の組合せによるテストケースの数が膨大になる場合に有効なテストケース設計法
- 直交表を使うことで、組合せに偏りがなく、かつ少ないテストケースを作れる
- 例（Webアプリを、OS・ブラウザ・回線の組合せで検証する）：
- OSはWindowsかMac、ブラウザはChromeかEdge、回線は有線か無線の、それぞれ2通り
- すべての組合せをテストすると、2³＝8パターン必要
- 直交表を使うと、次の4パターンですむ
| テストケースNo. | OS | ブラウザ | 回線 |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 2 | 1 | 0 | 0 |
| 3 | 0 | 1 | 0 |
| 4 | 0 | 0 | 1 |
- 表の見方：
- OSは1がWindows、0がMac。ブラウザは1がChrome、0がEdge。回線は1が有線、0が無線
- 直交表の性質：
- 4つのケースの中に、どの2つの項目を取っても、その2項目がとるすべての組合せ（［1，1］［1，0］［0，1］［0，0］の4つ）が含まれている
- 3つの項目の全組合せ（8通り）については、その50％（4通り）が含まれている
- 例えば、OSとブラウザに注目すると、No.1が［1，1］、No.2が［1，0］、No.3が［0，1］、No.4が［0，0］で、4つ全部そろっている
- 実験計画法の例え：
- 服・靴・帽子のコーディネートを全部試すと大変なので、「どの2つの組合せも一度は試した」状態になるように、少ない回数で試す
ホワイトボックステスト：中を見て、論理から確かめる（★計算・判定がよく出る）
- ホワイトボックステスト（構造テスト）：
- プログラムの内部論理の正しさを確かめるテスト
- プログラムの論理構造、つまり制御の流れに着目する
- ホワイトボックステストの考え方：
- 本当は、考えられるすべての入力データで、すべての命令や経路（パス）を通すのが望ましい
- しかし、作業量や時間の面で難しい
- そこで、網羅性を考えたうえで、判断（分岐）や繰返しなど、論理の重要な部分に着目したテストケースを作る
- テストカバレージツール：
- 網羅性を検査するツール
- ホワイトボックステストの例え：
- 自動販売機のふたを開けて、「100円を入れたらこの回路を通る」「売り切れのときはこの回路を通る」と、中の配線を1本ずつ確かめる
① 網羅性のレベル
- 網羅性のレベル：
- 命令網羅、判定条件網羅（分岐網羅）、条件網羅、判定条件／条件網羅、複数条件網羅がある
- 一般に、後のものほど網羅率の高い基準
| 網羅の基準 | テストケースの作り方 |
|---|---|
| 命令網羅 | すべての命令を少なくとも1回は実行する |
| 判定条件網羅（分岐網羅） | 判定条件の結果が真になる場合と偽になる場合の両方をテストする |
| 条件網羅 | 判定条件が複数条件のときに使う。判定条件を作る各条件が、真になる場合と偽になる場合の両方をテストする。ただし、判定条件の真偽両方はテストしなくてもよい |
| 判定条件／条件網羅 | 判定条件網羅と条件網羅を組み合わせる |
| 複数条件網羅 | 判定条件を作る各条件の起こり得る真と偽のすべての組合せと、それに伴う判定条件を網羅する |
- 複数条件：
- 「条件a OR 条件b」のように、1つの判定条件に複数の条件が含まれるもの
- 判定条件と条件の違い：
- 判定条件は、「条件1 OR 条件2」全体の結果（ここで真か偽かによって、どちらの道に進むかが決まる）
- 条件は、その中の「条件1」「条件2」の1つ1つ
- ORの判定条件の注意：
- 判定条件がOR条件の場合、テストケースの作り方によっては、判定条件そのものの誤りを見つけられないことがある
② 例：判定条件「条件1 OR 条件2」
- プログラムの形：
- 映画館の料金で、判定「65歳以上（条件1） OR 学生（条件2）」があり、真なら割引料金、偽なら通常料金にして、終了する
- 経路は「開始−割引−終了」（真）と「開始−通常−終了」（偽）の2つ
- 割引料金の処理に「命令X」、通常料金の処理に「命令Y」があるとする
| テストケース | 条件1（65歳以上） | 条件2（学生） | 判定条件 | 経路 |
|---|---|---|---|---|
| ① | 真 | 真 | 真 | 開始−割引−終了 |
| ② | 真 | 偽 | 真 | 開始−割引−終了 |
| ③ | 偽 | 真 | 真 | 開始−割引−終了 |
| ④ | 偽 | 偽 | 偽 | 開始−通常−終了 |
| 基準 | 必要なテストケースの例 | 満たす理由・足りないところ |
|---|---|---|
| 命令網羅 | ③と④ | 命令Xと命令Yを1回ずつ通ればよい。この例では真と偽の両方の経路に命令があるので、結果として判定条件網羅も満たす。もし偽の側に命令がなければ（何もせずに終了するなら）、③だけで命令網羅になり、偽の経路は確認できない |
| 判定条件網羅 | ③と④ | 判定条件の真（③）と偽（④）がそろう。でも、条件1（65歳以上）が真になる場合がテストされないので、条件網羅は満たさない |
| 条件網羅 | ②と③ | 条件1も条件2も、真と偽がそろう。でも、判定条件はどちらも真なので、偽の経路「開始−通常−終了」は確認できない。判定条件網羅は満たさない |
| 判定条件／条件網羅 | 例えば①と④ | 条件1・条件2ともに真偽がそろい、判定条件も真（①）と偽（④）がそろう |
| 複数条件網羅 | ①②③④の全部 | 条件の全組合せ（2×2＝4通り） |
- ひっかけ注意：
- 条件網羅は、判定条件網羅より「後」に並んでいるが、条件網羅を満たしても判定条件網羅を満たすとは限らない（②と③の例）
- だから、両方を組み合わせた判定条件／条件網羅がある
- 複数条件網羅のテストケースの数：
- 条件がn個なら、2ⁿ通り（条件2つなら4通り、3つなら8通り）
- 例題（網羅）：
- 判定条件「条件1 AND 条件2」で、条件網羅を満たすが判定条件網羅を満たさないテストケースの組はどれか
- ア（真，真）と（偽，偽） イ（真，偽）と（偽，真） ウ（真，真）と（真，偽）
- 例題の答え：
- ア：条件1も条件2も真偽がそろい、判定も真（真AND真）と偽（偽AND偽）がそろう。条件網羅も判定条件網羅も満たす
- イ：条件1も条件2も真偽がそろうが、判定はどちらも偽。条件網羅は満たすが、判定条件網羅は満たさない → 答えはイ
- ウ：条件1が真しかないので、条件網羅を満たさない
③ 制御パステスト
- 制御パステスト（制御フローテストともいう）：
- 命令網羅、判定条件網羅、条件網羅といった網羅性に着目して、プログラムの処理経路（パス）を網羅的に実行し、正しく動くかを確かめるテスト
- テストすべき処理経路は、プログラムをフローグラフに置き換えることで求める
- データフローテスト：
- 制御パステストに対して、プログラムの中で使うデータや変数が「定義 → 使用 → 消滅」の順に正しく処理されているかを確かめるテスト
- フローグラフ（制御フローグラフともいう）：
- プログラムを、連続した逐次命令群と、分岐命令（繰返しを含む）に分け、それぞれをノードにする
- 処理の順に、ノードとノードを有向線分（エッジ）で結んだもの
- 経路（パス）：
- フローグラフの開始から、同じエッジを2回以上通らずに出口に達するノードの列が、1つの経路
- 複数条件の分解：
- 分岐命令の判定条件が、ANDやORを使った複数条件の場合は、分解してからフローグラフに置き換える
- 例（上の映画館の料金を分解する場合）：
- 「条件1 OR 条件2」を、①「65歳以上か」と②「学生か」の2つの判定に分ける
- ①が真なら③割引へ、①が偽なら②へ。②が真なら③割引へ、②が偽なら④通常へ。③と④のあとはE（終了）へ
- 経路は、「S→①→③→E」「S→①→②→③→E」「S→①→②→④→E」の3つ
- サイクロマチック数（★計算が出る）：
- フローグラフから得られる、基本となる（互いに独立した）経路の数
- 分岐が続くときは、通り方の組合せの総数とは一致しないことがある（下の例題では、通り方は2×2×2＝8通りあるが、サイクロマチック数は4）。組み合わせればすべての通り方を作れる「基本の経路」の数と考える
- サイクロマチック数N＝
- E − V ＋ 2
- Eはエッジ（線）の数、Vはノード（点）の数
- 上の例の検算：
- ノードは、S・①・②・③・④・Eの6個
- エッジは、S→①、①→③、①→②、②→③、②→④、③→E、④→Eの7本
- N ＝ 7 − 6 ＋ 2 ＝ 3（経路3つと一致）
- この3つの経路を通るテストケースを作れば、処理経路を網羅できる
- 例題（サイクロマチック数）：
- 「判定1が真ならX、偽ならY。そのあと判定2が真ならZ、偽なら何もしない。さらに判定3が真ならW、偽なら何もしない。最後に終了（E）」というプログラムのサイクロマチック数は
- 例題の答え：
- ノードは、判定1・X・Y・判定2・Z・判定3・W・Eの8個
- エッジは、判定1→X、判定1→Y、X→判定2、Y→判定2、判定2→Z、判定2→判定3、Z→判定3、判定3→W、判定3→E、W→Eの10本
- N ＝ 10 − 8 ＋ 2 ＝ 4
- 補足（検算の近道）：
- 2方向に分かれる分岐だけでできたフローグラフなら、N ＝ 分岐の数 ＋ 1 になる
- 上の例題は分岐3つで3＋1＝4、映画館の例は分岐2つ（①、②）で3。どちらも一致する
モジュール集積テスト技法：つなぎながら確かめる（★）
- 結合テスト（ソフトウェア結合テスト）：
- 一般に、単体テストが終わったモジュールを2つ、3つと徐々に結合させながらテストする
- モジュール集積テスト技法：
- 結合テストを進めるための技法
- 上位から結合するか、下位から結合するかなど、いくつかの方法がある
- 大きく、増加テストと非増加テストに分かれる
| 分類 | テスト | やり方 |
|---|---|---|
| 増加テスト（少しずつ結合） | ボトムアップテスト | 下位から上位へ、順に結合する。上位の代わりにドライバが必要 |
| 増加テスト（少しずつ結合） | トップダウンテスト | 上位から下位へ、順に結合する。下位の代わりにスタブが必要 |
| 増加テスト（少しずつ結合） | 折衷テスト（サンドイッチテスト） | 折衷ラインを決め、その上をトップダウン、下をボトムアップで並行して行う |
| 非増加テスト（一気に結合） | ビッグバンテスト | すべてのモジュールの単体テストが終わってから、全モジュールを結合して一気にテストする |
| 非増加テスト（一気に結合） | 一斉テスト | 単体テストを省略し、必要なモジュールをすべて結合してテストする |
① ボトムアップテスト
- ボトムアップテスト：
- 下位のモジュールから上位のモジュールへと、順に結合しながらテストする
- 未完成の上位モジュールの代わりに、ドライバ（テスト用モジュール）が必要
- 流れの例（最上位がM1、その下にM2とM3、M2の下にM4とM5がある構造）：
- まず、ドライバを使って最下位のM4、M5をテストする
- 次に、ドライバを使ってM2、M3をテストする（M2にはM4、M5がつながっている）
- 最後に、M1を結合してプログラム全体をテストする
- ドライバ：
- テスト対象モジュールの上位モジュールの機能をまねるモジュール
- 引数を渡してテスト対象モジュールを呼び出す
- テスト対象モジュールからの戻り値を表示・印刷する
- ドライバの覚え方：
- ドライバ（運転手）は、上に乗って操作する（呼び出す）側
② トップダウンテスト
- トップダウンテスト：
- ボトムアップテストとは逆に、上位のモジュールから下位のモジュールへと、順に結合しながらテストする
- 未完成の下位モジュールの代わりに、スタブ（テスト用モジュール）が必要
- 流れの例（ボトムアップテストと同じ構造）：
- まず、スタブを使って最上位のM1をテストする
- 次に、M2、M3を結合し、スタブを使ってテストする
- 最後に、M4、M5を結合してプログラム全体をテストする
- スタブ：
- テスト対象モジュールから呼び出される
- テスト対象モジュールへ、擬似的な戻り値を返す
- スタブの覚え方：
- スタブ（切り株）は、下にある代わりの部品。呼ばれたら、決まった値を返すだけ
| ボトムアップテスト | トップダウンテスト | |
|---|---|---|
| 代わりの部品 | 上位の機能をまねるドライバ | 下位の代わりのスタブ |
| 並行作業 | モジュール数の多い下位から作るので、開発の初期から並行作業ができる | モジュール数の少ない上位から作るので、初期は並行作業が難しい |
| インタフェース | ドライバの下で確かめているので、最終段階でインタフェースの問題が出るおそれがある | 重要度の高い上位モジュールのインタフェースを早くテストできる |
| 信頼性 | − | 上位モジュールを繰り返し実行するので、信頼性が高い |
- 例え：
- ボトムアップは、レンガ（下位）を先にたくさん作って確かめ、最後に屋根（上位）を載せる。屋根を載せたときに、うまく合わないことがある
- トップダウンは、先に設計図どおりの骨組み（上位）を作り、壁がまだない所はベニヤ板（スタブ）で仮止めしながら確かめる
③ 折衷テスト
- 折衷テスト（サンドイッチテストともいう）：
- ボトムアップテストとトップダウンテストを組み合わせた方法
- 折衷ラインを決め、その上位をトップダウンテスト、下位をボトムアップテストで、並行して行う
その他のテスト及び検証
- ①システム結合テスト（システム統合テストともいう）：
- システム方式設計で決めたテスト要件に沿って行う
- ソフトウェア構成品目、ハードウェア構成品目、手作業、必要に応じて他のシステムをすべて統合したシステムが、要件を満たしているかを確かめる
- ②システム適格性確認テスト（システムテスト、システム検証テストともいう）：
- システム要件定義で決めた適格性確認要件に沿って行う
- システムが要件どおりにできているかを確かめ、システムの納入準備ができていることを確実にする
①と②で行う主なテスト
| テスト | 何をチェックするか |
|---|---|
| 機能テスト | システム要件を満たしているか |
| 性能テスト | スループット、レスポンスタイムなどの性能 |
| 操作性テスト | ユーザが操作しやすいか（ユーザインタフェース） |
| 障害回復テスト | 障害への対策が十分か（回復機能） |
| 負荷テスト | 実際の稼働時と同じ、またはより大きな負荷がかかったときの性能や機能 |
| 耐久テスト | 長時間の連続稼働に耐えられるか |
| 例外テスト | 例外や異常データの入力に対する対処（耐性） |
- エディットバリデーションチェック：
- 入力データの妥当性（属性、桁数、データ範囲など）をチェックすること
- 負荷テストと耐久テストの違い：
- 負荷テストは「重さ」（一度にたくさん）、耐久テストは「長さ」（長時間ずっと）
- ③運用テスト：
- システムが運用環境に合っているか、使用用途を満たしているか、使い勝手はどうかなどの最終確認
- 本番環境またはステージング環境（準本番環境）で、利用者の視点で行う
- そのため、開発プロセスではなく、運用プロセスの一部として、運用者が主体になって行う（ひっかけ注意）
- ④リグレッションテスト（回帰テスト、退行テストともいう）：
- 稼働中、または開発中のシステムの一部を修正したとき、その修正が他の部分に影響して新しい誤りが出ていないかを確かめるテスト
- 例えば、蛇口を修理したら、別の所から水漏れしていないかを確かめる
- ⑤探索的テスト：
- 経験や推測に基づいて、重要と思われる領域に焦点を当ててテストし、その結果をもとに新しいテストケースを作って、繰り返す技法
- ⑥ファジング：
- 問題を起こしそうなデータ（想定外の不正データ、異常データ、ランダムなデータ）を、検査対象に大量に送り込み、その応答や挙動を監視して、潜在的なバグや脆弱性を見つける検査手法
- ファズ：
- ファジングで送り込む、問題を起こしそうなデータ
混同しやすいペア
- ブラックボックステスト ／ ホワイトボックステスト
- ブラックボックステストは、外部仕様から作る（機能テスト）。冗長なコードは見つけられない
- ホワイトボックステストは、内部の論理構造から作る（構造テスト）
- 同値分析 ／ 限界値分析
- 同値分析は、各クラスの代表値を使う（1〜50なら −5、25、80）
- 限界値分析は、各クラスの端の値を使う（1〜50なら 0、1、50、51）
- 有効同値クラス ／ 無効同値クラス
- 有効同値クラスは、正しい値のグループ
- 無効同値クラスは、正しくない値のグループ
- 原因結果グラフ ／ デシジョンテーブル
- 原因結果グラフは、原因と結果の論理関係をグラフにしたもの
- デシジョンテーブルは、それをもとに、条件と結果の組合せを表にしたもの（テストケースになる）
- 実験計画法 ／ 複数条件網羅
- 実験計画法は、直交表で組合せを偏りなく減らす（ブラックボックス）
- 複数条件網羅は、条件の全組合せを網羅する（ホワイトボックス）
- 命令網羅 ／ 判定条件網羅
- 命令網羅は、すべての命令を1回は実行する。偽の経路を通らないことがある
- 判定条件網羅（分岐網羅）は、判定条件の真と偽の両方を通る
- 判定条件網羅 ／ 条件網羅
- 判定条件網羅は、判定条件「全体」の真偽をそろえる
- 条件網羅は、中の「各条件」の真偽をそろえる。判定条件の真偽はそろわなくてもよい
- 判定条件／条件網羅 ／ 複数条件網羅
- 判定条件／条件網羅は、判定の真偽と各条件の真偽をどちらもそろえる
- 複数条件網羅は、各条件の真偽のすべての組合せ（2ⁿ通り）
- 制御パステスト ／ データフローテスト
- 制御パステストは、処理経路（パス）を網羅的に実行する
- データフローテストは、データや変数が「定義 → 使用 → 消滅」の順に正しく処理されるかを確かめる
- エッジ ／ ノード
- エッジは、ノードを結ぶ有向線分（線）。式のE
- ノードは、命令群や分岐（点）。式のV
- ボトムアップテスト ／ トップダウンテスト
- ボトムアップテストは、下から結合する。ドライバが必要。初期から並行作業ができる
- トップダウンテストは、上から結合する。スタブが必要。上位のインタフェースを早く確かめられる
- ドライバ ／ スタブ
- ドライバは、上位の代わり。テスト対象を呼び出し、戻り値を表示する
- スタブは、下位の代わり。テスト対象から呼ばれ、擬似的な戻り値を返す
- 増加テスト ／ 非増加テスト
- 増加テストは、少しずつ結合する（ボトムアップ、トップダウン、折衷）
- 非増加テストは、一気に結合する（ビッグバン、一斉）
- ビッグバンテスト ／ 一斉テスト
- ビッグバンテストは、全モジュールの単体テストが終わってから一気に結合する
- 一斉テストは、単体テストを省略して、すべて結合してテストする
- システム結合テスト ／ システム適格性確認テスト
- システム結合テストは、システム方式設計のテスト要件で、すべてを統合して確かめる
- システム適格性確認テストは、システム要件定義の適格性確認要件で、納入準備ができているかを確かめる
- システム適格性確認テスト ／ 運用テスト
- システム適格性確認テストは、開発プロセスの中で、開発側が行う
- 運用テストは、運用プロセスの一部として、運用者が主体で、本番環境やステージング環境で行う
- 負荷テスト ／ 耐久テスト
- 負荷テストは、大きな負荷（重さ）に耐えられるか
- 耐久テストは、長時間の連続稼働（長さ）に耐えられるか
- 性能テスト ／ 負荷テスト
- 性能テストは、スループットやレスポンスタイムなどの性能を確かめる
- 負荷テストは、実際と同じかより大きな負荷をかけたときの性能や機能を確かめる
- 例外テスト ／ エディットバリデーションチェック
- 例外テストは、例外や異常データへの対処（耐性）を確かめる
- エディットバリデーションチェックは、入力データの妥当性（属性、桁数、範囲）をチェックする
- リグレッションテスト ／ 探索的テスト
- リグレッションテストは、修正の影響で新しい誤りが出ていないかを確かめる（回帰テスト、退行テスト）
- 探索的テストは、経験や推測で重要な所を試し、結果から新しいテストケースを作って繰り返す
- 探索的テスト ／ ファジング
- 探索的テストは、人の経験や推測で、テストケースを作りながら進める
- ファジングは、問題を起こしそうなデータ（ファズ）を大量に送り込み、バグや脆弱性を見つける