機械学習を使用して、コードの変更に対するテストの動作を予測できる。これらの予測は、チェックイン時に情報を提供することで、開発者へのフィードバック時間を短縮する。Marco Achtziger氏とDr. Gregor Endler氏は、OOP 2020で失敗から学ぶために機械学習をどのように使用しているかを発表した。
ソフトウェア変更の実際の影響を判断するのは難しい場合がある。機械学習は、コードの変更がテスト結果に与える影響を特定する問題にかなり適していると、Endler氏は説明した:
ソフトウェアの開発とテストのプロセスから自動的に発生する大量のデータがあります。さらに、予測しようとしているもの (テストケースの結果) はとにかく履歴データに存在するため、トレーニングデータに手動で注釈を付ける必要もありません。
これらは、ソフトウェア開発プロジェクトからのデータを使用して、ソフトウェアの非自明な依存関係に光を当て、影響を受ける可能性のあるテストケースについて事前に警告する。フィーチャーベクトルは、ソース管理システムからのコミットに関するメタデータで構成される。予測するクラスは、テスト実行データから取得したテストの結果である。これらはテストケースごとにバンドルされ、テストケースとMLアルゴリズムごとに1つのモデルがある。
開発者は、コードによってテストが失敗するかどうかを予測する機械学習についてどのように感じているのでしょうか? Achtziger氏は、システムを使用しているテスタや開発者から得たフィードバックについて次のように述べている:
このアプローチの利点を理解し、提供された情報を使用する人はかなりいます。しかし、もちろん、システムが変更が完全に正しくないと彼らに告げるのを嫌う人もいます。しかし、追加の入力の利点を示すことで、間違いを犯すのではなく、私たちがすでに持っている情報から学ぶことについて納得することができます。
InfoQはOOP 2020での講演の後、Marco Achtziger氏とDr. Gregor Endler氏にインタビューした。
InfoQ: ソフトウェア変更の影響を判断するために機械学習を使用することにした理由は何ですか?
Marco Achtziger氏: 私が取り組んでいるプロジェクトでは、レガシーコンポーネントと新しく開発されたパーツで構成される巨大なソフトウェアシステムを維持および進化させています。もちろん、コモディティパーツ (正当な理由なしに変更したくないシステム内の領域) も特定して、開発者が顧客に必要なイノベーションの一部ではない領域で作業しすぎないようにします。ただし、開発者がコモディティ領域またはシステムのレガシー部分 (通常はコードがそれほど頻繁に変更されず、影響を予測するのが難しい場合がある) のコードで作業する必要がある場合、コーディングによって望ましくない副作用が発生しないようにしたかったのです。
そうは言っても、テストの影響予測をより効率的にする必要があると考えました。とにかくソフトウェア開発のデータを集めているので、これを活用することを考えました。大量のデータについて話すとき、人間でそれを行うことはもはや不可能であり、それが機械学習のような技術の使用が思い浮かびました。
Gregor Endler氏: Achtziger氏がすでに述べたように、この問題は人間が解決するのは困難です。テスト結果が常に明確であれば、テストケースを実行する必要はありません。
InfoQ: どのような異なるアプローチを取り、それはどのように機能しましたか?
Achtziger氏: 最初に、非常に単純にすべてのデータをアルゴリズムにスローするだけのことを試しました。もちろん、それを構造化し、データ間の依存関係を透過的にすることにかなりの努力を払いました。しかし、結局、これは実際にはポイントに達していないことが判明しました。そのため、最初からやり直して、最初に何についての答えがほしいかを考えなければなりませんでした。これが基本的に、コードの変更に対するテストの動作です。そのため、データを再検討し、そのために何が必要かを判断しました。結局、私たちはいくつかのデータソースを捨てて、必要だと思った元のデータソースのうちの2つだけを使用しました。このようにすることで、私たちの質問に答えることができるデータの相互接続がはるかに簡単になりました。
Endler氏: 最初のアプローチでは、特に、接続されたアーキテクチャユニットと関連するテスト結果およびコード変更のグラフを作成することにより、ソフトウェア間のアーキテクチャの依存関係を考慮に入れようとしました。次に、グラフアルゴリズムとベイズ推論を使用して、テスト結果を予測しました。これにより、精査中のアプリケーションの興味深いビューが提供されましたが、残念ながら、予測力が不足していました。結果の大部分は誤検知でした。それでも、基本的なアプローチを信じていたので、データの収集と予測のプロセスをもう一度検討し、問題を「より伝統的な」方法で突き止めることにしました。教師あり機械学習を分類タスクに使用することです。テスト結果を予測するタスクをどれだけうまく実行できるかを評価するために、さまざまなデータシナリオと決定木、ランダムフォレスト、ニューラルネットワークなどのさまざまなアルゴリズムを実験しました。
InfoQ: どのテストケースが失敗するかを予測するためにどのデータを使用しますか?
Achtziger氏: 最終的に、必要なのはテスト実行データ (特定のテストが特定のソースコードリビジョンでどのような結果を示したか) とソース管理メタデータ自体だけであるという結論に達しました。そのため、たとえば、欠陥/変更管理データのように自ずと適合しているように見えるものは、現在まったく使用されていません。これら2つのデータソースで必要な情報の抽出が非常に簡単なことが利点です。
Endler氏: 機械学習の観点から、教師あり学習に必要なフィーチャーベクトルは、コミットに関するメタデータ (2つほど例をあげると、ファイルの数やファイルの平均経過時間など) で構成されます。これは、ソース管理システムから取得されます。予測したいクラスは、テスト実行データから取得したテストの結果です。これらのデータをテストケースごとにバンドルします。つまり、評価するテストケースとMLアルゴリズムごとに1つのモデルを取得します。
フィーチャーは、ドメインの知識と直感から生まれます。「より大きなコード変更はより多くのものを壊す可能性がある」のように。ただし、現時点では、フィーチャーはコミットの説明にすぎません。特定のテストケースの結果を説明できるかどうかは、存在する他の機能、合計トレーニングデータ、学習に使用されるアルゴリズムによって異なり、個別のテストデータとトレーニングデータを使用して機械学習システムを評価することで確認されます。
InfoQ: 開発者とテスタはこれらの予測についてどう思いますか?
Endler氏: 注意すべき興味深い点の1つは、カンファレンスでシステムをプレゼンテーションするときに得られるさまざまな質問です。テスタに焦点を当てたカンファレンスでは、質問は (予想どおり) 「テストケースの品質は、簡単に予測できるかどうかで判断できますか」のようにテストケースに焦点を当てていました。一方、開発者は、フィードバックサイクルの時間や、データ統合などの実装に重点を置いたものについて質問する傾向があります。全体として、話し合いの後に得られるフィードバックは非常に肯定的な傾向があります。
InfoQ: チェックイン前にテストケースの失敗を予測することでどのような利点がありますか?
Achtziger氏: 現在、私たちの主な焦点は、開発者の変更に関するフィードバック時間の短縮です。残念ながら、特定の変更についてテスト実行からフィードバックを取得するのに3〜4日 (またはそれ以上) かかるシステムがあります。したがって、チェックイン時に前もってこの情報を提供することには明らかな利点があります。
Endler氏: テストの実行に「たった」数時間の場合でも、システムは開発者に情報をより迅速に提供することで、自分のコードに慣れるために費やす時間を削減できます。完成したモデルから予測を取得するには、数秒しかかかりません。
もちろん、システムのトレーニングには時間がかかりますが、これはオフラインで行われ、たとえば夜間に実行することができます。これにより、頻繁に再トレーニングすることもできます。これは、テストの動作が変わる可能性があるため必要です。たとえば、テストに関連するコード領域の変更が時間の経過とともに少なくなるため、テストが安定する場合があります。
また、システムに必要なデータ統合プロセスには、テストとコミットがプロジェクトで相互作用する方法に関する非常に多くの情報を提供するため、いくつかの興味深い、たとえば不安定なテストについての情報の提供があるといった「二次的な」利点があります。