画像認識とヒエラルキーベースを併用した自動テスト改善のアプローチ

GREE Tech Conference 2025で発表された資料です。
https://techcon.gree.jp/2025/session/TrackC-5

Transcript

1. 株式会社WFS　山木 弘 画像認識とヒエラルキーベースを併用した 自動テスト改善のアプローチ
2. 2 山木 弘（やまき ひろし） 株式会社WFS シニアQA コンシューマー向けゲーム開発会社を経て 2012年にグリー株式会社（現：グリーホール ディングス株式会社）に入社 運用中のタイトルを中心に静的データの検証や モバイルアプリケーションの検証の自動化を担 当
3. 3 目次 • 背景と課題
 • ヒエラルキーベースのテスト導入
 • まとめと今後の展望

4. 4 目次 • 背景と課題
 • ヒエラルキーベースのテスト導入
 • まとめと今後の展望

5. これまでのテスト自動化の取り組み 
 • 画像認識ベースのテストを採用
 • 直感的で導入しやすいという利点 5 背景と課題 画像認識ベースのテスト 
 直感的で導入しやすい 

6. 画像認識ベースのテストにおける課題 
 • 信頼性
 ◦ UIの色味やレイアウト変更により画像認識の精度が低下
 ◦ 意図しない画像を正解と誤認識するケース
 • 効率性
 ◦ 画像認識に時間がかかり、テスト実行の効率が低下
 • 堅牢性
 ◦ 画像認識に失敗すると、後続のテストシナリオが実行不可
 ◦ 画像変更に対する耐性が低く、保守性にも影響 6 背景と課題
7. 7 背景と課題 課題の影響 
 • テスト結果の信頼性が低下し、品質保証の観点でリスクとなる
 • テストの実行時間が長くなり、CI/CDパイプラインへの影響も懸念
 • 画像変更によりスクリプトの修正が必要となり、保守コストが増加 信頼性の低下 効率性の低下 保守コストの増加
8. 改善の対象 テスト品質向上のビジョン 
 • 画像認識と新しい手法のテストの併用によりテスト品質を改善 8 テスト品質向上のアプローチ 画像の誤認識、画像認識の処理時間、スクリプトの堅牢性の低さ 
 既存のテスト手法との互換性を維持(画像認識と共存) 
 品質向上を目的とした新しいテスト手法の選択的導入(画像認識と相互に補完) 
 条件
 対象

9. 9 目次 • 背景と課題
 • ヒエラルキーベースのテスト導入
 • まとめと今後の展望
10. 導入の背景と目的 
 • 画像認識ベースのテストにおける課題への対応 
 ◦ 誤認識(信頼性)
 ◦ 処理時間(効率性)
 ◦ 変更による失敗(堅牢性) 10 ヒエラルキーベースのテスト導入 UI構造の情報を利用するヒエラルキーベースのテストを導入 

11. 11 ヒエラルキーベースのテスト導入 ヒエラルキーベースのテストとは 
 • UI要素の階層構造を利用して、要素を論理的に特定・操作 
 • 見た目に依存せず、構造的にUIを捉える 
 ◦ 誤認識が少なく、信頼性が高い
 ◦ 処理が高速で、実行効率が高い
 ◦ 見た目に依存せず、UI変更に強い
12. 画像認識とヒエラルキーベースの比較 
 　特徴 12 ヒエラルキーベースのテスト導入 観点 画像認識 ヒエラルキーベース 操作対象の特定 画面上の画像 UI要素の構造 UI変更への耐性 低い（変化、差し替え） 高い（構造の変更は少ない） 実行速度 比較的遅い 速い 実装の直感性 高い（見た目） やや低い（構造の理解が必要） 誤認識のリスク 高い（類似画像） やや低い（論理的な識別） ※どちらが優れているかではなく、得意な領域が異なる 

13. 13 ヒエラルキーベースのテスト導入 画像認識とヒエラルキーベースの併用の意義 
 • シーンに応じた最適な選択が可能 
 ◦ 画像認識が有効なケース 
 ▪ 見た目の確認が重要なUI
 ▪ UI構造が取得できない環境
 ◦ ヒエラルキーベースが有効なケース 
 ▪ 見た目の確認が必要ないUI
 ▪ ボタンやテキストなど、構造が安定しているUI
14. 14 ヒエラルキーベースのテスト導入 画像認識との比較と併用の意義 
 • 併用の意義 
 ◦ テストの柔軟性が向上し、失敗率の低減・保守性の向上
 ◦ 実行時間の短縮と安定したテスト結果の取得が可能
 ◦ 画像認識の直感性とヒエラルキーの堅牢性を両立
15. 15 使用したツール：Airtest & Poco Airtest 
 • 概要
 ◦ NetEaseが開発したUI自動テストフレームワーク。画像認識をベースにしてお り、クロスプラットフォーム（Android/iOS/Windows）対応。
 
 • 特徴
 ◦ スクリーンショットで操作対象を認識
 ◦ Pythonでスクリプトの記述が可能
 ◦ ゲームUIなど、視覚的要素が強いアプリに適している
