テストでは、作成したプログラムにバグがないかどうか、要求された機能が実現できているかどうかをチェックする。
ソフトウェアライフサイクルに応じて、異なる視点に立ち、単体テスト・結合テスト・システムテスト・運用テストなどを実施する。
要求事項を満たしていない場合は、障害あるいは欠陥として扱い、障害分析を行い、適切な対策を行う。

テストを効率よく効果的に行うためには、テストの日程、実施体制(テスト環境・テスト実施者)、テスト範囲、テスト方法(使用ツール)などを計画し実施する。
テストデータを作成し、テストを実施する。テスト結果を分析し、評価する。

【 テストデータジェネレータ 】
テストデータを自動的に大量に作るためのツール

【 実験計画法 】
統計学的手法に基づき、実験を計画的に実施する方法。
やみくもに数多くの実験を行うよりも、計画されたより少ない実験回数で多くの成果を出すことができる。

【 網羅率 】
用意したテストデータがプログラムのさまざまな部分をもれなくテストしていることが大事。プログラム全体でどれぐらいの割合をテストしているかのこと。

【 バグ曲線 】
ソフトウェアのバグ発生件数は、縦軸にバグの累積個数、横軸にテスト項目消化数、もしくはテスト時間をとると、S字型の成長曲線を描くことが知られている。この曲線は、ソフトウェア信頼度成長曲線やバグ曲線と呼ばれ、ソフトウェアの品質管理に利用される。
テストを開始してから間もなくすると、バグは多く発見されますが、徐々に減少し、最後にはほとんど発見されなくなるというエラー除去の様子がわかる。ソフトウェア信頼度成長曲線が水平な線を描き始めると、バグがほぼ収束し、ソフトウェアが一定の品質に達したものとしてみなすことができる。

【 バグ管理図 】
バグ管理図は、横軸に時間、縦軸にテスト項目未消化件数、検出バグの累積件数、未解決バグの件数などの推移を表したグラフです。これらの推移がすべて横ばいになった場合は、バグの修正に時間がかかり、次のテストを実施できず、新たなバグを摘出できない状況である可能性があります。そこで、解決困難なバグに直面しているかどうかを確認する必要があります。

【 ホワイトボックステスト 】
モジュールの内部で、正しい動作が行われているかチェックする。「プログラムの内部論理に基づいてテストケースを設定する技法」です。
命令網羅・判定条件網羅・条件網羅・複数条件網羅などを利用する。

【 ブラックボックステスト 】
モジュールの内部構造を考慮しないで、モジュールに入力した値と出力した値が正しいかどうかをチェックします。プログラムの「外部仕様」をもとにテストケースを設定する。つまりプログラムを中身の見えない箱と見なします。
同値分割法・限界値分析法などを利用する。

【 トップダウンテスト 】
上位モジユールに下位モジュールを順次組み合わせて結合してテストして行きます。完成されていない下位モジュールは「スタブ」と呼ばれるダミーのモジュールを使用して補います。

【 ボトムアップテスト 】
下位モジュールから順次、上位モジュールを組合わせてテストを行い、完成されていない上位モジュールがある場合は「ドライバ」と呼ばれるダミーのモジュールを使用して補います。

【 サンドイッチテスト 】
最上位モジュールからトップダウンテスト、最下位モジュールからボトムアップテストを同時並行的に行います。「ドライバ」と「スタブ」の両方が必要となります。折衷テストとも呼ばれる。

【 ビックバンテスト 】
「スタブ」「ドライバ」を用意しておき、単体テストが終了したすべてのモジュールを結合してテストを行います。最も短期間で結合テストを終了できますが、比較的小規模のソフトウェアにしか向いていません。

【 一斉テスト 】
小規模ソフトウェアに向いた方法で、モシュールの単体テストは行わず、直接、すべてのモジュールを結合してテストを行います。「ドライバ」「スタブ」は不要です。

【 単体テスト 】
モジュールテスト・ユニットテストとも呼ばれ、ロジックが正しいか、モジュール仕様との整合性に問題がないか確認するテスト。

【 システムテスト 】
すべてのモジュールを結合して、システム全体のテストを行う。システム開発者が行う最後のテストです。総合テストとも呼ばれる。具体的には以下のテストを行います。

• 機能テスト
  必要な機能がすべて含まれ、正常に動作するかどうかを検証する。
• 操作性テスト
  ユーザインタフェースが使いやすいかどうかを検証する。
• 例外事項テスト(例外テスト)
  仕様外のデータに対して正しく対処しているかどうかテストする。
• 障害テスト
  障害発生時の対応がなされているかどうかテストする
• 処理速度テスト(性能テスト)
  仕様で定められた性能を満たしているかどうかテストする。具体的には、ターンアラウンドタイム、レスポンスタイムなどの計測。
• 負荷テスト
  大きな負荷（大量のデータ処理など）をかけても、正常に動作するかどうかを検証する。
• 回帰テスト(リグレッションテスト)
  退行テストとも呼ばれ、モジュールの修正が発生したときに、バグを修正したことにより、新たなバグが発生していないかを確認するテスト
• セキュリティテスト(ペネトレーションテスト:侵入テスト)
  システムの不正アクセスの防止機能の動作やセキュリティホールの存在を確認する。

【 運用テスト 】
ユーザ部門が主体となって行うテストで、ユーザ部門が提示した条件を満たしているかどうか確かめるテストです。承認テストとも呼ばれる。以下の順番に行われます。

