ユニットテスト

プログラムを構成する最小の単位（モジュールやソフトウェアユニット）ごとに、設計どおりに動作するかを確かめるテスト。プログラムを作成した開発者が行うことが多い。単体テストの後に、複数のモジュールを組み合わせて確かめる結合テストを行う。

個々のモジュールやクラスの機能を独立して検証するテスト工程。ドライバやスタブを用いて、テスト対象のモジュールを単独で動作させる。開発者が主体となって実施し、コードレベルの不具合を検出する。

条件と動作の組合せを表形式で整理する手法。複雑な条件分岐のロジックを網羅的に表現でき、業務分析や要件定義、テストケースの作成に活用される。デシジョンテーブルとも呼ばれる。

プログラムの内部構造（ロジック）に着目してテストデータを作成するテスト手法。命令網羅、判定条件網羅（分岐網羅）、条件網羅、複数条件網羅などのカバレッジ基準がある。

プログラムの内部構造を意識せず、入力と出力の関係に着目してテストデータを作成するテスト手法。同値分析法、限界値分析法、原因結果グラフ法、エラー埋込法などの技法がある。

テストによってプログラムのどの程度が実行されたかを示す指標。命令網羅（C0）、判定条件網羅（C1）、条件網羅（C2）、複数条件網羅（MCC）などの基準があり、テストの十分性を評価する。

入力データの取りうる範囲を有効同値クラスと無効同値クラスに分割し、各クラスから代表値を選んでテストする手法。ブラックボックステストの技法の一つで、効率的にテストケースを削減できる。

同値クラスの境界値（最小値、最大値、その前後の値）を重点的にテストする手法。境界付近でバグが発生しやすいという経験則に基づき、同値分析法と組み合わせて使用される。