JP7629880B2 - プログラム修正支援システム、プログラム修正支援方法 - Google Patents

Description

本発明は、プログラム修正支援システム、プログラム修正支援方法に関する。

従来から、プログラムの単体テストにおけるデバッグ作業において、不具合を含む箇所を特定し、当該箇所に対する修正パッチを生成する技術がある。このような技術として、例えば、特許文献１がある。特許文献１には、ソフトウェアプログラム内の欠陥箇所を特定し、修復候補に基づき、前記欠陥箇所で、可能な修復を生成し、前記可能な修復をテストするよう第１テストを自動生成し、前記第１テストに基づき、第１テストオラクルのための第１クエリを生成し、前記第１クエリに対する応答を人間から取得し、前記第１クエリ及び該第１クエリに対する前記取得された応答に基づき、人間が提供した第１テストオラクルを生成し、拡張された第１テストを生成するよう、前記人間が提供した第１テストオラクルを前記第１テストに加え、前記拡張された第１テストを含むようテストスイートを増補し、前記増補されたテストスイートを用いて、前記可能な修復をテストする、ことが記載されている。

特開２０１９－２９０１５号公報

上記特許文献１では、テストケースの入力を生成する方法として、引数を並べ替えることしか開示されていない。この方法では、必ずしもパッチ候補の検証に有効なテストケースを生成できないことがある。

例えば、中央値を求める機能ｍｅｄｉａｎ（ｎ１，ｎ２，ｎ３）のテストケースとして、元々「ｍｅｄｉａｎ（２，６，８）の出力が６である」がある場合、新たな入力として、ｍｅｄｉａｎ（８，６，２）やｍｅｄｉａｎ（６，８，２）を生成することができない。また、例えば、元のソースコードにおいて、引数に負の数が入るときに不具合が発生する場合、不具合箇所の特定において見落としが生じてしまう。さらに、生成されたパッチにおいて同様の不具合が発生する場合、パッチ候補の検証で見落としてしまい、不具合が発生するパッチを出力してしまう。

一方で、網羅的（brute-force）またはランダムにテストケースの入力を生成すると、無駄に多くのテストケースが生成され、開発者が出力（期待値）を設定する手間が増えてしまう。

本発明は、パッチ候補の検証に効果的なテストケースを、無駄なテストケースを生成することなく生成することが可能な技術を提供することを目的とする。

本発明にかかるプログラム修正支援システムは、演算部と記憶部とを有したコンピュータにより、プログラムの修正を支援するプログラム修正支援システムであって、前記演算部は、ソースコードを解析し、当該解析により得られた前記ソースコードの入力値の条件と出力とを取得し、前記入力値の条件と出力とについての修正に関する候補を示す修正時情報と、テストコードにより前記ソースコードをテストするテストケースを増やすためのテスト追加基準とに基づいて、前記テストケースを拡充する、ことを特徴とするプログラム修正支援システムとして構成される。

本発明によれば、パッチ候補の検証に効果的なテストケースを、無駄なテストケースを生成することなく生成することができる。

本実施例におけるプログラム修正支援システムのハードウェア構成の一例を示す図である。 図１に示したプログラム修正装置の機能的な構成の一例を示す図である。 ソースコードの一例を示す図である。 テストコードの一例を示す図である。 不具合箇所候補の一例を示す図である。 パッチ候補の一例を示す図である。 テスト追加基準の一例を示す図である。 生成後テストコードの一例を示す図である。 修正結果の一例を示す図である。 本実施例において行われるプログラム修正処理の処理手順を示すフローチャートの一例を示す図である。 図１０に示したＳ１００３において行われるテスト生成処理の処理手順を示すフローチャートの一例を示す図である。

以下、図面を参照して本発明の実施形態を説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。

以下の説明では、「データベース」、「テーブル」、「リスト」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いた場合、これらについてはお互いに置換が可能である。

同一あるいは同様な機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。

また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）および／またはインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であれば良く、特定の処理を行う専用回路（例えばＦＰＧＡ（Field-Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit））を含んでいてもよい。

プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

以下、本実施例にかかるプログラム修正支援システム、プログラム修正支援方法の一実施例の構成について説明する。

