今日読んだのはこちら。
Lin, Jun-Wei, and Sam Malek. 2022. “GUI Test Transfer from Web to Android.” In 2022 IEEE Conference on Software Testing, Verification and Validation (ICST). IEEE. https://doi.org/10.1109/icst53961.2022.00011.
読もうと思ったきっかけ、参照していたもの
ISCT2022のリストを見ていて気になったため。
メモ
論文の概要
- GUIテストを類似アプリケーション間で流用する研究が行われている
- 既存研究は同一プラットフォーム間が多く、異なるプラットフォーム間では少ない
- 同じアプリケーションのWeb版とAndroid版では、それぞれ個別に自動テストが作成されがち
- そこでWebアプリの自動テストをAndroidアプリの自動テストに変換する仕組み、TRANSDROIDを作った
- 結果、有用であると言える
背景
- 作成した自動テストを異なるプラットフォーム向けに変換するには課題がある
- 互換性のないアクション（操作）がある
- コンテキストが不明瞭である
- 例）WebだとSign Upボタンだけど、AndroidだとRegisterボタン、など
手法
テスト変換の概要図は以下
- Context Extraction
- ウィジェットコンテキスト、スクリーンコンテキスト、アクションコンテキストの3種類を抽出
- 実際に元になるWebの自動テストを実行しながら、コンテキスト情報を取得する
- Action Transformation
- Webの操作とAndroidの操作間でマッピングし、処理する
- 再利用、マージ、変換、削除の4種類
- たとえばClickはそのままClick（※Tap、のほうが適当かも）に変換すればいい＝再利用
- mouseOverやrightClickはAndroidに該当操作はない。ただし、これらは他のアクションの組み合わせて使われるので、続く操作と合わせて処理する＝マージ
- など
- NavGraph Extraction
- テスト対象アプリに対して静的解析を行い、ナビゲーショングラフを構築する
これらをもとに、テスト生成を行う。
テスト生成時の工夫として、たとえば一部コンテキストの違い、先に挙げたSign UpとRegisterなどボタン文言の違いを吸収するために、テキストをWord2Vecを使って距離を測る。Create・DeleteよりもCreate・Addのほうが距離が近いので、WebでのAdd Newボタンに相当するボタンがAndroid側になかった場合に、「Create a Postが近そうだ」と判断できる。
結果
- RQ1:TRANSDROIDの精度と、有効性
- テストのうち、77％が適切に移行できた。有効と言える。
- RQ2:処理に失敗する場合は、どんな理由からか
- 大きく影響するのは、Webにある機能がAndroid側にない場合（それはそうだ）
- Android側の実装の仕方に起因するもの。たとえばボタンが画像になっていてテキストが取れないとか、識別子が重複しているとか。
- RQ3:削減できる労力はどのくらいか
- 平均して82%の手作業が省ける
- WebのテストをAndroid向けに移行したものが完璧に動かなかったとしても、ゼロからAndroid版のテストを書くより手間が減らせれば意味がある、ということで、移行したものが動かなかったから一概にダメというわけではない。むしろちょっといじれば動くのであれば十分使える。
- RQ4:処理時間はどのくらいか
- 平均して6分未満
感想
アイディアとしてすごく面白いと思ったし、あとはWebの各種アクションをAndroidのアクションに対応付ける考え方は参考になった。
実務で使うと考えたときに、最初にWebからAndroidに移行できるのは良いのだけれど、その後は結局それぞれの自動テストをメンテナンスしなければならないので、別の工夫もしていかないと、という印象。
この論文の範囲だと、たとえば機能追加があったときに再度TRANSDROIDを使ってWeb版からAndroid版にテストを移行するシチュエーションが課題として残る気がする。
次に気になっているもの
参考文獻にあったので。こちらはアプリAのテストシナリオをアプリBに流用しよう的な話？