中国科学院は、プログラマーがバグを見つけるのを助けるために大きなモデルを使用し、102の論文を分析し、これらの解決策をまとめた。

中国科学院は「バグ発見」に着手し、一気に N 個の解決策をまとめました。

魔法の武器は大きなモデルです。

優れた自然言語理解・推論機能により、大規模なモデルがさまざまなシナリオに適用され、これまでにない成果を達成しました。

同様に、ソフトウェア テストの分野でも、その強力な機能の恩恵を受けることができ、現実的で多様なテスト入力の生成、さまざまな異常のシミュレーション、欠陥の発見の加速、テストの効率性の向上、ソフトウェアの品質の向上に役立ちます。

中国科学院ソフトウェア研究所、オーストラリアのモナッシュ大学、カナダのヨーク大学の研究チームは、2023年10月30日時点で発表された関連論文102件を収集し、ソフトウェアテストと大規模モデルの観点から総合的な分析を行い、ソフトウェアテスト分野における大規模モデルの応用に関する総合的なレビューをまとめた。

（論文のアドレスは記事の最後にあります）

調査の結果、概要は次のようになりました。

詳細については読み続けてください。

ソフトウェアテストの観点から

まず、研究者らはソフトウェアテストの観点から分析を行い、収集した研究成果をテストタスクごとに整理しました。

下の図に示すように、ビッグモデルの適用は主にソフトウェアテストライフサイクルの後半に集中しており、テストケースの準備（ユニットテストケースの生成、テストオラクルの生成、システムレベルのテスト入力の生成を含む）、テストレポートの分析、プログラムのデバッグと修復などのタスクに使用されます。しかし、テストライフサイクルの初期タスク（テスト要件、テスト計画など）に大規模な言語モデルを使用する関連研究はありません。

さらに、研究者らは、さまざまなソフトウェアテストタスクにおける大規模モデルの適用についても詳細な分析を実施しました。

ユニット テスト ケースの生成を例にとると、ユニット テスト ケースの生成タスクでは、主に独立したソフトウェアまたはコンポーネント ユニットのテスト ケースを記述して、その正確性を確認します。従来の検索ベース、制約ベース、またはランダム生成手法では、テストケースのカバレッジが弱かったり、読みにくかったりする問題がありました。

ビッグモデルの導入後、従来の方法と比較して、ビッグモデルはドメイン知識をよりよく理解してより正確なテストケースを生成できるだけでなく、ソフトウェアプロジェクトとコードコンテキストの情報も理解してより包括的なテストケースを生成することができます。

システムレベルのテスト入力の場合、一般的な手法であるファズテストは、主に無効、予期しない、またはランダムなテスト入力を生成してテストの目的を達成することに重点を置いています。研究者らは、大規模モデルが従来のファズテスト技術をどのように改善できるかについても詳細に分析しました。

たとえば、Fuzz4All や ChatFuzz などの一般的なファズ テスト フレームワークを提案した研究もあれば、ディープラーニング ライブラリ、コンパイラ、ソルバー、モバイル アプリケーション、サイバー フィジカル システムなどの特定のソフトウェア開発向けの大規模モデルに基づくファズ テスト テクノロジに焦点を当てた研究もあります。

これらの研究の焦点の 1 つは、多様なテスト入力を生成してカバレッジを高めることです。これは通常、突然変異技術と大規模モデルに基づく生成を組み合わせることで実現されます。もう 1 つの焦点は、エラーを早期にトリガーできるテスト入力を生成することです。一般的な方法は、過去にエラーをトリガーしたプログラムを収集して大規模モデルを微調整するか、大規模モデルをクエリするときにデモ プログラムとして使用することです。

この論文では、さまざまな研究の技術的なアイデアをより詳細に紹介し、比較しています。

ビッグモデルの観点から

続いて、研究者らは、ソフトウェアテストタスクで選択されたビッグモデルをビッグモデルの観点から分析し、さらに、迅速なエンジニアリング技術、ビッグモデルの入力、従来のテスト技術との組み合わせなど、ビッグモデルをテストタスクに適応させる方法を紹介しました。

選択された大規模モデルに関しては、下の図に示すように、最も一般的に使用されている上位 3 つの大規模モデルは ChatGPT、Codex、および CodeT5 です。後者の 2 つは、複数のプログラミング言語のコードコーパスで特別にトレーニングされた大規模なモデルです。自然言語の記述に基づいて完全なコードスニペットを生成できるため、テストケースの生成や欠陥の修復など、ソースコードを含むテストタスクに非常に適しています。

さらに、GPT-4（4位）を使用した研究は14件あるが、大規模なマルチモーダルモデルとして、ソフトウェアテストタスクにおける画像関連機能（UIスクリーンショット、プログラミングデモンストレーションなど）の使用を調査する関連研究は見つかっていないと研究者らは述べており、これは今後の研究で調査する価値があるという。

