JP7070195B2 - インタラクティブなソフトウェアプログラムの修復 - Google Patents

Description

本開示は、ソフトウェアプログラムの修復に概して関係がある。

ソフトウェアプログラムは、それらの中にしばしば欠陥（“バグ”と広く呼ばれる。）を有している。その場合に、ソフトウェアプログラムは、意図されたように動作しないことがある。しばしば、自動化された修復システムが、ソフトウェアプログラム内の欠陥を特定及び修正しようとして使用される。

本開示で請求される主題は、上述されたもののような環境でしか動作しない実施形態又は如何なる欠点も解消する実施形態に制限されない。むしろ、この背景は、本開示で記載される実施形態が実施され得る技術分野の一例を説明するためにのみ与えられる。

いくつかの例に従って、１つ以上の自動生成されたテストに加えて、人間が生み出した１つ以上のテストオラクルを用いてソフトウェアプログラムをインタラクティブに修復する方法が、記載される。１つ以上の自動生成されたテストに加えて、人間が生み出した１つ以上のテストオラクルを用いてソフトウェアプログラムをインタラクティブに修復する方法の例は、ソフトウェアプログラム内の欠陥箇所を特定し、修復候補に基づき、前記欠陥箇所で、可能な修復を生成し、該可能な修復をテストするよう第１テストを自動生成し、該第１テストに基づき、第１テストオラクルのための第１クエリを生成することを含んでよい。方法は、前記第１クエリに対する応答を人間から取得し、前記第１クエリ及び該第１クエリに対する前記取得された応答に基づき、人間が提供した第１テストオラクルを生成し、拡張された第１テストを生成するよう前記人間が提供した第１テストオラクルを前記第１テストに加え、前記拡張された第１テストを含むようテストスイートを増補し、該増補されたテストスイートを用いて前記可能な修復をテストすることを更に含んでよい。

実施形態の目的及び利点は、特許請求の範囲で特に指し示されている要素、特徴、及び組み合わせによって少なくとも実現及び達成されるだろう。前述の概要及び以下の詳細な説明はいずれも例として与えられており、説明のためであって、請求される発明の限定ではない。

本開示の前述及び他の特徴は、添付の図面とともに理解される以下の記載及び添付の特許請求の範囲から、より十分に明らかになるだろう。それらの図面が本開示に従ういくつかの実施形態しか表しておらず、従って、その適用範囲の限定と見なされるべきでないとの理解の下、本開示は、添付の図面の使用を通じて、更なる特定及び詳細を用いて記載されることになる。
インタラクティブなソフトウェアプログラム修復に関する環境の例の概要を表す。 ソフトウェアプログラムを修復するよう構成され得る汎用のコンピュータシステムの例の選択されたコンポーネントを表す。 ソフトウェアプログラムをインタラクティブに修復するプロセスを例示するフロー図である。 ソフトウェアプログラムをインタラクティブに修復するプロセスを例示するフロー図である。 前に受け入れられた修復を増補されたテストスイートを用いて再テストするプロセスを例示するフロー図である。

以下の詳細な説明では、本願の一部をなす添付の図面が参照される。図面において、同様の符号は、別段文脈中で示されない限りは、通常は、同様のコンポーネントを特定する。詳細な説明、図面、及び特許請求の範囲で記載される、実例となる実施形態は、限定であるよう意図されていない。本願で提示されている主題の精神及び適用範囲から逸脱することなしに、他の実施形態が利用されてよく、他の変更がなされてよい。概して本明細書中で記載され且つ図に表されている本開示の態様は、多種多様な異なった構成において配置され、置換され、組み合わされ、分離され、且つ設計され得る。それらの全てが明示的に本明細書において考えられている。

本開示は、とりわけ、インタラクティブなソフトウェアプログラム修復に関する方法、装置、システム、デバイス、及び／又はコンピュータプログラム製品に概して引き付けられている。ソフトウェアプログラムは、意図しない様態でソフトウェアプログラムを挙動させることがある欠陥（一般には“バグ”とも呼ばれる。）をしばしば含む。その上、自動修復システム及び技術（例えば、自動プログラム修復）は、欠陥を検出及び修正してソフトウェアプログラムを修復するためにしばしば使用される。自動プログラム修復の目的は、ソフトウェアプログラム内でバグを特定し、その特定されたバグを直す（例えば、パッチをあてる）プロセスを自動化することである。これは、修正された又はパッチをあてられたソフトウェアプログラムの期待される挙動のための素晴らしい基準となり得る修復規格に基づき行われ得る。例えば、修復規格は、テストケースの組（例えば、テストスイート）を含んでよく、テストケースの１つ以上は、修復を受けているソフトウェア（例えば、テストを受けているソフトウェアプログラム）の現在のバグの出るバージョンの下では落第点であることがある。

しかし、テストスイートは、修復規格として不完全であることがある。更に、一般に使用されている自動修復システム及び技術は、単に、元の又は修復されたソフトウェアプログラムが所与のテストケースに合格又は落第するかどうかを確認するために、修復規格を使用していることがある。よって、一般に使用されている自動修復システム及び技術は、修復規格を満足する修復を実現し得る（例えば、修復規格に含まれるテストケースを満足する修復を実現し得る）が、実際には、テストスイートが不完全でありうるので不適当である。

いくつかの実施形態で、修復モジュールは、ソフトウェアプログラム内のバグのための修復（パッチ）を改善するのに適した拡張されたテストケースの発生及び増補されたテストスイートの発生において、人間が提供した（human-provided）テストオラクルを組み込む。修復モジュールは、初期テストスイート（例えば、既存のテストスイート）の実行に基づき、ソフトウェアプログラム内で１つ以上の欠陥及び対応する欠陥位置を特定してよい。初期テストスイートはテストの組を含んでよい。夫々の欠陥位置について、修復モジュールは、修復候補を選択し、修復候補を用いて欠陥位置での可能性がある修復又は変換（例えば、可能性があるパッチ）を構成してよい。修復モジュールは、次いで、可能性がある修復（例えば、可能性があるパッチ）がテストスイート（例えば、テストスイートに含まれているテスト）を通過するかどうかを判定するよう、テストスイートに対して、欠陥位置で可能性がある修復（例えば、可能性があるパッチ）を有しているソフトウェアプログラムを実行してよい。可能性がある修復がテストスイートを通過しない場合には、修復モジュールは、その可能性がある修復を捨て、他の修復候補を選択し、新たに選択された修復候補を用いて欠陥位置で新しい可能性がある修復を構成し、その新しい可能性がある修復をテストスイートを用いてテストしてよい。

可能性がある修復がテストスイートを通過する場合には、修復モジュールは、可能性がある修復をテストするのに適した新しい（例えば、更なる）テストが存在するかどうかを判定してよい。可能性がある修復をテストするのに適したテストがない場合には、修復モジュールは、欠陥の適切な修復（パッチ）として欠陥位置でその可能性がある修復を受け入れてよい。新しいテストがある場合には、修復モジュールは、その新しいテストをテストスイートに含めてよい。いくつかの例において、修復モジュールが新しいテストを生成してよい。修復モジュールは、新しいテストに基づきテストオラクルのためのクエリ（新しいテストの実行に対応するクエリ）を導出又は生成し、テストオラクルのためのクエリを、プログラマ、ソフトウェア開発者、などのような、ソフトウェアプログラミングの知識を持った人間に提示してよい。修復モジュールは、提示されたクエリ及びその提示されたクエリに対する人間の（例えば、人間による）応答に基づき、人間が提供したテストオラクルを生成し、その人間が提供したテストオラクルを新しいテストに加えてよい。このように、新しいテストは、既存のテストスイート（例えば、初期テストスイート）が、増補されたテストスイートを生成するよう、新しいテスト及びそれの人間が提供したテストオラクルにより増補され得るように、拡張されてよい。増補されたテストスイートは、次いで、既存のテストスイートになってよい。修復モジュールは、次いで、増補されたテストスイートを用いて、可能性がある修復をテストしてよい。可能性がある修復が増補されたテストスイートを通過する場合には、修復モジュールは、可能性がある修復を更にテストするのに適した更なる新しいテストが存在するかどうかを判定してよい。他の新しいテストがある場合には、修復モジュールは、対応する人間が提供したテストオラクルにより増補された新しいテストにより既存のテストスイートを増補するよう、上記のプロセスを繰り返してよい。このように、修復モジュールは、不適切な可能性がある修復を取り除くか又は捨てるよう、１つ以上のテスト及びそれらの人間が提供したテストオラクルによりテストスイートを強化してよい。いくつかの実施形態では、修復モジュールは、可能性がある修復を更にテストするための更なるテストをチェックすることなしに、可能性がある修復が増補されたテストスイートを通過すると、その可能性がある修復を適切な修復として受け入れてよい。

可能性がある修復が増補されたテストスイートを通過しない場合には、修復モジュールは、可能性がある修復を不適切な修復として拒絶してよい。すなわち、修復候補は、不適切な修復を生じさせるものとして捨てられてよい。修復モジュールは、新しい修復候補を選択し、新しい修復候補を用いて欠陥位置で新しい可能性がある修復を構成し、新しい可能性がある修復をテストスイートを用いてテストしてよい。同様にして、修復モジュールは、特定された欠陥位置のうちの１つ以上で修復候補のうちの１つ以上を処理してよい。

いくつかの実施形態では、修復モジュールは、欠陥のための更なる又は複数の適切な修復（例えば、複数のパッチ）を生成してよい。すなわち、修復モジュールは、欠陥の適切な修復（パッチ）として、欠陥位置で１つよりも多い可能性がある修復を受け入れてよい。例えば、欠陥位置での適切な修復として、修復候補に基づき、欠陥位置で可能性がある修復を受け入れた後、修復モジュールは、その欠陥位置のための更なる修復候補が存在するかどうかを判定し、そして、更なる修復候補に基づき可能性がある修復を生成し、可能性がある修復を増補されたテストスイートに対してテストして更なる可能性がある修復を欠陥位置で潜在的に受け入れる上記のプロセスを繰り返してよい。

