6945957 ソースコードのテストスイートを生成する方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6945957

(24)【登録日】2021年9月17日

(45)【発行日】2021年10月6日

(54)【発明の名称】ソースコードのテストスイートを生成する方法

(51)【国際特許分類】

   G06F 11/36 20060101AFI20210927BHJP

【ＦＩ】

   G06F11/36 184

【請求項の数】9

【全頁数】14

(21)【出願番号】特願2020-556581(P2020-556581)

(86)(22)【出願日】2019年3月7日

(65)【公表番号】特表2021-509996(P2021-509996A)

(43)【公表日】2021年4月8日

(86)【国際出願番号】JP2019010432

(87)【国際公開番号】WO2019188313

(87)【国際公開日】20191003

【審査請求日】2020年7月1日

(31)【優先権主張番号】18305333.9

(32)【優先日】2018年3月26日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】503163527

【氏名又は名称】ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィ

【氏名又は名称原語表記】ＭＩＴＳＵＢＩＳＨＩ ＥＬＥＣＴＲＩＣ Ｒ＆Ｄ ＣＥＮＴＲＥ ＥＵＲＯＰＥ Ｂ．Ｖ．

(74)【代理人】

【識別番号】100110423

【弁理士】

【氏名又は名称】曾我 道治

(74)【代理人】

【識別番号】100111648

【弁理士】

【氏名又は名称】梶並 順

(74)【代理人】

【識別番号】100122437

【弁理士】

【氏名又は名称】大宅 一宏

(74)【代理人】

【識別番号】100147566

【弁理士】

【氏名又は名称】上田 俊一

(74)【代理人】

【識別番号】100161171

【弁理士】

【氏名又は名称】吉田 潤一郎

(72)【発明者】

【氏名】モントレ、ダヴィド

(72)【発明者】

【氏名】クージノー、ドゥニ

(72)【発明者】

【氏名】ラヴィロニエール、エリック

【審査官】 石川 亮

(56)【参考文献】

【文献】 欧州特許出願公開第３２０８７１６（ＥＰ，Ａ１）

【文献】 米国特許出願公開第２０１３／０３１１９７６（ＵＳ，Ａ１）

【文献】 BLOEM, R et al.，Automating Test-Suite Augmentation，2014 14th International Conference on Quality Software [online]，IEEE，2014年，[retrieved on 2021.07.29], Retrieved from the Internet: <URL: https://ieeexplore.ieee.org/document/6958388>，<DOI: 10.1109/QSIC.2014.40>

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／３６

(57)【特許請求の範囲】

【請求項1】

ソースコードのテストスイートを生成する方法であって、テストケースが、コンピューター手段がアクセス可能なメモリに予備的に記憶され、該方法は、前記コンピューター手段によって実施され、
ａ）前記ソースコードの構造的解析を実施して、完成したソースコードを得ることであって、
前記ソースコードをパースすることと、
テスト目的を定義する注釈を前記ソースコードに加えることと、
前記ソースコードに対応するスタブを生成することと、
を含むことと、
ｂ）テスト目的の各セットを以下の複数のカテゴリ、すなわち、
ｉ／前記メモリに記憶されたテストパラメーターを含むテストケースを入力として用いることによって満たされるテスト目的のセットと、
ｉｉ／いずれのテストケースを用いても満たすことが不可能であるテスト目的のセットと、
ｉｉｉ／少なくとも一時的に満たされていないテスト目的のセットと、
のうちの単一のカテゴリにカテゴリ化することを含む、前記完成したソースコードに対して少なくとも１つの意味解析アルゴリズムを実施することと、
ｃ）カテゴリｉ／の前記テスト目的を満たすテストケースを、テストケースのセットの第１のリストにフィードすることと、
ｄ）満たすことが不可能であり、かつカテゴリｉｉ／に関するテスト目的を、テスト目的の第２のリストにフィードすることと、
ｅ）前記カテゴリｉｉｉ／が空でない場合、
前記テスト目的の少なくとも一部を満たすテストケースを識別することと、
前記テスト目的を満たすテストケースを、テストケースのセットの前記第１のリストにフィードすることと、
カテゴリｉ／に前記テスト目的をカテゴリ化することと、
を含む、カテゴリｉｉｉ／のテスト目的に対応する前記完成したソースコードの部分に対して少なくとも１つの数理最適化アルゴリズムを実施することと、
ｆ）ステップｃにおいて得られ、ステップｅにおいて完成した前記第１のリスト及び前記ソースコードに対応するステップｄにおいて得られた前記第２のリストを含むテストスイートを提供することと、
を含む、方法。

【請求項2】

