パフォーマンス・ログ・アクセシビリティを取得する
スクリーンショットだけでなく、Appiumではさまざまな情報を実行時に取得することが可能であり、継続的に取得することによって機能テストではできないフィードバックを行うことが可能です。
まずパフォーマンスですが、Androidの場合にはADB経由によってCPU・メモリ・フレームレートなどを取得できます。今回のクローラーでは、それらをグラフで表示されるのではなく、どの画面でのパフォーマンスなのかスクリーンショットも合わせて表示させていました。
また、ADB経由によってログも取得できます。これによって、例えば実行中にクラッシュ・例外が出た場合に、そのログによってどのような問題なのか判断しやすくなります。
モバイルアプリのAccessibility Labelも取得・比較できます。
他のセッションで紹介されていましたが、Accessibility Labelは、
- Appiumなどの自動テストで要素を取得しやすくする
- アクセシビリティ機能（読み上げなど）に必要になる
- アプリストアのSEOに影響する
など、さまざまな利点があります。
開発していく中で、意図せずこのAccessibility Labelが抜けてしまう・付け忘れてしまう可能性もあるため、継続的にモニタリングできるのはとても良いと感じました。
Beyond Functional Testingへ
基調講演でAppiumのプロジェクトリーダーであるJonathan Lippsが、これからのAppiumは「Beyound Functional Testing」になっていくと主張していました。これは、Appiumの役割が機能テストの自動化のみならず、ビジュアルテスティングやパフォーマンステスティングなどの役割を担っていき、より多角的にモバイルアプリのフィードバックを支援していくということです。
このセッションでは、実際にそれらの役割を担うクローラーをAppiumを活用しながら作っていたため、よりその可能性を感じ取ることができました。また、Appiumでテストを行う際に増えがちなメンテナンスコストを抑えながらも、効率的にかつ網羅的に情報を収集できるのがとても魅力的に感じました。
スピーカーのJustin Iron氏も述べていましたが、このクローラーがマニュアルテストやAppiumなどによる機能テストの自動化に置き換わるものではありません。
しかし、既存のマニュアルテストや自動テストとうまく組み合わせることによって、開発スピードを保ちながらも、より効率的にモバイルアプリのバグを見つけられるのではないかと感じました。
