JPH1040132A - プログラム検査システム - Google Patents

Abstract

(57)【要約】 【課題】 検査作業で人手で行なわれていた試験環境の
検査を自動的に行うことにより、従来の作業を短時間に
行い、その作業の正確さを向上させるプログラム検査シ
ステムを得る。 【解決手段】 試験データを生成して試験データテーブ
ルに格納する試験データ生成部と、起動データを生成し
て起動データテーブルに格納する起動データ生成部と、
前記試験データや前記起動データを過去に行われた同一
仕様の試験の試験データや起動データと比較する検証部
と、オペレータがプログラムに入力するコマンドを解
析、記録するオペレータ入力部と、前記検証部の比較の
結果をオペレータに通知するオペレータ出力部と、前記
オペレータ入力部から入力されたコマンドや、前記起動
データテーブルに保存された起動データによりプロセス
を起動、終了させたり、前記試験データテーブルに保存
された試験データにより試験で発生したオペレータの操
作をプログラムに再入力するプログラム制御部とで構成
される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータで動
作するソフトウエアプログラムの試験やデバッグに係る
ものであり、特に、プログラムの検査作業の効率を飛躍
的に向上させる方式に関するものである。

【０００２】

【従来の技術】

（従来の検査作業）プログラムの検査は、プログラムの
試験やデバッグなどで行われる作業の１つで、一般的に
は、何らかのデータを与えてプログラムを動作させ、そ
の動作を調べることである。以下に試験やデバッグを例
にとり従来の検査作業について説明する。

【０００３】（試験、デバッグのための構成）一般的
に、プログラムの試験やデバッグには図１４に示すソフ
トウエアプログラムと、ハードウエアが必要である。必
要なソフトウエアプログラムには。まず試験対象になる
プログラム１４１（被試験プログラム）と、被試験プロ
グラムからの関数の呼出しや、データの送信（プロセス
間通信による）を受信するプログラム１４２（スタブプ
ログラム）と、被試験プログラムを呼び出したり試験デ
ータを被試験プログラムに送信するプログラム１４３
（ドライバプログラム）、これらのプログラムを起動す
るためのオペレーションシステム１４４（以下OSと略
す）がある。なお、デバッグ時にはプログラムの実行を
制御できるデバッガ１４５と呼ばれるプログラムも必要
である。また必要なハードウエアには、上記プログラム
を実行するためのコンピュータシステム１４６と、プロ
グラムを操作するためのキーボード１４７やマウス１４
８、プログラムの出力結果を確認するためのディスプレ
イ１４９がある。

【０００４】（試験手順）一般的な試験の手順を図１５
を使って説明する。ステップ１５１において作業者は試
験仕様書を作成する。ステップ１５２において、試験環
境の設定を行う。ここでは試験に必要なプログラムが用
意され、プログラムの実行に必要なソフトウエア、ハー
ドウエアの検査が行われる。ステップ１５３では試験を
行う試験項目を決定する。ステップ１５４ではオペレー
タが試験仕様書に従いプログラムを起動する。ステップ
１５５では起動されたプログラムに対してオペレータが
コマンドや試験データを入力する。ステップ１５６では
オペレータが試験結果を確認する。ステップ１５７では
出力結果が正常であれば、ステップ１５９により次の試
験項目があるかどうかを調べ、もしあるようだったら、
ステップ１５３に戻り試験する試験項目を決定する。試
験結果が異常であれば、ステップ１５８により発生した
異常を障害として記録する。ここで障害として記録され
る項目には、実施した試験名や試験項目、入力したコマ
ンドや、プログラムに対して行われた操作、プログラム
の出力した結果が記載されている。ステップ１５９にて
実施する試験項目がなければ終了する。