前記方法は、少なくとも１つの意味解析アルゴリズムを実施するステップｂの前に、前記完成したソースコードの一部に対して少なくとも１つの数理最適化アルゴリズムを実施することを含む以下の補足的予備ステップ、すなわち、
前記テスト目的の少なくとも一部を満たすテストケースを識別することと、
前記テスト目的を満たすテストケースを、テストケースのセットの前記第１のリストにフィードすることと、
カテゴリｉ／に前記テスト目的をカテゴリ化することと、
を含む、ステップを更に含む、請求項１に記載の方法。

【請求項3】

前記ステップｅは、第１の数理最適化アルゴリズムを用いて１回目が実施され、その後、前記ステップｅは、前記第１の数理最適化アルゴリズムとは異なる、第２の数理最適化アルゴリズムを用いて少なくとも２回目が実施される、請求項１又は２に記載の方法。

【請求項4】

前記ステップｅは、少なくとも１つの数理最適化アルゴリズムを用いて少なくとも一度実施され、その後、ステップｆの前に、連続する以下のステップｂ’、ｃ’及びｄ’、すなわち、
ｂ’）前記テスト目的の少なくとも一部をカテゴリｉ／又はｉｉ／にカテゴリ化するように、カテゴリｉｉｉ／のテスト目的に対応する前記完成したソースコードの部分に対して、少なくとも１つの補足的意味解析アルゴリズムを実施することと、
ｃ’）カテゴリｉ／の前記テスト目的を満たすテストケースを、前記テストケースのセットの第１のリストにフィードすることと、
ｄ’）満たすことが不可能であり、かつカテゴリｉｉ／に関するテスト目的を、前記テスト目的の第２のリストにフィードすることと、
が少なくとも一度実施される、請求項１〜３のいずれか１項に記載の方法。

【請求項5】

ステップｄは、満たすことが不可能であり、かつカテゴリｉｉ／に関する各テスト目的に、満たすことが不可能である理由についての情報を関連付けることを更に含み、前記情報は自然言語によるものである、請求項１〜４のいずれか１項に記載の方法。

【請求項6】

少なくとも１つの意味解析アルゴリズムは、以下、すなわち、
「Ｆｒａｍａ−Ｃ」の「値解析」モジュールと、
「ＣＢＭＣ」と、
「Ｆｒａｍａ−Ｃ」の「パスクローラー」モジュールと、
のうちの１つである、請求項１〜５のいずれか１項に記載の方法。

【請求項7】

以下のステップ、すなわち、
ｂ）前記完成したソースコードに対して「Ｆｒａｍａ−Ｃ」の「値解析」モジュールを実施することと、
ｅ）前記カテゴリｉｉｉ／が空でない場合、カテゴリｉｉｉ／のテスト目的に対応する前記完成したソースコードの部分に対して遺伝的アルゴリズムを実施することと、
ｂ’）ＣＢＭＣ解析アルゴリズムを実施することと、
ｂ’’）「Ｆｒａｍａ−Ｃ」のパスクローラー解析アルゴリズムを実施することと、
をこの順序で含む、請求項１〜６のいずれか１項に記載の方法。

【請求項8】

プロセッサによって実行されると、請求項１〜７のいずれか１項に記載の方法を実施する命令を含む、コンピューターソフトウェア。

【請求項9】

ソフトウェアがプロセッサによって実行されると、請求項１〜７のいずれか１項に記載の方法を実施するように前記ソフトウェアが登録される、コンピューター可読非一時的記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ソフトウェア開発の技術分野に関し、より詳細には、ソースコードのテストの分野に関する。

【背景技術】

【0002】

ソフトウェアの従来の開発において、開発時間の大部分は、不具合のリスクを識別し、そのようなリスクのソースを訂正するために、ソフトウェア及びソースコードをテストすることに費やされる。より詳細には、ユニットテストは、単一のプログラムユニット（関数、メソッド、クラス）をテストすることに焦点を置く。そのようなテストをするために、テスト対象の関数及び関数名を含むソースファイルからテストを始める。その後、テスト関数を実行するテストケースを含むテストシートが生成されなければならない。

【0003】

時間、コスト及びヒューマンエラーのリスクを低減するために、関連のテストケースの発見を自動化するように試みるのは当然である。既知の方法のいくつかによって、所与のカバレッジ基準を満たす関連のテストケースを自動的に生成することが可能になる。例えば、「パスクローラー／Ｌｔｅｓｔ」は、関連のテストケースを自動的に生成することで商業的に既知である。しかしながら、そのような方法は、ソースコードが関連のテスト目的を有する注釈を含む場合にのみ機能する。換言すると、テスト対象の関数のソースコードを手作業で注釈をつけるのに人間の作業が依然として必要である。他のソフトウェアにおいて、ソースコードが解析され、入力のリストがユーザーに提示される。ランダム又はヒューリスティックベースの入力を、ソフトウェアによって提案することができる。ソフトウェアのいくつかは、いくつかのテストケースを自動的に提供する。ほとんどの場合、自動的に生成されるテストケースは、完全ではない。ユーザーは、目標カバレッジ基準に合わせるために、関連の入力を手作業でレビューし、埋めなければならない。これらの手作業の動作から、ソフトウェアはテストシートを生成する。

