Android自動化の停止条件：再試行、停止、またはレビュー？

安全なAndroidワークフローは、何かが起こるまでタップし続けることはありません。現在の画面を識別し、再試行を制限し、次の状態を確認し、結果が不確実な場合は証拠で停止します。

簡単な答え：次のアクションがもはや正当化されないときに停止する

Android自動化の停止条件とは、現在の画面、結果、またはタイミングが次のアクションをサポートしなくなったときにワークフローが継続しないようにするルールです。実行を終了したり、制御された結果を返したり、証拠を収集したり、ケースを人に送信したりできます。ポイントは、すべての驚きで停止することではありません。ポイントは、不確実性を別のタップに変えるのを避けることです。

信頼性の高いワークフローは、重要なアクションの前に4つの質問に答えます。電話のステータスはどのようなものにするべきですか？そのステータスを証明する観察は何ですか？どのくらいの回復試行は許容されますか？ステータスが表示されない場合は、どのような証拠を保存する必要がありますか？Android UI Automatorには条件付き待ちと安定性チェックが含まれており、WorkManagerにはキャンセルと停止処理のドキュメントが含まれています。共通のデザインの教訓はシンプルです。待ち、再試行、停止には明示的な制限が必要です。

• 予想される状態が肯定的に特定された場合にのみ継続してください。
• 失敗が一時的であり、再試行に明確な制限がある場合にのみ再試行してください。
• 画面が不明、アクションが敏感、または後続条件が失敗している場合は、停止またはレビューをリクエストします。

続ける、待つ、再試行、停止、またはレビューしますか？

これらの選択は互換性がないです。待ちは同じ状態の時間が落ち着くようにします。再試行は制限された観察または回復アクションを繰り返します。ブランチは既知の結果を選択します。停止はレビューされたパスを終了します。自動化が安全に選択するための十分な証拠が不足している場合は、人間のレビューが適切です。

ステップ1：アクションを選択する前に、ステータスを名付けます。

この手順の最後に、すべての重要な画面には名前と観察可能な事実の小さなセットがあります。テストビルドを開いたり、設定ページに移動したり、非敏感なオプションを変更したり、新しい状態を確認したりするなど、狭いワークフローから始めます。長時間の座標の順序から始めてはいけません。

1. 開始状態、次の状態への期待、および受け入れ可能な代替状態を書き留めます。
2. 各状態ごとに、最も狭い有用なシグナルを選択します。UIプロパティ、表示テキスト、既知の画像、検出済みのオブジェクト、またはフォーカスされたスクリーンショットです。
3. 予期せぬアカウント、許可、購入、削除、またはプロダクションデータの画面など、自動アクションを受け付けるべきでない画面はすべてマークします。

検証は簡単です。別のレビュアーが状態定義を見て、次のアクションが許可される理由を説明できるはずです。 その画像認識自動クリックガイド視覚的なターゲットを見つけるだけでは不十分であることを示しています。ワークフローには、タップする前の事前条件と、タップ後の事後条件が必要です。

ステップ2：各状態を証明する観察を1つ選択する

この手順の終わりに、各状態にはプライマリ観察とフォールバックの証拠ソースがあります。ラベル、選択された状態、有効なコントロール、アイテム数などの意味的な事実にはUI構造を使用します。表示可能なテキストが重要ですが、UIツリーが信頼できる方法でそれを露出しない場合はOCRを使用します。既知の視覚的ターゲットにはテンプレートマッチングを使用し、位置またはサイズが異なる検証済みのクラスにはオブジェクト検出を使用します。

複数の弱い信号を積み重ねて組み合わせの確実性を呼び出すことを避けましょう。広範なスクリーンショット、検証されていないテンプレート、および部分的なOCR結果は、自動的に信頼できる決定を下すわけではありません。代わりに、1つの耐荷重観測を定義し、他の信号を支持証拠として記録します。 そのAndroidの視覚テスト比較UI状態、OCR、スクリーンショット、テンプレート、検出がそれぞれどこに適合するかを説明します。

検証とは、陽性サンプルと陰性サンプルの両方をテストすることを意味します。 状態は、意図した画面で通過し、視覚的に類似しているが間違っている画面で失敗する必要があります。 これらの状態を区別できない場合は、領域を絞り込み、信号を変更するか、アクションの前にワークフローを停止します。

ステップ3：すべての待ちと再試行に予算を設定します。

この手順の終わりまでに、ループは永遠に実行することはできません。すべての待ち時間は、タイムアウトまたは名前付きの準備状態を必要とします。すべての再試行には、最大試行回数、合理的な間隔、および状況を悪化させずに再び試行で成功できる理由が必要です。

Android自動化に関するコミュニティの質問には、永遠に待っているループや、停止しているように見えるタスクがよく含まれます。最大試行ルールは便利ですが、カウントは操作に従う必要があります。読み取り専用チェックは、状態変更アクションよりも多くの試行を許容する場合があります。正しい数は、通常の遅延をカバーする最小のレビュー済み予算です。

ステップ4：成功を宣言する前に、後条件を確認します。

この手順の終了時点で、配信されたタップは完了したタスクとして処理されなくなりました。各状態変更アクションの後、インターフェースが安定するまで待って、予想される結果を確認してください。ポストコンディションが欠落している場合は、ワークフローが次アクションに無音で継続してはならないはずです。

1. アクションを承認したステータスを記録します。
2. 承認された単一のアクションを実行します。
3. 名前付きのポストコンディションまたは制限付きタイムアウトを待つ。
4. 次の州へのルートの成功と、証拠のキャプチャ、レビュー済みのリカバリ、または停止に失敗。

