JPH1115693A - ソフトウェアのテスト装置および記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 ソフトウェアのテスト作業全体を自動化し、
テストをより効率的に行えるようにする。 【解決手段】 ソフトウェアのテストで行われる複数の
内部作業をそれぞれ実行する複数種類の内部作業手段
（テストツール）１０１〜１０５を、あるツールで使用
すべきテスト情報に変化があったときに上記ツールを起
動するように制御するテスト制御手段１０６を設け、あ
るテスト情報に変化があったときにそのテスト情報を用
いて処理を行うツールを起動して処理を実行し、さら
に、この処理により生成されたテスト情報を用いて処理
を行う他のツールを起動して処理を実行するというよう
にして、テスト制御手段１０６の制御により各ツール１
０１〜１０５を順次起動し、各種テスト情報を順次生成
しながらソフトウェアのテストを自動実行できるように
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はソフトウェアのテス
ト装置および記録媒体に関し、特に、プログラム開発工
程のテスト段階において、個々のモジュールについて単
体テストを行う際に使用するテスト装置に用いて好適な
ものである。

【０００２】

【従来の技術】近年、コンピュータシステムの利用はま
すます広がってきており、その勢いは留まるところを知
らない。これに伴い、これらのコンピュータシステムに
搭載するために開発されるソフトウェア（プログラム）
の量も急増している。そして、この開発工程の一環とし
て行うべきソフトウェアのテストも膨大な量となってき
ている。

【０００３】ところが、実際のソフトウェア開発工程で
は、最終的な製品の納期が決められる一方で、設計や製
造などのテスト以外の作業により多くの労力を要するた
め、テスト作業に十分な人的資源を投入することは現実
上困難な場合が多く、その効率化が望まれている。特
に、ソフトウェア中の個々のモジュール（プログラム部
品等）を他のモジュールと切り離して単独でテストする
単体テストは、その作業内容は繰り返しが多く比較的単
調で、自動化への要望が特に強い分野である。

【０００４】

【発明が解決しようとする課題】このような背景のも
と、単体テスト作業の自動化への試みが続けられてきて
いるが、従来、この自動化は、単体テストで行われる複
数の内部作業のうちのどれか１つ、あるいは幾つかの作
業だけに対象を絞って行われており、単体テスト作業全
体を通して行われることはなかった。

【０００５】すなわち、単体テストは、大別して、テス
ト対象を実行するためのテストドライバの作成、テスト
の際に使用するテストデータの作成、テストドライバを
利用してのテスト対象の実行、テスト実行結果の照合お
よびテスト結果報告の各内部作業から成るが、単体テス
トを支援するためのテストツールは、各内部作業毎、し
かもその多くはテスト実行作業を更に分割した作業ごと
に別個に開発されていた。

【０００６】特に、テスト評価作業を支援するためのツ
ールは、機能的に乏しいものであった。すなわち、従来
のテスト評価支援ツールでは、テスト実行結果の照合
（テスト実行出力と、ソフトウェア仕様書などから期待
される正解値（以下、これをテストオラクルと呼ぶ）と
の照合）を行い、この照合結果を出力するのみであり、
実際の製品において問題となる可能性のある他の要素、
例えばメモリエラー等のチェックを含めた総合的な評価
は行えなかった。

【０００７】図２は、単体テスト作業の一般的な流れを
示す図である。ここで、図２に示した各手段３０１〜３
０５は、各々別個に開発されたテストツールが持つ機能
であるとする。また、本明細書では、符号２０１〜２０
７で示す各情報を“テスト情報”と総称することにす
る。

【０００８】まず最初に、ソフトウェア開発者は、テス
トデータ生成手段３０１を用いて、テストデータ２０２
をテスト対象ソースファイル２０１から生成する。ま
た、単体テストを行う際には、テスト対象はそれ単独で
は動作できないので、上記テストデータ２０２の他に、
そのテスト対象を動かすためのテストドライバが必要に
なる。そのためソフトウェア開発者は、テストドライバ
生成手段３０２を用いて、テストドライバソースファイ
ル２０３を上記テスト対象ソースファイル２０１から生
成する。

【０００９】次にソフトウェア開発者は、テスト実行手
段３０３を用いて、テスト対象ソースファイル２０１か
ら生成したテストプログラムを実行する。このときテス
ト実行手段３０３は、テスト対象ソースファイル２０１
とテストドライバソースファイル２０３とからテストプ
ログラム（実行ファイル）を作成し、テストデータ２０
２を用いてそのテストプログラムを実行する。そして、
そのテスト実行結果２０４を出力する。

【００１０】また、テスト結果照合手段３０４は、テス
ト実行手段３０３から出力されるテスト実行結果２０４
とテストオラクル２０５（これは、テストデータ２０２
をもとにソフトウェア開発者が作成する）とを照合し
て、テスト照合結果２０６として出力する。

【００１１】さらに、テスト結果レポート作成手段３０
５は、上記テスト照合結果２０６にテスト条件などの情
報を付加してテスト結果レポート２０７として出力す
る。ソフトウェア開発者は、このテスト結果レポート２
０７を参照して、作成したソフトウェアに欠陥があった
かどうかを検証する。そして、欠陥を発見した場合はそ
の欠陥を除去するためにプログラムのデバッグを行い、
デバッグ後のプログラムについてもう一度単体テストを
実行する。

【００１２】また、テスト結果レポート２０７上では誤
りを発見できない場合でも、そのとき用いたテストデー
タ２０２ではたまたま誤りが発生しなかったということ
も考えられるため、別のテストデータを作って再び単体
テストを行う。そして、このような処理を繰り返して行
い、テストが十分であると判断した時点でテストを終了
する。このようにして、ソフトウェア仕様書の通りのプ
ログラムを作成していく。

