JPH07210424A - ソフトウェアテスト支援システム - Google Patents

Abstract

(57)【要約】 【目的】 効率的なソフトウェアテストを容易に行うこ
とのできるソフトウェアテスト支援システムを提供する
ことを目的とする。 【構成】 構造化プログラミング手法を用いて作成され
たソースコードは、ソースコード解析手段によって複数
の単位ルーチンに分類され、さらに、各単位ルーチンの
呼び出し関係の解析が行われる。テストケース作成手段
では、解析された各単位ルーチンの呼び出し関係に基づ
いて全ての呼び出しパターンを網羅する複数のテストケ
ースが作成される。このように、ソースコードに基づい
てテストケースを自動的に作成することが可能となるた
め、日本語などの自然言語で記述されたソフトウェアの
仕様書やソフトウェアの状態遷移仕様などをベースにテ
ストケースを作成する従来の方式に比べて、より簡便に
テストケースを作成することが可能となる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ソフトウェア開発にお
いて、その動作テストを実施する際に利用されるソフト
ウェアテスト支援システムに関し、特に、構造化設計手
法を利用してＣ言語等の高級言語を用いて開発されたア
プリケーション・ソフトウェアの動作テストに利用され
るソフトウェアテスト支援システムに関する。

【０００２】

【従来の技術】従来、ソフトウェアの動作テストは、
「テストケース作成の検討が不十分である。」、「テス
トケースを確実に試験していない。」といった２つの要
因によりテストが不十分になることが多い。

【０００３】通常のソフトウェア動作テストは、日本語
などの自然言語で記述されたソフトウェアの仕様書をも
とに、手作業でテストケースを作成し、このテストケー
スに基づいて行っている。しかしながら、このテストケ
ース作成の作業は元となるソフトウェアの仕様書の記述
内容（レベル）やテストケース作成を検討する個人の能
力に依存する場合が多く、テストケースの質の低下を招
いていた。

【０００４】一方、バグ修正あるいはバージョンアップ
に伴うソフトウェアの修正では、修正前のソフトウェア
作成の際に行われた動作テストを元にしてテストが行わ
れることが多い。しかしながら、この手法によって行わ
れるテストでも、対象とするソフトウェアに関するテス
トケースとして十分であるかは定かではない。修正前の
ソフトウェアに対して新規に機能追加等を実施した場合
には、その機能追加部分に対する新たなテストが必要と
なるからである。

【０００５】このような問題を解決する手法として、状
態遷移仕様から自動的にテストケースを作成する方式が
提案されている。このテストケースの自動生成方式につ
いては、以下の文献に詳細に記載されている。

【０００６】「状態遷移仕様からのテストデータ生成方
式」 情報処理学会第４２回 全国大会論文集 ｐｐ５−２１
８ 岡安 他 この文献に記載されたテストケースの自動生成方式を概
説すると、状態遷移仕様に基づいたソフトウェアの動作
パターン（動作列）をテストケースとして利用するもの
である。具体的には、状態遷移モデルにおいて記述され
る状態からの遷移を引き起こすイベントに着目して、発
生するイベントを順次並べたイベント系列を作成し、こ
れによって起こるシステムの状態遷移を動作パターンと
してテストケースに利用するものである。

【０００７】しかしながら、この生成方式は状態遷移仕
様がソフトウェア作成の際に作成されていることが前提
となるため、その適用範囲は極めて狭く実用的ではな
い。

【０００８】また、テストの十分性については、ソース
コードが一連の動作テストでどの程度網羅的に実行され
ているかを示すテストカバレジを計測することによって
十分性を評価する試みが従来より行われている（参考文
献：玉井哲雄 「ソフトウェアのテスト技法」 ｐ３
４，３５ 共立出版）。しかしながら、テストカバレジ
は、個々のモジュール内に含まれる命令や条件分岐等の
通過率を計測するものが殆どであり、ソフトウェアの詳
細部まで入り込むため、システムテストやソフトウェア
・システムテスト等の上位レベルのテストの十分性評価
には適していなかった。

【０００９】さらに、ソフトウェアの動作テストでは、
対象となるソースコードが修正・変更された場合には、
再度、テストケースについての検討が必要となる。特に
構造化設計技法を利用して作成されたソフトウェアで
は、ソースコードを構成する一部のモジュールを修正・
変更した場合の影響が、別の部分のモジュールに影響を
及ぼすケースが多く、単純に修正・変更したモジュール
部分のみを再テストすればよいとは限らないからであ
る。

【００１０】

【発明が解決しようとする課題】上述したように、従来
においては、ソフトウェアテストを実施する上でのテス
トケースの作成方式が確立されておらず、また、テスト
の十分性評価手法も片寄ったものであり問題であった。
このため効率的にテストケースを生成し、また、このテ
ストケースに従ってテストを実施した場合のテストの十
分性評価を容易に行うことを可能とするソフトウェアテ
スト支援システムが望まれていた。

【００１１】本発明は、かかる従来の問題を解決するも
のであり、試験対象ソフトウェアのソースコードから自
動的にテストケースを作成し、また、テスト実施結果と
このテストケースを比較評価し、モジュール・カバレジ
計測及び未試験モジュール特定などによりテストの十分
性を判定するシステムを提供することを目的とする。

【００１２】さらに、本発明は、対象となるソフトウェ
アが修正・変更を受けた場合にも、修正前のソースコー
ドおよびテストケースと対比して、容易に修正ソフトウ
ェアに対するテストケース生成等の支援を行うシステム
を提供することを目的とする。

【００１３】

【課題を解決するための手段】上記課題を解決するため
に、本発明のソフトウェアテスト支援システムは、
（ａ）ソースコードを複数の単位ルーチンに分類し、各
単位ルーチンの呼び出し関係を解析するソースコード解
析手段と、（ｂ）ソースコード解析手段で解析された各
単位ルーチンの呼び出し関係に基づいて、全ての呼び出
しパターンを網羅する複数のテストケースを作成するテ
ストケース作成手段とを備える。

