JPH02103644A - ソフトウエア・モジュール・テスト方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔発明の技術分野〕 本発明はソフトウェアのテスト方法に関し、特にモジュ
ール単位でのテスト方法に関する。

〔従来技術およびその問題点〕

ソフトウェアの信頼性を高めるための一つの手段として
、充分なテストを開発のライフサイクル中でできるだけ
早期に行うことが挙げられる。

ある程度以上大規模なソフトウェアは階層構造をなす多
くのモジュールから構成されている。このような構造を
有するソフトウェアのテストを行う手法として、トップ
ダウン法、ボトムアップ法、サンドインチ法、ビッグパ
ン法（ｂｉｇ−ｂａｎｇｔｅｓｔｉｎｇ）などがある。

トップダウン法は、最上位のモジュールを先ずテストし
、その後はその直下のモジュールをテストが終わったモ
ジュールに付加してテストを行うという手続きを最下位
のモジュールの付加・テストまで繰り返す。すなわち、
このテストが終了した時点で、全モジュールのインテグ
レーションも終わっている。

ボトムアップ法は、トップダウン法とは逆に、最下位の
モジュールから始めて、上位のモジュールを付加しなが
らテストを進めるものである。

サンドインチ法は、トップダウン法とボトムアップ法の
折衷的なものであり、両方法を同時に進める。

これら３種類のテストにおいては、モジュールの作成と
テストを並行して行うためには、モジュールを作成する
順序が決まってしまう。例えば、トップダウン法では上
位のモジュールができない限り、下位のモジュールのテ
ストができない。そのため、一部のモジュールのスケジ
ュールの遅れが全体に影響しやすい。また、このように
インテグレーションとテストが同時進行する方法では、
インテグレーションが進んでくると大きくかつ複雑な動
作をするソフトウェアをテストすることになるので、障
害の発見やその切り分けが次第に困難になるという問題
がある。

これに対して、ビッグパン法では一つ一つのモジュール
について単体でテストを行うので、上述の開発スケジュ
ールの自由度や障害の発見・切り分けの問題は解消され
る。しかしながら、この方法には以下で説明するような
問題点があるため、多数のモジュールを含むソフトウェ
アの開発に適用するのには適さなかった。

ソフトウェアを構成するモジュールは上位側のモジュー
ルから呼び出され、また下位のモジュールを呼び出す、
すなわち他のモジュールと関連しながら動作している。

ビッグパン法ではモジュール単体でのテストを全てのモ
ジュールについて行うので、モジュール毎に当該モジュ
ールを直接呼び出すあるいはそれから呼び出されるモジ
ュールに代わるダミーのモジュール群等のテスト環境を
用意する必要がある。準備しなければならないテスト環
境はモジュール数が多くなると膨大なものとなり、テス
トに要するコストや時間が許容しかいはどのものになっ
てしまう。

また、従来のモジュール・テストでは、そのモジュール
の機能の代用特性として、モジュール内部の制御の流れ
の径路や分岐に関する情報を取得するという、いわゆる
ホワイトボックス・テストが採用されることが多かった
。しかし、ホワイトボックス・テストでは制御の流れは
見えるが情報の流れは見えないので、必ずしも満足でき
るものではなかった。一方、従来のモジュールに対する
ブラックボックス・テストでは、上位側から被試験モジ
ュール（以下、ＳＵＴと称する）を呼び出したときのこ
のＳＵＴからの応答を記録してそれを期待される応答と
比較していたが、ＳＵＴからのその下位側に対する呼び
出しに関する情報については特に記録する等の処理はな
されていなかった。そのため、ＳＵＴの挙動を外部から
観測して正しい動きをしているかを調べるブラックボッ
クス・テストとしては不充分なものであらた。

〔発明の目的〕

本発明は上述した従来技術の問題点を解消し、ＳＵＴの
環境に対する挙動をできるだけ多く調べることができる
モジュール・テスト方法を提供することを目的とする。

また、このようなモジュール・テスト方法において、テ
スト環境を自動的に生成してテスト・コストを低減する
ことも目的とする。

〔発明の概要〕

本発明の一実施例によれば、上述の目的を達成するため
のモジュール・テスト方法が提供される。

