JPH11224211A - ソフトウェア検査支援装置 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 ソフトウェアの仕様とテスト項目の作成およ
びデバッグの間に関連性を持たせることで、効率よくソ
フトウェアのテストを行う。 【解決手段】検査用ルール作成手段３０は、実際にその
コーディングされた内容４２が、内部仕様４０の内容に
合致しているか否かを検査するための検査用ルール４１
を作成する。検査用コード挿入手段３１は、テスト終了
後にテストの実行経過を記録したログを収集するため、
ソースコードに対して所定のコードを挿入する。テスト
実行手段３２は、オペレータの指示に従い、動作テスト
を行う。ここで、実行結果ログ４３が作成される。実行
結果ログ検査手段３３は、ソフトウェアに対するテスト
項目を実施した結果が、内部仕様に合致しているか否か
を検査する。実行結果ログ検査手段３３は、導出できる
か否かを判定した後、この結果を検査結果レポート３４
として出力する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ソフトウェアの動
作テストを支援するソフトウェア検査支援装置に係わ
り、詳細には、ソフトウェアの実行結果がソフトウェア
の仕様に合致しているか否かを検査するソフトウェア検
査支援装置に関する。

【０００２】

【従来の技術】近年コンピュータ技術の発達に伴い、ソ
フトウェアに対する需要は急増し、ソフトウェアに求め
られる内容も高度かつ複雑化している。そのため、製品
の品質を維持しながらソフトウェアの開発を効率的に行
なうための様々な装置が提案されている。

【０００３】図２は、ソフトウェアの開発における一般
的な作業工程を表わしたものである。ソフトウェアの開
発は、そのソフトウェアに対して求められる課題または
要求の分析から始まる。要求分析の段階では、クライア
ントの要求を分析し、ソフトウェアが最終的にどのよう
な機能を持っているべきかをまとめた要求仕様２０を作
成する。仕様とは、プログラムの挙動をプログラム言語
に直接依存しないかたちで記述したものをいう。例え
ば、表や図形を使用して、日本語で作成したものをい
う。一例を示す。今、「コンピュータを利用して請求書
を自動的に作成するシステム」という要求があったとす
る。この要求を実現するためには、いきなりプログラム
を作成する前に、「請求書を作成するためのデータを入
力する手段」や「所定の計算を実行する手段」、そして
「所定のフォーマットで請求書を発行する手段」につい
てきちんと検討する必要がある。そこで、これらの基本
的機能をハードウェアの構成とともに規定して、ソフト
ウェアの全体的な構成を最初に表わしたものが要求仕様
２０である。

【０００４】要求仕様２０を作成すると、この要求仕様
２０に規定した各機能を分割して更に詳細に規定した外
部仕様２１を作成する。前述した一例によれば、請求書
を作成するための計算を実行する手段について、より詳
細に規定する。図６は、本発明の実施例における外部仕
様であり、説明をわかりやすくするために簡単な計算処
理を規定したものである。

【０００５】外部仕様２１を作成すると、次に、ソフト
ウェアがその機能を実現するためにどのような流れで処
理を行うのかを具体的に規定した内部仕様２２を作成す
る。図７は、図６に示した外部仕様に基づいて実際に作
成された内部仕様である。外部仕様を実現するためのプ
ログラムの流れと内容を、所定のプログラム言語と図形
で表現している。

【０００６】各種仕様書を作成すると、プログラムを作
成する工程に移行する。プログラマは、これらの仕様に
基づいて各種プログラミング言語を使用してコーディン
グ２３を行う。コーディングとは、計算機に処理させる
ための手順を所定のプログラミング言語で具体的に記述
していくことをいう。図８は、図７の内部仕様に基づい
て実際にコーディングされたソースコードである。本実
施例では、プログラム言語としてＣ言語を用いている。

【０００７】コーディングを終えると、出来上がったプ
ログラムに対して動作テストを行う。動作テストとは、
プログラムが仕様に沿った処理を実行しているか否かを
検査することである。ここでは、仕様と誤って請求書の
計算方法をコーディングしたような場合に、動作に誤り
（バグ）があることになる。動作にバグが発見された場
合は、デバッグ２８を行い、バグを修正しなければなら
ない。デバッグ２８とは、コーディング中の誤りを取り
除いて、正常な動作に戻すための作業をいう。デバッグ
２８を終えると、再び同じテストを繰り返してバグが取
り除かれたかどうかを確認する。

【０００８】図３は、テスト項目を１つ実施する場合の
実行手順を具体的に表わしたものである。たとえば、
「入力データが偶数のときは『１』、奇数のときは
『０』を表示する」という仕様に基づいて作成されたソ
ースコードを基に、動作テストを実施する場合を考え
る。オペレータは、テストデータとして「２２」を入力
して（ステップＳ１０１）、ソフトウェアが仕様どおり
に「１」を表示するかどうかを検査する。表示画面に
「１」が表示されれば、仕様どおりに動作したことにな
るので（ステップＳ１０２；Ｙ）、テストを終了する
（ステップＳ１０５）。しかし、表示画面に「０」が表
示された場合は、仕様どおりに動作していないので（ス
テップＳ１０２；Ｎ）、ソースコードに誤りがあること
がわかる。よって、デバッグを行う者は、デバッガなど
を利用して、ソースコード上の誤り箇所を特定する（ス
テップＳ１０３）。ソースコードを修正すると（ステッ
プＳ１０４）、再度テスト項目を実施する（ステップＳ
１０１）。つまり、オペレータは、テストデータ「２
２」を入力して、表示画面に「１」が表示されるかどう
かを確認する。テストを実行する者は、ソフトウェアが
仕様どおりに動作するまでこの手順を繰り返す。

【０００９】図２に戻って、各動作テストについて説明
する。一般に、プログラムは機能単位に分割して作成さ
れる。そして、分割されたプログラムを各単位ごとに結
合していくことで最終的に１つのソフトウェアを構成す
る。従って、これらの段階に応じて、動作テストを行っ
てその結果を検査しなければならない。単体テスト２４
では誤りが検出されない場合でも、他のプログラムと結
合して統合テスト２５を行ったときに、はじめて動作に
バグが検出される場合もある。よって、単体テスト２
４、統合テスト２５、機能テスト２６、そしてシステム
テスト２７の順にテストを行い、その都度バグの発見と
デバッグ２８を繰り返すことで、最終的にバグをなくす
ものである。システムテスト２７が終了すると、出荷検
査２９を経て、ソフトウェア製品として出荷される。

【００１０】ソフトウェアの品質を保証するためには、
そのソフトウェアが正常に動作することが前提である。
そのために、質量ともに十分な動作テストを行うことに
よって、バグを発見し、これを修正していくことは、ソ
フトウェアの開発において必要不可欠な作業である。し
かし、近年のソフトウェアに関する技術の発達に伴い、
各種仕様の内容が高度化した結果、プログラムも肥大化
および複雑化している。よって、その動作テストも膨大
な量になり、人手と時間を大量に要するようになった。

【００１１】そこで、従来からソフトウェアのテストに
関する手法が多数提案されている。ソフトウェアのテス
ト手法としては、例えば、ブラックボックステストとホ
ワイトボックステストとに大別できる。ブラックボック
ステストとは、ソフトウェアの外部的な機能をテストす
るための手法である。これに対し、ホワイトボックステ
ストとは、実際に作成されたソフトウェアの内部の各部
分を十分にテストするためのものである。

【００１２】特開平８−２３５０２４号公報にはブラッ
クボックステスト手法を利用して、ソフトウェアのテス
トを行うソフトウェア検査支援装置が提案されている。
このソフトウェア検査支援装置では、入出力マトリクス
という外部仕様から、データに関する構造を抽出して、
原因結果グラフを作成している。原因結果グラフとは、
外部仕様に基づいて、ソフトウェアの結果（出力）と原
因（入力）との論理関係を表現したものである。例え
ば、「入力データが偶数のときは『１』、奇数のときは
『０』を出力する」や、「メニューＡを選択すると画面
ａ、メニューＢを選択すると画面ｂを表示する」といっ
た論理関係を表す。