【００１３】ところが、図２に示した各手段（各テスト
ツール）３０１〜３０５は、それらの受け持つ作業が単
体テストの全作業中の一部分であり、別々の目的で開発
されているため、ある作業を受け持つツールと別の作業
を受け持つツールとの間で伝えられるべきテスト情報の
種類が食い違ったり、情報の形式が異なったりすること
が多かった。また、１つのツールで支援される範囲は、
単体テスト全体に及ぶことはなかった。

【００１４】したがって、人間がテスト情報の過不足を
調整したり、ツール間でテスト情報を伝達するためにデ
ータファイルの形式を変換したりする必要があった。ま
た、テスト作業の進行に合わせて、その都度人間が適切
なツールを選択し、それを操作する必要があった。さら
に、上述のように単体テストは同じ作業を何回も繰り返
して行うが、以前に行ったテストの際に使用したテスト
情報がそのまま使えるにも拘らず作り直してしまうこと
が多く、余計な労力がかかっていた。

【００１５】しかしながら、これら人間によって行われ
ている作業は、本来余分なものであり、各内部作業が自
動化されたとしても依然として単体テスト作業に多大な
労力がかかってしまっているという問題があった。ま
た、これらの作業を人間が行うことによって人為的なミ
スが生じる恐れもあり、テストの信頼性に欠けるという
問題もあった。さらに、テスト評価作業では、テスト実
行結果とテストオラクルとを比較することができるだけ
で、総合的なテスト評価を行うことができないという問
題もあった。

【００１６】本発明は、このような問題を解決するため
に成されたものであり、ソフトウェアのテスト作業全体
を自動化し、テストをより効率的に行えるようにすると
ともに、テスト評価作業の品質を向上させることを目的
とする。例えば、単体テストの各内部作業間でのテスト
情報の伝達を正確に行えるようにし、これにより、単体
テスト全体の作業効率と作業品質とを共に向上させるこ
とを目的とする。

【００１７】

【課題を解決するための手段】本発明によるソフトウェ
アのテスト装置は、ソフトウェアのテストで行われる一
連の内部作業をそれぞれ実行し、各内部作業に対応した
テスト情報を出力する複数種類の内部作業手段を備えた
ソフトウェアのテスト装置であって、上記複数種類の内
部作業手段を制御し、任意の内部作業手段で使用すべき
テスト情報に変化があったときに上記任意の内部作業手
段を起動するようにするテスト制御手段を設けたことを
特徴とする。ここで、上記複数種類の内部作業手段間で
伝達される各種テスト情報は、情報形式が統一されてい
る。

【００１８】本発明の他の特徴とするところは、上記複
数種類の内部作業手段間で伝達される各種テスト情報を
一括して格納するテスト情報格納手段を備え、上記テス
ト制御手段は、上記テスト情報格納手段に格納される各
種テスト情報の変化を見て上記複数種類の内部作業手段
を制御することを特徴とする。

【００１９】上記複数種類の内部作業手段は、例えば、
テスト対象ソースファイルからテストデータを自動生成
するテストデータ生成手段と、上記テスト対象ソースフ
ァイルからテストドライバソースファイルを自動生成す
るテストドライバ生成手段と、上記生成されたテストド
ライバおよびテストデータを用いて上記テスト対象ソー
スファイルのテストを自動実行するテスト実行手段と、
上記テスト実行手段のテスト実行結果とあらかじめ作成
されたテストオラクルとを照合するテスト結果照合手段
と、上記テスト結果照合手段の出力に基づいてテスト結
果レポートを作成するテスト結果レポート作成手段とで
構成される。

【００２０】ここで、上記テスト制御手段は、例えば、
上記テスト対象ソースファイルに変化があったときに、
上記テストドライバ生成手段を起動するように制御す
る。この場合において、上記テスト対象ソースファイル
の少なくとも入出力インタフェース部分に変化があった
ときに、上記テストドライバ生成手段を起動するように
制御しても良い。

【００２１】また、上記テストデータ生成手段における
テストデータ生成方法を指定するためのテストデータ生
成方法指定手段を備え、上記テスト制御手段は、上記テ
スト対象ソースファイルに変化があったか、上記テスト
データ生成方法の指定に変化があったときに、上記テス
トデータ生成手段を起動するように制御する。この場合
において、上記テスト制御手段は、テスト対象ソースフ
ァイル中の少なくともテストデータ生成に用いられる部
分に変化があったときに、テストデータ生成手段を起動
するように制御しても良い。

【００２２】また、上記テスト制御手段は、上記テスト
対象ソースファイルに変化があったか、上記テストドラ
イバソースファイルに変化があったか、上記テストデー
タに変化があったときに、上記テスト実行手段を起動す
るように制御する。また、上記テスト実行手段より出力
されるテスト実行結果に変化があったか、上記テストオ
ラクルに変化があったときに、上記テスト結果照合手段
を起動するように制御する。また、上記テスト結果照合
手段より出力されるテスト照合結果に変化があったとき
に、上記テスト結果レポート作成手段を起動するように
制御する。

【００２３】本発明のその他の特徴とするところは、上
記複数種類の内部作業手段は、テスト対象のプログラム
内に潜むメモリ処理関連のバグを検出するメモリエラー
検出手段と、上記テスト対象のプログラムに対してどの
程度テストが達成しているかを定量的に検出するテスト
進捗検出手段と、の少なくとも一方を更に備え、上記テ
スト結果照合手段の出力に加えて、上記メモリエラー検
出手段の出力および上記テスト進捗検出手段の出力の少
なくとも一方を統合して評価を行うテスト評価手段を備
えたことを特徴とする。