【０００５】（デバッグ手順の説明） またデバッグの
手順について図１６に示すフローチャートを使って説明
する。ステップ１６１において試験担当者より、試験で
異常が発生した試験項目について、操作手順や出力結果
などの状況が報告される。ステップ１６２では障害の報
告をもとにデバッグ担当者が検査を行うプログラム中の
位置（ブレークポイント）を決定する。ステップ１６３
ではブレークポイントで入力するデータを作成し、試験
と同様にデバッグ環境を検証する。検証の結果正しい環
境が設定されればステップ１６４によりプログラムを起
動する。このとき被試験プログラムはデバッガを使って
起動する。プログラムが起動されたら、ステップ１６５
においてオペレータが試験で行った操作を実施する。こ
うしてブレークポイントまで被試験プログラムを実行さ
せる。ステップ１６６でブレークポイントに実行が達し
たら、ステップ１６７でデバッグデータを入力する。そ
こでステップ１６８によりプログラムの出力結果を確認
する。

【０００６】このように、試験において検査作業は、試
験データを入力して試験結果を確認することであり、デ
バッグではデバッグデータを与えて、その結果を調べる
ことである。

【０００７】こうしたテストやデバッグでは作業者にお
ける作業環境の検査、プログラムの起動、プログラムに
対する操作などの手動操作が不可欠である。そのために
作業者による操作ミスが混入されやすく、また長い作業
時間が必要であるといった問題があった。そこで、こう
した人間による作業を省力化するための方式が提案され
ている。

【０００８】例えば、図１７は特開平８ー１６４３１号
公報に示されたデバッグ方式を実行するための構成を示
す図である。この方式は、プログラムの検査手順を自動
化することで、デバッグ作業の効率化を計る例である。

【０００９】本方式を実行するための構成は、図１７に
おいて、入力ファイルからデータを入力し、出力ファイ
ルにデータを出力する被試験プログラム１７１と、端末
１７２から入力されたコマンドを解析するコマンド解析
手段１７３と、ブレークポイント時点で出力ファイルを
コミットするコミット手段１７４と、出力ファイルをブ
レークポイント時点の状態にロールバックするロールバ
ック手段１７５と、ブレークポイント時点の利用者プロ
グラムがアクセスしている入力ファイルのカレンシ情報
（ファイルを示す指示子に関する情報）をカレンシ情報
退避領域１８２に退避するカレンシ情報退避手段１７６
と、カレンシ情報退避手段１７６によって退避されたカ
レンシ情報を復旧するカレンシ情報復旧手段１７７と、
ブレークポイント時点の利用者プログラムの変数情報を
変数情報退避領域１８３に退避する変数情報退避手段１
７８と、変数情報退避手段１７８によって退避された変
数情報を復旧する変数情報復旧手段１７９と、ブレーク
ポイント時点の利用者プログラムのスタック情報をスタ
ック情報退避領域１８４に退避するスタック情報退避手
段１８０と、スタック情報退避手段１８０退避されたス
タック情報を復旧するスタック情報復旧手段１８１と、
カレンシ情報退避領域１８２、変数情報退避領域１８
３、スタック情報退避領域１８４を確保する領域確保手
段１８５と、その領域を解放する領域解放手段１８６と
で構成されている。

【００１０】この方式の動作は以下の通りである。退避
コマンドの入力に対して出力ファイルのカレンシ情報の
退避、変数情報の退避、スタック情報の退避を行い、復
旧コマンドの入力に対して、出力ファイルのロールバッ
ク、入力ファイルのカレンシ情報の復旧、変数情報の復
旧及びスタック情報の復旧を行うことにより、ブレーク
ポイントから被試験プログラムのデバッグを再開するこ
とができ、デバッグ処理の効率を向上させることができ
る。

【００１１】なお、この種の方式として関連するものは
例えば特開平７ー３１１６９３号公報、特開平７ー２９
５８５７号公報などがあげられる。

【００１２】

【発明が解決しようとする課題】