このため、実施例においては、ＳＵＴを呼び出すために
そのインターフェースへ渡された情報およびＳＵＴが他
のモジュールに対して行う呼び出しの情報の両者をＳＵ
Ｔの挙動を表す情報とする。

これによって、テスト環境から与えられるテスト・デー
タ等に対するＳＵＴの挙動を従来のテスト方法よりも充
分に把握することができる。

更に、上述のようなテストのためのテスト環境を自動的
に作成′するため、この実施例ではＳＵＴのインターフ
ェース情報（ＳＵＴが呼び出す下位のモジュールとのイ
ンターフェース情報も含む）からテスト・ドライバ（テ
スト環境のうちのＳＵＴを呼び出す側）とスタブ（ＳＵ
Ｔから呼び出される側）を自動的に作成する。シミュレ
ート・モードではＳ　Ｕ　Ｔを実際に動作させる代わり
に、ＳＵＴとテスト環境との間の入出力や他のモジュー
ルの呼び出し等の相互作用のテスト・データ（インター
フェースを介してＳＵＴへ与える値−３ＵＴへの入力）
および期待データ（ＳｔＪＴがインターフェースを介し
て外部へ渡す値＝ＳＵＴからの出力）を使用者が与える
。実行モードでは先に与えられたテスト・データに基づ
いてＳＵＴを実行し、そのテスト環境に対する作用（出
力、他のモジュールの呼び出し等）をやはり先に与えら
れた期待データと比較する。期待データと異なる場合に
はＳＵＴを修正したのち再度実行モードで動作させると
いうサイクルを、一致がとられるまで繰り返す。

〔発明の実施例〕

第１図に本発明の一実施例を概念的に示す。また、これ
と比較するために従来方法に基づいた場合のモジュール
・テストを第３図に概念的に示す。

第３図の従来例において、テスト担当者３０１は自分で
テスト・ドライバおよびスタブ３０３を作成し、これを
５ｔＪＴ３０５とともにコンパイル／リンクして実行可
能なテスト・プログラム３０７を作成する。次にテスト
・プログラム３０７にテスト・データ３０９を与えて実
行させる。テスト・プログラム３０７中にリンクされて
いるテスト・ドライバは同じくそこにリンクされている
ＳＵＴからの出力（関数の戻り値や参照渡しパラメータ
・グローバル変数への書き込み等）を実行結果としてフ
ァイルへ書き込む。テスト担当者３１１はこの実行結果
を期待データと照合し、不一致があれば５ＵＴ３０５に
不具合があるものとしてデバッグを行う。デバッグ完了
後、上述の過程を実行結果と期待データの一致がとれる
まで繰り返す。

これに対して、第１図に示す本発明の一実施例では、テ
スト担当者１０１はテスト・ドライバやスタブを自分で
作成する代わりに、５ＵＴ１０９のインターフェース情
報１０３をドライバ・スタブ自動生成プログラム１０５
へ与える。インターフェース情報１０３はＳＵＴを呼び
出す際のパラメータのリスト、ＳＵＴがどのようなグロ
ーバル変数を使用するか、またＳＵＴが呼び出すモジュ
ールのパラメータのリスト等を含んでおり、ＳＵＴとそ
の上位および下位のモジュールとの間で行われる入出力
のインターフェースを記述するものである。

次に自動生成されたテスト・ドライバおよびスタブ１０
７と５ＵＴ１０９をコンパイル・リンクしてテスト・プ
ログラム１１１を作成する。テスト・プログラム１１１
の内部の動作の概略を説明する図面を第２図に示す。テ
スト・プログラム１１０は第３図に示した従来技術とは
異なり、シミュレート・モードと実行モードの２つの動
作モードを持つ。

シミュレート・モードではテスト・プログラム１１１は
第２図（ａ）で説明されるような動作をする。同図にお
いて、テスト・ドライバ２０１はテスト担当者に対して
５ＵＴ１０９”　（コンパイル・リンクされたＳＵＴと
いうことを示すため、゛を参照番号に付加する）を呼び
出すためのＳＵＴへの入力、およびＳＵＴがその実行結
果として戻す出力の入力を要求する。テスト担当者はＳ
ＵＴへの入力のデータの要求に対しては対応するテスト
・データ１１３を、またＳＵＴからの出力のデータの要
求に対しては期待データ１１５を例えばコンソールから
与える。これらはそれぞれテスト・データ・ファイル１
１９と期待データ・ファイル１１７へ書き込まれる。