【００２４】ここで、上記テスト評価手段は、上記テス
ト結果照合手段の出力、上記メモリエラー検出手段の出
力、上記テスト進捗検出手段の出力の各記載内容を適切
な形式にまとめ、１つのファイルとして出力するように
しても良い。

【００２５】また、本発明のコンピュータ読み取り可能
な記録媒体は、ソフトウェアのテストで行われる一連の
内部作業をそれぞれ実行し、各内部作業に対応したテス
ト情報を出力する複数種類の内部作業手段を備えたソフ
トウェアのテスト装置において、上記複数種類の内部作
業手段を制御し、任意の内部作業手段で使用すべきテス
ト情報に変化があったときに上記任意の内部作業手段を
起動するようにするテスト制御手段としてコンピュータ
を機能させるためのプログラムを記録したことを特徴と
する。

【００２６】本発明は上記技術手段より成るので、ある
テスト情報に変化があると、そのテスト情報を用いて処
理を行う内部作業手段がテスト制御手段の制御により起
動され、処理が実行される。そして、この処理により生
成されたテスト情報が新規なものであれば、この生成さ
れたテスト情報を用いて処理を行う他の内部作業手段が
起動され、処理が実行される。このようにして、テスト
制御手段の制御により各内部作業手段が順次起動され、
各種テスト情報を順次生成しながらソフトウェアのテス
トが自動実行されていくようになる。

【００２７】このとき、各内部作業手段間で伝達される
テスト情報の形式は統一されているので、各種テスト情
報の形式統一が図られ、ユーザが形式統一のためにデー
タの過不足を調整したり変更を加えたりしなくても、各
内部作業手段でテスト情報を有効に利用してテストを自
動実行することが可能となる。

【００２８】本発明の他の特徴によれば、複数種類の内
部作業手段間で伝達される各種テスト情報はテスト情報
格納手段に一括して格納され、テスト制御手段により一
元管理されるので、例えば再テストを行う場合などにお
いて、以前に生成されたテスト情報と同じものが使える
ときには、該当する内部作業手段は起動されず、テスト
情報格納手段に既に格納されているものを再利用するこ
とが可能となる。

【００２９】本発明のその他の特徴によれば、テスト評
価作業において、テスト実行結果とテストオラクルとを
比較した結果だけでなく、テスト対象のプログラム内に
潜むメモリ処理関連のバグの検出結果や、テスト対象の
プログラムに対してどの程度テストが達成しているかの
定量的な検出結果が合わせて評価されるようになるの
で、実際の製品に合わせた総合的なテスト評価を行うこ
とが可能となる。

【００３０】

【発明の実施の形態】以下に、本発明の一実施形態を図
面に基づいて説明する。なお、図２で説明した単体テス
ト作業における符号２０１〜２０７の各テスト情報は、
本実施形態においても、情報の形式が統一されているこ
とを除けば同様の情報であるので、ここでは同一符号を
用いることとする。各テスト情報の形式についての説明
は後述する。

【００３１】図１は、本発明の第１の実施形態によるソ
フトウェアのテスト装置の機能構成を示すブロック図で
ある。図１に示すように、本実施形態のソフトウェアの
テスト装置は、テストデータ生成手段１０１と、テスト
ドライバ生成手段１０２と、テスト実行手段１０３と、
テスト結果照合手段１０４と、テスト結果レポート作成
手段１０５と、テスト制御手段１０６と、テスト情報格
納手段１０７と、テストデータ生成方法指定手段１０８
とを備えており、これらは、例えばＣＰＵ、ＲＯＭおよ
びＲＡＭなどからなるマイクロコンピュータにより構成
されている。これら各手段のうち、１０１〜１０５で示
す各手段は、ソフトウェアの単体テストで行われる一連
の内部作業をそれぞれ実行する内部作業手段（テストツ
ール）として機能する。

【００３２】すなわち、上記テストデータ生成手段１０
１は、テスト対象ソースファイルからテストデータを自
動生成するものである。テストドライバ生成手段１０２
は、上記テスト対象ソースファイルからテストドライバ
ソースファイルを自動生成するものである。テスト実行
手段１０３は、上記テスト対象ソースファイルとテスト
ドライバソースファイルとからテストプログラムを作成
し、上記生成したテストデータを用いてテストプログラ
ムを自動実行するものである。テスト結果照合手段１０
４は、上記テスト実行手段１０３のテスト実行結果と、
あらかじめユーザにより作成されたテストオラクルとを
照合するものである。また、テスト結果レポート作成手
段１０５は、上記テスト結果照合手段１０４の出力に基
づいてテスト結果レポートを作成するものである。

【００３３】なお、図１の各手段１０１〜１０５は、図
２に示した各手段３０１〜３０５と機能的には同じであ
るが、テスト制御手段１０６およびテスト情報格納手段
１０７とのインタフェースを持つ点で異なっている。ま
た、図１の各手段１０１〜１０５を用いて行う単体テス
ト全体の流れも図２に示した流れと同様であるが、図２
に示した各種テスト情報２０１〜２０７は、本実施形態
では全てテスト情報格納手段１０７に格納されてテスト
制御手段１０６により管理され、必要に応じて読み出さ
れるようになっている。

【００３４】上記テスト制御手段１０６は、ユーザから
ソフトウェアに対するテスト実施指示を受けると、上述
の各テストツール１０１〜１０５を下記のように制御す
る。すなわち、あるツールで使用すべきテスト情報に変
化があったときに、そのツールを起動するように制御す
る。つまり、上記テスト情報格納手段１０７に格納され
る各種テスト情報に変化があったかどうかを監視し、ど
のテストツールを起動するか、つまりどのテスト情報を
新しく作らなければならないかを決定する。