【0004】

或る部分的に自動化したプロセスにおいて、出力は、テストケースが生成されていないソースコードの部分についての情報を含まない。高々、テストされない部分は識別されるが、テストケースを見つけることに失敗した理由については不明である。結果として、冗長でコストがかかる人間の作業は、その後、ソースコードのテストされない部分を識別し、検査し、時には訂正するのに必要である。

【発明の概要】

【0005】

本発明は、その状況を改善する。

【0006】

ソースコードのテストスイートを生成する方法であって、テストケースが、コンピューター手段がアクセス可能なメモリに予備的に記憶され、方法は、上記コンピューター手段によって実施される、方法が提供される。方法は、
ａ）上記ソースコードの構造的解析を実施して、完成したソースコードを得ることであって、
ソースコードをパースすることと、
テスト目的を定義する注釈をソースコードに加えることと、
ソースコードに対応するスタブを生成することと、
を含むことと、
ｂ）テスト目的の各セットを以下の複数のカテゴリ、すなわち、
ｉ／メモリに記憶されたテストパラメーターを含むテストケースを入力として用いることによって満たされるテスト目的のセットと、
ｉｉ／いずれのテストケースを用いても満たすことが不可能であるテスト目的のセットと、
ｉｉｉ／少なくとも一時的に満たされていないテスト目的のセットと、
のうちの単一のカテゴリにカテゴリ化することを含む、上記完成したソースコードに対して少なくとも１つの意味解析アルゴリズムを実施することと、
ｃ）カテゴリｉ／のテスト目的を満たすテストケースを、テストケースのセットの第１のリストにフィードすることと、
ｄ）満たすことが不可能であり、かつカテゴリｉｉ／に関するテスト目的を、テスト目的の第２のリストにフィードすることと、
ｅ）カテゴリｉｉｉ／が空でない場合、
上記テスト目的の少なくとも一部を満たすテストケースを識別することと、
上記テスト目的を満たすテストケースを、テストケースのセットの上記第１のリストにフィードすることと、
カテゴリｉ／に上記テスト目的をカテゴリ化することと、
を含む、カテゴリｉｉｉ／のテスト目的に対応する上記完成したソースコードの部分に対して少なくとも１つの数理最適化アルゴリズムを実施することと、
ｆ）ステップｃにおいて得られ、ステップｅにおいて完成した上記第１のリスト及び上記ソースコードに対応するステップｄにおいて得られた上記第２のリストを含むテストスイートを提供することと、
を含む。

【0007】

そのような方法によって、ソースコードの構造的テストスイートを自動的に生成することが可能になる。結果として、ソースコードの最初の部分を自動的に検査し、認証することができる。（もし存在する場合）ソースコードの残りの部分は、テストできない状態にある理由を説明する（人間が理解可能な）メッセージに関連付けられる。結果として、ソースコードのテストできない部分及びテスト可能な部分を区別するために人間の作業は必要ではなくなる。意味解析及び数理最適化アルゴリズムの特定の連続する組合せによって、或るテストを確立できないことが（数学的に）証明されるソースコードの部分を速く識別することが可能になる。結果として、時間及び計算リソースの一部が保存される（不可能な解を探すのに消費されない）。方法の全般的な効率は、既知の方法に対して高められるとともに、全体的に自動化される。テストの完全性の割合が既知である。いくつかの場合、自動化した結果は、既知の方法によって得られる結果と同等だが、結果を得るのに消費される時間及び計算リソースは、低減される。

【0008】

別の態様において、本出願人は、プロセッサによって実行されると、本明細書において規定される方法を実施する命令を含むコンピューターソフトウェアを提案する。別の態様において、本出願人は、ソフトウェアがプロセッサによって実行されると、本明細書において規定される方法を実施するようにソフトウェアが登録される、コンピューター可読非一時的記録媒体を提案する。

【0009】

方法は、別々に、又は互いに組み合わせて以下の特徴を任意で含むことができる。

【0010】

方法は、少なくとも１つの意味解析アルゴリズムを実施するステップｂの前に、上記完成したソースコードの一部に対して少なくとも１つの数理最適化アルゴリズムを実施することを含む以下の補足的予備ステップ、すなわち、
上記テスト目的の少なくとも一部を満たすテストケースを識別することと、
上記テスト目的を満たすテストケースを、テストケースのセットの上記第１のリストにフィードすることと、
カテゴリｉ／に上記テスト目的をカテゴリ化することと、
を含む、ステップを更に含む。これによって、数理最適化を実施する前であっても、少なくともいくつかのソースコードのいくつかのテストケースを初期的に識別することが可能になる。