次にテスト・ドライバ２０１はテスト・ドライバの一部
分であるダミー・モジュール２０１−１に制御を移す。

ここでは、５ＵＴ１０９’がどのモジュールを呼び出す
かについてテスト担当者への問い合わせが行われる。最
初に呼び出されるべきモジュールをテスト担当者が指定
すると、ダミ−・モジュールはそれに対応するスタブ２
０３〜２０７を呼び出す。呼び出されたスタブは、シミ
ュレート・モードでは、丁度テスト・ドライバ２０１が
先に行ったように、ＳＵＴから呼び出されるべきモジュ
ールへ渡されるべきデータ（ＳＵＴからの出力データ）
とそのときそのモジュールがＳＵＴへ戻すデータ（ＳＵ
Ｔへの入力データ）をテスト担当者がコンソール等から
与えるように要求し、その入力が終わるとダミー・モジ
ュールへ制御を戻す。このとき、呼び出されるべきモジ
ュールを識別する情報およびＳＵＴからそのモジュール
へ渡されるべきものとしてテスト担当者から与えられた
データは期待データ・ファイル１１７へ、またこのモジ
ュールがＳＵＴへ渡すものとして与えられたデータはテ
スト・データ・ファイル１１９へ書き込まれる。

ダミー・モジュール２０１−１へ制御が戻ると、その次
に呼び出されるべきモジュールの指定の要求がテスト担
当者に対してなされ、上述のような動作が繰り返される
。このような手順を呼び出されるべきモジュール全てに
ついて行った後、モジュール呼び出しに関する情報の入
力の終了をダミー・モジュールへ通知する。これでシミ
ュレート・モードでの動作が完了する。

次に、第２図（ｂ）に示すような実行モードに入る。こ
のモードでは、５ＵＴ１０９’に入力すべきデータをテ
スト・ドライバ２０１がテスト・データ・ファイル１１
９から読み出して設定し、実際に５ＵＴ１０９’へ制御
を渡す。ＳＵＴの動作中に下位のモジュールを呼び出す
ことになると、ＳＵＴからはその呼び出すべきモジュー
ルと全く同じものに見える対応するスタブ２０３〜２０
７へ制御が移る。

実行モードで呼び出されたスタブは、ＳＵＴから渡され
たデータを実行結果ファイル１２１へ書き込むとともに
、ＳＵＴへ渡すべきデータをテスト・データ・ファイル
１１９から読み出して所要のパラメータや変数等への設
定を行った後に、ＳＵＴへ制御を移す。

このような５ＵＴ１０９’の内部動作および他のモジュ
ールの呼び出しが全て終了すると、制御がテスト・ドラ
イバ２０１へ戻る。テスト・ドライバは必要な後処理を
行った後、その動作を停止するか、あるいは制御を次の
段階の処理を行うルーチンへ移す。

もし５ＵＴ１０９”が期待通りの動作をしたのであれば
、この時点での期待データ・ファイル１１７と実行結果
ファイル１２１の内容は同一になっているはずであるの
で、両者を比較することにより、５ＵＴ１０９が正しく
作成されているか否かが判断できる（第１図１２３）。

あるいは、この比較を完全一致か否かではなく、必要に
応じである範囲内に収まっているか否かの判定としても
よい。

以下ではＳＵＴが一部仕様の拡張されたＰａ５ｃａ　１
の手続きあるいは関数であるとして、更に具体的な説明
を行う。勿論能の言語に対しても本発明は同様に適用し
うるし、またモジュールとしては、個々の手続き／関数
以外の別の独立してテストしうる単位でも良いことを注
意しておく。

ＳＯＴとして以下の手続き頭部を持った手続きを考える
。