これは、オーバーレイ、遅延ナビゲーション、入力ミス、期限切れの座標、類似した画面から保護します。 また、より良いエラーレポートを生成します。 レビュー者は、期待されていたもの、発生したアクション、および次の状態が表示されなかったものを確認できます。

ステップ5：人が判断するのに十分な証拠を保存する

この手順の最後に、各停止点では、曖昧な失敗ラベルではなく、コンパクトな証拠バケットが生成されます。リカバリが画面を変更する前に証拠をキャプチャします。診断に必要なものだけを残し、スクリーンショットやログは、テスト中のアプリのデータポリシーに従って処理します。

• ワークフローとステップ名、Appのビルド、デバイス、Androidバージョン、ローケール、並び方。
• 予想される状態、観測された状態、状態結果、試行回数、経過時間。
• 焦点を当てたスクリーンショットまたはトリミング、およびOCRテキスト、マッチスコア、UIプロパティ、または関連する場合の検出結果。
• 最後の成功したステート、試みたアクション、欠落した後条件、明示的な停止理由。
• 推奨されるレビュー担当者の選択：既知の修正を行った後、再試行するか、受け入れられた状態を更新するか、または製品を調査します。

有用なハンドオフにより、誰かが最初全体を実行せずに次の決定を下すことができます。 そのAndroid自動化QAスモークテストガイド実際のデバイスのチェックを狭く、再現可能に保つためのより広範な例を示しています。

どうやってLaiCai Flow安全な境界線を模範する

LaiCai Flowは、内部にある自動化機能です。LaiCai Screen Mirroring. フローは、UI構造または視覚状態を観察したり、既知の結果の間で分岐したり、目に見えるように待ったり、制限された回数だけ繰り返したり、成功または制限まで子フローを呼び出したり、明示的な戻りまたは停止動作を介して終了したりできます。これらのビルドブロックにより、レビュー者に安全な決定が表示されます。

典型的なパターンでは、UI、OCR、テンプレート、または検出ノードが電話を一回観察します。 ブランチは既知の成功または失敗をルーティングします。 待ちは実際のビジネス遅延を表します。 境界付きループは一時的な状態を処理します。 回復エッジのない失敗した観察は、同じアクションを永遠に供給する代わりに、現在のフローを終了できます。

LaiCai Flow Inside互換性の高いプロファイルを実行できます。LaiCai Android Agent展開後の電話。互換性は、そのプロファイルで使用される各ノード、資産、モデル、およびネットワーク依存性によって依然として異なります。デバイスの上で実行しても、制限、証拠、またはレビューの必要性はなくなります。

展開前の実用的なレビューチェックリスト

• すべてのアクションには、名前付きの前条件と検証可能な後条件があります。
• すべての待ち込みにはタイムアウトまたは準備状態があり、すべての再試行には最大試行回数が設定されています。
• 不明な状態は停止するか、レビュー済みのリカバリパスに移動します。
• 結果が不確実な場合、敏感な行動は決して盲目的に繰り返されることはありません。
• 画面が再び変更される前に、不具合の証拠がキャプチャされます。
• 正のケース、負のケース、遅いケース、中断されたケース、予期せぬ画面ケースは、正規のデバイスでテストされています。

これらの記述のうち一方が誤っている場合、ワークフローは無人操作に準備ができていません。それでも、監視モードではまだ有効かもしれません。AIアンドロイド自動化、その場所では、人がデバイスを監視し、状態条件を調整し、故障の証拠を確認することができます。

Android自動化の停止条件のFAQ

固定された遅延は停止条件ですか？

いいえ。固定された遅延はワークフローを一時停止するだけです。 アプリが期待される状態に達したという証拠にはなりません。 遅延を状態観察とタイムアウトと組み合わせてください。

すべての失敗が全体のワークフローを停止すべきでしょうか？

いいえ。既知の一時的な障害は、レビュー済みで制限されたリカバリパスに従う可能性があります。未知の状態、欠落した後条件、または不確実な敏感なアクションは、通常、停止するかレビューを要求する必要があります。

安全な再試行回数はいくつですか？

普遍的な数はありません。測定された通常の遅延をカバーする最小限の制限を使用し、状態を変更するアクションの制限を削減します。アクションを繰り返すと結果が重複する可能性がある場合は、一意性検証を実行するか、自動的に再試行しないでください。

AIは停止ルールを必要としないのでしょうか？

いいえ。AIは画面の解釈やワークフローの提案に役立つ場合がありますが、実行にはまだ明示的な許可された状態、予算、後条件、およびレビュー境界が必要です。不確実性は、継続する許可ではなく、証拠を収集する理由です。

不確実性を自動化するのではなく、可視化します。

信頼できるAndroidワークフローとは、最も長く実行されるものではありません。それは、各アクションがなぜ許可されたのか、どのような結果を期待していたのか、証拠が変更されたときになぜ停止したのかを説明できるものです。

州を指定し、1つの耐荷重観測を選択し、すべての待ちと再試行をバインドし、すべてのポストコンディションを検証し、有用なハンドオフを保持します。 この設計により、停止条件を防御的なコードからワークフローの運用ポリシーに変換できます。

• Android開発者：UIオートマタ
• Android開発者：UI Automatorのレガシーは待機中です。
• Android開発者：WorkManagerの作業を管理する
• Android開発者：永続的な作業と制約
• Appium：セッション機能
• Taskerの議論：制限付きの待機試行