【００１３】そこで、オペレータが、「メニューＡ」を
選択したところ「画面ｃ」が表示された場合、入力と出
力との関係から、プログラムの動作に誤りがあることが
わかる。従って、デバッグを行うためには。このような
不具合の状況に基づいて、ソースコード上の誤りを探さ
なければならない。一般に、プログラムは機能単位に分
割して作成されるので、テスト項目の内容から、ある程
度誤りの位置の見当をつけることはできる。しかし、テ
スト段階が進むにつれて実行するプログラムの量も増加
していくと、テスト結果のみで誤り箇所を特定すること
は難しくなる。特に、プログラム作成者とデバッグを行
う者が異なる場合や、プログラミングの経験が浅い場合
には、誤り位置の見当をつけることは困難である。その
ため、データを入力した状態から出力にいたるまでのソ
ースコードを調べたりするなど、多くの労力と時間がか
かるという問題があった。

【００１４】これに対し、特開平７−２１０４２４号公
報ではホワイトボックステスト手法を利用して、ソフト
ウェアのテストを行うソフトウェア検査支援装置が提案
されている。このソフトウェア検査支援装置では、ソー
スコードを一定の構文規則に基づいて複数の単位（ルー
チン）に解析し、この解析された各ルーチン間の全ての
呼び出し関係をテストパターンとして作成するものであ
る。例えば、装置は、ソースコードを読み出して、「ル
ーチン１」、「ルーチン２」、「ルーチン３」がそれぞ
れ記述されていることを判別したとする。そして、「ル
ーチン１」が所定の場合に「ルーチン２」を呼び出し、
「ルーチン３」が所定の場合に「ルーチン１」を呼び出
す関係にあることを判別して、テスト項目を作成する。

【００１５】ここで、オペレータが、「ルーチン１」が
「ルーチン２」を呼び出すためのテスト項目を実施した
ところ、「ルーチン２」ではなく「ルーチン３」が呼び
出されてしまった場合を考える。このような場合、「ル
ーチン１」の呼び出しに誤りがあることがわかる。よっ
て、デバッグを行うものは、「ルーチン１」が記述され
ているソースコードの位置を特定して修正すれば良い。
このテストでは、動作テストの誤りに基づいてソースコ
ード上の誤り位置を見当づけることができる。ところ
が、内部仕様からではなくソースコードからテスト項目
を作成するため、あくまでもソースコードを基準に動作
テストをしていることになる。例えば、本来の仕様では
ルーチン４の処理から「ルーチン１」の処理を呼び出す
内容が規定されているのに、ソースコードでは「ルーチ
ン３」が「ルーチン１」を呼び出すように記述されてい
たとする。この場合、ソースコードを基準にテスト項目
を作成すると、「ルーチン３」が「ルーチン１」を呼び
出しているか否かを検査することになる。よって、「ル
ーチン１」が「ルーチン３」によって呼び出された場
合、本来の仕様とは異なっているにも関わらず、動作テ
ストでは正常という結果になる可能性もある。動作テス
トの本来の目的は、ソースコードが仕様に合致している
かどうかを検査することであるから、これでは動作テス
トを行なう意味がなくなる。さらに、仕様に合致してい
ないため、ソフトウェアの品質を下げることになる。

【００１６】また、動作の誤りすなわちバグを効率的に
修正するために、特開平９−２０４３２１号には、デバ
ッグを行うための技術が提案されている。一般的に、デ
バッグを支援するツールとして代表的なデバッガでは、
プログラムの状態を確認しながら、プログラムを少しず
つ動作させるステップ実行とよばれる手法がとられてい
る。ここでは、ソースコード上の適切な場所で、そのと
きの状態が確認ができるように、ブレークポイントを詳
細に設定できることとしている。

【００１７】しかし、このようにデバッグを行うには、
あらかじめソースコード上の誤り位置に見当をつけた上
で、ブレークポイントの設定をしなければならない。デ
バッグを行うものは、テストで不具合が生じた状況に基
づいて、各ブレークポイントを設定する。そして、プロ
グラムの経過内容を調べることで、具体的な誤り位置を
特定しなければならなかった。また、ソースコード上の
誤りを１箇所修正すると、今まで仕様どおりに動作して
いた他の箇所にまで影響を及ぼして、新たなバグ（エン
バグ）を生むことがある。このため、デバッグを行った
場合には、単純に修正部分に関するテスト項目のみを再
度実行すればよいとは限らず、エンバグを防止するため
に関連する他の箇所を検査する必要がある。しかし、ソ
ースコードのどの箇所に影響を与えたか否かを調べるこ
とは困難であった。

【００１８】

【発明が解決しようとする課題】このようなブラックボ
ックステスト手法では、プログラムの内部構造やデータ
の流れによらないで、その外部仕様からテスト項目の作
成を行う。よって、デバッグを行う際に、具体的にソー
スコードのどこを修正すれば良いのかまではわからなか
った。一方、ホワイトボックステスト手法では、プログ
ラムの内部構造やデータの流れに基づいて、すなわちソ
ースコードからテスト項目を作成する。よって、本来の
仕様とは異なる処理をしているのに、テストでは異常が
ないという結果になる可能性があった。そこで、これら
のテストは、互いに独立して実施するものではなく、両
者を組み合わせて実施するのが望ましい。しかし、すべ
ての場合を想定してテストを実施することは、ソフトウ
ェアの開発に人的また時間的制限が設けられていること
からも、現実には不可能なことが多い。

【００１９】このように、従来のソフトウェアのテスト
を行うためのソフトウェア検査支援装置では、仕様に基
づいたテストを実施すれば、バグを修正するのに時間が
かかる。一方、ソースコードに基づいたテストを実施す
れば、仕様に合致しているか否かを検査しきれないとい
う問題があった。また、これらのテストは動作の誤りを
発見することが目的であるから、ソースコード上の誤り
を修正するデバッグ作業は、テスト作業とはまた別に行
う必要があった。すなわち、ソフトウェアの仕様、テス
ト項目の作成、デバッグの技法の３つの間に有機的な結
びつきがないために、バランスの良いテストを行うこと
ができなかった。

【００２０】特に、テスト結果に誤りがある場合のソー
スコード上の誤り箇所の特定は、一般に難しく、非常に
多くの時間がかかるものである。そのために、開発費全
体に対するテストの費用の割合は約半分ともいわれるよ
うに、ソフトウェアのテストには非常に多くの時間と費
用がかかるという問題があった。

【００２１】そこで、本発明の目的は、ソフトウェアの
仕様とテスト項目の作成およびデバッグの間に有機的な
関連性を持たせることにより、効率よくソフトウェアの
テストを行うことができるソフトウェア検査支援装置を
提供することにある。

【００２２】

【課題を解決するための手段】請求項１記載の発明は、
ソフトウェア検査支援装置に、（イ）プログラム言語の
構文規則としての第１の構文規則に従ってプログラムの
処理手順を記述した仕様データを入力する仕様データ入
力手段と、（ロ）プログラムの処理手順を第２の構文規
則で記述するための記号を記憶した記号テーブルと、
（ハ）仕様データ入力手段の入力した仕様データを記号
テーブルに基づいて記号データに変換し、検査用ルール
を作成する検査用ルール作成手段と、（ニ）プログラム
を入力するプログラム入力手段と、（ホ）プログラムの
実行経過を記録するためのコードを記憶したコードテー
ブルと、（ヘ）プログラム入力手段の入力したプログラ
ムに対してコードテーブルに基づいてコードを挿入し、
プログラムの実行経過を記録した実行結果ログを作成す
る実行結果ログ作成手段と、（ト）実行結果ログ作成手
段の作成した実行結果ログが、検査用ルール生成手段が
生成した検査用ルールと一致するか否かを、第２の構文
規則に従って検査する実行結果検査手段とを具備させた
ものである。

【００２３】すなわち請求項１記載の発明では、仕様書
どおりにプログラムが作成されたかどうかを検査するた
めに、仕様書から検査用ルールを作成してプログラムの
実行結果ログに適用することとした。これにより、仕様
書の内容とプログラムの内容とを比較して、ソフトウェ
アの動作の確認をすることができる。よって、コーディ
ングにミスがあるにも関わらず、偶然テストの結果が仕
様書と合致してしまったような場合でも、内部動作には
誤りがあることを検出することができる。