ｐｒｏｃｅｄｕｒｅ　ＧｅｔＡＤＣ１２（ｐｉｎＬｉｓ
ｔ　：　ＰｉｎＬｉｓｔＴｙｐｅ；ｏｆｆｓｅｔ　：　
ｉｎｔｅｇｅｒ；　ｒｅｓｕｌｔＮｕｎ＋　：　ｉｎｔ
ｅｇｅｒＨｖａｒ　　ｒｅｓｕｌｔＡｒｒａｙ　　：　
　Ｒｅ５ｕｌｔＡｒｒａｙＴｙｐｅ）；ここで、Ｐｉｎ
ＬｉｓｔＴｙｐｅはユーザが定義した型であって、配列
やポインタ型以外のものである。また、Ｒｅ５ｕｌｔＡ
ｒｒａｙＴｙｐｅはやはりユーザがｒｅａ　ｌの配列と
して定義している型である。また、３番目のパラメータ
ｒｅｓｕｌｔＮｕ−は配列ｒｅｓｕｌｔＡｒｒａｙのサ
イズを表している。

この手続きＧｅｔＡＤＣ１２のインターフェース情報（
含インターフェース上で使用されている型の定義情報な
ど）をドライバ・スタブ自動生成プログラムに通すこと
によって、モジュール・テスト用のテスト・ドライバお
よびもしこの手続きが他のモジュールを呼び出す場合に
はそのモジュールの代用となるスタブが自動的に生成さ
れる。表１にこの手続きに対して生成されるテスト・ド
ライバの主要部である手続きのソース・コードを示す。

１：ＰＲＯＣＥＤｔｌＲＥ 表　　１ ｐｒｏｃ５３９； ＥＧＩＮ ｐｒｏｓ＋ｐｔｌｎ（″＝＝＝＝ＧｅｔＡ口Ｃｌ２＝＝
＝＝’）；ｐｆｉｓｔＲｅａｄｌｎ （’ｐｉｎＬｉｓｔ’、　ＰＩｉｓｔ［１］）；１ｖａ
ｒＲｅａｄｌｎ （’ｏｆｆｓｅｔ’、　　１ｖａｒ［１］）；１ｖａｒ
Ｒｅａｄｌｎ （’ｒｅｓｕｌｔＮｕｓ＋ｂｅｒ’、　　１ｖａｒ［２
コ）；ＩＦ　　ｓｉｍｕｌａｔｅＭｏｄｅ　　＜＞　　
Ｉ　　ＴＨＥＮＧｅｔＡＤＣ１２（Ｐ１ｉｓｔＬ１］、
　　１ｖａｒ［１］。

１ｖａｒ［２］、　ｒｖａｒａｒｒａｙ［１３）　；Ｉ
Ｆ　　ｓｉｍｕｌａｔｅＭｏｄｅ　　＝　　Ｉ　　ＴＨ
ＥＮｄｕｍｓ＋ｙＭｏｄｕｌｅ； ＩＦ　　ｓｉｍｕｌａｔｅＭｏｄｅ　　＝　　Ｉ　　Ｔ
ＨＥＮｒｖａｒａｒｒａｙＲｅａｄＩｎ　（’　ｒｅｓ
ｕＩ　ｔＡｒｒａｙ１５： １ｖａｒ［２］、　ｒｖａｒａｒｒａｙ（−１］）；ｒ
ｖａｒａｒｒａｙＷｒｉｔｅｌｎＲｅｓｕｌｔ（’ｒｅ
ｓｕｌｔＡｒｒａｙ’、　　１ｖａｒ［２１゜ｒｖａｒ
ａｒｒａｙ（月）： １６：　　ＥＮＤ。

なお、このようなテスト・ドライバを生成する際、ＳＵ
ＴであるＧｅｔＡＤＣ１２を呼び出すためのインターフ
ェースを指示するため、表２に示すような形のパラメー
タ情報をドライバ・スタブ自動生成プログラムに与える
。