いくつかの実施形態では、修復モジュールは、前に受け入れられた可能性がある修復を取り除くよう（例えば、前の適切な修復が依然として適切な修復であるかどうかを判定するよう）、前に受け入れられた可能性がある修復（前の適切な修復）を増補されたテストスイート（例えば、対応する人間が提供したテストオラクルにより増補された新しいテストケースにより増補されたテストスイート）に対してテストしてよい。すなわち、修復モジュールは、前の適切な修復が増補されたテストスイートを通過するかどうかを判定してよい。例えば、前に受け入れられた可能性がある修復は、増補されたテストスイートにおいて現在含まれている１つ以上のテスト（例えば、人間が提供したテストオラクルにより増補された１つ以上の新たに生成されたテスト）を含んでいなかった前のテストスイートを用いてテストされて、適切な修復として受け入れられている。修復モジュールは、前に受け入れられた可能性がある修復を増補されたテストスイートを用いてテストしてよく、前に受け入れられた可能性がある修復が増補されたテストスイートを通過しない場合には、修復モジュールは、前に受け入れられた可能性がある修復を不適切な修復として捨ててよい。すなわち、前に決定された適切な修復は、もはや、適切な修復と見なされ得ない。前に受け入れられた可能性がある修復が増補されたテストスイートを通過する場合には、修復モジュールは、前に受け入れられた可能性がある修復を適切な修復として再び受け入れてよい。すなわち、前に決定された適切な修復は、増補されたテストスイートに対してテストされた適切な修復として引き続き見なされ得る。

本開示の様々な実施形態が、添付の図面を参照して詳細に記載される。

図１は、本明細書で記載される少なくともいくつかの実施形態に従って配置される、インタラクティブなソフトウェアプログラム修復に関連した、例となる環境１００の概要を表す。環境１００は、人間が提供した１つ以上のテストオラクルを生成するよう修復モジュール１０６と相互作用する人間１０２を含んでよい。人間１０２は、プログラマ、ソフトウェア開発者、などのような、ソフトウェアプログラミングの十分な知識を持った如何なる人であってもよい。修復モジュール１０６は、テストスイート１１２を用いて１つ以上の欠陥について被試験コード（code under test）１０４を解析するよう構成されてよい。修復モジュール１０６は、更に、人間が提供したテストオラクルが加えられている１つ以上の拡張されたテストを含む増補されたテストスイート１０８を出力又は生成するよう構成されてよく、被試験コード１０４内の欠陥に対する可能な修復をテストすることをもたらす。いくつかの実施形態では、修復モジュール１０６は、欠陥を正確に修復する１つ以上のパッチ１１０を出力又は生成するよう構成されてよい。

被試験コード１０４は、例えば、ソフトウェアプログラム、ソフトウェアプログラムのコード、ライブラリ、アプリケーション、スクリプト、若しくは他のロジック、又はプロセッシングデバイスによる実行のための命令のような、電子データを含んでよい。いくつかの実施形態では、被試験コード１０４は、ソフトウェアプログラムの完全なインスタンスを含んでよい。その上、又は代替的に、被試験コード１０４は、ソフトウェアプログラムの部分を含んでよい。被試験コード１０４は、ソフトウェアプログラムのために使用され得る如何なる適切なタイプのコンピュータ言語でも記述されてよい。

修復モジュール１０６は、コンピュータデバイスが被試験コード１０４内の欠陥に対する１つ以上の可能な修復を実行し、人間１０２と相互作用して、人間が提供したテストオラクルを夫々加えられている１つ以上の拡張された新しいテストを含む増補されたテストスイート１０８を生成することを可能にするよう構成されたコード及びルーチンを含んでよい。その上、又は代替的に、修復モジュール１０６は、コンピュータデバイスが増補されたテストスイート１０８を用いて被試験コード１０４内の欠陥に対する可能な修復をテストしてパッチ１１０を生成することを可能にするよう構成されたコード及びルーチンを含んでよい。いくつかの実施形態では、修復モジュール１０６は、プロセッサ、マイクロプロセッサ（例えば、１つ以上の動作を実行するか又はその実行を制御するもの）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は特定用途向け集積回路（ＡＳＩＣ）を含むハードウェアを用いて実装されてよい。いくつかの他の例では、修復モジュール１０６は、ハードウェアとソフトウェアとの組み合わせを用いて実装されてよい。本開示では、修復モジュール１０６によって実行されるものとして記載される動作は、修復モジュール１０６が対応するシステムに実行するよう指示し得る動作を含んでよい。

テストスイート１１２は、被試験コード１０４のためのテストケースとなり得る１つ以上のテスト（例えば、ルーチン、関数、など）を含んでよい。テストスイート１１２は、被試験コード１０４が特定の様態で動くかどうかを判定するよう構成されてよい。テストスイート１１２は、如何なる適切な技術にも従って構成されてよい。

修復モジュール１０６は、テストスイート１１２の１つ以上のテストを被試験コード１０４に対して適用して被試験コード１０４内で１つ以上の欠陥及び対応する欠陥位置を検出又は決定するよう構成されてよい。いくつかの実施形態では、修復モジュール１０６は、テストスイート１１２に含まれている１つ以上のテストを実行するよう構成されてよい。これは、テスト実行を実施するとも呼ばれ得る。通過するテスト実行は、“テスト実行合格”と呼ばれてよく、失敗するテスト実行は、“テスト実行落第”と呼ばれてよい。いくつかの実施形態では、被試験コード１０４の欠陥及び対応する欠陥位置は、１つ以上のテスト実行落第及び１つ以上のテスト実行合格を解析することに基づき特定されてよい。欠陥位置は、対応する欠陥を修復しようと試みるために被試験コード１０４の変更又は変換が行われ得る被試験コード１０４内の位置であってよい。

いくつかの実施形態では、修復モジュール１０６は、被試験コード１０４内の特定された欠陥及び／又は欠陥位置に優先順位をつけるよう構成されてよい。修復モジュール１０６は、次いで、特定の欠陥位置を、その特定の欠陥位置の優先順位に基づき、選択してよい。優先順位付けは、可能な修復動作の実行中に欠陥位置の選択の順序を決定するために使用されてよい。より高い優先順位を有している欠陥位置は、より低い優先順位を有している欠陥位置の選択より前に選択されてよい。例えば、修復モジュール１０６は、異なる欠陥位置の夫々の優先順位を比較してよい。特定の欠陥位置は、残りの欠陥位置の夫々よりも高い優先順位を有することがある。優先順位の比較に基づき、修復モジュール１０６は、より低い優先順位を有している欠陥位置を選択するのではなく、より高い優先順位を有している特定の欠陥位置を選択してよい。

いくつかの実施形態では、修復モジュール１０６は、修復テンプレートに基づき、可能な修復動作のうちの１つ以上を実行するよう構成されてよい。修復テンプレートは、如何なる適切なタイプの命令又はルーチンも含んでよい、命令又はルーチンは、実行される場合に、被試験コード１０４内の欠陥の存在に応答して被試験コード１０４に対して欠陥位置の１つ以上の変更又はそこでの変換を実施するよう構成されてよい。変更は、欠陥位置での被試験コード１０４における変更（changes）を含んでよく、そのような変更は、欠陥を修復するか又は修復するよう試みてよい。

いくつかの実施形態では、修復モジュール１０６は、被試験コード１０４内の欠陥位置を選択し、選択された欠陥位置で可能な修復動作を実行するよう構成されてよい。欠陥位置は、欠陥位置の優先順位付けに基づき選択されてよい。可能な修復動作は、被試験コード１０４内の選択された欠陥に関連し得る修復候補に基づいてよい。可能な修復動作は、可能性がある修復（可能性があるパッチ）として、選択された欠陥位置で修復候補を実装することを含んでよい。修復モジュール１０６は、テストスイート１１２の１つ以上のテストを用いて欠陥位置で可能性がある修復をテストするよう構成されてよい。修復モジュール１０６は、可能性がある修復がテストスイート１１２の中の適用されたテストを通過しない場合には、その可能性がある修復を、欠陥の不適切な修復として捨ててよい。修復モジュール１０６は、可能性がある修復がテストスイート１１２の中の適用されたテストを通過する場合には、可能性がある修復を更にテストするように、１つ以上の新しいテストケースを生成し、それらを、人間が提供したテストオラクルにより増補するよう試みるよう構成されてよい。修復モジュール１０６は、それらの人間が提供したテストオラクルにより増補された新しい自動生成されたテストケースを用いて、可能性がある修復をテストしてよい。修復モジュール１０６は、可能性がある修復が増補された新たに生成されたテストを通過しない場合には、可能性がある修復を、欠陥の不適切な修復として捨て、可能性がある修復が増補された新たに生成されたテストを通過する場合には、可能性がある修復を、欠陥の適切な修復（例えば、パッチ）として受け入れてよい。

いくつかの実施形態では、修復モジュール１０６は、次のように、テストスイート１１２のテストを通過する、被試験コード１０４内の欠陥に対する可能性がある修復をテストするように、１つ以上の新しい又は更なるテスト（例えば、テストスイート１１２内のテストに加えて１つ以上のテスト）を生成及び増強するよう構成されてよい。修復モジュール１０６は、如何なる適切な技術を用いても新しいテストを生成してよい。いくつかの実施形態では、テスト（例えば、新しいテスト）は単体テスト（unit test）であってよい。新しいテストを作ると、修復モジュール１０６は、その新しいテストに基づきテストオラクルのためのクエリを生成してよい。修復モジュール１０６は、次いで、テストオラクルのためのクエリを人間１０２に提示してよい。人間１０２は、テストオラクルのための提示されたクエリに応答又は返答してよい。例えば、テストオラクルのためのクエリは、視覚的な方法、音声、及び／又は同様のもののような、如何なる適切な技術を用いても、提示され且つ応答を受け取ってよい。修復モジュール１０６は、テストオラクルのための提示されたクエリ及び提示されたクエリに対する人間１０２の応答に基づき、人間が提供したテストオラクルを生成してよい。修復モジュール１０６は、人間が提供したテストオラクルを適切なテストにより含め（例えば、付加し）て、拡張されたテストを生成し、その拡張されたテストをテストスイート１１２に付加して、増補されたテストスイート１０８を生成してよい。

