テストの種類・方法

テストの体系

テストには多様なプロセスや方法があります。

（拡大図）

共通フレーム２００７では、企画開発工程とテストの関係を次のように示しています（図示）。

　　　　企画開発工程　　　　　　共通フレームでの　　　　　　　上図での
　　　　　　　　　　　　　　　　テスト・評価名称　　　　　　　テスト名称
　　事業レベル
　　　　経営戦略　　　　　　　　経営評価
　　　　システム化の方向性　　　情報化評価
　　　　システム化評価　　　　　運用評価
　　業務レベル
　　　　要件定義　　　　　　　　運用テスト　　　　　　　　　　運用テスト
　　システムレベル
　　　　システム要件定義　　　　システム適格性確認テスト
　　　　システム方式設計　　　　システム結合　　　　　　　　　システムテスト
　　ソフトウェアレベル
　　　　ソフトウェア要件定義　　ソフトウェア適格性確認テスト
　　　　ソフトウェア方式設計　　ソフトウェア結合　　　　　　　結合テスト
　　　　ソフトウェア詳細設計　　ソフトウェアテスト　　　　　　単体テスト

テストは，開発者と利用者が協力して行う必要がありますが，システムテストより前のテストは，プログラムに密着したチェックをするので，開発者が主体になり，それより後のテストは，システム全体の検収や運用での場面になるので，利用者が中心になります。
　システムテストは、システム結合の意味では、結合テストの延長だとして、開発者が中心になるともいえますが、システム適格性確認テストの意味では、システム要件を満たしていること、すなわち外部設計仕様書通りになっていることを確認するテストですので、外部設計者が担当することになります。その外部設計者には利用部門が参画しているので、開発者と利用部門の両方が主体になるといえます。さらには、システムテストの最終段階が承認テスト（受入れテスト）であるとすれば、利用部門が主体になるともいえます。

単体テスト

１つのプログラム（モジュール）を単体でテストします。文法ミスなどはプログラム作成段階で解決しているので，実際にデータを与えてみて，正しく動くかどうかを確認します。
　テストの方法から，次の二つに区分されます。

ホワイトボックステスト

プログラムの内部構造を知って，分岐命令や繰返し命令が正しく動くかをテストします。例えば，
　　　　if　Ｘ＞Ｙ　then　処理１　else　処理２;
という命令があれば，Ｘ＞ＹとなるデータとＸ≦Ｙとなるデータを与えて，それぞれ処理１，処理２を行うことを確認します。
　また、繰返し命令
　　　　while　（Ｎ＞０）｛
　　　　　　処理３;
　　　　　　Ｎ－－;
　　　　｝;
という命令がある場合には，Ｎ＝４を与えれば処理３を４回繰り返すか，Ｎ＝０のときは処理をしないかなどの確認をします。

ブラックボックステスト

プログラムの内部構造には関知せず，仕様書などに基づいたテストデータでテストします。ホワイトボックステストでは，プログラマが理解したことが正しく作られているかはテストできますが，プログラマが仕様書を正しく理解したかの確認ができないので，それをブラックボックステストで確認するのです。
逆に，ブラックボックステストでは，プログラムのすべてのステップをカバーするテストができたかどうかわかりません。極端にいえば，プログラマが特殊な状況のときだけに動く不正なプログラムを忍ばせていたとき，それを発見することができません。
それで，この二つの方法を組み合わせてテストするのです。

動的テストと静的テスト

実際にコンピュータにかけてテストするのを動的テスト、ソースプログラムやデータを机上で調べてテストするのを静的テストといいます。

テストを効果的に行うには，適切なテストデータを作成することが大切です。正しいデータが正しく処理されるだけでなく，わざと誤りのデータを与えて，誤りであることを正しく認識していることを確かめる必要があります。
次のチェックができるようにテストデータを設定します。

型チェック

数量などの数値項目に数字以外のデータを与えるとか，月日のデータに１３４５のような値を与える。

フォーマットチェック

４桁の項目に３桁，５桁のデータを与える。項目の境界を間違えたデータを与える。

リミットチェック（限界値チェック）

例えば１０≦Ｘ≦２０の条件のとき，その境界であるＸ＝９，１０，２０，２１を与える。

存在チェック（照合チェック）

例えば得意先マスタに存在しない得意先コードを与える

シーケンスチェック，重複チェック

これらはプログラムでなくデータファイルのチェックである。順序正しく並んでいるか，重複はないかのチェックをする。小さい順に並んでいるファイルを入力とするプログラムに，順序が異なるファイルを入力したら，それを発見できるか。出力されたファイルが順序正しくなっているかなどの確認をする。

●カバレッジ

ソースプログラムには多くの分岐やループなどがあります。それらのケースをくまなくテストすることが求められますが、すべてのケースをテストしようとすると、ケース数が非常に多くなり時間も費用もかかるので、重点的に選択したり、動的／静的を適切に組み合わせたりします。テストするケースの割合をカバレッジ（カバー率）といいます。
　テストに用いるデータ量も多くなります。それを支援するツールをテストデータ支援ツールといいます。

●チュックデジットについて

