IDOLY PRIDEのチュートリアルを自動テストする仕組み

2023/01/31 公開9 min read

はじめに

株式会社QualiArtsでUnityエンジニアをしている田中です。IDOLY PRIDE（以下、アイプラ）にてアウトゲーム開発などを行っていましたが、最近は開発基盤チームに異動し、自動テストを主な業務としています。

QualiArtsでは最近開発の品質を高めるべく、自動テストについて技術的な検証を進めております。ここでの自動テストがターゲットとするのはいわゆるUIテストで、一定の操作に基づく実機での検証を自動化することを指します。今回はそんな自動テストの検証の一環として、アイプラのチュートリアルのテストを自動化した話を紹介します。

アイプラのチュートリアル

まずはじめにアイプラのチュートリアルについて説明します。アイプラでは、はじめてプレイするユーザーに向けてチュートリアルの機能を用意しています。ユーザー規約の提示からユーザー名の選択、各種機能の紹介からライブを実際にしてみるといった、一連の流れを説明しながら体験してもらう機能です。

チュートリアルというのはゲームに必要な要素を案内する重要な要素ですが、同時に複数の機能に関わるがゆえに壊れやすい要素でもあります。これを検出するには一定の回帰テストが必要です。かといってチュートリアルを手動で毎度検証するというのも、それはそれでコストがかかります。チュートリアルは他の機能に比べてフローが非常に長く、一度の検証コストが重いからです。そこで、需要はあり作業も単純だがコストが高いテスト、という点から自動化を検証してみようとなりました。

チュートリアルの自動テストの仕組み

前項で説明したアイプラのチュートリアルを自動でテスト、つまりは自動で操作して検証する仕組みについて説明します。画面をタップしたり、名前を入力したり、フリックしたりといったひとつひとつの操作が必要になりますが、それらをAirtestで実現しました。

Airtestとは、NetEaseが開発および公開しているゲームの自動テスト用ツールです。Android、iOS、Webなど、多くのプラットフォームに対応しています。言語はPythonで特定の座標をタップするなどの操作を記述し、テストを構築します。画像認識をベースとしたテストと合わせてPocoというライブラリを利用したゲームのメタ情報を元にしたテストを行うことが可能になっています。どのような環境が必要でどのような実装を行うのか、Unityでの活用はどのように行うのかといったAirtest自体の詳細な説明は省略いたします。詳しい使い方や応用方法などAirtest自体について知りたい方については、弊社の住田による説明の記事がありますので、そちらを参照していただけますと幸いです。

Airtest+Pocoで始めるUnityの自動テスト

今回の要件に対しては、チュートリアルのシナリオにしたがってひとつひとつの操作をAirtestでの操作に当てはめて実装しました。実装する上ではさまざまな要所に対する工夫がありました。本記事では次の工夫について紹介します。

ゲーム内のメタ情報に対するRPCの活用
アプリケーション内のSlack連携機能の利用
別のテストケースの実装を見越した汎用的な実装

ゲーム内のメタ情報に対するRPCの活用

自動テストのシナリオを実装していくと、どうしてもゲーム内のシステム側の情報を知りたい時が存在します。たとえばある操作をして、ローディング処理を行なって、次の操作を行いたい。という場合があったとき、自動テストはこのローディング処理というものをうまく待つ必要があります。これがUIによって特定の演出があったりすれば、そのUIを元に画像認識で存在する限り待ったりとか、Pocoを活用してそのパーツが表示されている限り待ったりなどを行えますが、正確性に欠ける部分もあります。

そこで、Airtestがアプリケーション内の処理の呼び出しのために用意しているRPCの機能を積極的に利用しました。 AirtestにおけるRPCメソッドの利用については、自分が以前記事を執筆しましたので、参考にしていただけますと幸いです。

Airtest+Pocoの自動化でのアプリとのデータの受け渡し方法

ここの例にもあるローディングの待機はもちろん、記事内にあるアプリケーションの実行環境の取得や、チュートリアルの進行状態など、メタ的な情報を取得するのに大いに活用しています。また、UIベースの操作であるAirtestではどうしても実現が難しい複雑な操作なども存在します。その部分を乗り越えることだけを考慮するのであれば、Unity側のデバック処理として実装してしまい、RPCで呼び出すという手段も使えます。

アプリケーション内のSlackへの不具合通知機能の利用

アイプラでは開発用アプリケーションの機能として、何かしらの不具合の報告のために、現在のスクリーンショットとログを合わせてSlackに投稿する機能を実装しています。これは基本的には人間がアプリケーションを操作している際に、デバッグ用のUIを操作して実行する処理になっています。

Airtestは一連のテストを終えると結果を元にレポートを出力してくれます。こちらのレポートは非常に便利なのですが、今回自動テストを実装する過程の議論で、自動テスト中に不具合があったのならばレポートとは別にSlackで通知させたいとなり、この処理をAirtestからも呼び出すことにしました。前述したRPCを介してSlackへの通知機能を呼び出す形をとることによって、さほどコストなく実装することができました。