例えば、特定された欠陥が被試験コード１０４内にあり、たまたま、３つの整数の中間値を返す関数“int median(int n1,int n2,int n3)”であるとする。修復モジュール１０６は、被試験コード１０４内の欠陥に対応する欠陥位置の可能な修復をテストするよう新しいテスト“median(1,2,3)”を生成してよい。新しいテストについて、修復モジュール１０６は、クエリ“３つの整数１、２及び３の連続において中間値はどれですか？”を生成してよい。修復モジュール１０６は、次いで、クエリを人間１０２に提示してよい。人間１０２は、“２”が中間値であることを指示又は特定することによって、提示されたクエリへの応答を与えてよい。提示されたクエリに対する人間１０２の応答に基づき、修復モジュール１０６は、人間が提供したテストオラクル、例えば、“assert median(1,2,3)==2”を生成してよい。このテストオラクルは、次いで、新しいテストに加えられてよい。新しいテストは、入力1,2,3により関数medianを呼び出し（median(1,2,3)として）、“assert median(1,2,3)==2”において見られるようなオラクルを用いて、返された応答をチェックする。

いくつかの実施形態では、修復モジュール１０６は、新しいテストに基づきテストオラクルのための仮定（hypothesis）を生成するよう構成されてよい。仮定は、新しいテストの結果に関する提案であってよい。先の例では、新しいテスト“median(1,2,3)”について、修復モジュール１０６は、提案“３つの整数１、２及び３の連続において中間値は２ですか？”を生成してよい。修復モジュール１０６は、次いで、提案を人間１０２に提示してよい。人間１０２は、肯定応答（acknowledgement）（例えば、“yes”）を与えることによって、提示された仮定への応答を与えてよい。提示された仮定に対する人間１０２の応答に基づき、修復モジュール１０６は、人間が提供したテストオラクル、例えば、“assert median(1,2,3)==2”を生成してよい。これは、新しいテストを拡張するよう、新しいテストに加えられてよい。それらの又は他の実施形態において、拡張された新しいテストは、増補されたテストスイート１０８を生成するよう、テストスイート１１２に加えられてよい。

いくつかの実施形態では、修復モジュール１０６は、人間が提供したテストオラクルを伴った拡張された新しいテストを含む増補されたテストスイート１０８を用いて、欠陥位置で、可能な修復をテストしてよい。修復モジュール１０６は、可能な修復が増補されたテストスイート１０８を通過することに応答して、可能な修復を適切な修復として受け入れるよう構成されてよい。いくつかの実施形態では、修復モジュール１０６は、被試験コード１０４内の欠陥に対する可能性がある修復をテストするように、人間が提供したテストオラクルを伴った複数の拡張された新しいテストを生成するよう試みるよう構成されてよい。例えば、第１の人間が提供したテストオラクルを伴った第１の拡張された新しいテストを用いて可能な修復をテストした後、修復モジュール１０６は、第２の新しいテストを生成して、可能な修復をテストするよう試みてよい。修復モジュール１０６が第２の新しいテストを生成することができる場合には、修復モジュール１０６は、その第２の新しいテストに基づき第２の人間が提供したテストオラクルを生成し、第２の人間が提供したテストオラクルを第２の新しいテストに加えて、拡張された第２の新しいテストを生成してよい。修復モジュール１０６は、拡張された第２の新しいテストを、増補されたテストスイート１０８に加えるよう構成されてよい。修復モジュール１０６は、次いで、第２の人間が提供したテストオラクルを伴った拡張された第２の新しいテストを含む増補されたテストスイート１０８を用いて、可能な修復をテストしてよい。

選択された欠陥位置を処理し、ことによると、欠陥のための受け入れ可能な修復を見つけられなかった場合には、修復モジュール１０６は、被試験コード１０４内の新しい欠陥位置を選択し、新たに選択された欠陥位置での可能な修復動作を実行するよう構成されてよい。新しい欠陥位置は、欠陥位置の優先順位に基づき選択されてよい。例えば、新しい欠陥位置は、被試験コード１０４内の残りの欠陥位置の中で最も高い優先順位を有している欠陥位置であってよい。可能な修復動作は、被試験コード１０４内の新たに選択された欠陥位置と関連し得る修復候補に基づいてよい。可能な修復動作は、新たに選択された欠陥位置での修復候補を、可能性がある修復（可能なパッチ）として実装することを含んでよい。修復モジュール１０６は、次いで、本明細書で記載されるのと同様にして、新たに選択された欠陥位置を処理してよい。

いくつかの実施形態では、修復モジュール１０６は、欠陥のための複数のパッチを生成するよう構成されてよい。すなわち、修復モジュールは、欠陥位置での１つ以上の可能な修復を欠陥の適切な修復（パッチ）として受け入れてよい。欠陥位置での適切な修復として修復候補に基づきその欠陥位置での可能な修復を受け入れた後、修復モジュール１０６は、その欠陥位置のための更なる修復候補が存在するかどうかを判定するよう構成されてよい。更なる修復候補が存在する場合には、修復モジュール１０６は、更なる修復候補に基づき欠陥位置での可能な修復を生成し、その可能な修復を増補されたテストスイートに対してテストして、場合により、欠陥位置での複数の可能な修復を欠陥の複数のパッチとして受け入れる上記のプロセスを繰り返すよう構成されてよい。修復モジュール１０６は、欠陥位置のための如何なる追加の修復候補（例えば、第３、第４、など）も処理するよう構成されてよい。

いくつかの実施形態では、修復モジュール１０６は、欠陥のための１つ以上のパッチをパッチ１１０に含めるよう構成されてよい。いくつかの実施形態では、修復モジュール１０６は、１つ以上の更なる欠陥のための１つ以上のパッチをパッチ１１０に含めるよう構成されてよい。すなわち、パッチ１１０は、被試験コード１０４内の複数の欠陥のための１つ以上のパッチを含んでよい。

いくつかの実施形態では、修復モジュール１０６は、前に受け入れられた修復（前に受け入れられた可能な修復）を増補されたテストスイート１０８に対してテストして、前に受け入れられた修復を取り除くよう構成されてよい。修復モジュール１０６は、増補されたテストスイート１０８に対してテストされていなかった適切な修復を増補されたテストスイート１０８に対してテストして、その適切な修復が増補されたテストスイート１０８を通過するかどうかを判定してよい。適切な修復が増補されたテストスイート１０８を通過しない場合には、修復モジュール１０６は、その適切な修復を、不適切な修復であるとして拒絶してよい。適切な修復が増補されたテストスイート１０８を通過する場合には、修復モジュール１０６は、その適切な修復を適切な修復として再び受け入れてよい。

いくつかの実施形態では、修復モジュール１０６は、被試験コード１０４内の１つ以上の欠陥を直すように被試験コード１０４に対する変更（例えば、変換）を含む変更された被試験コードを出力するよう構成されてよい。

変更、追加、又は省略が、本開示の適用範囲から外れることなしに、図１に対して行われてよい。例えば、環境１００は、本開示で図解及び記載されているものよりも多い又は少ない要素を含んでよい。その上、いくつかの実施形態では、修復モジュールの１つ以上のルーチン、１つ以上の命令、又はコードの少なくとも一部分と、テストスイート１１２とは、それらが同じ要素と見なされ得るか、あるいは、修復モジュール１０６及びテストスイート１１２の２つ以上の部分と見なされ得る共通のセクションを有し得るように、組み合わされてよい。例えば、増補されたテストスイート１０８は、欠陥又は複数の欠陥をテストするよう、様々な数の、人間が提供したテストオラクルを含んでよい。他の例では、パッチ１１０は、欠陥又は複数の欠陥に対するパッチ（適切な修復）をいくつでも含んでよい。

図２は、本明細書で記載される少なくともいくつかの実施形態に従って配置される、ソフトウェアプログラムを修復するよう構成され得る、例となる汎用コンピュータシステム２０２の選択されたコンポーネントを表す。コンピュータシステム２０２は、修復モジュール（例えば、図１の修復モジュール１０６）と関連する１つ以上の動作を実装又は指示するよう構成されてよい。コンピュータシステム２０２は、プロセッサ２５０、メモリ２５２、及びデータストレージ２５４を含んでよい。プロセッサ２５０、メモリ２５２、及びデータストレージ２５４は、通信上結合されてよい。

一般に、プロセッサ２５０は、様々なコンピュータハードウェア又はソフトウェアモジュールを含む如何なる適切な専用又は汎用コンピュータ、コンピュータエンティティ、又はコンピュータ若しくはプロセッシングデバイスも含んでよく、如何なる適切なコンピュータ可読記憶媒体においても記憶された命令を実行するよう構成されてよい。例えば、プロセッサ２５０は、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、あるいは、プログラム命令を解釈するよう及び／若しくは実行するよう並びに／又はデータを処理するよう構成された如何なる他のデジタル又はアナログ回路構成も含んでよい。図２では単一のプロセッサとして表されているが、プロセッサ２５０は、本開示で記載される動作をいくつでも個々に又は集合的に実行するか又はそのような実行を指示するよう構成されるプロセッサをいくつでも含んでよい。その上、プロセッサの１つ以上は、１つ以上の異なる電子デバイス、例えば、異なるサーバにおいて存在してよい。

いくつかの実施形態では、プロセッサ２５０は、メモリ２５２、データストレージ２５４、又はメモリ２５２及びデータストレージ２５４に記憶されているプログラム命令を解釈及び／若しくは実行し、並びに／又はそのように記憶されているデータを処理するよう構成されてよい。いくつかの実施形態では、プロセッサ２５０は、データストレージ２５４からプログラム命令をフェッチし、プログラム命令をメモリ２５２にロードしてよい。プログラム命令がメモリ２５２にロードされた後、プロセッサ２５０はプログラム命令を実行してよい。

例えば、いくつかの実施形態では、修復モジュールは、プログラム命令としてデータストレージ２５４に含まれてよい。プロセッサ２５０は、修復モジュールのプログラム命令をデータストレージ２５４からフェッチしてよく、そして、修復モジュールのプログラム命令をメモリ２５２にロードしてよい。修復モジュールのプログラム命令がメモリ２５２にロードされた後、プロセッサ２５０は、コンピュータシステムが、命令によって指示されるように、修復モジュールに関連した動作を実装し得るように、プログラム命令を実行してよい。

