コラム

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

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

CTC 教育サービス

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

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

はじめに

　今回は、2019年に公開された論文「Assessing Transition-based Test Selection Algorithms at Google」を紹介します。ここでは、Google社内のCI（Continuous Integration/継続的インテグレーション）環境で収集したデータを用いて、ソフトウェアのテストに必要となるリソースを削減するために、「安全」にテストをスキップするアルゴリズムの性能評価を行っています。

Googleにおけるテスト環境

　まず、Google社内のCI環境については、第37回の記事「継続的インテグレーションを支える自動テスト環境」を参照してください。Google社内で開発されるソフトウェアのソースコードは、単一のリポジトリで管理されており、複数のプロジェクトにまたがってライブラリモジュールの共有が行われます。そして、あるモジュールのソースコードが変更されると、それに依存するすべてのソースコードに対するテストが自動的に再実行されます。1日あたり、約1万3千個のプロジェクトにおける、約80万回のビルド処理があり、それに伴うおよそ1億5千万個のテストが実行されるそうです。
　これだけのテストを実行するには膨大なリソースが必要となり、テストの結果が得られるまでの時間も長くなります。しかしながら、実際に問題が発見されるテストはごく一部ですので、「安全」と思われるテストをスキップすることで、テストに必要なリソースを削減すると共に、問題が起きる可能性が高いテストを集中的に実施することで、開発者へのフィードバックを早めることができます。さきほどの記事では、変更されたコードとそれに依存してテストが必要となるコードについて、それらの依存関係の「距離」に基づいて、実行するテストを選択する手法が紹介されています。
　この手法の有効性については、過去のテストデータの分析から明らかになっていますが、この他にも、よりシンプルで有効性が高い手法があるかも知れません。冒頭の論文では、過去のテストデータを用いて、スキップするテストを選び出す複数の手法について、その有効性を比較しています。その結果として、「Flaky（不安定な）テスト」を取り除いた分析が重要な事、そして、テストに影響を与えるコードの変更数、および、それに関わる開発者の人数がテスト結果に強い影響を与えることが報告されています。次回以降の記事でこれらの結果について詳しく説明していきますが、今回はまず、過去のテストデータを用いた評価方法を説明します。

テストデータの構成

　はじめに、過去のテストデータの構成を説明します。第37回の記事に説明があるように、Googleの開発環境では、コードの変更がコミット（Commit）されたタイミングですぐにテストが実行されるわけではありません。一定時間ごとに発生するマイルストーンにおいて、それまでのコミットに伴うテストをまとめて実行します。したがって、テスト結果が以前と変わった場合、どのコミットによる影響かがはっきりしない場合があります。たとえば、図1では、ある特定のテストターゲット（テスト項目）に対するテスト結果を時系列で示しており、ここでは、Commit1, 2, 3, 5, 7のタイミングでマイルストーンが発生したという想定になります。

fig01

図1 テスト結果の変化の例（論文より抜粋）

　ここで重要になるのは、テスト結果が「成功（P）から失敗（F）に変化したコミット（バグが混入したコミット）」、および、「失敗（F）から成功（P）に変化したコミット（バグの修正に成功したコミット）」を発見することです。一般にひとつのコミットは複数のテストターゲットを含むので、その中から「結果が変化する可能性が高いターゲット」を選び出すアルゴリズムがあれば、逆に変化する可能性が低いものを選んで、それらを安全にスキップすることができます。
　たとえば、Commit1とCommit2を比較すると、Commit1はテストに成功（P）しており、次のCommit2も変わらず成功（P）しています。したがって、Commit2では、このターゲットはスキップしても問題ありません。一方、次のCommit3ではテストが失敗（F）しているので、このターゲットをスキップすると、Commit3で混入したバグを見逃すことになります。図1のそれぞれのテスト結果に示された「Safe」「Unsafe」というフラグは、このような意味で、そのターゲットを安全にスキップできるかどうかを表します。
　次に、Commit4とCommit5を見ると、Commit5では、テストはまだ失敗したままです。Commit4に対するテスト結果のデータはありませんが、ここでは、「Commit4で成功に変わったものが再びCommit5で失敗した」という可能性は除外して、Commit4, 5ともに失敗（F）だと仮定します。したがって、Commit4, 5では、このターゲットは安全にスキップすることができます。失敗するテストを「安全にスキップできる」というのは違和感があるかもしれませんが、これらのコミットでバグが混入したわけではなく、また、これらのコミットでバグが修正されたわけでもありません。つまり、テストの失敗とこれらのコミットには何の関係もありません。
　そして最後に、Commit5ではテストに失敗（F）していますが、その後のCommit7では成功（P)しています。この場合、失敗から成功に変わったのが、Commit6によるものかCommit7によるものかがはっきりしません。そこでこれらについては、「Maybe unsafe」というフラグをつけています。

アルゴリズムの評価方法

　最終的な目標としては、「Safe」フラグがついたターゲットをうまく選び出すアルゴリズムを発見することになります。一例として、図2のように、複数のターゲットを含む一連のコミットがあった際に、あるアルゴリズムでテストをスキップするターゲットを選んだ場合に、「結果が変化しない（Safeフラグが付いた）ターゲットだけがスキップされたコミットの割合」を計算することができます。この図の例であれば2/3になりますが、この割合が高いほど、優秀なアルゴリズムということになります。

fig02

図2 アルゴリズムの性能を測る方法

　ただし、実際にスキップするターゲットがごくわずかであれば、この割合がいくら高くても意味がありません。それぞれのアルゴリズムでは、コミットに伴うテストターゲットごとにスキップに対する「安全率」を計算して、すべてのターゲットを安全率の高い順にソートします。そして、この順序に従って、一定の割合（たとえばすべてのターゲットの30%）を強制的にスキップした場合に、「Safeのみがスキップされたコミットの割合」がどのようになるかを計測します。

次回予告

　今回は、2019年に公開された論文「Assessing Transition-based Test Selection Algorithms at Google」に基づいて、安全にスキップできるテストを選択するアルゴリズムに対して、過去のテストデータからその性能を評価する方法を説明しました。次回は、冒頭で触れたFlakyテストの影響と実際の評価結果を紹介します。

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