Guarded Choice(ガードチョイス)の内部挙動解説

フォローする

マニュアルの記載によると
Guarded choiceステップはその後のアクションと関連する幾つかの条件を判断するために利用されます。
設定されたいずれかの条件やガードが最初に満たされると、それに関連したアクションやステップが実行されます。これはボタンなどのエンターフェイス要素がマウス移動やクリック動作などを実行する前に表示されていることを保証するために主に使用されます。無制限に待ち状態が発生することを避けるために、タイムアウトガードが追加されます。
Kapowロボットが必要な要素を発見しデザインしたとおりに動作することを確実にするために、ロケーションとタイムアウトガードが使用可能です。

とのことですが、具体的な挙動と使い分けについてはいまいちイメージがつかめません。以下、具体的なGuarded Choice(ガードチョイス)のパターン別の挙動と実際のシーンでの使い分けについて解説します。

 

各 Guard の実行開始タイミングと判定タイミング

Guard_Choice-1024x609.png

Guarded Choice(ガードチョイス)が実行されると、各Guardは一斉に動作を始めますが、Location Not Foundについては実行直後の状態で成否を判定します。

また、Location Found と Tree Stops Changing については同様にFinderに指定したエレメントの有無を判断して成否を判断しますが、以下の2点について違いがあります。

  1. Finderの対象範囲
  2. 成否判定タイミング

まず、1.については Location Found が画面上のボタンやテキストなど Component レベルでの判断を実行するのに対し、Tree Stops Changing については特定画面のApplicationレベルでの判断となります。

次に2.については Location Found が対象エレメントの状態(有効/無効)は考慮せず単にエレメントの有無を判断するのに対し、Tree Stops Changing  は対象エレメントのバックグラウンド処理(ページの読込とエレメントツリーの展開完了)を待ってエレメントの有無を判断します。

つまり、操作対象のアプリケーションによっては(特にAjaxなどによりページ読込後にプルダウンの要素が生成されるようなWebシステム)Location Foundによる判定はまだページローディング時の初期化処理が完了する前に要素の有無を判定してしまい、ボタン等が有効化されていない時点でその後の操作(クリックなど)を実施してしまいうまく動作しないということが発生しえます。

このタイミングの問題は往々にしてロボット作成時には発見しにくく、実際にデバッグ実行するタイミングや本番環境にてRoboServerにより効率的な処理が行われた場合に初めて発見されたりする厄介な問題です。

最後にLocation Removed についてですが、これは一時的に表示されるプログレスバーやスプラッシュ画面の表示とクローズを判断するためのガードであり特定エレメントの表示からクローズまでを判断するものですが、v10.2時点ではプロセスレベルで状態を監視しており、対象ウィンドウが特定アプリケーションの子画面として表示されている場合、FinderはComponentレベルで設定可能なもののDAS自体は対象プロセスの有無まで監視しており、いつまでのTRUEにならない問題が発生します。代替案としてはProgram Managerタブに対し、当該ウィンドウを画像判定にてFinder設定することによりウィンドウの表示からクローズまでを監視できるようになります。

 

各 Guard の利用シーン

上記の特性から以下の使い分けをお勧めします。

Guard 画面の要素がダイナミックに変更される場合
(画面の遷移、画面の読み込み中など)
画面の要素が静的な場合
(画面の読み込み後のボタンやラベルなど)
When seconds have passed
Location Found
Location Not Found  
Tree Stops Changing  
Location Removed  
3人中3人がこの記事が役に立ったと言っています

コメント

0件のコメント

ログインしてコメントを残してください。