【００３５】例えば、テスト制御手段１０６は、テスト
対象ソースファイル２０１が新規登録、変更されている
ときに、テストドライバ生成手段１０２を起動するよう
に制御する。なお、テストドライバは、テスト対象ソー
スファイル２０１の入出力インタフェース部分に変化が
なければ同じものが使えるので、本実施形態では、テス
ト対象ソースファイル２０１の少なくとも入出力インタ
フェース部分に変化があったときに、テストドライバ生
成手段１０２を起動するように制御する。

【００３６】また、上記テスト制御手段１０６は、テス
ト対象ソースファイル２０１が新規登録、変更されてい
るか、テストデータ２０２の生成方法の指定が変更され
ているときに、テストデータ生成手段１０１を起動する
ように制御する。テストデータ生成手段１０１は、テス
トデータ２０２を生成するための方法を幾つか備えてお
り、ユーザは、このテストデータ生成手段１０１におけ
るテストデータ生成方法を、テストデータ生成方法指定
手段１０８を使って指定することができる。なお、本実
施形態では、テストデータの生成においてテスト対象ソ
ースファイル２０１の入出力インタフェースの情報のみ
を用いているので、テスト対象ソースファイル２０１の
少なくとも入出力インタフェース部分に変化があったと
きに、テストデータ生成手段１０１を起動するように制
御する。

【００３７】また、上記テスト制御手段１０６は、テス
ト対象ソースファイル２０１が新規登録、変更されてい
るか、テストドライバソースファイル２０３が新規生
成、変更されているか、上記テストデータ２０２が新規
生成、変更されているときに、テスト実行手段１０３を
起動するように制御する。

【００３８】また、上記テスト制御手段１０６は、テス
ト実行結果２０４が新規生成、変更されているか、テス
トオラクル２０５が新規生成、変更されているときに、
テスト結果照合手段１０４を起動するように制御する。
また、上記テスト制御手段１０６は、テスト照合結果２
０６が新規生成、変更されているときに、テスト結果レ
ポート作成手段１０５を起動するように制御する。

【００３９】テスト制御手段１０６により起動されたテ
ストツールは、その処理で必要となるテスト情報をテス
ト情報格納手段１０７から取り込み、取り込んだ情報を
用いて処理を行う。そして、これにより生成したテスト
情報を再びテスト情報格納手段１０７に格納する。この
ようにして、各テストツール１０１〜１０５間で各種テ
スト情報がテスト情報格納手段１０７を介して伝達され
ていく。

【００４０】以下、図１に示した本実施形態によるソフ
トウェアのテスト装置の動作を、図３〜図５に示す具体
例を参照しながら説明する。図３は、テスト対象ソース
ファイルを新規に登録した場合の動作を説明するための
図である。すなわち、まず最初に、図３（ａ）に示すテ
スト対象ソースファイル２０１_-1を新規登録したとす
る。なお、ここでは説明を分かりやすくするために、一
例として四捨五入を行う簡単なプログラムを示してい
る。

【００４１】このようにテスト対象ソースファイル２０
１_-1が新規登録されたので、ユーザからテスト実施の指
示があったときにテスト制御手段１０６は、テストデー
タ生成手段１０１とテストドライバ生成手段１０２とを
起動する。これにより、テストドライバ生成手段１０２
は、テスト対象ソースファイル２０１_-1から図３（ｂ）
に示すようなテストドライバソースファイル２０３_-1を
自動生成し、テストデータ生成手段１０１は、同じくテ
スト対象ソースファイル２０１_-1から図３（ｃ）のよう
なテストデータ２０２_-1を自動生成する。なお、ここで
は５つのテストデータを生成しているが、この数には限
定されない。

【００４２】このようにしてテストドライバソースファ
イル２０３_-1とテストデータ２０２_-1とが新規生成され
たので、次にテスト制御手段１０６は、テスト実行手段
１０３を起動する。テスト実行手段１０３は、新規生成
されたテストドライバソースファイル２０３_-1とテスト
データ２０２_-1とを用いてテストを実行する。このとき
テストドライバは、図３（ｃ）に示したテストデータを
１個読み込んではテストプログラムを１回実行するとい
う処理を５つのテストデータについて順次行うことによ
り、図３（ｄ）に示すテスト実行結果２０４_-1を生成す
る。

【００４３】上記テスト実行結果２０４_-1が生成された
ら、次にテスト制御手段１０６はテスト結果照合手段１
０４を起動する。テスト結果照合手段１０４は、図３
（ｄ）に示したテスト実行結果２０４_-1と、ユーザによ
りあらかじめ生成された図３（ｅ）に示すテストオラク
ル２０５_-1とを照合し、図３（ｆ）に示すようなテスト
照合結果２０６_-1を自動生成する。ここでは、第４番目
のテストデータを用いたときに不一致が生じたので、そ
の部分が誤り（fail）として出力されている。

【００４４】次に、テスト制御手段１０６は、上述のよ
うにしてテスト照合結果２０６_-1が新規生成されたこと
に対応して、テスト結果レポート作成手段１０５を起動
する。テスト結果レポート作成手段１０５は、図３
（ｆ）に示したテスト照合結果２０６_-1から図３（ｇ）
に示すテスト結果レポート２０７_-1を自動生成する。テ
スト結果レポートは、例えばテスト実施日（date）、実
施者（user）、実施マシン（machine ）、使用オペレー
ティングシステム（OS）などのテスト条件を付加してテ
スト結果（result）を示したものである。なお、付加す
るテスト条件は、これらのものに限定されない。