５３９　　　　ＧｅｔＡＤＣ１２ ＰｉｎＬｉｓｔ　　　　　１ ｏｆｆｓｅｔ　　　　　　Ｔ ｒｅｓｕｌｔＮｕａ＋　　　Ｔ ｒｅｓｕｌｔＡｒｒａｙ　　０ 表２ ｐｒｏｃｅｄｕｒｅ　　　　ＰＡＳＣＡＬ　　　　４ａ
ｔｏｍ　　ＰｉｎＬｉｓｔＴｙｐｅ Ｂｔｔ）ｌＩＩｉｎｔｅｇｅｒ ａｔＯ＠　　ｉｎｔｅｇｅｒ ａｒｒａｙ　ｒｅａｌ　　　　３１６３８４表２に示す
パラメータ情報において、 最初の行 に置かれている項目は左からＳＵＴに与えられた識別番
号、ＳＵＴの名前、ＳＵＴが手続きが関数かを示す識別
子（もし関数ならここはｆｕｎｃｔｉｏｎとなる）、Ｓ
ＵＴの記述言語、パラメータの個数である。２行目から
５行目は個々のパラメータに関する情報である。左から
パラメータであることを示す識別子（もし値の引き渡し
が手続き頭部中のパラメータ以外に、グローバル変数を
介して行われる場合はここがＰではなくＧとなっている
行もここに含まれる）、手続き頭部でこのパラメータが
何番目に位置するかを示すシーケンス番号、このパラメ
ータを介して値を入力するのか（Ｔ）それとも値を出力
するのか（０）を示す識別子、パラメータの名前、この
パラメータが単一の変数か（ａｔｏｍ）配列か（ａｒｒ
ａｙ　）それともポインタが（ｐｏｉｎｔｅｒ　）を示
す識別子、パラメータ（配列の場合はその要素）の型で
ある。パラメータが任意のサイズをとることができる配
列の場合は更にその配列の実行時のサイズを指定する数
がパラメータ・リストの何番目に置かれているかを示す
指示子および配列の最大サイズを示す指示子が置かれる
。

なお、表２に示すような情報を人間が作って与える代わ
りに、被試験副プログラム（ＳＵＴ）の副プログラム頭
部の構文解析などを行うことにより、それに相当する情
報をドライバ・スタブ自動生成プログラム自身がＳＵＴ
から抽出してもよい。

なお、これを行う際には、ユーザが定義した型やグロー
バル変数等に関する情報はＳＯＴの外部にあるので、こ
れらの外部定義情報だけを含んだダミーのプログラム中
にＳＯＴを埋め込んだ形のものをドライバ・スタブ自動
生成プログラムに与えたりあるいはそのような情報だけ
を表２のような形で与える等の方法を用いることができ
る。

上述のように、ドライバ・スタブ自動生成プログラムは
スタブの自動生成も行う。ＳＵＴであるＧｅｔＡＤＣ１
２が、その頭部が以下のようになっている２つの副プロ
グラムＰｒｏｃＡ　、　ＦｕｎｃＢを呼び出すものとす
る： ｐｒｏｃｅｄｕｒｅ　ＰｒｏｃＡ（ｐａｒａｍｌ、ｐａ
ｒａｍ２：ｉｎｔｅｇｅｒ）；ｆｕｎｃｔｉｏｎ　　　
ＦｕｎｃＢ（ｐａｒａｍ３：ｉｎｔｅｇｅｒ）：ｒｅａ
ｌ；このとき、ＳＵＴの場合と同様に例えば表３に示す
ようなパラメータ情報を与える。

＄　６０１ ｐＨ ２Ｔ 表３ ＰｒｏｃＡ　　　ｐｒｏｃｅｄｕｒｅ　　　ＰＡＳＣＡ
Ｌ　　２ｐａｒａｍｌ　　ａｔｏｍ　　ｉｎｔｅｇｅｒ
ｐａｒａｗ２　ａｔｏｍ　ｉｎｔｅｇｅｒ宰６０２　　
　ＦｕｎｃＢ　　　ｆｕｎｃｔｉｏｎ　　　ＰＡＳＣＡ
Ｌ　　　ＩＰ　　１　１　　ｐａｒａＩＩＩ３　ａｔｏ
ｍ　ｉｎｔｅｇｅｒＰ　　ＯＯＦｕｎｃＢ　　ａｔｏｍ
　　ｒｅａｌここで、ＦｕｎｃＢのパラメータ情報の３
行目でそのシーケンス番号が０であるのは、これがこの
関数の戻り値であることを示すためである。ＧｅｔＡＤ
Ｃ１２のパラメータ情報の与え方に関して述べたように
、スタブを作成するための情報についてもこのような表
の形ではなく、例えば副プログラム頭部だけをＳＵＴの
ソースコードファイル中に書き込む等してもよい。

