Web教材一覧システムの調達

テストの種類・方法

学習のポイント

プログラムやシステムができたら,正しく処理できるか,処理速度は適切か,操作性はどうかなどの確認のためのテストをします。この工程が不十分だと稼動後になって大きなトラブルが発生する危険もあるし,利用者と開発者の間の責任問題にもなります。
 情報処理技術者試験では,テストに関する問題が多く出題されます。ここでは,よく出題されるものを集めました。

キーワード

単体テスト、ブラックボックステスト、限界値チェック、結合テスト、システムテスト、運用テスト、退化テスト


テストの体系

テストには多様なプロセスや方法があります。
共通フレームでは、企画開発工程とテストの関係を次のように示しています(図示)

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

これを単純化して
  単体テスト→結合テスト→システムテスト→運用テスト
に区分することが広く行われています。

テスト体系図 (拡大図)

テストの主体者

テストは,開発者と利用者が協力して行う必要がありますが,単体テスト、結合テストでは,プログラムに密着したチェックになるので,開発者が主体になり,それより後のテストは,システム全体の検収や運用での場面になるので,利用者が中心になります。
 システムテストは、システム全体のプログラムを対象にした結合テストとする狭義の観点では、開発者が中心になりますが、システム要件を満たしていること、すなわち外部設計仕様書通りになっていることを確認するテストとする観点では、外部設計者が担当することになります。その外部設計者には利用部門が参画しているので、開発者と利用者の両方が主体になるといえます。さらには、システムテストの最終段階が承認テスト(受入れテスト)であるとすれば、利用部門が主体になるともいえます。
 運用テストは、実際にシステムが稼働している環境でのテストが一般的なので、利用者が中心になります。しかし、利用者は問題発見はできても、その原因解明やテスト環境の設定などは専門的な知識が必要になるので、開発者の関与が必要です。また、稼働以前に負荷テストをするというような場合では、開発者が主体になることもあります。

単体テスト

一つのソフトウェア単体(1本のプログラム=モジュール)を対象としたテストです。単純な文法ミスはプログラム作成段階で解決しているものとします。テストの方法により、次のように区分できます。
 動的テスト:実際にテストデータを与えてプログラムを実行し、正しく処理されることを確認する。
   ホワイトボックステスト:ソースプログラムの内部構造を知って,テストデータを作成する。
   ブラックボックステスト:ソースプログラム内部を見ずに、仕様書からテストデータを作成する。
 静的テスト:プログラムの実行をせずに、プログラムの分析を行うことによって確認する。

ホワイトボックステスト

ホワイトボックステストは、プログラムが正しく動くことを確認するテストです。プログラムの内部構造を知って,分岐命令や繰返し命令が正しく動くかをテストする方法です。例えば,
    if X>Y then 処理1 else 処理2;
という命令があれば,X>YとなるデータとX≦Yとなるデータを与えて,それぞれ処理1,処理2を行うことを確認します。
 また、繰返し命令
    while (N>0){
      処理3;
      N--;
    };
という命令がある場合には,N=4を与えれば処理3を4回繰り返すか,N=0のときは処理をしないかなどの確認をします。
●カバレッジ
 ソースプログラムには多くの分岐やループなどがあります。それらのケースをくまなくテストすることが求められます。すべてのプログラムステップに対してテストで実行したステップの割合をカバレッジ(カバー率)といいます。
 カバー率100%である(すべてのステップをテストできた)のが理想ですが、すべてのケースを手探りでテストしようとすると、ケース数が非常に多くなります。少ないケースでカバー率を高める工夫が必要です。定量的に解析し、カバーした結果を測定・評価することを、カバレッジ分析といい、それを支援するツールをテストデータ支援ツールといいます。
 また、カバー率を100%にしようとすると、時間も費用もかかるので、重点的に選択したり、静的テストを適切に組み合わせたりします。

●ホワイトボックステストでの動的テスト(対象プログラムを実行しながらテスト)をするときの手法を列挙します。
これらは、プログラマがソースプログラムに明示的に記述することもありますが、プログラミング言語での付帯機能、あるいはテスト支援ツールを用いるのが通常です。それをデバッカーといいます。

ブラックボックステスト

ブラックボックステストとは、プログラムの内部構造を考慮せず(ブラックボックスだとして),外部仕様書に基づいたさまざまな入力データを与えて、仕様書どおりの出力が得られるかどうかを確認します。
 ホワイトボックステストでは,プログラマが理解したことが正しく作られているかどうかはテストできますが,プログラマが外部仕様書を正しく理解しているかの確認ができない、すなわち、設計者の意図した機能を実現しているかわからないので,それをブラックボックステストで確認するのです。
 そのため、テストデータはプログラマではなく、外部仕様書作成者あるいは利用者が作成すべきです。