（課題１）上記に示した従来の試験やデバッグ方式で
は、原則的には、１つの作業が終了するまで作業環境が
専有される。ところが実際の検査作業では、お互いに干
渉しない検査項目もあり、作業の効率化の点から同じ環
境をいくつか設定して、並行に作業を行うことが多い。
こうした並列して行う作業では、それぞれの作業が同一
の作業環境で行わなければならない。なぜなら、同じ名
前でありながら開発バージョン番号の異なる環境を使っ
ていると、同じ検査であっても結果が異なってしまうか
らである。ところが、こうした環境の検査は従来は人手
で行なわれており、時間もかかり、ミスが混入されやす
くなっていた。その結果、作業後にミスが発見され作業
全体をやり直したり、また未試験の機能を生じさせてし
まうといった問題が発生する。

【００１３】（課題２）また従来のデバッグや試験にお
けるプログラムの検証作業においては、プログラムの同
一性の確認をプログラム名とサイズの比較で行ってい
た。そのため複数のソースプログラムをコンパイルして
生成されるプログラムを識別しようとすると、構成する
ソースファイルの開発バージョン番号の違いを検出でき
ないため、開発バージョン番号の違いによって発生する
機能仕様の相違を検出することができない。

【００１４】（課題３）試験によっては周辺プログラム
の使われる機能が限定されるために、異なる開発バージ
ョン番号のプログラムを使って実施した試験であっても
試験結果が同じになることがある。例えば、OSのバージ
ョンは異なっていても同じ結果が得られることが判って
いる機能があるとき、これらの異なるOSを使って同じ被
試験プログラムで同じ試験を行った場合、異なる開発バ
ージョンのOSを使って被試験プログラムを試験しても出
力結果が同じになる。従来の試験方法ではこうした場
合、実施可能な試験であっても試験前に作業環境が異な
ると判断されて試験を開始できない。

【００１５】（課題４）また従来のデバッグや試験にお
けるプログラムの検査作業において、作業環境の相違を
検出した場合、相違を解消するために必要なファイルや
プログラムの検索と再設定を人手で行わなければならな
ければならず、手間がかかりミスも混入され易くなる。

【００１６】（課題５）また従来のデバッグや試験にお
けるプログラムの検査作業において、ネットワークで接
続された複数のマシンを使って並行して作業を行う場
合、作業を行うマシン全てについて作業環境の設定と検
証を行わなければならず、マシンの台数が増えるに従っ
て、手間やミスが混入され易い。

【００１７】（発明の目的）本発明の目的は、上記のよ
うな従来の問題点を除去し、検査作業で人手で行なわれ
ていた試験環境の検査を自動的に行う検査システムを提
案することにより、いままで行われていた作業を短時間
に行い、その作業の正確さを向上させることを目的とし
ている。

【００１８】

【課題を解決するための手段】本発明の第１のプログラ
ム検査システムは、複数のプログラムを同時に実行でき
るコンピュータシステムにおいて、試験データをオペレ
ータの入力操作から自動的に生成して試験データテーブ
ルに格納する試験データ生成部と、オペレータがプログ
ラムを起動させることで発生する起動データを起動デー
タテーブルに格納する起動データ生成部と、前記起動デ
ータを過去に行われた同一仕様の試験の起動データと比
較する検証部と、オペレータがプログラムに入力するコ
マンドを解析、記録するオペレータ入力部、前記検証部
の比較の結果をオペレータに通知するオペレータ出力部
と、前記オペレータ入力部から入力されたコマンドや、
前記起動データテーブルに保存された起動データにより
プロセスを起動、終了させたり、前記試験データテーブ
ルに保存された試験データにより試験で発生したオペレ
ータの操作をプログラムに再入力するプログラム制御部
とで構成される。

【００１９】本発明の第２のプログラム検査システム
は、検証部において、起動するプログラムの名前、サイ
ズ、前記プログラムを構成するソースファイルの名前と
開発バージョン番号の少なくとも１つを前記プログラム
の属性として比較を行う。