【0011】

ステップｅは、第１の数理最適化アルゴリズムを用いて１回目が実施され、その後、ステップｅは、第１の数理最適化アルゴリズムとは異なる、第２の数理最適化アルゴリズムを用いて少なくとも２回目が実施される。これによって、方法にいくつかの数理最適化アルゴリズム（又は最適解探索）を加えることによって、同じソースコードの異なるタイプのテストケースを識別する完全性を高め、テストスイートの完全性のレベルを選択することが可能になる。

【0012】

ステップｅは、少なくとも１つの数理最適化アルゴリズムを用いて少なくとも一度実施され、その後、ステップｆの前に、連続する以下のステップｂ’、ｃ’及びｄ’、すなわち、
ｂ’）上記テスト目的の少なくとも一部をカテゴリｉ／又はｉｉ／にカテゴリ化するように、カテゴリｉｉｉ／のテスト目的に対応する上記完成したソースコードの部分に対して、少なくとも１つの補足的意味解析アルゴリズムを実施することと、
ｃ’）カテゴリｉ／のテスト目的を満たすテストケースを、テストケースのセットの上記第１のリストにフィードすることと、
ｄ’）満たすことが不可能であり、かつカテゴリｉｉ／に関するテスト目的を、テスト目的の上記第２のリストにフィードすることと、
が少なくとも一度実施される。これによって、例えば、ソースコードのバージョンが最終又はほぼ最終である場合にのみ、任意でテストスイートの完全性を高めることが可能になる。

【0013】

ステップｄは、満たすことが不可能であり、かつカテゴリｉｉ／に関する各テスト目的に、満たすことが不可能である理由についての情報を関連付けることを更に含み、上記情報は自然言語によるものである。これによって、オペレーターが任意の異常事態を速く識別し、可能であれば訂正することが可能になる。

【0014】

少なくとも１つの意味解析アルゴリズムは、以下、すなわち、
「Ｆｒａｍａ−Ｃ」の「値解析」モジュールと、
「ＣＢＭＣ」と、
「Ｆｒａｍａ−Ｃ」の「パスクローラー」モジュールと、
のうちの１つである。これらの意味解析アルゴリズムは、本出願人によってテストされたソースコードの例に対して、明確に良い結果を示している。

【0015】

方法は、以下のステップ、すなわち、
ｂ）上記完成したソースコードに対して「Ｆｒａｍａ−Ｃ」の「値解析」モジュールを実施することと、
ｅ）カテゴリｉｉｉ／が空でない場合、カテゴリｉｉｉ／のテスト目的に対応する上記完成したソースコードの部分に対して遺伝的アルゴリズムを実施することと、
ｂ’）ＣＢＭＣ解析アルゴリズムを実施することと、
ｂ’’）「Ｆｒａｍａ−Ｃ」のパスクローラー解析アルゴリズムを実施することと、
をこの順序で含む。アルゴリズムのこの特定の組合せは、本出願人によってテストされたソースコードの例に対して、明確に良い結果を示している。

【0016】

他の特徴、詳細及び利点について、以下の詳細な説明においてかつ図に示す。

【図面の簡単な説明】

【0017】

【図1】本発明による方法を実施する、本発明によるシステムの概略図である。

【図2】本発明による方法の概略図である。

【図3】本発明による方法の一実施形態の図である。

【図4】テストすべき元のソースコードの一部の代表例の図である。

【図5】注釈が加えられた後の図４のソースコードの一部の図である。

【図6】ソースコードにおけるスタブの生成の一例の図である。

【発明を実施するための形態】

【0018】

図及び以下の詳細な説明は、本質的に、いくつかの厳密な要素を含む。それらは、本発明の理解を促進するために、また、必要な場合は本発明を定義するために使用することができる。

【0019】