メモリ２５２及びデータストレージ２５４は、コンピュータ実行可能な命令又はデータ構造を搬送するか、又はそれらが記憶されているコンピュータ可読記憶媒体を含んでよい。そのようなコンピュータ可読記憶媒体は、プロセッサ２５０のような汎用又は専用のコンピュータによってアクセスされ得る如何なる利用可能な媒体も含んでよい。一例として、制限なしに、そのようなコンピュータ可読記憶媒体には、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、電気的消去可能なプログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、コンパクトディスク・リードオンリーメモリ（ＣＤ－ＲＯＭ）若しくは他の光ディスクストレージ、磁気ディスクストレージ若しくは他の磁気記憶デバイス、フラッシュメモリデバイス（例えば、固体状態メモリデバイス）、あるいは、コンピュータ実行可能な命令又はデータ構造の形で特定のプログラムコードを搬送又は記憶するために使用され得、且つ、汎用又は専用のコンピュータによってアクセスされ得る如何なる他の記憶媒体も含む有形又は非一時的なコンピュータ可読記憶媒体が含まれ得る。上記の組み合わせも、コンピュータ可読記憶媒体の適用範囲内に含まれ得る。コンピュータ実行可能命令は、例えば、プロセッサ２５０に特定の動作又は動作群を実行させるよう構成される命令及びデータを含んでよい。

変更、追加、又は省略は、本開示の適用範囲から外れることなしに、コンピュータシステム２０２に対して行われてよい。例えば、いくつかの実施形態では、コンピュータシステム２０２は、明示的に図解又は記載され得ない他のコンポーネントをいくつでも含んでよい。

図３Ａ及び３Ｂは、本明細書で記載される少なくともいくつかの実施形態に従って配置される、ソフトウェアプログラムをインタラクティブに修復するプロセスを例示するフロー図３００である。例となるプロセス及び方法は、ブロック３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６、３１８、３２０、３２２、３２４、３２６、３２８、３３０、及び／又は３３２の１つ以上によって表される１つ以上の動作、関数、又はアクションを含んでよい。ブロック３０２～３３２で記載される動作は、ソフトウェアプログラム（例えば、図１の被試験コード１０４）に関して如何なる適切なシステム、装置、又はデバイスによっても実行されてよい。例えば、いくつかの実施形態では、ブロック３０２~３３２で記載される動作は、図１の修復モジュール１０６、又は（修復モジュールによって指示される）図２のコンピュータシステム２０２のようなコンピュータシステムによって実行されてよい。ブロック３０２~３３２で記載される動作はまた、コンピュータシステム２０２のメモリ２５２及び／又はデータストレージ２５４のようなコンピュータ可読媒体において、コンピュータ実行可能な命令として記憶されてよい。

フロー図３００によって表されているように、ソフトウェアプログラムをインタラクティブに修復するプロセスの例は、ブロック３０２（“欠陥位置を選択する”）から開始してよい。ブロック３０２で、修復モジュール（例えば、図１の修復モジュール１０６）は、修復されているソフトウェアプログラム（例えば、図１の被試験コード１０４）において欠陥位置を選択してよい。１つ以上の欠陥及び対応する欠陥位置は、如何なる適切な技術を用いてもソフトウェアプログラムにおいて特定されてよい。例えば、いくつかの実施形態では、欠陥の特定は、ソフトウェアプログラムに関して１つ以上のテストスイート（例えば、図１のテストスイート１１２）のテスト実行の結果起こってよい。

いくつかの実施形態では、修復モジュールは、特定された欠陥及び／又は対応する欠陥位置の優先順位に基づき、特定の欠陥位置を選択してよい。優先順位は、ソフトウェアプログラムのインタラクティブな修復の実行の間に、修復候補の実装のための特定の欠陥位置の選択の順序を決定してよい。例えば、修復モジュールは、特定された欠陥位置の夫々の優先順位を比較してよい。特定の欠陥位置は、残りの欠陥位置の夫々よりも高い優先順位を有してよい。優先順位の比較に基づき、修復モジュールは、より低い優先順位を有している欠陥位置を選択する代わりに、より高い優先順位を有している特定の欠陥位置を選択してよい。修復モジュールは、選択された欠陥位置での修復候補を、可能性がある修復として実装してよい。

ブロック３０２の後には、ブロック３０４（“修復候補を選択し、可能な修復を実装する”）が続いてよい。ブロック３０４で、修復モジュールは、修復候補を選択し、その選択された修復候補を用いて可能な修復を実装してよい。修復モジュールは、選択された欠陥位置での修復候補を、欠陥位置に対応する欠陥の可能な修復として実装してよい。いくつかの実施形態では、修復モジュールは、本明細書で記載されるように、修復テンプレートに基づき修復候補を実装してよい。

ブロック３０４の後には、ブロック３０６（“テストスイートを実行する”）が続いてよい。ブロック３０６で、修復モジュールは、欠陥位置での可能な修復に対してテストスイート（図１のテストスイート１１２）の中の１つ以上のテストを実行してよい。可能な修復をテストすることは、可能な修復を含むソフトウェアプログラムの一部又は全てをテストすることを含んでよい。可能な修復及び／又は可能な修復を含むソフトウェアプログラムの一部若しくは全てをテストすることは、テストされたソフトウェアプログラム及び／又は可能な修復がテストスイートの中のテストを通過するかどうかといった、テストされたソフトウェアプログラム及び／又は可能な修復に関する情報を生成してよい。

ブロック３０６の後には、決定ブロック３０８（“全てのテストを通過したか？”）が続いてよい。決定ブロック３０８で、修復モジュールは、選択された欠陥位置での可能な修復がテストスイートの中のテストを通過するかどうかを判定してよい。例えば、修復モジュールは、可能な修復がテストスイートを通過するかどうかを判定するよう、可能な修復に対して実行されたテストの夫々を試験してよい。選択された欠陥位置での可能な修復がテストスイートの中の全てのテストを通過する場合には、決定ブロック３０８の後に決定ブロック３１０（“テストスイートを増補するテストが存在するか？”）が続いてよい。決定ブロック３１０で、修復モジュールは、テストスイートを増補する追加の（例えば、新しい）テストが存在するかどうかを判定してよい。すなわち、修復モジュールは、欠陥位置での可能な修復をテストする追加のテストが存在するかどうかを判定してよい。

いくつかの実施形態では、修復モジュールは、如何なる適切な技術を用いても、追加のテストを生成するよう構成されてよい。例えば、修復モジュールは、記号実行に基づくテスト生成技術、検索に基づくテスト生成技術、又はそれらの技術の何らかの組み合わせを用いて、追加のテストを生成してよい。いくつかの実施形態では、修復モジュールは、修復されているソフトウェアプログラム及び／又は可能な修復における全ての実行経路が働かされない限りは、追加のテストを生成するよう構成されてよい。すなわち、修復モジュールは、修復されているソフトウェアプログラム及び／又は可能な修復における全ての実行経路が働かされると、追加のテストを生成することを中止するよう構成されてよい。いくつかの実施形態では、修復モジュールは、修復されているソフトウェアプログラム及び／又は可能な修復における実行経路のうちの特定の割合が働かされない限りは、追加のテストを生成するよう構成されてよい。すなわち、修復モジュールは、修復されているソフトウェアプログラム及び／又は可能な修復のうちの特定の割合（例えば、９５％、９０％、８５％、８０％、など）が働かされると、追加のテストを生成することを中止するよう構成されてよい。いくつかの実施形態では、修復モジュールは、テストの数が特定の数に達するまで、追加のテストを生成するよう構成されてよい。いくつかの実施形態では、修復モジュールは、修復モジュールが新しいテストを生成することができなくなるまで、追加のテストを生成するよう構成されてよい。

テストスイートを増補する追加の（例えば、新しい）テストが存在する場合には、決定ブロック３１０の後にブロック３１２（“新しいテストをテストスイートに加える”）が続いてよい。ブロック３１２で、修復モジュールは、追加のテストを生成し、その新しいテストをテストスイートに加えてよい。例えば、テストスイートは、ブロック３０６で可能な修復をテストするために使用されたテストスイート（例えば、図１のテストスイート１１２）であってよい。いくつかの実施形態では、テストスイートは、人間が提供したテストオラクルにより拡張されたテストケースにより以前に増補されたテストスイート（図１の増補されたテストスイート１０８）であってよい。

ブロック３１２の後には、ブロック３１４（“人間からテストオラクルを得る”）が続いてよい。ブロック３１４で、修復モジュールは、新たに生成されたテストケースについて人間（例えば、図１の人間１０２）からテストオラクルを取得してよい。いくつかの実施形態では、修復モジュールは、追加のテストに基づきテストオラクルのためのクエリを生成してよい。例えば、クエリは、追加のテストの実行の結果を要求してよい。修復モジュールは、クエリを人間に提示し、提示されたクエリに対する人間の応答を取得してよい。修復モジュールは、次いで、提示されたクエリ及び人間の対応する応答に基づき、人間が提供したテストオラクルを生成してよい。いくつかの実施形態では、修復モジュールは、提示されたクエリに人間が応答（例えば、回答）しないか又はそうすることができない場合に、提示されたクエリをスキップするよう構成されてよい。例えば、修復モジュールは、提示されたクエリに対する応答を受けるよう、特定量の時間（例えば、３０秒、１分、など）だけ待ってよい。いくつかの実施形態では、修復モジュールは、提示されたクエリに対して人間が応答しないか又はそうすることができない場合に、追加のテストを生成すること、及び生成された追加のテストに対応するクエリを提示することを続けるよう構成されてよい。いくつかの実施形態では、修復モジュールは、提示されたクエリに対して人間が応答しないか又はそうすることができない場合に、提示されたクエリと同じ入力スペースに異なる（例えば、他の）クエリを生成し提示するよう構成されてよい。いくつかの実施形態では、提示されたクエリに対して人間が応答しないか又はそうすることができない場合に、欠陥位置（例えば、現在の欠陥位置）をスキップし、次の（例えば、他の）欠陥位置を処理するよう構成されてよい。

