Supershipのアドテクセンターは広告事業のコアであるアドテクノロジー領域の広告プロダクトを一手に担うテクノロジー集団として、新規開発からDSP、SSP、DMPといった既存プロダクトまで、企画・開発・運営を担っています。
そのアドテクセンターのなかで私、佐藤はAd Generation（以後、アドジェネ）のQA（品質管理）チームにてSDKのテストを担当しています。

先日、アドジェネの動画リワード広告が、Unityで開発されたアプリでもご利用いただけるようになりました。
参考：SupershipのSSP「Ad Generation（アドジェネ）」、動画リワード広告SDKのUnity対応プラグインをiOS/Android両OSにて提供開始／Supershipプレスリリース

このUnity pluginをリリースするにあたり、QAチームではご利用いただく媒体社様にご迷惑をおかけすることがないよう、十分な手動・自動テストを実施いたしましたが、これには既存のテスト環境をそのまま使うことができず、イチからUnity用のテスト環境をAndroid／iOSともに構築する必要がありました。

そこで、本記事ではQAチームで実施しているUnityでビルドしたAndroid／iOSアプリの自動テストについてご紹介します。
Unity製アプリにて動画リワード広告の実装を検討しているアプリ開発者様の参考になればと思い、ご紹介します。

１.サンプルアプリの自動テストについて

アドジェネではSDKの配布にあたり、サンプルアプリにて手動ならびに自動テストを実施し、お客様にご迷惑をおかけしないよう、最善を尽くしております。詳細については、以下の記事を参照してください。

２.Unity版サンプルアプリを自動テストする際の問題点

これまでQAチームではサンプルアプリの自動テストをAppiumを使って自動テストを実施する体制を構築し、運用していましたが、Unity版の自動テストを実施するにあたり、以下の問題点があることがわかりました。

 

Appium

 

■全般的問題

・Unityでビルドしたアプリは、Appiumからは操作できない
・表示された画面等からテキスト等を取得し、ログとして残すことができない

■これまでの自動テストでAppiumが担当していた部分の問題

・アプリの起動・終了
・画面キャプチャの取得
・画面上の要素を取得して、操作（クリック、要素による画面判定、ADNW情報の取得）
・キーイベント（バックボタン）発生

■Appiumが関係していない部分の問題（参考）

・動作環境のチェック
・対話型式のテストスクリプト起動に必要な情報の設定
・テストスクリプトの起動
・ログの取得
・Slackへの経過報告
・テスト完了後のログの集計とレポート作成
・レポートのサーバーへのアップロード

などなど…これらの問題をひとつひとつ潰しながらテスト環境構築を進めていくことなりました。

３.Appiumを使わないでどこまでやれるか？という試み

まず、Android端末にて標準で提供されているADBコマンドをつかって、どこまでできるかを確認しながら構築することになりました。最終的には、Appiumを全く使うことなくADBコマンドのみで、Unity版サンプルアプリの自動操作とログの取得に成功しました。

■主な変更点

・アドネットワーク名の取得を、Appiumで取得した画面要素のテキストを使用する方式から、デバッグ用のログファイルより取得するように変更
・表示画面の判定方式を、Appiumで取得した要素名やID等から判定していた方法を、Activityを取得して判定するように変更

Activityを取得して判定する方法はテストスクリプトの構造がシンプルになる（ボタン名による分岐がなくなる）ため、弊社のケースでは広く応用できそうです。

次に、iOSですが、ipaファイルのインストールから起動のところまではAppiumを使うことなく構築できたのですが、AndroidのようにADBコマンドに相当するものが公式にないため、アプリに干渉するための手段がAppium以外にありませんでした。しかし、そもそもAndroid版と違い、iOS版のビルド時にはXcodeからビルドを行うため、アプリに干渉する部分はAppiumで操作が可能だったので、ボタン操作に関しては、Appiumを使用して実施しています。

■Unityのアプリビルド時のステップの違い

• Android => Unityから直接apkファイル（アプリの本体データ）を出力
• iOS => UnityからXcodeのプロジェクトファイルを出力 => Xcodeからipaファイル（アプリの本体データ）を出力

※Xcodeからipaファイル（アプリの本体データ）を出力という部分は既存の自動テストと同じです。

▼実機テストの様子

４.残った課題について

Unity版のサンプルアプリの自動テストも無事可能になり、多くの端末で動作確認を実施することが可能になりました。ただいくつかの問題点も残っており、それら問題点と見通しに関しては以下の通りです。

・iOS9.2以下の端末が自動化できない
iOS版のテスト環境からどうしてもAppiumを排除できなかったため、Appium環境の制限であるiOS9.3以上という制限を回避できず、iOS9.2以下では手動でテストするしかありませんでした。
ソフト的に操作するのが不可能なら、最終的にはハード的に自動テストをするしかないのだろうか？と考えていたのですが、GithubのAppiumのページ(https://github.com/appium/appium)を読んでいたら、ページの下の方にそのようなプロジェクトへのリンクが載っていました。


Using Robots
Using Appium with Tapster and other robots is possible, check out the Appium Robots project!
- hugs/tapsterbot: Mobile device automation robot - https://goo.gl/9wzsV7
- appium/robots: Robots for Appium - https://goo.gl/BszpPp


この方式だと、１台で１端末になってしまうので、CNCプロッタような形にすれば複数台を一度にテストできると思います。なにより、appiumからハードを連動して動作させることができるというのが分かっただけでもいろいろな可能性が膨らみます。

・iOS11、Android Oへの対応
あれやこれや試行錯誤しているうちに、iOS11やAndroid Oの発表があり、ベータ版を入手して動作確認しています。どちらもそのままでは動かすことはできず、各ツールのアップデートの様子を見ながら対応していくことになります。正式なリリースのタイミングに合わせ、なるべく早く対応できるよう体制を整えています。

・Unityのビルドに非常に時間がかかること
Unityのビルド、とくにXcodeでのビルド〜ipaファイル作成に非常に時間がかかることがわかっています。対応策としては、現在、手作業で行っているビルドをUnity Cloud BuildやJenkinsなどでの自動ビルドを検討しています。

・CIへの統合やテスト環境としての統合
現状は自動テストが連続して行えるというメインの目標があるため、Unity版と既存の自動テストのプロジェクトが分離してしまった状態なのですが、Unity版で導入した仕組みや、コードなどを既存のテスト環境へフィードバックして環境を一つにまとめておく必要があります。

５.まとめ

Unity版の自動テスト実施にあたり、一旦はAppiumを使わない方向で進み、Androidに関しては問題なく構築できたのですが、iOSに関してはAppiumを使うしかなく、各環境に応じてさまざまな対応が必要で、Appiumはシンプルでいいなと思ったり、iOSは堅牢なんだなと思ったりしましたが、なんとかデータを取れる環境をつくることができました。

Unity版の実機端末のテスト結果につきましては、端末リストを以下で公表していますのでご参考ください。

▼アドジェネ動画リワード広告の実機テスト結果
Unity Pluginの検証済み端末はこちら
iOSの検証済み端末はこちら
Androidの検証済み端末はこちら