単体テスト

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

ソフトウェアユニット（最小のプログラム単位）ごとに行うテスト。ソフトウェア設計で定義したテスト仕様に従い、個々のモジュールが正しく動作するかを検証する。ホワイトボックステストが主に用いられる。

条件の組み合わせと、それに対応する処理（アクション）を表形式で整理する技法。複雑な条件分岐をもれなく網羅的に記述でき、仕様の漏れや矛盾を発見するのに有効。テスト設計にも活用される。

ウォーターフォールモデルの各開発工程に対応するテスト工程を対に配置した開発モデル。要件定義に受入テスト、基本設計にシステムテスト、詳細設計に結合テスト、実装に単体テストが対応する。各工程の整合性を確保する。

内部構造を考慮せず、入力と出力の関係からテストケースを設計する手法。同値分割、境界値分析、デシジョンテーブル、状態遷移テストなどの技法がある。機能仕様に基づいてテストする。

プログラムの内部構造（制御フロー、データフロー）に基づいてテストケースを設計する手法。命令網羅、分岐網羅、条件網羅、パス網羅などのカバレッジ基準がある。ロジックの正確性を検証する。

単体テスト済みのモジュールを組み合わせ、モジュール間のインタフェースや連携を検証するテスト工程。トップダウンテスト、ボトムアップテスト、サンドイッチテスト（混合テスト）などの戦略がある。

発注者（ユーザ）がシステムの受入可否を判断するために実施するテスト。業務要件や契約条件への適合を検証する。運用テスト、ベータテストなどの形態がある。