【００４５】以上のように、テスト対象ソースファイル
２０１_-1を新規登録した場合は、テスト制御手段１０６
は各テストツール１０１〜１０５を順次起動し、テスト
情報２０２_-1〜２０７_-1（テストオラクル２０５_-1を除
く）を順次生成しながら単体テストを自動実行してい
く。このとき各種テスト情報２０１_-1〜２０７_-1は、上
述したように全てテスト情報格納手段１０７に格納さ
れ、必要に応じて読み出されるようになっている。

【００４６】ここで注目したいのは、図３（ｄ）〜
（ｆ）に示したように、格納されるテスト情報の形式が
統一されているということである。すなわち、本実施形
態では、データの始めに＃とデータ番号とを書き、その
後に実際の数値を書くというようにしてテスト情報の形
式を統一している。これにより、各ツール間で伝達され
るテスト情報の形式統一が図られ、ユーザが形式統一の
ためにデータの過不足を調整したり変更を加えたりしな
くても、テスト情報を有効に利用することが可能とな
る。なお、ここで示したテスト情報の形式はあくまでも
一例に過ぎず、形式が統一されているのであればどのよ
うな形式であっても構わない。

【００４７】上述の図３の例では、図３（ａ）に示した
テスト対象ソースファイル２０１_-1中に誤りがあったた
めに、図３（ｇ）のテスト結果レポート２０７_-1は、テ
スト実行結果に誤りが発生したものとして出力されてい
る。したがって、この場合ユーザは、テスト対象ソース
ファイル２０１_-1を検証し、エディタなどを用いて誤り
があった部分を修正する必要がある。

【００４８】図４は、ユーザが図３（ｇ）のテスト結果
レポート２０７_-1を見てデバッグなどを行い、図３
（ａ）のテスト対象ソースファイル２０１_-1を修正して
再びテストを行う場合の動作を説明するための図であ
る。ここでは、図３（ａ）に示したテスト対象ソースフ
ァイル２０１_-1中の上から５行目と７行目とを修正し
て、図４（ａ）のようなテスト対象ソースファイル２０
１_-2を本実施形態のソフトウェアのテスト装置に与えた
とする。

【００４９】ここで、修正した図４（ａ）のテスト対象
ソースファイル２０１_-2は、修正前の図３（ａ）のテス
ト対象ソースファイル２０１_-1と入出力インタフェース
部分は変化していない。したがって、この場合テスト制
御手段１０６は、テストドライバ生成手段１０２を起動
しない。上述したように、各種テスト情報はテスト情報
格納手段１０７に一括して格納され、テスト制御手段１
０６により一元管理されているので、以前に生成したテ
ストドライバソースファイル２０３_-1をそのまま再利用
することができる。

【００５０】また、上述のように、修正した図４（ａ）
のテスト対象ソースファイル２０１_-2は、修正前の図３
（ａ）のテスト対象ソースファイル２０１_-1と入出力イ
ンタフェース部分が変化していないので、この場合テス
ト制御手段１０６は、テストデータ生成手段１０１も起
動していない。そして、以前に生成したテストデータ２
０２_-1をそのまま再利用するようにしている。

【００５１】しかし、テスト対象ソースファイル２０１
自体には修正が加えられているので、それに対応してテ
スト制御手段１０６は、テスト実行手段１０３を起動す
る。テスト実行手段１０３は、１回目のテスト実行時に
テスト情報格納手段１０７に格納されたテストデータ２
０２_-1とテストドライバソースファイル２０３_-1とを用
いてテストを実行し、図４（ｂ）に示すテスト実行結果
２０４_-2を生成する。上記テスト実行結果２０４_-2が生
成されたら、次にテスト制御手段１０６は、テスト結果
照合手段１０４を起動する。

【００５２】テスト結果照合手段１０４は、図４（ｂ）
に示したテスト実行結果２０４_-2と、図３（ｅ）に示し
たテストオラクル２０５_-1（テストデータ２０２_-1を再
利用しているので、テストオラクル２０５_-1も再利用す
ることができる）とを照合し、図４（ｃ）に示すような
テスト照合結果２０６_-2を自動生成する。ここでは、テ
スト対象ソースファイル２０１_-1の修正により不一致が
なくなり、全ての結果が正常（pass）として出力されて
いる。

【００５３】次に、テスト制御手段１０６は、上述のよ
うにしてテスト照合結果２０６_-2が新規生成されたこと
に対応して、テスト結果レポート作成手段１０５を起動
する。テスト結果レポート作成手段１０５は、図４
（ｃ）に示したテスト照合結果２０６_-2から図４（ｄ）
に示すテスト結果レポート２０７_-2を自動生成する。

【００５４】このように、本実施形態では、再テストを
行う場合などにおいて、以前に生成されたテスト情報と
同じものが使えるときには再度生成しないように制御さ
れ、テスト情報格納手段１０７に格納されているものが
読み出されるように制御される。これにより、以前に行
ったテストの際に使用したテスト情報（図４の例ではテ
ストデータ２０２_-1とテストドライバソースファイル２
０３_-1とテストオラクル２０５_-1）を再利用することが
でき、必要最低限のテスト情報だけを生成すれば良くな
り、新たに作業を行う労力を削減して単体テストの作業
効率を向上させることができる。

【００５５】なお、図４（ｄ）のようにテスト実行結果
に一応は誤りが発生していない場合でも、テストの信頼
性を増すために別のテストデータを作って再び単体テス
トを行うことが一般である。図５は、その場合の動作を
説明するための図であり、ここでは、ユーザがテストデ
ータ生成方法指定手段１０８を使ってテストデータ生成
方法を変更し、テストデータ２０２を生成し直した場合
を想定している。

