テストの体系
テストには多様なプロセスや方法があります。
テストは，開発者と利用者が協力して行う必要がありますが，図のシステムテストより前のテストは，プログラムに密着したチェックをするので，開発者が主体になり，それより後のテストは，システム全体の検収や運用での場面になるので，利用者が中心になります。
単体テスト
１つのプログラム（モジュール）を単体でテストします。文法ミスなどはプログラム作成段階で解決しているので，実際にデータを与えてみて，正しく動くかどうかを確認します。
テストの方法から，次の二つに区分されます。
- ホワイトボックステスト
- プログラムの内部構造を知って，分岐命令や繰返し命令が正しく動くかをテストします。例えば，
if Ｘ＞Ｙ then 処理１ else 処理２;
という命令があれば，Ｘ＞ＹとなるデータとＸ≦Ｙとなるデータを与えて，それぞれ処理１，処理２を行うことを確認します。
繰返し命令
while （Ｎ＞０）｛
処理３;
Ｎ－－; ｝;
という命令がある場合には，Ｎ＝３を与えれば処理３を３回繰り返すか，Ｎ＝０のときは処理をしないかなどの確認をします。 - ブラックボックステスト
- プログラムの内部構造には関知せず，仕様書などに基づいたテストデータでテストします。ホワイトボックステストでは，プログラマが理解したことが正しく作られているかはテストできますが，プログラマが仕様書を正しく理解したかの確認ができないので，それをブラックボックステストで確認するのです。
逆に，ブラックボックステストでは，プログラムのすべてのステップをカバーするテストができたかどうかわかりません。極端にいえば，プログラマが特殊な状況のときだけに動く不正なプログラムを忍ばせていたとき，それを発見することができません。
それで，この二つの方法を組み合わせてテストするのです。
テストを効果的に行うには，適切なテストデータを作成することが大切です。正しいデータが正しく処理されるだけでなく，わざと誤りのデータを与えて，誤りであることを正しく認識していることを確かめる必要があります。
次のチェックができるようにテストデータを設定します。
- 型チェック
- 数量などの数値項目に数字以外のデータを与えるとか，月日のデータに１３４５のような値を与える。
- フォーマットチェック
- ４桁の項目に３桁，５桁のデータを与える。項目の境界を間違えたデータを与える。
- リミットチェック（限界値チェック）
- 例えば１０≦Ｘ≦２０の条件のとき，その境界であるＸ＝９，１０，２０，２１を与える。
- 存在チェック（照合チェック）
- 例えば得意先マスタに存在しない得意先コードを与える
- シーケンスチェック，重複チェック
- これらはプログラムでなくデータファイルのチェックである。順序正しく並んでいるか，重複はないかのチェックをする。小さい順に並んでいるファイルを入力とするプログラムに，順序が異なるファイルを入力したら，それを発見できるか。出力されたファイルが順序正しくなっているかなどの確認をする。
結合テスト
単体のプログラムは正しくても，複数のプログラム間でデータの受け渡しなどで誤りがないかをテストします。特に異なるプログラマが作成したプログラムでは，思い違いが発生する危険があります。
上位のプログラムから下位のプログラムを呼び出す構成もあります。例えば上位のプログラムでいくつかのメニューが示され，そこで指定されたの処理を，それぞれの下位のプログラムで行うようなケースです。このようなときの結合テストのときには，次の２通りがあります。
- トップダウンテスト
- 上位のプログラムにデータを与えて，正しく下位プログラムが呼び出されるかというように，上位のプログラムからテストします。このとき，下位のプログラムが未完成のときは，ダミーのプログラムを用意することになります。そのダミープログラムをスタブといいます。
- ボトムアップテスト
- 呼び出される下位のプログラムを先にテストする方法です。上位のプログラムが未完成のときは，ドライバというダミープログラムを用います。
利用者が中心のテスト
単体テストと結合テストの段階は，開発者が主体になるが，システムテスト（総合テスト）では，どちらが主体とはいいにくくなり，それ以降にかけて利用者が主体になります。
- システムテスト（総合テスト）
- システム全体を通してテストします。
- 承認テスト
- 利用者がこのシステムを受け入れるための確認テスト。これに合格することにより，システムが検収されます。
- 運用テスト
- 実際に運用してみて，問題点を発見するテスト。半年とか１年の期間を設けて，この間に発見された誤りは開発者の責任で修正するのが通常です。
単にロジックが正しいことを確認するだけではなく，後述のように総合的な観点からテストします。
- 機能テスト
- 要求要求した機能がすべて実現しているかのテスト
- 性能テスト
- 応答時間や一定時間内の処理量などの確認テスト
- 負荷テスト
- 一度に大量のデータが発生しても処理できるかのテスト
- 耐久テスト
- 負荷テストの一種であるが，長時間にわたって負荷状況がどのように変化するかを調査する。
- レグレッションテスト（退行テスト）
- システムの修正や機能追加をしたときに，正しく処理されるかを確認するテスト
テストの管理
システムに含まれるエラーのことをバグといい，それを発見して修正することをデバッグといいます。
最初の時点では単純なエラーが多く見つかるが，次第に発見が困難になるし，複雑なエラーで修正も困難になります。それで、バグ累積数をグラフにすると，指数曲線のようになると考えられます。ところが、最初の段階では準備などに時間がとられるため、実際にはゴンペルツ曲線のようになることが多いのです。
理想的にはすべてのバグを無くさなければならないのですが，システムにある真のバグ数は誰にもわかりません。でも，このような曲線を描くことにより，残っているバグの数を想定することができます。
ある時点を過ぎると、残っているバグは少ないのに，それを発見して修正する時間や費用が多くかかることになります。それで，実務的には致命的なバグが解決できているならば，この時点でテストを終了し，次の段階で発見されるのを待つことにするのが一般的です。
過去問題：「テストの種類・方法」 （test）