check picture
名前 | 説明 | タイプ | 修飾子 |
---|---|---|---|
window | (任意)ウィンドウのTA名です。 | Interface Entity | なし |
control | (任意)コントロールのTA名です。 | Interface Element | なし |
name | 正規また共有された画像チェックを職別はAUT表示と比較するために、使用される一つ以上のベーライン画像のコレクションです。 | String | なし |
question | (任意)テスト対象の内容を視覚的に確認できるために、必要な場合に使用するテスター向けの質問です。 | String | なし |
left | (任意)アクティブなUI要素(ウィンドウおよびコントロール引数の値の有無に応じてウィンドウ、コントロール、または画面全体)の左端に応じて、長方形エリア(rect エリアと呼ばれる)の左側境界を指定します。rect エリアはアクティブエリア( になります)を決定します。ベースライン画像との一致のスキャンは、このエリアに制限されます。 デフォルト値: 0 | String | なし |
top | (任意)アクティブなUI要素の上端に応じて、rect エリアの上部境界を指定します。 デフォルト値: 0 | String | なし |
width | (任意)rect エリアの幅を指定します デフォルト値: アクティブなUI要素の幅 | String | なし |
height | (任意)rect エリアの高さを指定します デフォルト値: アクティブなUI要素の高さ | String | なし |
setting value
setting verify picture yes
 
program
start program C:\Program Files\LogiGear\TestArchitect\samples\CarRental\CarRental.exe
 
window control click type
click ログイン ログイン left
click ようこそ 新しい注文 left
 
window control value
set 日付と場所を選択 同じ場所に戻る off
 
window control click type
click 日付と場所を選択 次へ left
 
window tree node path click type
click tree node 車の選択 車の選択ツリー Car Types/Standard/Chevrolet Monte Carlo left
 