【００２０】本発明の第３のプログラム検査システム
は、検証部において、起動データを比較する場合、比較
のためのルールを定義する知識データを設けることによ
り比較に柔軟性をもたせた。

【００２１】本発明の第４のプログラム検査システム
は、検証部において、任意の過去の起動データと現在の
作業環境で生成された起動データを比較して相違が生じ
た場合、その相違点を解消するように過去の起動データ
に関するプログラムやファイルの存在位置の情報を含む
ファイル探索テータを前記現在の作業環境で生成された
起動データに追加することにより、相違の生じたプログ
ラムやファイルを複製し、現在の作業環境を修正すると
ができる起動データ生成部を備えた。

【００２２】本発明の第５のプログラム検査システム
は、ネットワークを介して接続された別のコンピュータ
システムにある任意の起動データや試験データを試験名
と試験項目名で選択して得ることができる起動データ生
成部と試験データ生成部とを備えた。

【００２３】

【発明の実施の形態】

実施の形態１．図１は本発明における実施の形態１を示
したものである。同図において、１は試験データ（被試
験プログラムへ入力するコマンドやオペレータの入力す
るデータ）を実際のオペレータの操作から自動的に生成
して試験データテーブル７に格納する試験データ生成部
であり、２は起動データ（起動環境や起動するプログラ
ムの属性）を生成して起動データテーブル８に格納する
起動データ生成部であり、３は起動データを前回試験時
の起動データと比較する検証部であり、４はオペレータ
がプログラムへ入力するコマンドを解析、記録するオペ
レータ入力部であり、５は検証部の比較の結果をオペレ
ータに通知するオペレータ出力部であり、６はオペレー
タ入力部で解析されたコマンドや、起動データテーブル
に保存された起動データによりプログラムを起動、終了
するプログラム制御部である。本発明は以上のように構
成される。

【００２４】以下に試験時に本発明を利用した場合につ
いて説明する。まず試験仕様書（図２）に基づいて試験
に必要なプログラムが用意される。ここでは、被試験プ
ログラムはTestAであり、スタブプログラムはStubA、St
ubB、StubCが使われ、ドライバプログラムはDriverA、D
riverB、DriverC が用意される。このとき、各プログラ
ムについて必要なファイルは、図３に示す手順リストを
参照すると手順２、手順３よりTestAにはファイルTest
A.cfg があることがわかり、手順１,手順３よりStubAに
はStubA.cfgがあることがわかる。

【００２５】以下、図４に示すフローチャートに沿って
試験手順を説明する。ステップ４１において、試験作業
者は試験に係るプログラムについて、図２の試験仕様書
をもとに図５のような起動データを作成する。このとき
作成された起動データは実施する試験名とともに起動デ
ータ生成部が起動データテーブルに格納する。ステップ
４２において、オペレータは実施する試験項目をオペレ
ータ入力部を使って入力する。

【００２６】このときオペレータが入力する試験項目の
入力方法はキーボードを使って文字列を入力しても、メ
ニュー等により提示される現在の起動データ内にある試
験名に該当する試験項目名のリストからの選択でも同様
の効果が得られる。

【００２７】ステップ４３においてプログラム制御部は
入力された試験名と試験項目名に該当する起動データが
あるかを調べる。このとき起動データテーブルに該当す
る起動データがなければ、ステップ４４によりオペレー
タが実際にプログラムを起動する。このとき、オペレー
タ入力部は起動履歴を起動データテーブルに格納する
（ステップ４５）。図６は記録された起動データの例で
ある。図６では試験項目４ー１について３つの起動手順
があり、そのそれぞれについて起動するプログラム名と
サイズ、開発バージョン番号、使用するファイル名、サ
イズ、開発バージョン番号などが記録されている。一
方、ステップ４３で該当する起動データが存在すれば、
ステップ４６によりプログラム制御部が起動データを読
み込み、ステップ４４でプログラムを実行する。このと
き、ステップ４７により検証部が実行時に得られた起動
データ（プログラムの属性や、使用したファイルの属
性）が記録されていた同一仕様の前回の試験時の起動デ
ータと同一であるかを調べ、その結果をオペレータ出力
部を通してオペレータに通知する。図７は通知されたメ
ッセージの例である。ここで、検証部が比較する対象は
同一仕様の前回の試験時の起動データとしたが、過去の
複数回の起動データ履歴を起動データテーブルに格納
し、任意の回数だけさかのぼった起動データと比較する
ように構成すれば、より柔軟な作業環境の検証が行え
る。