16. 16 使用したツール：Airtest & Poco Poco
 • 概要
 ◦ Airtestと連携して動作するUI要素取得ライブラリ。アプリのUIツリー構造を取 得し、ヒエラルキー情報に基づいて要素を操作
 
 • 特徴
 ◦ UI要素の名前、クラス、親子関係などを取得可能
 ◦ 見た目に依存せず、論理的に要素を特定
 ◦ Android/iOS/Unityなど複数のプラットフォームに対応
17. 17 使用したツール：Airtest & Poco 選定した理由 
 • 既存の画像認識ベースのテストを活かしつつ、ヒエラルキー情報を扱えるPocoを 追加することで、段階的な移行と併用が可能
 • AirtestのライブラリであるためPythonベースで統一されており、追加で学習するコ ストが低く、スクリプトの再利用性が高い
18. 18 実装例(画像認識のみ / 併用) 誤認識の比較( 画像認識のみ )
 • テスト内容は「1-2」を選択する操作 • キャプチャ元画像「1-2」をゲーム 画面で検索 • 時間経過で色調が変化するようなイ メージの場合に別のオブジェクトと類 似度が近くなり誤認識 • リトライやしきい値の調整が必要 ◦ 実装コストも増加 キャプチャ元画像 時間の経過により色調が変化するUIで誤認識 キャプチャ元画像の「1-2」を検索
19. 19 実装例(画像認識のみ / 併用) 誤認識の比較( 併用)
 • 対象のソフトウェアにSDKを組み込み APIを通じて階層構造情報を取得 • 名前や識別子を指定することで要素を 操作可能 • 見た目の変化に影響されないテスト 識別子をコードで指定 poco = UnityPoco() poco(“Stage1_2”).tap() 階層構造情報から「1-2」を検索 色調の変化するUIでも問題なく操作可能
20. 20 実装例(画像認識のみ / 併用) 処理時間の比較( 画像認識のみ )
 • 画像認識を行う際、複数のアルゴリズムを組み合わせて使用 ◦ マルチスケールテンプレートマッチング、SHIFT、BRISKなど • iOSやAndroidのキャプチャから静的に用意したUIパーツを検索するのに3 秒程度 • 使用するアルゴリズムの種類を減らせば速度は上がる ◦ シーンによりチューニングが必要 ▪ 実装コストの増加
21. 21 実装例(画像認識のみ / 併用) 処理時間の比較( 併用)
 • 画像認識と比べて平均して1テストケースあたり30倍程度高速に処理 • 画像認識ではキャプチャからピクセル単位で走査するため計算量が多い • 階層構造はノードをたどるので検索回数が少ない
22. 22 実装例(画像認識のみ / 併用) 画像変更による影響( 画像認識のみ )
 • 要素の識別に画像を使用 ◦ 画像変更で対象の識別が不能に • 画像のタップでシーンが遷移する場 合、遷移ができずテストが継続できな いため失敗 キャプチャ元画像 形状の変化により対象を識別不能 キャプチャ元画像の「1-2」を検索
23. 23 実装例(画像認識のみ / 併用) 画像変更による影響(併用) 
 • 画像認識で要素の取得を試す • 存在する場合にはタップ • 存在しない場合にはスクリーン ショットで画像を見つけられな かったエビデンスを残し、ログも 出力する • 遷移は階層構造の情報を使用して 行う 画像がみつからない場合はスクショして継続 target_image = find(Template(“Stage1_2.png”)) if target_image != None: 　target_image.tap() else: 　snapshot() #スクショ 　 　Logger.log(“Stage1_2.pngが見つからない”) 　poco = UnityPoco() 　poco(“Stage1_2”).tap()
24. 24 目次 • 背景と課題
 • ヒエラルキーベースのテスト導入
 • まとめと今後の展望
25. 25 導入の効果 併用による効果 
 • 誤認識の抑制（信頼性の向上） 
 ◦ Before
 ▪ レイアウトや色味の違いで識別不可
 ◦ After
 ▪ 階層構造の情報からUI要素の位置を取得可能
 ▪ レイアウトや色味の違いに左右されないテスト
26. 26 導入の効果 併用による効果 
 • テスト実行時間の削減（効率性の向上） 
 ◦ Before
 ▪ 全てのテストが画像認識のためテスト実行に時間がかかる
 ◦ After
 ▪ テストの内容により使い分けることが可能なため
 全体的なテスト速度が向上
 ▪ 代替可能なテストケースの場合、処理の効率が約30倍向上

27. 27 導入の効果 併用による効果 
 • 画像変更による影響 
 ◦ Before
 ▪ 画像認識の失敗やテスト対象の画像が表示されていない場合、
 後続のテストシナリオの実行が不可能
 ◦ After
 ▪ 代替のテストを行うことでUI要素を特定し、
 テストシナリオの実行が可能
28. 28 今後の展望 • ローカルAI × 自然言語によるテスト自動化 
 • ファインチューニングによる精度向上
 • 非エンジニアでも自然言語でテスト記述が可能に
 • テストケースの網羅性向上と、保守性の高いテスト基盤の構築
 • 将来的には、AIによるテストシナリオの自動提案・最適化

29. ご清聴ありがとうございました 29