ブラックボックステストでは,プログラムの中を見ないので、カバー率がどの程度かわかりません。プログラムに冗長なコードがあっても検出できません。極端にいえば,プログラマが特殊な状況のときだけに動く不正なプログラムを忍ばせていても,それを発見することができません。

チェック目的とテストデータ

テストを効果的に行うには,適切なテストデータを作成することが大切です。正しいデータが正しく処理されるだけでなく,わざと誤りのデータを与えて,誤りであることを正しく認識されることを確かめる必要があります。
 誤った入力データが入力されると、誤った結果になりますが、いったんコンピュータに入った誤りデータを発見するには多大な手間がかかります。それで、入力時点で誤りを防ぐことが重要です。

型チェック
入力変数には型(タイプ)があります。それと異なる型のデータを入力したとき、誤りであることを検出させるテストです。
数量などの数値項目に数字以外のデータを与えるとか,月日のデータに1345のような値を与えたときに誤りとして処理するテストです。特に数字項目に数字以外の文字を入れた場合のチェックのことをニューメリックチェックといいます。
フォーマットチェック
4桁の得意先コードに3桁,5桁のデータを与えるというように、項目の境界を間違えたデータを与えます。複数の項目を連続した文字列として入力するときの誤り発見をします。
同値分割法・境界値分析(リミットチェック、限界値チェック)
同値分割法とは、仕様からデータを同値クラス(意味のあるグループ)に分類し,各グループから代表値を選ぶ技法です。例えば10≦X≦20の条件があるとき,有効同値クラス (10~20)、無効同値クラス1(~9)、無効同値クラス2(21~)の3ケースを与える必要があるという考え方です。
 さらに厳密にテストするには、条件の境界であるX=9,10,20,21を与えることが必要です。このような分析を境界値分析といい、境界値分析によるテストをリミットチェックあるいは限界値チェックといいます。
 なお、「昨日までの売上金累計に今日の売掛金データを加えると信用限度をオーバーする」というようなチェックをリミットチェックということもあります。
論理チェック
例えば、「注文日が入力日以前の営業日のはずがない」とか「○○支店では△△商品を取り扱わない」などのチェックです。
シーケンスチェック,重複チェック
これらはプログラムでなくデータファイルのチェックで、順序正しく並んでいるか、重複はないかのチェックをします。小さい順に並んでいるファイルを入力とするプログラムに,順序が異なるファイルを入力したら,それを発見できるか。出力されたファイルが順序正しくなっているかなどの確認をします。
存在チェック(照合チェック)
例えば「売上データで得意先マスタに存在しない得意先コードを与えた」というように、他のファイルと照合するチェックです。
バランスチェック
例えば「仕訳データの借方と貸方の最終的な合計が異なる」というように、異なる処理による結果をチェックします。これは結合テストやシステムテストで行うのが一般的ですが、既に集計値がある場合に、明細データ以外に集計データの入力して入力誤りを発見するなど、単体テストでも行うことがあります。

●チェックデジット
 特に長い数字列のコードの場合は入力誤りをしがちです。それで、コードの末尾に1桁たチェック用の桁をもうけておき、例えばコードの各桁を加算したときの1の位の数字を入れておき、コード入力したときに計算をして、答が合致するかどうかをチェックする方法があります。そのチェック用の桁をチェックデジットといいます。
 POSシステムではJANコード(バーコード)をスキャンしますが、読み取りエラーを防ぐために、JANコードにはチェックデジットがつけられています。また、厳しく誤りを発見するために、複雑な計算方法を採用しています。

静的テスト

実際にプログラムを実行するのではなく、ソースプログラムやデータを机上で調べてテストするのを静的テストといいます。
 後に使用されない変数への代入などプログラムの静的解析ツールで検出できます。

●CASE(Computer Aided Software Engineering、コンピュータ支援ソフトウェア工学)
一般には、仕様書やUML図表からソースプログラムを自動作成するツールですが、これを用いてテストすることもできます。

結合テスト

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

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

