カスタム UI テストステップ
HTML および JavaScript ページコンポーネントを取得し、それらがサポートするテストアクションを特定することによって、UI ページや UI マクロなどのカスタマイズされたユーザーインターフェイスをテストします。
カスタム UI テストステップでは、自動テストフレームワーク (ATF) はターゲット Web ページからテスト可能なコンポーネントを取得して識別する必要があります。
テスト可能なコンポーネント
テスト可能なページコンポーネントは、これらの特性を備えた標準の HTML と JavaScript で構成されています。
- ユーザーの操作によって設定またはクリックされる
- テスト可能なページコンポーネントを使用すると、ユーザーは値を設定したりクリックしたりできます。
- DOM (Document Object Model) からアクセス可能
- テスト可能なページコンポーネントは DOM からアクセスでき、DOM の JavaScript 操作をサポートします。カスタム UI テストステップは、シャドウ DOM 内のページコンポーネントにアクセスできません。
- JavaScript にアクセスできる
- テスト可能ページコンポーネントは JavaScript でアクセスできます。カスタム UI テストステップは、ファイルフィールドなどのオペレーティングシステムと直接やり取りするページコンポーネントにアクセスしたり、Excel ファイルや PDF ファイルなどの非 HTML コンテンツを表示したりすることはできません。
- カスタム UI テストから除外されない
- テスト可能なページコンポーネントは、カスタム UI テストから除外されません。自動テストフレームワーク (ATF) は、他のテストステップカテゴリで既にテスト可能なページコンポーネントを除外し、ServiceNow AI Platform 機能に関連づけられたページコンポーネントも除外します。
- ページインスペクターにアクセス可能
- テスト可能なページコンポーネントは、ページインスペクター から表示したときに結果を返さなければなりません。テスト設計者は、ページのテスト可能なコンポーネントを識別するためにページインスペクターを使用できます。
- ボタン
- リンク
- ページテキスト
- UI コントロール
- UI マクロ
- ui_date
- ui_date_time
- ui_reference
- UI ページ
- ウィザード
テスト不可能なページコンポーネントの例としては、これらの UI 要素があります。
| テスト不可能な理由 | テスト不可能なページコンポーネント |
|---|---|
| 設定またはクリックできない | 非表示のコントロール |
| HTML コメント | |
| div、section、span などの HTML レイアウト要素 | |
| HTML スクリプト要素 | |
| DOM からアクセスできない | ダッシュボード |
| イメージ | |
| リスト | |
| レポート | |
| シャドウ DOM | |
| JavaScript でアクセスできる | Excel ファイル |
| ファイルフィールド | |
| PDF ファイル | |
| ServiceNow AI Platform の機能である | フローデザイナー |
| Studio | |
| アップグレードモニター | |
| 他のテストステップカテゴリでテスト可能 | フォームフィールドラベル |
| フォームフィールド値 | |
| サービスカタログ | |
| ワークスペース |
設定可能なページコンポーネント
設定可能コンポーネントは、テキスト入力フィールドなどの動的な値を持つ UI 要素です。設定可能コンポーネントは、これらのテストアクションとテストステップをサポートします。
| ページインスペクターのアクション | カスタム UI テストステップ |
|---|---|
| コンポーネント値を設定 | コンポーネント値 (カスタムUI) の設定 |
| コンポーネント値を取得 | ページ (カスタムUI) のテキストをアサートする |
| コンポーネント値の検証 (カスタム UI) | |
| コンポーネントが無効 | コンポーネントステータスの検証 (カスタム UI) |
設定可能コンポーネントには、カスタム UI テストステップで設定できる値を決定する データタイプ があります。たとえば、特定のレコードへの参照を表示するためのページコンポーネントは、システム ID 値のみを表示するための参照データタイプを持つことができます。
- 日付
- 日時
- 参照
詳細については、「コンポーネントデータタイプを上書きする」を参照してください。
クリック可能なページコンポーネント
クリック可能なコンポーネントとは、チェックボックスやラジオの入力など、ユーザーがクリックすることで操作できる UI 要素のことです。クリック可能なコンポーネントはこれらのテストアクションをサポートします。
| ページインスペクターのアクション | カスタム UI テストステップ |
|---|---|
| コンポーネントをクリック | [コンポーネント (カスタム UI)] をクリックします |
| コンポーネント値を取得 | ページ (カスタムUI) のテキストをアサートする |
| コンポーネント値の検証 (カスタム UI) | |
| コンポーネントが無効 | コンポーネント ステータスの検証 (カスタム UI) |
クリック可能なコンポーネントは動的な値を持たないのでデータ型を持ちません。
取得されたページコンポーネント
自動テストフレームワーク (ATF) は、テストするカスタム UI ページごとに取得したページコンポーネントのリストを格納します。カスタム UI テストステップは、[コンポーネント] と [コンポーネント値 (Component values)] フィールドから取得したコンポーネントのリストを表示します。
デフォルトでは、ページコンポーネントのリストは静的であり、テスト設計者が手動で [コンポーネントの取得] をクリックしたときにのみ更新されます。アドミニストレーターは、システムプロパティ sn_atf.page_data_capture.enabled を有効にして、カスタム UI テストステップが実行されるたびにページコンポーネントのリストを更新できます。テスト設計時にこのプロパティを有効にすると、テスト設計者は常に最新のページコンポーネントリストにアクセスできるようになります。テスト設計が完了した後にこのプロパティを無効にすると、テストステップは以前に取得したページコンポーネントのリストを使用できるため、テストの実行速度が向上します。
ServiceNow AI Platform は、取得したページコンポーネントのリストをデータとして扱い、それらを更新セットまたはアプリケーションファイルに含めません。あるインスタンスから別のインスタンスにテストを転送するとき、テスト設計者は手動でページコンポーネントを再度取得する必要があります。
設計上の考慮事項
カスタム UI ページとページコンポーネントをテストするときは、これらの設計上の考慮事項に従ってください。
- ページインスペクターを使用してテスト可能なページコンポーネントを識別する
- ページインスペクターは、どのページコンポーネントがカスタム UI テストに使用できるかを決定します。ページインスペクターに利用できないページコンポーネントは、カスタム UI テストには利用できません。
- テストするカスタム UI に移動する
- ターゲットのカスタム UI に移動するには、既存のテストステップを使用します。たとえば、ナレッジベース記事をテストするには、既存のテストステップを使用してモジュールに移動するか、既存のレコードを開きます。ほとんどのカスタム UI テストでは、テストの一部として既存のテストステップカテゴリを使用する必要があります。
- コンポーネント領域を使用してページコンポーネントを識別します
- コンポーネント領域は、
<div>または<section>要素などのコンポーネントを含む HTML レイアウト要素を表します。この領域は、テストデザイナーがページレイアウト内の場所を指定することによってコンポーネントを区別するのに役立ちます。 - ServiceNow AI Platform UI ではなくカスタム UI をテストする
- 自動テストフレームワーク (ATF) は、ServiceNow AI Platform 機能のカスタム UI テストを回避します。たとえば、ダッシュボードやグラフィカルデザイナーをテストすることはできません。代わりに、カスタム UI ページと要素を検証するためのテストをビルドします。これらのユーザーインターフェイスは直接制御できるからです。
- HTML 属性を使用してページコンポーネントのテストプロパティを上書きする
- 自動テストフレームワーク (ATF)に固有の HTML 属性を使用して、特定のページコンポーネントのテストプロパティを変更します。「コンポーネントテストアクションを上書きする」を参照してください。
- テストを別のインスタンスに移動するときはページコンポーネントを再度取得する
- カスタム UI テストステップは、UI コンポーネントをメタデータとして格納しません。テスト担当者がインスタンス間でテストを移動するときは、ページコンポーネントを手動で再度取得する必要があります。
カスタム UI テストの例
取得したコンポーネントのリストを使用して、カスタム UI テストステップを設計できます。たとえば、ナレッジベース記事のレビューとコメントをテストしたいとします。ナレッジベース記事には、カスタム UI 手順がテストする必要があるページコンポーネントがいくつか含まれています。
- 記事の閲覧数。
- 記事を役に立ったとしてマークするボタン。
- コメントを残すテキスト領域。
- モジュールに移動。「ナレッジ」アプリケーションの「発行済み」モジュールに移動します。
- 既存のレコードを開く。ID が「Knowledge：KB0011110」の「ナレッジ」フォームを開きます。
- UI アクションをクリックします。「ナレッジ」フォームの UI アクション「記事の表示」をクリックします。
- ページ (カスタム UI) のテキストをアサートする。「開発者」というテキストがページにあることをアサートします。
- コンポーネント値を設定（カスタムUI）。次のようにページ上のコンポーネントを設定します。 'Textarea <textarea>[article_comments]‘ = 他の場所の記事への URL ではなく実際の記事で更新する。
- コンポーネント (カスタム UI) をクリック。「ボタン <button>：コメント」コンポーネントをクリックします。
- ページ (カスタム UI) のテキストをアサートする。「他の場所の記事への URL ではなく実際の記事で更新する。」というテキストがページ上にあることをアサートします。
カスタム UI コンポーネントのバージョンと順序
カスタム UI テストステップのいずれかでコンポーネントを選択すると、カスタム UI バージョンが表示される場合があります。複数の重複するコンポーネントがある場合は、コンポーネントの順序が表示されます。
- カスタム UI バージョンは、カスタム UI バージョンが異なるコンポーネントが少なくとも 2 つある場合にのみ表示されます。
- 順序は、コンポーネントのドロップダウンメニューに重複するコンポーネントがある場合にのみ表示されます。表示された順序に従って、それらを明確にすることができます。
- 異なる複数の重複コンポーネントがある場合は、[カスタム UI バージョン] と [順序] の両方が表示されます。
コンポーネントの識別
<button sn-atf-id="consistentValue">Test</button>ATF コンポーネントの識別の改善
[ページ領域] 列に含まれるラベルパスを使用して、コンポーネントを識別します。Rome リリース以降、 sn_atf.element.use_label_path プロパティはデフォルトで true に設定されています。
コンポーネントに sn-atf-area 属性がある場合、[ページ領域] 列には sn-atf-area 値が表示されます。 sn-atf-area 属性が存在しない場合、そのコンポーネントのラベルパスが [ページ領域] 列に表示されます。
sn-atf-area 属性またはラベルパスがない場合は、デフォルトとして表示されます。リストから必要なコンポーネントを選択して [送信] をクリックすると、テストステップの説明も詳細な情報で更新されます。