Ｗｅｂ教材一覧＞ システムの調達

テストの種類・方法

学習のポイント

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

キーワード

単体テスト、ブラックボックステスト、網羅率（カバレッジ）、命令網羅、分岐網羅(判定条件網羅)、条件網羅、組合せテスト, 動的テスト、トレース、スナップショットダンプ、インスペクタ、アサーションチェック、ブラックボックステスト、テストデータ、型チェック、フォーマットチェック、リミットチェック、論理チェック、シーケンスチェック、照合チェック、バランスチェック、チェックデジット、静的テスト、レビュー、リバースエンジニアリング、デバッガ、構文チェッカ、コードオーディタ、モジュールインタフェースチェックツール、メトリクス計測、メモリダンプ（静的ダンプ）、結合テスト、トップダウンテスト、ボトムアップテスト、状態遷移テスト、システムテスト、受入れテスト、移行テスト、運用テスト、性能テスト、負荷テスト、耐久テスト、ベンチマークテスト、レグレッションテスト、退化テスト、バグ管理図、バーンダウンチャート

テストの体系

テストとは、開発したソフトウェアのエラーや不具合（バグbug＝虫）を発見して修正する（デバッグバグ（debug）することです。

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

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

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

テスト体系図 （拡大図）

テストの主体者

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

単体テスト

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

ホワイトボックステスト

ホワイトボックステストは、プログラムが正しく動くことを確認するテストです。プログラムの内部構造を知って，分岐命令や繰返し命令が正しく動くかをテストする方法です。

網羅性
ソースプログラムには多くの分岐やループなどがあります。それらのケースをくまなくテストすることが求められます。すべてのプログラムステップに対してテストで実行したステップの割合を網羅率（カバレッジ）といいます。また、カバーした結果を測定・評価することを、カバレッジ分析といい、それを支援するツールをテストデータ支援ツールといいます。

テストケースの設計方法には、命令網羅、分岐網羅（判定条件網羅）、条件網羅、判定条件・条件網羅、複数条件網羅があります。すべてのケースが網羅できるのは複数条件網羅だけで、それ以外はテストされないケースが残ります。
　「if (A>0 or B>0) 処理１ else 処理２」のプログラム（右図はそのフローチャート）を例にします。

  • 命令網羅
    すべての命令を少なくとも１回は実行
    　　（１）Ａ＞０、Ｂ≦０　→Yes →処理１を実行
    　　（２）Ａ≦０、Ｂ≦０　→No　→処理２を実行
    欠点：この２組で網羅するので、「Ａ＞０、Ｂ＞０」「Ａ≦０、Ｂ＞０」のときのテストをしていない。このとき正しく実行されるか否か不明。「if (A>0) ～」と間違っていても発見できない。
  • 分岐網羅(判定条件網羅)
    判定条件の真偽（全ての分岐）を少なくとも１回は実行される。
    　　（１）Ａ＞０、Ｂ≦０　→Yes
    　　（２）Ａ≦０、Ｂ≦０　→No
    欠点：命令分岐と同じ。
  • 条件網羅
    判定条件が複数ある場合に、それぞれの条件が真・偽となるテストケース。
    　　（１）Ａ＞０、Ｂ≦０
    　　（３）Ａ≦０、Ｂ＞０
    欠点：この２組であっても、Ａ、Ｂがそれぞれ真・偽となるテストケースになるが、処理２を実行するテストケースがない
  • 判定条件・条件網羅
    判定条件網羅と条件網羅を組み合わせてテストケース
    　　（１）Ａ＞０、Ｂ≦０　→Yes
    　　（２）Ａ≦０、Ｂ≦０　→No
    　　（３）Ａ≦０、Ｂ＞０　→Yes
    欠点：これでYes/Noのケース、Ａの真偽・Ｂの真偽を網羅しているが、「Ａ＞０、Ｂ＞０」のテストケースがない。
  • 複数条件網羅
    判定条件のすべての可能な結果の組合せを網羅し、かつ、すべての命令を少なくとも1回は実行するようにテストケースを作成する。
    　　（１）Ａ＞０、Ｂ≦０　→Yes →処理１
    　　（２）Ａ≦０、Ｂ≦０　→No　→処理２
    　　（３）Ａ≦０、Ｂ＞０　→Yes →処理１
    　　（４）Ａ＞０、Ｂ＞０　→Yes →処理１
    　 これで、すべてのケースが網羅される。
組合せテスト
組合せテストとは、多数の入力条件の値をいろいろと組み合わせて実施するテストです。条件に用いる変数、各変数の条件数が大きいと、全体の条件数は、その組合せの数になるので、非常に大きくなります。カバー率を１００％にしようとすると、時間も費用もかかるので、実務的に不適切です。
　実務的には、何らかの合理的な制限を設けて、一部の組合せを設定し、それだけをテストすることになります。その設定には実務の観点から重要な条件を抽出こともありますが、実験計画法の「オールペア法」や「直交法」を用いると、少ないテスト回数で１００％の網羅性を実現できることが証明されています。そのようなテスト方法を「組合せテスト」といいます。
　非常に魅力的な手段ではありますが、適用にあたっては高度な数学的知識と実務知識が必要です。

動的テストの支援

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

ブラックボックステスト

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

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

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

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

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

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

人的静的テスト

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

静的解析ツール

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

結合テスト

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

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

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

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

結合テストの対象として、上位プログラムでの入力指示や計算結果により呼び出す下位プログラムを特定したり、下位プログラム間で同様なことを行うことが多くあります。状況により呼び出すプログラムを図示するのが状態遷移図です。主に外部設計段階で作成されます。状態遷移図が正しく反映されていることを確認するテストを状態遷移テストといいます。結合テストの重要な部分です。

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

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

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

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

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

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

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

運用テスト

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

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

ベンチマークテスト

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

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

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

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

テストの管理

バグ管理図

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

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

バーンダウンチャート

burndownとは「全焼する,焼け落ちる」に意味です。ＸＰなどアジャイル開発でのプロジェクト管理に用いられます。イテレーション単位でプロジェクトの時間と残り作業量をグラフ化したものです。プロジェクトのバックログを縦軸に取り、時間を横軸に取り。次の３本の線が表示されます。


テスト方法論

ここまでは、テストの方法について記述してきました。ここでは、テストをソフトウェア開発プロジェクトのサブプロセスとして捉え、テストプロセスをどのように管理するかにつて記述します。

テストプロセスの特徴

テストプロセス体系

テストプロセスは、ソフトウェア開発プロジェクトのサブプロジェクトですから、プロジェクトマネジメントとして、ＰＤＣＡサイクルとして管理する必要があります。

共通フレームに「ソフトウェアテスト」と「ソフトウェア適格性確認テスト」がありますが、ここではソフトウェア開発プロジェクト内でのテストチームとして、実務的にテストをするときのプロセスとして記述します。

要件定義

テストの準備・計画

テスト環境の整備

テストの実行

テストプロセスの終了

ソフトウェア開発プロジェクト終了時に、テスト報告書として提出するのが通常