【００１４】また、（ｃ）テストケース作成手段で作成
された複数のテストケースの一覧を帳票形式で出力する
テストケースレポート出力手段を備えていてもよい。

【００１５】さらに、（ｄ）ソースコードの各単位ルー
チンにテストプローブを挿入するテストプローブ挿入手
段と、（ｅ）テストプローブ挿入手段によってテストプ
ローブが挿入されたソースコードをコンパイル・リンク
してロードモジュールを作成するロードモジュール作成
手段と、（ｆ）テストケース作成手段で作成された各テ
ストケースに基づいて、ロードモジュール作成手段で作
成したロードモジュールを実行するテスト実行手段とを
備えていてもよい。この場合、テストプローブは、少な
くとも所定の履歴ファイルをオープンする命令と、この
履歴ファイルに挿入対象の単位ルーチンを特定する番号
を書き込む命令とを含んだ命令群である。

【００１６】さらにまた、（ｇ）テスト実行手段でのロ
ードモジュールの実行によって書き込まれた履歴ファイ
ルを分析して、ソースコードの全単位ルーチンの中の何
パーセントの単位ルーチンがこの履歴ファイルに書き込
まれているか検出すると共に、未実行のモジュールを検
出するモジュール網羅率評価手段を備えていてもよい。
この場合には、（ｈ）モジュール網羅率評価手段で検出
されたモジュール網羅率および未実行モジュールの一覧
を帳票形式で出力するモジュール網羅率出力手段とを備
えていてもよい。

【００１７】さらにまた、（ｊ）テスト実行手段でのロ
ードモジュールの実行によって書き込まれた履歴ファイ
ルを分析して、テストケース作成手段で作成された全テ
ストケースの中の何パーセントのテストケースがこの履
歴ファイルに書き込まれているか検出すると共に、未実
行のテストケースを検出するテストケース網羅率評価手
段を備えていてもよい。この場合には、（ｋ）テストケ
ース網羅率評価手段で検出されたテストケース網羅率お
よび未実行テストケースの一覧を帳票形式で出力するテ
ストケース網羅率出力手段とを備えていてもよい。

【００１８】さらにまた、（ｌ）バグ修正またはバージ
ョンアップによる修正が行われたソースコードを複数の
単位ルーチンに分類する修正ソースコード解析手段と、
（ｍ）ソースコード解析手段で分類された単位ルーチン
と修正ソースコード解析で分類された単位ルーチンとを
比較して、削除された単位ルーチンおよび追加された単
位ルーチンを検出する第１の修正単位ルーチン検出手段
と、（ｎ）修正前後のソースコードを比較して、修正ソ
ースコード解析で分類された単位ルーチンの中で修正さ
れた単位ルーチンを検出する第２の修正単位ルーチン検
出手段と、（ｏ）テストケース作成手段で作成されたテ
ストケースの内、第１の修正単位ルーチン検出手段で検
出された追加単位ルーチンを対象とするテストケースと
第２の修正単位ルーチン検出手段で検出された修正単位
ルーチンを対象とするテストケースとを特定する再実行
対象テストケース特定手段とを備えていてもよい。

【００１９】

【作用】本発明のソフトウェアテスト支援システムによ
れば、構造化プログラミング手法を用いて作成されたソ
ースコードは、ソースコード解析手段によって複数の単
位ルーチンに分類され、さらに、各単位ルーチンの呼び
出し関係の解析が行われる。単位ルーチンには、タスク
単位に分けたルーチンや、モジュール単位に分けたルー
チンがある。ここで、タスクとは構造化プログラムにお
けるソフトウェアとして一つのまとまった処理機能を実
現する単位をいい、モジュールとは構造化プログラムに
おけるソフトウェア構造の基本単位をいう。テストケー
ス作成手段では、解析された各単位ルーチンの呼び出し
関係に基づいて全ての呼び出しパターンを網羅する複数
のテストケースが作成される。このように、試験対象ソ
フトウェアのソースコードから自動的にテストケースを
作成することが可能となるため、日本語などの自然言語
で記述されたソフトウェアの仕様書やソフトウェアの状
態遷移仕様などをベースにテストケースを作成する従来
の方式に比べて、より簡便にテストケースを作成するこ
とが可能となる。

【００２０】また、テストケース作成手段で作成された
複数のテストケースの一覧は、テストケースレポート出
力手段によって帳票形式で出力される。このように出力
された書類はソフトウェアテストを実施する際の参考と
することができる。

【００２１】テストケース作成手段で作成されたテスト
ケースに基づいてテストを行うためには、以下のように
処理される。まず、テストプローブ挿入手段によってソ
ースコードの各単位ルーチンにテストプローブが挿入さ
れる。テストプローブ挿入後のソースコードはロードモ
ジュール作成手段によってコンパイル・リンクされてロ
ードモジュールが作成される。このロードモジュール
は、テスト実行手段で実行され、呼び出された全てのモ
ジュールの番号が履歴ファイルに記録される。

【００２２】履歴ファイルはモジュール網羅率評価手段
で分析され、モジュール網羅率および未実行モジュール
が検出される。このような検出を行うことにより、テス
トの抜けを明示的に把握することができるようになり、
テストの十分性が従来に比べ飛躍的に向上する。特に、
検出結果は、モジュール網羅率出力手段によって帳票形
式で出力できるので、追加テスト等の作成を効率的に行
うことができる。

【００２３】また、履歴ファイルはテストケース網羅率
評価手段でも分析され、テストケース網羅率および未実
行テストケースが検出される。このような検出を行うこ
とにより、テストの抜けを明示的に把握することができ
るようになり、テストの十分性が従来に比べ飛躍的に向
上する。特に、検出結果は、テストケース網羅率出力手
段によって帳票形式で出力できるので、追加テスト等の
作成を効率的に行うことができる。