ブロック３１５（“新しいテストを拡張する”）で、修復モジュールは、人間が提供したテストオラクルを新しいテストに加えることによって、新しいテストを拡張してよい。修復モジュールは、次いで、拡張された新しいテストをテストスイートに含めることによって、テストスイートを増補してよい。ブロック３１５の後には、ブロック３１６（“増補されたテストスイートを実行する”）が続いてよい。ブロック３１６で、修復モジュールは、欠陥位置での可能な修復に対して、人間が提供したテストオラクルにより拡張された更なるテストを含む増補されたテストスイートを実行してよい。いくつかの実施形態では、修復モジュールは、新たに生成された拡張されたテストに対して、欠陥位置での可能な修復をテストしてよい。いくつかの実施形態では、修復モジュールは、人間が提供したテストオラクルにより拡張されている拡張された新たに生成されたテストを含む増補されたテストスイートの中の一部又は全てのテストに対して、欠陥位置での可能な修復をテストしてよい。テストされたテストは、人間が提供したテストオラクルにより拡張された１つ以上の前に生成されたテストを含んでよい。可能な修復をテストすることは、可能な修復を含むソフトウェアプログラムの一部又は全てをテストすることを含んでよい。可能な修復及び／又は可能な修復を含むソフトウェアプログラムの一部若しくは全てをテストすることは、テストされたソフトウェアプログラム及び／又は可能な修復が増補されたテストスイートの中のテストを通過するかどうかといった、テストされたソフトウェアプログラム及び／又は可能な修復に関する情報を生成してよい。

ブロック３１６の後には、決定ブロック３２０（“全てのテストを通過したか？”）が続いてよい。決定ブロック３２０で、修復モジュールは、選択された欠陥位置での可能な修復が増補されたテストスイートの中のテストを通過するかどうかを判定してよい。例えば、修復モジュールは、選択された欠陥位置での可能な修復が、拡張された新たに生成されたテストを通過するかどうかを判定してよい。例えば、修復モジュールは、選択された欠陥位置での可能な修復が増補されたテストスイートを通過するかどうかを判定するよう、可能な修復に対して実行されたテストの夫々を試験してよい。選択された欠陥位置での可能な修復が（拡張された新たに生成されたテストを含む）増補されたテストスイートの中のテストを通過する場合には、決定ブロック３２０の後に決定ブロック３１０が続いてよい。決定ブロック３１０で、修復モジュールは、増補されたテストスイートを更に増補するようその増補されたテストスイートに加えられ得る他の人間が提供したテストオラクルにより拡張すべき他の追加の（例えば、他の新しい）テストが存在するかどうかを判定してよい。すなわち、修復モジュールは、他のテストが存在するかどうかを判定してよく、該他のテストは、人間が提供したテストオラクルのための基礎であってよく、且つ、欠陥位置での可能な修復を更にテストするよう対応する人間が提供したテストオラクルにより拡張され得る。この例では、修復モジュールは、増補されたテストスイートを、対応する人間が提供したテストオラクルにより拡張される更なる拡張されたテストにより充実させること又は強化させることであってよい。更なる拡張されたテスト（例えば、生成されたテスト及びその対応する人間が提供したテストオラクル）は、欠陥の適切な修復（パッチ）としての選択された欠陥位置での可能な修復を拒絶するために使用されてよい。例えば、可能な修復は、第１の人間が提供したテストオラクルを伴った第１の拡張されたテストには合格し、そして、第２の人間が提供したテストオラクルを伴った第２の拡張されたテストには落第することがある。この例では、可能な修復が、第２の人間が提供したテストオラクルを伴った第２の拡張されたテストに対してテストされない場合に、可能な修復は、たとえそれが適切な修復でない（例えば、パッチでない）としても、適切な修復として誤って受け入れられ得る。

さもなければ、選択された欠陥位置での可能な修復が増補されたテストスイートの中のテストを通過しない場合に、決定ブロック３２０の後にはブロック３２２（“可能な修復を拒絶する”）が続いてよい。ブロック３２２で、修復モジュールは、選択された欠陥位置での可能な修復を不適切な修復として拒絶してよい。修復モジュールは、可能な修復の基礎となった修復候補を、不適切又は不正確な修復を生成するものとして捨ててよい。ブロック３２２の後には、以下で更に記載されるように、決定ブロック３２８が続いてよい。

さもなければ、決定ブロック３１０で、修復モジュールが、テストスイートを増補する追加の（例えば、新しい）テストは存在しないと決定する場合に、決定ブロック３１０の後にはブロック３２４（“可能な修復を受け入れる”）が続いてよい。ブロック３２４で、修復モジュールは、選択された欠陥位置での可能な修復を適切な修復（パッチ）として受け入れてよい。修復モジュールは、可能な修復の基礎となった修復候補を、適切又は正確な修復を生成するものとして受け入れてよい。修復モジュールは、受け入れられた可能な修復を適切な修復（パッチ）としてパッチ１１０に含めてよい。上述されたように、決定ブロック３１０はまた、修復モジュールが、増補されたテストスイートの中を増補するよう他の追加の（例えば、他の新しい）テストが存在するかどうかを判定するよう確認し得る場合において、決定ブロック３２０から続いてよい。

ブロック３２４の後には、決定ブロック３２６（“更なる修復を生成するか？”）が続いてよい。決定ブロック３２６で、修復モジュールは、それが、選択された欠陥位置で追加の可能な修復を生成しようと試みるべきかどうかを判定してよい。選択された欠陥位置での可能な修復をパッチとして受け入れた後、修復モジュールは、それが、選択された欠陥位置で、まさに受け入れられたパッチ以外の他の追加のパッチを生成しようと試みるべきかどうかを判定してよい。例えば、修復モジュールは、新たに生成されたテストが前に受け入れられた可能な修復（例えば、前のパッチ）を無効にし得るということで、選択された欠陥位置での複数の可能な修復（例えば、欠陥のための複数のパッチ）を生成しようと試みてよい。いくつかの実施形態では、修復モジュールは、特定の計算量を費やした後には、選択された欠陥位置で追加の可能な修復をしようと試みないよう構成されてよい。特定の計算量の一例として、修復モジュールは、選択された欠陥位置で追加の可能な修復を生成しようと試みるのにｎ時間よりも多く費やさないように構成されてよい。特定の計算量の他の例として、修復モジュールは、選択された欠陥位置でｍ個のパッチを生成した後には、選択された欠陥位置で追加の可能な修復を生成しようと試みないよう構成されてよい。特定の計算量の更なる他の例として、修復モジュールは、最後のｐ個のパッチが新しいテストが生成されることをもたらさないとの決定時には、選択された欠陥位置で追加の可能な修復を生成しようと試みないよう構成されてよい。これは、増補されたテストスイートが十分にロバストであり、且つ／あるいは、可能性がある修復を拒絶すること又は前のパッチを無効にすることがありそうもないことを示し得る。特定の計算量は、前述の例のうちの２つ以上の如何なる組み合わせであってもよい。いくつかの実施形態では、ｎ、ｍ、及び／又はｐの値は、実験によって得られるデータに基づき設定されてよい。いくつかの実施形態では、ｎ、ｍ、及び／又はｐの値は、任意に設定されてよい。

選択された欠陥位置で追加の可能な修復を生成しようと試みるべきであると修復モジュールが決定する場合には、決定ブロック３２６の後に決定ブロック３２８（“更なる修復候補はあるか？”）が続いてよい。決定ブロック３２８で、修復モジュールは、選択された欠陥位置で他の可能な修復として実装され得る他の（例えば、追加の）修復候補が存在するかどうかを判定してよい。決定ブロック３２８はまた、選択された欠陥位置での可能な修復がテストスイートの中の全てのテストを通過しない場合に、決定ブロック３０８から続いてよい。決定ブロック３２８はまた、修復モジュールが選択された欠陥位置での可能な修復を不適切な修復として拒絶するブロック３２２から続いてよい。選択された欠陥位置で他の可能な修復として実装され得る追加の修復候補が存在すると修復モジュールが決定する場合には、決定ブロック３２８の後にブロック３０４が続く。ブロック３０４で、修復モジュールは、その追加の修復候補を用いて、選択された欠陥位置で追加の可能な修復を実装してよい。修復モジュールは、選択された欠陥位置での追加の修復候補を、その欠陥位置に対応する欠陥の他の可能な修復として実装してよい。修復モジュールは、本明細書で記載されるように、次いで、追加の可能な修復をテストしてよい。

さもなければ、選択された欠陥位置で他の可能な修復として実装され得る追加の修復候補が存在しないと修復モジュールが決定する場合に、決定ブロック３２８の後には決定ブロック３３０（“更なる欠陥位置はあるか？”）が続いてよい。決定ブロック３３０で、修復モジュールは、修復され得るソフトウェアプログラム内の他の欠陥位置が存在するかどうかを判定してよい。決定ブロック３３０はまた、選択された欠陥位置で追加の可能な修復を生成しようと試みるべきでないと修復モジュールが決定する場合に、決定ブロック３２６から続いてよい。修復されているソフトウェアプログラムにおいて他の欠陥位置が存在すると修復モジュールが決定する場合には、決定ブロック３３０の後にブロック３０２が続いてよい。ブロック３０２で、修復モジュールは、処理のために修復されているソフトウェアプログラムにおいて他の（例えば、新しい）欠陥位置を選択してよい。例えば、修復モジュールは、次に高い優先順位を有している欠陥位置を新しい欠陥位置として選択してよい。修復モジュールは、本明細書で記載されるように、次いで、選択された新しい欠陥位置を特定の欠陥位置として処理してよい（例えば、新しい欠陥位置は、現在の特定の欠陥位置を新しい特定の欠陥位置として置換する。）。

さもなければ、修復されているソフトウェアプログラムにおいて追加の欠陥位置が存在しないと修復モジュールが決定する場合に、決定ブロック３３０の後にはブロック３３２（“パッチを出力する”）が続いてよい。ブロック３３２で、修復モジュールは、ソフトウェアプログラムの修復の間に生成されたパッチ（例えば、パッチ１１０）を出力してよい。出力されたパッチは、単一の修復位置に対するパッチを含んでよい。出力されたパッチは、複数の修復位置に対するパッチを含んでよい。出力されたパッチは、夫々の修復位置について１つのパッチを含んでよい。いくつかの実施形態では、修復モジュールはまた、ソフトウェアプログラムの修復の間に生成されたそれらの対応する人間が提供したテストオラクルにより拡張された新たに生成されたテストケースを含む増補されたテストスイート（例えば、増補されたテストスイート１０８）を出力してよい。増補されたテストスイートは、次いで、他のソフトウェアプログラムにおいて欠陥及び対応する欠陥位置を特定するために使用されてよい。

当業者に明らかなように、本明細書で開示されているこの及び他のプロセス及び方法について、プロセス及び方法で実行される動作は、異なる順序で実施されてよい。その上、又は代替的に、２つ以上の動作は、同時に実行されてよい。更には、説明されているアクション及び動作は、単に例として与えられており、アクション及び動作の一部は、開示されている実施形態の本質から逸脱することなしに、任意であり、より少ないアクション及び動作にまとめられ、あるいは、更なるアクション及び動作に拡張されてよい。

