このページを共有
関連：GUI テストおよびコンポーネント
回復シナリオの適用対象は，予測できないイベントや，テストまたはコンポーネントの特定のステップと同期できないイベントに限定されます。
標準では，回復シナリオ操作が開始されるのは，ステップによってエラーが返された後にかぎられます。これは，最初にエラーを引き起こしたステップの数ステップ後に発生する可能性があります。別の方法としては，ステップごとにトリガ・イベントを確認することも考えられますが，パフォーマンスが低下する可能性があります。したがって，予測可能なエラーについては，テストまたはコンポーネントで直接処理することをお勧めします。
テストまたはコンポーネントの特定のポイントで発生することが予測できるイベントについては，回復シナリオを使用するのではなく，テストまたはコンポーネントから直接イベントを処理することをお勧めします。テストでこれを行うには，If ステートメントまたはオプション・ステップなどのステップを追加します。コンポーネントでこれを行うには，条件ステップを使ったユーザ定義関数を使用します。
テストまたはコンポーネントから直接イベントを処理する方法では，回復シナリオよりもより明確にエラー処理を行うことができます。これは回復シナリオが一般的な予測しないイベントのセットを処理するよう設計されているためです。またテストから直接イベントを処理すれば，調整処理のタイミングを制御でき，最小の労力で最大の効果を挙げることができます。
Example:
-
実行セッション中に［保存］ボタンをクリックすると［ファイルを上書きしますか］メッセージ・ボックスが開くことがわかっている場合は，
メッセージ・ボックスが開いたら［OK］をクリックする If ステートメントを使用するか，メッセージ・ボックスで［OK］をクリックするオプション・ステップをテストに追加します。（キーワード・コンポーネントの場合は，ユーザ定義関数でこの If ステートメントを定義し，関連付けられているアプリケーション領域で使用できるようにします）。
-
プリンタ・エラーを処理する回復シナリオを定義できます。これにより，実行セッション中にプリンタ・エラーが発生した場合，回復シナリオが OpenText Functional Testing に対して［プリンタ エラー］メッセージ・ボックスの標準のボタンをクリックするよう指示できます。
この例で回復シナリオを使用するのは，テストまたはコンポーネントでは，このようなエラーを直接処理できないからです。なぜなら，どの時点でネットワークによってプリンタ・エラーが返されるか知ることができないためです。ユーザ定義関数またはテスト内で，プリンタにファイルを送信するステップの直後に If ステートメントを追加したとしても，ネットワークが実際にプリンタ・エラーを報告するまでの間にテストまたはコンポーネントは数ステップ進んでしまうことがあります。
その他の参照項目：