図１は、本実施例におけるプログラム修正支援システムのハードウェア構成の一例を示す図である。以下では、プログラム修正支援システムが、ある１つのコンピュータであるプログラム修正装置１００により構成される場合を例示するが、これらの機能の全部または一部が、クラウドのような１または複数のコンピュータに分散して設けられ、ネットワークを介して互いに通信することにより同様の機能を実現してもよい。プログラム修正装置１００を構成する各部が行う具体的な処理については、フローチャートを用いて後述する。
図１に示すようにプログラム修正装置１００は、ＣＰＵ等のプロセッサ１１０と、メモリ等の主記憶装置１２０と、ＨＤＤ(Hard Disk Drive)等の補助記憶装置１３０と、スキャナ、キーボード、マウスといった入力装置１４０と、ディスプレイ等の出力装置１５０と、通信ネットワークに接続するためのＮＩＣ(Network Interface Card)等の通信装置１６０と、を備えた一般的なコンピュータにより実現できる。

図２は、図１に示したプログラム修正装置１００の機能的な構成の一例を示す図である。図２に示すように、本実施例にかかるプログラム修正装置１００は、不具合箇所特定部２１０と、パッチ候補生成部２２０と、テスト生成部２３０と、パッチ候補検証部２４０と、情報記憶部２９０とを有して構成される。また、情報記憶部２９０には、ソースコード２９１と、テストコード２９２と、不具合箇所候補２９３と、パッチ候補２９４と、テスト追加基準２９５と、生成後テストコード２９６と、修正結果２９７とが記憶される。

プログラム修正装置１００に記憶され、あるいは処理に用いられる様々なデータ（例えば、ソースコード２９１、テストコード２９２、不具合箇所候補２９３、パッチ候補２９４、テスト追加基準２９５、生成後テストコード２９６、修正結果２９７）は、プロセッサ１１０が主記憶装置１２０または補助記憶装置１３０から読み出して利用することにより実現可能である。また、プログラム修正装置１００の各機能部（例えば、不具合箇所特定部２１０、パッチ候補生成部２２０、テスト生成部２３０、パッチ候補検証部２４０）は、プロセッサ１１０が補助記憶装置１３０に記憶されている所定のプログラムを主記憶装置１２０にロードして実行することにより実現可能である。

上述した所定のプログラムは、通信装置１６０を介してネットワークから、あるいはＵＳＢ（Universal Serial Bus）等の記憶媒体から、補助外部記憶装置１３０に記憶(ダウンロード)され、それから、主記憶装置１２０上にロードされて、プロセッサ１１０により実行されるようにしてもよいし、主記憶装置１２０上に直接ロードされ、プロセッサ１１０により実行されるようにしてもよい。

不具合箇所特定部２１０は、ソースコード２９１と、ソースコード２９１をテストするためのテストコード２９２とを用いて、ソースコード２９１の不具合箇所の候補を特定する。

パッチ候補生成部２２０は、所定の修正パタンに基づいて、ソースコードの不具合箇所の候補を修正したパッチ候補を生成する。

テスト生成部２３０は、上記ソースコードの不具合箇所の候補または／および上記パッチ候補の検証に関するテスト基準や後述するテスト追加基準に基づいて、前記ソースコードに対するテストケースを生成する。

図３は、ソースコード２９１の一例を示す図である。ソースコード２９１は、不具合を含むコードである。具体的には後述するが、図３では、例えば、ソースコード２９１に、本来であれば「false」が記述されるべきところ、「true」が記述された不具合箇所３０１が含まれていることを示している。

図４は、テストコード２９２の一例を示す図である。テストコード２９２は、ソースコード２９１の不具合箇所を特定するためのコードである。図４では、例えば、数値「５」をソースコード２９１に入力した場合の期待値は「false」であり（test１）、数値「２０」をソースコード２９１に入力した場合の期待値は「false」である（test２）ことを示している。

図５は、不具合箇所候補２９３の一例を示す図である。不具合箇所候補２９３は、ソースコード２９１の含まれる不具合箇所の候補を記憶したテーブルである。図５に示すように、不具合箇所候補２９３は、不具合箇所を識別するためのＩＤと、当該ＩＤで識別される不具合箇所の候補とが対応付けて記憶される。図５では、例えば、ＩＤ「１」で識別される不具合箇所の候補は「２行目」であることを示している。

図６は、パッチ候補２９４の一例を示す図である。パッチ候補２９４は、ソースコード２９１を所定の修正パタンで修正したコードである。図６に示すように、パッチ候補２９４は、パッチの候補を識別するためのＩＤと、当該ＩＤで識別されるパッチの候補とが対応付けて記憶される。図６では、例えば、ＩＤ「１」で識別されるパッチの候補は、ソースコード２９１の２行目の「ｘ＞１」を「ｘ＞＝１」に修正したコードであることを示している。