【００２４】請求項２記載の発明は、（イ）プログラム
言語の構文規則としての第１の構文規則に従ってプログ
ラムの処理手順を記述した仕様データを入力する仕様デ
ータ入力手段と、（ロ）プログラムの処理手順を第２の
構文規則で記述するための記号を記憶した記号テーブル
と、（ハ）仕様データ入力手段の入力した仕様データを
記号テーブルに基づいて記号データに変換し、検査用ル
ールを作成する検査用ルール作成手段と、（ニ）プログ
ラムを入力するプログラム入力手段と、（ホ）プログラ
ムの実行経過を記録するためのコードを記憶したコード
テーブルと、（ヘ）プログラム入力手段の入力したプロ
グラムに対してコードテーブルに基づいてコードを挿入
し、プログラムの実行経過を記録した実行結果ログを作
成する実行結果ログ作成手段と、（ト）実行結果ログ作
成手段の作成した実行結果ログが、検査用ルール生成手
段が生成した検査用ルールと一致するか否かを、第２の
構文規則に従って検査する実行結果検査手段と、（チ）
この実行結果検査手段の検査結果が実行結果ログが検査
用ルールに適合しないものであるとき、実行結果ログか
らプログラム入力手段の入力したプログラムの中の誤り
位置を検出する誤り位置検出手段を具備させたものであ
る。

【００２５】すなわち請求項２記載の発明では、ソフト
ウェアの動作に誤りが発見されたとき、その原因となる
ソースコード上の誤り位置を検出することとした。これ
により、例えば誤り位置の行番号を画面に表示あるいは
印刷することとすれば、テストに誤りが発見された場合
に、ソースコード上の誤りを迅速に探し出すことができ
る。

【００２６】請求項３記載の発明は、ソフトウェア検査
支援装置に、（イ）プログラム言語の構文規則としての
第１の構文規則に従ってプログラムの処理手順を記述し
た仕様データを入力する仕様データ入力手段と、（ロ）
プログラムの処理手順を第２の構文規則で記述するため
の記号を記憶した記号テーブルと、（ハ）仕様データ入
力手段の入力した仕様データを記号テーブルに基づいて
記号データに変換し、検査用ルールを作成する検査用ル
ール作成手段と、（ニ）プログラムを入力するプログラ
ム入力手段と、（ホ）プログラムの実行経過を記録する
ためのコードを記憶したコードテーブルと、（ヘ）プロ
グラム入力手段の入力したプログラムに対してコードテ
ーブルに基づいてコードを挿入し、プログラムの実行経
過を記録した実行結果ログを作成する実行結果ログ作成
手段と、（ト）実行結果ログ作成手段の作成した実行結
果ログが、検査用ルール生成手段が生成した検査用ルー
ルと一致するか否かを、第２の構文規則に従って検査す
る実行結果検査手段と、（チ）実行結果検査手段の検査
した内容に基づいて実行結果レポートを出力する実行結
果レポート出力手段を具備させたものである。

【００２７】すなわち請求項３記載の発明では、検査結
果レポートとして実行結果ログと検査用ルールの導出経
緯を出力することとした。これにより、実行結果ログが
検査用ルールから導出できたか否かの経緯を具体的に知
ることができる。また、導出不可能であった場合には、
実行結果ログで導出不可能となった地点やソースコード
上の行番号が記述されるので、バグを容易に修正するこ
とができる。

【００２８】請求項４記載の発明は、ソフトウェア検査
支援装置に、（イ）プログラム言語の構文規則としての
第１の構文規則に従ってプログラムの処理手順を記述し
た仕様データを入力する仕様データ入力手段と、（ロ）
プログラムの処理手順を第２の構文規則で記述するため
の記号を記憶した記号テーブルと、（ハ）仕様データ入
力手段の入力した仕様データを記号テーブルに基づいて
記号データに変換し、検査用ルールを作成する検査用ル
ール作成手段と、（ニ）プログラムを入力するプログラ
ム入力手段と、（ホ）プログラムの実行経過を記録する
ためのコードを記憶したコードテーブルと、（ヘ）プロ
グラム入力手段の入力したプログラムに対してコードテ
ーブルに基づいてコードを挿入し、プログラムの実行経
過を記録した実行結果ログを作成する実行結果ログ作成
手段と、（ト）実行結果ログ作成手段の作成した実行結
果ログが、検査用ルール生成手段が生成した検査用ルー
ルと一致するか否かを、第２の構文規則に従って検査す
る実行結果検査手段と、（チ）実行結果ログ作成手段の
作成した実行結果ログとこの実行結果ログを作成した履
歴とを記憶する実行結果ログ記憶手段と、（リ）この実
行結果ログ記憶手段の記憶した履歴に基づいて実行結果
ログを比較する実行結果ログ比較手段を具備させたもの
である。

【００２９】すなわち請求項４記載の発明では、動作テ
ストでバグが生じたときの実行結果ログとバグを修正し
た後の実行結果ログとを比較することとした。これによ
り、デバッグでソースコードを修正した場合にエンバグ
が生じる可能性を、その前後の実行結果ログを比較する
ことで、確認することができる。

【００３０】請求項５記載の発明は、ソフトウェア検査
支援装置に、（イ）プログラム言語の構文規則としての
第１の構文規則に従ってプログラムの処理手順を記述し
た仕様データを入力する仕様データ入力手段と、（ロ）
プログラムの処理手順を第２の構文規則で記述するため
の記号を記憶した記号テーブルと、（ハ）仕様データ入
力手段の入力した仕様データを記号テーブルに基づいて
記号データに変換し、検査用ルールを作成する検査用ル
ール作成手段と、（ニ）プログラムを入力するプログラ
ム入力手段と、（ホ）プログラムの実行経過を記録する
ためのコードを記憶したコードテーブルと、（ヘ）プロ
グラム入力手段の入力したプログラムに対してコードテ
ーブルに基づいてコードを挿入し、プログラムの実行経
過を記録した実行結果ログを作成する実行結果ログ作成
手段と、（ト）実行結果ログ作成手段の作成した実行結
果ログが、検査用ルール生成手段が生成した検査用ルー
ルと一致するか否かを、第２の構文規則に従って検査す
る実行結果検査手段と、（チ）実行結果ログ作成手段の
作成した実行結果ログとこの実行結果ログを作成した履
歴とを記憶する実行結果ログ記憶手段と、この実行結果
ログ記憶手段の記憶した履歴に基づいて実行結果ログを
比較する実行結果ログ比較手段と、（リ）実行結果ログ
比較手段の比較した内容に基づいて実行結果ログ比較レ
ポートを出力する実行結果ログ比較レポート出力手段を
具備させたものである。

【００３１】すなわち請求項５記載の発明では、バグが
生じたときの実行結果ログとデバッグ後の実行結果ログ
を併記した比較結果レポートを出力することとした。テ
ストを実施する者は、実行経過ログを比較することで、
エンバグが生じる可能性を具体的に知ることができる。
さらに、表示された行番号に基づいてソースコードを再
度確認することで、エンバグを未然に防止することがで
きる。

【００３２】

【発明の実施の形態】

【実施例】以下実施例につき本発明を詳細に説明する。

【００３３】図１は、本発明の一実施例におけるソフト
ウェア検査支援装置の構成を表わしたものである。ソフ
トウェア検査支援装置１０は、各種制御の中枢となるＣ
ＰＵ１１を備えている。ＣＰＵ１１は、バス１９を介し
てＲＯＭ１２、記憶媒体１３およびＲＡＭ１４に接続さ
れている。ＲＯＭ（読み出し専用メモリ）１２には、検
査用ルール作成手段などを実行するためのプログラムが
書き込まれている。記憶媒体１３は、内部仕様やソース
プログラムを格納するためのものである。ＲＡＭ（作業
用メモリ）１４は、ＣＰＵ１１が各種制御を実行する上
での一時的に必要とするデータを格納するための作業用
メモリとしての役割を持っている。また、プリンタ１５
やＣＲＴ１７は、検査結果レポートや比較結果レポート
を出力または表示するためのものである。キーボード１
８は、内部仕様やソースプログラムを入力したり、ソフ
トウェアのテストを実施する際に使用される入力装置で
ある。なお、内部仕様やソースプログラムは、外部記憶
媒体１６から本体に入力して、記憶媒体１３に格納して
おくこともできる。

