コラム

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

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

CTC 教育サービス

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

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

はじめに

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

Mutation Testの目的

　Googleにおけるソフトウェア開発では、一般に「テスト駆動開発」と呼ばれる手法を採用しており、ある機能を実装するコードを作成する際は、その機能が正しく動作することを検証するためのテスト用のコードも同時に作成します。将来、該当のコード、あるいはこのコードが依存するライブラリーなどに変更があった際は、このテストを再実行することで、本来の機能が満たされなくなるといった想定外の問題が起きていないことを確認します。この時、テスト用のコードそのものに問題があると困ります。正しく機能しているのにテストが失敗する「偽陽性」のケースであれば、開発者自身がテストに問題があると気づくことができますが、本当は正しく機能していないのにテストが成功するという「偽陰性」の場合、ソフトウェアの問題が気づかれないまま放置される危険性があります。そこで、元のコードに対して、それが正しく機能しなくなるような変更をわざと加えて、対応するテストが正しく「失敗」することを確認しようというのがMuattion Testの考え方です。
　Mutation Testを行う際は、通常、次のような自動化を行います。まず、一定のルールに基づいて、元のコードをランダムに変更します。具体的には、図1のようなルールがあります。

fig01

図1 Mutation Testで用いられるコード変更ルールの例（論文より抜粋）

　たとえば、「AOR」は、足し算を引き算に置き換えると言った、単純な算術処理の書き換えを行います。あるいは、「ROR」は、IF文の判定処理に使われる不等号の向きを反対にするといった具合です。このような変更を加えることを「Mutation（変異）」、また、変更されたコードを「Mutant（変異体）」と呼びます。既存のテストによって、このような変異体を正しく検出できるかをチェックします。検出できない変異体があった場合は、「この変異体を検出できるようにテストコードを修正してください」と開発者に依頼する流れになります。

GoogleにおけるMutation Testの方法

Mutation Testの考え方そのものは単純ですが、現実のソフトウェア開発における有効性については、一般にはあまり高く評価されていません。変異体を生成する際は、前述のように、一定のルールでランダムに変更するだけですので、開発者にとって有益な知見を与える、つまり、既存のテストコードの問題点を明らかにするような変異体が生成されるとは限りません。特に、既存のテストでは検出できない変異体の報告を受けた開発者がその内容を調べた結果、「見かけ上コードは変更されているが、論理的な動作は変わらない」と言った意味のない変更、あるいは、「ログ出力用の定型のコードを変更しただけ」と言った、本来の機能とは関係のない（わざわざテストで検出する必要のない）変更という場合があります。こういった結果が続いてしまうと、開発者は、やがて、Mutation Testの結果をはじめから無視するようになります。
　このような問題を避けるため、Googleでは、コードの修正に伴うレビュープロセスにMutation Testを組み込むという方法を用いています。まず、開発者が既存のコードを修正した場合、その修正部分についてのレビューが行われますが、この際、レビュー対象となる修正部分についてのみMutationを行うことで、開発者（あるいは、レビュアー）の興味の対象となる部分にポイントを絞って、Mutation Testを行います。さらにまた、得られた変異体の中で「意味がない変更」とみなされたものは、この時点で自動的に破棄されます（これはMutation Testのメンテナンスチームが作成したツールによって行われます）。そして、破棄されなかった変異体の中にテストで検出できなかったものがあれば、その旨を示すコメントがレビューツール上に現れます（図2)。

fig02

図2 レビューツール上に示されたコメントの例（論文より抜粋）

　レビュアーは検出できなかったMutationの内容をチェックして、必要な際は、「Please fix」というリンクを押して、これを検出できるようにテストを修正／追加することを開発者に依頼します。あるいは、修正に値しない結果と判断した場合は、「Not useful」を押してこれを無視します。Mutation Testのメンテナンスチームは、無視されたMutationの情報を分析して、今後、類似の問題が起きないように、先ほどの「意味がない変更」をチェックするツールを改善していきます。

次回予告

　今回は、2018年に公開された論文「State of Mutation Testing at Google」を元にして、GoogleにおけるMutation Testの適用プロセスを説明しました。この論文では、このプロセスの中で生成された約116万件の「変異体」について、生存率（テストで検出されずに残った割合）や開発者からのフィードバックなどを分析した結果が示されています。次回は、これらの分析結果を紹介したいと思います。

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