図７は、テスト追加基準２９５の一例を示す図である。テスト追加基準２９５は、テストケースを追加する基準を定めたテーブルである。図７に示すように、テスト追加基準２９５は、追加する基準を識別するためのＩＤと、当該ＩＤで識別されるテストの追加基準とが対応付けて記憶される。本例では特に例示していないが、追加される前のテスト基準については、従来から知られている様々な方法により定められているものとする。

図７では、例えば、ＩＤ「１」で識別されるテストの追加基準は、「不具合箇所候補のカバレッジを上げる入力値」であることを示している。特許文献１では、テストケースの入力を生成する方法として、引数を並べ替えることが記載されているが、どのような基準でテストを行うのかについては開示されておらず、必ずしも適切にソースコードの不具合をテストすることができない。この例では、「不具合箇所候補のカバレッジを上げる入力値」のほか、「パッチ候補の条件式の境界値」をテスト追加基準として例示する。具体的には後述するが、前者の例では、不具合箇所特定の結果、不具合のある（あるいは可能性の高い）メソッドや命令ブロックに対してテストコードを生成するため、当該箇所のカバレッジ（テストで実行される処理、条件分岐、実行パスの網羅率）が向上することで、パッチ候補の検証精度を向上できる。また、後者の例では、パッチ候補生成の結果、出力されたパッチ候補に基づいてテストコードを生成するため、例えば、境界値を生成することで、パッチ候補の検証精度を向上できる。一例を示すと、ｉｆ（ｘ＞０）をｉｆ（ｘ＞１）に修正すべきところ、パッチ候補としてｉｆ（ｘ≧１）が生成された場合、境界値ｘ＝１を入力とするテストを追加することで、誤ったパッチ候補を落とすことができる。

図８は、生成後テストコード２９６の一例を示す図である。生成後テストコード２９６は、テストコード２９２に、テスト追加基準２９５で定められた基準のテストコードが追加されたコードである。図８に示すように、生成後テストコード２９６は、図４に示したテストコード２９２に含まれるｔｅｓｔ１、ｔｅｓｔ２に、新たにｔｅｓｔ３、ｔｅｓｔ４、ｔｅｓｔ５で示すコードが追加されていることを示している。

図９は、修正結果２９７の一例を示す図である。修正結果２９７は、ソースコード２９１を修正した結果を示すコードである。図９に示すように、修正結果２９７は、図２に示したソースコード２９１を、図６に示したパッチ候補２９４のＩＤ「３」のコードで修正されていることを示している。

図１０は、本実施例において行われるプログラム修正処理の処理手順を示すフローチャートの一例を示す図である。

Ｓ１０１０において、不具合箇所特定部２１０は、図４に示したテストコード２９２を図３に示したソースコード２９１に適用し、ソースコード２９１の不具合箇所を特定する。例えば、不具合箇所特定部２１０は、ソースコード中の各行に対し、不具合を含む可能性の高さを計算し、計算した結果が所定の閾値以上となる行を不具合箇所として特定する。不具合箇所特定部２１０は、特定した不具合箇所を、図５に示した不具合箇所候補２９３として出力する。

Ｓ１０２０において、パッチ候補生成部２２０は、ソースコード２９１において、出力された不具合箇所を、所定の修正パタンにより修正したソースコードを、パッチ候補２９４として出力する。このように、パッチ候補生成部２２０は、不具合を含む可能性の高い行を書き換えることで、テストに通るような修正パッチ案を複数生成する。上記所定の修正パタンは、例えば、不足する文の挿入、インスタンス生成方法の変更、条件式の変更等、修正内容を記述したパタンをあらかじめ定めておけばよい。

Ｓ１０３０において、テスト生成部２３０は、出力されたパッチ候補のそれぞれについて、テスト追加基準２９５に基づいたテストコードを生成する。Ｓ１００３の具体的な処理については、図１１を用いて後述する。

Ｓ１０４０において、パッチ候補検証部２４０は、生成されたテストコードを実行し、あらかじめ定められた各種テストに成功するパッチ候補を、最終的なパッチ案として出力する。

図１１は、図１０に示したＳ１００３において行われるテスト生成処理の処理手順を示すフローチャートの一例を示す図である。

Ｓ１１１０において、テスト生成部２３０は、修正前のソースコード２９１を解析し、入力値の条件と出力値の組を取得する。例えば、テスト生成部２３０は、図３に示したソースコード２９１を解析し、入力条件として、「ｘ＞１」および「ｘ≦１」、それぞれに対応する出力「ｔｒｕｅ」、「ｆａｌｓｅ」を取得する。これらの情報は、記号実行（シンボリック実行）等の技術を用いて実現することができる。