その上、いくつかの実施形態では、プロセス及び方法において実行される動作は、繰り返し実行されてよい。その場合に、一度に１つの欠陥位置及び／又は修復候補が解析されてよい。その上、又は代替的に、１つ以上のブロックに関連する１つ以上の動作は、一度に複数の欠陥位置及び／又は修復候補に対して実行されてよい。

例えば、例となるインタラクティブな修復プロセスとして、修復モジュールは、ソフトウェアプログラムをインタラクティブに修復してよく、次のソフトウェアプログラムにおいて次の欠陥を処理してよい：

int median(int n1,int n2,int n3){
//n1が中間値である
if(n2<=n1 && n1<=n3)
return n1;
//n2が中間値である
if((n1<n2 && n2<=n3)||(n3<=n2 && n2<n1))
return n2;
//上記以外で、n3が中間値である
return n3;
}

上記の欠陥のあるソフトウェアプログラムは、３つの整数の中間値を返す関数を含み、欠陥（例えば、欠陥は、if(n2<=n1 && n1<=n3) return n1の記述である。）を含む。欠陥及び対応する欠陥位置（例えば、上記の欠陥位置）は、以下のテストスイートを用いて特定され得る：

void test1(){
//テスト３つの異なる数
assert(median(2,6,8)==6);
}
void test2(){
//テスト３つの異なる数
assert(median(9,9,9)==9);
}
void test3(){
//テスト３つの異なる値
assert(median(8,8,2)==8);
}

例えば、上記のテストスイートを適用すると、関数は、テスト“median(8,8,2)”に応答して値“８”の代わりに値“２”を返し、アサーション“assert(median(8,8,2)==8)”に落第する。

修復モジュールは、次の可能な修復［１］を実装することによって、欠陥を修復又は回復しようと試みてよい：

replace
if((n1<n2 && n2<=n3)||(n3<=n2 && n2<n1))
return n2;

with
if((n1<n2 && n2<=n3)||(n1==n2))
return n2; ［１］

修復モジュールは、可能な修復［１］を含む関数をテストスイートに対してテストしてよい。可能な修復［１］を含む関数は、テストスイートの中の３つのテストを通過する。可能な修復［１］を適切な修復として受け入れることよりむしろ、修復モジュールは、可能な修復［１］を更にテストするように追加のテストを生成しようと試みてよい。

例えば、修復モジュールは、可能な修復［１］をテストするよう第１の追加のテスト“median(8,6,2)”（最初のテスト内の引数を並べ替えるテスト）を生成してよい。修復モジュールは、第１の追加のテストに基づきクエリ“３つの数８、６及び２の中で中間値はどれですか？”を生成してよい。修復モジュールはクエリを人間に提示し、人間は応答“数６”を供給し得る。修復モジュールは、次いで、第１の追加のテストに関連するクエリ及び人間の応答に基づき、人間が提供したテストオラクル“assert(median(8,6,2)==6)”を生成し、第１の人間が提供したテストオラクルを第１の追加のテストにより含めて、以下のように、第１の追加のテストをテストスイート内の第４のテストとして増補してよい：

void test1(){
//テスト３つの異なる数
assert(median(2,6,8)==6);
}
void test2(){
//テスト３つの異なる数
assert(median(9,9,9)==9);
}
void test3(){
//テスト３つの異なる値
assert(median(8,8,2)==8);
}
void test4(){
//test1の引数が置換されたテスト
assert(median(8,6,2)==6);
}

すなわち、修復モジュールは、テストスイートの中のテスト及び第１の人間が提供したテストオラクルを含む拡張された最初のテスト（例えば、第４のテスト）に基づき、増補されたテストスイートを生成してよい。修復モジュールは、次いで、可能な修復［１］を含む関数を、増補されたテストスイートに対して（例えば、最初の３つのテストケースと、その人間が提供したテストオラクルを伴った新たに生成された第４のテストとに対して）テストしてよい。増補されたテストスイートに対してテストされると、関数（例えば、可能な修復［１］）は、第１の追加のテスト（median(8,6,2)）に応答して値“６”の代わりに値“２”を返し、第１の人間が提供したテストオラクル“assert(median(8,6,2)==6)”に落第する。関数が増補されたテストスイートに落第した結果として、修復モジュールは、可能な修復［１］を不適切な修復として捨ててよい。

修復モジュールは、再び、次の可能な修復［２］を実装することによって、欠陥を修復又は回復しようと試みてよい：

replace
if(n2<=n1 && n1<=n3)
return n1

with
if((n2<=n1 && n1<=n3)||(n1==n2))
return n1; ［２］

修復モジュールは、可能な修復［２］を含む関数を、第１の人間が提供したテストオラクルを伴った第１の拡張されたテストを含む増補されたテストスイートに対してテストしてよい。可能な修復［２］を含む関数は、増補されたテストスイートの中の４つのテストを通過する。可能な修復［２］を適切な修復として受け入れることよりむしろ、修復モジュールは、可能な修復［２］を更にテストするように他の追加のテストを生成しようと試みてよい。

例えば、修復モジュールは、可能な修復［２］をテストするよう第２の追加のテスト“median(6,8,2)”（最初のテスト内の引数を更に並べ替えるテスト）を生成してよい。修復モジュールは、第２の追加のテストに基づきクエリ“３つの数６、８及び２の中で中間値はどれですか？”を生成してよい。修復モジュールはクエリを人間に提示し、人間は応答“数６”を供給し得る。修復モジュールは、次いで、第２の追加のテストに関連するクエリ及び人間の応答に基づき、人間が提供したテストオラクル“assert(median(6,8,2)==6)”を生成し、第２の人間が提供したテストオラクルを第２の追加のテストにより含めて、以下のように、第２の追加のテストをテストスイート内の第５のテストとして増補してよい：

void test1(){
//テスト３つの異なる数
assert(median(2,6,8)==6);
}
void test2(){
//テスト３つの異なる数
assert(median(9,9,9)==9);
}
void test3(){
//テスト３つの異なる値
assert(median(8,8,2)==8);
}
void test4(){
//test1の引数が置換されたテスト
assert(median(8,6,2)==6);
}
void test5(){
//test1の引数が置換されたテスト
assert(median(6,8,2)==6);
}

修復モジュールは、次いで、可能な修復［２］を含む関数を、増補されたテストスイート（例えば、前から存在する４つのテストに加えて第５のテストを含む。）に対してテストしてよい。増補されたテストスイートに対してテストされると、関数（例えば、可能な修復［２］）は、第２の追加のテスト（median(6,8,2)）に応答して値“６”の代わりに値“２”を返し、第２の人間が提供したテストオラクル“assert(median(6,8,2)==6)”に落第する。関数が増補されたテストスイートに落第した結果として、修復モジュールは、可能な修復［２］を不適切な修復として捨ててよい。

修復モジュールは、再び、次の可能な修復［３］を実装することによって、欠陥を修復又は回復しようと試みてよい：

replace
if(n2<=n1 && n1<=n3)
return n1

with
if((n2<=n1 && n1<=n3)||(n3<=n1 && n1<=n2))
return n1; ［３］

修復モジュールは、可能な修復［３］を含む関数を、第２の人間が提供したテストオラクルを伴った第２の追加のテスト（例えば、第５のテスト）を含む増補されたテストスイートに対してテストしてよい。可能な修復［３］を含む関数は、増補されたテストスイートの中の５つのテストを通過する。修復モジュールは、次いで、可能な修復［３］を含む関数を更にテストするために追加のテストが必要とされないと決定してよい。例えば、修復モジュールは、増補されたテストスイートが十分にロバストであると決定してよい。然るに、修復モジュールは、可能な修復［３］を欠陥位置での適切な修復（パッチ）として受け入れてよい。

図４は、本明細書で記載される少なくともいくつかの実施形態に従って配置される、前に受け入れられた修復を増補されたテストスイートを用いて再テストするプロセスを例示するフロー図４００である。例となるプロセス及び方法は、ブロック４０２、４０４、４０６、４０８、及び／又は４１０の１つ以上によって表される１つ以上の動作、関数、又はアクションを含んでよい。ブロック４０２～４１０で記載される動作は、ソフトウェアプログラム（例えば、図１の被試験コード１０４）に関して如何なる適切なシステム、装置、又はデバイスによっても実行されてよい。例えば、いくつかの実施形態では、ブロック４０２~４１０で記載される動作は、図１の修復モジュール１０６、又は（修復モジュールによって指示される）図２のコンピュータシステム２０２のようなコンピュータシステムによって実行されてよい。ブロック４０２~４１０で記載される動作はまた、コンピュータシステム２０２のメモリ２５２及び／又はデータストレージ２５４のようなコンピュータ可読媒体において、コンピュータ実行可能な命令として記憶されてよい。

フロー図４００によって表されているように、前に受け入れられた修復を増補されたテストスイートを用いて再テストするプロセスの例は、ブロック４０２（“前に受け入れられた修復（パッチ）を読み出す”）から開始してよい。ブロック４０２で、修復モジュール（例えば、図１の修復モジュール１０６）は、増補されたテストスイートに対してテストすべき、前に受け入れられた修復（例えば、欠陥位置での前に受け入れられた可能な修復）を読み出してよい。増補されたテストスイートは、１つ以上のテスト（例えば、人間が提供したテストオラクル）を含んでよく、前に受け入れられた修復は、増補されたテストスイート内のテストの１つ以上に対してテストされたことがない可能性がある。

ブロック４０２の後には、ブロック４０４（“増補されたテストスイートを実行する”）が続いてよい。ブロック４０４で、修復モジュールは、読み出された、前に受け入れられた修復を、増補されたテストスイートに対してテストしてよい。修復モジュールは、前に受け入れられた修復が依然として適切な修復（パッチ）であるかどうかを判定するよう、前に受け入れられた修復を増補されたテストスイートに対してテストしてよい。

ブロック４０４の後には、決定ブロック４０６（“全てのテストを通過したか？”）が続いてよい。決定ブロック４０６で、修復モジュールは、前に受け入れられた修復が増補されたテストスイートの中のテストを通過するかどうかを判定してよい。前に受け入れられた修復が増補されたテストスイートの中のテストを通過すると修復モジュールが決定する場合には、決定ブロック４０６の後にブロック４０８（“前に受け入れられた修復を受け入れる”）が続いてよい。ブロック４０８で、修復モジュールは、前に受け入れられた修復を適切な修復として受け入れてよい（例えば、再度受け入れてよい）。

