- 「ソラコム」がスイングバイIPOを実現、東証グロース市場上場承認 - 2024-02-22
- （更新）結果速報 LAUNCHPAD SEED#IVS2023 #IVS #IVS @IVS_Official - 2023-03-09
- 「始動 Next Innovator 2022」締め切りは9月5日（月）正午ー経産省・JETRO主催のイノベーター育成プログラム #始動2022 - 2022-09-01
モバイルアプリの実機を使った自動テストが注目されている。リモート操作＆テストプラットフォーム「HeadSpin」の日本正規代理店であり、日本唯一のテクニカルパートナーであるCO-WELL（コウェル）社は2021年3月27日（土）、モバイルアプリのテスト自動化ツール「Appium」と「HeadSpin」を使ったスマートフォン実機テストの最新情報を伝えるオンラインイベント「【CO-WELL】Global Tech Meet #01 モバイルテストの最前線 〜Appiumの今とこれから、急成長HeadSpinとは？」を開催した。
今回は、そのイベントのレポートの前編として、AppiumコミッターでありHeadSpinのサービス基盤開発を米国で行っている松尾和昭 氏の講演内容を整理してお伝えする。
イベント情報「モバイルテストの最前線 〜Appiumの今とこれから、急成長HeadSpinとは？」
HeadSpin社シニアソフトウェアエンジニア 松尾和昭氏
松尾和昭氏は現在、米HeadSpin社でSenior Software Engineerとして主にSeleniumやAppiumといったデバイス上でのテストを自動化できるものを増やしていくといった部分に注力している。
これまでは組み込み系のACCESS社やクックパットでテストエンジニア・ソフトウェアの品質を担保する技術者として活動しており、その際、テスト自動化の「Appium」のオープンソースソフトウェア開発に関わるようになり、それがきっかけとなりアメリカに渡った。
まずモバイルアプリの自動テストを、どの領域でどう実行するかを説明するために、松尾氏はピラミッド型のテストを使って説明した。
実行速度が速いユニット単位のテストを「ユニットテスト」とし、徐々に結合度を上げていき（インテグレーションテスト）、最後にユーザーが使うのを想定したテスト（ＵＩテスト）を行っていく。ピラミッドの上位になるほど、テストには時間がかかる傾向がある。最近では、テストの技術の成熟があり、ＵＩのユニットだけをテストする「ＵＩコンポーネントテスト」が出来るようになっている。Appiumは最上位にあるリリースしたアプリいわゆる成果物の「UIテスト」を支援するものという位置づけになる。
Appiumの構成と仕組み
Appiumのテストで必要なのは3つ。
どういうシナリオでテストするかをRuby/Javaなどで書かれた「テストコード」、そのテストコードを実行する「Appiumサーバー」、その命令を受け取って実際にテストを行う端末やエミューレーターというクライアント・サーバー型アーキテクチャーが採用されている。
なお、自端末から「Appiumサーバー」へはW3Cなどで定義されているウェブドライバー（現時点ではHTTP/S通信）でやりとりを行い、「Appiumサーバー」から「テスト対象」へはHTTP通信で端末を直接操作するコマンドを発行し、テスト端末内ではアプリ対してAPI（OS/テスト用/プライベート）を叩いて実際にアプリを操作する仕組みになっており、テストを書くところとテストを実行する端末を分離することが可能だ。
また、SDKを使っていないので、テスト対象に対して何らかのコードを埋め込む必要がない。これにより、リリース用にビルドしたアプリでそのままテストをすることが出来るようになるというメリットがある。
HeadSpinのテスト性能
モバイルアプリのテストでは、今までは「機能的なものが壊れていないか？」、ボタンを押して次の動作に遷移するかといった機能的な議論が多く、一方ウェブなら「負荷や性能はどうか？」という議論が多かった。
しかし、松尾和昭氏が翻訳を担当した書籍「Software Engineering a Practitioners Approach」では、以下のような興味深いテストポイントが指摘されているという。
–Performance Testing 端末に依存した非機能テスト（ダウンロード回数、プロセッサースピード、ストレージ、電池）
–Connectivity Testing 実際の端末で途切れたり電波が弱くなるなどの状況があるがテストは安定しているか
–Testing in the wild 実際にユーザーはいろいろなところで端末を使う
これらはちゃんとやろうとするとコストが高くなってしまうが、HeadSpinを使えばより手軽に実現することができるという。
HeadSpinは世界に設置された端末でテストを実行できる
「HeadSpin」は世界の色々なところに端末を設置してテストを実行できるようにするＳａａＳ型サービス。「HeadSpin」で使えるモバイルデバイスは、世界中に展開されたデータセンターで保管されている。サブスクリプションプラン（Local/Compassプラン）では世界17か所でHeadSpinが用意した実機を使用できる（追加も可能）。上位プランでは150か所に展開可能だ。
世界に展開されたモバイル実機のテストをリモートで実行できる「HeadSpin」に、テスト自動化ツール「Appium」を連携させることで、世界中に国に用意されたモバイルデバイスでテストや監視検証をリモートで行うことができるようになる。AppiumはSDK不要のツールなので、リリースされたアプリをそのまま世界中の端末でテストを実行することができる。「HeadSpin」側で定期的にテストを実行することが可能で、サービス監視として利用することもできるのがポイント。
「HeadSpin」におけるユーザーの環境とテスト完了は分離されており、ユーザー側は「HeadSpin」によりテスト環境を手放すことが出来るようになっている。
通常ローカルでやっていることを「HeadSpin」の端末で行う
実際「Appium」と「HeadSpin」でテストを行う方法について。自端末とAppiumテストサーバー、テスト端末はそれぞれウェブドライバーで通信をを行う。例えば、ローカルのモバイル端末を接続する場合、このような設定を記述する。
これを、「HeadSpin」上の端末として接続する場合は以下のように書き換えることになる。
ただし、多数のデバイスに接続できる「HeadSpin」では、逐一設定を記述することもなり面倒。
そこで、うまく使いたいのが「Appium Load Balancer」だ。細かい設定をしなくともテスト可能な端末群から選ぶことができる。「AndroidのOS10」といったざっくりとした条件や使用中の端末を避けて選んでくれる。
全ての処理を「Appium Load Balancer」を経由して行う方法と、端末抽出時だけ「Appium Load Balancer」を経由し、端末選定・接続確立後はダイレクトに通信を行う2通りの仕組みがある。
後者の場合、余計な遅延が発生しないメリットがある。この場合、クライアント側の対応が必要でAppiumのRubyライブラリ、ウェブドライバーI/O、dartドライバなどが用意されておりそれを使用する。松尾氏はこの対応ライブラリなどを増やしているという。
【関連リンク】
・コウェル
www.co-well.jp/