今日読んだのはこちら。
Lin, Jun-Wei, Reyhaneh Jabbarvand, and Sam Malek. 2019. “Test Transfer across Mobile Apps through Semantic Mapping.” In 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE. https://doi.org/10.1109/ase.2019.00015.
読もうと思ったきっかけ、参照していたもの
昨日読んだ“GUI Test Transfer from Web to Android.”から。
メモ
論文の概要
- GUIベーステストの入力生成技術についていくつかの制限があった。これを解決するためにCRAFTDROIDという仕組みを提案する
- CRAFTDROIDは静的解析＋動的解析をベースに、あるアプリの既存のGUIテストをもとに別の類似アプリのテストを生成する
- 現実世界のアプリで評価したところ、有効性が示された
背景
- GUIテストの入力生成はまだ実用的でない
- テストのコンテキストを考慮した生成ができず、到達できないGUIなどがある
- 一般的でない手順を生成して、デバッグしづらい
- テストオラクルの自動生成が困難で、アプリがクラッシュしたり例外発生したり、でないとFailの検知ができない
- CRAFTDROIDを作った
- あるアプリの特定の機能やユースケースに対応するテストを、類似のアプリに流用する
- アサーション含むテストオラクルも生成可能
手法
仕組みの概要は下図。
元になるアプリとテストケースを入力し、実行。実行過程でGUIウィジェットから情報を得て、補強。 自動テストの生成対象となるアプリを静的解析し、UI Transition Gparh（UITG）を作成し、元となるアプリにあるウィジェットと類似なものを探し、新しいテストを生成する。
ウィジェットの類似度を判断する際には、Word2Vecを使って、違う文言でも同じ意味で用いられているウィジェットを探す。 また、候補ウィジェトへの到達可能性判定も行う。
結果
以下がRQと結果。
- RQ1:テストの転送がどの程度成功するか
- 全体で73%の精度と90%の再現性
- ウィジェットのマッチングに失敗してもテスト自体は転送できる場合がある
- 元アプリにある機能が転送先アプリに無い場合など
- しかし、カテゴリやアプリごとで成功率に幅がある
- RQ2:転送に失敗する場合、原因はなにか
- 一つがテストの長さ。テストが長いとより多くのウィジェットやテストオラクル（アサーション）が含まれるので失敗率が上がる
- カテゴリによっては標準設計やガイドラインなどがあり見た目や機能が類似していて、そうしたカテゴリでは転送が成功しやすい。たとえばブラウザは成功しやすいが、ショッピングアプリは機能や画面も様々なので、成功率が低め。
- RQ3:実行時間
- 平均して1.5時間未満
- とくに到達可能性の検査に時間がかかるが、並列化することで転送時間を短縮可能
- RQ4:効率に影響を与える要因
- テストの長さ、テスト転送の成否、アプリのサイズ
Appium、Python、Javaを使用。ブラウザ、TODOリスト、ショッピング、メールクライアント、チップ計算の5つのカテゴリそれぞれ5つのアプリ、計25のアプリについて評価した。
感想
確かにアプリ間でテストを流用できると、色々な場面で捗りそう。この仕組みを流用して、それこそテスト会社とかが「Androidアプリ向けの標準的なテストスイート」みたいなものを持っておいて、新規の対象アプリのテストを自動生成、とかできるんじゃないかと思ったりする。が、この研究はあくまでもアプリAのテストをアプリBのテストとして転送する話なので、標準からアプリBのテスト生成、がそのままできるかは不明。
次に気になっているもの
昨日読んだ“GUI Test Transfer from Web to Android.”の参考文獻から。