【００２８】ここではTestA,StubA,DriverA の３つのプ
ログラムについて比較を行った結果であり、TestAにつ
いては相違は検出されず、StubAについてはプログラム
サイズが異なり、DriverA についてはプログラムサイズ
と開発バージョンが異なっていることが通知されてい
る。

【００２９】プログラムの起動が完了後、起動したプロ
グラムに対して試験データの入力が行なわれる。ステッ
プ４８では、検証部が実施中の試験名と試験項目に該当
する試験データが試験データテーブルにあるかを調べ
る。もし存在すれば、ステップ４９により試験データを
読み込み、ステップ５０により試験データを実行中のプ
ログラムに送信する。また、ステップ４８において試験
データテーブルに該当する試験データがなければ、ステ
ップ５０によりオペレータによる実際のデータ入力操作
が行なわれ、ステップ５１によりその内容が試験データ
テーブルに記録される。以降はステップ５２により出力
結果を確認し、これ以上行う試験がなければ終了する
（ステップ５３）。

【００３０】以下にデバッグ作業に本発明を適用した場
合の作業の流れについて説明する。ここでは、図２の試
験仕様書と図３の手順リストに基づいた試験が本発明を
使って実施され、試験実施後にデバッグ作業者が図５の
ような起動データを作成し、デバッグを開始する状況を
仮定する。このデバッグの目的は、試験項目“４ー１”
で障害が発見されたため、その原因を究明することとす
る。以下に図８のフローチャートにそって、このデバッ
グ作業の流れを説明する。

【００３１】デバッグ作業者（以下オペレータと表記す
る）には、試験作業者より障害の発見された試験名と試
験項目名、および試験結果（エラーメッセージや、画面
イメージでもよい）が伝えられる。

【００３２】次に、オペレータはオペレータ入力部を使
って、通知された試験名と試験項目名を入力する。この
例では“組み合わせ試験”、“４ー１”と入力する（ス
テップ８０１）。

【００３３】このときの入力方法はキーボードを使って
文字列をオペレータが入力しても、現在の起動データ内
にある試験名に該当する試験項目名のリストをディスプ
レイに表示して、その中からマウスを使って選択させて
も同様の効果が得られる。

【００３４】入力された試験名や、試験項目名に該当す
る起動データを起動データテーブルから検索する。該当
する起動データがあればステップ８０２により作業環境
の検査を行う。ここではプログラムを起動するハードウ
エアの検査がオペレータにより行われる。

【００３５】本例では、試験項目名は“４ー１”である
ことから、記録された起動データの中から試験項目名と
して“４ー１”を含む起動データを検索する。

