コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第87回　GoogleにおけるMutation Testの実践（パート2）

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

CTC 教育サービス

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

第87回　GoogleにおけるMutation Testの実践（パート2） (中井悦司) 2020年8月

はじめに

　前回に続いて、2018年に公開された論文「State of Mutation Testing at Google」を元にして、「Mutation Test（ミューテーション・テスト）」と呼ばれるソフトウェアのテスト方法について、Googleにおける取り組みと、その有効性の分析結果を紹介します。

Mutation Testの流れ

　前回の記事では、Googleの開発プロセスにおけるMutation Testの流れを説明しました。開発者がコードの変更に伴うレビューをリクエストしたタイミングで、変更対象部分についてMutation Testを実施します。具体的には、変更対象のそれぞれの行に対して、前回の図1に示したコード変更ルールの中から、どれか1つをランダムに選択して適用します。コードの一部を変更すると、変更していない他の部分の動作も変化する可能性があるため、厳密には、コードのすべての行に対してMutationを適用するべきです。しかしながら、実際にこれを行うとMutation Testの実行量が膨大になるため、変更した行のみにMutationを適用しています。（1つのMutationに対して、関連するすべてのテストを実行して、どれか1つでも「正しく失敗する」ものがあることをチェックする必要がある点に注意してください。）
　また、Mutation Testは、コードの正しさを確認するものではなく、テスト用のコードの有用性（誤ったコードを正しく検出できること）を確認するものでした。Mutation Testを導入する際は、テスト駆動開発が導入されており、すでにある程度のテストコードがあることが前提となります。図1は、Google社内の開発プロジェクトにおけるテストカバレッジ（テストの実行時に、コードの何パーセントの部分が実行されるかを示す値）を表したものですが、大多数のプロジェクトが70%以上のカバレッジを実現してることがわかります。

fig01

図1　プロジェクトごとのコードカバレッジの分布（論文より抜粋）

変異体（Mutant）の生存率とその有用性

　Googleでは、7種類のプログラミング言語に対してMutation Testを実施しており、論文の中では、言語ごとに「変異体（Mutantionを加えたコード）」の生存率、すなわち、既存のテストで検出されなかったものの割合が示されています。図2がその結果となります。左側が言語ごとの結果で（Py、Js、Tsは、それぞれ、Python、JavaScript、TypeScriptを表します）、右側は前回に説明したコード変更ルールごとの結果です。

fig02

図2　変異体の生存率（論文より抜粋）

　これは、それぞれの言語の特性を考える上での興味深いデータと言えますが、一方、実際にレビューを行うレビュアーの視点ではどうでしょうか？　論文によると、1回のレビューにつき、中央値で約2個の変異体が「生き残る」そうです。つまり、1回のレビューにおいて、前回の図2のような指摘が、2個程度は現れることになります。レビュアーは、これらの指摘が有用だったかを報告するわけですが、その集計結果は図3のようになります。図2と同様に、変更ルールごとの結果とプログラミング言語ごとの結果が記されています。

fig03

図3 Mutation Testによる検出結果の有用性（論文より抜粋）

　一般には、Mutation Testの有用性はあまり高く評価されていないことを考えると、非常によい結果が得られています。前回説明したように、「Not useful」という評価を受けたMutationについては、これを自動的に除外するツールを利用しており、それがうまく機能していると考えられます。また、Mutation Testの目的は、テスト用のコードの問題点を発見することですが、開発者からのフィードバックでは、テスト対象のコードそのものについても、新たな知見が得られることがあるそうです。「この変異体がなぜ検出できなかったのか」という点を考えることで、元のコードの動作についての新しい発見があるものと想像されます。