レポーター.ReportEvent UFT/QTP 例を挙げて
編集チーム
⚡ スマートサマリー
レポーター.ReportEvent UFT/QTP micPass、micFail、micDone、micWarning ステータス定数を使用して、カスタムの合格、不合格、警告、および情報メッセージを実行結果ビューアに直接送信し、テスターに自動化スクリプトが実際に行ったことを段階的に読みやすい記録として提供します。
Reporter.ReportEvent とは何ですか UFT/QTP?
Reporter.ReportEvent 標準メソッドとして組み込まれています UFT/QTP （現在は販売されています） OpenTextマイクロフォーカス UFT 1つ目は、テスト結果ウィンドウにカスタムの人間が読めるメッセージを直接書き込む機能です。組み込みのチェックポイントが生成する自動的な合格または不合格の判定とは異なり、ReportEvent 呼び出しを使用すると、テスターはログに記録する内容、タイミング、およびラベル付け方法を正確に決定できます。
この HP QTP チュートリアル 関数の使用方法を示します Reporter.ReportEvent (NAIST) と 結果のフォーマットチュートリアルでは短いスクリプトを作成するように指示されていますが、そのスクリプト作成演習を完了することが、カスタムレポートが結果ツリーをリアルタイムで更新する様子を確認する最も速い方法です。
詳しくはこちら こちら ビデオにアクセスできない場合
Reporter.ReportEvent は、スクリプトが通常、スケジュールに基づいて、または CI/CD パイプライン内で無人で実行されるため、自動化において最も重要です。実行結果ファイルは、何が起こったかの唯一の記録となるため、手順がサイレントに失敗したり、説明なしに成功したりすると、後でデバッグが非常に困難になります。重要なアクションの後に明示的な ReportEvent 呼び出しを追加することで、結果ツリーが読みやすいステップバイステップの監査証跡となり、テスター、開発者、または管理者はスクリプト自体を開かなくても確認できます。
これはオブジェクトチェックポイントとは異なり、 UFT は自動的に生成し、独自のデフォルトのステップ名を使用してレポートします。Reporter.ReportEvent を使用すると、「WebEdit オブジェクトでチェック ポイント パス」という一般的な表現ではなく、「注文確認が表示されました」などのビジネス上意味のある言語を添付できるため、技術的な知識のない関係者でも最終レポートをはるかに簡単に読み取ることができます。このメソッドは、スクリプトが Web ページ、 Windows Reporterは特定のテストオブジェクトのプロパティではなくグローバルオブジェクトであるため、デスクトップアプリケーションまたはメインフレーム端末で使用できます。
Guru99の UFT/QTP このシリーズでは、この方法をすぐ後に取り上げています if、else、およびexists文なぜなら、ほとんどの Reporter.ReportEvent 呼び出しは、結果を micPass または micFail として報告するかどうかを決定する条件ブロック内に位置するからです。
Reporter.ReportEvent構文とEventStatus値
あなたが使用することができます Reporter.ReportEvent Micro Focusでカスタムテストステップを報告する UFTテスト結果ツリー。このメソッドは、以下に示すように、3 つの必須引数と 1 つのオプション引数を固定の順序で受け取ります。
Reporter.ReportEvent EventStatus, ReportStepName, Details [, ImageFilePath]
イベントステータス ステップに表示されるアイコンと色を設定し、全体の実行ステータスを切り替えることができます。 レポートステップ名 テスト結果ツリーに表示される短いラベルで、通常は期待される結果として記述されます。 Details より長い説明、通常は実際に観察された結果を保持します。そしてオプション 画像ファイルパス スクリプト内で先に取得したスクリーンショットを、その特定の手順に添付します。
| VALUE | CONSTANT | 結果への影響 | 実行ステータスへの影響 |
|---|---|---|---|
| 0 | micPass | 結果ツリーでは、ステップは「合格」と表示されます。 | 変更なし。テストは合格として継続されます。 |
| 1 | マイクの失敗 | 結果ツリーでは、このステップは失敗と表示されます。 | 全体的な実行ステータスが失敗に変更されました |
| 2 | マイク完了 | ステップは情報メッセージとして表示されます | 合否判定に変更なし |
| 3 | マイク警告 | ステップは警告として表示されます | 合否判定に変更なし |
各定数は、名前の代わりに数値として渡すこともできます。 Reporter.ReportEvent 1、「ステップ」、「詳細」 まさに Reporter.ReportEvent micFail、「ステップ」、「詳細」名前付き定数を使用すると、後で別のテスターが保守するスクリプトでも読みやすくなります。
スクリプトでは、通常、1つのアクション内に複数のReportEvent呼び出しをネストします。アクション開始前のmicDoneエントリ、キーチェックのためのmicPassまたはmicFailエントリ、そして途中で異常が検出された場合の追加micWarningエントリなどです。
- 自動化ツールを使用してテストケースを実行すると、一部のユーザーにとって生のテスト結果を理解するのが難しい場合があります。 results.xml は、テスト結果を好みの方法で表示する XSL ファイルを作成します。.
- 使用することもできます VBScript ライブラリ関数 結果をxlsファイルまたはテキストファイルに保存する 外部の報道について UFT.
Reporter.ReportEvent の使い方：実践例
構文を知っていることと、実際のスクリプトの中でそれを見ることは全く別物です。4つのステータス定数の意味を理解するには、構文を理解することが重要です。以下の例では、チェックをIf…Then…Elseステートメントで囲み、Reporter.ReportEventを使用して合格または不合格を報告することで、レビュー担当者が期待する結果が結果ツリーの適切な場所に表示されます。
If Browser("Guru99 Demo").Page("Guru99 Demo").WebButton("Login").Exist(5) Then Reporter.ReportEvent micPass, "Login button check", "Login button was found on the page" Else Reporter.ReportEvent micFail, "Login button check", "Login button was not found on the page" End If
これは、以下に示すパターンを反映しています。 Guru99の VBScriptの条件文 このチュートリアルでは、If…Then…Else ブロックが 2 つの結果から選択するようになっています。唯一の違いは、各分岐で Reporter.ReportEvent を呼び出して結果をログに記録することです。
マイク完了 純粋に情報提供を目的としたステップ、そして マイク警告 何か異常なことが起こったように見えるが、実行が即座に失敗すべきではない場合。次のコードスニペットは、データ入力ステップを「完了」としてログに記録し、応答の遅さを「警告」としてフラグ付けし、オプションの ImageFilePath 引数を使用してスクリーンショットを添付します。
Reporter.ReportEvent micDone, "Enter search text", "Typed 'UFT tutorial' into the search box" errorImage = "C:\Results\SearchDelay.png" Browser("Guru99 Demo").CaptureBitmap errorImage, True Reporter.ReportEvent micWarning, "Search response time", "Results took longer than 5 seconds to load", errorImage
キープ レポートステップ名 短く保ち、 Details 実際の結果を明確に示しましょう。夜間実行が失敗した後に数百ものログステップをスキャンするレビュー担当者は、スクリプト自体を開かなくても何が起こったのかを把握できるはずです。すべてのアクションで一貫した命名パターンを使用することで、スキャンがはるかに速くなります。
複数のスクリプトから ReportEvent を呼び出すチームは、このロジックを LogStep(status, name, details) のような共有 VBScript 関数に移動させることがよくあります。これにより、すべてのスクリプトが同じ If…Then ブロックを繰り返すことなく、一貫した結果ツリーを生成できます。
レポーターオブジェクトのプロパティ：フィルター、レポートパス、および実行ステータス
Reporter.ReportEvent は Reporter オブジェクトのメンバーの唯一のものではありません。さらに 3 つのプロパティにより、結果の内容と場所をより詳細に制御できます。 UFT それらは保存され、生産自動化フレームワークで頻繁に登場します。
| PROPERTY | 目的 | 一般的な使用例 |
|---|---|---|
| フィルター | 結果に書き込まれるイベントの種類を制御します | Reporter.Filter = rfEnableErrorsAndWarnings は、長時間実行時に通過したステップを非表示にします |
| レポートパス | 読み取り専用。現在の実行結果が保存されているフォルダを返します。 | 結果フォルダ = レポーター.レポートパス |
| 実行ステータス | 読み取り専用。これまでの実行の合否ステータスを返します。 | Reporter.RunStatus = micFail の場合、アクションを終了します。 |
Reporter.Filter は 4 つの値を受け入れます。0 または rfEnableAll はすべてのイベントを表示し、これがデフォルトです。1 または rfEnableErrorsAndWarnings は通過したステップを非表示にします。2 または rfEnableErrorsOnly は通過したステップと警告の両方を非表示にします。3 または rfDisableAll は結果のログ記録を完全に無効にします。スクリプトの途中で Reporter.RunStatus を確認すると、テストは独自のロジックを分岐させることができます。たとえば、スキップできます。ping 前のステップが既に失敗した場合に、アクションの残りのステップを実行する。
ReportPathとRunStatusは読み取り専用であるため、値を割り当てることはできません。これらは、現在の実行に関する情報を読み取るために使用します。たとえば、スクリプトの開始時に結果フォルダーのパスをログファイルに書き込んだり、致命的なエラーが発生した後に長時間の処理を中断したりする場合などです。これらのプロパティを読み取る際のオーバーヘッドはごくわずかであるため、長時間の回帰テストスイートの主要なステップごとにReporter.RunStatusをチェックしても、実行速度が著しく低下することはありません。
Reporter.ReportEvent のベストプラクティス UFT
いくつかの習慣を身につけることで、カスタムレポートは煩雑なものではなく、役立つものとなる。
- micFailは、真の故障のために予約しておいてください。 micFail を呼び出すたびに Reporter.RunStatus が反転するため、見た目の問題にこれを使用すると、同じ実行の後半で発生する本当の欠陥が隠蔽されてしまいます。
- ReportStepNameを期待される結果のように記述してください。 レビュー担当者は、詳細欄を読まなくても、ステップ名だけでチェック内容を理解できるべきである。
- 失敗した場合のみスクリーンショットをキャプチャする： 全てのステップでImageFilePathを渡すと、結果フォルダがすぐにいっぱいになり、実行速度が低下するだけで、ほとんどメリットがありません。
- ノイズの多い実行をフィルタリングする： スケジュール実行または CI 実行の場合、Reporter.Filter を rfEnableErrorsAndWarnings に設定して、通過したステップによって重要な失敗が埋もれてしまわないようにします。
- ロジックを一元化する： Reporter.ReportEvent 呼び出しを再利用可能な内部でラップします アクション または関数ライブラリを使用して、スイート内のすべてのスクリプトが同じ方法で結果をログに記録するようにします。
- 非技術系の読者向けにエクスポート： 結果を確認する必要がある場合は、QA チーム以外の関係者が結果ファイルを開かずに確認できるように、results.xml とカスタム XSL を組み合わせてください。 UFT.
