(57)【要約】【課題】ソースコードが変更されたソフトウェアに対して、不具合防止のための回帰テストを効率的に実施することができるソフトウェアテストシステムを提供する。【解決手段】制御フローを規定するソースコードの構造を解析して変数間の依存関係を求める依存関係解析手段と、前記変更前後のソースコードから変更箇所を求める変更箇所抽出手段と、前記ソースコードが変更された制御フローに対して前記変更箇所を含むようにテストの実行範囲を決定する実行範囲決定手段と、前記変更箇所に含まれる変数と依存関係を有する変数の中から前記テストの入力変数を決める入力変数決定手段と、前記テストの網羅範囲の基準を設定するテスト基準設定手段と、前記実行範囲と前記入力変数と前記テスト基準に基づいて前記テストケースを生成するテストケース生成手段と、前記テストケースを出力するテストケース出力手段と、を有することを特徴とする。【選択図】図１
2015069400.tif 000002
【特許請求の範囲】
【請求項１】
制御フローを規定するソースコードの構造を解析して変数間の依存関係を求める依存関係解析手段と、
前記変更前後のソースコードから変更箇所を求める変更箇所抽出手段と、
前記ソースコードが変更された制御フローに対して前記変更箇所を含むようにテストの実行範囲を決定する実行範囲決定手段と、
前記変更箇所に含まれる変数と依存関係を有する変数の中から前記テストの入力変数を決める入力変数決定手段と、
前記テストの網羅範囲の基準を設定するテスト基準設定手段と、
前記実行範囲と前記入力変数と前記テスト基準に基づいて前記テストケースを生成するテストケース生成手段と、前記テストケースを出力するテストケース出力手段と、を有することを特徴とする、ソフトウェアテストシステム。
【請求項２】
請求項１のソフトウェアテストシステムにおいて、
前記実行範囲決定手段は、前記ソースコードにおける実行開始点の候補を実行開始点データとして有し、
前記変更箇所を含む制御フローから前記実行開始点データに含まれる実行開始点を探索して前記実行範囲を決定することを特徴とする、ソフトウェアテストシステム。
【請求項３】
請求項１のソフトウェアテストシステムにおいて、
前記入力変数決定手段は、前記ソースコードにおける入力変数の候補を入力変数データとして有し、
前記変更箇所に含まれる変数と依存関係を有する変数から前記入力変数データに含まれる変数を探索することで前記入力変数を決定することを特徴とする、ソフトウェアテストシステム。
【請求項４】
請求項３のソフトウェアテストシステムにおいて、
前記実行範囲決定手段は、前記入力変数が前記制御フロー上に出現するように前記実行範囲を決定することを特徴とする、ソフトウェアテストシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェアのテストを行うシステムに係り、特にテスト用データを生成する技術に関する。
【背景技術】
【０００２】
ソフトウェア開発では、仕様変更やそれに伴う実装（ソースコード）の変更時に、回帰テストが行われる。回帰テストは、変更前のソフトウェアに対して実施したテストケースを用いて再度検査し、仕様または実装変更により機能が損なわれていないかを確認するものである。ここでテストケースとは、入力値、実行事前条件、期待結果、実行事後条件の組からなるテスト用データ、またそのデータを用いて実施するテスト１件のことである。また「テストケース」は、入力値のみなど、上記データセットの一部を指して用いられる場合もある。この場合、期待結果などは未記述のテストケースと見ることができる。本明細書でもこちらの意味で「テストケース」を用いる場合がある。
【０００３】
限られた時間の中で回帰テストを効率的に行うには、全てのテストケースを実施するのではなく、ソフトウェアの変更点に関係するテストケースに限定して実施することが望ましい。これを実現しようとする公知技術として、特許文献１では、ソフトウェアの変更点を実行パスに含むテストケースのみを既存テストケースから抽出する。特許文献２では、ソフトウェアの変更によるソースコード上の影響範囲を解析し、外部から与えられるテストケースの実施必要性を、そのテストケースが影響範囲に関与するかを見て判定する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−００３９８５号公報
【特許文献２】特開２０１０−０６７１８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ソフトウェアの変更内容によっては、既存のテストケースだけでは不十分であり、新規にテストケースを作成する必要がある。特許文献１・２はこの点に対応していない。
【０００６】
新規のテストケースを自動的に作成する技術としては、ソースコードを解析してテストケースを生成する手法がある。テストケースが所定のテストカバレッジ基準（Ｃ０，Ｃ１など）を満たすように生成する方法もある。ソフトウェアの仕様変更前に適用したテストケース生成方法のカバレッジ基準をＣｂ、仕様変更後に適用したテストケース生成方法のカバレッジ基準をＣａとすると、Ｃｂ≦Ｃａであれば、仕様変更後のテストは、カバレッジ基準Ｃｂで回帰テストを実施したことと同等であると言える。また、直行表やＰａｉｒｗｉｓｅ法を用いて網羅性をもった入力値の決定を行うテストケース生成手法（入力値決定方法）があるが、このような手法を仕様変更前後に適用していれば、仕様変更後のテストは回帰テストを実施したことと同等であると言える。以上のことから、テストケース生成技術は、回帰テストにも対応していると言える。
【０００７】
テストケースを生成する他の方法の一つとして、モデル検査を応用したテストケース生成がある。これは、あらゆる入力条件や実行タイミングを考慮して網羅的なテストケースを生成するため、極めて高いカバレッジのテストケースを得ることができる。
【０００８】
ただし、テストケース生成の課題として、求めるカバレッジの基準が高くなるほど、生成されるテストケース数が多くなり、テスト実施に掛かる工数が増大する点が挙げられる。例えば、モデル検査を用いたテストケース生成を、ソフトウェア全体に適用することは現実的に困難である。
【０００９】
そこで、本発明は、ソースコードが変更されたソフトウェアに対して、不具合防止のための回帰テストを効率的に実施することができるソフトウェアテストシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため本発明は、制御フローを規定するソースコードの構造を解析して変数間の依存関係を求める依存関係解析手段と、前記変更前後のソースコードから変更箇所を求める変更箇所抽出手段と、前記ソースコードが変更された制御フローに対して前記変更箇所を含むようにテストの実行範囲を決定する実行範囲決定手段と、前記変更箇所に含まれる変数と依存関係を有する変数の中から前記テストの入力変数を決める入力変数決定手段と、前記テストの網羅範囲の基準を設定するテスト基準設定手段と、前記実行範囲と前記入力変数と前記テスト基準に基づいて前記テストケースを生成するテストケース生成手段と、前記テストケースを出力するテストケース出力手段と、を有することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、ソフトウェアのソースコードが変更されたソフトウェアに対して、不具合防止のための回帰テストを効率的に実施することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明に係るソフトウェアテストシステムの実施例１の機能構成図。
【図２】実施例１のシステム構成図。
【図３】実施例１のテストケース生成の処理フロー。
【図４】実施例１において用いられるサンプルソースコード。
【図５】実施例１において用いられるサンプルソースコードのプログラム依存グラフ。
【図６】実施例１において生成されたテストケースの例。
【図７】実施例２において用いられるサンプルソースコード。
【図８】実施例２において生成されたテストケースの例。
【図９】実施例３において用いられる実行開始点テーブル。
【図１０】実施例４において用いられる入力変数テーブル。
【図１１】実施例４において用いられる入力変数テーブル。
【図１２】実施例５において生成されたテストケースの例。
【発明を実施するための形態】
【００１３】
以下、本発明の実施形態について説明を行う。
【実施例１】
【００１４】
図１は、本発明の実施例１に係るソフトウェアテストシステム２０を実現する基本的な機能構成図であり、本明細書における全ての実施例で共通である。このソフトウェアテストシステム２０はソフトウェアツールとして実現されている。各機能はソフトウェアとして実装されており、表示画面、主演算装置、主記憶装置（メインメモリ）、ハードディスク等の記憶媒体、キーボードやポインティングデバイス等の入力装置を備えるコンピュータ上で実行される。
【００１５】
ソースファイル入力部１０は、テスト対象とするソフトウェアの変更前後のソースコードファイルをコンピュータの記憶媒体から読み込む。ソースコードは変更前後それぞれで「プロジェクト」などとしてグループ化されている。
【００１６】
構文解析部１１は、ソースファイル入力部１０から入力されたソースコードファイルの構文を解析し、構文木（Ａｂｓｔｒａｃｔ  Ｓｙｎｔａｘ  Ｔｒｅｅ）データを生成する。なお、本明細書の実施例では、Ｃ言語で記述されているソースコードを扱う。
【００１７】
依存関係解析部１２は、構文解析１１による構文木データから、テスト対象とするソースコードにおける制御フローと依存関係のデータを解析し生成する。具体的には双方のデータを含むプログラム依存グラフ（ＰＤＧ；  Ｐｒｏｇｒａｍ  Ｄｅｐｅｎｄｅｎｃｅ  Ｇｒａｐｈ）を解析する。
【００１８】
変更箇所抽出部１３は、ソースファイル入力部１０から入力されたソースコードファイルの変更前後における差分（即ち、変更箇所）を抽出する。
【００１９】
変更箇所依存関係抽出部１４は、依存関係解析部１２が解析した制御フローから、変更箇所を通過する制御フローを抽出する。また、依存関係解析部１２が解析した依存関係上にて、変更箇所抽出部１３が発見した変更箇所に該当する部分を特定し、さらにその部分から依存関係がつながる部分を求めて、変更箇所に関係する依存関係として抽出する。
【００２０】
実行範囲決定部１５は、変更箇所依存関係抽出部１４が抽出した変更箇所に関係する制御フローから、テストケースの実行範囲、すなわちソースコードにおけるテストの実行開始点と実行終了点を決定する。
【００２１】
入力変数決定部１６は、変更箇所依存関係抽出部１４が抽出した変更箇所に関係する依存関係から、テストケースの実行範囲に対して入力となる変数を決める。
【００２２】
テストケース生成部１７は、テスト基準設定部１８に設定されたテストのテストの網羅範囲の基準（即ち、カバレッジ基準）と、実行範囲決定部１５が決めたテストケースの実行範囲と、入力変数決定部１６が決めた入力変数とから、テストケースのデータを生成する。
【００２３】
テストケース出力部１９は、テストケース生成部１７によるテストケースのデータを、ファイルや画面表示として出力する。
【００２４】
図２は、本ソフトウェアテストシステム２０を実現した場合のシステム構成である。図１で説明したソフトウェアは、テストケース生成プログラム２１３１として、例えばコンピュータ２１上のＲＯＭ２１３に格納されており、ＣＰＵ２１１によって読み出され、ＲＡＭ２１２を一時記憶領域として実行される。コンピュータ２１はテストケース生成プログラム２１３１によって規定された処理、すなわち図１で説明した各部の処理を実行する。テスト対象とするソースコードファイルは、コンピュータ２１上のハードディスク２１４に格納されている。解析実行指示などのユーザ操作は、キーボードなどの入力装置２２から行うことができる。
【００２５】
なお、テストケース出力部１９による出力は、例えばディスプレイなどの表示装置２３やハードディスク２１４になされるが、図示しない外部コンピュータへのネットワークを介した出力や、フラッシュメモリなどの外部記憶媒体へのデータファイル形式での書き込みによる出力であってもよい。
【００２６】
図３は図１の機能構成により実行される処理のフローである。処理開始後、ステップ３１にて、ソースファイル入力部１０はテスト対象とするソフトウェアの変更前後のソースコードファイルを読み込み、構文解析部１１がソースコードファイルを解析して構文木データを生成する。
【００２７】
ステップ３２にて、依存関係解析部１２は構文木データから入力されたソースコードの制御フローと依存関係を解析する。
【００２８】
ステップ３３にて、変更箇所抽出部１３は入力されたソースコードの変更前後における差分（即ち、変更箇所）を抽出する。差分を取る方法としては、テキストや依存関係の比較を行う方法がある。
【００２９】
ステップ３４にて、変更箇所依存関係抽出部１４はテスト対象のソースコードにおける制御フローと依存関係のうち、ソースコードの変更前後における変更箇所を含む部分を抽出する。
【００３０】
ステップ３５にて、実行範囲決定部１５は変更箇所に関係する制御フロー上から実行開始点と実行終了点を選択することでテストケースの実行範囲を決定する。また、入力変数決定部１６は変更箇所に関係する依存関係上にて、テストケースの入力となる変数を決める。
【００３１】
ステップ３６にて、テストケース生成部１７は、入力値の組合せや処理の実行タイミングを決めることで、テストケースのデータを生成する。
【００３２】
ステップ３７にて、テストケース出力部１９は、テストケースを出力する。以上により処理を終了する。
【００３３】
図４は、テスト対象となるソフトウェアのソースコードの一例である。ソースコード４１は、テスト対象となるソースコードのうち一部である。左端の数字は行番号である。またソースコード４２は、ソースコード４１のうち、一部が変更されており、変更箇所として１５行目の定数「２」が「３」に置き換わっていることが示されている。これらのソースコード４１，４２は、ソースファイル入力部１０に読み込まれる。
【００３４】
図５は、図４のソースコード４２について、依存関係解析部１２により生成されるプログラム依存グラフのうち、変更箇所依存関係抽出部１４によりコード変更箇所に関係する（制御フローまたは依存関係でつながっている）部分だけが抽出されたものである。このようなグラフを抽出する方法は、コード変更箇所に対応するノードを、コード変更箇所の記述位置に関する情報からプログラム依存グラフ上で探索し、そのノードから前方及び後方に制御フローと依存関係をぞれぞれ辿る。
【００３５】
なお図５は見易さのために、制御フローグラフ５１と依存関係グラフ５２とに分けて表記している。変更箇所抽出部１３が抽出したコード変更前後の差分は、制御フローグラフ５１と依存関係グラフ５２とに紐付けられている。
【００３６】
以下では、変更後のソースコード４２に対するテストケース生成の具体例を示す。
【００３７】
実行範囲決定部１５は制御フローグラフ上にて、実行開始点を決定するために、１つのコード変更点（１５行目）から後方にフローを探索する。ある関数Ａが関数Ｂから呼び出しされる制御フローにおいて、関数Ｂ内の制御フロー探索中にコード変更箇所に遭遇しないときに探索を打ち切り、関数Ａの始点を実行開始点とする。この実行開始点の決定には、制御フローではなく関数コールツリーを用いても良い。
【００３８】
制御フローグラフ５１では、関数ｆ１１にコード変更箇所が無いので、関数ｆ１２の始点（１３行目）が実行開始点とされる。実行終了点は、実行開始点とされた関数の終点、または実行範囲の制御フローで最後に通過するコード変更点が含まれる関数の終点とする。ここでは、関数ｆ１２の終点（２４行目）が実行終了点とされる。但し、これ以外にも、実行終了点をテスト基準設定部１８で設定可能とし、テスト基準設定部１８から実行範囲決定部１５に指示されるものであってもよい。
【００３９】
次に入力変数決定部１６は依存関係グラフ５２上にて、変更点（１５行目）から後方と前方とに依存関係を探索する。探索範囲は、実行範囲決定部１５が同じ変更点（１５行目）に対して決定した実行開始点から実行終了点までの制御フロー内とし、この制御フローに含まれないステートメントに遭遇した時点で探索を打ち切る。
【００４０】
本実施例では、依存関係グラフ上で未定義の（すなわち代入されていない）変数をテストケースの入力変数として扱う。依存関係グラフ５２で探索した範囲では変数ｃとｖが未定義であるので、この２つを入力変数とする。
【００４１】
次にテストケース生成部１７は、テストケースのデータを生成する。テストケースの実行範囲と入力変数は既に決定されており、ここでは入力変数の値が決定される。本実施例では、テスト基準設定部１８にカバレッジ基準としてＣ１（分岐網羅）が設定されているものとする。制御フローグラフ５１から、分岐条件にて真と偽がそれぞれ選択されるための値が計算される。ｃ＞０（１７行目）が分岐条件であるため、Ｃ１を満たすために変数ｃ＝｛０，１｝とされる。また本実施例では、分岐条件に関係しない変数は、ランダムに２つの値を取るとする。例えば変数ｖ＝｛１，２｝と決定される。テストケースの入力変数値は、変数ｃ＝｛０，１｝、変数ｖ＝｛１，２｝の組合せとなる。
【００４２】
図６は、テストケース出力部１９が出力するテストケースのデータである。テーブル６１の各行が１つのテストケースに相当し、実行開始点、実行終了点、入力変数とその値が含まれる。テスト実行のためには、期待結果などを別途追加することが必要である。
【００４３】
以上によりソースコードの変更点とその影響範囲についてテストケースを生成することができ、ソースコードの変更に対応した回帰テストを容易に実行できる。テストケース生成部１７はプログラムの制御フローや依存関係を辿ってテストケースを生成しているため、ソースコードの変更点だけでなく、その影響範囲もテスト対象とすることができる。
【００４４】
即ち、本実施形態のソフトウェアテストシステム２０は、ソフトウェアの仕様または実装（ソースコード）の変更点とその変更が影響を及ぼす範囲、つまり変更が処理内容や処理結果に差異をもたらし得る仕様・実装に限定してテストケース生成を適用できるため、テストケース数の限定と、ソフトウェアの仕様・実装変更に伴う不具合発生の防止の両方に効果的である。また、仕様変更は実装変更につながるため、仕様変更時も実装の変更点とその影響範囲についてテストケース生成を行えばよい。
【実施例２】
【００４５】
以下では、テスト基準設定部１８にテストケース生成手法（即ち、テスト基準の入力値生成方法）として「モデル検査器を利用」が設定されているときのテストケース生成例を示す。他の条件は実施例１と同じとする。
【００４６】
図７は、図４のソフトウェアと同じプロジェクトに含まれるソースコードの一部である。このソースコードには変更がないとする。関数ｉｎｔｒは割込みで実行されることが、ソースコード内にコンパイラ指令（ｐｒａｇｍａ）を用いて設定されている。またこの設定情報は、依存関係解析部１２による制御フローデータに付与される。
【００４７】
変更箇所依存関係抽出部１４は、割込みに指定されている関数のプログラム依存グラフも抽出する。このため、関数ｉｎｔｒのプログラム依存グラフもコード変更点に関係するとして抽出される。実行範囲決定部１５と入力変数決定部１６の処理内容は、実施例１と同じである。
【００４８】
テストケース生成部１７はモデル検査器を用いてテストケース生成を行う。ソースコードは、モデル検査器（ＳＰＩＮなど）の仕様記述言語（ＳＰＩＮではＰｒｏｍｅｌａ）にＡＳＴ経由で所定のルールを用いて変換される。さらに、実行開始点である関数ｆ１２と、割込みで実行される関数ｉｎｔｒに相当する箇所が、モデル検査でも実行開始点に指定される。例えばＳＰＩＮを用いる場合、関数ｆ１２に相当する箇所を実行するプロセスと、関数ｉｎｔｒに相当する箇所を実行するプロセスが、Ｐｒｏｍｅｌａコードとして付与される。入力変数については、実施例１のように取りうる値を求め、その中から１つの値が非決定的に選択されるコードを、関数ｆ１２に相当する箇所の実行前に記述する。仕様記述言語にて変数がその型で取りうる値をすべて取りうることを指定できるのであれば、そのように指定してもよい。ここでは前者の方法を取る。
【００４９】
以上のようにして作成された仕様記述について、実行トレースが反例として生成されるようにプロパティを指定した上で、モデル検査が実行される。生成された反例から、入力変数値やプロセスの実行タイミングが抽出される。
【００５０】
図８は、テストケース出力部１９が出力するテストケースの例である。ただし、モデル検査器が生成した反例のうち、実行トレースとして冗長なものは除外してある。テーブル８１には、割込みで実行される関数と、その実行タイミングに関するデータが記載されている。例えばテストケース５では、関数ｆ１２の１７行目を実行しているときに、関数ｉｎｔｒが割込みとして実行されることが記載されている。
【００５１】
以上により、複数のプロセス（タスクや割り込み）を含むソフトウェアのソースコードに対し、変更点とその影響範囲についてテストケースを生成することができ、ソースコードの変更に対応した回帰テストを容易に実行できる。
【実施例３】
【００５２】
以下では、実行範囲決定部１５によるテストケースの実行範囲決定について、実施例１とは異なる方法を示す。テストケース生成の条件は実施例１と同じとする。
【００５３】
図９は、図４のソースコードについて、テストにおいてプログラムの実行開始点となる関数の候補が設定された実行開始点テーブル９１である。実行開始点テーブル９１は、実行範囲決定部１５に付与されている。
【００５４】
実行範囲決定部１５は実行範囲を決定するために次の処理を行う。図５の制御フローグラフ５１において、コード変更箇所（１５行目）から後方を探索する。制御フローグラフ５１の各ステートメントにて、実行開始点テーブル９１との合致を判定する。すると、関数ｆ１２が合致し、実行開始点として抽出される。実行開始点が抽出されたところで、制御フローグラフ５１の探索を終了する。もし、実行開始点テーブル９１と合致するステートメントがない場合には、制御フローの始点の関数を実行開始点とする。
【００５５】
他の処理は実施例１と同様であり、結果として図６のテストケースが生成される。
【００５６】
以上により、ソースコードの変更点とその影響範囲についてテストケースを生成することができ、その生成は次の特徴を持つ。実行開始点テーブル９１を用いることで、実行開始点を特定のステートメントに限定できる。これにより、例えば実行開始点をプログラムの実際の動作と同じ、周期タスクや割込み処理が開始する関数の先頭にすることができ、テストの事前条件を整えやすくなる、プログラムの実際の動作に近いテストが可能になる、などの利点がある。また、テストの実行開始点をコード変更前後で同じにすることで、コード変更前後のテスト結果を比較しやすくなる。
【実施例４】
【００５７】
以下では、入力変数決定部１６による入力変数の決定について、実施例１とは異なる方法を示す。テストケース生成の条件は実施例１と同じとする。
【００５８】
図１０は、図４のソースコードについて、テストにおいてプログラムの一部または全部を実行するときに入力となる変数の候補と、その値の選択肢や範囲が設定されている入力変数テーブル１０１である。入力変数テーブル１０１は、入力変数決定部１６に付与されている。
【００５９】
入力変数決定部１６は入力変数を決定するために次の処理を行う。図５の依存関係グラフ５２において、コード変更箇所（１５行目）から後方を探索する。探索中は、依存関係グラフ５２の各ステートメントにて、そのステートメントに記載された変数と、入力変数テーブル１０１の変数との合致を判定する。すると変数ｖが合致し、入力変数として抽出される。またその値の範囲は［１，２］に限定されることがわかる。
【００６０】
依存関係グラフ５２上のあるパスにおける探索は、探索位置におけるステートメントで利用される変数が入力変数テーブル１０１の変数と合致しているか、探索位置が実行範囲決定部１５が決定した実行範囲を超えた（対象ステートメントが制御フロー上にない）ところで、終了する。依存関係グラフ５２の探索終了後に、依存関係グラフ５２上で探索中に発見され、かつ未定義である変数ｃは、実施例１と同様に入力変数として抽出される。
【００６１】
テストケース生成部１７は入力変数の値を決める際、入力変数決定部１６により指定された変数ｖの範囲で取りうる値を選択する。選択方法としては、全て選択しても良いし、例えばテスト基準設定部１８に「Ｐａｉｒｗｉｓｅ法を利用」などと設定されていれば、指定の方法で組合せを選択してもよい。
【００６２】
他の処理は実施例１と同様であり、結果として図６のテストケースが生成される。
【００６３】
以上により、ソースコードの変更点とその影響範囲についてテストケースを生成することができ、その生成は次の特徴を持つ。入力変数テーブル１０１を用いることで、入力変数の取りうる値（仕様範囲外の値を含む）を規定し、その取りうる値の範囲で網羅的なテストケースを生成することができる。また逆に、入力変数が取らない値で不要なテストケースを生成することを防ぎ、テストに掛かる時間の短縮などの利を得ることができる。
【実施例５】
【００６４】
以下では、実行範囲決定部１５によるテストケースの実行範囲決定と、入力変数決定部１６による入力変数の決定について、実施例１とは異なる方法を示す。テストケース生成の条件は実施例１と同じとする。
【００６５】
本実施例では、実施例１〜４と異なり、入力変数決定部１６による入力変数の決定を、実行範囲決定部１５によるテストケースの実行範囲決定より先に行う。入力変数決定部１６は入力変数を決定するため、図５の依存関係グラフ５２を探索する。この処理は実施例４と同様であるが、探索範囲が実行範囲決定部１５の決めたテストケースの実行範囲に限定されない点が異なる。
【００６６】
次に実行範囲決定部１５は実行範囲を決定するために次の処理を行う。図５の制御フローグラフ５１において、コード変更箇所（１５行目）から後方を探索する。探索は、実行範囲決定部１６により決定された入力変数が利用されている箇所を、各入力変数について１回でも通過した時点で打ち切り、そのときのステートメントが含まれる関数の始点を実行開始点とする。実行終了点は、実施例１と同様に決定する。
【００６７】
次に入力変数決定部１６は、依存関係グラフ５２上の探索中に発見され、かつ未定義のままである変数ｃを、実施例１と同様に入力変数として抽出する。
【００６８】
図１１は、本実施例にて入力変数決定部１６に付与される入力変数テーブル１１１を示している。入力変数決定部１６は依存関係グラフ５２を探索し、変数ｒｅｇ１を入力変数として抽出し、その値の候補を｛１，３｝とする。依存関係グラフ５２の探索終了時に、未定義な変数として残っているのは、変数ｃである。
【００６９】
次に実行範囲決定部１５は、制御フローグラフ５１を探索し、変数ｒｅｇ１が利用されている９行目のステートメントにて探索を打ち切り、このステートメントが含まれる関数ｆ１１を実行開始点とする。次に入力変数決定部１６は、変数ｃを利用するステートメントが実行範囲に含まれることを確認し、変数ｃを入力変数に追加する。変数ｃの値の決め方は、実施例１と同様に、テスト基準設定部１８に設定されているカバレッジ基準やテストケース生成方法による。
【００７０】
以上の処理により、テストケース出力部１９は、図１２に示されたテストケースのデータを出力する。テーブル１２１の各行が１つのテストケースに相当し、その入力値は変数ｒｅｇ１の値｛１，３｝と、変数ｃの値｛０，１｝の組合せとなっている。
【００７１】
以上により、ソースコードの変更点とその影響範囲についてテストケースを生成することができ、その生成が持つ特徴は実施例４と同様である。ただし実施例４と比較して、入力変数のうち取りうる値が規定されたものの割合が、同等か増加する。これにより、テストの網羅性向上と不要なテストケースの減少を図ることができる。
【００７２】
以上の各実施例では、ソフトウェアの変更点とその影響範囲に関してテストケースを生成することが可能となり、コード変更により新規に必要となるテストケースを補った上での回帰テストを実現できる。また本ソフトウェアテストシステム２０では、ソフトウェアのソースコードの変更点とその影響範囲を特定し、その範囲に限定してテストケースを生成する方法を取っているため、ソフトウェア全体のようにより広範囲についてテストケース生成する方法よりも、テストケース生成に掛かる時間とテスト実施に掛かる時間を小さくすることができる。
【００７３】
本ソフトウェアテストシステム２０と同様に、ソフトウェアの変更点とその影響範囲に限定してテストケースを得る他の方法として、より広い範囲、例えばソフトウェア全体に対してテストケースを生成し、そのテストケースの中から、ソースコードの変更点とその影響範囲に関係するものだけを抽出する方法が考えられる。この方法では、生成されるテストケース数が本ソフトウェアテストシステム２０より大幅に増え、またその多数のテストケースから必要なものをより分ける作業が必要なことから、計算機のリソース（処理時間・メモリ消費量など）が本ソフトウェアテストシステム２０より多く必要になると考えられる。本ソフトウェアテストシステム２０はこの点を改善している。
【符号の説明】
【００７４】
１０…ソースファイル入力部、１１…構文解析部、１２…依存関係解析部、１３…変更箇所抽出部、１４…変更箇所依存関係抽出部、１５…実行範囲決定部、１６…入力変数決定部、１７…テストケース生成部、１８…テスト基準設定部、１９…テストケース出力部、２０…ソフトウェアテストシステム
【図１】
2015069400.tif 000003
【図２】
2015069400.tif 000004
【図３】
2015069400.tif 000005
【図４】
2015069400.tif 000006
【図５】
2015069400.tif 000007
【図６】
2015069400.tif 000008
【図７】
2015069400.tif 000009
【図８】
2015069400.tif 000010
【図９】
2015069400.tif 000011
【図１０】
2015069400.tif 000012
【図１１】
2015069400.tif 000013
【図１２】
2015069400.tif 000014