さもなければ、前に受け入れられた修復が増補されたテストスイートの中のテストを通過しないと修復モジュールが決定する場合に、決定ブロック４０６の後にはブロック４１０（“前に受け入れられた修復を拒絶する”）が続いてよい。ブロック４１０で、修復モジュールは、前に受け入れられた修復を不適切な又は不正確な修復として拒絶してよい。すなわち、修復モジュールは、前に受け入れられた修復を、もはや適切な修復でないとして取り除いてよい。前に受け入れられた修復は拒絶され、そして、増補されたテストスイートに落第するために、もはや適切な修復でない。いくつかの実施形態では、修復モジュールは、前に受け入れられた修復をパッチ１１０から除いてよい。修復モジュールは、増補されたテストスイートに対してテストされていない更なる前に受け入れられた修復を、増補されたテストスイートに対してテストしてよい。

上述されたように、本開示で記載される実施形態は、本明細書で更に詳細に説明されるように、様々なコンピュータハードウェア又はソフトウェアモジュールを含む専用又汎用のコンピュータ（例えば、図２のプロセッサ２５０）の使用を含んでよい。更には、上述されたように、本開示で記載される実施形態は、コンピュータ実行可能な命令又はデータ構造を搬送するか又はそれらが記憶されているコンピュータ可読媒体（例えば、図２のメモリ２５２）を用いて実装されてよい。

本開示で使用されるように、語“モジュール”又は“コンポーネント”は、コンピュータシステムの汎用ハードウェア（例えば、コンピュータ可読媒体、プロセッシングデバイス）において記憶及び／又は実行され得るソフトウェアオブジェクト若しくはソフトウェアルーチン及び／又はモジュール若しくはコンポーネントのアクションを実行するよう構成される特定のハードウェア実装を表し得る。いくつかの実施形態では、本開示で記載される種々のコンポーネント、モジュール、エンジン、及びサービスは、コンピュータシステムで（例えば、別個のスレッドとして）実行するオブジェクト又はプロセスとして実装されてよい。本開示で記載されるシステム及び方法の一部は、ソフトウェア（汎用ハードウェアにおいて記憶及び／又は実行される。）で実装されるものとして概して記載されるが、特定のハードウェア実装、ファームウェア実装、又はそれらの如何なる組み合わせも、可能であって考えられている。本明細書において、“コンピュータエンティティ”は、本開示で先に記載されている如何なるコンピュータシステムであっても、あるいは、コンピュータシステムで実行する如何なるモジュール又はモジュールの組み合わせであってもよい。

一般的に、本明細書内及び添付の請求の範囲内（例えば、添付の請求の範囲の要部）で使用される用語は、一般的に「非限定的な（open）」用語として意図されている（例えば、「含んでいる（including）」という用語は、「・・・を含んでいるが限定されない（including, but not limited to）」と解釈されるべきであり、「有している（having）」という用語は、「少なくとも・・・を有している（having at least）」と解釈されるべきであり、「含む（includes）」という用語は、「・・・を含むが限定されない（includes, but is not limited to）」と解釈されるべきである。）。

加えて、導入されたクレーム記載（introduced claim recitation）において特定の数が意図される場合、そのような意図は当該クレーム中に明確に記載され、そのような記載がない場合は、そのような意図も存在しない。理解を促すために、例えば、後続の添付する特許請求の範囲では、「少なくとも１つの（at least one）」及び「１つ以上の（one or more）」といった導入句を使用し、クレーム記載を導入することがある。しかし、このような句を使用するからといって、「a」又は「an」といった不定冠詞によりクレーム記載を導入した場合に、たとえ同一のクレーム内に、「１つ以上の」又は「少なくとも１つの」といった導入句と「a」又は「an」といった不定冠詞との両方が含まれるとしても、当該導入されたクレーム記載を含む特定のクレームが、当該記載事項を１つのみ含む例に限定されるということが示唆されると解釈されるべきではない（例えば、「a」及び／又は「an」は、通常は、「少なくとも１つの」又は「１つ以上の」を意味すると解釈されるべきである。）。定冠詞を使用してクレーム記載を導入する場合にも同様のことが当てはまる。

加えて、導入されたクレーム記載において特定の数が明示されている場合であっても、そのような記載は、通常、「少なくとも」記載された数を意味するように解釈されるべきであることは、当業者には理解されるであろう（例えば、他に修飾語のない、単なる「２つの記載事項」という記載がある場合、この記載は、「少なくとも」２つの記載事項、又は「２つ以上の」記載事項を意味する。）。更に、「Ａ、Ｂ及びＣなどのうち少なくとも１つ」又は「Ａ、Ｂ及びＣのうちの１つ以上」に類する表記が使用される場合、一般的に、そのような構造は、Ａのみ、Ｂのみ、Ｃのみ、Ａ及びＢの両方、Ａ及びＣの両方、Ｂ及びＣの両方、並びに／又はＡ及びＢ及びＣの全て、などを有するものとして意図される。

ここで挙げられている全ての例及び条件付き語は、当該技術の促進に対して発明者によって寄与される概念及び発明を読者が理解するのを助ける教育上の目的を意図され、そのような具体的に挙げられている例及び条件に制限されないものとして解釈されるべきである。本発明の実施形態が詳細に記載されてきたが、様々な変更、置換及び代替は、本発明の主旨及び適用範囲から逸脱することなしに行われてよいことが理解されるべきである。

上記の実施形態に加えて、以下の付記を開示する。
（付記１）
人間が生み出した１つ以上のテストオラクルを用いてソフトウェアプログラムをインタラクティブに修復する方法であって、
ソフトウェアプログラム内の欠陥箇所を特定し、
修復候補に基づき、前記欠陥箇所で、可能な修復を生成し、
前記可能な修復をテストするよう第１テストを自動生成し、
前記第１テストに基づき、第１テストオラクルのための第１クエリを生成し、
前記第１クエリに対する応答を人間から取得し、
前記第１クエリ及び該第１クエリに対する前記取得された応答に基づき、人間が提供した第１テストオラクルを生成し、
拡張された第１テストを生成するよう、前記人間が提供した第１テストオラクルを前記第１テストに加え、
前記拡張された第１テストを含むようテストスイートを増補し、
前記増補されたテストスイートを用いて、前記可能な修復をテストする
ことを有する方法。
（付記２）
前記拡張された第１テストを含む前記増補されたテストスイートを前記可能な修復が通過することに応答して、前記可能な修復を適切な修復として受け入れる
ことを更に有する、付記１に記載の方法。
（付記３）
前記拡張された第１テストを含む前記増補されたテストスイートを前記可能な修復が通過しないことに応答して、前記可能な修復を不適切な修復として拒絶する
ことを更に有する、付記１に記載の方法。
（付記４）
前記可能な修復が前記増補されたテストスイートを通過することに応答して、
前記可能な修復をテストするよう第２テストを自動生成し、
前記第２テストに基づき、第２テストオラクルのための第２クエリを生成し、
前記第２クエリに対する応答を人間から取得し、
前記第２クエリ及び該第２クエリに対する前記取得された応答に基づき、人間が提供した第２テストオラクルを生成し、
拡張された第２テストを生成するよう、前記人間が提供した第２テストオラクルを前記第２テストに加え、
前記拡張された第２テストを含むよう、前記増補されたテストスイートを増補する
ことを更に有する、付記１に記載の方法。
（付記５）
前記拡張された第２テストを含む前記増補されたテストスイートを用いて、前記可能な修復をテストする
ことを更に有する、付記４に記載の方法。
（付記６）
前記拡張された第２テストを含む前記増補されたテストスイートを前記可能な修復が通過することに応答して、前記可能な修復を適切な修復として受け入れる
ことを更に有する、付記５に記載の方法。
（付記７）
前記拡張された第２テストを含む前記増補されたテストスイートを前記可能な修復が通過しないことに応答して、前記可能な修復を不適切な修復として拒絶する
ことを更に有する、付記５に記載の方法。
（付記８）
前記拡張された第１テストを含む前記増補されたテストスイートを用いて、前に受け入れられた可能な修復をテストする
ことを更に有する、付記１に記載の方法。
（付記９）
人間が生み出したテストオラクルに基づきソフトウェアプログラムに対する修復をインタラクティブに生成する方法であって、
ソフトウェアプログラム内の欠陥箇所で、第１修復候補に基づく第１の可能な修復をテストするよう、テストを自動生成し、
前記テストに基づき、テストオラクルのためのクエリを生成し、
前記クエリに対する応答を人間から取得し、
前記クエリ及び該クエリに対する前記取得された応答に基づき、人間が提供したテストオラクルを生成し、
拡張されたテストを生成するよう、前記人間が提供したテストオラクルを前記テストに加え、
前記拡張されたテストを含むようテストスイートを増補し、
前記拡張されたテストを含む前記増補されたテストスイートを用いて、前記第１の可能な修復をテストする
ことを有する方法。
（付記１０）
前記拡張されたテストを含む前記増補されたテストスイートを前記第１の可能な修復が通過することに応答して、前記第１の可能な修復を第１の適切な修復として受け入れる
ことを更に有する、付記９に記載の方法。
（付記１１）
前記ソフトウェアプログラム内の前記欠陥箇所で、第２修復候補に基づく第２の可能な修復を生成し、
前記拡張されたテストを含む前記増補されたテストスイートを用いて、前記第２の可能な修復をテストし、
前記拡張されたテストを含む前記増補されたテストスイートを前記第２の可能な修復が通過することに応答して、前記第２の可能な修復を第２の適切な修復として受け入れる
ことを更に有する、付記１０に記載の方法。
（付記１２）
前記拡張されたテストを含む前記増補されたテストスイートを用いて、前に受け入れられた可能な修復をテストする
ことを更に有する、付記９に記載の方法。
（付記１３）
人間が生み出した１つ以上のテストオラクルを用いてソフトウェアプログラムをインタラクティブに修復するよう構成されるシステムであって、
命令を記憶するよう構成される１つ以上のコンピュータ可読記憶媒体と、
前記命令を実行するよう構成される１つ以上のプロセッサと
を有し、
前記命令の実行は、当該システムに、
ソフトウェアプログラム内の欠陥箇所を特定し、
第１修復候補に基づき、前記欠陥箇所で、第１の可能な修復を生成し、
前記第１の可能な修復をテストするよう第１テストを生成し、
前記第１テストに基づき、第１テストオラクルのための第１クエリを生成し、
前記第１クエリに対する応答を人間から取得し、
前記第１クエリ及び該第１クエリに対する前記取得された応答に基づき、人間が提供した第１テストオラクルを生成し、
拡張された第１テストを生成するよう、前記人間が提供した第１テストオラクルを前記第１テストに加え、
前記拡張された第１テストを含むようテストスイートを増補し、
前記拡張された第１テストを含む前記増補されたテストスイートを用いて、前記第１の可能な修復をテストする
ことを含む動作を実行させる、システム。
（付記１４）
前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを前記第１の可能な修復が通過することに応答して、前記第１の可能な修復を第１の適切な修復として受け入れることを更に含む、
付記１３に記載のシステム。
（付記１５）
前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを前記第１の可能な修復が通過しないことに応答して、前記第１の可能な修復を不適切な修復として拒絶することを更に含む、
付記１３に記載のシステム。
（付記１６）
前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを前記第１の可能な修復が通過することに応答して、
前記第１の可能な修復をテストするよう第２テストを生成し、
前記第２テストに基づき、第２テストオラクルのための第２クエリを生成し、
前記第２クエリに対する応答を人間から取得し、
前記第２クエリ及び該第２クエリに対する前記取得された応答に基づき、人間が提供した第２テストオラクルを生成し、
拡張された第２テストを生成するよう、前記人間が提供した第２テストオラクルを前記第２テストに加え、
前記拡張された第２テストを含むよう、前記増補されたテストスイートを増補する
ことを更に含む、
付記１３に記載のシステム。
（付記１７）
前記動作は、前記拡張された第２テストを含む前記増補されたテストスイートを用いて、前記第１の可能な修復をテストすることを更に含む、
付記１６に記載のシステム。
（付記１８）
前記動作は、
第２修復候補に基づき、前記欠陥箇所で、第２の可能な修復を生成し、
前記拡張された第１テストを含む前記増補されたテストスイートを用いて、前記第２の可能な修復をテストする
ことを更に含む、
付記１３に記載のシステム。
（付記１９）
前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを前記第２の可能な修復が通過することに応答して、前記第２の可能な修復を第２の適切な修復として受け入れることを更に含む、
付記１８に記載のシステム。
（付記２０）
前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを用いて、前に受け入れられた可能な修復をテストすることを更に含む、
付記１３に記載のシステム。