このようにパラメータ情報を与えることによりスタブが
生成される。ＦｕｎｃＢ用のスタブの主要部の例を表４
に示す。なお、ＰｒｏｃＡについて生成されるスタブも
同様であるので、その具体例は省略する。

表４ ＦＵＣＮＣＴＩＯＮ　ＦｕｎｃＢ（ｐａｒａｍ３　：　
ｉｎｔｅｇｅｒ）　：　ｒｅａｌ；ＡＲ ＲｅｔｕｒｎＶａｌｕｅ　：　ｒｅａｌ；ＢＥＧＩＮ ｐｒｏｍｐｔＩｎ　（’　＝＝＝＝ＦｕｎｃＢ＝＝＝＝
　’　）　；ＩＰ　（ｓｉｍｕｌａｔｅＭｏｄｅ　＜＞
　１）　ＴＨＥＮ　ＢＥＧＩＮｉｖａｒＷｒｉｔｅＲｅ
ｓｕｌｔ（’ｐａｒａｍ３’、　ｐａｒａ＋＊３）；Ｅ
ＮＤ ＥＬＳＥ　ＢＥＧＩＮ ｉｖａｒＲｅａｄｌｎ（’ｐａｒａｍ３″、　　ｐａｒ
ａｍ３）：１ｖａｒＷｒｉｔｅＲｅｓｕｌｔ（’ｐａｒ
ａｓ＋３’、　ｐａｒａｍ３）；ＥＮＤ　。

ｒｖａｒＲｅａｄｌｎ（’ＲｅｔｕｒｎＶａｒＲｅｔｕ
ｒｎＶａｌｕｅ）； ＦｕｎｃＢ　　：＝ ＲｅｔｕｒｎＶａｌｕｅ； ＥＮＤ。

また上述のようなインターフェース情報に基づいて生成
されるテスト ドライバの別の一部分を 構成するダミー・モジュールは例えば以下の表５のよう
になる。

表 ｐｒｏｃｅｄｕｒｅ　ｄｕｎ＋ｗｙＭｏｄｕｌｅ；ＡＲ ｐｒｏｃＩＤ　　： ｉｎｔｅｇｅｒ； ＢＥＧＩＮ ＥＰＥＡＴ ｉｖａｒＲｅａｄｌｎ （’Ｄｕｍｍｙ ｏｄｕｌｅ Ｎｏ。

９′ ｐｒｏｃｌＤ）； ＡＳＥ ｐｒｏｃＩＤ　０Ｆ ６０１　： ＰｒｏｃＡ　（ｉｖａｒ［１］＋ １ｖａｒ［２Ｊ）； ６０２　　：　　ｒｖａｒ［１］　　：＝　　ｆｕｎｃ
Ｂ（ｉｖａｒ（１コ）；０ＴＨＥＲＷＩＳＥ　　： ＩＦ　ｐｒｏｃｌＤ　＞　ＯＴＨＥＮ ｐｒｏｍｐｔｌｎ（’　　Ｗｒｏｎｇ ｎｕ＋＋ｂｅｒ！’）； ＥＮＤ。

ＵＮＴＩＬ　ｐｒｏｃｌＤ　＜＝　０；ＥＮＤ。

なお、これらインターフェース情報を用いてテスト・ド
ライバおよびテスト・スタブを自動生成すること自体は
コンパイラ、インタープリタ、トランスレータにおける
構文解析、解釈、コード生成等の技術そのものであって
当業者にとっては周知の事項であるので、テスト・ドラ
イバ・スタブ自動生成プログラムの実現手法についての
説明は省略する。

以下では、このようにして生成されたテスト・ドライバ
、スタブを使用してテストを行う手順を上述の表を参照
して説明する。

表１のコードで、シミュレート・モードのときはグロー
バル変数ｓ　ｉｍｕ　ｌａ　ｔｅＭｏｄｅの値を１にセ
ットし、実行モードのときには１以外にセットする。

