コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第38回　継続的インテグレーションを支える自動テスト環境（パート2）

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

CTC 教育サービス

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

第38回　継続的インテグレーションを支える自動テスト環境（パート2） (中井悦司) 2018年5月

はじめに

　前回に引き続き、2017年に公開された論文「Taming Google-Scale Continuous Testing」をもとにして、Google社内の開発チームが活用する自動テストのインフラ環境を紹介します。

　前回説明したように、Google社内の開発環境における自動テストは、「Test Automation Platform (TAP)」と呼ばれるシステムによって管理されており、一定の間隔で発生するマイルストーンごとに複数のテスト処理がまとめて実行されます。この際、マイルストーンの間隔を短くするとテストに必要なリソースが膨大になり、一方、マイルストーンの間隔を長くすると、問題を発見するまでの時間が長くなるというトレードオフが発生します。本論文を執筆したTAPシステムのチームは、このトレードオフの解決策を見つけるために、過去のテスト結果に対する分析を行いました。今回は、この中から主要な分析結果を紹介していきます。

テストデータの分析結果

　前回紹介したように、TAPシステムでは、1日あたり約1億5千万個のテストが実行されています。前述のトレードオフの解決にあたり、TAPシステムのチームが注目したのは、これらすべてに共通のマイルストーンを適用することが妥当なのかという点です。容易に想像できるように、これらのテストの大部分は成功して終わります。場合によっては、ほとんど失敗する可能性のないテストが何度も繰り返し実行されることもあるでしょう。失敗する可能性が高いテストを何らかの方法で見つけ出すことができれば、これらについては、より短い間隔でマイルストーンを適用して、その他のテストにはより長い間隔でマイルストーンを適用するという戦略を取ることが可能になります。

　そこで、TAPシステムのチームでは、テストの失敗に影響を与える要因についていくつかの仮説を立てて、過去のテスト結果を用いてそれらを検証していきました。具体的には、2016年2月の1ヶ月間に実行されたテスト結果のデータを分析しました。そこには、550万種類以上のテストに対する、合計約4億回の実行結果が含まれており、このデータを分析した結果、次のような事実が明らかになりました。

550万種類のテストの内、実際に失敗が発生したものは6万種類程度。また、4億回のテスト全体において、開発者によるコードの変更に起因して失敗したものは、その中の1.23%。
変更されたコードからの依存関係が遠い（10ホップ以上）のテストはほとんど失敗することがない。
頻繁に変更されるコードは、テストの失敗を引き起こす可能性が高い。特に、短期間に3人以上の開発者が変更を加えたコードは、テストの失敗を引き起こす可能性が著しく高くなる。
特定のファイルタイプ、ツール、開発者が高い割合でテストの失敗を引き起こすことがある。

　これらの結果は、Googleでの開発環境に特有の部分もあり、すべての環境にあてはまるというわけではありませんが、具体的な分析の内容には興味深い点があります。ここでは、論文に掲載されているデータとあわせて、いくつかの具体例を紹介したいと思います。

分析結果の具体的な内容

　まず、失敗したテストの割合に関するデータが図1になります。「PAASED」は成功したテスト、「AFFECTED_TARGET」は、前回説明したマイルストーンの仕組みにより「AFFECTED」のフラグが付与されただけで実際にはテストされなかったもの、「SKIPPED」は開発者の指定などにより、テストの実行が省略されたもの、そして、「FAILED」がテストに失敗したものです。このグラフは縦軸が対数スケールになっており、「FAILED」は「PASSED」の100分の1以下であることが読み取れます。

fig01

図1 テスト結果の分布（論文より抜粋）

　次は、変更されたコードからの依存関係の「距離」です。これも前回説明しましたが、TAPシステムでは、あるコードが変更されると、そのコードそのものに対するテストに加えて、そのコードに依存するモジュールのテストがあわせて行われます。モジュールの依存関係をたどることで、依存関係のあるモジュールすべてのテストが再実行されるわけです。この際、依存関係が離れるに従って、コード変更の影響はより小さくなるものと予想されます。まず、図2は、テスト対象（ターゲット）となったモジュールとそのテストを引き起こしたコードの距離（依存関係のホップ数）を示したものです。ホップ数が10を超えるとターゲット数が減り始める傾向が見られますが、それでも、中には40ホップに達するものも存在しています。

fig02

図2 変更したコードとテストターゲットのホップ数の分布

　そして、重要なのは、これらの中に失敗したテストがどれだけあるかという点ですが、論文の中では、テスト結果が「成功」から「失敗」、もしくは、「失敗」から「成功」に変化したものを抽出するという処理を行っています。これは、コードの修正によって不具合が取り除かれる事もまた、修正による影響の伝搬範囲として捉えるためです。さらに、コードの変更とは関係なく、タイミングによって失敗する可能性がある不安定なテストの影響を取り除いた結果が図3になります。

fig03

図3 コード変更により「成功」と「失敗」が変化したテストの分布

　この結果を見ると、ホップ数が10以下の部分に分布が集中しており、ホップ数が10を超えるテストは、コード変更の影響をほとんど受けないことがわかります。つまり、ホップ数が10を超えるテストは、マイルストーンの間隔を大きくして、テスト回数を減らしても大きな影響を与えないということになります。

　そして最後は、コードの変更回数とテストの結果に対する相関関係のデータです。図4は、テスト結果が「成功」から「失敗」、もしくは、「失敗」から「成功」に変化したものについて、そのテストを引き起こしたファイルがChange List（CL）に含まれていた回数を調べた結果を表します。横軸がCLに含まれていた回数で、縦軸は、そのファイルがテスト結果に影響する確率を表します。これを見ると、CLに含まれていた回数が多い、すなわち、変更の頻度が高いファイルは、テストの失敗を引き起こす確率が高いことがよくわかります。これもまた、マイルストーンの間隔を調整するための指標として活用することができます。

fig04

図4 コードの変更回数とテスト結果の相関関係

次回予告

　今回は、論文「Taming Google-Scale Continuous Testing」をもとにして、Googleの自動テストシステム「TAP」に関連したテストデータの分析結果を紹介しました。本文中でも触れたように、これはあくまでも、Googleの開発環境に固有の結果ですが、一般的なCI環境の特性を理解する上で参考になる点も多いのではないでしょうか。論文の中では、今回紹介した結果の他にも、開発言語によるテスト結果の違いなども紹介されていますので、興味のある方は、ぜひ参考にしてください。

　次回は、Googleの社内ネットワークに関する話題をお届けしたいと思います。

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