【００５６】この場合、テスト対象は図４（ａ）のソー
スファイル２０１_-2と同一であるので、テスト制御手段
１０６はテストドライバ生成手段１０２を起動せず、図
３（ｂ）のテストドライバソースファイル２０３_-1を再
び利用する。一方、テスト制御手段１０６は、ユーザが
テストデータ生成方法指定手段１０８を使ってテストデ
ータ生成方法を変更したことに対応して、テストデータ
生成手段１０１を起動する。

【００５７】テストデータ生成手段１０１は、新しく指
定された生成方法に基づいて、テスト対象ソースファイ
ル２０１_-2から図５（ａ）のようなテストデータ２０２
_-2を自動生成する。なお、ここでは、６つのテストデー
タを生成している。この場合ユーザは、生成されたテス
トデータ２０２_-2からそれに対応した図５（ｃ）のテス
トオラクル２０５_-2を生成する。

【００５８】次に、テスト制御手段１０６は、テストデ
ータ２０２_-2が新規生成されたことに対応して、テスト
実行手段１０３を起動する。テスト実行手段１０３は、
新規生成されたテストデータ２０２_-2を用いてテストを
実行し、図５（ｂ）に示すテスト実行結果２０４_-3を生
成する。

【００５９】上記テスト実行結果２０４_-3が生成された
ら、次にテスト制御手段１０６は、テスト結果照合手段
１０４を起動する。テスト結果照合手段１０４は、図５
（ｂ）に示したテスト実行結果２０４_-3と、ユーザによ
りあらかじめ生成された図５（ｃ）に示すテストオラク
ル２０５_-2とを照合し、図５（ｄ）に示すようなテスト
照合結果２０６_-3を自動生成する。ここでも全ての結果
が正常（pass）として出力されている。

【００６０】次に、テスト制御手段１０６は、上述のよ
うにしてテスト照合結果２０６_-3が新規生成されたこと
に対応して、テスト結果レポート作成手段１０５を起動
する。テスト結果レポート作成手段１０５は、図５
（ｄ）に示したテスト照合結果２０６_-3から図５（ｅ）
に示すテスト結果レポート２０７_-3を自動生成する。

【００６１】以上のように、２回目のテストでは、テス
ト対象ソースファイル２０１_-1を新規に登録した場合の
１回目のテストに比べて、テストデータ２０２とテスト
ドライバソースファイル２０３とテストオラクル２０５
の生成を行わくても済み、３回目のテストでは、テスト
ドライバソースファイル２０３の生成を行わくても済
む。これにより、単体テストの作業効率を格段に向上さ
せることができる。

【００６２】次に、本発明の第２の実施形態について説
明する。上記第１の実施形態では、テスト評価作業を支
援する際に、テスト実行結果２０４とテストオラクル２
０５とを比較するだけであったが、以下に述べる第２の
実施形態では、例えば、メモリエラーの検出結果やテス
トカバレッジの計測結果を合わせて総合的にテスト結果
を評価するようにしている。テストカバレッジとは、テ
スト対象のプログラムに対するテストの達成度を定量的
に測定するための指標の１つである。

【００６３】図６は、本発明の第２の実施形態によるソ
フトウェアのテスト装置の機能構成を示すブロック図で
あり、図７は、本実施形態によるテスト装置を用いた単
体テスト作業の流れを示す図である。なお、図６および
図７において、図１および図２に示した符号と同一の符
号を付したものは同一のものであるので、これについて
の詳細な説明は省略する。

【００６４】図６に示すように、本実施形態のテスト実
行手段６０３は、テスト実行ツール６０３ａと、メモリ
エラー検出ツール６０３ｂと、カバレッジ計測ツール６
０３ｃとを備える。テスト実行ツール６０３ａは、図１
に示したテスト実行手段１０３と同様の機能を有するツ
ールである。すなわち、このテスト実行ツール６０３ａ
は、テスト対象ソースファイル２０１とテストドライバ
ソースファイル２０３とからテストプログラムを作成
し、別に生成されたテストデータ２０２を用いて上記テ
ストプログラムを自動実行する。

【００６５】また、メモリエラー検出ツール６０３ｂ
は、作成されたテストプログラム内に潜むメモリ処理関
連のバグを自動的に見つけ出すためのツールであり、図
７のようにメモリエラー検出結果７０１を出力する。ま
た、カバレッジ計測ツール６０３ｃは、テスト対象のプ
ログラムに対して、どの程度テストが達成しているかを
定量的に見定めることを自動的に行うためのツールであ
り、図７のようにカバレッジ計測結果７０２を出力す
る。何れも人間が行うのは非常に困難かつ面倒な作業で
あるが、これらのツールを使えば自動的に行うことがで
きる。

【００６６】また、テスト評価手段６０４は、単にテス
ト実行ツール６０３ａによるテスト実行結果２０４とテ
ストオラクル２０５との照合を行うだけでなく、メモリ
エラー検出ツール６０３ｂおよびカバレッジ計測ツール
６０３ｃがテスト実行時に出力するメモリエラー検出結
果７０１およびカバレッジ計測結果７０２等のテスト情
報を読み込み、それらを統合してテスト評価結果７０６
を作成する。

【００６７】すなわち、テスト評価手段６０４は、テス
ト実行結果２０４とテストオラクル２０５との照合結
果、メモリエラー検出結果７０１、およびカバレッジ計
測結果７０２の各ファイルの記載内容を適切な形式にま
とめ、１つのファイルとしてテスト評価結果７０６を出
力する。テスト結果レポート作成手段１０５は、テスト
評価手段６０４より出力されたテスト評価結果７０６に
基づいて、テスト結果レポート２０７を作成する。