以下において、厳密な表現が用いられる。したがって、いくつかの定義が以下に与えられる。すなわち、
−「ｆ」がテストすべきソースコードの（或る言語における）テスト対象の関数である場合、「テスト目的」は、関数ｆの特定の命令文ｓとブール式Ｆとの組合せである；
−ｆに関する「テストパラメーターのセット」は、ｆの全ての入力パラメーターに割り当てられるとともに、全てのグローバル変数ｆがアクセスすることができる値のセットである；
−ｆを実行する際、テストパラメーターのセットを用いて、命令文ｓが達成され、式Ｆが命令文ｓのエントリポイントにおいて（すなわち、ｓの実行の直前で）真である場合、かつその場合に限り、「テストパラメーターのセットは、テスト目的（ｓ、Ｆ）を満たす」とみなされる；
−そのテスト目的を満たすテストパラメーターのセットが存在しない場合、かつその場合に限り、「テスト目的は（満たすことが）不可能である」とみなされる；
−ｆに関する「テストスイート（test suite）」は、ｆのパラメーターのセットの組である；
−各テスト目的が不可能であるか、又はテストスイートに属するテストパラメーターのセットによって満たされる場合、「テストスイートは、テスト目的のセットを満たす」；
−「（構造的）カバレッジ基準」は、或る関数のテスト目的のセットを構文的に定義する。テストスイートが、或る関数に関する（それぞれ、或るプログラムに関する）カバレッジ基準によって定義される全てのテスト目的を満たす場合、その関数に関する（それぞれ、そのプログラムに関する）カバレッジ基準を満たすとみなされる；
−関数の「スタブ」「ｇ」は、同じタイプのシグネチャを有する関数である；
−「テストケース」は、テストパラメーターのセット、及びそのテストパラメーターを用いてテスト対象の関数を実行するのに必要な全ての要素にある。構造的ユニットテストにおいて、ｆのテストケースは、テストパラメーター、及びｆにおいて呼び出される全ての関数のスタブからなる。

【0020】

本発明による方法を実施するように計画されるコンピューターシステムは、図１に示される。そのようなシステムは、少なくとも１つのプロセッサ等のコンピューター手段３と、コンピューター手段３がアクセス可能なメモリ５とを備える。メモリ５において、テストすべきソースコード１が登録される。いくつかの実施形態において、いくつかのテストパラメーターは、メモリ５に前もって登録することができる。ソースコードに１回目のテストが行われ、次に、修正された後に２回目にテストされる状況において、１回目において確立されたテストケースを、メモリ５において更に登録することができる。換言すると、或るテストケースは、初期的に記憶することができ、他のテストケースは、徐々に登録することができる。本発明による方法の実行の後、完成したソースコード１’が、テストケーススイート１１、２１と関連付けられて提供される。完成したソースコード１’は、方法の開始時に提供された元のソースコード１に関して自動的に加えられた注釈を含む。

【0021】

本発明による方法１００が、図２に示される。メモリ５は、テストケースの第１のリスト１１を含む。方法１００の開始時、第１のリスト１１は空である。第１のリスト１１は、方法１００の実施中、テストケースを徐々にフィードされる。メモリ５は、満たすことが不可能であるソースコード１に関するテスト目的の第２のリスト２１を含む。方法の開始時、第２のリスト２１は空である。第２のリスト２１は、方法１００の実施中、徐々にフィードされる。方法１００は、第１のリスト１１及び第２のリスト２１に徐々に登録されるとともに、ソースコード１に関連付けられるデータの形式の構造的テストスイートを生成する。テストすべきソースコード１は、方法１００の入力である。完成したソースコード１’並びに第１のリスト１１及び第２のリスト２１は、方法１００の出力である。

【0022】

方法は、ステップ（「ａ」で参照される）を含む。ステップａは、ソースコード１の構造解析の実施１０１を含む。構造解析は、以下、すなわち、
−ソースコード１をパースすること、
−テスト目的を定義する注釈をソースコード１に加えること、
−ソースコード１へのスタブを生成すること、
を含む。

【0023】

一例として、図４及び図５の比較によって、注釈（図５において「//」で始まる行）の形式でいかにテスト目的をソースコード１に加えることができるのかをソフトウェア開発の当業者が理解することが可能になる。換言すると、図４は、テストすべき元のソースコード１の一部の一例であり、一方で、図５は、ステップａが実施された後、注釈を含む完成したソースコード１’の対応する部分である。図４において、５１で参照される行は、テストすべき関数「ｆ（ａ，ｂ）」を含む。５３で参照される行は、テストすべき関数「ｆ（ａ，ｂ）」において呼び出された関数「ｇ（ａ）」を含む。図５において、注釈の行は、所与のカバレッジ基準によるテスト目的を含む。容易に理解することができるように、５５で参照される行は、不可能なテスト目的を含む。そのようなテスト目的の処理は、以下に記載する。

【0024】

図示の例において、カバレッジ基準は、単純な制限を含む。すなわち、パラメーター「ａ」の場合、以下の値、すなわちｋ−１、ｋ、ｋ＋１、「ａ」の最小値及び最大値がテストされ、ｋは、テストされる関数の制限条件と等しい（図４及び図５の例における１０及び１２と等しい）定数である。種々の実施形態において、より洗練された基準を含む他の基準を実施することができる。例えば、ＭＣ／ＤＣカバレッジ（「ＭＣ／ＤＣ」は「改良条件／判定カバレッジ（Modified Condition/Decision Coverage）」を表す）を用いることができ、それは通常、航空電子工学ソフトウェア等の高性能技術分野において用いられる。

【0025】

そのような注釈をソースコード１に加えることは、自動である（人間の介入なしでコンピューター手段３によって行われる）。

