[論文レビュー] On the Energy Footprint of Mobile Testing Frameworks

Luís Cruz, Rui Abreu|arXiv (Cornell University)|Oct 19, 2019

Green IT and Sustainability参考文献 36被引用数 7

ひとこと要約

本論文は、テスト中の8つのモバイルUI自動化フレームワークのエネルギー消費オーバーヘッドを評価し、一部のフレームワークがエネルギー消費を最大2200%まで増加させることを明らかにした。Espressoは最もエネルギー効率の良いフレームワークであり、コンテンツベースのUIコンポonent検索（例：Contentで検索）を用いる方法は、最大600%高いエネルギーコストを要する。本研究では、開発者がエネルギーに配慮したテストフレームワークを選択し、インストルメンテーションのオーバーヘッドを最小限に抑えるための意思決定ツリーとベストプラクティスを提供する。

ABSTRACT

High energy consumption is a challenging issue that an ever increasing number of mobile applications face today. However, energy consumption is being tested in an ad hoc way, despite being an important non-functional requirement of an application. Such limitation becomes particularly disconcerting during software testing: on the one hand, developers do not really know how to measure energy; on the other hand, there is no knowledge as to what is the energy overhead imposed by the testing framework. In this paper, as we evaluate eight popular mobile UI automation frameworks, we have discovered that there are automation frameworks that increase energy consumption up to roughly 2200%. While limited in the interactions one can do, Espresso is the most energy efficient framework. However, depending on the needs of the tester, Appium, Monkeyrunner, or UIAutomator are good alternatives. In practice, results show that deciding which is the most suitable framework is vital. We provide a decision tree to help developers make an educated decision on which framework suits best their testing needs.

研究の動機と目的

• UI自動化フレームワークがモバイルアプリケーションのエネルギー効率測定に歪みをもたらすような顕著なエネルギーオーバーヘッドを導入するかどうかを調査すること。
• 一般的なユーザー操作を想定した状況下で、人気のあるモバイルテストフレームワークのエネルギーインパクトを比較すること。
• 特にUIコンポーネント検索方法に関連して、エネルギー効率の良い自動テストスクリプトの作成に関するベストプラクティスを同定すること。
• プロジェクトの制約に基づいて、最もエネルギー効率の良いテストフレームワークを選択するための意思決定フレームワークを提供すること。

提案手法

• 著者は8つの人気のあるモバイルUI自動化フレームワーク（Espresso、Appium、UIAutomator、Monkeyrunner、AndroidViewClient、Calabash、およびその他の2つ）を評価した。
• エネルギー消費は、タップ、長押し、ドラッグアンドドロップ、スワイプ、ピンチイン・ピンチアウト、戻るボタン、テキスト入力、さまざまなFind操作といった一般的なUI操作の実行中に、電力計を用いて測定された。
• 本研究では、各フレームワークの内部ロジックが引き起こすオーバーヘッドを分離し、同一の操作に対するエネルギー使用量をフレームワーク間で比較した。
• UIコンポーネント検索方法（IDで検索、説明で検索、コンテンツで検索）のエネルギーコストを評価し、特にコンテンツベースの検索がパフォーマンスに与える影響に焦点を当てた。
• エネルギー効率、機能サポート、プロジェクト固有の制約を基に意思決定ツリーを構築し、フレームワーク選定を支援した。
• 実証的結果に基づきベストプラクティスを導出し、特にコンテンツベースの検索の回避と、コンポーネント参照のキャッシュを推奨した。

実験結果

リサーチクエスチョン

• RQ1 RQ1: UI自動化フレームワークが引き起こすエネルギー消費オーバーヘッドは、モバイルアプリケーションのエネルギー効率測定結果に影響を及ぼすか？
• RQ2 RQ2: エネルギー消費をプロファイルするのに最も適したフレームワークは何か？
• RQ3 RQ3: エネルギー効率テスト用の自動スクリプト作成において、どのようなベストプラクティスがあるか？

主な発見

• Espressoは最小のエネルギーインパクトを示し、1回のタップあたりわずか0.09Jのエネルギー消費で、評価されたフレームワークの中で最もエネルギー効率がよかった。
• ドラッグアンドドロップ操作におけるエネルギーオーバーヘッドは、一部のフレームワークで最大2200%に達し、エネルギー測定値に顕著な歪みをもたらした。
• Espressoにおいて、UIコンポーネント検索に「Contentで検索」を使用すると、「IDで検索」に比べ最大600%高いエネルギー消費が発生し、エネルギーコストは1.4Jから9.4Jに増加した。
• Appium、Monkeyrunner、UIAutomatorは、Espressoの制限（例：ソースコードへのアクセス、WebView非対応）が問題となるプロジェクトにおいて、Espressoの優れた代替手段であることが特定された。
• AndroidViewClientとCalabashは、高いエネルギーオーバーヘッドのため、エネルギー効率テストには不適切であると判明した。
• UIコンポーネント検索の結果をキャッシュし、コンテンツベースの検索を避けてIDまたは説明で検索するようにすることで、テストスクリプトのエネルギー消費を顕著に削減できる。