受入れテスト

開発されたシステムが発注者の要件を満たしているかを、発注者側が確認するテスト。納品・検収の判断基準となり、実際の業務データを用いて運用可能性を検証する最終段階のテスト。

開発されたシステムが、利用者の意図する用途や目的に合致しているかを確認するテスト。要件定義の内容と実装結果の整合性を検証し、「正しいシステムを作ったか」を判定する。

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

開発されたシステムがユーザの要件を満たしているかを利用者が確認するテスト。ユーザ受入テスト（UAT）とも呼ばれ、本番移行前の最終的な検証として位置づけられる。監査ではテスト結果の妥当性を検証する。

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

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

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

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

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

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