【0026】

図６は、スタブの生成を示している。すなわち、呼び出された関数ｇ（ａ）の結果は、関数「ｆ（ａ，ｂ）」のテスト中、値「１」によって置き換えられる。換言すると、ユニットテストを実行するのに必要な呼び出される関数は、ダミー関数によって置き換えることができる。各スタブの関数タイプシグネチャを生成するだけでなく、関数のボディも生成する。したがって、人間の介入なしでスタブをコンパイルすることができる。例えば以下の２種類のスタブを生成することができる。
−製造中のソフトウェアをテストするためのスタブ。スタブは、スタブと組み合わされたテスト対象の関数が全ての参照されるシンボルを定義するように生成される；
−テスト目的を満たすテストパラメーターを見つけるのに用いられる、数理最適化又は意味解析アルゴリズムの各タイプに特有のスタブ。

【0027】

いくつかの実施形態において、ソースコード１の意味論的形式解析によって、例えば、疑似定数を見つける、及び／又は、方法１００の以下の段階の入力を準備することが更に可能になる。「疑似定数」という用語は、ここでは、ソースコードの任意の可能な実行について求めることができる異なる値の小さいセットを有することができる変数を意味する。

【0028】

通常、既知のプロセスにおいて、スタブ生成の動作は、手作業である（人間によってなされる）。スタブ生成の動作は、テストプロセスの重要な部分となる。統合テストの場合（ユニットテストとは反対に）、スタブは、テスト対象の関数の呼び出しツリーの任意の深さで生成することができる。スタブ生成は、ユニットテスト及び統合テストの双方に適用される。

【0029】

ソースコード１に注釈を加えること及びスタブを生成することは、上記ソースコード１をパースすることを含む、ソースコード１の構造的分解によって確実になる。ステップａの最後において、ソースコード１は、注釈及びスタブを含む、完成したソースコード１’になる。完全なマニュアル、パースを手伝うソフトウェアソースを用いるマニュアル及びランダム又はヒューリスティックベースの入力手法のソフトウェアを用いるマニュアルと比較して、記載されているステップａは、カバレッジ基準を満たすことについての保証を与える。例えば、そのような手法は、以下のドキュメント、すなわちＶｅｃｔｏｒＣＡＳＴユーザーマニュアル、Ｐａｒａｓｏｆｔ Ｃ／Ｃ＋＋ｔｅｓｔユーザーマニュアルにおいて定義されている。

【0030】

次に、方法は、「ｂ」で参照されるステップ、すなわち、完成したソースコード１’に対して意味解析アルゴリズム１０２を実施することを含む。意味解析アルゴリズム１０２によって、各テスト目的をカテゴリ化することが可能になる。（既知の）意味解析の例は、以下、すなわち、
−「Ｆｒａｍａ−Ｃ」のモジュール「値解析」；
−「Ｃに関する有界モデル検査（ＣＢＭＣ）」；
−「Ｆｒａｍａ−Ｃ」のモジュール「パスクローラー」、
である。

【0031】

意味解析を実施することによって、テスト目的の各セットを以下の複数のカテゴリのうちの単一のカテゴリにカテゴリ化することが可能になる。
ｉ／メモリ５に記憶されるテストパラメーターを含む、テストケースを入力として用いることによって満たされるテスト目的のセット；
ｉｉ／いずれのテストケースを用いても満たすことが不可能であるテスト目的のセット；
ｉｉｉ／少なくとも一時的に満たされていないテスト目的のセット。

【0032】

換言すると、テスト目的のカテゴリ（又はクラス）は、以下のとおりである。
１．「満たされた」、すなわち、テスト目的を満たすテストパラメーターのセットが識別された。
２．「不可能」、すなわち、テスト目的を満たすことができないと証明された。
３．「未分類」、すなわち、テスト目的が（まだ）処理されていない。

【0033】

意味解析によって、テストケースを見つけることが可能になる。いくつかの実施形態において、テスト目的のセットを満たすテストパラメーターの数は、更に最小化する。したがって、例えば、生成されたテストスイートにおけるテストの期待される出力を埋めるために、生成されたテストスイートに対する人間による任意のレビューが促進される。

【0034】

種々の実施形態において、意味解析の前に遺伝的アルゴリズムを実施することによってカバレッジ基準の一部を満たす自明のテストケースのパラメーターを非常に速く見つけることが可能になり得る。そのように事前に遺伝的アルゴリズムを実施することは、任意選択である。

【0035】

方法は、「ｃ」で参照されるステップ、すなわち、カテゴリｉ／のテスト目的を満たすテストケースを、テストケースのセットの第１のリスト１１にフィードすることを含む。

【0036】