【００３６】環境の検査が終了し、試験時と同じ環境で
あることが通知されれば、ステップ８０３によりデバッ
グ作業者は従来のデバッグ作業と同様にブレークポイン
トを決定する。ステップ８０４では試験項目“４ー１”
に該当する起動データを読み込み、ステップ８０５によ
りプログラム制御部がプログラムを自動的に起動する。
プログラムの起動時には、起動したプログラムに関する
起動データを起動データ生成部が作成し、ステップ８０
６において検証部が起動データテーブルから読み込まれ
た起動データと起動時に発生した起動データの内容を比
較する、同じ内容の起動データであれば、ステップ８０
７により、プログラム制御部が試験データテーブルに保
存された試験項目に該当する試験データを読込み、ステ
ップ８０８により、読み込んだ試験データを実行中のプ
ログラムに出力する。このときステップ８０９によりプ
ログラムの実行がブレークポイントに達すれば、ステッ
プ８１０においてオペレータがデバッグデータを入力し
てプログラムの結果を判定する（ステップ８１１）。ス
テップ８１２において障害原因が明かにならなければ、
プログラム制御部がプログラムを全て終了させてステッ
プ８０３に戻り新たなブレークポイントを設定してデバ
ッグを続ける。

【００３７】本実施の形態によれば、試験時の環境を自
動的に検査し、正確な手順でプログラムを起動するた
め、人為的なミスが少なくなりミスによる試験のやり直
しなどの無駄な時間の発生がない。またデバッグ時に
は、正確な障害発生状況を短時間で再現できるためデバ
ッグや試験の効率が飛躍的に増す。

【００３８】実施の形態２．上記実施の形態１において
検証部がプログラムを識別する際に、プログラムを構成
するソースファイルの属性を使うこともできる。

【００３９】図９は実施の形態２に基づく、検証部によ
る比較の流れを示すフローチャートである。ステップ９
０１でプログラム名が比較される。ステップ９０２では
プログラムがハードディスクなどに記録されているサイ
ズを比較する。ステップ９０３でプログラムを構成して
いるソースファイルがあるかを調べる。もし構成するソ
ースファイルがあれば、ステップ９０４により構成する
ソースファイルのリストが作成される。

【００４０】図１０はプログラムAとプログラムBに関す
るソースファイルのリストの例である。

【００４１】ここで、１０１はプログラムA を構成する
ソースファイルの属性を示したもので、各ファイルにつ
いて名称と開発バージョン番号が記述されている。ま
た、１０２は同様にプログラムBに関するソースファイ
ルのリストである。

【００４２】前記リストが作成されると各ソースファイ
ルについて名称と開発バージョン番号が比較される（ス
テップ９０５、９０６）。図１１は前記２つのソースフ
ァイルのリストを元に実施の形態３における検証部によ
りプログラムAとプログラムBの属性を比較した結果であ
る。ここではプログラムサイズの相違と、ソースファイ
ル add_window.c , cfs.c の開発バージョン番号の相違
が通知されている。

【００４３】ステップ９０７において、ソースファイル
のリストに比較するソースファイルが残っているかを調
べ、比較するソースファイルがなければ終了する。

【００４４】本実施の形態によればプログラムの試験や
デバッグにおいて、複数のソースプログラムをコンパイ
ルして生成されるプログラムについて、プログラムを構
成するソースファイルの開発バージョン番号も考慮して
比較を行うことができるため、構成するソースファイル
の開発バージョン番号の違いで発生する機能仕様の違い
を識別することができるようになる。

【００４５】実施の形態３．なお、実施の形態２におい
ては検証部は読み込まれた起動データと、実行時に検出
された起動データを比較するだけであるが、図１２のよ
うな知識データを用意することにより柔軟な比較を行う
ことができる。例えば、図１２においてプログラムStub
Aの起動に必要な設定ファイルStubA.cfgについては、St
ubA01.cfg とStubA02.cfgの２つのファイルも同様に使
用でき、またTestAについては、開発バージョン番号は
１．２，１．３の両方が使うことができると定義してい
る知識データの例である。

【００４６】こうした知識データを使って試験を行った
場合、実施の形態１ではファイルStubA がシステムに存
在しなければ、試験環境の検証が行えず。試験を行うこ
とができなかったが、前記の例にある知識データを使え
ばシステム上にStubA01.cfgか、StubA02.cfg の２つの
ファイルのいずれかが存在すればStubA.cfg が存在しな
くとも試験を行うことができる。また、TestA について
も、開発バージョンが１．２，あるいは１．３のプログ
ラムが存在すれば試験を開始することができる。

