ローソンデジタルイノベーション　テックブログ

ローソンデジタルイノベーション（LDI）の技術ブログです

トップ > スマホアプリ自動テストフレームワークのShiratesを画像認識技術で改良しました

スマホアプリ自動テストフレームワークのShiratesを画像認識技術で改良しました

プロジェクトディベロップメント部の仙波です。

スマホアプリ用自動テストフレームワーク Shirates（シラテス） を画像認識技術を活用して改良しました。 メジャーアップデートです。macOSで利用できます。

github.com

旧バージョンが抱えていた問題

Shiratesはスマホを操作するドライバーとして内部でAppiumを使用していますが、ドライバの種別毎に以下のような制約がありました。

iOS(XCUITestDriver)固有の問題

  • テストの実行（特に画面の要素を全て取得する処理）が非常に遅い
  • 画面に表示されていない要素が取得される場合がある（テストコードで回避する必要がある）
  • 画面に表示されている要素が取得できない場合がある

Android(UIAutomator2 Driver)固有の問題

  • エミュレーターが不安定で実行時エラーが発生しやすいため、テストのリランがたびたび必要となる


また、共通の問題として以下のものがありました。

共通の問題

  • AndroidとiOSのネイティブアプリをサポートしているが、FlutterやCompose Multiplatformといった新手の開発フレームワークに対応できていない
  • 画像マッチング機能を実装しているが、OS毎、画面の解像度毎にテンプレート画像を用意する必要があり、作成およびメンテナンスに工数がかかる
  • AndroidとiOSの差異を吸収するマッピングファイルの作成およびメンテナンスに工数がかかる
  • AndroidとiOSの差異を吸収するための仕組みの学習コストが高く、初学者にとって敷居が高い

対策の必要性

テストの実行が遅い問題はテストを並列化して影響を緩和してきましたが、その他の問題は対策できずにいました。

近年のアプリ開発のトレンドとして、AndroidとiOSでコードを統一する開発プラットフォームである Flutter や Compose Multiplatform の存在感が増してきています。 転機は2024年にFlutterとCompose Multiplatformの対応のための調査をしたことでした。 Compose Multiplatformで作成したアプリの画面の情報をAppiumを使用して取得してみたところ、テストコード作成のために必要な情報が存在していませんでした。結果、テストコードを作成することができませんでした。

このまま現行のShiratesを使い続けると新しいプラットフォームに対応できず、近い将来自動テストの運用が行き詰まるのではないかと危機感を感じました。

機械学習とAI-OCR

上記の問題を解決するためには、アプリの画面情報を取得するドライバーとしてAppium以外のものを検討する必要がありますが オープンソースソフトウェアでAppium以外に利用できるメジャーな製品は見当たりません。

また、Appiumのように画面のDOM（Document Object Model）に依存した情報を取得する方式だと、開発プラットフォームに依存してしまうので それとは違う方式にする必要があります。

そうなると、画像認識によるコンピュータービジョン技術を活用するしかないのですが、今回改めて調査を実施しました。 すると、近年のAI関連の技術発展の賜物だと思うのですが、コンピュータービジョン技術における機械学習の活用が進んでおり、敷居が非常に低く、かつ高機能で高品質なAPIが提供されていることがわかりました。 これらを使えばうまく実装できるかもしれないと思いました。

鍵となる技術は 機械学習 と AI-OCR です。

機械学習

機械学習はテンプレート画像を学習させることで画像のマッチングを実現します。現在表示されている画面の画面名（ラベル）を識別したり、画面の画像においてテンプレート画像にマッチする部位の座標を取得したりするのに使用します。

Appleのコンピュータービジョン技術であるVision Frameworkで評価したところ、十分実用に耐える程度の精度を実現できることを確認しました。

AI-OCR

AI-OCRは画面に表示されたテキストの座標と値を取得するのに使用します。

Vision Frameworkで評価したところ、十分実用に耐える程度の精度を持っていることを確認しました。 従来型のOCRと比較すると驚異の認識率を達成しており、機械学習の威力を感じました。また、macOSにバンドルされている機能なので追加費用は発生しません。

Shirates/Vision

機械学習とAI-OCRの導入によってShiratesを改修しました。フレームワークとしてはmacOS上で利用できるVision Frameworkを採用しました。

Shiratesの既存の機能はそのままサポートするため、既存のAPIの関数はそのままとし、同等の関数を新方式で再度実装しました。 これに伴い、旧機能はShirates/Classic、新機能はShirates/Visionと呼び分けることにしました。 Shirates/Classicで作成済みのテストコードは段階的にShirates/Visionに置き換えることができます。

実行時間の新旧比較

弊社が開発しているアプリのテストコードにおいて、新旧のテストコードで実行時間を計測したところ、以下のようになりました。
使用した機材は MacBook Pro 14インチ 2021、M1 Max、メモリ64GBです。

Androidの実行時間

305秒（5分5秒）→218秒（3分38秒）に短縮されました。87秒（1分27秒）短縮です。

Androidは旧バージョンでも実行速度は速いと感じていたので、改修後はむしろ遅くなってしまうことを懸念していましたが、 予想に反して平均で30%程度改善されることを確認しました。