このセット動作はテスト・ドライバ中の表１に示した手
続きｐｒｏｃ５３９の外側にある部分で行う。

表１の行３の手続きｐｒｏｍｐｔＩｎは、そのパラメー
タの文字列および復帰／改行コードを期待データ・ファ
イルへ格納する。

行４の手続きｐｌｉｓｔＲｅａｄｌｎはＳＵＴであるＧ
ｅｔＡＤＣ１２の最初のパラメータであるｐｉｎＬｉｓ
ｔの取り込みに関するものである。この手続きは、その
最初のパラメータを含むプロンプト： ｐｉｎＬｉｓｔ　？ をコンソールへ出力して（シミュレート・モードでは）
テスト担当者にどのテスト・データを入力すべきかを指
示した後、標準入力からの入力を型がＰｉｎＬｉｓＴｙ
ｐｅである２番目のパラメータにセットする。標準入力
は、シミュレート・モードではコンソールへ、また実行
モードではテスト・データ・ファイルへ接続されている
。また、１番目のパラメータの文字列、および２番目の
パラメータにセットされた値の文字列表現が出力される
。なおシミュレート・モードにおいては、１番目のパラ
メータの文字列および２番目のパラメータにセットされ
たデータの文字列表現は同時にテスト・データ・ファイ
ルにも書き込まれる。

行５．６の手続き１ｖａｒＲｅａｄ　Ｉｎも、取り扱う
変数の型がｉｎｔｅｇｅｒである点を除いては、ｐｌｉ
ｓｔＲｅａｄｌｎと全く同様の動作であり、ＧｅｔＡＤ
Ｃの２番目、３番目のパラメータの値の取り込みを行う
。他のｘｘｘＲｅａｄｌｎという名前の手続きも同様の
動作をする。なお、配列について同様の動作を行う手続
きｒｖａｒａｒｒａｙＲｅａｄ　Ｉｎでは、その２番目
のパラメータで値が取り込まれる配列のサイズを指定す
る。

シミュレート・モードの場合は行１２でダミー・モジュ
ールｄｕｓ＋＋ｓｙＭｏｄｕｌｅが呼ばれ、上述のよう
に、ＳＵＴから呼び出される下位のモジュールの識別番
号の入力を要求し、その指定されたモジュールに対応す
るスタブを呼び出してそのモジュールに期待値データお
よびテスト・データの収集・蓄積を行わせる。このｄｕ
ｍｍｙＭｏｄｕｌｅの動作、およびシミュレート・モー
ドにおけるスタブの動作は夫々表４、表５から明らかで
ある。

また、ＳＵＴからの出力については、シミュレート・モ
ードでは行１４でその出力（ここでは参照渡しされた４
番目のパラメータである配列中にＧｅｔＡＤＣ１２が書
き込むデータ）となるはずのデータの入力をテスト担当
者に要求する。これにより与えられたデータを行１５で
パラメータ名とともに期待データ・ファイルへ書き込む
。

シミュレート・モードの動作は以上の通りである。なお
、何通りかのテスト・データを一度にセットすることも
、表１の手続きｐｒｏｃ５３９を必要な回数だけ繰り返
す等すれば簡単にできる。

上述のようにテスト・データおよび期待データの蓄積が
終わった後、実行モードでテスト・プログラムを動作さ
せる。

このモードでは、表１の行１において、このＳＵＴが試
験されたことを示すためｐｒｏｍｐｔＩｎにより文字列
ＧｅｔＡＤＣ１２を実行結果ファイルへ格納する。

その後、行４〜行６により、先にテスト・データ・ファ
イルにセットされたテスト・データが読み出され、行９
でこれらの値が実パラメータとしてセットされたＧｅｔ
ＡＤＣ１２が実際に呼び出される。

ＧｅｔＡＤＣ１２からの出力（ｒｅｓｕｌｔＡｒｒａｙ
　）は行１５で実行結果ファイルへ記憶される。

実行モードでＧｅｔＡＤＣ１２が下位のモジュールを呼
び出そうとすると、実際にはそれに対応するスタブが呼
び出される。実行モードにおけるスタブの動作は表４か
られかるように、引き渡されたデータ（パラメータや、
場合によってはグローバル変数等）を実行結果ファイル
へ記憶するものである。