【００４７】このように、知識データをもうけることに
より検査作業にロジックを定義でき柔軟に作業を行え
る。

【００４８】実施の形態４．上記実施の形態１では、検
証部で異常が発生した場合、通知を行うだけであるが、
起動データテーブルに実際にプログラムやファイルの存
在する位置を記述したデータ（ファイル探索データと呼
ぶ）を起動データに追加することにより、指定の開発バ
ージョン番号のプログラムやファイルを探索し、存在す
ればそれを使って検査を行うこともできる。

【００４９】図１３は実施の形態４に基づいた、ファイ
ル探索データの例である。この例では、プログラムTest
Aは /usr/test/A ディレクトリ下にあり、プログラ
ムStubA、StubBは/usr/test/stub ディレクトリ下に
あることを示している。デバッグ作業者はプログラムを
起動する際に、起動したプログラムやファイルが読み込
んだ起動データに記載されている内容と異なっていれ
ば、起動データにあるファイル探索データからファイル
を探索し、複製して現在の作業環境に追加することがで
きる。例えば検証部の比較によりプログラムTestA の開
発バージョン番号が異なっていた場合、ディレクトリ/u
sr/test/Aの下にあるプログラムTestAを現在の作業ディ
レクトリ下に複製して使うことができる。

【００５０】なお、この例ではオペレータが予め起動デ
ータにファイル探索データを追加して記述したが、オペ
レータがオペレータ入力部を通して実際にファイルを獲
得するための操作を行うことにより、その操作履歴から
自動的に起動データに探索データを追加することも可能
である。

【００５１】本実施の形態によればプログラムの試験や
デバッグにおいて、作業環境の相違を検出した場合、同
一環境を設定するのに必要なファイルやプログラムの検
索を自動的に行えることから省力化が行え、ミスも混入
しにくくなる。

【００５２】実施の形態５．上記実施の形態４でプログ
ラムを探索する場合、ネットワークに接続された別のコ
ンピュータからプログラムを探索できるようにすること
もできる。

【００５３】以下に動作を説明する。まずオペレータは
試験名を入力する、次に起動データ及び、実施の形態４
におけるファイル探索データを作成し起動データに追加
する。このとき起動するマシン名を追加して記述する。
起動データをオペレータの入力履歴から作成する場合は
マシン名を指定してプログラムを起動すれば、起動デー
タにプログラムの存在するマシンの情報が追加される。
検索部はこうして作成されたファイル探索データを参照
してネットワークで接続された別のマシンにあるプログ
ラムを獲得することができる。

【００５４】本実施の形態により、ネットワークで接続
された複数のマシンを使って並行して作業を行う場合、
作業が別々のマシンで行なわれる場合であっても、ネッ
トワークに接続されていれば指定の開発バージョン番号
のプログラムを得ることができる。このため別々のマシ
ン上で試験が行なわれる場合であっても、１度起動デー
タが作成されれば、試験に必要なプログラムの探索位置
が定義されているので、試験作業者が必要なプログラム
を探すといった手間を省略することができ、ミスが混入
されにくくなる。

【００５５】

【発明の効果】以上の説明から明かなように、デバッグ
や試験作業において人間が行っていた作業環境の検証を
自動的に行うことにより、試験においては試験の精度を
向上させ、デバッグにおいては作業時間の短時間化を行
える。その結果、試験やデバッグ作業におけるプログラ
ムの検査作業を効率化することができる。

【図面の簡単な説明】

【図１】 本発明の実施の形態を実現するためのプログ
ラム検査システムの構成図。

【図２】 実施の形態で使用するプログラムの試験仕様
書の例を示す図。

【図３】 図２のプログラム試験仕様書内に記載される
試験手順のリストを示す図。

【図４】 実施の形態１で用いる本発明を使った試験作
業の流れを示すフローチャート。

