Automated, Cost-effective, and Update-driven App Testingを読みました

こんにちは。マネックス ラボでferciの開発をしている佐藤です。

 このエンジニアブログは3ヶ月に一回ローテートして記事を書いているのですが、毎回ネタに悩むので、”佐藤の論文流し読み”シリーズを始めてみようと思います。エンジニアブログそのものが継続できることを目的に投稿者のローテートを組んでいるわけですが、自分でも何か一貫したテーマを決めた方が継続しやすいなと思って始めてみます。これまで技術研究を仕事にしてきたわけではないので、専門の方からすると内容が浅いかもしれませんが、Done is better than perfectの精神でとりあえずやってみます。

読み始めた経緯

 第一回目は、Automated, Cost-effective, and Update-driven App Testingの紹介です。この記事を選んだのはタイトルが今自分が悩んでいることに対してとても合っていたからです。フロントエンドの開発をしている時の悩みの一つに、テストの工数が大きくなりがち、というのがあります。大体の場合は更新した内容をテスト設計者に伝えて、テストを実施してもらうことになりますが、人に伝えるというのはそれなりに労力を要します。できれば短い時間でコンピュータが自動的にテストしてくれたら理想的です。また、タイトルのUpdate-drivenという言葉が大好きです。テスト駆動開発(TDD)は有名ですが、プログラマとしてはテストを書きたいのではなくて、機能を追加することに集中したいわけです。テスト書いてる時間があったら機能追加したい・・・目指すべきはここなのではといつも思っていて、ちょうどこの文献のタイトルが心に響いたので読んでみました。ただ、この文献は51ページありまして、仕事の合間に、関係するドキュメントも含めて細かく読んでいる時間はありません。なので、この文献でやっていることについて簡単に紹介したいと思います。

Automated, Cost-effective, and Update-driven App Testingの紹介

 この文献では、最新のテスト自動化アプローチ(参考文献のDM2(DoroidMate2), Monkey, APE)では、入力が多い割にはコードのカバレッジが低いことを指摘しています。そしてこれを改善するために、DM2の機能拡張を実装する形で、高いカバレッジを確保しつつ出来るだけ少ない入力を自動生成する工夫をしています。

 改良点としては、事前に静的解析を行うことにより、更新されたメソッドを呼び出すために必要な入力を決定する手法を追加しています。更新されたメソッドの検出はソースコードレベルで行うことができるものの、商用のアプリケーションを使って手法の評価をするために、Javaのバイトコードレベルで差分を検知できるようにツールを開発しています。

 さらに、Javaの静的解析ツールであるGatorとSootを使って、入力とViewのイベントハンドラの関係を調べ、更新されたメソッドを呼び出すために必要な入力を特定しています。ただし、イベントハンドラの識別はハードコードに依存していることとAndroidAPIから呼び出されるものであることから、アプリケーションのコードのみから全ての入力とイベントハンドラの関係を特定することはできず、これらに対してはテスト実行時に動的に特定するアプローチがとられています。

 実装の評価については細かく読めていないため具体的な記述は避けますが、他の手法に比べると少ない入力で、高いカバレッジを達成できた、と結論付けています。

終わりに

 ざっと読んでみた限りではソフトウェア開発におけるテストに対する問題を綺麗に解決できるものではありませんが、こうした研究の成果が少しずつ改良され、一般に使われるようになり、10年後、20年後にはもっと開発が楽になっているかもしれません。

 以上、佐藤の論文流し読み1回目でした。2回目があるかわかりませんが、書くとしたら3ヶ月後なのでまた何かネタを探しておきたいと思います。

佐藤 俊介マネックス・ラボ