方法は、「ｄ」で参照されるステップ、すなわち、満たすことが不可能であり、かつカテゴリｉｉ／に関するテスト目的を、テスト目的の第２のリスト２１にフィードすることを含む。カテゴリｉｉ／の各テスト目的は、満たすことが不可能である理由についての情報に関連付けられる。この情報は、自然言語で、人間が理解可能であることが好ましい。自然言語によって、上記情報は、ソースコード１の対応する部分を人間が検査するために、読まれたり、用いられたりするように計画されることが理解されなければならない。機械語又はコードの使用は避けることが好ましい。

【0037】

方法１００の以下の記載において、目的は、第３のカテゴリｉｉｉ／「未分類」のテスト目的の数を低減する、可能であればゼロにすることである。

【0038】

方法１００は、「ｅ」で参照されるステップ、すなわち、カテゴリｉｉｉ／が空でない場合、カテゴリｉｉｉ／のテスト目的に対して、少なくとも１つの数理最適化アルゴリズム１０３（「最適解探索アルゴリズム」とも呼ばれ得る）を実施することを含む。ステップｅは、以下、すなわち、
−上記テスト目的の少なくとも一部を満たすテストケース１１３を識別すること、
−上記テスト目的を満たすテストケースを、テストケース１１３のセットの第１のリスト１１にフィードすること、
−カテゴリｉ／に上記テスト目的をカテゴリ化すること、
を含む。

【0039】

（既知の）数理最適化アルゴリズムの一例は、遺伝的アルゴリズムであり、それは数理最適化の人工知能カテゴリに関する一例である。遺伝的アルゴリズムは、比較的明らかではないテストケースのパラメーターを見つける。種々の実施形態において、数理最適化の他の例、すなわち、深層学習（人工知能）、シンプレックスアルゴリズム（最適化アルゴリズム）、焼きなまし法（ヒューリスティックカテゴリ）、貪欲アルゴリズム（ヒューリスティックカテゴリ）を用いることができる。

【0040】

意味解析アルゴリズムによって、テスト目的を満たすことが不可能である（カテゴリｉｉ）と（数学的に）証明するか、及び／又は、テスト目的を満たす（カテゴリｉ）新しいテストパラメーターを見つけることによって、処理されていないテスト目的（カテゴリｉｉｉ）の数を速く、効率的に低減することができる。

【0041】

方法１００において、ステップｂ（少なくとも１つの意味解析）は、例えば「Ｆｒａｍａ−Ｃ」のモジュール「値解析」を用いることによって、ステップｅ（少なくとも１つの数理最適化）の前に実施される。したがって、数理最適化が、満たすことが不可能なテスト目的（カテゴリｉｉ）に対する数理最適化を避けることによって実施される場合、リソース（コンピューター手段３及び時間）は保存される。

【0042】

方法１００は、「ｆ」で参照されるステップ、すなわち、
−ステップｃにおいて得られた第１のリスト１１のテストケース、及び、
−満たすことが不可能であり、ステップｄにおいて得られた第２のリスト２１の不可能である理由についての情報に関連付けられるテスト目的、
を含むテストスイートを提供することを含む。いくつかの実施形態において、ステップｆは、完成したソースコード１’を提供することを更に含む。

【0043】

テストスイートは、ＣＳＶファイル（カンマ区切り値）の形式を有することができる。Ｃソースは、例えば、商用テストソフトウェア「カバレッジマスターｗｉｎＡＭＳ」を用いて単体テストを実行するスタブとともにコンパイルすることができる。

【0044】

いくつかの実施形態において、ソースコード１の単一の意味解析が実施される（ステップｂ）。種々の実施形態において、少なくとも１つの補足的（完全）意味解析は、数理最適化アルゴリズムの実施の後（ステップｅの後）、実施することができる（ステップｂ’）。そのような補足的ステップは、より多くのリソース（時間）を消費するが、残りのテストケースのパラメーター又は解の欠如を示すことができる。換言すると、そのような任意選択及び補足的意味解析は、カテゴリｉｉｉ／において依然として分類することができる任意の客観テストを処理するために、好ましくはステップｅの後に実施することができる。

【0045】

いくつかの実施形態において、第１の意味解析アルゴリズム１０２は、第１のリスト１１（ステップｃ）及び第２のリスト２１（ステップｄ）にフィードするために実施され（ステップｂ）、次に、少なくとも１つの数理最適化アルゴリズム１０３（ステップｅ）を実施した後、第１の意味解析アルゴリズムとは異なる第２の意味解析アルゴリズムが実施される（ステップｂ’）。これによって、それぞれステップｃ’及びｄ’において、第１のリスト１１にいくつかのテストケース１１９を、及び、第２のリスト２１にいくつかの不可能なテスト目的を再びフィードすることが可能になる。

【0046】