【００６８】図８は、この総合的なテスト評価を行った
際のテスト結果レポート２０７の一例を示す図である。
この図８に示すように、テスト実行結果２０４とテスト
オラクル２０５との照合結果（テストケース結果一
覧）、メモリエラーの検出結果、テストカバレッジの計
測結果がそれぞれ示されるとともに、これらを総合的に
判断した結果が最上段にＰＡＳＳ／ＦＡＩＬの別で表さ
れている。

【００６９】このように、本実施形態によれば、単にテ
スト実行結果２０４とテストオラクル２０５との照合を
行うだけでなく、メモリエラー検出結果７０１やカバレ
ッジ計測結果７０２を加味して評価するテスト評価手段
６０４を設けたので、総合的でより詳細なテスト結果を
自動的に判定することができ、テスト評価作業の品質を
より向上させることができる。また、テスト作業者は、
総合判定結果である図８のようなテスト結果レポート２
０７の最上段の表示を見れば、良い結果が得られたかど
うかを直ちに判断することができる。

【００７０】なお、以上の実施形態では、単体テストを
行う場合を例にとって説明したが、本発明はこれに限定
されるものではない。例えば、単体テストの後に行われ
る単体間のインタフェースを検査するための結合テスト
（統合テスト）や、更にその後で行われるシステムテス
トにも適用することができる。

【００７１】また、以上の実施形態で説明した各手段と
してコンピュータのＣＰＵ、記憶装置等を動作させるよ
うに作成したプログラムを用いることによって、コンピ
ュータを上記テスト装置として使用することができる。
その場合、当該プログラムを情報記録媒体に記録し、そ
の情報記録媒体をコンピュータに読み込ませることで達
成できる。情報記録媒体の例としては、例えばＲＯＭ、
フロッピーディスク、ハードディスク、光ディスク、光
磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性の
メモリカード等を用いることができる。

【００７２】

【発明の効果】本発明は上述したように、ソフトウェア
のテストで行われる一連の内部作業をそれぞれ実行する
複数種類の内部作業手段を、ある内部作業手段で使用す
べきテスト情報に変化があったときに上記ある内部作業
手段を起動するように制御するテスト制御手段を設けた
ので、ソフトウェアのテスト作業全体を自動化すること
ができ、テスト内の各内部作業間で行われていたデータ
の過不足の調整や、自動化されていない作業を行うため
の人間の労力を大幅に削減することができる。しかも、
このように人間の作業を排除することにより、人為的な
ミスの入り込む余地をなくし、テスト作業の品質を向上
することもできる。

【００７３】また、本発明の他の特徴によれば、複数種
類の内部作業手段間で伝達される各種テスト情報を一括
して格納するテスト情報格納手段を設けたので、例えば
再テストを行う場合などにおいて、以前に行ったテスト
の際に使用したテスト情報を再利用することができ、同
じ作業を繰り返し行う労力を削減することができる。こ
れにより、プログラムの開発効率を著しく向上させるこ
とができる。

【００７４】本発明のその他の特徴によれば、テスト対
象のプログラム内に潜むメモリ処理関連のバグを検出す
るメモリエラー検出手段と、テスト対象のプログラムに
対してどの程度テストが達成しているかを定量的に検出
するテスト進捗検出手段との少なくとも一方を更に設
け、テスト結果照合手段の出力に加えて、メモリエラー
検出手段の出力およびテスト進捗検出手段の出力の少な
くとも一方を統合して評価を行うテスト評価手段を設け
たので、テスト評価作業において、テスト実行結果とテ
ストオラクルとを比較するだけでなく、メモリエラーの
検出結果や、どの程度テストが達成しているかの検出結
果を合わせて評価することで総合的なテスト評価を行う
ことができ、テスト評価の品質を向上させることができ
る。

【図面の簡単な説明】

【図１】本発明の第１の実施形態によるソフトウェアの
テスト装置の構成例を示す機能ブロック図である。

【図２】単体テストの全体的な作業手順を説明するため
の図である。

【図３】テスト対象ソースファイルを新規に登録した場
合におけるソフトウェアのテスト装置の動作を説明する
ための図である。

【図４】テスト対象ソースファイルを修正して再びテス
トを行う場合の動作を説明するための図である。

【図５】テストデータを変更して同一のテスト対象ソー
スファイルについて再びテストを行う場合の動作を説明
するための図である。

【図６】本発明の第２の実施形態によるソフトウェアの
テスト装置の構成例を示す機能ブロック図である。

【図７】第２の実施形態による単体テストの全体的な作
業手順を説明するための図である。

【図８】第２の実施形態において総合的なテスト評価を
行った際のテスト結果レポートの一例を示す図である。

【符号の説明】

１０１ テストデータ生成手段 １０２ テストドライバ生成手段 １０３ テスト実行手段 １０４ テスト結果照合手段 １０５ テスト結果レポート作成手段 １０６ テスト制御手段 １０７ テスト情報格納手段 １０８ テストデータ生成方法指定手段 ２０１ テスト対象ソースファイル ２０２ テストデータ ２０３ テストドライバソースファイル ２０４ テスト実行結果 ２０５ テストオラクル ２０６ テスト照合結果 ２０７ テスト結果レポート ６０３ テスト実行手段 ６０３ａ テスト実行ツール ６０３ｂ メモリエラー検出ツール ６０３ｃ カバレッジ計測ツール ６０４ テスト評価手段 ７０１ メモリエラー検出結果 ７０２ カバレッジ計測結果 ７０６ テスト評価結果

Claims (14)