また、ＳＵＴであるＧｅｔＡＤＣ１２へ入力すべき値（
ここでは関数ＦｕｎｃＢＯ値）をテスト・データ・ファ
イルから読み出してセットすることも行われる。

ＳＵＴへ入力すべき値は、グーパル変数や参照渡しのパ
ラメータによって引き渡すこともあるが、その場合の値
のセットのやり方も同様である。

以上のようにして実行モードの動作の終了後、期待デー
タ・ファイルと実行結果ファイルを比較することにより
、ＳＵＴが期待通りの動作をしているか否かがわかる。

なお、全ての実行動作が終了した後に比較する代わりに
、個々の実行結果データが得られる毎に比較を行っても
よい。

比較の結果不一致があれば、ＳＵＴに修正を加える。こ
こでＳＵＴのインターフェースに変更がない限り、次回
のモジュール・テストに必要なことは、新しいＳＵＴを
コンパイルし、以前のテスト・ドライバおよびスタブと
リンクしたあと、既に作成されているテスト・データ・
ファイルおよび期待データ・ファイルを用いて直ちに実
行モードでテスト・プログラムを走らせることだけであ
る。これを期待データと実行結果の一致がとれるまで繰
り返すことにより、テストが完了する。

〔発明の効果〕

以上説明したように、本発明によれば、ＳＵＴ自体は何
ら変更せずに、その上位側に加えて下位側のインターフ
ェースから見た挙動も観測できるので、より完全なモジ
ュール・テストを行うことができる。更に、テスト・ド
ライバおよびスタブの自動生成により、従来困難と考え
られていた、大規模なプログラムのモジュール単位のテ
ストが容易に行えるようになる。また、テスト・プログ
ラムをシミュレーション・モードで動作させている間に
それからの質問に順番に答えて必要なデータを入力して
いくことにより、これら入力されたデータをテスト・デ
ータ・ファイルと期待データ・ファイルに自動的に振り
分けて夫々正しい順序で書き込むため、これらのデータ
の入力間違いが低減される。また、両ファイルを一度作
っておけば、ＳＵＴの修正とテストを繰り返す際に同じ
ものを毎回使用できるので、再テストを自動的に行うこ
とができる。再テストを行うことにより、不具合が正し
く修正されたかをチエツクするのみならず、その修正が
他の機能に影響を与えていないかも検査できる。これに
よりソフトウェアの信頼性が全体的に向上する。更に、
両ファイルに正しい順序でデータが書き込まれるため、
実行結果と期待データの照合も自動化することができる
。

【図面の簡単な説明】

第１図および第２図は本発明の一実施例を説明するため
の図、第３図は従来技術を説明する図である。 １０５：テスト・ドライバ・スタブ自動生成プログラム １０７：テスト・ドライバ／スタブ １０９：被試験モジュール １１７：期待データ・ファイル １１９：テスト・データ・ファイル １２１：実行結果ファイル ２０１：テスト・ドライバ ２０１−１：ダミー・モジュール ２０３．２０５．２０７：スタブ

Claims (3)

【特許請求の範囲】
1. （１）被試験モジュールが他のモジュールを呼び出すこ
   とに関する情報を含むテスト環境との相互作用情報を被
   試験モジュールから取得することを特徴とするソフトウ
   ェア・モジュール・テスト方法。
2. （２）第１のモードと第２のモードを有するテスト・ド
   ライバおよび前記被試験モジュールが呼び出す前記他の
   モジュールの代わりに用いられるスタブとを設け、 前記第１のモードでは前記相互作用情報を使用者に入力
   せしめ、 前記第２のモードでは前記相互作用情報に基づいて前記
   被試験モジュールを実行し、この実行中に前記テスト環
   境に対してなした作用を記録しまたは前記相互作用情報
   と比較する請求項１記載のソフトウェア・モジュール・
   テスト方法。
3. （３）前記被試験モジュールのインターフェース情報に
   基づいて前記テスト・ドライバおよび前記スタブを自動
   的に作成する手段を設けることを特徴とする 請求項２記載のソフトウェア・モジュール・テスト方法
   。