【００２４】テスト時に発見されたバグ等の修正や、バ
ージョンアップによる修正を行った場合には、修正ソー
スコード解析手段によって修正後のソースコードを複数
の単位ルーチンに分類する。そして、第１の修正単位ル
ーチン検出手段で修正前後の単位ルーチンが比較され、
削除された単位ルーチンおよび追加された単位ルーチン
が検出される。さらに、第２の修正単位ルーチン検出手
段で修正前後のソースコードが比較され、修正された単
位ルーチンが検出される。このように検出された追加単
位ルーチンおよび修正単位ルーチンは再実行対象テスト
ケース特定手段に与えられ、これらの単位ルーチンを対
象としたテストケースが特定される。この特定により再
テストで実行すべきテストケースが判定評価され、また
特に重点的にテストすべき箇所が特定できるので、効率
的な再テストを実施することができる。

【００２５】

【実施例】以下、本発明の一実施例を添付図面を参照し
て説明する。

【００２６】図１〜図３は、本実施例に係るソフトウェ
アテスト支援システムの構成を示すブロック図である。
これらの図より、本実施例のソフトウェアテスト支援シ
ステムは、ソースコード１を複数のモジュール（または
タスク）に分類して各モジュールの呼び出し関係を解析
するソースコード解析部１０と、各モジュールの呼び出
し関係に基づいて複数のテストケースを作成するテスト
ケース作成部２０と、テストケースレポート３１を出力
するテストケースレポート出力部３０とを備えている。
また、ソースコード１にテストプローブを挿入するテス
トプローブ挿入部４０と、ソースコード１をコンパイル
・リンクしてロードモジュール３を作成するロードモジ
ュール作成部５０と、ロードモジュール３を実行してテ
ストカバレジを計測するテストカバレジ計測部６０とを
備えている。

【００２７】さらに、モジュール網羅率および未実行モ
ジュールの検出を行うモジュール網羅率評価部７０と、
テストケース網羅率および未実行テストケースの検出を
行うテストケース網羅率評価部８０と、テストカバレジ
レポート９１を出力するモジュール網羅率出力部９０
と、未試験モジュール遷移パスレポート１０１を出力す
るテストケース網羅率出力部１００とを備えている。さ
らにまた、デバッグなどで修正された修正ソースコード
６を複数のモジュールに分類する修正ソースコード解析
部１１０と、ソースコード１の修正によるテストケース
への影響を評価するソースコード変更影響評価部１２０
と、追加・変更されたモジュールを対象とするテストケ
ースを特定する再実行対象テストケース特定部１３０と
を備えている。また、ソースコード変更影響評価部１２
０には、削除されたモジュールおよび追加されたモジュ
ールを検出する第１の修正モジュール検出部１２１と、
修正されたモジュールを検出する第２の修正モジュール
検出部１２２とが設けられている。

【００２８】本実施例のソフトウェアテスト支援システ
ムの処理は、（１）テストケースを自動生成する処理
と、（２）テストの十分性を計測・評価する処理と、
（３）再テストを支援する処理とに分かれる。

【００２９】テストケースの自動生成処理は、ソースコ
ード解析部１０とテストケース作成部２０と、テストケ
ースレポート出力部３０が関係する。また、テストの十
分性計測・評価処理は、テストプローブ挿入部４０、ロ
ードモジュール作成部５０、テストカバレジ計測部６
０、モジュール網羅率評価部７０、テストケース網羅率
評価部８０、モジュール網羅率出力部９０およびテスト
ケース網羅率出力部１００が関係する。さらに、再テス
ト支援処理は、修正ソースコード解析部１１０、ソース
コード変更影響評価部１２０および再実行対象テストケ
ース特定部１３０が関係する。以下、各処理について説
明する。

【００３０】（１）テストケース自動生成処理 テストケースを自動生成するために、まずソースコード
解析部１０を実行してソースコードの解析を行う。ソー
スコード解析部１０は、テストの対象となるソフトウェ
アのソースコード１を解析し、その内部構造を明らかに
する役割を持つ。ここでソフトウェアの内部構造とは、
ソフトウェアを構成するタスク、モジュールの関連を意
味する。ソフトウェアがどのようなタスクから構成さ
れ、またどのようなモジュールによってタスクが構成さ
れ、それぞれのタスク、モジュールがどのような呼び合
い関係にあるかを明確にするものである。例えば、ソー
スコード１がＣ言語によって作成されている場合は、制
御構造（ｉｆ〜ｔｈｅｎ〜ｅｌｓｅ，ｗｈｉｌｅ，ｄｅ
〜ｗｈｉｌｅ，ｓｗｉｔｃｈ，ｇｏｔｏ，ｌａｂｅｌ，
ｂｒｅａｋ，ｃｏｎｔｉｎｕｅ，ｒｅｔｕｒｎ，ｆｏ
ｒ）などを解析して、構文規則に基づいてタスク、モジ
ュールの解析を行うのである。関連する文献には、特開
平１−２８３６３１公報などがある。

【００３１】図４は、ソースコード１の内部構造をソー
スコード解析部１０によって解析した例を示す図であ
る。この例では、ソースコード１はモジュールＡ，Ｂ
１，Ｂ２，Ｃ１，Ｃ２，Ｃ３，Ｄ１，Ｄ２から構成され
ており、例えば、モジュールＣ２はその下位モジュール
としてモジュールＤ１，Ｄ２を順次呼んでいることが判
る。また、モジュールＣ３はモジュールＢ１から呼ばれ
た場合には単独で処理を行い下位のモジュールを呼ばな
いが、モジュールＢ２から呼ばれた場合にはモジュール
Ｄ２をさらに呼んで処理を行うことが判る。従って、ソ
ースコード解析部１０により得られるモジュール呼び合
い関係は、モジュール内部の処理条件までを考慮した実
際の呼び合い関係に相当する。

【００３２】ソースコード解析部１０の解析によってソ
フトウェアの内部構造を明らかにした後にテストケース
作成部２０を実行して、ソフトウェアの内部構造をもと
にソフトウェアテストとして実施すべきテストケースを
作成する。テストケースは、ソフトウェアを構成するタ
スク、モジュールの呼び合い関係を考慮し、実際のソフ
トウェア操作で起こり得る呼び合い系列全てを網羅する
ように作成される。

