はじめに
AppiumはモバイルアプリケーションのE2E UIテストを行うテスティングフレームワークであり、機能テストやリグレッションテストの自動化などで用いられることが多いです。それによってコスト削減やフィードバックの速さを期待できます。
一方で、これはE2E UIテストのデメリットでもありますが、UIや機能の変更に追従するのにはある程度コストがかかります。そのため、必要以上にE2E UIを増やしてしまうと、そのメンテナンスコストによってフィードバックが遅くなってしまう可能性があります。
加えてそのテストをさまざまなOS・デバイスごとに実行させようとすると、なおさらコストが増えてしまいます。
スピーカーであるJustin Iron氏も開発スピードの速いチームにいた際に同じ課題感を感じ、そのような状況の中でより効率的にモバイルアプリのバグを見つけるためにAppiumを活用した自律的に動作するクローラーを開発しました。セッションの概要・動画・スライドなどは下記リンクから参照できます。
- 「Appium Native Application Crawler」（Appium Conf 2019）
自律的に、効率的に動くクローラーを作る
通常Appiumを用いてテストを実行させるには、スクリプトが必要になります。そのため、上記でも述べたように一定のメンテナンスコストが必要になったり、スクリプトが書ける人が必要になるという課題があります。
今回扱うクローラーでは、Appiumを通してアプリ内にあるページ階層・操作可能な要素を取得し、それらをもとにループ処理で画面を操作します。
しかしすべての要素に対してループ処理で操作させると、重複された操作なども含まれてしまうため非効率な部分が残ってしまいます。
より効率的な操作をクローラーにさせるには、よりアプリの内部を理解する必要があり、今回はapktoolを利用していました。apktoolはリバースエンジニアリングツールであり、Androidのapkファイルをデコードできます。
今回はそのデコードされたファイルの中からView Layoutsを取得します。それらとクローラーで取得したページ階層とマッチさせることで、具体的にクローラーがどの画面にいるのかが判断しやすくなり、より効率的なクローラーの操作を可能にしました。
スクリーンショットを自動で取得し比較する
OS・デバイスが増えていくと特に懸念しないといけないのは「画面崩れ」です。開発スピードが速い中で、手動で複数のOS・デバイスで画面が崩れていないか確認することはかなり難しいです。
そこで、この画面崩れを確認する役割を、今回のクローラーに行わせます。スクリーンショット自体を取得すること自体は、Appiumを利用することで簡単に行えます。
しかし、メンテナンスコストを抑えながらスクリーンショットを自動で比較するのには技術的な難しさがあります。画像比較として使われているツールの多くは、画像のピクセルレベルで比較しているもののため、本来確認したいレイアウトと関係のないもの（例えば文字など）も比較対象になってしまう課題があります。
1つのOS・デバイスであればある程度メンテナンスできるかもしれませんが、これが複数のOS・デバイスになるとメンテナンスコストが高くなってしまいます。
上記の課題を解決するため、今回のセッションではApplitoolsを用いることによって、精度の高いビジュアルリグレッションテストを実現することを可能にしました。Applitools自体の解説については、前回の記事で取り上げられてた「Your Tests Lack Vision: Adding Eyes to Your Automation Framework」のセッションを参考にしていただければと思います。