Ｓ１１２０において、テスト生成部２３０は、追加される前のテストコードで実行されていない命令または条件を実行するような入力値と期待値を取得する。期待値は、修正前のソースコードの出力値としてもよい。例えば、図４に示したテストコード２９２では、ソースコード２９１における「ｘ≦１」を満たすテストケースが記載されていない。したがって、テスト生成部２３０は、例えば、当該「ｘ≦１」を満たすテストケースを満たすような「Ｘ＝０」の入力値を取得する。Ｓ１１２０に示したように、テスト生成部２３０は、図７に示したテスト追加基準２９５を読み出し、ＩＤ「１」に対応する「不具合箇所候補のカバレッジを上げる入力値」を取得する。

Ｓ１１３０において、テスト生成部２３０は、パッチ候補のそれぞれを解析し、入力条件の境界値を取得する。当該境界値の取得は、記号実行（シンボリック実行）等の技術を用いて実現することができる。例えば、テスト生成部２３０は、図６に示したＩＤ「１」のパッチ候補について、境界値として「ｘ＝１」を取得する。また、テスト生成部２３０は、ＩＤ「２」、「３」のパッチ候補について、境界値として「ｘ＝１０」を取得する。Ｓ１１３０に示したように、テスト生成部２３０は、図７に示したテスト追加基準２９５を読み出し、ＩＤ「２」に対応する「パッチ候補の条件式の境界値」を取得する。

Ｓ１１４０において、テスト生成部２３０は、取得したテストの入力値を開発者に提示し、正しい期待値を開発者から取得する。例えば、テスト生成部２３０は、出力装置１５０の一例であるディスプレイに、取得した境界値「ｘ＝１」、あるいは「ｘ＝１０」を表示する。また、例えば、テスト生成部２３０は、開発者から、入力装置１４０の一例であるキーボードから入力された期待値「ｔｒｕｅ」あるいは「ｆａｌｓｅ」を取得する。

Ｓ１１５０において、テスト生成部２３０は、Ｓ１１２０、Ｓ１１３０において取得した入力値、およびＳ１１４０において取得した期待値をテストケースとするテストコードを生成する。例えば、テスト生成部２３０は、Ｓ１１２０で取得した入力値「Ｘ＝０」および期待値「ｆａｌｓｅ」を含むコード８０１を、生成後テストコード２９６に追加する。また、テスト生成部２３０は、Ｓ１１３０で取得した入力値「Ｘ＝１」および期待値「ｆａｌｓｅ」を含むコード８０２、および入力値「Ｘ＝１０」および期待値「ｔｒｕｅ」を含むコード８０３を、生成後テストコード２９６に追加する。

このように、本実施例では、演算部（例えば、ＣＰＵ）と記憶部（例えば、メモリ）とを有したコンピュータにより、プログラムの修正を支援するプログラム修正支援システムにおいて、上記演算部は、ソースコード（例えば、ソースコード２９１）を解析し、当該解析により得られた上記ソースコードの入力値の条件と出力（例えば、「ｘ＞１」および「ｔｒｕｅ」、「ｘ≦１」および「ｆａｌｓｅ」の組）とを取得し、上記入力値の条件と出力とについての修正に関する候補を示す修正時情報（例えば、不具合箇所候補２９３、パッチ候補２９４）と、テストコード（例えば、テストコード２９２）により上記ソースコードをテストするテストケースを増やすためのテスト追加基準（例えば、テスト追加基準２９５）とに基づいて、上記テストケースを拡充する。このように、修正時情報とテスト追加基準に基づいたテストケースを拡充することで、パッチ候補検証において，正しくないパッチ候補を高い精度で除外できる。また、修正時情報とテスト追加基準に基づいたテストケースのみを拡充することで、開発者が期待値を設定する手間を削減できる。

また、上記修正時情報には、上記ソースコードの不具合箇所の候補（例えば、不具合箇所候補２９３に示したソースコード２９１の「２行目」）を含み、上記演算部は、上記不具合箇所のカバレッジが増加する入力を含むテストケース（例えば、ソースコード２９１における「ｘ≦１」を満たすテストケース「Ｘ＝０」）を生成し、上記テストケースを含むテストコードを出力する。したがって、パッチ候補検証において、不具合箇所のカバレッジを考慮しつつ、正しくないパッチ候補を高い精度で除外できる。

また、上記修正時情報には、上記ソースコードのパッチ候補（例えば、ソースコード２９１を所定の修正パタンで修正したパッチ候補２９４）を含み、上記演算部は、上記パッチ候補における境界値の入力を含むテストケース（例えば、パッチ候補２９４のＩＤ「１」のパッチ候補についての境界値「ｘ＝１」）を生成し、上記テストケースを含むテストコードを出力する。したがって、パッチ候補検証において、パッチ候補における境界値を考慮しつつ、正しくないパッチ候補を高い精度で除外できる。