大規模モデルの動作をソフトウェア テスト タスクに適合するように調整する方法に関しては、主に事前トレーニングまたは微調整とプロンプト エンジニアリングという 2 つの技術的手段があります。

下の図に示すように、38 件の研究では事前トレーニングまたは微調整を使用して大規模モデルの動作を微調整し、64 件の研究ではヒント エンジニアリングを使用して大規模モデルをガイドし、目的の結果を達成しました。

プロンプトエンジニアリング技術の主な利点は、モデルの重みを更新せずに大規模モデルを特定の分野やタスクに適応させ、大規模モデルの理解力と推論力を高めることができることです。現在使用されている技術には、ゼロサンプルまたは少数サンプル学習、自己一貫性、思考連鎖、自動プロンプトなどの技術が含まれます。

さらに研究者らは、35 件の研究で、大規模なモデルの使用に加えて、突然変異テスト、差分テスト、プログラム分析、統計分析などの従来のテスト手法を組み合わせて、テストの有効性と範囲を向上させていることを発見しました。

大規模モデルはさまざまなタスクで大きな可能性を示していますが、複雑なプログラム構造を理解して処理することが難しいなど、依然としていくつかの制限があります。

したがって、大規模なモデルは他の技術と組み合わせて、その長所を最大限に活かし、弱点を回避し、現実世界のシナリオをより適切にシミュレートする、より多様で複雑なコードを生成するなど、特定の状況でより良い結果を達成します。

大規模モデルでバグを見つける際に、他にどのような課題がありますか?

過去 2 年間で、ソフトウェア テストに大規模なモデルを使用する成功した事例が数多くありました。しかし研究者らは、この技術はまだ開発の初期段階にあり、探求すべき課題や未解決の問題が数多くあると指摘している。

課題1: 高いカバレッジを実現することの課題

テスト対象ソフトウェアの多様な動作を調査して高いカバレッジを達成することは、常にソフトウェア テストの重要な焦点となっています。大規模なモデルで必要な多様性を直接実現することは、依然として非常に困難です。たとえば、ユニット テスト ケースの生成では、SF110 データセットの行カバレッジはわずか 2%、分岐カバレッジはわずか 1% です。

体系的なテスト入力生成に関しては、ディープラーニングライブラリのファズテストの場合、TensorFlow の API カバレッジは 66% (2215/3316)です。既存の研究では、突然変異テストと大規模モデルを組み合わせて、より多様な出力を生成することがよくあります。

その他の潜在的な研究の方向性としては、テスト関連のデータを活用して、テストの特性を理解し、テストの要件を理解し、多様な出力を自律的に生成できる特殊な大規模モデルをトレーニングまたは微調整することが挙げられます。

チャレンジ2: Oracleチャレンジのテスト

テストオラクルの問題は、さまざまなテストアプリケーションが常に直面している課題です。既存の作業における一般的なアプローチは、それをよりアクセスしやすい形式に変換することです。通常は、差分テストを通じて実装するか、自動的に識別しやすいテストオラクル（クラッシュタイプのエラーなど）のみに焦点を当てます。これは良い結果を達成しましたが、いくつかのケースにしか適用できません。

他の種類のテスト予測問題を解決するために、大規模なモデルの使用を検討することは価値があります。

たとえば、メタモルフォーシス テストも、テスト予測の問題を軽減するためによく使用されるテクノロジです。人間とコンピューターのインタラクションやドメイン知識を組み合わせることで、メタモルフォーシス関係の自動生成を探索できます。また、大規模なモデルを探索して、メタモルフォーシス関係に基づいてテスト ケースを自動的に生成し、さまざまな種類の入力をカバーすることもできます。さらに、GPT-4 のような大規模なマルチモーダル モデルは、ユーザー インターフェイス関連の欠陥を検出し、テスト予測を導き出すのに役立つ可能性も提供します。

課題3: パフォーマンスを正確に評価する

△この画像はGPT-4 AIによって生成されました

ベンチマーク データセットの不足と、大規模なモデルベースの手法における潜在的なデータ漏洩の問題により、厳密で包括的なパフォーマンス評価を実施することが困難になっています。研究者らは、大規模モデルのトレーニング用のデータ ソース CodeSearchNet と BigQuery をチェックした結果、Defect4J ベンチマーク データセットで使用されている 4 つのコード ベースも CodeSearchNet に含まれており、Defects4J のコード ベース全体が BigQuery に含まれていることを発見しました。