【００３３】図５は、上記の考えに基づき、図４で示し
た内部構造を持つソフトウェアに関して、テストケース
を抽出したものである。同図に示すように、Ｃａｓｅ−
１からＣａｓｅ−９まで９通りのテストケースが抽出さ
れている。次に、テストケースの抽出についての具体例
として、例えば、画面処理を中心とするような事務処理
系のソフトウェアについて考える。この場合、個々のモ
ジュールはそれぞれの表示画面に対応する構造となる。
図６は画面処理を中心とした財務事務処理関係のソフト
ウェアの内部構造を示すモジュール関連図の一例であ
る。また、図７はこのソフトウェアの画面間の呼び合い
に基づいたソフトウェアの処理操作の関連を示したブロ
ック図である。例えば、このソフトウェアを実行した際
に表示される図７の「会計管理システム初期画面」は、
ソフトウェアの内部構造の観点からは図６に示す（会計
処理メイン）モジュールの処理が対応する。図７におい
て「会計管理システム初期画面」からは、「入力処理選
択機能」「日次処理選択機能」等の下位機能の選択が可
能であり、この「会計管理システム初期画面」からこれ
らの下位機能が呼ばれて実行されることが判る。これを
図６のソフトウェア内部構造の観点からみると、（会計
処理メイン）モジュールの下位にある（入力処理）、
（日次処理）等の各モジュールを呼び出す形で実現され
ていることが判る。

【００３４】この図６と図７を見ても明らかなように、
このようなソフトウェアに関しては、内部構造を示すモ
ジュール関連図は対象ソフトウェアの画面呼び合い関係
や処理操作の関連に深く関係している。

【００３５】従って、図６のモジュール関連図をもとに
生成された上記のような呼び合い関係の遷移系列を網羅
するテストケースは、対象ソフトウェアに関する処理操
作の系列を網羅するものとなる。

【００３６】図８（ａ）は、図６に基づいて生成された
テストケースの一例であり、一方、図８（ｂ）は図７か
ら想定される対象ソフトウェアの処理操作の流れを示し
たものである。図８（ａ）で生成されたテストケース
（Ｃａｓｅ−２）では、モジュール呼び合い関係から、
（総合管理メイン）モジュールから（会計管理メイン）
モジューメを呼び、更に、（入力処理）（日次処理）
（月次処理）（マスタメンテナンス）（決算処理）の各
モジュールを順次呼ぶモジュール遷移系列がテストケー
スとして生成されている。これに対し、図８（ｂ）で対
象ソフトウェアの処理操作を考えると、（総合管理シス
テム初期画面）から（会計管理システム初期画面）を選
択し、更に下位の（入力処理機能選択画面）（日次処理
選択画面）（月次処理選択画面）（マスタメンテナンス
処理選択画面）（決算処理選択画面）を逐次起動操作す
る流れがあることが判る。この処理操作の流れは、図８
（ａ）のＣａｓｅ−２で生成されたテストケースでのモ
ジュール遷移に対応している。

【００３７】このようにモジュール呼び合い関係の遷移
系列から作成されるテストケースは、対象ソフトウェア
に関する処理操作の系列を網羅している。なお、このモ
ジュール関連図は、ソースコード解析部１０の実行によ
って得られる。

【００３８】このようにして作成されたテストケース
は、テストケースファイル２として保持される。このテ
ストケースファイル２は、テスト実施後にここで作成さ
れたテストケースについてどのケースがテストされ、あ
るいはテストされなかったかの判定を行うための参考情
報として利用される。また、１度目のテストで不具合が
発生し、バグ修正を施したソフトウェアに対して再テス
トを行う場合にも、このテストケースファイル２に保持
されたテストケースのうち有効なものが再利用される。

【００３９】さらに、作成されたテストケースはテスト
ケースレポート出力部３０により、テストケース・レポ
ート３１として通常のプリンターから帳票形式で出力さ
れる。テストケース・レポート３１は、ソフトウェアテ
ストを実施する際の参考となる。図９は、帳票形式で出
力されたテストケース・レポート３１の例を示す図であ
る。

【００４０】次に、モジュール関連図からのテストケー
ス生成の手順を図１０のフローチャートを用いて説明す
る。例えば、図４のモジュール関連図からテストケース
を作成することを考えた場合、まず、テストケース作成
の起点モジュールとして、モジュール関連図の最上位の
モジュールであるモジュールＡが選択される（ステップ
２０１）。次に、モジュール関連図により、この起点モ
ジュールから呼ばれる下位モジュールが特定される（ス
テップ２０２）。図４の例では、モジュールＡの下位モ
ジュールとして、モジュールＢ１，Ｂ２の２つのモジュ
ールが特定される。

【００４１】次に、このようにして特定された下位モジ
ュールの呼出形式が確認される（ステップ２０３）。呼
出形式とは、上位モジュールから下位モジュールが呼び
出される方式をいう。下位モジュールの呼び出され方に
は、無条件に呼び出される場合と、条件に合ったときに
呼び出される場合の２通りがある。例えば、図４の例で
は、起点モジュールであるモジュールＡの内部処理とし
て、 ・下位のモジュールＢ１，Ｂ２が順番に呼び出される場
合と ・内部条件処理によって、下位のモジュールＢ１のみが
呼び出される場合と ・同様に、下位のモジュールＢ２のみが呼び出される場
合と が考えられる。これらの下位モジュールの呼出形式の特
定は、起点モジュールの内部処理手順を解析することに
よって行われる。

【００４２】上記の操作によって、図１１（ａ）に示す
ような起点モジュールを始点としたテストケース１次ツ
リーが作成される（ステップ２０４）。テストケース１
次ツリーが作成された後に、現在対象としている起点モ
ジュールより下位に呼出モジュールが存在するかどうか
の判定を行う（ステップ２０５）。次に、起点モジュー
ルを１つ下位のモジュールに移動する。即ち、図４の例
では、起点モジュールとしてモジュールＢ１が選択され
る（ステップ２０６）。