また、上記演算部は、テストの入力値（例えば、上記「Ｘ＝０」の入力値）を生成し、生成した入力値に対する期待値を上記プログラム修正支援システムの外部から取得（例えば、開発者が入力した期待値「ｔｒｕｅ」を取得）し、上記入力値と上記期待値を含むテストケースを生成し、上記テストケースを含むテストコードを生成する。したがって、開発者の想定（設計）通りのテストケースを生成でき、その結果、生成されるテストケースの品質を向上させることができる。

なお、本実施例では、取得した境界値を出力装置１５０の一例であるディスプレイに表示し、あるいは入力装置１４０の一例であるキーボードから入力された期待値を取得することとした。しかし、入力装置１４０としてマイクのような音声入力装置や、出力装置１５０としてスピーカのような音声出力装置を有する場合には、当該装置を通じた音声により境界値を出力したり、あるいは期待値の入力を受け付ける等、ユーザが認識可能な他の態様のインタフェースを用いてもよい。

本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化したり、上記実施の形態に開示されている複数の構成要素を適宜組み合わせて実施することができる。

１００ プログラム修正装置
２１０ 不具合箇所特定部
２２０ パッチ候補生成部
２３０ テスト生成部
２４０ パッチ候補検証部
２９０ 情報記憶部
２９１ ソースコード
２９２ テストコード
２９３ 不具合箇所候補
２９４ パッチ候補
２９５ テスト追加基準
２９６ 生成後テストコード
２９７ 修正結果

Claims (6)

1. 演算部と記憶部とを有したコンピュータにより、プログラムの修正を支援するプログラム修正支援システムであって、
   前記演算部は、
   ソースコードを解析し、当該解析により得られた前記ソースコードの入力値の条件と出力とを取得し、
   前記入力値の条件と出力とについての修正に関する候補を示す修正時情報と、テストコードにより前記ソースコードをテストするテストケースを増やすためのテスト追加基準とに基づいて、前記テストケースを拡充する場合において、
   前記修正時情報には、前記ソースコードの不具合箇所の候補を含み、
   前記演算部は、前記不具合箇所のカバレッジが増加する入力として、テストで実行される処理、条件分岐、実行パスの網羅率を向上させる入力を含むテストケースを生成し、前記テストケースを含むテストコードを出力する、
   ことを特徴とするプログラム修正支援システム。
2. 前記修正時情報には、前記ソースコードのパッチ候補を含み、
   前記演算部は、前記パッチ候補における境界値の入力を含むテストケースを生成し、前記テストケースを含むテストコードを出力する、
   ことを特徴とする請求項１に記載のプログラム修正支援システム。
3. 前記演算部は、テストの入力値を生成し、生成した入力値に対する期待値を前記プログラム修正支援システムの外部から取得し、前記入力値と前記期待値を含むテストケースを生成し、前記テストケースを含むテストコードを生成する、
   ことを特徴とする請求項１に記載のプログラム修正支援システム。
4. 演算部と記憶部とを有したコンピュータにより、プログラムの修正を支援するプログラム修正支援システムで行われるプログラム修正支援方法であって、
   ソースコードを解析し、当該解析により得られた前記ソースコードの入力値の条件と出力とを取得し、
   前記入力値の条件と出力とについての修正に関する候補を示す修正時情報と、テストコードにより前記ソースコードをテストするテストケースを増やすためのテスト追加基準とに基づいて、前記テストケースを拡充する場合において、
   前記修正時情報には、前記ソースコードの不具合箇所の候補を含み、
   前記演算部は、前記不具合箇所のカバレッジが増加する入力として、テストで実行される処理、条件分岐、実行パスの網羅率を向上させる入力を含むテストケースを生成し、前記テストケースを含むテストコードを出力する、
   ことを特徴とするプログラム修正支援方法。
5. 前記修正時情報には、前記ソースコードのパッチ候補を含み、
   前記パッチ候補における境界値の入力を含むテストケースを生成し、前記テストケースを含むテストコードを出力する、
   ことを特徴とする請求項４に記載のプログラム修正支援方法。
6. テストの入力値を生成し、生成した入力値に対する期待値を前記プログラム修正支援システムの外部から取得し、前記入力値と前記期待値を含むテストケースを生成し、前記テストケースを含むテストコードを生成する、
   ことを特徴とする請求項４に記載のプログラム修正支援方法。

Images