誤った入力データが入力されると、誤った結果になりますが、いったんコンピュータに入った誤りデータを発見するには多大な手間がかかります。それで、入力時点で誤りを防ぐことが重要です。
　特に長い数字列のコードの場合は入力誤りをしがちです。それで、コードの末尾に１桁たチェック用の桁をもうけておき、例えばコードの各桁を加算したときの１の位の数字を入れておき、コード入力したときに計算をして、答が合致するかどうかをチェックする方法があります。そのチェック用の桁をチェックデジットといいます。
　ＰＯＳシステムではＪＡＮコード（バーコード）をスキャンしますが、読み取りエラーを防ぐために、ＪＡＮコードにはチェックデジットがつけられています。また、厳しく誤りを発見するために、複雑な計算方法を採用しています。

結合テスト

単体のプログラムは正しくても，複数のプログラム間でデータの受け渡しなどで誤りがないかをテストします。特に異なるプログラマが作成したプログラムでは，思い違いが発生する危険があります。

上位のプログラムから下位のプログラムを呼び出す構成もあります。例えば上位のプログラムでいくつかのメニューが示され，そこで指定されたの処理を，それぞれの下位のプログラムで行うようなケースです。このようなときの結合テストのときには，次の２通りがあります。

トップダウンテスト

上位のプログラムにデータを与えて，正しく下位プログラムが呼び出されるかというように，上位のプログラムからテストします。このとき，下位のプログラムが未完成のときは，ダミーのプログラムを用意することになります。そのダミープログラムをスタブといいます。

ボトムアップテスト

呼び出される下位のプログラムを先にテストする方法です。上位のプログラムが未完成のときは，ドライバというダミープログラムを用います。

利用者が中心のテスト

単体テストと結合テストの段階は，開発者が主体になるが，システムテスト（総合テスト）では，両者の共同作業になり（厳密には外部設計者），それ以降は利用者が主体になります。

システムテスト（総合テスト）

システム全体を通してテストします。システム要件定義、それをまとめた外部設計書、請負契約の場合は契約でのシステム仕様書の内容が正しく実現されているかを確認するテストです。

承認テスト

利用者がこのシステムを受け入れるための確認テスト。これに合格することにより，システムが検収されます。システムテストの最終段階が承認テストになることもあります。
システムテストや承認テストでは、提供者がテストしたのでは要件を誤解していることが発見できません。利用部門が中心になって行う必要があります。
利用部門がテストデータを作成しする必要があります。このとき、誤ったデータや誤った操作をしたとき、システムが誤りであることを正しく認識した対応をすることを確認することが重要です（不適切な例）。

ところが、利用者はテストに関心が低いのが通例です。しかも、テストには非常な労力を伴います。そのため、十分なテストが行えないことがよくあるのです。
　ひどい場合には、先月のデータをもってきて「先月と同じ結果になればいいよ」などという利用者もいます。

• 確かにデータ量は多いのですが、ほとんど同じようなデータなので、プログラムの一部だけが実行されただけで、大部分はテストされないままです。
• このなかには、コンピュータに入らなかった誤ったデータがありません。誤データ、誤操作のテストができません。

「君たちはプロだし、誠実だから、君たちを信用するよ」という人もいます。テストの段階になると、奇妙に提供者は信用されるのですね。

運用テスト

実際に運用してみて，問題点を発見するテスト。半年とか１年の期間を設けて，この間に発見された誤りは開発者の責任で修正するのが通常です。

単にロジックが正しいことを確認するだけではなく，後述のように総合的な観点からテストします。

機能テスト

要求要求した機能がすべて実現しているかのテスト

性能テスト

応答時間や一定時間内の処理量などの確認テスト

負荷テスト

一度に大量のデータが発生しても処理できるかのテスト

耐久テスト

負荷テストの一種であるが，長時間にわたって負荷状況がどのように変化するかを調査する。

レグレッションテスト（退行テスト）

システムの修正や機能追加をしたときに，その修正などにより、ほかの部分でエラーになることがないことを確認するテストです。このような場合には、 　・短期間での解決が求められるので、正規の体制ではなく担当者個人で対処することになりやすい
　　　　保守運用ルールの徹底が必要
　・影響を及ぼすプログラムを特定することが難しい
　　　　文書化（可視化）の徹底が必要
などのため、テストが不十分になることが多いのです。

テストの管理

システムに含まれるエラーのことをバグといい，それを発見して修正することをデバッグといいます。
　最初の時点では単純なエラーが多く見つかるが，次第に発見が困難になるし，複雑なエラーで修正も困難になります。それで、バグ累積数をグラフにすると，指数曲線のようになると考えられます。ところが、最初の段階では準備などに時間がとられるため、実際にはゴンペルツ曲線のようになることが多いのです。

理想的にはすべてのバグを無くさなければならないのですが，システムにある真のバグ数は誰にもわかりません。でも，このような曲線を描くことにより，残っているバグの数を想定することができます。
　ある時点を過ぎると、残っているバグは少ないのに，それを発見して修正する時間や費用が多くかかることになります。それで，実務的には致命的なバグが解決できているならば，この時点でテストを終了し，次の段階で発見されるのを待つことにするのが一般的です。