テスト結果自体はレポートという形でJenkinsから通知され、ログもJenkins上で参照できるので、詳細な情報はそこから見ることになります。しかし、普段不具合が通知される部屋に通知されることも重要です。これによって、不具合があったという事実をよりシンプルかつ認知度の高い状態でチームに共有する仕組みが実現できました。

別のテストケースの実装を見越した汎用的な実装

今回はチュートリアルというケースに絞った自動テストの実装を行いましたが、今後アイプラでの別のテストケースや別のプロジェクトでの活用などを加味した汎用的な実装を行っています。具体的には、どのテストでも共通するような環境構築や頻出するUI操作などの処理を、ひとつのモジュールとして実装を進めました。チュートリアルについては一連の実装を終えましたが、汎用的なライブラリとして独立できる部分については今でも作業を行なっています。

JenkinsとOpenSTFによる実行環境の整備

Airtestでチュートリアルを自動テストできたとて、それが特定のエンジニアの手元にて手動で回るだけではシステムとしてあまり意味がありません。誰もがいつでも実行できるシステムと端末の実行環境が必要です。そこで、QualiArtsでCIツールとして活用しているJenkinsとOpenSTFというアプリケーションを組み合わせることで、それを実現しました。Airtestの実行や端末の操作などの一連の処理をJenkins上のジョブとして確立し、そのジョブの中でOpenSTFサーバーと連携してテストを実行する端末を確保する流れです。

Jenkinsのジョブとして確立したことによって、任意のタイミングでテストを実行できることもメリットのひとつですが、定期的に自動実行するという回帰テストにとって非常に大きなメリットを実現しました。現在アイプラでは毎日早朝に最新版のアプリを使ってこのチュートリアルのテストを回すようにしています。

また、OpenSTFはモバイル端末についてブラウザやAPIを通じて遠隔操作できる環境を実現するOSSのWebアプリケーションです。STFはSmartphone Test Farmの略称で、主にはデバッグ作業の効率化を目的にしています。

OpenSTF

QualiArtsが所属しているSGE（ゲーム・エンターテイメント事業部）では会社横断でゲーム開発に利用できるOpenSTF環境の開発を進めており、今回はそれが用途にマッチするということで利用することにしました。これによって、特定のテスト用の端末をアイプラのチーム内で誰かが物理的に管理することなく、クラウドのマシンを借りる感覚で実機の自動テストを実現することができました。Jenkins上で特定の端末を指定して実行したり、複数の端末でテストを行うということも可能になっています。

テストレポートの配信と結果のSlack通知

テスト結果についてはAirtestの機能を使ってレポートを生成します。AirtestのレポートはHTMLやCSSによるWeb形式で出力されます。このレポートをどのようにしてプロジェクトに共有するか自動テストの検証チームで検討したところ、GitHub Pagesの活用にたどり着きました。

GitHub PagesはGitHub上で静的なWebサイトをホスティングし公開できるサービスです。当初はパブリックに公開することしかできなかったのですが、2021年にプライベートで公開できる機能がリリースされました。これを活用し、GitHubのプロジェクト内にのみ、自動テストのレポートを展開するようにしました。

レポートについては、テストの種類とアプリケーションのバージョン組み合わせ分のページが閲覧できるようになっています。テストレポートのための成果物をそれぞれ階層的にディレクトリ分けすることで、これを実現しています。また、ひとつひとつのレポートについては溜め続けてしまうと容量の肥大化につながるため、最新のものから一定数の身を残す形をとっています。

そして、Slackへの不具合報告を行う部分でも少し触れましたが、実行が完了した際にはSlack上でリンクと共に成功または失敗の通知が行われます。

以上の工程を経て、アイプラのチュートリアルを定期的かつ自動的にテストし、結果を出力する仕組みが実現しました。運用してみて利便性が悪い点や機能を拡充したい部分もまだまだありますが、ある程度整った仕組みには仕上がったと感じています。実際この仕組みによって発見されたチュートリアルの不具合も存在しており、効果を発揮しています。

おわりに

アイプラのチュートリアルを例に、Unity製モバイルゲームにおけるUIテストの自動化と、それを定常的に実行するための仕組みづくりについて紹介しました。 Airtest、Jenkins、OpenSTFとさまざまなツールの組み合わせが必要になりますが、より汎用的な自動テストの仕組みが検証できたのではないかと感じております。チュートリアルのように単純な操作ではあるものの手動コストが高い、それでいて一定の需要があるような回帰的なテストは自動化と非常に相性がいいです。 QualiArtsでは今後も自動テストについてさらなる技術的な検証やユースケースの検討を予定しています。これを読んでいる方の中にも面倒だがやらないといけない検証作業などありましたら、ぜひ自動化を試みてはいかがでしょうか。