はじめに
皆さま、こんにちは。AIQVE ONE Advent Calendarも残り6日となりました。
19日目を担当します、@keysh_と申します。
私はゲームのテスト自動化をお仕事としているのですが、今年はその中でも
AirTest Poco（以下、Poco） を使って、ゲームを自動化する機会があり、
自身でがっつりと触れられたのが初めてだったので、
その時の所感と、改めて自動化8原則は大事だなと思ったところをまとめていこうかと思います。
AirTest Pocoとは
AirTestとは、NetEase社が開発している画像認識ベースによるアプリケーションの自動化用テストフレームワークのことで、PocoはそのAirTestに同梱されている、アプリ内のメタデータを基に自動テストを実装できるものです。
Poco SDKをアプリ内部に仕込むことで、Unityであれば、ヒエラルキー情報やTextといった指定のUIコンポーネントのオブジェクトといったメタデータを参照することが可能です。
Unityの他にも、Unreal Engineや Cocos-2dxなど様々なプラットホームでテストを実装することができます。
Pocoを使ってみての所感
最初は結構混乱しました…
普段画像認識ベースの方でしか組まないのもあって、
「どっちがどっちのメソッドだっけ？ 」
「これで動く？」
「あれ？動かない…」
みたいな場面が結構ありました(笑)
これは極端な例ですが、画面の指定した部分をタップさせるといった処理をさせる場合、
画像認識ベースでは
touch(画像または座標)
となりますが、Pocoの場合は
poco.click([座標])
または
poco(指定したオブジェクト).click()
といった書き方になります。
普段の感じでスクリプトを書いていざ実行っていうときに「あ…そりゃそうだわ」ってなりました。（構文エラーにはならないので…）
実際に組んだスクリプトを動かした時は、画像認識ベースだと処理に時間がかかる部分が、その半分の時間で済んだり、アニメーションなどでコケやすい部分を指定しても難なくパスしたので、ちょっと感動しました。
ゲーム自動化のネックなところ
さて、話は少々飛びますが、ゲームの自動化は非ゲームのアプリケーションよりも難しいといわれています。
特にネックと思われるのが、以下3点です。
・スマホゲームは施策ごとに部材が変わるため、その都度メンテナンスコストが発生する
・画像によってはアニメーションやエフェクトが入り、ツールが誤認識してしまい、 スクリプトがコケてしまう可能性が高い
・保守作業が頻繁に発生するので、スクリプト自体がスパゲティコードになりやすい
自動化8原則の5つ目に「自動テストシステムの開発は継続的におこなうものである」とあり、確かに変更が加えられた際にその変更に合わせてスクリプトを改修していく必要があります。1度スクリプトを作ったらそれで終わりではありません。
しかしゲームを対象とした場合、その変更がかなり短いスパンで高頻度でやってきます。
皆さまも普段遊んでいるスマホゲームを思い浮かべてみてください。
毎月あるいは毎週のように開催されるイベントやガチャといった施策…これらのTOPページやボタン、報酬、TIPS（ヘルプ画像のこと）などが毎回変わっているかと思います。
画像認識ベースで自動テストを実装した場合、基本はほぼ変わらない部材をテンプレートにするものの、
その施策に合わせて変更しないといけない部分が出てくるため、アプリ更新の度にスクリプトのメンテナンスをし続けなければなりません。
場合によっては、その施策のテストにメンテナンスが間に合わない…
なんてことになる可能性もあります。
それならAppium使ってオブジェクト指定すればいいじゃないか！
と思われる方もいらっしゃるかと思いますが、ゲームアプリは画像自体がボタンになっている、オブジェクトなのでは？と思った部分がオブジェクト要素として取れず、指定できないものなどが多々あり、
画像認識ベース以外で自動化を組むのがとても難しいといった事情があります。
Pocoを使用するゲーム自動化のメリット
そんなネックな部分を解消してくれるのが、Pocoの大きなメリットと言えます。
Appiumでは難しかったゲームアプリ内のメタデータ、つまりオブジェクトを指定して自動テストを実装することが可能なので、ボタンなどの画像が変わっても、その画像が配置されるオブジェクト名が変わらなければ、改修する必要もないため、メンテナンスコストを最小限に抑えられます。
また、画像認識しにくいアニメーションやエフェクトが入っているものでも、オブジェクト自体をみるため、処理がコケにくくなります。
そして画像を認識させるよりも処理が早いです。（個人の感覚です）
その他、PocoにはRPC（ Remote Procedure Callの略。「遠隔手続き呼び出し」とも呼ばれる）を介して、アプリ側からUnity側の特定の関数を呼び出し、テスト実行前の環境設定や特定のテスト値をロジックに流し込むなどを行わせることが可能です。
Poco導入のハードル
ここまでゲーム自動化におけるメリットを書き連ねてきましたが、
実のところ、現場で導入しているケースをあまり見かけません。
Pocoだけではなく、ゲームのテスト自動化全体に言えることではありますが、導入するには越えなければならない高いハードルが存在します。
先述した通り、Pocoを動かすためにはSDKをテスト対象のアプリに仕込まないといけません。
つまり、開発側がSDKをアプリ内に導入してくれることが大前提となります。
完全に外部操作となる画像認識ベースとは違い、アプリの内部に入れ込むため、 何かエラーが起きた時にそのSDKを導入したことで起きたものなのかそうでないのかの切り分け作業が追加で発生してしまいます。
そのため、導入したいと思っていてもかなり難色を示されることが多かったりします。
このハードルを下げるには、「自動化8原則の6つ目「自動化検討はプロジェクト初期から」というように、
プロジェクト初期段階から自動テストを導入することを前提としたうえで、PocoのようなSDKをアプリ内に仕込むことに対して予め合意を取っておくと、スムーズに導入ができるかと思われます。
また、手動テストとバイナリを分けることで他テストへの影響を出ないようにすることも大切です。（バイナリ作成の手間はかかるかもしれませんが…）
まとめ
Pocoはゲームを自動化する上で導入のハードルは少々高めですが、メンテナンスコストの低いテスト実装が行え、ゲーム自動化のネックとなる点をクリアできるので、
これからゲームを作り、テストをしていくプロジェクトには個人的にはおすすめです。
先述した導入のハードルを少しでも低くするために、導入は初期段階から検討し、よりテスト自動化を行いやすい環境を整えていくことで、テスト作業自体の効率化が図れるかと思われます。
スマホゲームのテストを効率化したいと思っている方は、こういったものもあるんだなと少しでも参考になれば幸いです。