　「承認テスト」→「導入テスト」→「実地テスト」

• 承認テスト
  システム納品後、ユーザ部門がテストデータを用意して動作確認する。
• 導入テスト
  実際の動作環境のもとでシステムが仕様どおりの性能を満たしているか確認してシステムの検収と受領を行う。
• 実地テスト
  システムを実際に業務で使用して確認・評価する。これはシステムが破棄されるまで継続します。

【 命令網羅 】
プログラム中のすべての命令が少なくとも 1 回は実行されるようにテストする。

A B 全体 真 真 真

【 判定条件網羅(分岐網羅) 】
プログラムの判定条件で真と偽が少なくとも 1 回は実行するようにテストする。

A B 全体 真 真 真 偽 偽 偽

【 条件網羅(分岐条件網羅) 】
判定条件において、真偽についての組合せを満たす条件を少なくとも 1 回は実行するようにテストする
それぞれの条件の真の場合と偽の場合を組み合わせてテストする。

A B 全体 真 偽 偽 偽 真 偽

【 判定条件 / 条件網羅 】
判定条件において、真偽についての組合せを満たす条件を少なくとも 1 回は実行する　かつ　プログラムの判定条件で真と偽が少なくとも 1 回は実行するようにテストする。

A B 全体 真 真 真 偽 真 偽 真 偽 偽

【 複数条件網羅 】
判定条件で条件のとりうるすべての組合せを網羅するようにテストする。

A B 全体 真 真 真 真 偽 偽 偽 真 偽 偽 偽 偽

【 テストケース 】
プログラミングが終了したシステムのテストを行うために、あらゆる場合を想定して作成された、テストの項目や条件のこと。

【 同値分割 】
入力データを「同じ出力結果が得られるグループ」に分割します。このグループを「同値クラス」と言います。この際、正常処理を行う同値クラスを「有効同値クラス」と言い、エラー処理を行う同値クラスを「無効同値クラス」と言います。
同値分割によって、最低限のテストデータを作成する場合は、
・有効同値クラスより小さい範囲の無効同値クラス
・有効同値クラス
・有効同値クラスより大きな範囲の無効同値クラス
それぞれから代表データを選択する。

【 限界値分析 】
プログラムのエラーは条件判定の境界近くに含まれることが多いため、 同値クラスの境界値をテストケースとすることを言います。

正常データの範囲が 2 ＜ A ＜ 8 のとき、

同値分割は、-1 , 5 , 11 を使う。
限界値分析は、2 , 3, 7 ,8 を使う。

【 原因結果グラフ法 】
入力やイベント(原因)の組合せと、出力(結果)との関係をグラフ化するテスト技法。論理関係の網羅性を高めることができる。
原因結果グラフは同値分割された 複数の原因（入力値）と複数の結果（出力値）の要素間の因果関係を論理演算子（AND、OR、NOT、EOＲ、等）と線で結合したグラフで表し、そのグラフからテストケースを抽出するためのデシジョンテーブルを作成するものである。

【 エラー埋込法 】
エラー埋め込み法とは、プログラムに意図的にエラー(制御エラー)を埋め込んだ状態でテストを行い、発見された埋め込みエラー数から、まだ発見されていない潜在バグ（真のエラー）数を推測する手法です。

エラーの検出率 ＝ 検出した埋め込みエラー ÷ 全埋め込みエラー
＝ 発見された真のエラー ÷ (発見された真のエラー ＋ 残存する真のエラー)

または、
制御エラーの発見数 : 真のエラーの発見数 ＝ 残りの制御エラー数 : 見つかっていない真のエラー数

Ex.
プログラムに埋め込んだ制御エラーの全体が60個で、すべてのエラー発見数が78個で、その中の制御エラー数が36個であるときの、残りの真のエラー数はいくつ?
エラー検出率 ＝ 36 ÷ 60 ＝ 0.6
発見された真のエラー数 ＝ 78 － 36 ＝ 42
全部の真のエラー数 ＝ 42 ÷ 0.6 ＝ 70
残りの真のエラー数 ＝ 70 － 42 ＝ 28

【 メトリクス計測 】
ソフトウェアの品質を正確に把握するための「客観的な指標」 として、「関数の行数」や「関数内の分岐の数」などがあります。 これらをメトリクスと呼びます。 メトリクスを計測 /分析することで、ソフトウェアの弱点をより具体的に、かつ正確に把握することができます。
ソフトウェアの複雑度を客観的に数値化できます。
以下のようなメトリクスがあります。

• 関数の行数
• 関数内の分岐の数
• 関数呼び出しの数
• コメント密度
• クラスの凝集度
• クラスの結合度
• 関数・変数に対するアクセス率

1. 平成28年度春期　問49　　命令網羅
2. 平成28年度秋期　問48　　有効同値クラス　無効同値クラス
3. 平成28年度秋期　問49　　結合テスト
4. 平成27年度春期　問49　　バグ累積件数
5. 平成27年度春期　問50　　ホワイトボックステスト
6. 平成25年度春期　問22　　ホワイトボックステスト
7. 平成19年度春期　問44　　結合テスト
8. 平成19年度春期　問48　　テスト　運用テスト
9. 平成15年度春期　問51　　テスト　ブラックボックステスト
10. 平成15年度秋期　問52　　テスト　スタブ