window control name question left top width height
check picture 車の選択 メッセージ chevrolet それは黄色いシボレーですか。 0 0 # control_width # control_height
この例では、プログラムのカタログから車を選択した時に、車のレンタルアプリケーションに正しい車の画像が表示されているかどうかを確認するためのテストを実行します。以下のアクションラインは、アプリケーションを起動し、View Cars ウィンドウに移動し、ツリービューから Chevrolet Monte Carlo のノードを選択します。以下のように表示されます:
最後のアクションラインのステップは正しい画像が表示されているかを検証します
アクションライン check picture から位置引数 left, top, width, height を省略します。つまり、画像チェックのアクティブエリアが 車画像 のコントロール全体に対応していることを意味しています。
画像を検証する
テストでアクションライン check picture は、既に存在する名前が chevrolet の画像チェックがあると仮定しています。この場合は、少なくともまだ存在していません。しかし、前述のように、check picture の実行時に存在していない画像チェックに遭うと、抑制された警告及び未検証の画像チェックの作成が結果として発生します。そして、ビルトイン設定の確認された画像が yes に設定されているため、未検証の画像チェックはテストの完了時に 画像チェック-新規画像 ダイアログボックスが表示されるようになります。
表示された質問に基づいて、“それは黄色いシボレーですか。"、テスターは直のいずれかの操作を行います:
- 現在タップに正しい画像が表示されていない場合は、Fail をクリックします。
- 画像が正しい場合は、Pass をクリックします。
確かに画像が正しいので、テスターが Pass をクリックすることが期待されます。これにより、以下の効果があります:
- 新しくキャプチャされた画像は将来のテスト実行で使用できるように、シボレー画像チェックにベースラインの参照として保存されます。この画像は、画像チェック-新規画像 ダイアログボックスのベースラインタブで表示されるようになります。
- 画像エクスポローラツリーのノードのアイコン(ダイアログボックスの左上)は、合格した画像チェック
を示す緑のチェックマークに変更されます。
最後に、登録 をクリックすると、画像の検証が完了します。
- このダイアログボックで、選択されたオプション(Pass また Fail)は一時的なメモリだけに保存され、登録 ボタンをクリックするまでリポジトリには保存されません。
- 閉じる ボタンは変更を破棄し(ある場合)、ダイアログボックスを閉じます。
- 複数のベースライン:
画像チャックは単一のベースライン画像に制限されません。代わりに、一つの画像チャックには複数のベースラインを保存できます。これはAUTによって、提供される単一のビットマップが、特定の画像チャックに対して、許容可能と考えられる場合に重要です。(画像チャック に複数のベースラインがある一般的な理由の1つは特定の画像ファイルが異なるハードウェア上でわずかに異なる方法でレンダリングされる可能性がありません)。特定の画像チェックに複数のベースラインが存在する場合、TestArchitect による合格の基準は保存されているベースラインのいずれかがテスト画像と一致することです。
後続 check picture の実行 ・ 一致と一致しない場合
ベースライン画像、(或いは、最終的には複数のベースライン画像)を シボレー画像チェック に保存した後、テスト実行を続けることができます。ライン30の check picture の後続実行ではAUTの画像をキャプチャし、それを画像チェックのベースラインと比較します。自動化が一致を見つける場合、結果は Passed になり、手動の検証は必要ありません。
一方、新しいキャプチャされたテスト画像がベースラインと一致しない場合、テストが完了すると新しいダイアログボックス、画像チェックー変更画像 が表示されます:
このダイアログボックスでは、テスト画像を再度確認できます。また、テスト画像をテストの質問と比較するか、既存のベースライン画像(または複数のベースライン画像)と比較するオプションがあり、ベースライン のサプタブをクリックして、確認できます。現在のオプションは以下の通りです:
- Fail このチェックを Fail として報告します。(つまり、テスト中の画像は、このアクション check picture の実行時にAUTが表示するべきではない画像であるか、表示すべきではない画像です)
- Pass, これが新規ベースラインです。: これが新しいベースラインです。このアクションを Passed として、報告し、全ての存在のベース来院画像を削除し、テスト画像をベースラインとして保存します。警告:現在の画像チェックに複数のベースライン画像がある場合、このオプションは全てを削除します。
- Pass, ベースラインを変更しません。: このチェックを Passed として報告しますが、元の存在のベースラインを保持します。テスト画像は破棄されます。
- Pass, ベースラインバリエーションとして保存します。: このチェックを Passed として報告し、テスト画像を追加のベースラインとして保存します。
決断を保存するには 保存 ボタンをクリックします。
最後に、画像確認プロセスを完了するために 登録 ボタンをクリックしてください。
自動モード
画像チェックを含むテスト実行は自動モードまたは半自動モードノイズ化で実行できることが言及されます。これまで、手動の介入がかく実行の最後で必要な半自動のテスト実行を見てきました。製造テスト環境では、テストを頻繁に、しばしば連続して実行する必要があり、人間の入力を持つことなく実行することがよくあります。
製造テスト環境では、連続したテストをバッチ制御の下で実行する必要があり、人間の入力を待たずに実行することがよくあります。ただし、バッチファイル制御の下では、シリアルバッチ実行内の各テストモジュールは、個別のテスト実行セッションとして呼び出されます。その結果、半自動モードの場合、未検証の画像チェックを持つ単一のテストモジュールは、そのテストモジュールが実行を完了したときに人間の介入が必要となります。これは、それがシリアルテスト実行の一部であるかどうかに関係なく発生します。この中断を避けるために、このようなバッチ実行が自動モードで実行されることを確認し、手動のピクチャーチェック検証が行われるかどうかを判断できるようにします。
画像チェック ダイアログボックスをアクセスします
画像を新しいベースラインとして指定する手段として、画像チェック ダイアログボックスがどのように機能するかを見てきました。また、画像チェック ダイアログボックスが半自動テスト実行の終了時に自動的に表示され、自動化されたテスト実行の後には表示されないことも見てきました。
ここで明らかな疑問は、「自動実行中に新しい画像(ベースライン候補)が出てきた場合、その後でシステムにその画像をベースラインとして受け入れるよう指示する方法はあるのか?」ということです。答えは「はい」です。
- 半自動実行と同様に、テスト実行が完了した後に、画像チェック ダイアログボックスにアクセスすることでこれが実現されます。
- 自動実行の場合と同様に、次のようになります:
- 画像チェックを含むテストの各結果レポートについて、TestArchitect はテスト実行中に行われた全ての未検証の画像チェックから取得した画像を含むレコードを保持します。未検証の画像ェックがあるテスト結果のアイコンには、U が重ねて表示されます。未検証の画像チェックを解決すると、テスト結果からその指定が解除されます。ヒント:未検証の画像チェックを解決するには、このトピック を参照してください。
- 未検証の画像チェックとは、以下の条件を満たすものです:
- check picture の実行時に一致が見つからなかった(名前付き画像チェックが存在しないか、一致しない画像があるため)
- 関連する 画像チェック ダイアログボックスを介して、まだ人間がチェックをレビューし解決していない(Pass または Fail オプションを選択することにより)。
- 画像チェックを含むテストの各結果レポートについて、TestArchitect はテスト実行中に行われた全ての未検証の画像チェックから取得した画像を含むレコードを保持します。未検証の画像ェックがあるテスト結果のアイコンには、U が重ねて表示されます。未検証の画像チェックを解決すると、テスト結果からその指定が解除されます。
- iOSデバイスに適用されるビルトインUIアクションはピクセルではなく、画面座標をポイント単位で指定します。(詳細については、ビルトインアクション get screen resolution を参照してください)
- このビルトインクションは常に pixel-by-pixel image comparison 技術を適用します。キーポイント検出は、check picture を使用できません。
- check picture は保存されたベースライン画像とAUTディスプレイの指定されたアクティブエリアとの間で正確な一致を探します。アクティブエリア内でベースライン画像の存在を検索するには、アクション check picture exists を使用してください。
- 参照された画像チェックが複数のベースライン画像に保持される場合、各画像はAUTのビットマップに対して、一致するものが見つかるまで続けられます。一致を見つけるためには、単一の “hit”だけが必要です。
- 編集時に便宜のために、このアクションの引数 name に 画像チェック フォルダ(TestArchitectエクスポローラツリー内)から適切な画像チェックノードをドラッグすることができます。
- check picture 実行の規範的な結果は以下のいずれかです:
チェック結果 条件 説明 合格しました 画像が一致する 参照画像チェックは表示されたテスト画像と一致するベースライン画像を保存します。 未検証の画像チェックで失敗しました 画像が一致しない 参照画像チェックは表示されたテスト画像と一致するベースライン画像を保存していません。 未検証の画像チェックで警告しています 欠落した画像 画像チェックすの引数 name は存在しない画像を指定します。
Failed 及び Warning の結果は一時的であり、各未検証の画像チェックと関連付けられています。テスト実行の完了時に、各未検証の画像チェックは手動でアクセスして、最終的なチェック結果を変更する方法で解決できます。(または、未検証の画像チェックについてはこれ以上のアクションは必要ありません) - 未検証の画像チェックの結果はテスト実行完了時に、2種類の 画像チェック ダイアログボックスを使用して、解決できます:
- 未検証の画像チェックの Fail 結果は ダイアログボックスを通して、解決できます。このダイアログボックスはキャプチャしたテスト画像を関連付けた画像チェックに、新しいベースライン画像として、通過する可能性を提供します。
- 未検証の画像チェック関連する Warning 結果は ダイアログボックスダイアログボックスを通して、解決できます。このダイアログボックスはキャプチャしたテスト画像をベースライン画像として持つ新しい画像チェック(その名前は、引数 name から取得されます)を追加できます。
- 写真チェックとベースライン写真を追加するための提案された方法は Picture Capturing Tool を使用して「オフライン」で実行することがお勧めされています。テスト中の未検証の画像チェックに対する結果としてベースライン画像を追加することは、テスト中に予期しないチェック画像の失敗が発生した場合に意図されています。
- テストが完了した際に、画像チェック ダイアログボックスが表示される方法は、ビルトイン設定である verify picture によって決定されます。verify picture が yes に設定されている場合は、テスト中に発生した未検証の画像チェックはテストセッションが完了した後、自動的に一連の 画像チェック ダイアログボックスを表示します。verify pictureを no に設定した「Non-verify mode」はバッチファイル制御のもとで、無人の serial test runs 推奨されています。これにより、手動操作が必要となる可能性によって、一部のテストが後続のテストの実行を妨げる可能性がなくなります。
- 未検証の画像チェックは2つのいずれかが発生するまで未検証のままです: そのステータスは 画像チェック ダイアログボックス(上記で説明した)を通して、解決されるまたは、関連するローカルの 結果 項目がリポジトリに移動されます。結果 項目がリポジトリに移動されると、未検証の画像チェックに関連する一時的の Failed 及び Warning の結果はロックされ、それぞれ Failed 及び Warning として確定し、未検証の画像チェックは破棄されます。
- このアクションはキャプチャされたビットマップの中でアクティブエリアとして職別された部分に適用され、画像の残り部分は無視されます。アクティブエリアは、rect エリアを定義する4つの引数(left, top, width, height)によって、決定されます。最初に、ウィンドとコントロールはクティブUI要素を決定して、コントロールまた全体の画面を操作できます。以下のように表示されます。
引数 window 引数 control アクティブなUI要素 省略 省略 画面全体(全体のキャプチャされたテスト画像) 指定 省略 アプリケーションウィンドウ全体 指定 指定 指定されたコントロール
アクティブなUI要素が確率された場合、任意の rect エリアが定義されている場合はアクティブなUI要素の左上隅に対応する長方形エリアを指定します。(4つの引数 rect のいずれも指定されていない場合、アクティブエリアはアクティブなUI要素です)
上記の図では、引数 window, control が両方指定され、画像コントロール(12台の車が表示されている)をアクティブなUI要素として確立された場合に適用されるアクティブエリアを示しています。左、上、幅及び高さで指定された rect エリア自体がアクティブエリアです。警告:画像チェック ビルトインアクションのアクティブエリアを決定するルールは Picture Handling の他のビルトインアクション、例えば、check picture exists, click picture などとは異なります。 - 全ての場合において、rect エリア自体が指定されている場合は、アクティブエリアです。以下の三つの画像は、rect エリアの4つの値(左、上、幅、高さ)が指定された場合、アクティブエリアがどのように決定されるかを示しています。
アクティブエリアを決定する一般的なルールは以下のように表示されます:rect エリア: 結果のアクティブエリア: 指定されていない場合 アクティブなUI要素 アクティブなUI要素と重なる場合 rect エリア アクティブなUI要素と重ならない場合 rect エリア - このアクションは <ignore> 修飾子をサポートしています。文字列
<ignore>
が引数の値として存在する場合、 または引数に<ignore>
と評価する式を含まれている場合、アクションは実行中にスキップされます。