【００４３】その後、同様に選択されたテストケース作
成の起点モジュールに対して、下位モジュールの特定と
呼出形式が特定され、この起点モジュールに関するテス
トレース１次ツリーが作成される（ステップ２０４）。
同様に、起点モジュールを順次下位に移動させることに
よって、各モジュールを起点とするテストケース１次ツ
リーが作成される（ステップ２０４）。図１１（ｂ）は
図４に示したモジュール関連図をもとに作成された各モ
ジュールに関するテストケース１次ツリーの例である。
このようにして作成された各モジュールのテストケース
１次ツリーを融合して、網羅的にテストケースの作成が
行われる（ステップ２０７）。

【００４４】図１２（ｃ）は、図１１（ｂ）の各モジュ
ールをテストケース１次ツリーを融合して作成したテス
トケースの一例である。テストケース１次ツリーの融合
では、ツリー上の同一ノードに着目して融合を進める。
例えば、図１２（ｃ）に示したＣａｓｅ−１を融合生成
するためには、以下の４つのテストケース１次ツリーに
着目する。

【００４５】・まずテストケース１次ツリー〈ａ〉の終
端のモジュールＢ１に着目する。 ・次にモジュールＢ１を始点とするテストケース１次ツ
リーを検索し、該当する１次ツリーとして〈ｂ１〉を得
る。

【００４６】・テストケース１次ツリー〈ｂ１〉の終端
モジュールＣ１に着目する。

【００４７】・次にモジュールＣ１を始点とするテスト
ケース１次ツリーを検索し、該当する１次ツリー〈ｂ
２〉を得る。

【００４８】・テストケース１次ツリー〈ｂ２〉の終端
モジュールＤ２に着目する。

【００４９】・次にモジュールＤ２を始点とするテスト
ケース１次ツリーを検索し、該当する１次ツリー〈ｂ
３〉を得る。

【００５０】・テストケース１次ツリー〈ｂ３〉の終端
は、（Ｅ）として下位モジュールがないことが分かるた
め、ここでテストケース１次ツリーの探索・融合は完了
する。

【００５１】このようにして、テストケース１次ツリー
の終端モジュールをキーに順次、探索・融合が進められ
る。上記の結果から以下に示すように、Ｃａｓｅ−１に
示した一連のテストケースが融合獲得される。

【００５２】 〈ａ〉 モジュールＡ→モジュールＢ１ 〈ｂ１〉 モジュールＢ１→モジュールＣ１ 〈ｂ２〉 モジュールＣ１→モジュールＤ２ 〈ｂ３〉 モジュールＤ２→Ｅ Ｃａｓｅ−１ モジュールＡ→モジュールＢ１→モジュールＣ１→モジ
ュールＤ２ （２）テストの十分性計測・評価処理 テスト実施時のテスト十分性を計測するために、対象ソ
フトウェアにカバレジ計測用プローブを挿入する。この
手順を、図１３のフローチャートを用いて説明する。

【００５３】テストプローブ挿入については、まず、ソ
ースコード解析部１０によって分類された構成モジュー
ルの全てに番号付けを行う（ステップ３０１）。図１４
は図５に示したソフトウェアを構成するモジュールに関
して各モジュールの番号付けを行った一例であり、各モ
ジュール名と付けられた番号の対応テーブルの生成が行
われる。

【００５４】対象となるソースコードを構成するタス
ク、モジュールの先頭部にそれぞれのタスク、モジュー
ルの通過チェックを行うためのカウンタ（テストプロー
ブ）が挿入される（ステップ３０２）。このカウンタ
（テストプローブ）は、図１５に示すように、モジュー
ル通過管理ファイル４に当該タスク、モジュールの番号
を書き込む命令（Ｆｉｌｅ Ｗｒｉｔｅ命令）を組み合
わせたものである。

【００５５】このカウンタ（テストプローブ）は、当該
タスク、モジュールが実行された場合に、その当該タス
ク、モジュール番号の値をモジュール通過管理ファイル
４に書き込む役割を持つ。例えば、図５に示したソフト
ウェアにおいて、モジュールＣ３はモジュール番号“０
６”が割り付けられており、この場合、ソースコードの
モジュールＣ３の先頭部分に図１５に示すようなテスト
プローブが自動的に挿入される。

【００５６】このカウンタ（テストプローブ）は、当該
タスク、モジュールが実行された場合に、その当該タス
ク、モジュール番号の値をモジュール通過管理ファイル
４に書き込む役割を持つ。例えば、図５に示したソフト
ウェアにおいて、モジュールＣ３はモジュール番号“０
６”が割り付けられており、この場合、ソースコードの
モジュールＣ３の先頭部分に図１５に示すようなテスト
プローブが自動的に挿入される。

【００５７】このテストプローブが埋め込まれたソース
コードをコンパイル・リンクすることにより、テストカ
バレジの計測、テストの十分性の評価が可能となる（ス
テップ３０３）。

【００５８】テストカバレジは、上記のテストプローブ
を挿入したソフトウェアを実行することにより計測され
る。テストカバレジ計測部６０は、テスト実施時にテス
ト対象となるソフトウェアのモジュール通過管理ファイ
ル４をセットする。このテストカバレジ計測部６０の処
理手順を図１６のフローチャートを用いて説明する。

【００５９】テストカバレジ計測部６０では、テスト起
動されるソフトウェアの起動回数が常に監視されている
（ステップ４０１）。そして、そのソフトウェアの起動
が始めてかどうかの判定が行われる（ステップ４０
２）。以前に起動されていないソフトウェアが始めて起
動された場合には、テストカバレジ計測部６０では、モ
ジュール通過管理ファイル４が書き込み可能な状態で自
動作成される（ステップ４０３）。また、すでに過去に
起動されたことのあるソフトウェアである場合には、該
当するモジュール通過管理ファイル４が書き込み可能な
状態でオープンされる（ステップ４０４）。