iOSの実行時間

727秒（12分7秒）→344秒（5分44秒）に短縮されました。383秒（6分23秒）短縮です。

iOSでは実行速度が改善されることを予想していましたが、平均で50%以上改善されることを確認し、想定を上回る結果となりました。

なぜ速くなっているのか（推定）

Appiumの実装が遅く、M1チップのNPUを使用したAIの推論処理は想像以上に速いのが、差が発生する要因であると考えます。 加えて、Shirates/Visionは実装当初から徹底的にパフォーマンスチューニングを行ったことが功を奏したと考えています。

テスト実行の安定性

Shirates/Classicでは並列実行するとAndroidエミュレーターでテストを継続不能な異常（スクリーンショットが撮れなくなるなど）がたまに発生していましたが Shirates/Visionでは安定することが確認できました。

Appiumの機能で画面情報を取得しないよう変更したことで、Appiumやエミュレーターに高負荷がかからなくなったのが安定化した要因ではないかと推測しています。

改善点まとめ

Shirates/Visionで改善された点を次表にまとめます。

No 問題 顛末 顛末 補足
1 (iOS)テストの実行（特に画面の要素を全て取得する処理）が非常に遅い ◎ 解消
2 (iOS)画面に表示されていない要素が取得される場合がある（テストコードで回避する必要がある） ◎ 解消 画像認識方式では原理上問題が発生しない
3 (iOS)画面に表示されている要素が取得できない場合がある ◎ 解消 画像認識で取得できる
4 (Android)エミュレーターが不安定で実行時エラーが発生しやすいため、テストのリランがたびたび必要となる ○ 緩和 完璧ではないが、比較的安定した
5 AndroidとiOSのネイティブアプリをサポートしているが、FlutterやCompose Multiplatformといった新手の開発フレームワークに対応できていない ◎ 解消 画像認識方式は原理上マルチプラットフォームに対応できる
6 画像マッチング機能を実装しているが、OS毎、画面の解像度毎にテンプレート画像を用意する必要があり、作成およびメンテナンスに工数がかかる ◎ 解消 機械学習のロバスト性によって差異が吸収される。テンプレート画像は1つ登録すれば良い
7 AndroidとiOSの差異を吸収するマッピングファイルの作成およびメンテナンスに工数がかかる ◎ 解消 画像認識方式ではマッピングファイルは作成不要となった。代わりに画像をキャプチャして画像テンプレートを登録するだけでよい
8 AndroidとiOSの差異を吸収するための仕組みの学習コストが高く、初学者にとって敷居が高い ◎ 解消 独自のセレクターの使い方を学習する必要は無くなった

新方式の導入によって、従来抱えていた問題がほぼ解消されたと言えます。

新方式で発生する問題

コンピュータービジョン方式に変更することによって旧製品の問題の多くが改善されましたが、 一方で新たに抱え込んだ問題もあります。

AI-OCRの精度の問題

Vision FrameworkのAI-OCRは精度は高いですが、OCRであるがゆえに以下のような問題があります。

誤認識が発生する
  • アイコンを文字として認識してしまう場合があります（虫眼鏡アイコンを「Q」など）
  • 似た文字は区別できない場合があります（「く」と「<」など）
  • 通常の文字と小書き文字を間違える場合があります（「つ」を「っ」など）
  • 誤認識しやすい文字や欠落しやすい文字があります（「送信」を「送言」、「配偶者」を「配者」など）

Shirates/Visionでは正誤表（eratta）を実装しています。必要に応じて正誤表にエントリーを追加し、テキスト認識結果を修正することができます。

文字コードレベルの比較はできない
  • OCR(Optical Charactor Recognition)は見た目で文字を判断するので、期待した文字コードを取得できない場合があります
  • Unicodeの波ダッシュ・全角チルダ問題も発生します（「〜」(U+301C)と「～」(U+FF5E)）
  • 全角と半角の区別はうまくできません（「Ａ」と「A」、「ア」と「ｱ」など）

Shiratesは必要ならばShirates/ClassicのAPIを使用することで文字コードレベルの比較を行うことができますが、実行速度は遅くなります。

一方、AI-OCRの認識結果のテキストをそのまま比較することはできませんが、文字列を正規化（≒名寄せ）することである程度の実用性をもって検証することができます。 Shirates/Visionのテキスト検証用関数には開発時の知見をもとに独自の正規化処理が組み込まれています。

まとめ

  • Shiratesを画像認識技術を活用して改良したShirates/Visionを作成しました
  • 新方式は開発プラットフォームによる差異が発生しません。FlutterやCompose Multiplatformで作成したアプリでも利用できます
  • Appium起因によって従来製品が抱えていた問題がほぼ解消し、生産性や品質が向上しました
  • 一方で、AI-OCRに固有の問題を抱えることになりました。必要ならば旧APIを使用することで問題を回避できるので、テストに要求される文字認識の精度とテスト実行速度のバランスを考えて運用することができます


Shirates はオープンソースソフトウェアとして公開中です。 スマホアプリのテストの自動化に興味がある方はぜひ一度ご確認ください。

github.com