スタブとドライバの図解
トップダウンテスト
上位のプログラムにデータを与えて,正しく下位プログラムが呼び出されるかというように,上位のプログラムからテストします。このとき,下位のプログラムが未完成のときは,ダミーのプログラムを用意することになります。そのダミープログラムをスタブといいます。
早期に全体の構成を把握して下位プログラムの仕様を確認できる利点があります。
ボトムアップテスト
呼び出される下位のプログラムを先にテストする方法です。上位のプログラムが未完成のときは,ドライバというダミープログラムを用います。
システム開発の当初から,単体のプログラミングと結合テストの並行作業ができる利点があります。

トップダウンとビトムアップを組み合わせたテストをサンドイッチテストといいます。また、複数のモジュールを結合させたプログラムを、全てのモジュールを組み合わせてから一気に動作検証するテストをビッグバンテストといいます。

システムテスト(総合テスト)

システム全体を通してテストします。システム要件定義、それをまとめた外部設計書、請負契約の場合は契約でのシステム仕様書の内容が正しく実現されているかを確認するテストです。単体テストと結合テストの段階は,開発者が主体になりますが,システムテスト(総合テスト)では,外部設計者(開発者と利用者が参加している)が主体になります。
 システムテストを狭義にとらえれば、システムとして正しく動作することの確認テストになりますが、広義に、受入れテストや移行テスト、さらには運用テストの一部(負荷テストなど)も含めた総合テストととらえることもあります。

受入れテスト(承認テスト)
利用者がこのシステムを受け入れるための確認テスト。これに合格することにより,システムが検収されます。システムテストの最終段階が承認テストになることもあります。
システム要件が満たされていることの確認ですのでシステムテストと同様なテストになりますが、利用者側が実際の運用と同様の条件でソフトウェアを使用し,正常に稼働することを確認することも目的なので、試運転期間を設けて、その間に不都合な個所を発見するというように、運用テストの一部を受入れテストで行うこともあります。
受入れテストの性格から取得者(発注者、利用者)が主体になりい,開発者は受入れを支援する体制になります。(不適切な例)

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

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

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

移行テスト
さらに細分化するならば、受入れから運用までの移行の円滑化を目的とした移行テストがあります。業務遂行の立場で安全性・効率性の観点から、既存システムから新システムへの切換え手順や切換えに伴う問題点を確認します。この実施とともに、利用者マニュアルを整備し,利用者への教育訓練を実施します。

運用テスト

実際に運用してみて,問題点を発見するテスト。半年とか1年の期間を設けて,この間に発見された誤りは開発者の責任で修正するのが通常です。
 ここでは、単にロジックが正しいことを確認するだけではなく,実務環境での総合的な観点からテストします。機能面のチェック以外に、システムの処理能力面でのテストが重視されます。

性能テスト
応答時間や一定時間内の処理量など、処理能力に関連する事項の確認テストです。通常の環境を対象にするのが通常ですが、以下の負荷テストや耐久テストを含めて性能テストということもあります。
負荷テスト(ストレステスト)
一度に大量のデータが発生しても処理できるかをテストします。想定される最大業務負荷に耐えられるかどうかの確認です。過酷の環境での性能テストだともいえます。
耐久テスト
負荷テストの一種ですが,長時間にわたって負荷状況がどのように変化するかを調査します。

ベンチマークテスト

性能テストの一つですが、コンピュータの処理性能を比較・評価するために行われるテストです。この分野の支援組織により、いろいろな典型的な処理について標準的なテストプログラムがあり、典型的なコンピュータ(OSも含む)構成での処理時間が公表されています。
 システムで採用しようとするコンピュータ環境で、システムと類似した処理内容の標準テストプログラムを実行した測定結果を上記の公表値と比較することにより、適切なコンピュータ構成を検討したり、処理効率を上げるべき重点個所を特定したりできます。
 このテストは運用中にテストするよりも、初期の段階でハードウェアを選択するために行うのが通常です。

レグレッションテスト(退行テスト、回帰テスト)

保守段階でのテストです。システムの修正や機能追加をしたとき,それが他の部分に影響を及ぼし、いままで正常に処理したいた部分でエラーになることがあります。それを確認するテストです。
 例えば、「日次処理の部分を変更して、それが正しく動作することは確認したのだが、月次処理への影響に気付かず、月次処理でエラーが発生した」といようなことが発生するのを防ぐためのテストです。

このような場合には、
 ・影響を及ぼすプログラムを特定することが難しい
    システムの可視化の徹底が必要
 ・短期間での解決が求められるので、正規の体制ではなく担当者個人で対処することになりやすい
    変更管理ルールの徹底が必要
など、テストの方法よりも管理体制が重要になります。

テストの管理

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

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


過去問題