【００６０】このようにモジュール通過管理ファイル４
がオープンされた状態で、対象ソフトウェアが実際に起
動され、モジュール通過時のテストプローブからのモジ
ュール通過情報の書き込みが行われる（ステップ４０
５）。このモジュール通過管理ファイル４は、上記のテ
ストプローブを挿入したソフトウェアの最初の起動時に
セットされ、そのソフトウェアが変更されない限りモジ
ュールの通過履歴が記録され続ける。

【００６１】モジュール通過管理ファイル４のファイル
内容の例を図１７に示す。このファイルには、テスト実
施日時及び実施時のタスク／モジュール・パスが記録さ
れている。図１７に示すように、モジュール通過管理フ
ァイル４は、対象ロードモジュール指定部１８及びテス
ト通過モジュール記録部１９から構成される。対象ロー
ドモジュール指定部１８には、テスト対象となるソフト
ウェアのロードモジュールの名称、作成日時等が記録さ
れる。また、テスト通過モジュール記録部１９には指定
されたロードモジュールがテスト実行された日時、及
び、その際にテストプローブに基づきカウントされた通
過したタスク／モジュール番号が記録される。

【００６２】図１７の例では、テスト対象ロードモジュ
ールは“ＥＳＱ−ＳＹＳ．ＥＸＥ”、作成日時は“９３
−６−３ １５：１９”であり、試験実施日が“９３−
６−５ １０：１４”のテストでは、モジュール番号
“０１，０４，０９，０２，０１”という系列がテスト
されたことが記録されている。

【００６３】テストカバレジ計測部６０の実行によっ
て、モジュール通過管理ファイル４にモジュールの通過
履歴が記録されると、次に、モジュール網羅率評価部７
０とテストケース網羅率評価部８０が実行され、テスト
の十分性の評価が行われる。

【００６４】まず、モジュール網羅率評価部７０では、
図１４に示した構成モジュールリストに記録されたモジ
ュールと、図１７に示したモジュール通過管理ファイル
４に記録されたテスト実施モジュール番号との照合が行
われ、対象ソフトウェアを構成するモジュールの内、何
パーセントを通過したかが評価される。また、同時にテ
スト時に通過していないモジュールが特定され、リスト
（未試験モジュールリスト）が作成される。図１４，図
１７の事例では、モジュールＣ３，Ｃ５，Ｄ４は未通過
であることが判る。

【００６５】次に、テストケース網羅率評価部８０で
は、図５に示したテストケースと図１７に示したモジュ
ール通過管理ファイル４に記録されたテスト実施モジュ
ール番号が照合され、考えられるテストパスの内、何パ
ーセントがテストされたかが評価される。同時に、テス
ト未実施のテストパスが特定され、リスト（未試験モジ
ュール遷移パスリスト）が作成される。図５，図１７の
事例では、図５に示したテストケースのうち、Ｃａｓｅ
−４，５，７，８，９のパスがテストされていないこと
が分かる。

【００６６】上記のような２つの観点からテストの十分
性の評価が行われ、評価結果はテスト結果評価ファイル
５に記憶されると共に、テストカバレジレポート９１お
よび未試験モジュール遷移パスレポート１０１として、
本システムの利用者に提供される。

【００６７】テストカバレジレポート９１について、図
１８，図１９にその事例を示す。

【００６８】図１８はテストカバレジレポート９１の一
つである「モジュール網羅率評価レポート」の一例であ
り、対象ソフトウェアを構成するモジュール数およびテ
スト時に実行されたモジュール数からテストにおけるモ
ジュール網羅率が算出・表記されている。また、図１９
は「モジュール遷移パス網羅率評価レポート」の一例で
あり、対象ソフトウェアを構成するモジュール間で可能
な遷移系列数に対して実際のテストされた遷移系列の数
が示され、これによりモジュール遷移系列のテスト網羅
度が算出・表記される。

【００６９】未試験モジュール遷移パスレポート１０１
については、図２０，図２１にその事例を示す。図２０
は「未試験モジュールレポート」の一例であり、テスト
実行時に通過していないモジュール名称がリストアップ
されている。また、図２１は「未試験モジュール遷移パ
スレポート」の一例である。このレポートは、ソフトウ
ェアを構成するモジュール間で可能なモジュール間の遷
移系列のうち、実際のテストで確認されていないパス
が、モジュール名の系列としてリストアップされてい
る。

【００７０】なお、本支援システムにおけるテストの十
分性評価は、対象ソフトウェアを複数回実行した場合の
総計を用いて行われる。

【００７１】（３）再テスト支援処理 通常、ソフトウェアの開発においては、テスト段階で発
見されたバグを修正して、再度テストを行う。また、バ
ージョンアップの際には機能追加や機能変更によってソ
ースコードの修正が行われ、再度のテストが必要とな
る。このような場合、修正されたソースコードのどの部
分をテストする必要があるかを特定し、これに対応した
テストケースを作成、テストすることが問題となる。

【００７２】本システムでは、これらの再テストに対す
るテストケース作成についても支援を行う。

【００７３】ソースコード変更影響評価部１２０は、通
常の１回目のテストを実施したソースコードと、テスト
結果を反映させて修正したソースコードとの比較を行う
役割を持つ。ソースコード変更影響評価部１２０には、
削除されたモジュールおよび追加されたモジュールを検
出する第１の修正モジュール検出部１２１と、修正され
たモジュールを検出する第２の修正モジュール検出部１
２２とが設けられている。

【００７４】第１の修正モジュール検出部１２１では、
変更後のソースコードに対してソースコード構成解析が
行われ、図４に示すようなソフトウェア内部構造が明瞭
にされ、先に解析されている変更前のソフトウェア内部
構造との対比が行われる。これにより、どのモジュール
が削除・追加され、また、どのモジュール間の呼び合い
関係が変更を受けたかが特定できる。

【００７５】また、第２の修正モジュール検出部１２２
では、変更前のソースコードと変更後のソースコードそ
れぞれについて、各構成モジュールのステップ数、条件
文数、ループ数等の比較が行われ、これらが変わってい
る場合には、変更・修正を行ったモジュールとして特定
できる。