【００３４】図４は、このようなソフトウェア検査支援
装置１０の機能的な構成を表わしたものである。ソフト
ウェア検査支援装置１０は、ソフトウェアの内部仕様４
０に基づいてソフトウェアの動作に関するルールを抽出
する検査用ルール作成手段３０を備えている。外部記憶
媒体１６などから入力された内部仕様４０には、図７で
示したように所定の言語や図形で、プログラムの流れが
記述されている。プログラマはこの仕様に基づいて、コ
ーディングを行わなければならない。そこで、検査用ル
ール作成手段３０は、実際にそのコーディングされた内
容（ソフトウェア４２）が、内部仕様４０の内容に合致
しているか否かを検査するための検査用ルール４１を作
成する。検査用ルールは、たとえば対象となる内部仕様
４０にプログラム言語の構文規則とは異なる構文規則を
適用して作成することができる。検査用ルールを作成す
るための構文規則はあらかじめ記憶媒体１３に記憶して
おくものとする。作成された検査用ルール４１は、動作
テストを実行した後、実行結果ログ検査手段３３で利用
される。

【００３５】検査用コード挿入手段３１は、テスト終了
後にテストの実行経過を記録したログを収集するため、
プログラマが作成したソースコードに対して所定のコー
ドを挿入する。ソフトウェアが仕様どおりに動作してい
るか否かについてテストを実行した場合、その裏でどの
ようにプログラムが動いているのかはわからない。そこ
で検査用コードを挿入して、テストを開始してから終了
するまでの実際のプログラムの流れを記述したログを作
成するためのものである。各検査用コードは、検査用ル
ール４１や所定のプログラム言語の構文規則に応じて挿
入される。コードを挿入するための条件をあらかじめ記
憶媒体１３に記憶しておくものとする。ログは、動作テ
ストを実行したときに作成され、実行結果ログ検査手段
３３で利用される。

【００３６】検査用ルールの作成と検査用コードの挿入
を終えると、テスト実行手段３２は、オペレータの指示
に従い、動作テストを行う。ここで、動作テストを行っ
ているプログラム４２には検査用コードが挿入されてい
るので、実行結果ログ４３が作成される。

【００３７】実行結果ログ検査手段３３は、ソフトウェ
ア４２に対するテスト項目を実施した結果が、内部仕様
４０に合致しているか否かを検査する。検査用ルール４
１と実行結果ログ４３とを比較して、実行結果ログ４３
が検査用ルール４１から導出できるかどうかを判別す
る。検査用ルール４１は、内部仕様４０に基づいてプロ
グラムが動作すべき流れを表わしたものである。これに
対し、実行結果ログ４３は、実際に動作したプログラム
の流れを表わしたものである。検査用ルール４１に記述
された流れと、実行結果ログ４３に記述された流れとを
比較することによって、プログラム４２が内部仕様４０
どおりに動作したかどうかを調べることができる。両者
の流れが最後まで一致した場合、実行結果ログ４３は検
査用ルール４１から導出できると判別される。しかし、
両者の流れが途中で一致しない場合は、実行結果ログ４
３は検査用ルール４１から導出できなかったことにな
る。実行結果ログ検査手段３３は、導出できるか否かを
判定した後、この結果を検査結果レポート３４として出
力する。オペレータは、この検査結果レポート３４を見
て内部仕様４０どおりにソフトウェア４２が動作したか
どうかを検査することができる。

【００３８】以上説明したソフトウェア検査支援装置１
０の動作の流れを、実際のテスト作業とともに説明す
る。

【００３９】図６は、本発明の一実施例における外部仕
様を表わしたものである。外部仕様は図示しない要求仕
様に基づいて作成されたものである。ここでは、「関数
ｆ(x)は、入力値ｘが奇数なら関数ｇ(x)の値を出力し、
偶数なら０を出力する。関数ｇ(x)は、入力値ｘに対し
て２ｘを出力する。」という内容の仕様が規定されてい
る。

【００４０】図７は、図６に示した外部仕様に基づいて
作成された内部仕様である。本実施例では、内部仕様の
表現手段として、ＰＡＤ図（problem analysis diagr
am）を用いている。ＰＡＤ図とは、プログラムの構造お
よび実行手順を所定の構文規則に基づいて表現したもの
である。プログラミングにおける３つの基本形（連接、
選択、反復）を明確に表現するために、図形を樹木状に
組み合わせている。このＰＡＤ図では、図６の外部仕様
に基づいて関数ｆ(x)５０とｇ(x)５１の処理を表わして
いる。関数ｆ(x)の処理は、「入力値xが奇数なら関数ｇ
(x)の値を出力し、入力値xが偶数なら０を出力する」も
のなので、３つの基本型（連接、選択、反復）のうちの
「選択」に該当する。関数ｆ(x)５０の図形５２は、
「選択」を表現したものである。

【００４１】図８は、図７に示したＰＡＤ図に基づいて
作成されたソースコードである。本実施例では、プログ
ラム言語としてＣ言語を用いている。なお、各コードの
左側には行番号５３が記述されている。

【００４２】本実施例では、ソフトウェア検査支援装置
１０による検査用ルール作成が、検査用ルールを表現す
る形式として属性文法の一種を利用している。プログラ
ム言語を構成する記号や単語の並べ方には一定の規則が
ある。プログラムは、通常その言語に応じた構文規則に
基づいて作成される。例えば、C言語では「ｉｆ〜ｅｌ
ｓｅ、ｗｈｉｌｅ、ｒｅｔｕｒｎ」のようなキーワード
によって制御されている。そして、このようなプログラ
ムの流れを記述する内部仕様も、その言語に応じた構文
規則を考慮して一定の文字や図形で記述されていること
が多い。このような内部仕様の構造を解析し、これを属
性文法の形式で新たに表現したものが検査用ルールであ
る。本実施例で利用する属性文法の特徴を簡単に説明す
ると、文脈自由文法に対して、各非終端記号に属性
を、各プロダクションルールに意味規則を追加したも
のである。ＰＡＤ図では、プログラムの動作を「連接、
反復、選択」の３つの制御構造で記述している。よっ
て、これらの制御構造を分析することで、プログラムの
流れと内容に関するルールを属性文法によって表現する
ことができる。

【００４３】図９は、プログラムの３つの制御構造（連
接、反復、選択）を属性文法で表現した例である。大文
字で始まる記号は非終端記号、小文字で始まる記号は終
端記号を意味している。反復の「Ａ→ＢＢＢ…ＢＢＢ」
は一定回数の反復で一定個の非終端記号が並ぶことを示
している。また、反復の「Ａ→（反復条件）ＢＡ」で
は、不定回数の反復で反復条件を意味規則とすることが
できることを示している。反復の「Ａ→（反復終了条
件）φ」は、反復終了条件を意味規則とすることができ
ることを示している。

【００４４】図１０は、ソフトウェア検査支援装置１０
による検査用ルール作成の流れを表わしたものである。
以下、図７の内部仕様を使用して実際に検査用ルールを
作成する手順を説明する。図７の内部仕様は、キーボー
ド１８やテープなどの外部記憶媒体１６から入力し、記
憶媒体１３に格納する。ここでは、内部仕様に記述され
た関数ｆ(x)について検査用ルールを作成する。記憶媒
体１３には、検査用ルールを作成するための規則と、入
力される内部仕様の構造に関する情報があらかじめ記憶
されている。

【００４５】検査用ルール作成手段３０は、まず、内部
仕様から所定の関数（ステップＳ２０１；Ｙ）とその関
数名を読み出す（ステップＳ２０２）。次に、取得した
関数名を使用して関数についてのルールを作成する。図
７のＰＡＤ図では、関数名ｆが読み出され、「Ｆ→｛en
ter f(EXP1) Fbody exit F(EXP2)｝」というルール
を作成する（ステップＳ２０３）。このルールでは、非
終端記号「Ｆ」に対して「｛enter f(EXP1) Fbody e
xit F(EXP2)｝」という処理が続くことを意味してい
る。作成されたルールは、検査用ルールの集合に追加さ
れる（ステップＳ２０４）。検査用ルールは、各プログ
ラムの処理に対応して作成されるので、一連のルールは
検査用ルールの集合として記憶媒体１３に記憶される。
関数ｆ(x)についてのルールを作成したら、関数ｆ(x)の
内部処理である「Fbody」のためのルールを作成する
（ステップＳ２０５）。そして、このルールを検査用ル
ールの集合に同じように追加する（ステップＳ２０
６）。