１００ 環境
１０２ 人間
１１４ 被試験コード（code under test）
１０６ 修復モジュール
１０８ 増補されたテストスイート
１１０ パッチ
１１２ テストスイート
２０２ コンピュータシステム
２５０ プロセッサ
２５２ メモリ
２５４ データストレージ

Claims (20)

1. 人間が生み出した１つ以上のテストオラクルを用いてソフトウェアプログラムをインタラクティブに修復する方法であって、
   ソフトウェアプログラム内の欠陥箇所を特定し、
   修復候補に基づき、前記欠陥箇所で、可能な修復を生成し、
   前記可能な修復をテストするよう第１テストを自動生成し、
   前記第１テストに基づき、第１テストオラクルのための第１クエリを生成し、
   前記第１クエリに対する応答を人間から取得し、
   前記第１クエリ及び該第１クエリに対する前記取得された応答に基づき、人間が提供した第１テストオラクルを生成し、
   拡張された第１テストを生成するよう、前記人間が提供した第１テストオラクルを前記第１テストに加え、
   前記拡張された第１テストを含むようテストスイートを増補し、
   前記増補されたテストスイートを用いて、前記可能な修復をテストする
   ことを有する方法。
2. 前記拡張された第１テストを含む前記増補されたテストスイートを前記可能な修復が通過することに応答して、前記可能な修復を適切な修復として受け入れる
   ことを更に有する、請求項１に記載の方法。
3. 前記拡張された第１テストを含む前記増補されたテストスイートを前記可能な修復が通過しないことに応答して、前記可能な修復を不適切な修復として拒絶する
   ことを更に有する、請求項１に記載の方法。
4. 前記可能な修復が前記増補されたテストスイートを通過することに応答して、
   前記可能な修復をテストするよう第２テストを自動生成し、
   前記第２テストに基づき、第２テストオラクルのための第２クエリを生成し、
   前記第２クエリに対する応答を人間から取得し、
   前記第２クエリ及び該第２クエリに対する前記取得された応答に基づき、人間が提供した第２テストオラクルを生成し、
   拡張された第２テストを生成するよう、前記人間が提供した第２テストオラクルを前記第２テストに加え、
   前記拡張された第２テストを含むよう、前記増補されたテストスイートを増補する
   ことを更に有する、請求項１に記載の方法。
5. 前記拡張された第２テストを含む前記増補されたテストスイートを用いて、前記可能な修復をテストする
   ことを更に有する、請求項４に記載の方法。
6. 前記拡張された第２テストを含む前記増補されたテストスイートを前記可能な修復が通過することに応答して、前記可能な修復を適切な修復として受け入れる
   ことを更に有する、請求項５に記載の方法。
7. 前記拡張された第２テストを含む前記増補されたテストスイートを前記可能な修復が通過しないことに応答して、前記可能な修復を不適切な修復として拒絶する
   ことを更に有する、請求項５に記載の方法。
8. 前記拡張された第１テストを含む前記増補されたテストスイートを用いて、前に受け入れられた可能な修復をテストする
   ことを更に有する、請求項１に記載の方法。
9. 人間が生み出したテストオラクルに基づきソフトウェアプログラムに対する修復をインタラクティブに生成する方法であって、
   ソフトウェアプログラム内の欠陥箇所で、第１修復候補に基づく第１の可能な修復をテストするよう、テストを自動生成し、
   前記テストに基づき、テストオラクルのためのクエリを生成し、
   前記クエリに対する応答を人間から取得し、
   前記クエリ及び該クエリに対する前記取得された応答に基づき、人間が提供したテストオラクルを生成し、
   拡張されたテストを生成するよう、前記人間が提供したテストオラクルを前記テストに加え、
   前記拡張されたテストを含むようテストスイートを増補し、
   前記拡張されたテストを含む前記増補されたテストスイートを用いて、前記第１の可能な修復をテストする
   ことを有する方法。
10. 前記拡張されたテストを含む前記増補されたテストスイートを前記第１の可能な修復が通過することに応答して、前記第１の可能な修復を第１の適切な修復として受け入れる
    ことを更に有する、請求項９に記載の方法。
11. 前記ソフトウェアプログラム内の前記欠陥箇所で、第２修復候補に基づく第２の可能な修復を生成し、
    前記拡張されたテストを含む前記増補されたテストスイートを用いて、前記第２の可能な修復をテストし、
    前記拡張されたテストを含む前記増補されたテストスイートを前記第２の可能な修復が通過することに応答して、前記第２の可能な修復を第２の適切な修復として受け入れる
    ことを更に有する、請求項１０に記載の方法。
12. 前記拡張されたテストを含む前記増補されたテストスイートを用いて、前に受け入れられた可能な修復をテストする
    ことを更に有する、請求項９に記載の方法。
13. 人間が生み出した１つ以上のテストオラクルを用いてソフトウェアプログラムをインタラクティブに修復するよう構成されるシステムであって、
    命令を記憶するよう構成される１つ以上のコンピュータ可読記憶媒体と、
    前記命令を実行するよう構成される１つ以上のプロセッサと
    を有し、
    前記命令の実行は、当該システムに、
    ソフトウェアプログラム内の欠陥箇所を特定し、
    第１修復候補に基づき、前記欠陥箇所で、第１の可能な修復を生成し、
    前記第１の可能な修復をテストするよう第１テストを生成し、
    前記第１テストに基づき、第１テストオラクルのための第１クエリを生成し、
    前記第１クエリに対する応答を人間から取得し、
    前記第１クエリ及び該第１クエリに対する前記取得された応答に基づき、人間が提供した第１テストオラクルを生成し、
    拡張された第１テストを生成するよう、前記人間が提供した第１テストオラクルを前記第１テストに加え、
    前記拡張された第１テストを含むようテストスイートを増補し、
    前記拡張された第１テストを含む前記増補されたテストスイートを用いて、前記第１の可能な修復をテストする
    ことを含む動作を実行させる、システム。
14. 前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを前記第１の可能な修復が通過することに応答して、前記第１の可能な修復を第１の適切な修復として受け入れることを更に含む、
    請求項１３に記載のシステム。
15. 前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを前記第１の可能な修復が通過しないことに応答して、前記第１の可能な修復を不適切な修復として拒絶することを更に含む、
    請求項１３に記載のシステム。
16. 前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを前記第１の可能な修復が通過することに応答して、
    前記第１の可能な修復をテストするよう第２テストを生成し、
    前記第２テストに基づき、第２テストオラクルのための第２クエリを生成し、
    前記第２クエリに対する応答を人間から取得し、
    前記第２クエリ及び該第２クエリに対する前記取得された応答に基づき、人間が提供した第２テストオラクルを生成し、
    拡張された第２テストを生成するよう、前記人間が提供した第２テストオラクルを前記第２テストに加え、
    前記拡張された第２テストを含むよう、前記増補されたテストスイートを増補する
    ことを更に含む、
    請求項１３に記載のシステム。
17. 前記動作は、前記拡張された第２テストを含む前記増補されたテストスイートを用いて、前記第１の可能な修復をテストすることを更に含む、
    請求項１６に記載のシステム。
18. 前記動作は、
    第２修復候補に基づき、前記欠陥箇所で、第２の可能な修復を生成し、
    前記拡張された第１テストを含む前記増補されたテストスイートを用いて、前記第２の可能な修復をテストする
    ことを更に含む、
    請求項１３に記載のシステム。
19. 前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを前記第２の可能な修復が通過することに応答して、前記第２の可能な修復を第２の適切な修復として受け入れることを更に含む、
    請求項１８に記載のシステム。
20. 前記動作は、前記拡張された第１テストを含む前記増補されたテストスイートを用いて、前に受け入れられた可能な修復をテストすることを更に含む、
    請求項１３に記載のシステム。

Images