【００７６】図２２は、第１の修正モジュール検出部１
２１での処理事例を示したものである。変更前のソフト
ウェアではモジュールＢ１がモジュールＣ１，Ｃ２，Ｃ
３を呼んでおり、また、モジュールＣ２はモジュールＤ
１，Ｄ２を呼んでいた。これに対して、変更後のソフト
ウェアではモジュールＢ１，Ｃ１，Ｃ２のみを呼び、ま
た、モジュールＣ２はモジュールＤ１，Ｅ１を呼んでお
り、呼び合い関係が変更されていることが判る。

【００７７】図２３は、第２の修正モジュール検出部１
２２での処理事例を示したものである。変更前と変更後
のソフトウェアでは、モジュールＢ１，Ｃ２，Ｄ１，Ｅ
１の内部構造が変更されていることが判る。

【００７８】修正・変更を受けたソースコードの変更点
を特定した後、テストケース変更影響評価部１２０によ
って変更前に生成されたテストケースの中で、これらの
ソースコード変更の影響を受けると考えられるテストケ
ースを特定する。第１の修正モジュール検出部１２１で
検出された追加モジュールと、第２の修正モジュール検
出部１２２で検出された修正モジュールは、全て再テス
トの対象となる。

【００７９】図２２，図２３に示したソースコード変更
影響評価について考えると、変更前に生成されたテスト
ケースのうち、次のものについてはソースコード変更の
影響を受けていると判定される。

【００８０】 Ｃａｓｅ−１：Ａ−Ｂ１−Ｃ１−Ｃ２−Ｃ３ Ｃａｓｅ−２：Ａ−Ｂ１−Ｃ２−Ｄ１−Ｄ２ 逆に、次のＣａｓｅ−３はソースコードの変更の影響を
受けていないと考えられるため、再テストの必要は少な
いと判定される。

【００８１】 Ｃａｓｅ−３：Ａ−Ｂ２−Ｃ３−Ｄ２ 再実行対象テストケース特定部１３０では、変更前のソ
ースコードに対して作成されたテストケースについて、
ソースコード変更の影響が及んでいるかどうかを特定す
る働きを持つ。再実行対象テストケース特定部１３０で
特定されたテストケースの情報はテストケース作成部２
０に与えられる。そして、テストケース作成部２０で
は、この情報に基づいて、再度、変更されたソースコー
ド６のテストケースが作成される。

【００８２】例えば、先に示した図２２，図２３の例で
は、上記のＣａｓｅ−１，２のテストケースが再テスト
の対象となり、一方、Ｃａｓｅ−３はソースコード変更
の影響を受けていないと判定されるため、再テストのテ
ストケースからは除外される。

【００８３】このようにして変更されたソースコードに
対して再度テストを行った場合に、変更されたソフトウ
ェアに対するテストの十分性（網羅率）や未実行パス、
未実行モジュールが特定される。この場合、テスト十分
性評価については、修正変更の影響を受けないモジュー
ルやモジュール遷移パスも含めて、どの程度をテストし
たかが判定されるものである。また、未実行モジュー
ル、未実行モジュールパスについても、変更の影響を受
けないモジュール、モジュール遷移パスも含めて指摘の
対象となる。

【００８４】

【発明の効果】以上説明したように、本発明のソフトウ
ェアテスト支援システムによれば、効率的なソフトウェ
アテストを容易に行うことができる。つまり、通常の開
発言語によって作成されたソフトウェアに関して、その
テストのためのテストケースを自動的に抽出することが
可能となる。このレベルで生成されるテストケースは、
対象ソフトウェアのソフトウェア・システムテストの際
の参考として利用でき、これにより効率的に抜けのない
テスト仕様書を作成できるようになる。

【００８５】また、テストの十分性を計測するテストプ
ローブを対象のソフトウェアのソースコードに挿入する
ことにより、テスト実行時に対象ソフトウェアを構成す
るモジュールをどの程度テストしたかを評価する「モジ
ュール網羅率」および各モジュール間の関連を考慮して
実行可能なモジュールの遷移系列をどの程度テストした
かを評価する「モジュール遷移パス系列網羅率」の評価
が可能となる。また、これらの評価結果をレポートとし
て確認することが可能となる。これにより、対象ソフト
ウェアのテスト実施時に、具体的にどのモジュールある
いはどのモジュール遷移パスがテストされていないかが
明確になり、効率的なテスト実施及び評価が可能とな
る。このモジュール網羅率、モジュール遷移パス網羅
率、未試験モジュールの特定、未試験モジュールパス特
定によって、より確実なソフトウェア・システム試験が
可能となる。

【００８６】さらに、ソースコードからのテストケース
生成及びテスト実施時の十分性評価により、ソフトウェ
アのテストの効率的実施が容易となる。また、これによ
ってテストの抜けや片寄りが防止され、ソフトウェアの
効果的なテストが可能となり、品質、生産性の向上が図
れる。

【図面の簡単な説明】

【図１】本実施例に係るソフトウェア支援システムの構
成を示すブロック図である。

【図２】本実施例に係るソフトウェア支援システムの構
成を示すブロック図である。

【図３】本実施例に係るソフトウェア支援システムの構
成を示すブロック図である。

【図４】ソフトウェアテストを実施する対象となるソフ
トウェアのモジュール構成を示す図である。

【図５】抽出されたテストケースの例を示す図である。

【図６】画面処理を中心とした財務事務処理関係のソフ
トウェア内部構造を示すモジュール関連図である。

【図７】画面処理を中心とした財務事務処理関係のソフ
トウェアの処理操作の関連を示したブロック図である。

【図８】生成されたテストケースと処理操作の流れの一
例を示す図である。

【図９】本装置により出力されるテストケース・レポー
トの例を示す図である。

【図１０】テストケース生成の手順を示すフローチャー
トである。

【図１１】テストケース生成のためのテストケースツリ
ーを示す図である。

【図１２】テストケース生成のためのテストケースツリ
ーを示す図である。

【図１３】テストプローブ挿入手順を示すフローチャー
トである。

【図１４】各モジュールの番号付けを行った一例を示す
図である。