【図５】 実施の形態１で用いる本発明によって作成し
た起動データの例を示す図。

【図６】 実施の形態１で作成された起動データの例を
示す図。

【図７】 実施の形態１で用いた比較結果を示す図。

【図８】 実施の形態１で用いた本発明を使ったデバッ
グ作業の流れを示すフローチャート。

【図９】 実施の形態２で用いた検証部の動作を示すフ
ローチャート。

【図１０】 実施の形態２で用いたソースファイルのリ
ストの例を示す図。

【図１１】 実施の形態２によるオペレータ出力部の比
較結果を示す図。

【図１２】 実施の形態３で用いた本発明による検証部
で使われる知識データの例を示す図。

【図１３】 実施の形態４で用いた本発明によるファイ
ル探索データの例を示す図。

【図１４】 従来の試験を行うためのシステムの構成例
を示す図。

【図１５】 従来の試験手順における試験実施の手順を
示すフローチャート。

【図１６】 従来のデバッグ手順の流れを示すフローチ
ャート。

【図１７】 デバッグに関する従来技術例に関するシス
テム構成図。

【符号の説明】

１ 試験データ生成部、２ 起動データ生成部、３ 検
証部、４ オペレータ入力部、５ オペレータ出力部、
６ プログラム制御部。

Claims (5)

【特許請求の範囲】
1. 【請求項１】 複数のプログラムを同時に実行できるコ
   ンピュータシステムにおいて、試験データをオペレータ
   の入力操作から自動的に生成して試験データテーブルに
   格納する試験データ生成部と、オペレータがプログラム
   を起動させることで発生する起動データを起動データテ
   ーブルに格納する起動データ生成部と、前記起動データ
   を過去に行われた同一仕様の試験の起動データと比較す
   る検証部と、オペレータがプログラムに入力するコマン
   ドを解析、記録するオペレータ入力部、前記検証部の比
   較の結果をオペレータに通知するオペレータ出力部と、
   前記オペレータ入力部から入力されたコマンドや、前記
   起動データテーブルに保存された起動データによりプロ
   セスを起動、終了させたり、前記試験データテーブルに
   保存された試験データにより試験で発生したオペレータ
   の操作をプログラムに再入力するプログラム制御部とで
   構成され、ソフトウエアプログラムのテストやデバッグ
   作業において、試験データやデバッグデータを入力して
   プログラムの出力結果を確認するような検査作業で、作
   業を開始する前に作業環境の検証を自動的に行うことを
   特徴とするプログラム検査システム。
2. 【請求項２】 前記検証部において、起動するプログラ
   ムの名前、サイズ、前記プログラムを構成するソースフ
   ァイルの名前と開発バージョン番号の少なくとも１つを
   前記プログラムの属性として比較を行うことを特徴とす
   る請求項１記載のプログラム検査システム。
3. 【請求項３】 前記検証部において、起動データを比較
   する場合、比較のためのルールを定義する知識データを
   設けることにより比較に柔軟性をもたせたことを特徴と
   する請求項１記載のプログラム検査システム。
4. 【請求項４】 前記検証部において、任意の過去の起動
   データと現在の作業環境で生成された起動データを比較
   して相違が生じた場合、その相違点を解消するように過
   去の起動データに関するプログラムやファイルの存在位
   置の情報を含むファイル探索テータを前記現在の作業環
   境で生成された起動データに追加することにより、相違
   の生じたプログラムやファイルを複製し、現在の作業環
   境を修正するとができる起動データ生成部を備えたこと
   を特徴とする請求項１記載のプログラム検査システム。
5. 【請求項５】 ネットワークを介して接続された別のコ
   ンピュータシステムにある任意の起動データや試験デー
   タを試験名と試験項目名で選択して得ることができる起
   動データ生成部と試験データ生成部とを備えたことを特
   徴とする請求項４記載のプログラム検査システム。