【００４６】図１２は、このような検査用ルール作成手
段によって図７の内部仕様から最終的に作成される検査
用ルールの集合を表わしたものである。ここで、ルール
（ａ）は関数ｆ(x)のルールを示している。

【００４７】図１１は、図１０のステップＳ２０５で説
明した「Fbody」のためのルールを作成する処理の内容
を詳細に表わしたものである。検査用ルール作成手段
は、図７のＰＡＤ図から「Fbody」にあたる処理を読み
出し、３つの制御構造（連接、反復、選択）のどれに当
たるかを判別する（ステップＳ３０１）。記憶媒体１３
の検査用ルールを作成するための規則を参照して（ステ
ップＳ３０２）、判別された制御構造に該当するルール
を作成する（ステップＳ３０３）。図７の関数ｆ(x)５
２は、「連接、反復、選択」のうちの「選択」を表わし
ていると判別される（ステップＳ３０１）。そこで、
「選択」に関する検査用ルールを読み出して（ステップ
Ｓ３０２）、関数ｆ(x)５２のルールを作成する（ステ
ップＳ３０３）。図１２を参照すると、ルール（ｂ）お
よび（ｃ）が追加されている。ここで、「Fbody」にあ
たる処理が、３つの制御構造のうちの「反復」である場
合は、一定回数の反復か否かに応じて、反復用の検査ル
ールが作成される。また、「連接」であると判別した場
合は、連接用の検査ルールが作成される。

