スクリーン全体の外観にはスクリーンショットを使用し、表示テキストには OCR を使用し、既知の視覚的ターゲットには画像マッチングを使用します。最強の Android ビジュアル テストは、1 つの焦点を絞ったアサーションと、安定したタイミングおよび障害の証拠を組み合わせます。
短い答え: 真実でなければならないものをテストする
画面全体、コンポーネント、間隔、色、またはタイポグラフィーの視覚的な一貫性を維持する必要がある場合は、スクリーンショット テストを使用します。要件が人が見ることができる単語、特にローカライズされたテキストまたは動的にレンダリングされたテキストに関するものである場合は、OCR を使用します。信頼できる UI 識別子がない場合でも、既知のアイコン、ボタン、バッジ、またはイラストを表示する必要がある場合は、イメージ マッチングを使用します。
要件がセマンティックである場合、つまりコントロールが存在する、有効になっている、選択されている、または安定したラベルを公開している場合は、UI セレクターまたはアクセシビリティ状態から開始します。ターゲットがビジュアル クラスに属し、1 つのテンプレートに対してサイズや位置が大きく変更される可能性がある場合にのみ、オブジェクト検出を追加します。これらのメソッドはレイヤーであり、競合するテスト フレームワークではありません。
- 要件が合格したことをレビュー担当者に納得させる証拠は何かを尋ねます。
- デフォルトですべてのピクセルを比較するのではなく、最も狭い信頼性の高い信号を選択します。
- 観察する前に画面を安定させ、アサーションが失敗したときにアーティファクトを保存します。
Android のビジュアル テスト方法の比較
| 方法 | こんな方に最適 | 主な弱点 | 有用な証拠 |
|---|---|---|---|
| UIまたはアクセシビリティの状態 | コントロール、ラベル、有効な状態、選択、ナビゲーション構造 | カスタムレンダリングされた要素またはアクセスできない要素は、UI ツリーに表示されない場合があります | UI階層、選択したプロパティ、スクリーンショット |
| スクリーンショットまたはゴールデン イメージ | レイアウト、間隔、色、タイポグラフィ、コンポーネントの外観 | 動的データ、アニメーション、デバイスの違い、レンダリングの変更により、ノイズの多い差分が発生する可能性があります | 現在の画像、承認されたベースライン、視覚的な差分 |
| OCR | 表示テキスト、ローカリゼーション、レシート、ステータス メッセージ、ピクセルとしてレンダリングされた値 | 認識品質は、クロップ、スケール、コントラスト、言語データ、回転、セグメンテーションによって決まります。 | ソースのトリミング、認識されたテキスト、信頼性または結果のリスト |
| テンプレートマッチング | 既知のアイコン、ボタン、バッジ、サムネイル、または小さな安定した領域 | テーマ、スケール、圧縮、再デザインによりテンプレートが無効になる可能性があります | テンプレート、検索領域、ベストマッチ、スコア、スクリーンショット |
| 物体検出 | 位置やサイズが変化してもクラスが意味を持ち続けるビジュアル オブジェクト | 互換性のあるモデル、ラベル付きクラス、しきい値、モデル検証が必要です | モデルのバージョン、クラス、ボックス、スコア、スクリーンショット |
Android の公式スクリーンショット テスト ガイダンスでは、現在のレンダリングと承認された参照画像を比較することが説明されています。 Appium の画像プラグインは、特徴マッチング、テンプレート マッチング、類似性比較を公開します。 OpenCV は画像上でテンプレートをスライドさせるメカニズムを文書化する一方、Tesseract は OCR 前処理とページ セグメンテーションが重要な理由を文書化します。ツールは異なりますが、テスト設計の質問は同じです。つまり、この要件を証明する観察は何ですか?
4 つの質問で正しい主張を選択してください
1. 要件は意味的なものですか、それとも視覚的なものですか?
テストで「送信ボタンが有効になっている」と表示された場合は、まず UI の状態を検査します。 「フォント変更後に送信ボタンが切り取られない」と表示されている場合は、スクリーンショットを使用するか、焦点を絞った目視チェックを使用してください。通常、セマンティック クエリは保守が容易ですが、外観を証明することはできません。
2. 正確なテキストは重要ですか?
ユーザーに表示される文字列が要件であり、テキストが UI ツリーを通じて確実に公開されない場合は、OCR を使用します。認識を意味のある最小の領域に制限し、正しい言語を選択し、正規化された結果を比較します。正しい OCR 文字列だけでは切り捨て、重複、またはコントラストの低下を示すことができないため、スクリーンショットを保存してください。
3. 安定した視覚目標は 1 つありますか?
既知のアイコンまたは小さなコントロールにはテンプレート マッチングを使用します。テンプレートをしっかりとトリミングし、対象領域内を検索して、実際の陽性サンプルと陰性サンプルからしきい値を設定します。テーマ、解像度、圧縮されたリモート ストリームにわたって、1 つの普遍的なしきい値を擁護できることはほとんどありません。
4. 全体の構成は一貫していなければなりませんか?
多くの要素間の関係が重要な場合は、スクリーンショットの比較を使用します。フォント、ロケール、デバイス構成、システム バー、時間、ネットワーク データ、アニメーション、およびシードされたコンテンツを制御します。これらの入力を制御できない場合は、ノイズの多いテストを永続的に受け入れる代わりに、動的領域をマスクまたはクロップします。
効果的に失敗するビジュアル テストを構築する
- 承認されたデバイスまたはエミュレータ上でアプリを指定された開始状態にします。
- 固定的な遅延ではなく、安定した状態になるまで待ちます。 UI Automator は安定性の待機を提供し、アプリ固有の準備完了シグナルはさらに優れています。
- 必要な証拠を含む最小のソース領域をキャプチャします。
- 1 つの主要なアサーション (UI 状態、OCR、テンプレート、検出、またはスクリーンショットの比較) を実行します。
- 次のアクションを実行する前に、ソース イメージと構造化された結果を保存します。
- 障害が発生した場合は、停止するか、レビューされた回復パスに従います。テストを続行するためだけに近くの類似物をタップしないでください。
移行を許可すると、視覚的なチェックがより安全になります。現在の状態を観察し、アサーションを作成し、成功後にのみ許可されたアクションを実行し、事後条件を検証します。これは、画像認識自動クリック ガイドで説明されている設計原理と同じです。認識はワークフローが終了したことを証明するものではありません。
実際のデバイスの作業では、モバイル アプリ テスト用の Android 画面ミラーリングを使用すると、テストの設計中にレビュー担当者にライブ ビューが表示されます。Android オートメーション QA スモーク テスト ガイドでは、繰り返されるチェックを範囲を絞って再現可能に保つ方法について説明しています。
3 つの実用的な Android ビジュアル テスト シナリオ
チェックアウト画面のローカリゼーション QA
UI 状態を使用してチェックアウト画面に移動し、OCR を使用してローカライズされた合計とアクションのラベルを確認し、フォーカスされたスクリーンショットを使用して文字列が切り取られたり重なったりしていないことを示します。制御されたテスト データを使用して各ロケールを実行します。全画面ピクセル比較だけでは、翻訳された文字列の長さに敏感になりすぎますが、OCR だけではレイアウトの損傷を見逃してしまいます。
再設計されたツールバーアイコンを確認する
小さなツールバー領域で承認されたアイコンのテンプレートを使用します。明るいテーマと暗いテーマの両方がサポートされている場合は、別々のテンプレートを保持します。一致が失敗した場合は、ツールバーのトリミングと最適な候補のスコアを添付します。アイコンが意図的に再設計されている場合は、形状が合格するまでしきい値を下げるのではなく、テンプレートを確認して置き換えます。
導入後の実際の電話煙テスト
既知のアカウントとアプリの状態から開始し、ランディング画面を待ち、その ID をアサートし、許可されたアクションを 1 つ実行して、次の名前付き状態を確認します。失敗するたびにスクリーンショットをキャプチャします。デバイス密度、許可ダイアログ、キーボード、通知、およびシステム アップデートは実際の電話環境の一部であるため、テストではそれらを非表示にするのではなく報告する必要があります。
よくある誤った失敗とその防止方法
| 症状 | 考えられる原因 | より良い応答 |
|---|---|---|
| スクリーンショットの差分は実行ごとに変更されます | 時計、アニメーション、広告、シード データ、キーボード、システム バー、またはネットワーク コンテンツ | 入力をフリーズし、安定するまで待ち、動的領域のみをトリミングまたはマスクします |
| OCR はもっともらしいが間違ったテキストを返します | 間違った言語、低コントラスト、小さなトリミング、回転、ノイズ、または不適切なセグメンテーション | トリミングを保存し、スケールとコントラストを改善し、言語とセグメンテーションを慎重に選択します |
| テンプレート マッチは 1 台の電話でのみ機能します | 異なる密度、テーマ、スケーリング、アスペクト比、または圧縮 | サポートされているビジュアル バリアントに対して関心領域と検証済みのテンプレートを使用する |
| 正しい画像が見つかりましたが、タップに失敗しました | 一致座標が現在の画面またはオーバーレイ ブロック入力に変換されませんでした | 認識と行動を分離し、次の状態を検証する |
| 間違った画面でテストが続行される | 事後条件または失敗エッジなし | 予想される状態に名前を付け、現在の画面がレビューされたパスの外にあるときに停止します |
| オブジェクト検出器が間違ったクラスを検出しました | モデルまたはラベルがアプリのドメインに適合しません。しきい値が検証されていません | 互換性のあるモデルを使用し、バージョンとスコアを記録し、陰性サンプルをテストします |
Android の回帰テストに関するコミュニティの議論では、多くの場合、デバイス マトリックス、不安定なタイミング、ベースライン レビュー、コンテンツが変化する画面など、同じメンテナンス コストに戻ります。これらはビジュアルテストを放棄する理由にはなりません。これらは、テスト環境、許容される差異、および失敗による成果物を明示する理由になります。
LaiCai Flow がビジュアル テストにどのように適合するか
LaiCai Flowは、LaiCai Screen Mirroring 内の自動化機能です。フローでは、スクリーンショットのキャプチャ、UI チェック、OCR、テンプレート マッチング、オブジェクト検出、条件、アクション、および明示的な成功または失敗の遷移を組み合わせることができます。これにより、テスターは認識を孤立したトリックとして扱うのではなく、画面を状態としてモデル化できます。
LaiCai Flow Insideを使用すると、展開後に互換性のあるプロファイルを電話機で LaiCai Android Agent を通じて実行できます。互換性は、そのプロファイルで使用されるすべてのノードとアセットに依存します。ローカル OCR は Tesseract を使用します。テンプレート マッチングでは、選択した画像アセットと構成可能なスコアを使用します。互換性のあるローカル検出では、サポートされているモデルが使用されます。ネットワーク ノードまたはリモート モデルには、依然として独自のネットワーク依存関係が必要です。
これにより、すべてのビジュアル テストが自動的に信頼できるようになるわけではありません。チームには依然として、代表的なベースライン、テンプレート、OCR 領域、モデル、しきい値、否定的なケース、事後条件が必要です。価値があるのは、これらの決定と移行を 1 つのワークフローでレビューできることです。AI Android オートメーション ガイドは、オーサリングと実際のデバイスの実行についてより広範な視点を提供します。
不合格の視覚テストに対する最小限の証拠の束
- テスト名、アプリのビルド、デバイス モデル、Android バージョン、ロケール、テーマ、向き。
- アサーションで使用されるソースのスクリーンショットまたはトリミングされた領域。
- 予期されるベースライン、テンプレート、テキスト、クラス、または UI プロパティ。
- 観察された差分、OCR 結果、境界ボックス、一致スコア、または UI 値。
- 以前の名前付き状態、試行されたアクション、予想される次の状態、および停止理由。
- レビュー担当者が決定を再現できるようにするための、アセット、モデル、またはベースライン バージョン。
このコンテキストのない合格/不合格ラベルは、次の人に実行全体を再現することを強制します。コンパクトな証拠バンドルは、失敗をレビュー可能な決定に変えます。製品を修正し、テストを安定させ、承認されたビジュアル資産を更新し、サポートされていないデバイス構成を拒否します。
Android ビジュアル テストに関するよくある質問
すべての Android UI テストにスクリーンショットを含める必要がありますか?
いいえ。外観が重要な場合、または失敗した成果物がレビュー担当者に役立つ場合には、スクリーンショットを使用します。通常、セマンティック アサーションは、UI ツリーが確実に公開する動作に適しています。
OCR は画像マッチングよりも優れていますか?
OCR は、表示されるテキストに関する質問に答えます。画像マッチングは、既知の視覚パターンに関する質問に答えます。要件にラベルとその外観の両方が含まれる場合は、OCR に加えて、焦点を当てたスクリーンショットまたはテンプレート チェックを使用します。
スクリーンショット テストは実際の Android スマートフォンで実行できますか?
はい、しかし実際のデバイスでは、制御されたホスト側のレンダラやエミュレータよりも多くのバリエーションが導入されます。デバイス構成を記録し、システム UI とデータを安定させ、実際にサポートするデバイス マトリックスに対する期待値を設定します。
オブジェクト検出はいつ使用する必要がありますか?
これは、意味のあるオブジェクト クラスが安定したテンプレートの許容範囲を超えて移動またはスケーリングする場合、および互換性のあるモデルがアプリの実際のイメージで検証されている場合にのみ使用します。より高度に聞こえるからといって、検出器を追加しないでください。
テクノロジーを選択する前に証拠を選択してください
信頼性の高い Android ビジュアル テストは、「レビュー担当者は何を証明できる必要があるか?」という 1 つの文から始まります。セマンティクスには UI 状態、合成にはスクリーンショット、テキストには OCR、既知の視覚ターゲットにはテンプレート マッチング、可変ジオメトリを持つ検証済みクラスにはオブジェクト検出を選択します。
次に、状態遷移の観察部分を作成します。つまり、安定化、キャプチャ、アサート、成功後にのみ動作し、事後条件を検証し、失敗の証拠を保存します。この設計は、切断されたビジョン コールの集合よりも理解しやすく、アプリやデバイスが変更された場合でも保守がはるかに簡単です。