いくつかの実施形態において、補足的数理最適化アルゴリズム１０５、１０７が実施される。例えば、遺伝的アルゴリズムの実施は、入力をミックスするように、解を改善し、テストサンプルのより小さいセットを得る一方で、同じテスト目的を網羅することができる。換言すると、ステップｅは、第１の数理最適化アルゴリズム１０３を用いて１回目を実施することができ、その後、ステップｅは、第１の数理最適化アルゴリズムとは異なる、第２の数理最適化アルゴリズム１０５（及び、任意選択で第３の数理最適化アルゴリズム１０７）を用いて少なくとも２回目が実施される。

【0047】

ステップｆの後、方法１００は、ソースコード１が変更される場合、繰り返すことができる。１回目に生成されたテストスイートは、再利用することができる。「フィンガープリント」機構を用いて、同じソースコード１の２つのバージョンの間で修正されていない部分を識別することができる。これによって、ソースコード１全体に対して、方法が完全に再生されることを避けることが可能になる。

【0048】

図３は、Ｃ言語（Ｃコードの６００００行）におけるソースコード１に対する単体テストの生成に関する実施態様の一例を示している。その実施態様は、
−シンボリック計算に基づく数理最適化アルゴリズム及び「ｅｒｌｔｏｏｌｓ」と呼ばれるソフトウェア上に構築される遺伝的アルゴリズムに関する１つのブロック１０３；
−意味解析、すなわち、Ｆｒａｍａ−Ｃのモジュール「値解析」、ＣＢＭＣ、及び（Ｆｒａｍａ−Ｃの）モジュール「パスクローラー」に関する３つのブロック１０２、１１９、１２１、
を含む。

【0049】

図３は、所与の入力プログラムのセットで得られる結果の一例としても与えられる。Ｃソースの処理は、以下の順序で以下の４つの動作において行われる。
１．Ｆｒａｍａ−Ｃのモジュール「値解析」によって、いくつかのテスト目的を不可能なものとして分類すること；
２．遺伝的アルゴリズムによってテスト目的のテストパラメーターを見つけること。これらの動作１及び２の後、テストスイートの９５％は、１０分以内に構築される。
３．ＣＢＭＣを用いて、テスト目的のより多くのテストパラメーターを見つけ、これによって、合計で３５分後、テストスイートの９７％を構築することが可能になる。
４．テスト目的のより多くのテストパラメーターを見つける、Ｆｒａｍａ−Ｃのモジュール「パスクローラー」を用いて、いくつかのテスト目的を「満たすことが不可能なもの」として分類すること。それによって結果として、テストスイートの９８％が１時間３５分以内に見つけられる。

【0050】

図３の特定の実施形態は、特に良好な結果を示している。上述した例示的な値は、用いられるソースコード１及びコンピューター手段に依存する。方法１００によって、テストスイートの大部分を速く得られる一方で、かなりの時間を費やして完全性を確実にすることが可能であることを本質的に示すように与えられる。換言すると、最終ユーザーは、速い（しかしながら不完全な）テストスイートと保証される完成したテストスイートとの間で容易に選択を行うことができる。

【0051】

既知の方法のいくつかは、特定のコンピューター言語に限定される。例えば、Ｃ言語において、ポインタ関数引数がスカラー又は配列を指すかどうかを構文的に判定することは不可能であり、したがって、追加の手作業の情報が、通常、（既知の情報が用いられる場合）必要となる。方法１００の種々の実施形態において、手作業の補足的注釈は、テスト目的（ステップａ）の自動識別を高めるように、メモリ５に登録されたテストケースに事前に加えることができる。カバレッジ基準のテストケースを生成するのに必要な時間及び労働力が低減される。加えて、方法１００は、高い完全性を与え、すなわち、不可能なテスト目的ごとに、不可能なテスト目的が存在する場合、不可能であることの説明が提供される。人間は、ソースコード１のそのような部分を具体的に検査することができる。これは、ソースコード１の任意の後続の認証プロセスを促進する。例えば、Ｃコードにおける「Ｐａｔｈ ｐｒｅｄｉｃａｔｅｓ」に対応するアサーションを提示し、その後、Ｆｒａｍａ−Ｃの「ＷＰ」モジュールを用いて、それらを検証することができる。

【0052】

方法１００は、プロセッサ等のコンピューター手段３及びメモリ５を備える、コンピューターシステムによって実施されるように記述されている。別の態様では、方法１００は、ソフトウェアが任意のプロセッサによって実行されると、方法１００を実施する命令を含む、コンピューターソフトウェアの形態を有することができる。コンピューターソフトウェアは、コンピューター可読非一時的記録媒体上に記録することができる。

【0053】

本発明は、本明細書において記載した方法、システム、コンピューターソフトウェア及びコンピューター可読非一時的記録媒体に限定されず、それらは単なる例である。本発明は、当業者が本明細書を読む際に想到するあらゆる代替形態を包含する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】