はじめに

Airtestを使用したE2Eテストの自動化を行なっています。最近はiOSとAndroid環境でデイリーのビルドに対して自動テストの実行を行い、ブロッカーチェックとして活用しています。
元々検証用のPC環境を順次増やしていった経緯から、iOSとAndroidで実行するPCが分かれていました。最近、この環境を統合する必要が出てきたため、その作業を行う中でいくつかの課題と今後の構成を考える機会があったので、その内容についてまとめてみたいと思います。

統合前の環境

図のようにキューを使用したシーケンシャルな実行環境になっています。スマートフォン端末も1台だけなのでとてもシンプルな構成です。

tirgger.py：ビルドが作成されるとSlackメッセージが投稿されるのでそれを監視し、該当するものがあったら予約リストにpushします
scriptRun：実行するビルドやバージョン情報をエントリーしておくテキストファイルです
runner.py：scriptRunを監視しており、実行エントリーがあるとrun.shを実行します
run.sh：apk/ipaのダウンロードとインストール及び、AirtestIDEコマンドでテストスクリプトを実行します。テストスクリプト実行後Slackにテスト完了の通知を投稿します

実行に必要なオプション

ここで、実行に必要となるオプションについて整理しておきます。概ねこのようなものが挙げられるかと思います。

アプリ種別（ゲームタイトル）
ビルド種別（リージョン、ステート（用途、バージョン、サブバージョン））
実行スクリプト（ビルド別にするのか、共通にするのか）

統合後の環境

元の構成を並列化したような環境になりました。iOSを動かしていた環境にAndroid環境を持って来ています。同じ処理をするモジュールも分けて実装しています。とにかく統合の手間をかけずにひとまずの実装をしたというところになります。

この構成にして気づいたことは、runnerはアプリ種別やビルド種別に紐づくのではなく、スマートフォン端末に紐づくということでした。将来的にはオプションで場合分けをしてモジュールを統合するにしても、runnerの実行プロセスだけは常に今実行しているスクリプトを制御する必要があるのでスマートフォン端末と1対1で用意する必要がありそうだということです。

今後の環境（構成）について考えてみる

統合できるモジュールはオプションをつかって別実行できるようにしたいと考えています。また、スマートフォン端末を増やしたり、対応できるタイトルを増やしたときにも対応できるような構成にしていく必要がありそうです。
例えば、runnerの一つ前段階にdispatcherが必要かもしれません。runnerがスマートフォン端末と紐づくので、その枠を超えた制御を行う必要がでてくるからです。

今ある機能（とオプション）

あらためて、今できていることを整理すると以下のような機能があります。ダウンロードしないで実行する機能はテストスクリプトの調整の際にダウンロード時間を短縮するために利用しています。

最新のビルドを取得してインストールして実行
ビルドを指定して実行
ダウンロードしないで実行
インストールしないで実行

これから欲しい（必要な）機能

複数端末で複数のスクリプトを並列実行する時に必要となる機能について考えてみました。

割り込み（現在の実行を中断して別のテストを実行）
実行スマートフォン端末の状態によって端末を選んで実行する
実行するスマートフォン端末を指定して実行する
実行中の状態を見るビューアーがほしい
直前の実行結果をみて再実行するといった処理をいれたい
実行するビルドや使用するスマートフォン端末の優先度で割当を制御する

おわりに

まだまだ発展途上ではありますが、少しずつ強化していければと考えています。既にこういった環境を実現されている方も多くいるかとおもいますが、同じような課題をもっている方の参考になれば幸いです。