【００４８】図１２の各検査用ルールの内容について説
明する。大文字から始まる記号は非終端記号（例えば
Ｆ、Fbt）、小文字から始まる記号は終端記号（例えば
{ enter、f(x)）を意味する。ここで、プログラムの階
層構造は、一定の木構造で表現することができる。この
場合、上位の階層から下位の階層に向けて木の枝が伸び
ていくかたちで表現すると、枝が伸びている根元にある
記号を非終端記号、枝が伸びていない記号を終端記号と
いう。ルールの左辺には１つの非終端記号をおいて、右
辺にはその記号から伸びている記号群をおいている。こ
の左辺の非終端記号から右辺の記号群を導出していくこ
とで、プログラムの動作を検査することができる。非終
端記号「EXP」６０はＣ言語の任意の式を表わしてい
る。また、「expr(EXP)」６１は、変数に対する代入文
を表わすものである。「｛enter f(EXP)〜」６２また
は「〜exit f(EXP)｝」６３などは、プログラム内部
の論理的な処理の流れを表現するための記号群である。
関数や復号文などのブロックの入口や出口を表現するた
めのものである。このように、検査用ルールを作成する
ためには、あらかじめ用意された属性文法やＣ言語の構
文規則に関する情報を参照することで行う。

【００４９】図１３は、検査用コード挿入手段３１が、
ソースコードにコードを挿入するときの条件と挿入する
コードをあらかじめ対応づけて記憶したテーブルを表わ
したものである。検査用コードは、テストの実行経過を
記録したログを収集するためにソースコードに挿入する
ものである。よって、プログラムの流れがわかるような
箇所に挿入するのが一般的である。ここでは、関数の入
口と出口や、条件文の肯定節と否定節の各入口に所定の
コードを挿入している。また、代入文のように変数の値
が変化する場合は、その変化内容が識別できるようにコ
ードを挿入する。なお、実行結果ログからソースコード
の位置がすぐに認識できるように、行番号を表示するコ
ードも挿入する。また、図示していないが、関数の引数
や戻し値などを表示するコードを挿入してもよい。

【００５０】検査用コード挿入手段３１は、ソースコー
ドを順次読み出して、図１３のテーブルを参照しながら
所定の箇所に検査用コードを挿入していく。ソースコー
ドは、キーボード１８やテープなどの外部記憶媒体１６
から入力し、記憶媒体１３に格納しておく。対象となる
コードが関数の入口であると判別したきは、コード「行
番号｛enter 関数名（引数）」を挿入する。また、関
数の出口では、「行番号 exit 関数名（引数）｝」を
挿入する。また、条件文の肯定節の入口では、「行番号
true 関数名（条件式）」を挿入する。また、条件文の
否定節の入口であるときは、「行番号false 関数名
（条件式）」を挿入する。

【００５１】図１４は、検査用コード挿入手段３１が、
図１３のテーブルを参照して、図８のソースコードに検
査用コードを挿入したものである。printf７１、printf
７４は関数の入口に該当するコードを挿入している。pr
intf７３、printf７９は関数の出口に該当するコードを
挿入している。printf７５は条件文の肯定節の入口に該
当するコードを挿入している。printf７７は条件文の否
定節の入口に該当するコードを挿入している。printf７
２、printf７６、printf７８は変数の値が変わるポイン
トに該当するコードを挿入している。これにより、テス
トを実施した場合の、プログラムの内部的な経過がログ
として出力される。

【００５２】テストを実行するオペレータは、内部仕様
から検査用ルールを作成し、ソースコードに対して検査
用ルールの挿入が終了すると、動作テストを実行する。
オペレータは、所定のテスト項目に従って、テストデー
タをソフトウェア検査支援装置１０に入力する。ここで
は、入力値としてｘ＝５、ｘ＝０を入力したものとす
る。テスト実行手段３２は、入力されたデータに基づい
て検査用コードの挿入されたソースコードを実行する。
よって、入力値としてｘ＝５、ｘ＝０が与えられた場合
の実行結果ログが出力される。

【００５３】図１５は、入力値としてｘ＝５を与えた場
合の実行結果ログ、図１６は、入力値としてｘ＝０を与
えた場合の実行結果ログを表わしたものである。なお、
実行結果ログ中の改行や字下げは、説明のために便宜的
につけたものである。

【００５４】図１７は、実行結果ログ検査手段３３が実
行結果を検査する際に行う初期設定の手順を表わしたも
のである。検査は、それぞれ対応する検査ルールの流れ
と実行結果ログの流れを、各記号単位に比較していくこ
とによって行うので、各記号を特定するための注目点
ｐ、ｑをそれぞれの開始地点に設定する必要がある。実
行結果ログ検査手段３３は、図１２の検査用ルールと、
図１５の実行結果ログとを比較する。

【００５５】実行結果ログ検査手段３３は、記憶媒体１
３に記憶されている検査用ルールの集合を読み出す（ス
テップＳ４０１）。そして、最初に実行される関数名に
相当する非終端記号を左辺に持つルールＸを、検査用ル
ールの集合から検索する。ルールＸを検索すると（ステ
ップＳ４０２；Ｙ）、ルールＸを記号単位に見ていくた
めの注目点ｑを、ルールＸの右辺の先頭の記号に設定す
る（ステップＳ４０３）。図１２の検査用ルールでは、
ルール（ａ）が最初に実行される関数ｆに相当するの
で、ルールＸに該当する。よって、注目点ｑは、（ａ）
の右辺にある記号「｛ enter」に設定される。

【００５６】次に、記憶媒体１３に記憶された実行結果
ログを読み込んで（ステップＳ４０４）、該当するログ
を検索する（ステップＳ４０５）。既に複数のテスト項
目が実施されている場合には、複数の実行結果ログが記
憶されているからである。該当するログを検索すると
（ステップＳ４０５；Ｙ）、実行結果ログを記号単位に
見ていくときの注目点ｐを、ログの先頭に設定する（ス
テップＳ４０６）。ここでは、検索された図１５の実行
結果ログについて（ステップＳ４０５；Ｙ）、注目点ｐ
は、実行結果ログの先頭にある記号「｛ enter」に設
定される。

【００５７】図１８は、実行結果ログ検査手段３３が、
初期設定を終えて実行結果を検査していく流れを表わし
たものである。ルールＸ上の注目点ｑと実行結果ログ上
の注目点ｐからそれぞれ開始して、注目点ｐ以降の実行
結果ログを導出することが可能かどうかを検査する。は
じめに、検査用ルールＸの注目点ｑが設定された記号
は、終端記号か非終端記号かを判別する（ステップＳＳ
５０１）。図１２の検査用ルールでは、注目点ｑの設定
された位置にある記号は「{ enter」であるので、終端
記号であると判別される（ステップＳ５０１；Ｙ）。

【００５８】ステップＳ５０１で注目点ｑの記号「{ e
nter」が、終端記号であると判別されたら、終端記号は
注目点ｐにある記号と一致するか否かを調べる。図１５
の実行結果ログでは、注目点ｑにある記号は「｛ ente
r」であるので、注目点ｐの記号「｛ enter」と一致す
ることがわかる（ステップＳ５０２；Ｙ）。

【００５９】注目点ｐとｑにある記号が一致したと判別
されると、注目点ｐとｑをそれぞれ次の記号に移動させ
る（ステップＳ５０３）。ここで、注目点ｑはルールＸ
の最後に到達したか否かを判別する。図１２で、注目点
ｑは「｛ enter」の次の記号である「f(EXP)」に移動
しているが、記号はまだ続いているので、最後に到達し
ていないことがわかる（ステップＳ５０４；Ｎ）。従っ
て、ステップＳ５０１に戻って、注目点ｑにある「f(EX
P)」について、同様に検査を実行する。

【００６０】注目点ｑにある「f(EXP)」は終端記号で
（ステップＳ５０１；Ｙ）、注目点ｐにある記号「f
(0)」と一致するので（ステップＳ５０２；Ｙ）、注目
点ｐ、ｑはそれぞれ次の記号に移動する（ステップＳ５
０３）。ここで、注目点ｑは「Fb」に移動し、注目点ｐ
は「true(x&1)」に移動している。ステップＳ５０１に
戻って注目点ｑについての検査を開始すると、注目点ｑ
の記号は「Fb」であるので、非終端記号であることがわ
かる（ステップＳ５０１；Ｎ）。よって、次の流れを規
定したルールＹを新たに探す必要がある。つまり、注目
点ｑの非終端記号「Fb」を左辺に持つルールＹを、検査
用ルールの集合の中から探す（ステップＳ５０６）。

【００６１】図１９は、図１８のステップＳ５０６にて
注目点ｐ以下の実行結果ログが、ルールＹから開始して
導出できるか否かについての流れを詳細に説明したもの
である。実行結果ログ検査手段３３は、図１２の検査用
ルールの中から、注目点ｑにある非終端記号「Fb」を左
辺に持つルールＹを探す（ステップＳ６０１）。ここ
で、「Fb」を左辺に持つルールとして、最初にルール
（ｂ）が該当するので（ステップＳ６０１；Ｙ）、注目
点ｐ以降のログを導出できるかどうかを図１８のステッ
プＳ５０１以下の手順に従って検査する（ステップＳ６
０２）。

【００６２】注目点ｑは、ルール（ａ）の非終端記号
「Fb」からルール（ｂ）の右辺の先頭にある記号「true
(EXP)」に移動する。図１８のステップＳ５０１から開
始すると、注目点ｑにある記号「true(EXP)」は終端記
号であり（ステップＳ５０１；Ｙ）、図１５の注目点ｐ
の記号は「true(x&1)」であるので、両者は一致する
（ステップＳ５０２；Ｙ）。従って、注目点ｐ、ｑをそ
れぞれ次の記号「｛ enter」、「Fbt」に移動させる
（ステップＳ５０３）。注目点ｑは、ルールＸにあたる
ルール（ａ）の最後ではないので、ステップＳ５０１に
戻る（ステップＳ５０４；Ｎ）。ここで、注目点ｑにあ
る「Fbt」は非終端記号であるので、検査用ルールの中
から該当するルールとして新たなルール（ｄ）を探し出
す。

【００６３】注目点ｑは、ルール（ｂ）の非終端記号
「Fbt」からルール（ｄ）の右辺の先頭にある記号「G」
に移動し、図１８のステップＳ５０１から検査を開始す
る。ここで、注目点ｑにある記号「G」は非終端記号で
あるので（ステップＳ５０１；Ｎ）、再び検査用ルール
の中から該当するルールとしてルール（ｆ）を判別する
（ステップＳ５０６）。そして、ルール（ｆ）の右辺の
先頭にある記号「｛enter」に注目点ｑを移動する。一
方、図１５の注目点ｐは「｛ enter」のままであり、
両者は一致する（ステップＳ５０２；Ｙ）。

【００６４】このように、図１８の検査手順に従って検
査用ルールと実行結果ログとを比較していく。すると、
実行結果ログは、検査用ルール（ａ）から始まって、ル
ール「ａ−ｂ−ｄ−ｆ−ｇ」の経路で導出できることが
わかる。これにより、図８のプログラムの動作結果が図
７に示した内部仕様に合致していることがわかる。同様
に、図１６の実行結果ログを導出すると、ルール「ａ−
ｃ−ｅ」という流れで導出できることがわかる。

【００６５】図２０は、導出失敗例となる実行結果ログ
を表わしたものである。プログラマが、図７の内部仕様
に基づいてコーディングをする際に、関数ｆ(x)の中の
条件文の肯定節と否定節とを間違えたとする。つまり、
入力値ｘが奇数なら０を出力し、偶数なら関数ｇ(x)の
値を出力するように、コーディングしてしまったとす
る。しかし、入力値として例えばX＝０を与えてテスト
を実行すると、コーディングミスをしているにも関わら
ず、偶然正しい出力結果ｆ(x)＝０が得られてしまうこ
とがわかる。よって、入力と出力との関係だけでは外部
仕様に合致しているので、動作に誤りはないことにな
る。

【００６６】しかし、実行結果ログ検査手段３３が、図
１２の検査用ルールを適用すると、図２０の実行結果ロ
グを導出している最中で、導出不可能であることがわか
る。すなわち、図１８の手順に従って、ステップ５０１
から検査を開始すると、ルール「ａ−ｃ−ｅ−導出不可
能」という結果になる。ルール（ｅ）の段階で、注目点
ｑは検査用ルール（ｅ）の右辺の先頭に位置する記号
「expr」にあるが、注目点ｐは実行結果ログの「｛ en
ter」にある。よって、注目点ｑは終端記号であるにも
関わらず注目点ｐの記号と一致しないと判別される（ス
テップ５０２；Ｎ）。よって、注目点ｐ以降の終端記号
「｛ enter g(o)…」を受け入れる検査用ルールがな
いため、導出不可能となり（ステップＳ５０７）、この
ソースコードに誤りがあると判定する。テスト実施者
は、偶然正しい出力が得られるもののソースコード上に
誤りが含まれていることがわかり、これを修正すること
になる。

【００６７】また、図１８のステップ５０７で、導出不
可能と判別されたとき、実行結果ログ検査手段３３は、
実行結果ログ中の行番号情報からソースコード上の修正
すべき場所を比較的容易に探し当てることができる。修
正すべき箇所は、例えば、図２０の実行結果ログを検査
した際に導出不可能になった前後を見ることとすればよ
い。ここでは、注目点ｐが実行結果ログの「｛ ente
r」ある時点で、導出不可能と判別されたので、行番号
「＠２」「＠１２」から、ソースコード中の１２行目あ
るいは２行目にエラーがあると予測する。ここで図２０
の実行結果ログを見ると、１２行目に本来肯定節中にあ
るものが否定節中にあることがわかる。

【００６８】図２１は、実行結果ログが導出不可能であ
った場合の検査結果レポートの例である。実行結果ログ
検査手段３３は、検査結果レポートとして実行結果ログ
の導出判定の過程８０とその結果８１を出力する。実行
結果ログが導出不可能であった場合は、誤り位置を指摘
するためにソースコード上の行番号８３も出力する。図
２１では、Parse error８０の指摘より関数ｇ(x)が誤
って呼び出されていることがわかるとともに、ソースコ
ード上の行番号８２が表示されている。よって、デバッ
グを行う者は、検査結果レポートを参照することで効率
的にソースコードの該当する箇所を探して修正すること
ができる。

【００６９】以上説明したように、オペレータは、内部
仕様とソースコードをあらかじめ入力しておいてテスト
を実施すると、検査結果レポートを入手してテスト結果
を知ることができる。本実施例では、非常に小さく単純
なプログラムを例にあげて説明したため、図６のＰＡＤ
図での記述が実際のソースコードとほとんど詳細度が同
じである。このため、検査結果レポートに出力される実
行結果ログもソースコードとほとんど同じ詳細度であ
る。しかし、実際には内部仕様書の詳細度は自由であ
り、仕様書の詳細度に応じて検査用ルールが作成され、
またこれに応じてソースコードに検査用コードが挿入さ
れる。よって、内部仕様書の詳細度に応じて、実行結果
ログ検査装置での検査の緻密さも変化することになる。

【００７０】図５は、図２１の検査結果レポートに基づ
いてソースコード上の誤りを修正した後、再度同じテス
ト項目を実施した場合のソフトウェア検査支援装置１０
の機能の一例を表わしたものである。実行結果ログ管理
手段３５は、各テスト項目が実行されるごとに、その実
行結果ログ４３とテスト実行履歴４４とを記憶媒体３１
に記憶してこれを管理する。そして、デバッグを行った
後のテストの際に、デバッグを行う前の実行結果ログと
デバッグを行った後の実行結果ログとを比較して、比較
結果レポート３６を出力する。

【００７１】テスト項目を実施して実行結果ログからプ
ログラムにバグがあることがわかると、デバッグを行う
者は、ソースコード上の誤りを探し出してこれを修正し
なければならない。そして、再度おなじ動作テストを実
行して、このバグが取り除かれたかどうかを確認する必
要がある。バグが取り除かれていればこのテスト項目は
終了する。ところが、ソースコード上の誤りを１箇所修
正すると、今まで仕様どおりに正常に動作していた別の
箇所に影響を及ぼして、新たなバグ（エンバグ）を生む
ことがある。このため、ソースコードを一度修正した場
合には、他の関連箇所に影響を与えているか否かを検査
する必要がある。

【００７２】図２２は、図２１の検査結果レポートに基
づいてソースコード上の誤りを修正した後、再度テスト
を実施して動作が正常だった場合の実行結果ログの比較
結果レポートを表わしている。図２２の左側には修正前
の実行結果ログが記述され、右側には修正後の実行結果
ログが記述されている。図２０は、条件文の内容を間違
えてコーディングした場合の実行結果ログである。これ
に基づいてソースコードの該当する箇所すなわち条件文
の内容を修正し、入力データX＝０を入力して同じテス
トを再実行した。ここで、再実行して動作が正常だった
場合の実行結果ログが図２２の右側に示されている。

【００７３】比較結果レポートの右側と左側とを比較す
ると、両者の相違点が、ソースコード上の修正箇所に対
応していることがわかる。よって、この範囲では他の箇
所に影響を与えていないので、エンバグの可能性が少な
いことがわかる。これに対し、修正前と修正後の実行結
果ログを比較して、ソースコード上の修正箇所以外に相
違点があれば、エンバグの可能性があると判別される。
この場合、実行結果ログ管理手段３５は、エンバグの可
能性を比較結果レポートで指摘して警告をしたりソース
コードの確認を求めることができる。

【００７４】以上説明した実施例では、内部仕様として
ＰＡＤ図を用いプログラム言語にＣ言語を用いて説明し
たが、他の形式で記述された内部仕様やＣ言語以外のプ
ログラム言語に対して、本発明を適用することも可能で
ある。また、検査用ルールの生成手段として属性文法の
一種を用いる際に、プロダクションルールで制御構造を
記述する以外に、付加的な検査条件を属性と意味規則に
よって記述することも可能である。例えば、特定の変数
の値の範囲を制限するような記述を含めることもでき
る。さらに、属性文法以外の文法規則、たとえば自由文
脈文法などを用いた場合にも本発明を適用することはで
きる。この場合、検査用ルールの表現形式に応じて実行
結果ログの表現形式を変えても良い。

【００７５】また、本実施例では、検査用コード挿入手
段を、ソースコードレベルで検査用コードを挿入するも
のとして説明したが、ソースコードをコンパイルすると
きに挿入したり、あるいはコンパイル後の実行形式プロ
グラムに対して挿入する場合にも本発明を適用すること
は可能である。また、本実施例では、検査用コードの挿
入によるログは標準出力に出力しているので文字情報で
出力されているが、例えば絵やグラフで出力する場合に
も本発明を適用することはできる。

【００７６】また、本実施例では、バグがあった実行結
果ログと、デバッグをしてバグを取り除いた後の実行結
果ログとを比較することで、エンバグの可能性を検査す
る場合について説明した。しかし、テストの実施者が、
テストの履歴データから任意に過去のテストを幾つか選
択し、選択された各実行結果ログ同士を比較させるよう
にしてもよい。

【００７７】

【発明の効果】以上説明したように請求項１記載の発明
によれば、仕様書とソースコードを入力することで、ソ
フトウェアの内部動作とその動作が仕様書に合致してい
るか否かを検査することができる。これにより、とかく
形骸化しがちな仕様書をきちんと記述しておけば、緻密
な検査を行うことができるので、テスト工程における能
率を結果的に上げることができる。その結果、ソフトウ
ェアの質を向上させることができる。

【００７８】また請求項２記載の発明によれば、デバッ
グを行う者がこの内部仕様やソースコードをよく知らな
いような場合でも、指摘されたソースコード上の誤り位
置と内部仕様とを参照することで、容易に誤りを修正す
ることができるという効果がある。

【００７９】また請求項３記載の発明によれば、プログ
ラムの作成者とテストの実施者が異なるような場合で
も、実行結果ログをプログラム作成者が見れば、動作に
不具合が生じたときのプログラムの動作を容易に把握す
ることができるという効果がある。特に、テストを行う
者がプログラムに関して十分な知識がない場合は、テス
トで誤りを発見してもプログラムの作成者にうまくその
状況を伝えることは難しい。このような場合にも、検査
結果レポートを残しておけば後のデバッグ作業に支障が
ないので、動作テストとデバッグ作業とを効率的に行う
ことができるという効果がある。

【００８０】また請求項４記載の発明によれば、各テス
ト段階における実行結果ログを比較することで、他のプ
ログラムと結合することによるエンバグを防止すること
が可能となる。例えば、単体テストから統合テストへと
テスト段階が進むにつれ、プログラムは次々と結合され
ていく。各ソースコードは正常に動作していても、他の
ソースコードと結合することでバグを生じることがあ
る。そこで、各テスト段階における実行結果ログを比較
すれば、プログラムを結合することで生じる新たなバグ
の可能性を警告できるという効果がある。

【００８１】また請求項５記載の発明によれば、テスト
を実施する者が、比較結果レポートでエンバグの可能性
をチェックすることができるので、再度テストすべき項
目を効率よく選択することができるという効果がある。

【図面の簡単な説明】

【図１】本発明の一実施例におけるソフトウェア検査支
援装置の構成の概要を表わした構成図である。

【図２】ソフトウェアの開発における一般的な作業工程
を表わしたものである。

【図３】テスト項目を１つ実施する場合の動作を具体的
に表わした流れ図である。

【図４】本発明の一実施例におけるソフトウェア検査支
援装置の機能的な構成を表わしたものである。

【図５】本発明の一実施例における要求仕様を表わした
平面図である。

【図６】図５の要求仕様に基づいて作成された外部仕様
を表わした平面図である。

【図７】図６の外部仕様に基づいて作成された内部仕様
を表わした平面図である。

【図８】図７の内部仕様に基づいて作成されたソースコ
ードを示した平面図である。

【図９】プログラムの３つの制御構造を属性文法で表現
した例を示した平面図である。

【図１０】ソフトウェア検査支援装置１０による検査用
ルール作成の手順を表わした流れ図である。

【図１１】図１０のステップＳ２０５で説明した「Fbod
y」のためのルールを作成する処理の内容を詳細に表わ
した流れ図である。

【図１２】図７の内部仕様から作成された検査用ルール
を表わした平面図である。

【図１３】検査用コード挿入手段３１が、ソースコード
にコードを挿入するときの条件と挿入するコードをあら
かじめ対応づけて記憶したテーブルを表わした平面図で
ある。

【図１４】検査用コード挿入手段３１が、図８のソース
コードに対して検査用コードを挿入したものを示した平
面図である。

【図１５】入力値としてｘ＝５を与えた場合の実行結果
ログを示した平面図である。

【図１６】入力値として「X＝０」を与えた場合の実行結
果ログを示した平面図である。

【図１７】実行結果ログ検査手段３３が、実行結果を検
査する際に行う初期設定の手順を表わした流れ図であ
る。

【図１８】実行結果ログ検査手段３３が、初期設定を終
えて実行結果を検査していく流れを表した流れ図であ
る。

【図１９】実行結果ログ検査手段３３が、図１８のステ
ップＳ５０６にて注目点ｐ以下の実行結果ログをルール
Ｙから開始して導出できるか否かについて検査する流れ
を詳細に説明した流れ図である。

【図２０】導出失敗例となる実行結果ログを示した平面
図である。

【図２１】実行結果ログが導出不可能であった場合の検
査結果レポートを示した平面図である。

【図２２】再度テストを実施した場合の実行結果ログの
比較結果レポートを示した平面図である。

【符号の説明】

１０…ソフトウェア検査支援装置、１１…ＣＰＵ、１２
…ＲＯＭ、１３…記憶媒体、１４…ＲＡＭ、１５…プリ
ンタ、１６…外部記憶媒体、１７…ＣＲＴ、１８…キー
ボード、１９…バス

Claims (5)

【特許請求の範囲】
1. 【請求項１】 プログラム言語の構文規則としての第１
   の構文規則に従ってプログラムの処理手順を記述した仕
   様データを入力する仕様データ入力手段と、 プログラムの処理手順を第２の構文規則で記述するため
   の記号を記憶した記号テーブルと、 前記仕様データ入力手段の入力した仕様データを前記記
   号テーブルに基づいて記号データに変換し、検査用ルー
   ルを作成する検査用ルール作成手段と、 プログラムを入力するプログラム入力手段と、 プログラムの実行経過を記録するためのコードを記憶し
   たコードテーブルと、 前記プログラム入力手段の入力したプログラムに対して
   前記コードテーブルに基づいてコードを挿入し、プログ
   ラムの実行経過を記録した実行結果ログを作成する実行
   結果ログ作成手段と、 この実行結果ログ作成手段の作成した実行結果ログが、
   前記検査用ルール生成手段が生成した検査用ルールと一
   致するか否かを、前記第２の構文規則に従って検査する
   実行結果検査手段とを具備することを特徴とするソフト
   ウェア検査支援装置。
2. 【請求項２】 プログラム言語の構文規則としての第１
   の構文規則に従ってプログラムの処理手順を記述した仕
   様データを入力する仕様データ入力手段と、 プログラムの処理手順を第２の構文規則で記述するため
   の記号を記憶した記号テーブルと、 前記仕様データ入力手段の入力した仕様データを前記記
   号テーブルに基づいて記号データに変換し、検査用ルー
   ルを作成する検査用ルール作成手段と、 プログラムを入力するプログラム入力手段と、 プログラムの実行経過を記録するためのコードを記憶し
   たコードテーブルと、 前記プログラム入力手段の入力したプログラムに対して
   前記コードテーブルに基づいてコードを挿入し、プログ
   ラムの実行経過を記録した実行結果ログを作成する実行
   結果ログ作成手段と、 この実行結果ログ作成手段の作成した実行結果ログが、
   前記検査用ルール生成手段が生成した検査用ルールと一
   致するか否かを、前記第２の構文規則に従って検査する
   実行結果検査手段と、 この実行結果検査手段の検査結果が前記実行結果ログが
   前記検査用ルールに適合しないものであるとき、前記実
   行結果ログから前記プログラム入力手段の入力したプロ
   グラムの中の誤り位置を検出する誤り位置検出手段とを
   具備することを特徴とするソフトウェア検査支援装置。
3. 【請求項３】 プログラム言語の構文規則としての第１
   の構文規則に従ってプログラムの処理手順を記述した仕
   様データを入力する仕様データ入力手段と、 プログラムの処理手順を第２の構文規則で記述するため
   の記号を記憶した記号テーブルと、 前記仕様データ入力手段の入力した仕様データを前記記
   号テーブルに基づいて記号データに変換し、検査用ルー
   ルを作成する検査用ルール作成手段と、 プログラムを入力するプログラム入力手段と、 プログラムの実行経過を記録するためのコードを記憶し
   たコードテーブルと、 前記プログラム入力手段の入力したプログラムに対して
   前記コードテーブルに基づいてコードを挿入し、プログ
   ラムの実行経過を記録した実行結果ログを作成する実行
   結果ログ作成手段と、 この実行結果ログ作成手段の作成した実行結果ログが、
   前記検査用ルール生成手段が生成した検査用ルールと一
   致するか否かを、前記第２の構文規則に従って検査する
   実行結果検査手段と、 この実行結果検査手段の検査した内容に基づいて実行結
   果レポートを出力する実行結果レポート出力手段とを具
   備することを特徴とするソフトウェア検査支援装置。
4. 【請求項４】 プログラム言語の構文規則としての第１
   の構文規則に従ってプログラムの処理手順を記述した仕
   様データを入力する仕様データ入力手段と、 プログラムの処理手順を第２の構文規則で記述するため
   の記号を記憶した記号テーブルと、 前記仕様データ入力手段の入力した仕様データを前記記
   号テーブルに基づいて記号データに変換し、検査用ルー
   ルを作成する検査用ルール作成手段と、 プログラムを入力するプログラム入力手段と、 プログラムの実行経過を記録するためのコードを記憶し
   たコードテーブルと、 前記プログラム入力手段の入力したプログラムに対して
   前記コードテーブルに基づいてコードを挿入し、プログ
   ラムの実行経過を記録した実行結果ログを作成する実行
   結果ログ作成手段と、 この実行結果ログ作成手段の作成した実行結果ログが、
   前記検査用ルール生成手段が生成した検査用ルールと一
   致するか否かを、前記第２の構文規則に従って検査する
   実行結果検査手段と、 前記実行結果ログ作成手段の作成した実行結果ログとこ
   の実行結果ログを作成した履歴とを記憶する実行結果ロ
   グ記憶手段と、 この実行結果ログ記憶手段の記憶した履歴に基づいて実
   行結果ログを比較する実行結果ログ比較手段とを具備す
   ることを特徴とするソフトウェア検査支援装置。
5. 【請求項５】 プログラム言語の構文規則としての第１
   の構文規則に従ってプログラムの処理手順を記述した仕
   様データを入力する仕様データ入力手段と、 プログラムの処理手順を第２の構文規則で記述するため
   の記号を記憶した記号テーブルと、 前記仕様データ入力手段の入力した仕様データを前記記
   号テーブルに基づいて記号データに変換し、検査用ルー
   ルを作成する検査用ルール作成手段と、 プログラムを入力するプログラム入力手段と、 プログラムの実行経過を記録するためのコードを記憶し
   たコードテーブルと、 前記プログラム入力手段の入力したプログラムに対して
   前記コードテーブルに基づいてコードを挿入し、プログ
   ラムの実行経過を記録した実行結果ログを作成する実行
   結果ログ作成手段と、 この実行結果ログ作成手段の作成した実行結果ログが、
   前記検査用ルール生成手段が生成した検査用ルールと一
   致するか否かを、前記第２の構文規則に従って検査する
   実行結果検査手段と、 前記実行結果ログ作成手段の作成した実行結果ログとこ
   の実行結果ログを作成した履歴とを記憶する実行結果ロ
   グ記憶手段と、 この実行結果ログ記憶手段の記憶した履歴に基づいて実
   行結果ログを比較する実行結果ログ比較手段と、 この実行結果ログ比較手段の比較した内容に基づいて実
   行結果ログ比較レポートを出力する実行結果ログ比較レ
   ポート出力手段とを具備することを特徴とするソフトウ
   ェア検査支援装置。