【図１５】テストプローブが挿入されたソースコードの
例を示す図である。

【図１６】テストカバレジ計測部の処理手順を示すフロ
ーチャートである。

【図１７】モジュール通過管理ファイルのファイル内容
の例を示す図である。

【図１８】テストカバレジレポートのうち、「モジュー
ル網羅率」評価結果レポートの一例を示す図である。

【図１９】テストカバレジレポートのうち、「モジュー
ル遷移パス系列網羅率」評価結果レポートの一例を示す
図である。

【図２０】「未試験モジュールレポート」の一例を示す
図である。

【図２１】「未試験モジュールパスレポート」の一例を
示す図である。

【図２２】再テスト時のソースコード変更影響評価部に
よるソフトウェア構成評価の一例を示す図である。

【図２３】再テスト時のソースコード変更影響評価によ
る構成モジュール内部評価の一例を示す図である。

【符号の説明】

１…ソースコード ２…テストケースファイル ３…ロードモジュール ４…モジュール通過管理ファイル ５…テスト結果評価ファイル ６…修正ソースコード １０…ソースコード解析部 ２０…テストケース作成部 ３０…テストケースレポート出力部 ３１…テストケースレポート ４０…テストプローブ挿入部 ５０…ロードモジュール作成部 ６０…テストカバレジ計測部 ７０…モジュール網羅率評価部 ８０…テストケース網羅率評価部 ９０…モジュール網羅率出力部 ９１…テストカバレジレポート １００…テストケース網羅率出力部 １０１…未試験モジュール遷移パスレポート １１０…修正ソースコード解析部 １２０…ソースコード変更影響評価部 １２１…第１の修正モジュール検出部 １２２…第２の修正モジュール検出部 １３０…再実行対象テストケース特定部。

Claims (8)

【特許請求の範囲】
1. 【請求項１】 構造化プログラミング手法によって作成
   されたソースコードを解析してソフトウェアのテストの
   支援を行うソフトウェアテスト支援システムにおいて、 ソースコードを複数の単位ルーチンに分類し、各単位ル
   ーチンの呼び出し関係を解析するソースコード解析手段
   と、 前記ソースコード解析手段で解析された各単位ルーチン
   の呼び出し関係に基づいて、全ての呼び出しパターンを
   網羅する複数のテストケースを作成するテストケース作
   成手段とを備えることを特徴とするソフトウェアテスト
   支援システム。
2. 【請求項２】 前記テストケース作成手段で作成された
   複数のテストケースの一覧を帳票形式で出力するテスト
   ケースレポート出力手段とを備えることを特徴とする請
   求項１記載のソフトウェアテスト支援システム。
3. 【請求項３】 前記ソースコードの各単位ルーチンにテ
   ストプローブを挿入するテストプローブ挿入手段と、 前記テストプローブ挿入手段によってテストプローブが
   挿入された前記ソースコードをコンパイル・リンクして
   ロードモジュールを作成するロードモジュール作成手段
   と、 前記テストケース作成手段で作成された各テストケース
   に基づいて、前記ロードモジュール作成手段で作成した
   ロードモジュールを実行するテスト実行手段とを備え、 前記テストプローブは、少なくとも所定の履歴ファイル
   をオープンする命令と、この履歴ファイルに挿入対象の
   単位ルーチンを特定する番号を書き込む命令とを含んだ
   命令群であることを特徴とする請求項１または請求項２
   に記載のソフトウェアテスト支援システム。
4. 【請求項４】 前記テスト実行手段でのロードモジュー
   ルの実行によって書き込まれた前記履歴ファイルを分析
   して、前記ソースコードの全単位ルーチンの中の何パー
   セントの単位ルーチンがこの履歴ファイルに書き込まれ
   ているか検出すると共に、未実行のモジュールを検出す
   るモジュール網羅率評価手段を備えることを特徴とする
   請求項３記載のソフトウェアテスト支援システム。
5. 【請求項５】 前記モジュール網羅率評価手段で検出さ
   れたモジュール網羅率および未実行モジュールの一覧を
   帳票形式で出力するモジュール網羅率出力手段とを備え
   ることを特徴とする請求項４記載のソフトウェアテスト
   支援システム。
6. 【請求項６】 前記テスト実行手段でのロードモジュー
   ルの実行によって書き込まれた前記履歴ファイルを分析
   して、前記テストケース作成手段で作成された全テスト
   ケースの中の何パーセントのテストケースがこの履歴フ
   ァイルに書き込まれているか検出すると共に、未実行の
   テストケースを検出するテストケース網羅率評価手段を
   備えることを特徴とする請求項３記載のソフトウェアテ
   スト支援システム。
7. 【請求項７】 前記テストケース網羅率評価手段で検出
   されたテストケース網羅率および未実行テストケースの
   一覧を帳票形式で出力するテストケース網羅率出力手段
   とを備えることを特徴とする請求項６記載のソフトウェ
   アテスト支援システム。
8. 【請求項８】 バグ修正またはバージョンアップによる
   修正が行われたソースコードを複数の単位ルーチンに分
   類する修正ソースコード解析手段と、 前記ソースコード解析手段で分類された単位ルーチンと
   前記修正ソースコード解析で分類された単位ルーチンと
   を比較して、削除された単位ルーチンおよび追加された
   単位ルーチンを検出する第１の修正単位ルーチン検出手
   段と、 修正前後の前記ソースコードを比較して、前記修正ソー
   スコード解析で分類された単位ルーチンの中で修正され
   た単位ルーチンを検出する第２の修正単位ルーチン検出
   手段と、 前記テストケース作成手段で作成されたテストケースの
   内、前記第１の修正単位ルーチン検出手段で検出された
   追加単位ルーチンを対象とするテストケースと前記第２
   の修正単位ルーチン検出手段で検出された修正単位ルー
   チンを対象とするテストケースとを特定する再実行対象
   テストケース特定手段とを備えることを特徴とする請求
   項１から請求項７までのいずれかに記載のソフトウェア
   テスト支援システム。