【特許請求の範囲】
1. 【請求項１】 ソフトウェアのテストで行われる一連の
   内部作業をそれぞれ実行し、各内部作業に対応したテス
   ト情報を出力する複数種類の内部作業手段を備えたソフ
   トウェアのテスト装置であって、 上記複数種類の内部作業手段を制御し、任意の内部作業
   手段で使用すべきテスト情報に変化があったときに上記
   任意の内部作業手段を起動するようにするテスト制御手
   段を設けたことを特徴とするソフトウェアのテスト装
   置。
2. 【請求項２】 上記複数種類の内部作業手段間で伝達さ
   れる各種テスト情報は、情報形式が統一されていること
   を特徴とする請求項１に記載のソフトウェアのテスト装
   置。
3. 【請求項３】 上記複数種類の内部作業手段間で伝達さ
   れる各種テスト情報を一括して格納するテスト情報格納
   手段を備え、 上記テスト制御手段は、上記テスト情報格納手段に格納
   される各種テスト情報の変化を見て上記複数種類の内部
   作業手段を制御することを特徴とする請求項１または２
   に記載のソフトウェアのテスト装置。
4. 【請求項４】 上記複数種類の内部作業手段は、 テスト対象ソースファイルからテストデータを自動生成
   するテストデータ生成手段と、 上記テスト対象ソースファイルからテストドライバソー
   スファイルを自動生成するテストドライバ生成手段と、 上記生成されたテストドライバおよびテストデータを用
   いて上記テスト対象ソースファイルのテストを自動実行
   するテスト実行手段と、 上記テスト実行手段のテスト実行結果とあらかじめ作成
   されたテストオラクルとを照合するテスト結果照合手段
   と、 上記テスト結果照合手段の出力に基づいてテスト結果レ
   ポートを作成するテスト結果レポート作成手段とを含む
   ことを特徴とする請求項１〜３の何れか１項に記載のソ
   フトウェアのテスト装置。
5. 【請求項５】 上記テスト制御手段は、上記テスト対象
   ソースファイルに変化があったときに、上記テストドラ
   イバ生成手段を起動するように制御することを特徴とす
   る請求項４に記載のソフトウェアのテスト装置。
6. 【請求項６】 上記テスト制御手段は、上記テスト対象
   ソースファイル中の少なくとも入出力インタフェース部
   分に変化があったときに、上記テストドライバ生成手段
   を起動するように制御することを特徴とする請求項５に
   記載のソフトウェアのテスト装置。
7. 【請求項７】 上記テストデータ生成手段におけるテス
   トデータ生成方法を指定するためのテストデータ生成方
   法指定手段を備え、 上記テスト制御手段は、上記テスト対象ソースファイル
   に変化があったか、上記テストデータ生成方法の指定に
   変化があったときに、上記テストデータ生成手段を起動
   するように制御することを特徴とする請求項４に記載の
   ソフトウェアのテスト装置。
8. 【請求項８】 上記テスト制御手段は、上記テスト対象
   ソースファイル中の少なくともテストデータ生成に用い
   られる部分に変化があったときに、上記テストデータ生
   成手段を起動するように制御することを特徴とする請求
   項７に記載のソフトウェアのテスト装置。
9. 【請求項９】 上記テスト制御手段は、上記テスト対象
   ソースファイルに変化があったか、上記テストドライバ
   ソースファイルに変化があったか、上記テストデータに
   変化があったときに、上記テスト実行手段を起動するよ
   うに制御することを特徴とする請求項４に記載のソフト
   ウェアのテスト装置。
10. 【請求項１０】 上記テスト制御手段は、上記テスト実
    行手段より出力されるテスト実行結果に変化があった
    か、上記テストオラクルに変化があったときに、上記テ
    スト結果照合手段を起動するように制御することを特徴
    とする請求項４に記載のソフトウェアのテスト装置。
11. 【請求項１１】 上記テスト制御手段は、上記テスト結
    果照合手段より出力されるテスト照合結果に変化があっ
    たときに、上記テスト結果レポート作成手段を起動する
    ように制御することを特徴とする請求項４に記載のソフ
    トウェアのテスト装置。
12. 【請求項１２】 上記複数種類の内部作業手段は、テス
    ト対象のプログラム内に潜むメモリ処理関連のバグを検
    出するメモリエラー検出手段と、 上記テスト対象のプログラムに対してどの程度テストが
    達成しているかを定量的に検出するテスト進捗検出手段
    と、の少なくとも一方を更に備え、 上記テスト結果照合手段の出力に加えて、上記メモリエ
    ラー検出手段の出力および上記テスト進捗検出手段の出
    力の少なくとも一方を統合して評価を行うテスト評価手
    段を備えたことを特徴とする請求項４〜１１の何れか１
    項に記載のソフトウェアのテスト装置。
13. 【請求項１３】 上記テスト評価手段は、上記テスト結
    果照合手段の出力、上記メモリエラー検出手段の出力、
    上記テスト進捗検出手段の出力の各記載内容を適切な形
    式にまとめ、１つのファイルとして出力することを特徴
    とする請求項１２に記載のソフトウェアのテスト装置。
14. 【請求項１４】 ソフトウェアのテストで行われる一連
    の内部作業をそれぞれ実行し、各内部作業に対応したテ
    スト情報を出力する複数種類の内部作業手段を備えたソ
    フトウェアのテスト装置において、上記複数種類の内部
    作業手段を制御し、任意の内部作業手段で使用すべきテ
    スト情報に変化があったときに上記任意の内部作業手段
    を起動するようにするテスト制御手段としてコンピュー
    タを機能させるためのプログラムを記録したことを特徴
    とするコンピュータ読み取り可能な記録媒体。