そのため、大規模モデルでは事前トレーニング プロセス中に既存のプログラム修復ベンチマーク データセットが確認されており、深刻なデータ漏洩の問題が発生しています。そのため、より専門的かつ多様なベンチマークデータセットを構築し、データ漏洩を防ぐ対策を講じる必要があります。

課題4: 実際のプロジェクトにおける課題

データのプライバシーに関する懸念から、実際のアプリケーションを検討する場合、ほとんどのソフトウェア組織は、商用の大規模モデルの使用を避け、オープンソースの大規模モデルを採用し、組織固有のデータを使用してトレーニングまたは微調整することを好む傾向があります。

さらに、コンピューティング能力の限界やエネルギー消費への懸念から、中規模モデルを採用する傾向にある企業もあります。このような現実的な条件下では、既存の研究で報告されているものと同様のパフォーマンスを達成することは非常に困難です。たとえば、広く使用されている QuixBugs データセットでは、40 個の Python エラーのうち 39 個と 40 個の Java エラーのうち 34 個を自動的に修正できます。

しかし、Stack Overflow から収集されたディープラーニング プログラム(実際のコーディング プラクティスを表す)に関しては、72 個の Python エラーのうち 16 個だけが自動的に修正できました。実際のニーズにもっと注意を払い、対応する技術を開発する方法は、技術の実装と実用化にさらに役立ちます。

大規模モデルは研究の機会ももたらす

ソフトウェア テストに大規模なモデルを使用すると、多くの研究機会が生まれ、ソフトウェア テスト分野の発展に大きなメリットをもたらします。

機会 1: より多様なソフトウェア テスト タスクとフェーズに大規模なモデルを活用する

テストミッションの初期段階では、大型モデルはまだ効果的に使用されていません。主な理由は 2 つあります。1 つ目は、初期のテスト タスクが主観的であるため、専門家の評価が必要になること、2 つ目は、初期段階でオープン データ リソースが不足しているため、大規模モデルのパフォーマンスが制限されることです。

また、下図に示すように、大規模モデルは単体テストやシステムテストでは広く使用されているものの、統合テストや受け入れテストでは比較的使用頻度が低いことがわかります。つまり、より多様なソフトウェア テスト タスクとテスト フェーズに大規模なモデルを最大限に活用する方法は、綿密な研究に値する新しい方向性です。たとえば、受け入れテストでは、大規模なモデルが人間のテスターと連携して、テストケースを自動的に生成し、テスト範囲を評価できます。

機会2: 大規模なモデルをより幅広いテストタイプとソフトウェアに適用する

一方、ビッグモデルは機能テストでは広く使用されていますが、パフォーマンステストやユーザビリティテストなどの他の分野ではあまり使用されていません。これは、これらのテストに特化した適切なモデルとツールがすでにいくつかあるためであると考えられます。

ただし、ビッグモデルを使用してパフォーマンステストツールを統合したり、実際のユーザーの動作をシミュレートしてさまざまな種類のワークロードを生成したりするなど、ビッグモデルとこれらのツールを組み合わせることは、潜在的な研究方向として残っています。他の

一方で、下図に示すように、モバイルアプリケーション、ディープラーニングライブラリ、自動運転システムなど、さまざまな種類のソフトウェアテストに大規模モデルを適用して成功した研究もあります。既存の技術を他の種類のソフトウェアに移行できるだけでなく、特定の種類のソフトウェアの特性に基づいてターゲットを絞った技術を開発することもできます。

機会3：高度な迅速なエンジニアリング技術を統合する

既存の研究では、大規模モデルの可能性はまだ十分に検討されておらず、下の図に示すように、最も一般的なプロンプト エンジニアリング手法のうち 5 つだけが使用されています。今後の研究では、大規模モデルの理解力と推論力をより効果的に発揮または強化するために、より高度なプロンプト エンジニアリング手法(図の思考ツリーやマルチモーダル思考チェーンなど)を検討する必要があります。

機会4: 従来の技術との組み合わせ

現時点では、大規模モデルがソフトウェア テストの問題を解決できるかどうかについては明確なコンセンサスがありません。一部の研究では、大規模モデルと従来のソフトウェア テスト手法を組み合わせることで良好な結果が得られており、これは大規模モデルがソフトウェア テストの問題を解決するための唯一の万能薬ではないことを意味している可能性があります。

成熟したソフトウェアエンジニアリング関連の技術やツールが数多くあることを考慮すると、大規模なモデルと従来の技術（既存の研究では検討されていない形式検証など）を組み合わせたり、他のより高度な組み合わせを検討したり、ツールと統合して既存のツールの可能性をよりよく検討したりすることができます。

論文Arxivリンク: https://arxiv.org/abs/2307.07221.
GitHub リンク: https://github.com/LLM-Testing/LLM4SoftwareTesting。