コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第80回　CI環境のテストを安全に効率化するアルゴリズム（パート3）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第80回　CI環境のテストを安全に効率化するアルゴリズム（パート3） (中井悦司) 2020年4月

はじめに

　前回に続いて、2019年に公開された論文「Assessing Transition-based Test Selection Algorithms at Google」を紹介します。前回までは、「安全にスキップできるテストターゲット」を判別するアルゴリズムについて、その評価方法を説明した上で、いくつかのアルゴリズムを比較した結果を紹介してきました。今回は、個々のアルゴリズムの中身を解説します。

評価対象のアルゴリズム

　まずは、前回の図2を振り返ってみましょう。この図には、次のアルゴリズム名が登場しています。

・Random
・Transition count
・Affected count
・Author count
・Presubmit history
・Shared dirs

　この中でも「Affected count」と「Author count」が、他と比べて優秀な結果を示していましたが、ここでは、その他のアルゴリズムも含めて、それぞれの概要を解説していきます。

判別アルゴリズムの概要 --- 性能がよくなかった例

　はじめに「Random」は、その名前の通りスキップする対象をランダムに選ぶもので、比較用のベースラインとなります。前回の図2を見ると、たとえば、「Shared dirs」は「Random」とほぼ同等の結果になっていることから、この手法は、アルゴリズムとしてあまり意味をなさないことがわかります。「Shared dirs」では、変更があったソースコードファイルのディレクトリ名（フルパス名）とテスト対象となるパッケージのソースコードファイルが入ったディレクトリ名（フルパス名）を比較して、共通部分が多いほど、このテストは変更の影響を受けやすい、すなわち、スキップするのは危険であると見なします。
　一般に、変更された部分とテスト対象の部分が持つ関連性が高いほど、そのテストは変更の影響を受けやすいと考えられますが、ディレクトリ名から関係性を判別するというこの手法の問題は、「関係が近すぎるテスト」だけが選ばれる点だと論文内で指摘されています。特に今回のシミュレーションでは、変更したコードをリポジトリにコミットする前に、開発者の環境において、「変更したコードが属するモジュールそのもののテスト」は事前に実行されているという想定です。変更に直接起因する問題はこの時点でチェックされていますので、コミット後のテストで再度チェックしても結果が変化する可能性はほとんどありません。
　ちなみに、実際のGoogleの環境では、モジュール間の依存関係を用いて、変更されたコードとテスト対象の「距離（依存関係のホップ数）」を計算しています。詳細は「第38回　継続的インテグレーションを支える自動テスト環境（パート2）」にありますが、ここの図3を見ると、ホップ数が4前後のテストが最も影響を受けやすいことがわかります。
　続いて、「Presubmit history」は、コミット前のテストで結果が変化したものをもう一度、コミット後のテスト対象にするというものですが、これは同じ理由でうまくいきません。コミット前のテストでは、変更したコードが属するモジュールのテストしか実行されませんので、そのほかのテストについては、何も指標がなく、ランダムにスキップするものが選ばれることになります。
　次に、「Transition count」は、「直近で結果が変化したテストは、今回も結果が変化する可能性が高い」という考え方に基づきます。より正確には、対象となるテストターゲットについて、過去の一定期間に結果が変化した回数を調べて、その回数が多いほど、スキップするのは危険であると見なします。この方法では、前回説明した「Flakyテスト」は常に危険度が高くなりますが、ここでは、Flakyテストの影響を取り除いて評価している点に注意してください。このアルゴリズムもまた、あまり良い性能が得られていません。Flakyテストを別にすれば、テスト結果が変化するというのは、（テスト全体の総数を考えると）ごくまれな現象であり、適切な判断を行うには、これだけでは情報量が少なすぎる点が論文内で指摘されています。

判別アルゴリズムの概要 --- 性能がよかった例

　ここまでの説明でわかるのは、コードとテストの「距離」や過去のテスト結果と言った「静的」な情報ではなく、コードの変更状況を示す、より「動的」な情報が必要ということです。この点を考慮したのが「Affected count」と「Author count」です。まず、「Affected count」は、過去の一定期間において何度もテスト対象になったターゲットは、（結果の変化に関わらず）スキップしない方がよいという考え方です。テスト対象になる回数が多いということは、そのテストに影響を与えるソースコードが頻繁に変更されている、すなわち、活発に開発されていると考えられます。したがって、テスト結果を変化させるような重大な変更が入る可能性が高いと考えるわけです。「Author count」は、この考え方を発展させたもので、ソースコードの変更に関わった開発者の数を考慮します。つまり、多数の開発者が変更に関わるほど、テスト結果への影響はより大きくなると考えるのです。
　それほど特別な計算をしているわけではありませんが、結果として、これらのアルゴリズムは他よりもよい性能が得られています。Googleの環境では、専用のビルドシステムが整っており、コード間の依存関係（ホップ数）を厳密に評価することができますが、一般の開発環境でこれと同じ仕組みを実現するのは難しいこともあります。この論文でのシミュレーションにより、過去にテスト対象になった回数、あるいは、コードを変更した開発者の数など、より簡単に計算できる指標が効果を発揮する可能性が示されたことになります。

次回予告

　今回は、2019年に公開された論文「Assessing Transition-based Test Selection Algorithms at Google」で示された、「スキップ対象のテスト」を判別するアルゴリズムについて、それぞれの概要を説明しました。より具体的なアルゴリズムの中身、あるいは、得られた結果に対する考察については、論文の方もぜひ参照してください。
　次回は、データセンターの電源設備に関する話題をお届けしたいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