(57)【要約】【課題】テストを効率的に実行する。【解決手段】記憶部１ａは、複数の文字列を記憶する。演算部１ｂは、記憶部１ａに記憶部に記憶された文字列を含むテストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、その後に行う実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度を調整する。演算部１ｂは、実行テストの実行順序をテストデータに含まれる文字列ごとの優先度に基づいて変更する。【選択図】図１
2014049066.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
複数の文字列を含むテストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度を調整し、
その後に行う実行テストの実行順序をテストデータに含まれる文字列ごとの優先度に基づいて変更する、処理を実行させるプログラム。
【請求項２】
テストデータに応じた処理の実行テストの結果が不正である場合に、当該テストデータに含まれる文字列ごとの優先度が上がるように文字列ごとの優先度を調整し、
テストデータに含まれる文字列ごとの優先度に基づいてテストデータ単位の優先度を求め、テストデータごとの優先度に基づいて前記実行順序を変更する、請求項１記載のプログラム。
【請求項３】
テストデータに応じた処理の実行テストの結果が正しい場合に、当該テストデータに含まれる文字列ごとの優先度が下がるように文字列ごとの優先度を調整し、
テストデータに含まれる文字列ごとの優先度に基づいてテストデータ単位の優先度を求め、テストデータごとの優先度に基づいて前記実行順序を変更する、請求項１または２記載のプログラム。
【請求項４】
結果が不正となる文字列が特定できると、実行テストが未実行であるテストデータのうち、当該文字列を含むテストデータを実行テストの対象から除外する、または、当該文字列を含むテストデータに対する実行テストの実行順序が後回しになるように制御する、請求項１乃至３の何れか１項に記載のプログラム。
【請求項５】
前記複数のテストデータそれぞれに対する実行テストを行うたびにテストしたテストデータに含まれる文字列ごとの優先度を調整し、実行テストを所定回数行うたびに前記実行順序を変更する、請求項１乃至４の何れか１項に記載のプログラム。
【請求項６】
複数の文字列を記憶する記憶部と、
前記記憶部に記憶された文字列を含むテストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度を調整し、その後に行う実行テストの実行順序をテストデータに含まれる文字列ごとの優先度に基づいて変更する演算部と、を有する情報処理装置。
【請求項７】
コンピュータが、
複数の文字列を含むテストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度を調整し、
その後に行う実行テストの実行順序をテストデータに含まれる文字列ごとの優先度に基づいて変更する、テスト方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はプログラム、情報処理装置およびテスト方法に関する。
【背景技術】
【０００２】
ソフトウェアの品質を検証するために、テスト用のデータ（テストデータということがある）を当該ソフトウェアに入力して、その動作をテストすることがある。例えば、入力されたテストデータに対してソフトウェアから正しい出力が得られるかを確認する。そのために、入力され得るコマンドの組合せやパラメータの組合せのパターンを網羅したテストデータを複数作成し、テスト対象のソフトウェアに入力することが考えられる。入力されたテストデータに対するソフトウェアの出力を分析してバグを発見する。しかし、網羅的にテストを行うとするとテストにかかる時間や工数などが増大し得る。
【０００３】
そこで、テストする項目に対してテスト優先度を予め付与し、テスト優先度により優先的・重点的にテストする項目を決定することで、テスト計画の作成を支援する提案がある。また、テスト対象のパラメータの組合せ（テストパターン）がテスト済のパラメータの組合せに類似する場合は、当該テストパターンをテスト対象から除く処理の提案もある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−２５６２０６号公報
【特許文献２】特開２０１０−３２２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述のようにソフトウェアのテストでは、コマンドやパラメータなどの文字列の組合せを含む複数のテストデータをテスト対象のソフトウェアに入力することがある。当該テストにおいて、テストデータを、生成された順番や予め計画された順番でソフトウェアに入力してテストすることが考えられる。
【０００６】
しかし、テストを行っていく上で優先的にテストしたい内容は変わり得る。例えば、不正な結果となり得るテストデータを用いたテストを先に実行してエラーの状況を早期に確認し、対策の作業を開始したいということがある。また、例えば、正しい結果となり得るテストデータを用いたテストは後回しでもよいということがある。ところが、どのテストデータを入力したときに不正な結果となるか否かは実際にテストを実行してみない限り判断することが難しいという問題がある。
【０００７】
一側面によれば、本発明は、テストを効率的に実行できるプログラム、情報処理装置およびテスト方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一実施態様によれば、コンピュータによって実行されるプログラムが提供される。このプログラムは、コンピュータに、複数の文字列を含むテストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度を調整し、その後に行う実行テストの実行順序をテストデータに含まれる文字列ごとの優先度に基づいて変更する、処理を実行させる。
【０００９】
また、一実施態様によれば、情報処理装置が提供される。情報処理装置は、記憶部と演算部とを有する。記憶部は、複数の文字列を記憶する。演算部は、記憶部に記憶された文字列を含むテストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度を調整し、その後に行う実行テストの実行順序をテストデータに含まれる文字列ごとの優先度に基づいて変更する。
【００１０】
また、一実施態様によれば、コンピュータによって実行されるテスト方法が提供される。このテスト方法では、コンピュータが、複数の文字列を含むテストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度を調整し、その後に行う実行テストの実行順序をテストデータに含まれる文字列ごとの優先度に基づいて変更する。
【発明の効果】
【００１１】
一実施態様によれば、テストを効率的に実行できる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施の形態の情報処理装置を示す図である。
【図２】第２の実施の形態のハードウェア例を示す図である。
【図３】第２の実施の形態のソフトウェア例を示す図である。
【図４】第２の実施の形態のデータ例を示す図である。
【図５】第２の実施の形態の定義ファイルの例を示す図である。
【図６】第２の実施の形態の定義ファイルの例（続き）を示す図である。
【図７】第２の実施の形態のコード要素管理テーブルの例を示す図である。
【図８】第２の実施の形態の組合せ絞込条件リストの例を示す図である。
【図９】第２の実施の形態の組合せ管理テーブルの例を示す図である。
【図１０】第２の実施の形態の順序管理テーブルの例を示す図である。
【図１１】第２の実施の形態のコンパイル成否基準テーブルの例を示す図である。
【図１２】第２の実施の形態のテスト用のソースコードの例を示す図である。
【図１３】第２の実施の形態のテスト結果テーブルの例を示す図である。
【図１４】第２の実施の形態のテスト処理を示すフローチャートである。
【図１５】第２の実施の形態のコード要素組合せ処理を示すフローチャートである。
【図１６】第２の実施の形態のコード要素の組合せ例を示す図である。
【図１７】第２の実施の形態の目的コードの実行を示すフローチャートである。
【図１８】第２の実施の形態のコード要素の変更例を示す図である。
【図１９】第２の実施の形態のテスト順序変更を示すフローチャートである。
【図２０】第２の実施の形態のテスト順序変更例を示す図である。
【図２１】第３の実施の形態のソフトウェア例を示す図である。
【図２２】第３の実施の形態のデータ例を示す図である。
【図２３】第３の実施の形態の定義ファイルの例を示す図である。
【図２４】第３の実施の形態のコード要素管理テーブルの例を示す図である。
【図２５】第３の実施の形態のテスト順序変更例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理装置を示す図である。情報処理装置１は、テスト対象のソフトウェアに、テストデータを入力して、当該ソフトウェアの処理をテストする。情報処理装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａはＲＡＭ（Random Access Memory）などのメモリである。演算部１ｂはＣＰＵ（Central Processing Unit）などのプロセッサである。例えば、記憶部１ａに記憶されたプログラムを演算部１ｂが実行することで、第１の実施の形態の情報処理を実現できる。
【００１４】
記憶部１ａは、複数の文字列を記憶する。例えば、文字列はコマンドやコマンドの引数となるパラメータなどを示すものである。例えば、記憶部１ａは、文字列ＣＳ１，ＣＳ２，ＣＳ３，ＣＳ４，ＣＳ５，ＣＳ６を記憶する。
【００１５】
演算部１ｂは、記憶部１ａに記憶された文字列を含むテストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度を調整する。例えば、演算部１ｂは、あるテストデータに対する実行テストの結果が不正であった場合に、当該テストデータに含まれる文字列の優先度を、当該テストデータの実行テストを行う前より高くしてもよい。
【００１６】
例えば、テスト対象のソフトウェアはコンパイラでもよい。コンパイラは、ソースコードを処理して目的コードを作成する。この場合、テストデータはソースコードを記述したデータである。ソースコードは、変数を定義するための文字列やループや分岐などを記述した文字列などを含む。また、テスト対象のソフトウェアは、入力されたコマンドを実行するような他のアプリケーションでもよい。この場合、テストデータは、コマンドとコマンドに与える引数などの文字列を含む。ここで、文字列とは１または複数の文字である。文字は記号などの特殊文字を含んでもよい。
【００１７】
演算部１ｂは、その後に行う実行テストの実行順序をテストデータに含まれる文字列ごとの優先度に基づいて変更する。演算部１ｂは、当該テストデータに含まれる文字列の優先度に基づいてテストデータの優先度を算出してもよい。演算部１ｂは、テストデータごとの優先度に基づいて実行テストの実行順序を変更してもよい。例えば、優先度の高いテストデータの実行テストを優先して行うようにしてもよい。そうすれば、過去の実行テストの実績から、結果が不正になる可能性が高いテストデータを優先してテストするように制御することができる。
【００１８】
より具体的には次の通りである。例えば、テストデータＡ，Ｂ，Ｃ，Ｄ，Ｅをこの順序でテスト対象のソフトウェアに入力して処理の結果を取得し、結果を得るごとにその正否を確認する場合を考える。図１ではテストデータＡ，Ｂ，Ｃ，Ｄ，Ｅの集合をテストデータ群と称している。テストデータＡは文字列ＣＳ１，ＣＳ２，ＣＳ３を含む。テストデータＢは文字列ＣＳ３，ＣＳ４，ＣＳ５を含む。テストデータＣは文字列ＣＳ１，ＣＳ２，ＣＳ６を含む。テストデータＤは文字列ＣＳ２，ＣＳ３，ＣＳ６を含む。テストデータＥは文字列ＣＳ３，ＣＳ４，ＣＳ６を含む。
【００１９】
まず、演算部１ｂはテスト対象のソフトウェアにテストデータＡを入力する。テストデータＡに応じた処理の結果は正しかったとする。次に、演算部１ｂはテスト対象のソフトウェアにテストデータＢを入力する。テストデータＢに応じた処理の結果は不正であったとする。そこで、演算部１ｂはテストデータＢに含まれる文字列ＣＳ３，ＣＳ４，ＣＳ５の優先度を、テストデータＢによる実行テストを行う前よりも高くする。すると、文字列ＣＳ３，ＣＳ４，ＣＳ５を含む他のテストデータの優先度が高くなる。図１の例では、テストデータＤ，Ｅは文字列ＣＳ３，ＣＳ４を含む。よって、テストデータＤ，Ｅの優先度が高くなることになる。
【００２０】
その結果、例えば、テストデータＥの優先度がテストデータＤの優先度よりも高くなる。また、テストデータＤの優先度がテストデータＣの優先度よりも高くなる。よって、演算部１ｂはテストデータＣ，Ｄ，Ｅという順番を、テストデータＥ，Ｄ，Ｃという順番に変更する。すなわち、テストデータＥに対するテストをテストデータＤ，Ｃよりも繰り上げて実行する。また、テストデータＤに対するテストをテストデータＣよりも繰り上げて実行する。
【００２１】
なお、演算部１ｂは正しい結果が得られたテストデータに含まれる文字列の優先度を下げるようにしてもよい。そうすれば、当該文字列を含むテストデータが他のテストデータよりも後回しになるように制御できる。
【００２２】
また、演算部１ｂは１つのテストデータについて実行テストを行ったタイミングで実行順序を変更してもよいし、２以上の所定数のテストデータについて実行テストを行ったタイミングで実行順序を変更してもよい。
【００２３】
情報処理装置１によれば、演算部１ｂにより、テストデータに応じた処理の実行テストを複数のテストデータそれぞれに対して順次実行しながら、実行テストの結果に基づいてテストデータに含まれる文字列ごとの優先度が調整される。演算部１ｂにより、その後に行う実行テストの実行順序がテストデータに含まれる文字列ごとの優先度に基づいて変更される。
【００２４】
これにより、テストを効率的に実行できる。具体的には、ソフトウェアの処理のテストを実行しながら、動的にテストの実行順序を変更する。このため、各テストデータのテスト結果に応じた実行順序の制御が可能である。例えば、結果が不正になり得るテストデータをテスト開始前に事前に判断するのが難しい場合でも、各テストデータのテスト結果に応じて、不正な結果となる可能性の高いテストデータを優先してテストできる。
【００２５】
ここで、エラーを引き起こすテストデータや文字列の発見が遅れると、対策の作業が遅滞し得る。特に、テストデータに含まれる文字列の組合せの数によっては、全ての組合せのテストの開始から終了までに数時間から数日かかることもある。品質向上のためにはテストを網羅的に行うことが好ましい。しかし、テストを網羅的に行おうとするほど、テストに時間がかかることになり、作業の遅れが深刻になり得る。
【００２６】
これに対して、情報処理装置１によれば、上述の制御によりエラーを引き起こすテストデータや文字列を早期に発見できる可能性が高まる。よって、当該テストデータに含まれるコマンドやパラメータなどを参照して、バグなどの原因究明や対策の作業を迅速に行えるようになる。このように、ソフトウェアのデバッグ作業を効率的に支援することができる。
【００２７】
第１の実施の形態の情報処理は、種々のソフトウェアのテストに適用できる。以下の説明では、まず、第２の実施の形態として、コンパイラの実行テストに適用する場合を例示する。次に、第３の実施の形態として、ＤＢＭＳ（DataBase Management System）におけるＳＱＬの実行テストに適用する場合を例示する。以下の説明では、当該テストを実行する装置をテスト装置と称する。テスト装置は、例えばコンピュータによって実現できる。
【００２８】
［第２の実施の形態］
図２は、第２の実施の形態のハードウェア例を示す図である。テスト装置１００は、コンパイラのコンパイル処理（翻訳処理）の実行テストを行う。第２の実施の形態では、特に、コンパイル時の最適化の処理をテストする。具体的には、コンパイル時に最適化を行っても目的コードを正しく作成できるか否かを確認する。コンパイル時の最適化の処理とは、例えば、ループの融合や分割、ループのネスト（入れ子）構造の変更などである。
【００２９】
テスト装置１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ（Hard Disk Drive）１０３、通信部１０４、画像信号処理部１０５、入力信号処理部１０６、ディスクドライブ１０７および機器接続部１０８を有する。各ユニットがテスト装置１００のバスに接続されている。
【００３０】
プロセッサ１０１は、テスト装置１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）またはＰＬＤ（Programmable Logic Device）などである。プロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ、ＰＬＤのうちの２以上の要素の組合せであってもよい。
【００３１】
ＲＡＭ１０２は、テスト装置１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションのプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００３２】
ＨＤＤ１０３は、テスト装置１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。テスト装置１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００３３】
通信部１０４は、ネットワーク１０を介して他のコンピュータと通信を行えるインタフェースである。通信部１０４は、有線インタフェースでもよいし、無線インタフェースでもよい。
【００３４】
画像信号処理部１０５は、プロセッサ１０１からの命令に従って、テスト装置１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。
【００３５】
入力信号処理部１０６は、テスト装置１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００３６】
ディスクドライブ１０７は、レーザ光などを利用して、光ディスク１３に記録されたプログラムやデータを読み取る駆動装置である。光ディスク１３として、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などを使用できる。ディスクドライブ１０７は、例えば、プロセッサ１０１からの命令に従って、光ディスク１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００３７】
機器接続部１０８は、テスト装置１００に周辺機器を接続するための通信インタフェースである。例えば、機器接続部１０８にはメモリ装置１４やリーダライタ装置１５を接続できる。メモリ装置１４は、機器接続部１０８との通信機能を搭載した記録媒体である。リーダライタ装置１５は、メモリカード１６へのデータの書き込み、またはメモリカード１６からのデータの読み出しを行う装置である。メモリカード１６は、カード型の記録媒体である。機器接続部１０８は、例えば、プロセッサ１０１からの命令に従って、メモリ装置１４またはメモリカード１６から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００３８】
第２の実施の形態では、テスト対象のコンパイラを被検コンパイラと称する。被検コンパイラの最適化の機能をテストするために、テスト用の複数のソースコード（テストデータ）に対して次の（１）〜（３）の手順を順次実行する。
【００３９】
（１）被検コンパイラでソースコードをコンパイルする。被検コンパイラは、最適化オン（最適化する）／最適化オフ（最適化しない）の２通りの方法でコンパイルする。
（２）被検コンパイラのコンパイル結果に基づいて、コンパイルの成否を確認する。コンパイル成功と判断できた場合には、被検コンパイラによる最適化オン／オフのコンパイル処理で生成された２通りの目的コードを実行する。
【００４０】
（３）両方の目的コードの実行結果に基づいて、最適化を行っても目的コードが正しく作成できるかを確認する。具体的には、両方の目的コードの実行結果が一致すれば、目的コードが正しく作成できたことになる。一方、両方の目的コードの実行結果が不一致であれば、目的コードが正しく作成できていないことになる。
【００４１】
図３は、第２の実施の形態のソフトウェア例を示す図である。図３に示す各ユニットは、例えば、プロセッサ１０１がＲＡＭ１０２に記憶されたプログラムを実行することで実現できる。図３の各ユニットはＡＳＩＣやＦＰＧＡなどによって実現されてもよい。
【００４２】
テスト装置１００は、記憶部１１０、組合せ生成部１２０、順序管理部１３０、コード生成部１４０、テスト用ソフトウェア１５０および検証部１６０を有する。
記憶部１１０は、各部の処理に用いられるデータを記憶する。記憶部１１０は、例えばＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実装できる。記憶部１１０に格納されるデータには、定義ファイル、組合せ管理テーブル、順序管理テーブルおよびテスト結果テーブルなどが含まれる。
【００４３】
定義ファイルは、ソースコードを生成するためのコマンドやパラメータなどを示す文字列を定義したデータである。組合せ管理テーブルは、文字列の組合せを管理するためのデータである。順序管理テーブルは、組合せごとのテストの実行順序を管理するためのデータである。
【００４４】
組合せ生成部１２０は、記憶部１１０に記憶された定義ファイルに基づいて、文字列の組合せを生成し、組合せ管理テーブルに登録する。組合せ生成部１２０は、類似する組合せや余分の組合せを削減して、テストに用いる組合せを絞り込む処理も行う。
【００４５】
順序管理部１３０は、記憶部１１０に記憶された組合せ管理テーブルに登録された複数の組合せについて、テストの実行順序を決定し、順序管理テーブルに登録する。具体的には、組合せに含まれる文字列ごとに優先度が設定される。順序管理部１３０は、文字列ごとの優先度に基づいて組合せ単位の優先度を算出する。順序管理部１３０は、組合せ単位の優先度に基づいて、テストの実行順序を決定する。
【００４６】
コード生成部１４０は、記憶部１１０に記憶された定義ファイルに基づいて、テスト用のソースコードを生成する。このとき、コード生成部１４０は順序管理部１３０が決定した順番に従って、テスト用のソースコードを生成する。
【００４７】
テスト用ソフトウェア１５０は、テスト対象のソフトウェアを含むソフトウェア群である。第２の実施の形態では、当該ソフトウェアはコンパイラである。コンパイラはソースコードから目的コードを生成する。テスト用ソフトウェア１５０には、被検コンパイラ１５１および比較用コンパイラ１５２が含まれる。被検コンパイラ１５１は、テスト対象のコンパイラである。被検コンパイラ１５１は、最適化オン／オフでのコンパイルを行える。比較用コンパイラ１５２は、被検コンパイラ１５１によるコンパイルの成否確認に利用できるコンパイラである。
【００４８】
ここで、第２の実施の形態では、プログラミング言語の一例としてＦｏｒｔｒａｎを想定する。被検コンパイラ１５１および比較用コンパイラ１５２は、Ｆｏｒｔｒａｎで記述されたソースコードをコンパイルする。ただし、Ｃ、Ｃ＋＋およびＪａｖａ（登録商標）など他のプログラミング言語で記述されたソースコードのコンパイルのテストに、第２の実施の形態の情報処理を適用してもよい。
【００４９】
検証部１６０は、テスト用のソースコードのうち、コンパイルに成功したものについて、目的コードを実行し、実行結果の正否を確認する。具体的には、コンパイルに成功した場合、被検コンパイラ１５１により生成された２種類の目的コードが得られる。１つ目は最適化オンで生成された目的コードである。２つ目は最適化オフで生成された目的コードである。検証部１６０は、両方の目的コードを実行して、両方の実行結果が一致するか否かにより、最適化オンでも正しい結果が得られるかを確認する。検証部１６０は、最適化オンで生成された目的コードの実行結果と、比較用コンパイラで生成された目的コードの実行結果とを照合して、当該正否の判断を行ってもよい。検証部１６０は、記憶部１１０に記憶されたテスト結果テーブルに確認結果を登録する。
【００５０】
検証部１６０は、確認結果に応じて、対応するソースコードの生成に用いられたコード要素の組合せに含まれる各コード要素の優先度を調整する。
図４は、第２の実施の形態のデータ例を示す図である。記憶部１１０は、定義ファイル１１１、コード要素管理テーブル１１２、組合せ絞込条件リスト１１３、組合せ管理テーブル１１４、順序管理テーブル１１５、コンパイル成否基準テーブル１１６、ソースコード１１７およびテスト結果テーブル１１８を記憶する。
【００５１】
定義ファイル１１１は、前述のように、ソースコードを生成するためのコマンドやパラメータなどを示す文字列を定義したデータである。以下の説明では、コマンドやパラメータなどを示す文字列をコード要素と称することがある。定義ファイル１１１は、例えばテストに応じてユーザにより予め作成される。
【００５２】
定義ファイル１１１では、１つのコード要素について複数のバリエーションを定義できる。例えば、ソースコードの一部分に対して、第１のコマンドおよび第２のコマンドの何れかを挿入するような定義が可能である。また、あるコマンドの引数について、第１のパラメータおよび第２のパラメータの何れかを挿入するような定義が可能である。
【００５３】
更に、定義ファイル１１１ではコード要素ごとに優先度が設定される。例えば、２つのコード要素である第１，第２のコマンドを、ソースコード内に選択的に挿入する場合に、第１のコマンドの優先度を第２のコマンドの優先度よりも高くする。すると、第１のコマンドが第２のコマンドよりも優先的に選択されてソースコードが作成される。すなわち、第１のコマンドを含むソースコードのテストを、第２のコマンドを含むソースコードのテストよりも早い段階で行えることになる。
【００５４】
コード要素管理テーブル１１２は、定義ファイル１１１に定義されたコード要素およびコード要素ごとの優先度を管理するためのデータである。各コード要素は識別記号に対応付けられる（後述する）。
【００５５】
組合せ絞込条件リスト１１３は、コード要素の組合せを絞り込むための条件を定義したデータである。例えば、組合せ生成部１２０は類似の組合せを削減する処理を行う。この場合、類似の組合せを判定するための基準が組合せ絞込条件リスト１１３に予め設定される。
【００５６】
組合せ管理テーブル１１４は、前述のように、文字列（コード要素）の組合せを管理するためのデータである。コード要素の組合せは、コード要素に対応する記号の組合せによって管理される。
【００５７】
順序管理テーブル１１５は、前述のように、コード要素の組合せごとのテストの実行順序を管理するためのデータである。順序管理テーブル１１５は、順序管理部１３０によって更新される。
【００５８】
コンパイル成否基準テーブル１１６は、ソースコードのコンパイルの成否を判定するための基準を定義したデータである。あるテスト用のソースコードのコンパイルの成否は、被検コンパイラ１５１や比較用コンパイラ１５２によるコンパイル処理の結果に基づいて判定される。当該判定のための基準がコンパイル成否基準テーブル１１６に予め設定される。
【００５９】
ソースコード１１７は、コード生成部１４０により定義ファイル１１１に基づいて生成されたテスト用のソースコード（テストデータの一例）である。ソースコード１１７は、１つの定義ファイル１１１に対して複数のバリエーションが生成され得る。
【００６０】
テスト結果テーブル１１８は、目的コードの実行結果の正否を登録したデータである。テスト結果テーブル１１８は、順序管理部１３０によって参照され、コード要素の優先度を変更する処理に用いられる。
【００６１】
また、記憶部１１０はソースコード１１７に対応する目的コードを記憶してもよい。具体的には、被検コンパイラ１５１により最適化オン／オフの２種類の方法を用いて生成された２種類の目的コードを記憶してもよい。更に、比較用コンパイラ１５２により生成された目的コードを記憶してもよい。
【００６２】
図５は、第２の実施の形態の定義ファイルの例を示す図である。定義ファイル１１１は、Ｆｏｒｔｒａｎのソースコードを作成するためのデータである。以下、定義ファイル１１１に便宜的に付した行番号を用いて説明する。定義ファイル１１１は次のルール１〜３に基づいて記述されている。
【００６３】
（ルール１）行頭（行の左端）のコロン“：”によって、ソースコード内のコード要素の１つの集合（要素集合と称することがある）を表す。例えば、ある行に行頭の第１のコロン“：”が存在する場合、定義ファイル１１１をその行から順番に下に参照していき、行頭の第２のコロン“：”が現れる行の１つ前の行を特定する。第１のコロン“：”の行から当該特定された行までが、第１のコロン“：”で表される１つの要素集合である。行頭の“：”に続けて、同じ行に記述された文字列は当該要素集合の名称を示す。１つの要素集合は１以上のコード要素を含み得る（ただし、行頭に“＊”が付された記述はコード要素には該当しない）。
【００６４】
例えば、１行目の“：ｐｒｏｇｒａｍ  ｓｔａｒｔ”は、１つの要素集合の開始を表している。“ｐｒｏｇｒａｍ  ｓｔａｒｔ”は要素集合の名称である。当該要素集合は、４行目以降に記述された“ｉｎｔｅｇｅｒ  ｉ１，ｉ２，ｉ３”や“ｉｎｔｅｇｅｒ  ［＊４，１０｜＊８，２０］  ｖ１”などの文字列を含んでいる。これらの文字列がコード要素である。
【００６５】
（ルール２）行頭の“＊”によって、要素集合内のコード要素に対する属性を定義できる。定義可能な属性としては、要素ＩＤ（IDentifier）および優先度である。要素ＩＤはコード要素の識別名である。優先度はコード要素ごとの優先度である。優先度は、値が大きいほど、優先される度合いが高いものとする。行頭の“＊”に続けて、要素ＩＤおよび優先度をカンマ区切りで記述する。
【００６６】
例えば、１６行目の記述“＊  ｌｏｏｐ  （，  １２０”は、１７行目のコード要素“ｄｏ  ｉ１＝０，１０，１”の属性を定義している。具体的には、要素ＩＤ“ｌｏｏｐ  （”、優先度“１２０”が当該コード要素に付与されていることを示す。ここで、要素ＩＤに“ｌｏｏｐ”の文字列が含まれる場合、当該要素集合がソースコード内のブロック構造（より詳細にはループ）に関するコード要素であることを示す。
【００６７】
同様に、１８行目の記述“＊  ｌｏｏｐ＿ｅｎｄ  ）”は、１９行目のコード要素“ｅｎｄ  ｄｏ”の属性を定義している。具体的には、要素ＩＤ“ｌｏｏｐ＿ｅｎｄ  ）”が当該コード要素に付与されていることを示す。要素ＩＤ“ｌｏｏｐ＿ｅｎｄ  ）”は要素ＩＤ“ｌｏｏｐ  （”で示されるコード要素に付随するブロック構造に関するコード要素（より詳細にはループの終了）であることを示す。ここで、優先度は付与されていない。１９行目のコード要素は、１７行目のコード要素に付随するものであり、１７行目のコード要素に優先度を定義すれば十分だからである。これは、２４行目、２９行目のコード要素（何れも“ｅｎｄ  ｄｏ”）についても同様である。
【００６８】
また、必須のコード要素には優先度を定義しなくてもよい。必須のコード要素とはソースコードに必ず含まれるようにするコード要素である。例えば、２行目の記述“＊  ｍａｉｎ”は“ｍａｉｎ”という要素ＩＤのみを定義している（優先度を定義していない）。なお、要素ＩＤ“ｍａｉｎ”は、データ構造の定義に関するコード要素であることを示す。
【００６９】
（ルール３）１つのブロックはコマンドを示す文字列を１または複数個含み得る。各コマンドを示す文字列を選択可能な形式で記述できる。具体的には、角括弧記号“［”、“］”で囲った内側に、バーティカルバー記号“｜”で区切って選択対象の文字列を記述する。各文字列には、当該文字列を選択する際の優先度をカンマ区切りで設定できる。
【００７０】
例えば、５行目のコード要素“ｉｎｔｅｇｅｒ  ［＊４，１０｜＊８，２０］  ｖ１”は、テスト用のソースコード内に“ｉｎｔｅｇｅｒ＊４  ｖ１”または“ｉｎｔｅｇｅｒ＊８  ｖ１”の何れか一方を選択して記述することを示す。このとき、当該コード要素の定義によれば、“ｉｎｔｅｇｅｒ＊４  ｖ１”の優先度が“１０”、“ｉｎｔｅｇｅｒ＊８  ｖ１”の優先度が“２０”である。よって、当該定義ファイル１１１の設定では“ｉｎｔｅｇｅｒ＊８  ｖ１”の方が優先的に選択されてソースコードが生成されることになる。ただし、この優先度はソースコードごとのテスト結果に応じて補正され得る。
【００７１】
また、５行目のコード要素では要素ＩＤを定義していない。当該コード要素の要素ＩＤは、コード要素を直接記述した文字列となる。この場合は、“ｉｎｔｅｇｅｒ＊４  ｖ１”および“ｉｎｔｅｇｅｒ＊８  ｖ１”を要素ＩＤとする。
【００７２】
図６は、第２の実施の形態の定義ファイルの例（続き）を示す図である。例えば、要素集合“ｅｘｐｅｒ”（３２行目の記述）が定義されている。当該要素集合は、例えば、３４行目のコード要素“［ｖ１｜ｖ２］＝［ｖ２｜ｖ３］”を含む。これは“ｖ１＝ｖ２”、“ｖ１＝ｖ３”、“ｖ２＝ｖ２”、“ｖ２＝ｖ３”の何れかをソースコード内に記述するための定義である。３３行目の記述“＊  ｅｘｐｒ１，５０”によれば、３４行目のコード要素には要素ＩＤ“ｅｘｐｒ１”、優先度“５０”が付与されている。要素ＩＤに“ｅｘｐｒ”の文字列が含まれる場合、当該要素集合が数式やＡＰＩ（Application Programming Interface）の利用に関するコード要素であることを示す。
【００７３】
なお、定義ファイル１１１には要素集合“ｅｎｄ”（４４行目）において、要素ＩＤ“ｐｒｉｎｔ”（４５行目）、“ｅｎｄ”（４７行目）も例示されている。要素ＩＤ“ｐｒｉｎｔ”は、出力に関するコード要素であることを示す。要素ＩＤ“ｅｎｄ”は、プログラムの終了を示すコード要素であることを示す。
【００７４】
組合せ生成部１２０は、定義ファイル１１１に記述されたコード要素を組合せる。組合せを行うためには次の（１）（２）のような条件も用いる。（１）ループの選択数。例えば５個以内というように予め指定される。（２）ループ内に挿入する数式・ＡＰＩの数。例えば５個以内というように予め指定される。これらの条件は、組合せ生成部１２０に対して予め指定できる。あるいは、定義ファイル１１１内に定義されてもよい。
【００７５】
図７は、第２の実施の形態のコード要素管理テーブルの例を示す図である。コード要素管理テーブル１１２には、定義ファイル１１１のうち、選択の対象となり得るコード要素が組合せ生成部１２０により登録される。コード要素管理テーブル１１２は、コード要素、要素区分、識別記号および優先度補正値の項目を含む。
【００７６】
コード要素の項目には、要素ＩＤが登録される。要素区分の項目には、要素区分が登録される。要素区分とは、要素ＩＤから導かれるコード要素の区分である。例えば、要素ＩＤに“ｉｎｔｅｇｅｒ”が含まれる場合、要素区分は“データ構造”である。また、要素ＩＤに“ｌｏｏｐ”が含まれる場合、要素区分は“ブロック構造”である。また、要素ＩＤに“ｅｘｐｒ”が含まれる場合、要素区分は“式、ＡＰＩ”である。
【００７７】
識別記号の項目には、識別記号が登録される。識別記号とは、コード要素の組合せの管理に用いられる記号である。識別記号は、定義ファイル１１１で指定されることもあるし、組合せ生成部１２０によって付与されることもある。例えば、要素ＩＤの文字列の末尾にスペースに続く記号を含む場合（例えば、“ｌｏｏｐ  （”）、当該コード要素の識別記号はその記号（例えば、丸括弧開始記号“（”）である。要素ＩＤがそのような記号を含まなければ、組合せ生成部１２０が当該コード要素に一意の識別記号を付与する。
【００７８】
優先度補正値の項目には、定義ファイル１１１で指定された優先度に対する補正値が登録される。優先度補正値の項目に設定される初期値は“０”である。
例えば、コード要素管理テーブル１１２には、コード要素が“ｉｎｔｅｇｅｒ＊４  ｖ１”、要素区分が“データ構造”、識別記号が“ａ”、優先度補正値が“１５”という情報が登録されている。これは、コード要素“ｉｎｔｅｇｅｒ＊４  ｖ１”の要素区分が“データ構造”を示すものであることを示す。また、識別記号が“ａ”であり、定義ファイル１１１で設定された優先度に補正値“１５”を加算することを示す。
【００７９】
ここで、定義ファイル１１１では、コード要素“ｉｎｔｅｇｅｒ＊４  ｖ１”や“ｉｎｔｅｇｅｒ＊８  ｖ１”に対する識別記号は指定されていない。このようなコード要素には組合せ生成部１２０が識別記号を付与する。識別記号“ａ”は組合せ生成部１２０によって付与されたものである。また、コード要素“ｉｎｔｅｇｅｒ＊４  ｖ１”および“ｉｎｔｅｇｅｒ＊８  ｖ１”は、同一の変数“ｖ１”を定義するものである。よって、ソースコードには何れか一方の定義を記述すればよいことになる。
【００８０】
また、例えば、コード要素管理テーブル１１２には、コード要素が“ｌｏｏｐ（”、要素区分が“ブロック構造”、識別記号が“（”、優先度補正値が“０”という情報が登録されている。これは、コード要素“ｌｏｏｐ  （”の要素区分が“ブロック構造”を示すものであることを示す。また、識別記号が“（”であり、定義ファイル１１１で設定された優先度に補正値“０”を加算する（初期値のままとする）ことを示す。
【００８１】
また、例えば、コード要素管理テーブル１１２には、コード要素が“ｅｘｐｒ１”、要素区分が“式、ＡＰＩ”、識別記号が“１”、優先度補正値が“−１”という情報が登録されている。これは、コード要素“ｅｘｐｒ１”の要素区分が“式、ＡＰＩ”を示すものであることを示す。また、識別記号が“１”であり、定義ファイル１１１で設定された優先度に補正値“−１”を加算する（“１”を減算する）ことを示す。このように、優先度補正値は、プラス／マイナスの値をとり得る。
【００８２】
なお、以下の説明において、コード要素をコード要素管理テーブル１１２に設定された識別記号で指し示すことがある。例えば、コード要素“ａ”という場合、識別記号が“ａ”であるコード要素“ｉｎｔｅｇｅｒ＊４  ｖ１”を意味する。
【００８３】
図８は、第２の実施の形態の組合せ絞込条件リストの例を示す図である。組合せ絞込条件リスト１１３には、コード要素の組合せの絞込みを行うための条件を設定可能である。この条件はテスト対象の入力データを絞り込むための条件ということもできる。
【００８４】
例えば、組合せ絞込条件リスト１１３には、““ｌｏｏｐ  ＜”は“ｌｏｏｐ  （”と類似”という情報が登録されている。これは、要素ＩＤ“ｌｏｏｐ  ＜”で示されるコード要素“ｄｏ  ｉ３＝０，１０，２”を、要素ＩＤ“ｌｏｏｐ  （”で示されるコード要素“ｄｏ  ｉ１＝０，１０，１”と類似するものとし、前者のコード要素を含む組合せを省略し得ることを示している。
【００８５】
また、例えば、組合せ絞込条件リスト１１３には、““ｌｏｏｐ＿ｅｎｄ”記号の直後に“式、ＡＰＩ”のコード要素あり”という情報が登録されている。これは、“ｌｏｏｐ＿ｅｎｄ”記号、すなわち、定義ファイル１１１の例でいえば“）”、“］”、“＞”などの後に、要素区分“式、ＡＰＩ”のコード要素が結合されるような組合せを省略し得ることを示している。
【００８６】
このような組合せを省略し得るのは、コンパイルの最適化のテストには不向きである可能性が高いからである。例えば、ループに対する最適化の処理についてテストしたい場合に、ループの外側に数式が存在するソースコードをテストしても、バグの調査にとって有益な情報を得られない場合がある。そこで、このような組合せをテスト対象から除外可能とする。テストを効率的に行えるようにするためである。
【００８７】
このように、組合せ絞込条件リスト１１３には、テスト対象から除外し得る組合せを判別するための条件を、テスト内容に応じて登録できる。
図９は、第２の実施の形態の組合せ管理テーブルの例を示す図である。組合せ管理テーブル１１４では、コード要素の組合せが識別記号を用いて管理される。組合せ管理テーブル１１４は、組合せＩＤ、組合せ内容および優先度の項目を含む。
【００８８】
組合せＩＤの項目には、組合せを識別するための識別情報が登録される。組合せ内容の項目には、コード要素の識別記号を用いて表された組合せの内容が登録される。ループの開始を示すコード要素に対しては、それに付随するループの終了を示すコード要素も組合せ内容に含める。ループの範囲を識別し易くするためである。優先度の項目には、組合せ単位の優先度が登録される。
【００８９】
例えば、組合せ管理テーブル１１４には、組合せＩＤが“Ｃ１”、組合せ内容が“ｂｃｅ（＜１３＞＜２３＞＜１＞）”、優先度が“７０４”という情報が登録されている。これは、組合せＩＤ“Ｃ１”で示される組合せの内容がコード要素の識別記号の組合せ“ｂｃｅ（＜１３＞＜２３＞＜１＞）”であり、組合せ単位の優先度が“７０４”であることを示す。
【００９０】
なお、以下の説明において、組合せＩＤを用いて組合せを指し示すことがある。例えば、組合せ“Ｃ１”という場合、組合せＩＤが“Ｃ１”である組合せを意味する。
１つの組合せでは、同じコード要素が複数回現れてもよい。ただし、要素区分が“データ構造”であるコード要素（例えば、“ｉｎｔｅｇｅｒ＊８  ｖ１”）は、１つの変数（例えば、“ｖ１”）に対し、１つの組合せの中で１回登場すれば十分である。よって、組合せ生成部１２０は、このようなコード要素は１つの変数（例えば、“ｖ１”）に対して１回だけ現れるようにする。
【００９１】
また、優先度（組合せ単位の優先度）は、定義ファイル１１１で定義されたコード要素単位の優先度を、コード要素管理テーブル１１２に設定された優先度補正値で補正し、組合せに含まれる各コード要素の補正後の優先度を加算したものである。
【００９２】
組合せ“Ｃ１”の例でいえば、コード要素“ｂ”は“ｉｎｔｅｇｅｒ＊８  ｖ１”に対応する。当該コード要素には定義ファイル１１１で優先度“２０”が付与されている。また、コード要素管理テーブル１１２によれば、当該コード要素の優先度補正値は“５”である。したがって、コード要素単位の補正後の優先度は“２０＋５＝２５”となる。
【００９３】
同様にして、コード要素“ｃ”の補正後の優先度は“１０＋１５＝２５”である。コード要素“ｅ”の補正後の優先度は“１０＋１５＝２５”である。コード要素“＜”の補正後の優先度は“８０＋２０＝１００”である。コード要素“（”の補正後の優先度は“１２０＋０＝１２０”である。コード要素“１”の補正後の優先度は“５０＋（−１）＝４９”である。コード要素“２”の補正後の優先度は“４０＋５＝４５”である。コード要素“３”の補正後の優先度は“３０＋３＝３３”である。
【００９４】
組合せ“Ｃ１”の組合せ単位の優先度は、コード要素“ｂ”、“ｃ”、“ｅ”、“（”、“＜”、“１”、“２”、“３”の補正後の優先度（複数回現れるコード要素はその回数を補正後の優先度に乗じた値）を合計した値となる。すなわち、組合せ“Ｃ１”の優先度は“２５＋２５＋２５＋１２０＋１００＋４９＋３３＋１００＋４５＋３３＋１００＋４９＝７０４”と算出される。
【００９５】
図１０は、第２の実施の形態の順序管理テーブルの例を示す図である。順序管理テーブル１１５では、組合せＩＤを用いて組合せごとのテスト順序が管理される。順序管理テーブル１１５は、順序および組合せＩＤの項目を含む。順序の項目には、テストを実行する順番が登録される。順序“１”が最初（１番目）である。順序“２”が２番目である。３番目以降も同様である。組合せＩＤの項目には、組合せＩＤが登録される。
【００９６】
例えば、順序管理テーブル１１５には、順序が“１”、組合せＩＤが“Ｃ１”という情報が登録される。これは、順序管理テーブル１１５に登録された組合せの中で組合せ“Ｃ１”を最も優先して、テストすることを示す。
【００９７】
図１１は、第２の実施の形態のコンパイル成否基準テーブルの例を示す図である。コンパイル成否基準テーブル１１６には、テスト用のソースコードのコンパイル成否を判断するための基準が登録される。
【００９８】
コンパイル成功と判断される場合は、次のフェーズ（目的コードの実行）に移ることになる。これをテストの“続行”と称している。一方、コンパイル失敗と判断される場合は目的コードがないため、当該ソースコードについては、次のフェーズ（目的コードの実行）を行わない（次のソースコードのテストに移る）。これをテストの“スキップ”と称している。
【００９９】
コンパイル成否基準テーブル１１６は、被検コンパイラ、比較用コンパイラおよびテスト実行方針の項目を含む。被検コンパイラでは最適化オン／オフでコンパイルを行うため、被検コンパイラの項目は、更に最適化オン／オフの項目に細分化される。
【０１００】
被検コンパイラ（最適化オン／オフ）の項目には、被検コンパイラ１５１によるコンパイルの成功／失敗の何れかが登録される。比較用コンパイラの項目には、比較用コンパイラ１５２によるコンパイルの成功／失敗の何れかが登録される。テスト実行方針の項目には、被検コンパイラ１５１および比較用コンパイラ１５２のコンパイルの成功／失敗のパターンに応じた、当該ソースコードに対するテストの実行方針が登録される。
【０１０１】
例えば、コンパイル成否基準テーブル１１６では、被検コンパイラ１５１で最適化オン／オフの両方の方法でコンパイルが成功すれば、当該ソースコードに対するテストを“続行”し、最適化オン／オフの少なくとも何れかの方法でコンパイルが失敗すれば、当該ソースコードに対するテストを“スキップ”するように設定されている。
【０１０２】
ただし、被検コンパイラ１５１の最適化オンでコンパイル成功し、比較用コンパイラ１５２でコンパイル成功していれば、被検コンパイラ１５１の最適化オフでコンパイル失敗していても、当該ソースコードに対するテストを“続行”するように設定してもよい。被検コンパイラ１５１により最適化オンで生成された目的コードと、比較用コンパイラ１５２で生成された目的コードを用いて、最適化オンで生成された目的コードを実行したときの結果を検証できるからである。
【０１０３】
図１２は、第２の実施の形態のテスト用のソースコードの例を示す図である。ソースコード１１７は、順序管理部１３０により指定された組合せの内容および定義ファイル１１１に基づいて、コード生成部１４０により生成されるテストデータである。ソースコード１１７は、組合せ“Ｃ１”に対して生成されるソースコードの一例である。組合せ“Ｃ１”の組合せ内容は“ｂｃｅ（＜１３＞＜２３＞＜１＞）”である。以下、ソースコード１１７に便宜的に付した行番号を用いて説明する。
【０１０４】
１行目に記述された“ｌｏｏｐ０００１．ｆ”はソースコード１１７のファイル名である。４行目はコード要素“ｂ”である。５行目はコード要素“ｃ”である。６行目はコード要素“ｅ”である。１３行目はコード要素“（”である。
【０１０５】
１４行目はコード要素“＜”である。１５行目はコード要素“１”である。１６行目はコード要素“３”である。１７行目は１４行目のコード要素“＜”に付随するコード要素“＞”である。
【０１０６】
１８行目はコード要素“＜”である。１９行目はコード要素“２”である。２０行目はコード要素“３”である。２１行目は１８行目のコード要素“＜”に付随するコード要素“＞”である。
【０１０７】
２２行目はコード要素“＜”である。２３行目はコード要素“１”である。２４行目は２２行目のコード要素“＜”に付随するコード要素“＞”である。
２５行目は１３行目のコード要素“（”に付随するコード要素“）”である。
【０１０８】
それ以外の行に記述されたコード要素は定義ファイル１１１に必須のコード要素として記述されたコード要素である。また、ソースコード中には、コード要素の優先度は記述されない。
【０１０９】
図１３は、第２の実施の形態のテスト結果テーブルの例を示す図である。テスト結果テーブル１１８では、ソースコードのファイル名に対応付けてテスト結果が登録される。テスト結果テーブル１１８は、組合せＩＤ、ソースコードファイル名および結果の項目を含む。
【０１１０】
組合せＩＤの項目には、組合せＩＤが登録される。ソースコードファイル名の項目には、ソースコードのファイル名が登録される。結果の項目には、テスト結果の内容が登録される。テスト結果としては、例えば、次のような内容が登録され得る。
【０１１１】
（１）正常に実行できたこと。（２）コンパイルの時点で失敗したこと。（３）目的コードの実行中に異常が発生したこと。（４）コンパイルに成功して目的コードを実行したが最適化オン／オフ（または、最適化オンで生成された目的コードと比較用コンパイラ１５２が生成した目的コードと）で実行結果が不一致だった（すなわち、実行結果が不正であった）こと。失敗や異常が発生した場合には、目的コードのエラー箇所などを示すデバッグ情報を登録してもよい。
【０１１２】
例えば、テスト結果テーブル１１８には、組合せＩＤが“Ｃ１”、ソースコードファイル名が“ｌｏｏｐ０００１．ｆ”、結果が“実行結果不一致”という情報が登録される。これは、組合せ“Ｃ１”に対して生成されたソースコードのファイル名が“ｌｏｏｐ０００１．ｆ”であり、コンパイルに成功して目的コードを実行したが実行結果が不正であったことを示す。
【０１１３】
例えば、ソフトウェアの開発者は、テスト結果テーブル１１８の内容を参照可能である。ソフトウェアの開発者は、テスト結果テーブル１１８の内容に基づいて、被検コンパイラ１５１のバグ箇所を特定し、修正し得る。なお、ソースコードのファイルは、所定のディレクトリに格納される。ソフトウェアの開発者は、ソースコードの内容を閲覧してバグ解析に活用できる。
【０１１４】
図１４は、第２の実施の形態のテスト処理を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
（ステップＳ１１）組合せ生成部１２０は、被検コンパイラ１５１の最適化処理に関するテストを開始する旨の入力を受け付ける。例えば、ソフトウェアの開発者は、入力デバイス１２を操作して、当該入力を行える。ソフトウェアの開発者は、定義ファイル１１１、組合せ絞込条件リスト１１３およびコンパイル成否基準テーブル１１６を記憶部１１０に予め格納しておく。組合せ生成部１２０は、定義ファイル１１１に含まれるコード要素の組合せ処理を実行し、コード要素管理テーブル１１２および組合せ管理テーブル１１４を生成する（詳細は後述する）。ただし、本ステップでは組合せ管理テーブル１１４において、組合せ単位の優先度は未登録であるとする。
【０１１５】
（ステップＳ１２）順序管理部１３０は、定義ファイル１１１、コード要素管理テーブル１１２および組合せ管理テーブル１１４に基づいて、組合せ単位の優先度を計算し、組合せ管理テーブル１１４に登録する。組合せ単位の具体的な計算方法は、図９で説明した通りである。順序管理部１３０は、組合せ管理テーブル１１４に基づいて順序管理テーブル１１５を作成する。
【０１１６】
（ステップＳ１３）順序管理部１３０は、順序管理テーブル１１５に基づいて、次に実行するコード要素の組合せを１つ抽出し、その組合せＩＤをコード生成部１４０に出力する。
【０１１７】
（ステップＳ１４）コード生成部１４０は、順序管理部１３０から取得した組合せＩＤに対応する組合せ内容を組合せ管理テーブル１１４から取得する。コード生成部１４０は当該組合せ内容に基づいてテスト用のソースコードを生成し、被検コンパイラ１５１および比較用コンパイラ１５２に入力する。具体的には、コード生成部１４０は組合せ内容に含まれる識別記号に対応するコード要素を、定義ファイル１１１から選択してソースコードを生成する。例えば、組合せ“Ｃ１”であれば、図１２で説明したようにソースコード１１７を生成する。ここで、定義ファイル１１１では、１つのコード要素に複数の文字列が対応することがある。例えば、コード要素“１”（要素ＩＤ“ｅｘｐｒ１”）に対して“ｖ１＝ｖ２”、“ｖ１＝ｖ３”、“ｖ２＝ｖ２”、“ｖ２＝ｖ３”の４つの文字列の何れかを選択可能である。この場合、コード生成部１４０は、何れか１つをランダムに選択してもよい。あるいは、コード要素ごとに選択された履歴を記憶部１１０に保持しておき、前回とは異なるコード要素を選択してソースコードを生成するようにしてもよい。
【０１１８】
（ステップＳ１５）被検コンパイラ１５１は、最適化オン／オフの２つの方法でソースコードをコンパイルし、検証部１６０にコンパイル結果を出力する。被検コンパイラ１５１は、コンパイルが成功していれば記憶部１１０の所定のディレクトリに、生成された目的コードを格納する。比較用コンパイラ１５２は、ソースコードをコンパイルし、検証部１６０にコンパイル結果を出力する。比較用コンパイラ１５２も、コンパイルが成功していれば、記憶部１１０の所定のディレクトリに、生成された目的コードを格納するようにしてもよい。
【０１１９】
（ステップＳ１６）検証部１６０は、被検コンパイラ１５１および比較用コンパイラ１５２のコンパイル結果と、コンパイル成否基準テーブル１１６とに基づいて、当該ソースコードにつき以降のフェーズのテストを続行するか否かを判定する。続行する場合、処理をステップＳ１７に進める。続行しない場合（すなわち、スキップする場合）、処理をステップＳ１９に進める。コンパイル成否基準テーブル１１６の例では、被検コンパイラ１５１が最適化オン／オフの両方でコンパイル成功であれば、“続行”であり、何れか一方でコンパイル失敗であれば“スキップ”である。
【０１２０】
（ステップＳ１７）検証部１６０は、最適化オン／オフの２種類の方法で被検コンパイラ１５１により生成された目的コードを実際に実行して、目的コードが正しく生成されたかをテストする。更に、検証部１６０は、目的コードが正しく生成されたか否かの判断結果に基づいて定義ファイル１１１に含まれる各コード要素の優先度補正値を増減させる。詳細は後述する。
【０１２１】
（ステップＳ１８）検証部１６０は、目的コードを実行して行ったテストの結果をテスト結果テーブル１１８に登録する。登録され得る内容は図１３で例示した通りである。そして、処理をステップＳ２０に進める。
【０１２２】
（ステップＳ１９）検証部１６０は、ステップＳ１４で生成されたソースコードについて、コンパイルが失敗した旨をテスト結果テーブル１１８に登録する。
（ステップＳ２０）検証部１６０は、テストの実行回数に１を加算する。ここで、テストの実行回数はステップＳ１１の直前では“０”である。検証部１６０はテスト済の組合せを組合せ管理テーブル１１４から削除する。
【０１２３】
（ステップＳ２１）検証部１６０は、組合せ管理テーブル１１４に登録された全ての組合せについてテスト済であるか否かを判定する。全てテスト済である場合、処理を終了する。未テストの組合せがある場合、処理をステップＳ２２に進める。
【０１２４】
（ステップＳ２２）検証部１６０は、各組合せのテスト順序を変更する。具体的には、ステップＳ１７の処理によって定義ファイル１１１に含まれるコード要素ごとの優先度補正値が変動するので、当該優先度補正値に基づいて、組合せ単位の優先度を再計算し、テスト順序を変更する。詳細は後述する。そして、処理をステップＳ１３に進める。
【０１２５】
このようにして、テスト装置１００は、各ソースコードのテストを実行しながら、実行結果に基づいて、以降にテストするソースコードの順番を変更する。次に、ステップＳ１１に処理を説明する。
【０１２６】
図１５は、第２の実施の形態のコード要素組合せ処理を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
（ステップＳ３１）組合せ生成部１２０は、記憶部１１０に記憶された定義ファイル１１１からコード要素を抽出し、コード要素管理テーブル１１２に登録する。ここで、優先度補正値の初期値は“０”である。本ステップでは、各コード要素の識別記号は未登録の状態である。
【０１２７】
（ステップＳ３２）組合せ生成部１２０は、抽出した各コード要素に識別記号を付与し、コード要素管理テーブル１１２に登録する。前述のように、定義ファイル１１１内に各コード要素の識別記号が指定されていれば、当該識別記号を付与する。一方、定義ファイル１１１内で識別記号が付与されていないコード要素には、当該コード要素を一意に識別するための識別記号を付与する。識別記号は例えば半角一文字が好ましい。コード要素の組合せ管理の容易化のためである。
【０１２８】
（ステップＳ３３）組合せ生成部１２０は、要素区分が“ブロック構造”のコード要素を抽出して、ブロック構造パターンのリストを作成する。“ブロック構造”のコード要素を幾つ抽出するかは、組合せ生成部１２０に予め与えられる。あるいは、定義ファイル１１１で明示して組合せ生成部１２０に指定してもよい。例えば、５個以下であれば、ループなどのブロック構造に係るコード要素を５個以内で選択して、複数のループを（入れ子にせずに）順番に実行するようなパターン、複数のループを入れ子で実行するようなパターンおよびこれら２種類のパターンが混在したパターンなど、ブロック構造の複数のパターンを作成する。当該ブロック構造のパターン（数式などを含まないパターン）をブロック構造パターンと称する。
【０１２９】
（ステップＳ３４）組合せ生成部１２０は、ブロック構造パターンに要素区分“ブロック構造”以外の要素区分のコード要素を追加して、複合パターンを作成する。複合パターンは、全ての要素区分のコード要素を考慮して作成されたコード要素の組合せである。ブロック構造パターン（要素区分“ブロック構造”のコード要素のみを考慮して作成された組合せ）と区別するために複合パターンの用語を用いる。例えば、要素区分“データ構造”のコード要素を１つの変数につき１つ選択して、ブロック構造パターンに追加する。例えば、要素区分“データ構造”のコード要素は、最初のループに入る前に追加される。また、例えば、要素区分“式、ＡＰＩ”のコード要素は、ループ内に挿入される。１つのループ内に幾つ挿入するかは、組合せ生成部１２０に予め与えられる。あるいは、定義ファイル１１１で明示して組合せ生成部１２０に指定してもよい。例えば、５個以下であれば、ループ内に挿入する“式、ＡＰＩ”のコード要素を５個以内で選択して、各ブロック構造パターンに含まれる各ループ内に挿入する。これにより、複数の複合パターンが作成される。
【０１３０】
（ステップＳ３５）組合せ生成部１２０は、複合パターンにおいて、ブロック構造以外のコード要素をマスクしてマスク後パターンを作成する。“マスクする”とは、他の文字（例えば、“ｘ”の文字）に置換することである。要素区分ごとにマスク文字を変えてもよい（例えば、要素区分“式・ＡＰＩ”であれば“ｘ”、要素区分“データ構造”であれば“ｙ”の文字でマスクするなど）。
【０１３１】
（ステップＳ３６）組合せ生成部１２０は、同一のマスク後パターンは１つを残してテスト対象の組合せから除外する。
（ステップＳ３７）組合せ生成部１２０は、組合せ絞込条件リスト１１３に基づいて、マスク後パターンの絞込を更に行う。組合せ絞込条件リスト１１３では、例えば“ｌｏｏｐ  ＜”と“ｌｏｏｐ  （”とを類似のコード要素としている。この場合、パターンの構造が同一で、ループに用いられているコード要素の識別記号が“＜”か“（”、および、“＞”か“）”の違いのみであれば、識別記号“＜”および“＞”を用いている方のマスク後パターンをテスト対象から除外する（具体例は後述する）。また、組合せ絞込条件リスト１１３では、例えば、“ｌｏｏｐ＿ｅｎｄ”の識別記号の直後に要素区分“式、ＡＰＩ”のコード要素がある場合に、当該マスク後パターンをテスト対象から除外するものとしている。この場合、例えば、識別記号“）”に続いて文字“ｘ”が存在するマスク後パターンはテスト対象から除外される（具体例は後述する）。
【０１３２】
（ステップＳ３８）組合せ生成部１２０は、残ったマスク後パターンに対応する複合パターンを組合せ管理テーブル１１４に登録する。要素区分“データ構造”のコード要素については、１つのマスク文字に対して、２種類の識別記号が存在し得る（例えば、１つの変数“ｖ１”につき識別記号“ａ”、“ｂ”が存在する）。このため、残ったマスク後パターンに対応する複合パターンは少なくとも２つ登録されることになる。
【０１３３】
このようにして、組合せ生成部１２０は、テスト対象とするコード要素の組合せを生成し、組合せ管理テーブル１１４に登録する。次に、ステップＳ３３〜Ｓ３７の具体例を説明する。
【０１３４】
図１６は、第２の実施の形態のコード要素の組合せ例を示す図である。図１６では、図１５で説明したステップＳ３３〜Ｓ３７で処理される各パターンリストを例示している。各パターンリストは複数の行を含み、１つの行が１つのパターンに相当する。１つのパターンを各行に便宜的に付した記号（ａ１など）によって指し示すことがある。例えば、ブロック構造パターンａ１というとき、ブロック構造パターンリスト２１０の行“ａ１”のパターン“（＜［］＞）”を示す。
【０１３５】
まず、組合せ生成部１２０は、ブロック構造パターンリスト２１０を作成する（ステップＳ３３）。組合せ生成部１２０は、ブロック構造パターンリスト２１０の各ブロック構造パターンに、他の要素区分のコード要素を追加して複合パターンリスト２２０を作成する（ステップＳ３４）。
【０１３６】
組合せ生成部１２０は、複合パターンリスト２２０にマスク処理を施してマスク後パターンリスト２３０を作成する（ステップＳ３５）。そして、同一のマスク後パターンは１つを残して除外して、マスク後パターンリスト２４０を作成する（ステップＳ３６）。例えば、マスク後パターンリスト２３０においてマスク後パターンｃ２，ｃ３は同一である。よって、例えば、マスク後パターンｃ２を残して、マスク後パターンｃ３を削除する。
【０１３７】
組合せ生成部１２０は、組合せ絞込条件リスト１１３に基づいて、マスク後パターンリスト２４０を更に絞り込み、マスク後パターンリスト２５０を作成する（ステップＳ３７）。例えば、マスク後パターンリスト２４０によれば、マスク後パターンｄ４は“ｘｘｘ［ｘｘ（ｘｘ）］”である。マスク後パターンｄ５は“ｘｘｘ［ｘｘ＜ｘｘ＞］”である。マスク後パターンｄ４，ｄ５はパターンの構造が同一である（ｘの文字の並びとブロック構造を示す記号の並びが一致している）。マスク後パターンｄ４では“（ｘｘ）”と記述されている箇所が、マスク後パターンｄ５では“＜ｘｘ＞”と記述されている点のみが相違している。組合せ絞込条件リスト１１３によれば、これらは類似するものとして取り扱う。この場合、マスク後パターンｄ４を残して、マスク後パターンｄ５を削除する。
【０１３８】
また、例えば、マスク後パターンリスト２４０によれば、マスク後パターンｄ１は“ｘｘｘ（ｘ＜ｘ［ｘ］ｘ＞ｘ）”である。マスク後パターンｄ３は“ｘｘｘ（ｘ＜ｘｘ［ｘ］ｘ＞）”である。組合せ絞込条件リスト１１３によれば、“ｌｏｏｐ＿ｅｎｄ”記号の直後に“式、ＡＰＩ”のコード要素があれば、テスト対象から除外する。“ｌｏｏｐ＿ｅｎｄ”記号とは“）”、“］”、“＞”などである。また、ステップＳ３４の処理によればループ内の文字“ｘ”は“式、ＡＰＩ”である。したがって、マスク後パターンｄ１，ｄ３は絞込条件に該当する。“］ｘ”（角括弧記号の直後の文字“ｘ”）や“＞ｘ”（山形括弧記号の直後の文字“ｘ”）を含むからである。よって、組合せ生成部１２０はマスク後パターンｄ１，ｄ３を削除する。
【０１３９】
このように、組合せ生成部１２０は、重複したテストを排除し、また、最適化のテストにとって有益でない組合せを排除する。これにより、無駄にテストが実行されるのを抑制し、テストの効率化を図れる。なお、ステップＳ３７では類似のパターンを削除することを例示したが、それ以外の方法も考えられる。例えば、第１のパターンと第２のパターンとが類似する場合、何れか一方のパターンのテストを後回し（例えば、最後）にするように制御してもよい。
【０１４０】
次に、図１４のステップＳ１７の処理を説明する。
図１７は、第２の実施の形態の目的コードの実行を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。
【０１４１】
（ステップＳ４１）検証部１６０は、目的コードを実行する。検証部１６０は、１つのソースコードに対して２種類の目的コードを実行する。１つは、被検コンパイラ１５１が最適化オンで生成した目的コードである。もう１つは、例えば被検コンパイラ１５１が最適化オフで生成した目的コードである。
【０１４２】
（ステップＳ４２）検証部１６０は、２種類の目的コードの実行結果に基づいて、最適化オンで生成された目的コードの実行結果が正しいか否かを判定する。正しい場合、処理をステップＳ４３に進める。正しくない場合、処理をステップＳ４５に進める。前述のように、目的コードの実行結果の正否は、例えば２種類の目的コードの実行結果が一致するか否かに基づいて判定できる。一致すれば正しい。不一致であれば不正である。また、最適化オンで生成された目的コードの実行中にエラーが発生することもある。この場合も目的コードの実行結果が不正であると判断する。
【０１４３】
（ステップＳ４３）検証部１６０は、目的コードが連続して正常実行された回数が閾値以上であるか否かを判定する。目的コードが連続して正常実行されるとは、例えば、テスト結果テーブル１１８に連続して“正常実行”が登録されることを意味する。すなわち、“実行結果不一致”や“コンパイル失敗”など“正常実行”以外の内容が記録されると“連続”が途切れることになる。閾値は、例えば、５０回、１００回などと予め検証部１６０に与えられる。例えば、閾値が５０回であるとする。テスト結果テーブル１１８に直前まで連続して４９回“正常実行”が記録されているとき、今回の目的コードの実行結果が正常実行であれば、閾値５０回に達することになる。連続して正常実行された回数が閾値以上である場合、処理をステップＳ４４に進める。閾値よりも小さければ、処理を終了する。
【０１４４】
（ステップＳ４４）検証部１６０は、連続して正常実行した組合せに含まれるコード要素の優先度を下げる。例えば、ステップＳ４３の閾値が５０であり、連続して正常実行した回数が５０回であれば、直近の過去５０回分でテストした組合せに含まれる各コード要素の優先度を下げる。閾値が５０であり、連続して正常実行した回数が５１回であれば、直近の過去５１回分でテストした組合せに含まれる各コード要素の優先度を下げる。例えば、各コード要素につき優先度補正値から１だけ減算する。連続して正常実行した回数に応じて減算する値を変えてもよい。例えば、５０〜５９回連続して正常実行できた場合は１減算し、６０〜６９回連続して正常実行できた場合は２減算するなどのようにしてもよい。検証部１６０は、コード要素管理テーブル１１２の優先度補正値の項目に、各コード要素の当該減算後の優先度補正値を登録する。そして、処理を終了する。
【０１４５】
（ステップＳ４５）検証部１６０は、コード要素を変更したソースコードの作り直しをコード生成部１４０に指示する。コード生成部１４０は、検証部１６０の指示に応じてソースコードを作り直す。例えば、元のソースコードに対して、変数の定義を変更したソースコードを作成する。また、例えば加算の演算を減算の演算に変更したソースコードを作成する。具体的な方法は後述する。
【０１４６】
（ステップＳ４６）コード生成部１４０は、作り直したソースコードを被検コンパイラ１５１に入力する。被検コンパイラ１５１は、最適化オン／オフの両方の方法を用いて、当該ソースコードをコンパイルし、２つの目的コードを生成する。検証部１６０は、２つの目的コードを実行して、結果の正否を検証する。コード要素を変更することで不正な結果となった原因（エラー原因）のコード要素を特定できる可能性がある。例えば、あるコード要素が原因でエラーが生じている場合、そのコード要素を類似の処理を行う別のコード要素に置き換えると、正しい結果が得られることがある。その場合、変更前のコード要素がエラーの原因である可能性が高いと推測できる。したがって、その場合は変更前の当該コード要素をエラー原因と特定する。
【０１４７】
（ステップＳ４７）検証部１６０は、ステップＳ４６の処理により、エラー原因のコード要素を特定できたか否かを判定する。特定できた場合、処理をステップＳ４８に進める。特定できなかった場合、処理をステップＳ４９に進める。
【０１４８】
（ステップＳ４８）検証部１６０は、エラー原因のコード要素を含む組合せをテスト対象から除外する。具体的には、検証部１６０は、組合せ管理テーブル１１４から当該組合せを削除する。例えば、コード要素“４”がエラー原因であると特定された場合、コード要素“４”を含む全ての組合せが削除されることになる。そして、処理を終了する。
【０１４９】
（ステップＳ４９）検証部１６０は、エラーとなった組合せに含まれる各コード要素の優先度を上げる。例えば、各コード要素につき優先度補正値に１だけ加算する。ただし、１以外の他の値を加算してもよい。検証部１６０は、コード要素管理テーブル１１２の優先度補正値の項目に、各コード要素の当該加算後の優先度補正値を登録する。そして、処理を終了する。
【０１５０】
このようにして、検証部１６０は目的コードを実行しながら、その実行結果に応じて各コード要素の優先度補正値を更新する。すなわち、検証部１６０は各コード要素の優先度を調整する。各コード要素の優先度補正値は、ユーザ（例えば、ソフトウェアの開発者）により、任意のタイミングで変更可能としてもよい。
【０１５１】
ステップＳ４８において、エラー原因のコード要素を含む組合せをテスト対象から除外する理由は次の通りである。１つのコード要素がエラー原因として特定されれば、当該１つのコード要素を含む組合せでは、対応する目的コードの実行結果が不正となる可能性が高い。この場合、ソフトウェアの開発者は当該コード要素に係る最適化の処理の見直しに注力すればよい。よって、この場合には当該コード要素を含む組合せをテスト対象から除外して無駄なテストを行わないようにする。これにより、テストの一層の効率化を図れる。
【０１５２】
なお、ステップＳ４８では、同一のコード要素がエラー原因となった回数が所定回数（例えば、２回）に達したときに、当該コード要素を含む組合せをテスト対象から除外するようにしてもよい。例えば、あるコード要素がエラー原因であると最初に特定された場合、ステップＳ４８では当該コード要素を含む組合せの除外を行わない。その代わり、検証部１６０は、当該コード要素がエラー原因となった回数“１”を記憶しておく。そして、その後、他の目的コードをテストする上で当該コード要素が次にエラー原因として特定されたときに、当該コード要素を含む組合せをテスト対象から除外するようにする。同じコード要素が複数回エラー原因と特定されるときは、当該コード要素を含む組合せに対応する目的コードの実行結果が不正となる可能性は非常に高いと考えられるからである。
【０１５３】
また、ステップＳ４８では、当該コード要素を含む組合せをテスト対象から除外する代わりに、エラー原因と特定されたコード要素の優先度を大幅に下げたり、または、当該組合せのテストを後回し（例えば、最後）にしたりしてもよい。例えば、後回しになった（最後に回された）組合せが複数ある場合は、後回しになった組合せ同士の優先度を比べて、更に順番を決定する。また、当該コード要素の優先度を下げることも、当該コード要素の組合せのテストを後回しにするための制御といえる。
【０１５４】
図１８は、第２の実施の形態のコード要素の変更例を示す図である。図１７のステップＳ４５において、コード生成部１４０は例えば次のようにソースコード１１７のコード要素を変更する。図１８（Ａ）は変数の定義を変更する場合を例示している。図１８（Ｂ）は減算を加算に変更する場合を例示している。
【０１５５】
例えば、コード生成部１４０は、４行目の“ｉｎｔｅｇｅｒ＊８  ｖ１”を“ｉｎｔｅｇｅｒ＊４  ｖ１”に変更する。または、１６行目の“ｖ１＝ｖ１−ｖ３”を“ｖ１＝ｖ１＋ｖ３”に変更する。ソースコード１１７の各コード要素について１つずつ順番にコード要素を検索して、１つずつ変更していき、１つのコード要素を変更したら、コンパイルの実行、目的コードの実行の手順を繰り返す。例えば、倍精度の変数を単精度の変更にする（またはその逆）、加算を減算に変更する（またはその逆）、乗算を除算に変更する（またはその逆）などの変更が考えられる。
【０１５６】
次に、図１４のステップＳ２２の処理を説明する。
図１９は、第２の実施の形態のテスト順序変更を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
【０１５７】
（ステップＳ５１）順序管理部１３０は、テストの実行回数が所定値に達したか否かを判定する。テストの実行回数が所定値に達した場合、処理をステップＳ５２に進める。テストの実行回数が所定値よりも小さい場合、処理を終了する。所定値は、例えば１０回、５０回、１００回など、１以上の回数を示す値が順序管理部１３０に予め与えられる。
【０１５８】
（ステップＳ５２）順序管理部１３０は、定義ファイル１１１、コード要素管理テーブル１１２および組合せ管理テーブル１１４に基づいて、組合せ単位の優先度を再計算する。順序管理部１３０は、再計算した優先度を組合せ管理テーブル１１４に登録する。更に、順序管理部１３０は組合せ管理テーブル１１４に基づいて、順序管理テーブル１１５を再作成する。
【０１５９】
（ステップＳ５３）順序管理部１３０は、テストの実行回数を“０”にリセットする。
このようにして、順序管理部１３０はテストの実行回数が所定値に達すると、組合せごとの優先度を再計算する。そして、当該優先度に基づいて、順序管理テーブル１１５を再作成する。これによって、コード要素の組合せをテストする順序が更新される。ステップＳ５１でいう“所定値”は、テストに応じた値を設定可能である。例えば、コード要素の種類が多い場合には、テスト順序を毎回変更すると、テスト順序を変更するための処理コストが増大し得る。そこで、テストを複数回行うたびにテスト順序を変更するよう設定すれば、処理コストの増大を抑えられる。
【０１６０】
ここで、ステップＳ５２において、あるコード要素の組合せについて、組合せ単位の優先度が所定の最低値よりも低くなることがある。その場合には当該コード要素の組合せをテスト対象から除外するように制御してもよい。
【０１６１】
図２０は、第２の実施の形態のテスト順序変更例を示す図である。図２０では、ソースコード１１７ｋ，１１７ｌ，１１７ｐ，１１７ｑ，１１７ｒが例示されている。ソースコード１１７ｋ，１１７ｌ，１１７ｐ，１１７ｑ，１１７ｒは、定義ファイル１１１に基づいてコード生成部１４０により生成されるソースコード１１７のバリエーションである。
【０１６２】
テストの開始当初のテスト順序は次の通りであるとする。ソースコード１１７ｋはＫ番目にテストされる予定である。ソースコード１１７ｌはＬ番目（Ｌ＞Ｋ）にテストされる予定である。ソースコード１１７ｐはＰ番目（Ｐ＞Ｌ）にテストされる予定である。ソースコード１１７ｑはＱ番目（Ｑ＞Ｐ）にテストされる予定である。ソースコード１１７ｒはＲ番目（Ｒ＞Ｑ）にテストされる予定である。
【０１６３】
例えば、第１サイクルは図１９のステップＳ５１でいう所定値分の回数のテストを含んでいる。Ｋ，Ｌ番目のテストは第１サイクルに含まれる。第２サイクルは第１サイクルよりも後に実行されるテスト群を含んでいる。Ｐ，Ｑ，Ｒ番目のテストは第２サイクルに含まれる。
【０１６４】
第１サイクルにおいて、Ｋ番目のテストで目的コードの実行結果が不正であったとする。また、コード要素を変更してテストをやり直してもエラー原因が特定できなかったとする。すると、当該目的コードに対応する組合せに含まれるコード要素について、優先度補正値に１が加算される。同様にＬ番目のテストで目的コードの実行結果が不正であったとする。また、コード要素を変更してテストをやり直してもエラー原因が特定できなかったとする。すると、当該目的コードに対応する組合せに含まれるコード要素について、優先度補正値に１が加算される。
【０１６５】
このように、目的コードの実行結果が不正であるたびに、その目的コードに対応する組合せに含まれるコード要素の優先度が増加し、そのコード要素を含む組合せのテストの優先度が高まる。
【０１６６】
第１サイクルが終了すると、順序管理部１３０はテスト順序を更新する。例えば、ソースコード１１７ｑ，１１７ｒは、第１サイクルでエラーが発生したソースコード１１７ｋ，１１７ｌなどに含まれるコード要素を比較的多く含んでいるとする。そして、ソースコード１１７ｑ，１１７ｒに対応する組合せの優先度が、ソースコード１１７ｐに対応する組合せの優先度よりも大きくなったとする。すると、ソースコード１１７ｑ，１１７ｒをソースコード１１７ｐよりも前に順番を繰り上げて実行する。このようにして、テスト装置１００はテストの実行順序を制御する。
【０１６７】
結果が不正となる可能性の高いソースコードを早い段階でテストすることで、エラーとなる入力のサンプルや各エラーの内容などを早い段階で取得できることになる。このため、ソフトウェアの開発者は、被検コンパイラ１５１のバグに対して早期に対処することができる。このようにして、テスト装置１００はテストを効率的に実行することができる。また、ソフトウェアのデバッグ作業を効率的に支援することができる。
【０１６８】
［第３の実施の形態］
以下、第３の実施の形態を説明する。前述の第２の実施の形態との相違点を主に説明し、同様の事項の説明を省略する。
【０１６９】
第２の実施の形態では、テスト対象のソフトウェアとしてコンパイラを例示した。第３の実施の形態では、他のソフトウェアとしてＤＢＭＳを例示する。具体的には、ＤＢＭＳにおけるＳＱＬの実行テストを行う場合を想定する。ここで、第３の実施の形態のテスト装置のハードウェア例は、図２で説明したテスト装置１００と同様である。第３の実施の形態のテスト装置を、特に断らない限りテスト装置１００と同一の名称・符号を用いて指し示す。
【０１７０】
図２１は、第３の実施の形態のソフトウェア例を示す図である。図２１に示す各ユニットは、例えば、テスト装置１００ａが備えるプロセッサがＲＡＭに記憶されたプログラムを実行することで実現できる。図２１の各ユニットはＡＳＩＣやＦＰＧＡなどによって実現されてもよい。
【０１７１】
テスト装置１００は、記憶部１１０、組合せ生成部１２０、順序管理部１３０、コード生成部１４０、テスト用ソフトウェア１５０および検証部１６０を有する。記憶部１１０、組合せ生成部１２０、順序管理部１３０、コード生成部１４０、テスト用ソフトウェア１５０および検証部１６０の説明は、第２の実施の形態と同様である。
【０１７２】
ただし、組合せ生成部１２０および順序管理部１３０は、テスト用のソースコードに代えて、テスト用のＳＱＬを生成するためのコマンドおよびパラメータの組合せを処理する点が第２の実施の形態と異なる。また、コード生成部１４０は、テスト用のソースコードに代えて、テスト用のＳＱＬを生成する点が第２の実施の形態と異なる。
【０１７３】
また、テスト用ソフトウェア１５０は、テスト対象のソフトウェアとして被検ＤＢＭＳ１５１ａを含む点が第２の実施の形態と異なる。テスト用ソフトウェア１５０は、被検ＤＢＭＳ１５１ａによるＳＱＬ実行の正否を確認するためのソフトウェアとして比較用ＤＢＭＳ１５２ａを含む点が第２の実施の形態と異なる。
【０１７４】
更に、検証部１６０は、被検ＤＢＭＳ１５１ａによるＳＱＬの実行結果および比較用ＤＢＭＳ１５２ａによるＳＱＬの実行結果に基づいて、被検ＤＢＭＳ１５１ａによるＳＱＬ実行の正否を検証する点が第２の実施の形態と異なる。例えば、被検ＤＢＭＳ１５１ａによるＳＱＬの実行結果が、比較用ＤＢＭＳ１５２ａによるＳＱＬの実行結果に一致すれば、被検ＤＢＭＳ１５１ａが正しくＳＱＬを実行できたことになる。一方、被検ＤＢＭＳ１５１ａによるＳＱＬの実行結果が、比較用ＤＢＭＳ１５２ａによるＳＱＬの実行結果に一致しなければ、被検ＤＢＭＳ１５１ａが正しくＳＱＬを実行できていないことになる。
【０１７５】
図２２は、第３の実施の形態のデータ例を示す図である。記憶部１１０は、定義ファイル１１１ａ、コード要素管理テーブル１１２ａ、組合せ絞込条件リスト１１３、組合せ管理テーブル１１４、順序管理テーブル１１５、テスト結果テーブル１１８およびテスト用ＳＱＬ１１９を記憶する。
【０１７６】
ここで、組合せ絞込条件リスト１１３、組合せ管理テーブル１１４、順序管理テーブル１１５およびテスト結果テーブル１１８の説明は、第２の実施の形態の絞込条件リスト１１３、組合せ管理テーブル１１４、順序管理テーブルおよびテスト結果テーブル１１８と同様である。ただし、組合せ絞込条件リスト１１３には、ＳＱＬの実行テストを考慮した絞込条件が予め登録される。また、テスト結果テーブル１１８には、ＳＱＬの実行正否などのテスト結果が検証部１６０により登録される。
【０１７７】
定義ファイル１１１ａは、ＳＱＬを生成するためのコマンドやパラメータなどを示す文字列を定義したデータである。以下の説明では、ＳＱＬを生成するためのコマンドやパラメータなどを示す文字列をコード要素と称することがある。ＳＱＬもＤＢＭＳに実行させたい命令を記述したコードと呼べるからである。各コード要素について定義可能な内容は第２の実施の形態の定義ファイル１１１と同様である。例えば、定義ファイル１１１ａでもコード要素ごとに優先度を定義できる。
【０１７８】
コード要素管理テーブル１１２ａは、定義ファイル１１１ａに定義されたコード要素およびコード要素ごとの優先度を管理するためのデータである。各コード要素は、第２の実施の形態と同様に、識別記号に対応付けられる。
【０１７９】
テスト用ＳＱＬ１１９は、コード生成部１４０により生成されたテスト用のＳＱＬ（テストデータの一例）である。テスト用ＳＱＬ１１９は、１つの定義ファイル１１１ａに対して複数のバリエーションが生成され得る。
【０１８０】
図２３は、第３の実施の形態の定義ファイルの例を示す図である。以下、定義ファイル１１１ａに便宜的に付した行番号を用いて説明する。定義ファイル１１１ａの記述ルールは、図５で説明した定義ファイル１１１ａの記述ルールと同様である。ただし、定義ファイル１１１ａでは要素集合の概念がない。このため、行頭に“：”が記述された行は存在しない。定義ファイル１１１ａで指定されるのは、コマンドとコマンドの実行に用いる引数である。
【０１８１】
例えば、１行目の記述“＊  ｃｏｍｍａｎｄ１，１００”は２行目のコード要素“ｓｅｌｅｃｔ  ［ｒｏｗ１］  ｆｒｏｍ  ［ｔａｂｌｅ１］  ［ｗｈｅｒｅ１｜ｗｈｅｒｅ２｜・・・］”の属性を定義している。具体的には、要素ＩＤ“ｃｏｍｍａｎｄ１”、優先度“１００”が付与されていることを示す。当該コード要素のうち“ｓｅｌｅｃｔ・・・ｆｒｏｍ・・・”は、ＳＱＬにおけるｓｅｌｅｃｔコマンドの１つの構文を示すものである。
【０１８２】
それ以外の“［”および“］”で囲われた箇所（“［ｒｏｗ１］”など）は、ｓｅｌｅｃｔコマンドで用いる列名、テーブル名、条件文、副問合せ文などを複数の選択肢から選択して挿入し得ることを示す。例えば、“［ｒｏｗ１］”であれば、１６行目に要素ＩＤ“ｒｏｗ１”に対応するコード要素“［ＩＤ｜ＮＡＭＥ｜・・・］”が記述されている（“ｒｏｗ１”の要素ＩＤは１５行目で付与されている）。これは、“［ｒｏｗ１］”として、“ＩＤ”、“ＮＡＭＥ”、・・・の何れかの列名を選択して挿入し得ることを示している。
【０１８３】
２行目の“［ｔａｂｌｅ１］”、“［ｗｈｅｒｅ１｜ｗｈｅｒｅ２｜・・・］”などの記述も同様の意味である。ただし、“［ｗｈｅｒｅ１｜ｗｈｅｒｅ２｜・・・］”の記述は、“［ｗｈｅｒｅ１］”、“［ｗｈｅｒｅ２］”、・・・の何れかを選択することを意味する。“［ｗｈｅｒｅ１］”について、要素ＩＤ“ｗｈｅｒｅ１”のコード要素が２０行目に定義されている。“ｗｈｅｒｅ１”について複数の選択肢が存在することもある。その場合、コード要素“ｃｏｍｍａｎｄ１”において、“［ｗｈｅｒｅ１］”が選択されたとき、“ｗｈｅｒｅ１”の複数の選択肢の中の何れかが更に選択されることになる。
【０１８４】
ｉｎｓｅｒｔコマンドやｕｐｄａｔｅコマンドなどの他のＳＱＬコマンドについても、ｓｅｌｅｃｔコマンドと同様にして引数として与えるコード要素のバリエーションを定義できる。また、コード要素ごとに優先度を定義できる。
【０１８５】
図２４は、第３の実施の形態のコード要素管理テーブルの例を示す図である。コード要素管理テーブル１１２ａは、コード要素、要素区分、識別記号および優先度補正値の項目を含む。ここで、コード要素、要素区分、識別記号および優先度補正値の項目の説明は、第２の実施の形態のコード要素管理テーブル１１２の各項目の説明と同様である。
【０１８６】
例えば、コード要素管理テーブル１１２ａには、コード要素が“ｃｏｍｍａｎｄ１”、要素区分が“コマンド種別”、識別記号が“！”、優先度補正値が“５”という情報が登録される。これは、要素ＩＤ“ｃｏｍｍａｎｄ１”の要素区分が“コマンド種別”であり、組合せ管理に用いる識別記号が“！”、定義ファイル１１１ａに設定された優先度の補正値が“５”であることを示す。
【０１８７】
このように、ＳＱＬを生成するためのコード要素についても、定義ファイル１１１の場合と同様に管理することができる。そして、以上のような構成により、図１４〜１９で説明した第２の実施の形態と同様の手順を実行し得る。ただし、ソースコードの生成に代えて、ＳＱＬを生成する。また、コンパイル成否の確認に相当するステップ（例えば、図１４のステップＳ１５，Ｓ１６，Ｓ１９や図１７のステップＳ４６のコンパイル処理の部分）を行わなくてよい。更に、目的コードを実行する代わりに、被検ＤＢＭＳ１５１ａおよび比較用ＤＢＭＳ１５２ａにＳＱＬを実行させる。当該実行結果に応じて、テストしたＳＱＬに対応する組合せに含まれるコード要素の優先度補正値を加減する。
【０１８８】
図２５は、第３の実施の形態のテスト順序変更例を示す図である。図２５ではテスト用ＳＱＬ１１９ｋ，１１９ｌ，１１９ｍ，１１９ｎ，１１９ｐ，１１９ｑ，１１９ｒが例示されている。テスト用ＳＱＬ１１９ｋ，１１９ｌ，１１９ｍ，１１９ｎ，１１９ｐ，１１９ｑ，１１９ｒは、定義ファイル１１１ａに基づいてコード生成部１４０により生成されるテスト用ＳＱＬ１１９のバリエーションである。
【０１８９】
テストの開始当初のテスト順序は次の通りであるとする。テスト用ＳＱＬ１１９ｋはＫ番目にテストされる予定である。テスト用ＳＱＬ１１９ｌはＬ番目（Ｌ＞Ｋ）にテストされる予定である。テスト用ＳＱＬ１１９ｍはＭ番目（Ｍ＞Ｌ）にテストされる予定である。テスト用ＳＱＬ１１９ｎはＮ番目（Ｎ＞Ｍ）にテストされる予定である。テスト用ＳＱＬ１１９ｐはＰ番目（Ｐ＞Ｎ）にテストされる予定である。テスト用ＳＱＬ１１９ｑはＱ番目（Ｑ＞Ｐ）にテストされる予定である。テスト用ＳＱＬ１１９ｒはＲ番目（Ｒ＞Ｑ）にテストされる予定である。
【０１９０】
例えば、第１サイクルは所定値分の回数のテストを含んでいる。Ｋ，Ｌ，Ｍ，Ｎ番目のテストは第１サイクルに含まれる。第２サイクルは第１サイクルよりも後に実行されるテスト群を含んでいる。Ｐ，Ｑ，Ｒ番目のテストは第２サイクルに含まれる。
【０１９１】
第１サイクルにおいて、Ｋ，Ｌ，Ｍ，Ｎ番目のテストでＳＱＬの実行結果が不正であったとする。また、何れのテストにおいても、コード要素を変更してテストをやり直してもエラー原因が特定できなかったとする。すると、各テストのＳＱＬに対応する組合せに含まれる各コード要素について、優先度補正値に１が加算される。
【０１９２】
このように、ＳＱＬの実行結果が不正であるたびに、そのＳＱＬに対応する組合せに含まれるコード要素の優先度が増加し、そのコード要素を含む組合せのテストの優先度が高まる。
【０１９３】
第１サイクルが終了すると、順序管理部１３０はテスト順序を更新する。例えば、テスト用ＳＱＬ１１９ｑ，１１９ｒは、第１サイクルでエラーが発生したテスト用ＳＱＬ１１９ｋ，１１９ｌ，１１９ｍ，１１９ｎなどに含まれるコード要素を比較的多く含んでいるとする。そして、テスト用ＳＱＬ１１９ｑ，１１９ｒに対応する組合せの優先度が、テスト用ＳＱＬ１１９ｐに対応する組合せの優先度よりも大きくなったとする。すると、テスト用ＳＱＬ１１９ｑ，１１９ｒをテスト用ＳＱＬ１１９ｐよりも前に順番を繰り上げて実行する。このようにして、テスト装置１００はテストの実行順序を制御する。
【０１９４】
結果が不正となる可能性の高いＳＱＬを早い段階でテストすることで、エラーとなる入力のサンプルや各エラーの内容などを早い段階で多数取得できることになる。そして、ソフトウェアの開発者は、被検ＤＢＭＳ１５１ａのバグに対して早期に対処することができる。このようにして、テスト装置１００はテストを効率的に実行することができる。また、ソフトウェアのデバッグ作業を効率的に支援することができる。
【０１９５】
なお、前述のように、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体（例えば、光ディスク１３、メモリ装置１４およびメモリカード１６など）に記録できる。
【０１９６】
プログラムを流通させる場合、例えば、当該プログラムを記録した可搬記録媒体が提供される。また、プログラムを他のコンピュータの記憶装置に格納しておき、ネットワーク経由でプログラムを配布することもできる。コンピュータは、例えば、可搬記録媒体に記録されたプログラムまたは他のコンピュータから受信したプログラムを、記憶装置に格納し、当該記憶装置からプログラムを読み込んで実行する。ただし、可搬記録媒体から読み込んだプログラムを直接実行してもよく、他のコンピュータからネットワークを介して受信したプログラムを直接実行してもよい。
【０１９７】
また、上記の情報処理の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤなどの電子回路で実現することもできる。
【符号の説明】
【０１９８】
１  情報処理装置
１ａ  記憶部
１ｂ  演算部
Ａ，Ｂ，Ｃ，Ｄ，Ｅ  テストデータ
ＣＳ１，ＣＳ２，ＣＳ３，ＣＳ４，ＣＳ５，ＣＳ６  文字列
【図１】
2014049066.tif 000003
【図２】
2014049066.tif 000004
【図３】
2014049066.tif 000005
【図４】
2014049066.tif 000006
【図５】
2014049066.tif 000007
【図６】
2014049066.tif 000008
【図７】
2014049066.tif 000009
【図８】
2014049066.tif 000010
【図９】
2014049066.tif 000011
【図１０】
2014049066.tif 000012
【図１１】
2014049066.tif 000013
【図１２】
2014049066.tif 000014
【図１３】
2014049066.tif 000015
【図１４】
2014049066.tif 000016
【図１５】
2014049066.tif 000017
【図１６】
2014049066.tif 000018
【図１７】
2014049066.tif 000019
【図１８】
2014049066.tif 000020
【図１９】
2014049066.tif 000021
【図２０】
2014049066.tif 000022
【図２１】
2014049066.tif 000023
【図２２】
2014049066.tif 000024
【図２３】
2014049066.tif 000025
【図２４】
2014049066.tif 000026
【図２５】
2014049066.tif 000027