バージョン:Rome
Automated Test Framework

Automated Test Framework の使用

記事 (1/40)

Automated Test Framework の目的

このモジュールでは、Automated Test Framework (ATF) を使用して次のことを行う方法を学習します。

  • テストを作成して実行する
  • テストおよびテストスイートの実行を有効にする
  • テストステップを追加して設定する
  • テストを実行する
  • テスト結果を表示および解釈する
  • テストの実行にクライアントテストランナーが必要かどうかを判断する
  • テストステップからの出力変数を別のテストステップの入力変数として使用する
  • テスト開発の効率を高めるためのテストテンプレートを作成して使用する
  • テストスイートを作成する
  • テストスイートを実行する
  • テストスイート結果を表示および解釈する
  • テストスイートを実行するためのスケジュールを作成する
  • スケジュール済みスイートのウォッチリストにユーザーを追加する
  • クライアント側のテストステップを含むスイートのスケジュール済みスイート実行用のブラウザーや OS を選択する
  • スケジュール済みテストスイートに関するメールレポートを表示および解釈する

記事 (2/40)

この学習モジュールについて

重要:この学習モジュールの内容は、Rome ServiceNow リリース用に最後に更新されました。

この学習モジュールのコンセプトページでは、さまざまな例が使用されています。例を再作成する必要はありません。演習では、NeedIt アプリケーションを開発します。演習は、次の 3 つの方法で示されます。

  • ナビゲーションペインの [演習] アイコン。
  • ページ上部の [演習] アイコンと「演習」という単語。
  • ページタイトルの「演習」または「課題」という単語。

ナビゲーションとページタイトルに、強調表示された演習ページのアイコンと演習プリフィックスが表示された、演習ページの上部。

NeedIt アプリケーションを使用すると、ユーザーは複数の部門からのサービスを要求できます。ソースコントロールを使用して、この学習モジュールに必要なすべての NeedIt アプリケーションファイルから始めます。

記事 (3/40)

Automated Test Framework とは

Automated Test Framework (ATF) は、アプリケーション、カスタマイズ、および設定のテストを自動化するために使用される ServiceNow アプリケーションです。

  • テスト主導型開発:新しいアプリケーションの開発中のテスト
  • 回帰テスト:ビジネスロジックテスト
  • 定期検査:ServiceNow の定期点検の一環
  • その他のテスト:テストが必要なその他のユースケース

ATF を使用して以下をテストします。

  • サービスポータルのサービスカタログ
  • Forms
  • Application Navigator
  • Service Catalog
  • カスタム UI
  • リストと関連リスト
  • サービスポータルのフォーム
  • REST
  • サーバー
  • メール
  • レポート
  • レスポンシブダッシュボード

たとえば、アップグレード前に、Beth Anglin は、NeedIt テーブルにレコードを作成できます。アップグレード後、ATF を使用して、Beth が引き続き NeedIt テーブルレコードを作成できるかどうかを確認します。

アップグレードによって、Beth は NeedIt レコードを作成できなくなりましたか?

記事 (4/40)

テスト

ATF テストは、ServiceNow における自動化され、順序付けられた一連のステップです。ステップでは、実行するアクションと実行順序を定義します。ATF はステップを実行し、各ステップのステータスおよびテスト全体のステータスを報告します。

ATF には、さまざまなアクションのテストの例が用意されています。サンプルテストのリストを表示するには、Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。

「既存のレコードを開く」テスト

既存のレコードを開く」テストは、レコードを開いていくつかの値をアサートするテストの例です。「既存のレコードを開く」テストのステップは、次のとおりです。

  1. ATF ユーザーの代理操作を行う
  2. ATF ユーザーフォームを開く
  3. フォームの値を検証する

ATF は、クライアント側ステップのスクリーンショットを撮ります。開発者は、テスト結果を調べるときにスクリーンショットを表示できます。

ユーザーがこれらの手順を手動で実行する場合、次のアクションを実行します。

ステップ 1 - ATF ユーザーの代理操作を行う

ATF ユーザーの代理操作を行う

ステップ 2 - ATF ユーザーフォームを開く

ATF ユーザーレコードを開く

ATF ユーザーレコード

ステップ 3 - [ユーザーレコード] フィールドの値を確認する

[ユーザー ID]、[名]、および [姓] フィールドの値が想定される値であるかを検証する

ユーザーが手動でテストを実行することは可能ですが、ATF はテストステップを自動化し、時間を節約して人為的なミスを防ぎます。

記事 (5/40)

テストの有効化と実行

ATF テストは、ServiceNow インスタンスでアクションを実行します。テストが誤って実行されないようにするため、テストの実行はデフォルトで無効になっています。

テストはデフォルトで無効になっています。テストレコードでテストが無効になっている場合、テストレコードに次の警告メッセージが表示されます。テストとテストスイートの実行が無効です。ここでテストとテストスイートの実行を有効にします (リンク)。

テストレコード内のリンクをクリックしてテストの実行を有効にするか、Application Navigator を使用して [Automated Test Framework (ATF)] > [管理] > [プロパティ] を開きます。

[テスト/テストスイートの実行を有効にする] プロパティの [はい] をクリックして、テストを有効にします。

重要:すべてのテスト同様、ATF テストは開発インスタンスまたはテストインスタンスでのみ実行してください。本番環境で ATF を実行することは推奨しませんし、サポートもされません。

ATF テストをオンデマンドで実行するには、テストレコードを開き、[テストを実行] ボタンをクリックします。

テストフォームヘッダーの [テストを実行] ボタンをクリックして、テストを実行します。

テストステップにフォームを開くなどのクライアント側アクションが含まれている場合、テストはクライアントテストランナーで実行されます。クライアントテストランナーは、クライアント側テストのランタイム環境です。クライアントテストランナーは、クライアントテストランナーが起動されているブラウザー (Chrome や Firefox など) を使用して、特定のユーザーとしてテストステップを実行します。

テストランナーを選択するか、新しいテストランナーを作成する

必要に応じて、クライアントテストランナーでテストの進捗状況を監視します。

クライアントテストランナーは、テストの進捗状況をリアルタイムで表示

注意:クライアントテストランナーがフォアグラウンドのウィンドウまたはタブである場合、クライアントテストはより高速に実行されます。

クライアントテストランナーが現在のテストの実行を終了すると、「テストの実行終了、結果を報告」というテキストが短時間表示された後、「テストの実行を待機しています」という表示に戻ります。クライアントテストランナーはアクティブなままで、別のテストが実行されるのを待ちます。ブラウザータブを閉じると、クライアントテストランナーが終了します。ATF 管理者は、[Automated Test Framework (ATF)] > [管理] > [すべてのテストランナー] モジュールを使用してクライアントテストランナーを管理します。

クライアントテストランナーはアクティブなままです

重要:サーバー側のテストステップでは、クライアントテストランナーを使用しません。

テストの起動に使用する ServiceNow ウィンドウで、クライアント側とサーバー側の両方のテストの進捗状況を監視します。

[テストを実行] ダイアログには、テストのステータスとテストステップが表示されます。この例では、最初のテストステップは 100% 完了、2 番目のテストステップは 50% 完了、3 番目のテストステップはまだ開始されていません。全体的なテストの進捗状況は 33% 実行中です。

テストの実行後、ATF は次のレコードを除き、テスト実行中に変更されたデータをロールバック (取り消し) します。

  • 履歴 [sys_history_line]
  • ECC キュー [ecc_queue]
  • メール [sys_email]
  • メールログ [sys_email_log]
  • レポート実行 [report_executions]
  • レポート統計情報 [report_stats]
  • これらのテーブルを拡張するテーブル

注意:ATF ロールバックは無効にできません。ロールバックを無効にすると、プラットフォーム全体に予期しない結果が生じるおそれがあるため、無効化は許可されていません。

記事 (6/40)

テスト結果とテストステップ結果の表示

実行が完了したら、[結果に移動] ボタンをクリックして段階的なテスト結果を表示します。過去のテスト結果を確認するには、Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト結果] を開きます。

[結果に移動] ボタンをクリック

テスト結果レコードには、テスト結果、テストステップ結果、テストログ、およびテストの実行に関連するトランザクションが表示されます。

テスト結果には、テストの各ステップのステータスが表示されます。

想定されるテストステップステータス値は次のとおりです。

  • 待機中:実行前
  • 実行中:現在実行中
  • 成功:正常に完了
  • 失敗:完了したが、結果は失敗
  • スキップ:未実行 (通常は前のステップの失敗による)
  • エラー:未完了 (実行中にエラーが発生したため)
  • キャンセル:実行なし (ユーザーの介入による)

スクリーンショット

有効にすると、テスト実行中にスクリーンショットがキャプチャされ、テスト結果レコードに添付されます。このプロパティはデフォルトで有効になっています。このプロパティ値を変更するには、Application Navigator を使用して [Automated Test Framework (ATF)] > [管理]> [プロパティ] を開きます。

テスト結果レコードの [ダウンロード] リンクをクリックして、スクリーンショットをダウンロードして表示します。

スクリーンショットの横にある [表示] リンクをクリックして、スクリーンキャプチャを表示する

すべてのスクリーンショットをダウンロードして表示するには、[添付ファイルの管理] リンクをクリックし、[すべてをダウンロード] ボタンをクリックします。

テストステップ

[ステップ結果] 関連リストを使用して、特定のテストのステップ結果を表示します。[開始時間] 列のリンクをクリックして、テストステップレコードを開きます。

テストステップを開いてその結果を表示する

たとえば、[代理操作] ステップ結果へのリンクをクリックすると、代理操作ステップ結果レコードが開きます。

「代理操作」テストステップ

テストログ

[テストログ] 関連リストを使用して、テストおよびすべてのテストステップのログ情報を確認します。

ログ情報の表示に関連するテストログを使用する

テストトランザクション

[テストトランザクション] 関連リストを使用して、テストステップのトランザクションを表示します。ここに示されているトランザクションは、ServiceNow とのブラウザー (クライアント側) のインタラクションです。

トランザクション関連リスト

記事 (7/40)

テストのデバッグ

ATF には、開発者がテスト実行に関する追加情報にアクセスできるようにするためのデバッグ機能があります。

デバッグ機能はデフォルトで無効になっています。テストのデバッグを有効にするには、[Automated Test Framework (ATF)] > [管理] > [プロパティ] を開きます。[追加のデバッグ機能を有効にします] チェックボックスを選択します。

チェックボックスをオンにしてデバッグ機能を有効にする

デバッグ機能を有効にすると、クライアントテストランナーに [デバッグ情報] タブが追加されます。

[デバッグ情報] タブが追加されました

デバッグでは、テストレコードの [テストログ] に情報が書き込まれます。

テストログには 40 件のレコードが含まれます

デバッグ機能を有効にすると、ATF はより詳細なテスト実行動作を [テストログ] に記録します。デバッグ機能を有効にすると、[既存のレコードを開く][テストログ] にさらに多くのステートメントが含まれることに注意してください。

デバッグ機能を有効にした結果、テストログに 351 件のステートメントが含まれている

演習 (8/40)

演習:サンプルテストを実行する

この演習では、「簡易 UI テスト」と「フォームが開いていないために不合格」という 2 つのサンプル ATF テストを実行します。また、テスト結果を確認します。

注意:PDI が自動的に App Engine Studio を開く場合は、PDI にアクセスするために使用するユーザーロールを変更する必要があります。演習を完了するには、[管理者] ユーザーロールに切り替えます

準備

  1. Application Navigator を使用して [ユーザー管理] > [ユーザー] を開きます。
  2. 列検索の行がまだ表示されていない場合は、[列検索の行を表示] アイコン ([列検索行を表示] アイコンは虫眼鏡です。) をクリックします。
  3. [名前] フィールドの検索フィールドに「*chad」と入力し、キーボードの <return> (Enter) キーを押します。
    名前に文字列「chad」が含まれているユーザーを検索します。
  4. Chad Chaddington という名前のユーザーのレコードがないことを確認します。

「簡易 UI テストの実行」ステップを手動で実行する

  1. Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。

  2. [簡単な UI テスト] テストを見つけ、開いて編集します。

  3. [テストステップ] 関連リストまでスクロールします。6 つのステップを調べて、テスト内容について理解してください。

    簡易 UI テストステップには、代理操作、ユーザーフォームを開く、フィールド値の設定、フィールド値の検証、フィールド属性 (読み取り専用、表示、必須) の検証、ユーザーフォームの送信があります。

  4. テストステップを手動で実行して、テストの内容を確認し、ATF を使用することによる時間の節約を実感してください。

    1. 時計、電話、またはオンラインタイマーを使用してタイマーを開始します。
    2. Fred Luddy の代理操作を行います。
      1. ServiceNow ブラウザーのメインウィンドウで、ServiceNow バナーのユーザー名をクリックしてユーザーメニューを開きます。[代理操作ユーザー] オプションを選択します。
        代理操作メニューの選択
      2. [ユーザーの検索] フィールドに「Fred」と入力します。
      3. ドロップダウンリストで、[fred.luddy] をクリックします。
      4. ServiceNow バナーの [ユーザーメニュー] を確認します。「Fred Luddy」になっているはずです。
        ServiceNow バナーに「Fred Luddy」という名前が表示されるはずです
    3. ユーザーレコードを作成します。
      1. Application Navigator を使用して [ユーザー管理] > [ユーザー] を開きます。
      2. [新規] ボタンをクリックします。
      3. スクリーンショットをキャプチャできる場合は、新しいユーザーフォームのスクリーンショットを撮ります。
    4. 新しい ユーザーレコードにフィールド値を設定します。
        ユーザー ID test.testing
        Test
        Testing
        メール test.testing@example.com
    5. スクリーンショットをキャプチャできる場合は、[Test Testing] ユーザーフォームのスクリーンショットを撮ります。
    6. フィールドステータス (表示、読み取り専用、必須) を検証します。
      1. [メール] フィールドがフォームに表示されます。
      2. [市区町村] フィールドはフォームに表示されません。
      3. [アクティブ] フィールドと [パスワードのリセットを強制] フィールドに書き込み (値を変更) できるはずです。
      4. [ユーザー ID][メール]、および [名] フィールドは必須ではありません。必須フィールドの前にはアスタリスクがあることに注意してください。
      5. スクリーンショットをキャプチャできる場合は、フォームのスクリーンショットを撮ります。
    7. [送信] ボタンをクリックします。
    8. リストから [Test Testing] ユーザーフォームを再度開きます。
    9. スクリーンショットをキャプチャできる場合は、[Test Testing] ユーザーフォームのスクリーンショットを撮ります。
    10. test.testing ユーザーレコードを削除して [管理者] ユーザーに戻ることで、テストステップをロールバックします。
      1. [Test Testing] ユーザーレコードフォームで、[削除] ボタンをクリックします。
      2. 削除の [確認] ダイアログで、[削除] ボタンをクリックします。
      3. バナーの [Fred Luddy] をクリックしてユーザーメニューを開き、[代理操作を終了] メニューアイテムを選択します。
  5. タイマーを停止します。テストステップを完了するのにかかった時間をメモします。

簡易 UI テストの実行 - ATF

  1. まだグローバルスコープになっていない場合は、グローバルスコープに切り替えます。

    1. ServiceNow バナーにアプリケーションピッカーを追加した場合は、アプリケーションピッカーを使用してスコープをグローバルに変更します。
      アプリケーションピッカーを使用してスコープをグローバルに設定する
    2. ServiceNow バナーにアプリケーションピッカーを追加していない場合:
      1. ServiceNow バナーの [設定] ボタン ([設定] ボタンは、ServiceNow バナーの右端のボタンです) をクリックします。
      2. [開発者] ペインを選択し、[アプリケーション] フィールドを使用してスコープを [グローバル] に変更します。
      3. ServiceNow バナーにアプリケーションピッカーを追加するには、[ヘッダーにアプリケーションピッカーを表示] トグルを有効にします (オプション)。
      4. [システム設定] ダイアログを閉じます。
  2. Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。

  3. [簡単な UI テスト] テストを見つけ、開いて編集します。

  4. [ここからテストおよびテストスイートを有効にしてください] リンクをクリックします。既にテストの実行を有効にしている場合は、再度プロンプトが表示されることはありません。

    リンクをクリックしてテストを有効にします。

  5. [はい | いいえ] ボックスにチェックマークを付けて、テスト/テストスイートの実行を有効にします。

    チェックボックスをオンにしてテスト/テストスイートの実行を有効にする

  6. [保存] ボタンをクリックします。

  7. 簡易 UI テスト」レコードに戻ります。

  8. テストを実行します。

    1. [テスト実行] ボタンをクリックします。
    2. [ブラウザーを選択] ダイアログで、[新しいテストランナーを開始] オプションが選択されていることを確認してから、[テストを実行] ボタンをクリックします。
    3. テストステップの実行中にクライアントテストランナーを監視します。テストステップが終了し、クライアントテストランナーで「テストの実行を待機しています」と表示されたら、簡易 UI テストが開かれているブラウザータブに戻ります。
      テストの実行を待機するということは、クライアントテストランナーがクライアント側のテストステップを実行できることを意味します。
  9. [テストを実行] ダイアログを確認します。

    1. [テストを実行] ダイアログには、すべてのステップが正常に終了したことが示されているはずです。

      テストは正常に完了しているはずです。

    2. [結果に移動] ボタンをクリックします。

  10. 簡易 UI テスト」結果レコードを調べます。

    1. [期間] フィールドの値は、「簡易 UI テスト」ステップを手動で完了するのにかかった時間と比較してどうですか?
    2. [ステップ結果] 関連リストまでスクロールします。6 つのテストステップがすべて正常に完了しているはずです。
    3. [テストログ] 関連リストを開き、ログ情報をスクロールします。
    4. [テストトランザクション] 関連リストを開いて、テストステップがブラウザーとどのようなインタラクションを行ったかを確認します。
    5. テストによってキャプチャされたスクリーンショットを表示します。
      1. 簡易 UI テスト」結果フォームの上部にある [添付ファイルの管理] リンクをクリックします。
      2. [すべてをダウンロード] ボタンをクリックします。
      3. 選択したアプリケーションを使用して、ダウンロードしたスクリーンショットファイルを表示します。
  11. Application Navigator を使用して、[ユーザー管理] > [ユーザー] を開き、Chad Chaddington のユーザーレコードを探します。

質問Chad Chadington のユーザーレコードはありますか?あるべきですか?

回答:ATF は、テストの実行が終了した後で、実行内容をクリーンアップしました。テスト中に作成された Chad Chaddington のレコードは、テストの実行が終了した時点でユーザーテーブルから削除されました。

「フォームが開いていないために失敗」テストを実行する

  1. フォームが開いていないために不合格」サンプルテストを開きます。
  2. テストを調べて、テスト内容を確認します。
  3. [説明] フィールドの値を読んで、テストが不合格になる理由を確認します。
  4. [テスト実行] ボタンをクリックします。
  5. クライアントテストランナーは、前回のテストから開かれたままになっている場合、[ブラウザーを選択] ダイアログのリストに表示されます。[テスト実行] ボタンをクリックします。
  6. テストが終了したら、結果を確認します。テスト結果を使用して、テストが失敗した理由を特定します。テストの [説明] フィールドに基づいて想定したとおりですか?

記事 (9/40)

テストの作成とテストステップの追加

テストを作成するには、Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。[新規] ボタンをクリックします。

テストレコードを設定します。

新しいテストレコードの名前と説明を入力します。

  • 名前:テストのわかりやすい名前を入力します。
  • アクティブ:テストはランタイム環境で利用できます。
  • パラメーター化されたテストの有効化:パラメーター化された値でテストを実行できるようにします。このトピックについては、このモジュールの後半で詳しく説明します。
  • 説明:テストの内容を説明します。

開発者向けのヒント:予想されるテスト結果を [説明] フィールドに含めます。同僚も将来の自分も、それを高く評価するでしょう。

[保存] ボタンをクリックします。フォームには、[テストステップ][テスト結果][相互に排他的なテスト] 関連リストが表示されます。

テストステップとテスト結果に関連するリストがフォームの下部に追加されます。

テストステップの追加

[テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。[テストステップを追加] ダイアログで、テストカテゴリを選択します。

テストに追加するテストステップを選択し、[次へ] ボタンをクリックします。

テストステップは、リストと関連リスト、サービスカタログ、カスタム UI、サービスポータルのフォーム、アプリケーションナビゲータ、サービスポータルのサービスカタログ、フォーム、REST、レスポンシブダッシュボード、レポート、サーバー、メールというカテゴリ別に整理されています。

[テストステップを追加] ダイアログで、ステップを設定します。ステップフィールドは、選択したテストによって異なります。

テストステップを設定します。「新しいフォームを開く」ステップでは、テーブルを指定します。

[送信] ボタンをクリックします。

ステップは、[テストステップ] 関連リストに追加される

実行順序

実行順序によって、テストステップを実行する順序が決まります。デフォルトでは、実行順序はステップがテストに追加される順番です。

テストステップの作成時

テストステップをテストに追加する場合は、[次の後に挿入] 選択リスト使用してステップを目的の場所に配置します。

冒頭を選択するか、特定のステップを選択リストから選択

テストステップの作成後

テストステップを作成した後、[実行順序] フィールドを使用して、順序が正しくないステップに番号を付け直します。フォームを保存すると、他のテストステップは、加えた変更に基づいて自動的に並べ替えられます。

[実行順序] フィールドをダブルクリックして、順序を編集します。

開発者向けのヒント:多くのテストは、「ユーザーの作成」または「代理操作」テストステップで始まり、管理者以外のユーザーに対してテストステップが想定どおりに機能するかどうかを確認します。

演習 (10/40)

演習:テストを作成する

この演習では、次のテストを作成して実行します。

  • 既存のインシデントテーブルレコードを開く
  • [簡単な説明] フィールドに文字列「メール」が含まれているかを検証する
  • [更新] ボタン (UI アクション) が表示されているかを検証する

準備

  1. Application Navigator を使用して、[インシデント] > [開く] を開きます。
  2. 列検索の行がまだ表示されていない場合は、[列検索の行を表示] アイコン ([列検索行を表示] アイコンは虫眼鏡です。) をクリックします。
  3. [簡単な説明] フィールドの検索フィールドに「*email」と入力し、キーボードの <return> (Enter) キーを押します。
    [簡単な説明] フィールドで「メール」という文字列が含まれるオープンインシデントレコードを検索します。
  4. メールインシデントの INC 番号をメモしておきます。

テストを作成する

  1. Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。
  2. [新規] ボタンをクリックします。
  3. テストを次のように設定します。
      名前 メールインシデントを検証する (Validate Email Incident)
      説明 既存のインシデントレコードを開き、[簡単な説明] に文字列「メール」が含まれているかを検証し、[更新] ボタンが表示されることを確認します。(Open existing Incident record, validate the Short description contains the string email, and verify the Update button is visible。)
  4. [保存] ボタンをクリックします。

「既存のレコードを開く」テストステップを追加する

  1. [テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。
  2. [テストステップを追加] ダイアログで、[フォーム] カテゴリを選択します。
  3. [既存のレコードを開く] テストを選択します。
  4. テストステップの説明を読んで、テストステップの機能を理解してください。
    「既存のレコードを開く」ステップをテストに追加する
  5. [次へ] ボタンをクリックします。
  6. テストステップのテーブルを選択します。
      テーブル インシデント [incident]
  7. テストステップにレコードを設定します。
    1. [レコード] フィールドの [リストからドキュメントを参照] ボタン ([リストからドキュメントを参照] ボタンは、[レコード] フィールドの右側にあります。) をクリックします。
    2. [ドキュメント] フィールドの [リストから参照] ボタン ([リストからドキュメントを参照] ボタンは、[レコード] フィールドの右側にあります。) をクリックします。
    3. メールの問題のアクティブなインシデントを見つけるためのフィルターを構築します。
      1. [フィルター] ボタン (フィルタービルダーを開く) をクリックして、フィルタービルダーを開きます。
      2. フィルター条件の設定:[アクティブ] [次の値に等しい] [true]
      3. AND ボタンをクリックし、[簡単な説明] [次の値を含む] [メール]
        という別のフィルター条件を設定します。
        メールに関連するオープンインシデントを見つけるためのフィルターを作成します。
      4. [実行] ボタンをクリックして、フィルターを [インシデント] リストに適用します。
    4. レコード番号をクリックして、フィルタリングされたリストからレコードを選択します。
    5. [OK] ボタンをクリックします。
  8. [レコード] フィールドの注釈を読み取ります。

質問:注釈はどういう意味ですか?

注釈には、「既存のレコードを使用すると、このテストで予期しない動作が発生する可能性があります。デザインの検討に関するドキュメントを参照してください」


回答:Automated Test Framework では、特定のレコードがインスタンスに存在することを保証できません。選択したレコードを削除すると、テストは不合格になります。この注釈は、既存のレコードを選択すると予期しない結果が生じる可能性があることを開発者に知らせるものです。

  1. [送信] ボタンをクリックします。

「フィールド値の検証」テストステップを追加する

  1. [テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。

  2. [テストステップを追加] ダイアログで、[フォーム] カテゴリを選択します。

  3. [フィールド値の検証] テストステップを選択します。

  4. テストステップの説明を読んで、テストステップの機能を理解してください。

  5. [次へ] ボタンをクリックします。

  6. テストステップに条件を設定します。

    1. 条件[簡単な説明] [次の値を含む] [メール]
      条件は [簡単な説明] [次の値を含む] [メール] です

    注意:「フィールド値の検証」テストステップでは、大文字と小文字が区別されます。インシデントの値によっては、検証を正常に実行するために条件を調整する必要がある場合があります。

  7. [送信] ボタンをクリックします。

「UI アクション可視性」テストステップを追加する

  1. [テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。
  2. [テストステップを追加] ダイアログで、[フォーム] カテゴリを選択します。
  3. [UI アクション可視性] テストを選択します。
  4. テストステップの説明を読んで、テストステップの機能を理解してください。
  5. [次へ] ボタンをクリックします。
  6. テストステップの [表示] フィールドを設定して、[更新] ボタンが表示されているかを検証します。
    1. [表示] フィールドの [表示のロックを解除 (Unlock Visible)] ボタン ([ロック/ロック解除] ボタンは [表示] フィールドの右側にあります) をクリックします。
    2. [リストから参照] ボタン ([リストからドキュメントを参照] ボタンは、[レコード] フィールドの右側にあります。) をクリックします。
    3. フィルタービルダーを使用して、[名前] [次の値を含む] [更新] および [条件] [は空でない] の 2 つの条件を追加します。
    4. [実行] ボタンをクリックします。
      フィルタービルダーを使用して 2 つの条件を追加する
    5. フィルターは 1 つの結果を返す必要があります。レコードを選択して、テストステップ中にフォームに表示される UI アクションのリストに追加します。
      更新 UI アクションは [表示] フィールドリストにあります。
  7. [送信] ボタンをクリックします。

メールインシデント検証テストを実行する

  1. メールインシデント検証」テストを実行します。

    1. [テスト実行] ボタンをクリックします。
    2. [ブラウザーを選択] ダイアログで、新しいテストランナーを開始するか、既存のランナーが開いている場合はそれを選択します。
    3. [テスト実行] ボタンをクリックします。
    4. テストステップの実行中にクライアントテストランナーを監視します。テストステップが終了し、クライアントテストランナーで「テストの実行を待機しています」と表示されたら、「メールインシデント検証」テストが開かれているブラウザータブに戻ります。
      テストの実行を待機するということは、クライアントテストランナーがクライアント側のテストステップを実行できることを意味します。
  2. [テストを実行] ダイアログを確認します。

    1. [テストを実行] ダイアログには、すべてのステップが正常に終了したことが示されているはずです。
    2. [結果に移動] ボタンをクリックします。
  3. メールインシデント検証」テスト結果レコードを調べます。

    1. [ステップ結果] 関連リストまでスクロールします。3 つのテストステップがすべて正常に完了しているはずです。

      注意:「フィールド値の検証」テストステップが不合格になった場合は、テストステップで大文字と小文字が区別されている可能性があります。「フィールド値の検証」テストステップの条件に [簡単な説明] [次の値を含む] [メール] が含まれていますが、ここでは、メールアドレスは小文字です。メールアドレスは、インシデントレコードの簡単な説明で大文字にすることができます。よって、検証を正常に完了するために条件を調整する必要がある場合があります。

    2. [テストログ] 関連リストを開き、ログ情報をスクロールします。

    3. [テストトランザクション] 関連リストを開いて、テストステップがブラウザーとどのようなインタラクションを行ったかを確認します。

    4. テストによってキャプチャされたスクリーンショットを表示します。

      1. テスト結果フォームの上部にある [添付ファイルの管理] リンクをクリックします。
      2. [すべてをダウンロード] ボタンをクリックします。
      3. 選択したアプリケーションを使用して、ダウンロードしたスクリーンショットファイルを表示します。

課題

メールインシデント検証」テストを変更して、admin ロールを持つユーザーとしてすべてのテストステップを実行できるようにします。テストを実行し、結果を調べて、テストがまだ成功していることを確認します。行き詰まった場合は、課題のソリューションを表示できます。

課題のソリューション

メールインシデント検証」テストの最初のステップは、「ユーザーの作成」です。ユーザーには任意の名前を付けることができます。ユーザーを admin ロールで設定し、[このユーザーの代理操作を行う] フィールドを選択 (オン) する必要があります。

「代理操作」テストステップを最初のステップとして追加

その他のテストケース

ATF のその他のテストケースを確認したい場合は、docs.servicenow.com サイトの「Automated Test Framework use case examples (Automated Test Framework のユースケースの例)」のページにアクセスしてください。


記事 (11/40)

ATF 変数

ATF は変数を使用して、あるテストステップから別のテストステップにデータを渡します。変数には次の 2 つのタイプがあります。

  • 入力
  • 出力

入力変数

入力変数は、実行に必要な情報をテストステップに提供します。開発者は、テストステップを設定するときに入力変数の値を指定します。たとえば、「ユーザーの作成」テストステップには、[名][姓][ロール][グループ][このユーザーの代理操作を行う] の 5 つの入力変数があります。

[名]、[姓]、[ロール]、[グループ]、[このユーザーを代理操作] は、「ユーザーの作成」テストステップの入力変数

出力変数

一部のテストステップは、出力変数と呼ばれる値を返します。出力変数は、後のテストステップへの入力として使用できます。たとえば、「ユーザーの作成」テストステップは、他のテストステップが使用できる [ユーザー] 変数を出力します。

記事 (12/40)

ATF 変数の使用

テストを設定する場合、開発者は以前のテストステップの出力変数を使用して、後続のテストステップの入力変数を設定できます。この例では、[ユーザー] は「ユーザーの作成」テストステップからの出力変数です。「ユーザーの作成」テストステップのに生じるどのテストステップでも、[ユーザー] 出力変数を使用して入力変数を設定できます。

ステップからの出力変数を使用して、後続のテストステップの入力変数を設定できます。

出力変数を入力として受け入れるテストステップフィールドには、[データピルピッカー] ボタンがあります。

出力変数を受け入れるフィールドには、[参照を挿入] ボタンがある

[データピルピッカー] ボタンにより、入力変数で使用できる出力変数を含むステップのリストが開きます。

出力変数を含むステップのリストを表示する

ステップをクリックして、そのステップからの出力変数のリストを開きます。

出力変数を選択する

右側の列で出力変数をクリックして、入力変数に挿入します。

入力変数の設定に使用する出力変数

変数は、データピルで視覚的に表現されます。[問い合わせユーザー] フィールドに示されている構文は、テスト「ステップ 1:ユーザーの作成」の出力変数 [ユーザー][問い合わせユーザー] フィールドへの入力として使用することを意味します。

このトレーニングモジュールでは、規則 (ステップ ➔ 変数) を使用してデータピルを示します。

ドット連結

[ユーザー] 出力変数は、データベース内のレコードを一意に識別する参照 (sys_id) です。参照レコードのフィールド値を使用して入力変数を設定するには、[展開] ボタン (参照フィールドの [展開] ボタンをクリックします。) をクリックして、目的のフィールドを選択します。開発者は参照を使用して、関連するレコードをドット連結できます。

関連レコードのフィールドに到達するためのドット連結

演習 (13/40)

演習:出力変数を使用する

この演習では、「フィールド値の設定」テストステップを追加して、「メールインシデント検証」テストを変更します。新しいテストステップでは、出力変数を使用して入力変数を入力します。

「メールインシデント検証」テストにテストステップを追加する

  1. 前回の演習でまだ開いていない場合は、「メールインシデント検証」テストを編集用に開きます。
    1. Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。
    2. リストで「メールインシデント検証」テストを見つけて、編集用に開きます。
  2. 既存の「フィールド値の検証」テストステップの後に、「フィールド値の設定」テストステップを追加します。
    1. [テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。
    2. [次の後に挿入] 選択リストで、[ステップ 3 - フィールド値の検証] テストステップを選択します。
    3. カテゴリペインで、[フォーム] カテゴリを選択します。
    4. テストステップペインで、[フィールド値の設定] を選択します。
    5. [次へ] ボタンをクリックします。
  3. [問い合わせユーザー] フィールドの値を「ユーザーの作成」ステップの [ユーザー] 出力変数に設定します。
    1. [問い合わせユーザー] フィールドの [データピルピッカー] ボタン ([データピルピッカー] ボタン) をクリックします。
    2. [ステップ 1:ユーザーの作成] をクリックします。
    3. [ユーザー] をクリックします。
    4. [問い合わせユーザー] フィールドの構文を調べて、構文を理解してください。
    5. リストされている他のフィールドの [削除] ボタン ([削除] ボタンは、フィールドの横にある X です。) をクリックして、[問い合わせユーザー] フィールドのみが設定されるようにします。
    6. [送信] ボタンをクリックします。
  4. [他のアクション] メニュー ([他のアクション] メニューには [保存] メニューオプションが含まれています) をクリックして、[保存] メニューアイテムを選択します。
  5. [テストステップ] 関連リストで、「フィールド値の設定」テストの [説明] フィールドを調べます。特に [問い合わせユーザー] フィールド値がどのように設定されているかに注意します。

メールインシデント検証テストを実行する

  1. メールインシデント検証」テストを実行します。

    1. [テスト実行] ボタンをクリックします。
    2. [ブラウザーを選択] ダイアログで、新しいテストランナーを開始するか、既存のランナーが開いている場合はそれを選択します。
    3. [テスト実行] ボタンをクリックします。
    4. テストステップの実行中にクライアントテストランナーを監視します。テストステップが終了し、クライアントテストランナーで「テストの実行を待機しています」と表示されたら、「メールインシデント検証」テストが開かれているブラウザータブに戻ります。
      テストの実行を待機するということは、クライアントテストランナーがクライアント側のテストステップを実行できることを意味します。
  2. [テストを実行] ダイアログを確認します。

    1. [テストを実行] ダイアログには、すべてのステップが正常に終了したことが示されているはずです。
    2. [結果に移動] ボタンをクリックします。
  3. メールインシデント検証」テスト結果レコードを調べます。

    1. [ステップ結果] 関連リストまでスクロールします。テストステップがすべて正常に完了しているはずです。
    2. フィールド値の設定」テストのサマリーを調べて、[caller_id] フィールド値がテストステップ 1 で作成したユーザーと一致するかを検証します。
  4. テストによってキャプチャされたスクリーンショットを表示します。

    1. テスト結果フォームの上部にある [添付ファイルの管理] リンクをクリックします。
    2. [すべてをダウンロード] ボタンをクリックします。
    3. 選択したアプリケーションを使用して、ダウンロードしたスクリーンショットファイルを表示します。3 番目と 4 番目のスクリーンショットでは、[問い合わせユーザー] は、作成したユーザーに付けた名前になっているはずです。

記事 (14/40)

テストテンプレート

ATF テストテンプレートは、よく一緒に使用される再利用可能なテストステップのセットです。テストテンプレートには、テストステップの任意の組み合わせを含めることができます。テンプレートのテストステップには、テストに追加した後にさらに構成が必要になる場合があります。

ATF には、例として「デフォルトの新規フォームテストテンプレート」が含まれています。デフォルトのテンプレートには、一連の 8 つのテストステップが含まれています。

デフォルトのテンプレートには 8 つのテストステップが含まれる

テストにテストテンプレートを追加するには、テストの [テストステップ] 関連リストで、[テストテンプレートを追加] ボタンをクリックします。テンプレートを選択します。プロンプトが表示されたら、他の変数値を入力します。要求される変数値は、テンプレートのテストステップによって異なります。[追加] ボタンをクリックします。

テンプレートを選択し、必要な変数を入力します。

テンプレートの [説明] フィールドには、テンプレートのテストステップに基づいて入力されます。説明には、テンプレートステップを機能させるためにテンプレートのテストステップに対して何を実行する必要があるかを説明する、開発者向けの指示が含まれています。テンプレートがテストに追加される前に [説明] フィールドに値があった場合、既存の [説明] フィールドの値にテンプレートのステップと指示が追加されます。

テストの [説明] フィールドにテンプレートのステップリストが追加されます。

テンプレートのテストステップは、[テストステップ] 関連リストに追加されます。個別に追加されたテストステップと同じ戦略を使用して、テンプレートから追加されたステップを編集および削除します。たとえば、テンプレートによって追加された 8 つのテストステップのうち 6 つだけがテストに必要な場合、開発者はテンプレートを使用してテストステップを追加してから、不要なテストステップをテストから削除できます。この例では、テストで「UI アクション可視性」を検証する必要はありません。UI アクション関連のテストステップは、テンプレートによって追加されたすべてのテストステップを削除することなく削除できます。

テンプレートによって追加されたすべてのテストステップをテストに残す必要があるわけではありません。

記事 (15/40)

テストテンプレートの作成

ATF 管理者は、[Automated Test Framework (ATF)] > [管理] > [テストテンプレート] モジュールを使用してテストテンプレートを作成および編集します。

テストテンプレートの名前と説明を入力します。

  • 名前:テンプレートのテストステップコレクションを説明する名前です。たとえば、「フォームの作成とテスト」などです。
  • テストテンプレート:テストステップの順序付きリストです。
  • 説明:テンプレートの使用目的を説明するテキストを追加します。テンプレートの説明は、テンプレートを使用するテストの [説明] フィールドには表示されません

テストステップの追加

テンプレートにテストステップを追加するには、[テストテンプレートのロック解除 (Unlock Test template)] ボタン ([テストテンプレートを追加] ボタンをクリックして、テンプレート内のテストステップのリストを変更します。) をクリックし、テストステップリストを編集します。

テストステップをテンプレートに追加します。

スラッシュバケットを使用してテストステップを追加するには、テストを選択してから、[追加] ボタンをクリック ([追加] ボタンをクリックします。) します。終了したら、[保存] ボタンをクリックします。

スラッシュバケットを使用して、ステップを [コレクション] フィールドから [リスト] フィールドに移動します。

演習 (16/40)

演習:「Automated Test Framework の使用」モジュールのためにリポジトリをフォークしてアプリケーションをインポートする

ServiceNow は GitHub を使用して、開発者サイトの学習コンテンツをコピーして使用するアプリケーションリポジトリを提供します。リポジトリには、アプリケーションファイルの固定セットであるタグが含まれているため、部分的に構築されたアプリケーションを使用して作業を開始できます。ServiceNow が提供するリポジトリを個人開発者インスタンス (PDI) にコピーしてインポートすることで、モジュール内の実践的な演習に必要なすべてのファイルを取得できます。

注意:ServiceNow が開発者プログラムの学習コンテンツで GitHub を使用する方法の詳細と、リポジトリをフォークしてアプリケーションをインポートする方法に関するビデオを見るには、『GitHub ガイド』を参照してください。

この演習では、次のことを行います。

  1. ServiceNow リポジトリを GitHub アカウントにフォークします。
  2. リポジトリのフォークから PDI にアプリケーションをインポートします。

重要:リポジトリを既にフォークしてインポートしている場合は、次の演習に進み、タグから分岐を作成して、アプリケーションファイルを PDI にロードできます。モジュールを完了するには、NeedIt アプリケーションファイルが必要です。

リポジトリのフォーク

演習のこのセクションでは、開発者サイトの学習コンテンツで使用するアプリケーションリポジトリのパーソナルフォークを作成します。

  1. Web ブラウザーで、github.com を開きます。

  2. GitHub アカウントをお持ちの場合は、サインインします。お持ちでない場合は、新しいアカウントにサインアップします。

  3. サインインしたら、NeedIt リポジトリを開きます。

  4. [フォーク] ボタン (GitHub の [フォーク] ボタン) をクリックして、GitHub アカウントにリポジトリのコピーを作成します。

  5. 既にリポジトリをフォークしている場合は、ダイアログが表示されます。リポジトリを既にフォークしている場合は、次の演習に進みます。

    リポジトリは以前にフォークされている

  6. GitHub アカウントが複数の組織に属している場合は、GitHub でフォークを作成する場所を指定します。[Fork devtraining-application-release] ダイアログで、<お使いの GitHub ユーザー名> リンクを選択します。リポジトリのプライベートフォークを作成します。GitHub はリポジトリフォークのページを自動的にロードします。

    GitHub ユーザーが複数の組織に属している場合、GitHub はフォーク先を尋ねます。GitHub ユーザー名を選択します。

  7. リポジトリのフォークの URL が次のようになっているかを検証します:<お使いの GitHub ユーザー名>/devtraining-application-release

    フォークしたコピーは自動的にロードされます。

  8. フォークしたリポジトリの URL をコピーします。

    1. [コード] ボタンをクリックします。

    2. URL に ServiceNow ではなく GitHub ユーザー名が含まれていることを確認します。

    3. HTTPS が選択されていることを確認します。選択されていない場合は、[クローン] フライアウトで [HTTPS] タブを選択します。

    4. [クリップボードにコピー] ボタン ([クリップボードにコピー] ボタン) をクリックします。

      フォークしたリポジトリの URL をコピーする

      注意:次のセクションでは、コピーした URL を使用して、フォークしたリポジトリへの接続を設定します。

フォークしたリポジトリからアプリケーションをインポートします。

演習のこのセクションでは、アプリケーションリポジトリを ServiceNow にインポートします。プロセスの一環として、まず GitHub アカウントの資格情報レコードを作成してから、Studio を使用してアプリケーションリポジトリを PDI にインポートします。

  1. 管理者ユーザーとして PDI にログインします。PDI がない場合は、ServiceNow 開発者サイトを開いて Rome PDI を入手してください。

    注意:PDI の入手方法については、『個人開発者インスタンス (PDI) ガイド』を参照してください。

  2. GitHub 接続の資格情報レコードを作成します。

    重要:資格情報レコードを作成する必要があるのは 1 回だけです。別の演習で資格情報レコードを既に作成している場合は、この手順をスキップしてください。

    1. Application Navigator を使用して、[接続および資格情報] > [資格情報] を開きます。

    2. [新規] ボタンをクリックします。

    3. [作成する資格情報のタイプは?] リストで、[基本認証資格情報] リンクをクリックします。

    4. 資格情報レコードを設定します。

        名前 GitHub 資格情報 (GitHub Credentials) - <お使いの github.com ユーザー名>
        ユーザー名 <お使いの github.com ユーザー名>
        パスワード <お使いの github.com 個人アクセストークン>

      基本認証資格情報の新しいレコードフォーム。

      重要:GitHub では、ServiceNow などの他のプラットフォームからリポジトリにアクセスするには、個人アクセストークンが必要です。認証時には、パスワードの代わりに個人用アクセストークンが使用されます。GitHub パーソナルアクセストークンを作成する方法については、『GitHub ガイド』の「GitHub への認証」セクションを参照してください。

    5. [送信] ボタンをクリックします。

  3. Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。

    Studio アプリケーションを開きます。

  4. 新しいブラウザータブで Studio が開きます。

  5. [アプリケーションを選択] ダイアログで、[ソースコントロールからインポート] ボタンをクリックします。

    [ソースコントロールからインポート] ボタンをクリックします。

  6. [アプリケーションのインポート] ダイアログで、分岐したリポジトリへの接続を設定します。

      URL <リポジトリのフォークドバージョン用にコピーしたURL>
      資格情報 GitHub 資格情報 (GitHub Credentials) - <お使いの github.com ユーザー名>
      分岐 メイン (main)

    注意[分岐] の値を [メイン (main)] に変更すると、「デフォルトの命名規則を使用することを強くお勧めします」という情報メッセージが表示されます。[分岐] フィールドの値はリポジトリに存在する必要があります。開発者サイトのトレーニングリポジトリにはすべて [メイン (main)] 分岐があり、デフォルト値の代わりに使用する必要があります。

    github.com からコピーした URL を使用して、GitHub にフォークしたリポジトリへの接続を構成します。

  7. [インポート] ボタンをクリックします。

  8. アプリケーションのインポートが完了したら、[アプリケーションの選択] ボタンをクリックします。

    有効なリポジトリが存在する必要があります。

    注意:接続に失敗した場合は、フォークしたリポジトリ URL ではなく ServiceNow のリポジトリ URL を [URL] フィールドに入力しているか、あるいは GitHub アカウントで 2 要素認証を有効にしている可能性があります。接続のトラブルシューティング方法については、 「GitHub 問題のトラブルシューティング」を参照してください。

  9. [アプリケーションを選択] ダイアログで、Studio で編集するために、アプリケーションをクリックして開きます。

    重要:タグから分岐を正常に作成しないと、次の演習で Studio にアプリケーションファイルが表示されません。

演習 (17/40)

演習:「Automated Test Framework の使用」のブランチを作成する

この演習では、モジュールで使用するアプリケーションファイルを含む「Automated Test Framework の使用」モジュールの NeedIt アプリケーションの分岐を作成します。

注意:この演習を開始する前に、「演習:「Automated Test Framework の使用」モジュールのためにリポジトリをフォークしてアプリケーションをインポートする」で説明しているように、NeedIt リポジトリをフォークしてインポートしておく必要があります。

  1. 前回の演習で NeedIt アプリケーションを Studio で開いていない場合は、ここで開きます。

    1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。
    2. [アプリケーションを選択] ダイアログで、NeedIt アプリケーションをクリックします。
  2. Studio で、[ソースコントロール] メニューを開き、[ブランチを作成] メニューアイテムを選択します。

    [ソースコントロール] メニューおよび [ブランチを作成 (Create Branch)] メニューアイテムを開きます。

  3. 分岐を構成します。

      分岐名 ATFModule
      タグから作成 LoadForATFModule
  4. [ブランチを作成] ボタンをクリックします。

  5. [閉じる] ボタンをクリックします。

  6. タグに含まれているアプリケーションファイルをロードするには、(Studio ではなく) ServiceNow ブラウザーのメインタブに戻り、ブラウザーの再ロードボタンをクリックしてページを更新します。

    注意:分岐の作成に失敗した場合は、フォークしたリポジトリ URL ではなく ServiceNow のリポジトリ URL を [URL] フィールドに入力しているか、あるいは GitHub アカウントで 2 要素認証を有効にしている可能性があります。GitHub 接続問題のトラブルシューティング方法については、『GitHub ガイド』の「GitHub 問題のトラブルシューティング」セクションを参照してください。

演習 (18/40)

演習:テストテンプレートを作成する

この演習では、テストテンプレートを作成して次の演習で使用します。インスタンスがアップグレードされたら、次の 3 つの場合にインスタンスが機能することを確認するために、「NeedIt の [必要な場合] フィールドの日付」ビジネスルールで回帰テストを実行することができます。

  • 過去
  • 今日
  • 予定

ビジネスルールをテストするためのテンプレートを作成します。

準備

  1. 前の演習でまだ開いていない場合は、Studio で NeedIt アプリケーションを編集用に開きます。

    1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。
    2. [アプリケーションを選択] ダイアログで、NeedIt アプリケーションをクリックして Studio で開きます。
  2. Studio で、アプリケーションエクスプローラーを使用して、[サーバー開発 (Server Development)] > [ビジネスルール] > [NeedIt の [必要な場合] フィールドの日付過去 (NeedIt When needed field date past)] を開きます。

  3. ビジネスルールの機能を理解するには、「NeedIt の [必要な場合] フィールドの日付過去」のロジックを調べます。

    1. ビジネスルールがどのレコードに対応しているかを判断するには、[テーブル] フィールドの値を確認します。
    2. [実行のタイミング] セクション (タブ) を使用して、ビジネスルールをトリガーするデータベースインタラクション ([挿入]、[更新]、[削除]、[クエリ]) と、ビジネスルールを実行するために満たす必要がある条件を決定します。
    3. [詳細] タブに切り替え、スクリプトの内容を確認します。

    質問:「NeedIt の [必要な場合] フィールドの日付過去」ビジネスルールスクリプトは何を実行しますか?

    回答:ユーザーが [必要な場合] の値で過去のレコードを作成しようとすると、ビジネスルールによってエラーメッセージがユーザーに表示され、レコードはデータベースに保存されません。

  4. NeedIt の [必要な場合] フィールドの日付過去」ビジネスルールを開いて調べ、ビジネスルールがいつトリガーされるか、またビジネスルールがトリガーされると何が起こるかを理解します。

  5. NeedIt レコードを作成します。

    1. ServiceNow ブラウザーのメインウィンドウに戻り、Application Navigator を使用して [NeedIt] > [新規作成] を開きます。NeedIt アプリケーションが利用できない場合は、ブラウザーでページを再ロードしてください。
    2. フォームで、どのフィールドが必須かを確認します。すべての必須フィールドに値が設定されていますか?どの必須フィールドにデフォルト値が設定されているかを覚えておきます。次の演習でこの情報が必要です。
    3. [必要な場合] フィールドの値を過去の日付に設定します。
      1. [必要な場合] フィールドで、[日時を選択] ボタン ([必要な場合] フィールドのボタンをクリックする) をクリックします。
      2. 日付を昨日または昨日より前の日付に設定します。
      3. [送信] ボタンをクリックします。レコードはデータベースに保存されましたか?「NeedIt の [必要な場合] フィールドの過去の日付」ビジネスルールについて知っていることを基にすると、これは想定される動作ですか?
    4. [必要な場合] フィールドの値を今日の日付に設定します。
      1. [必要な場合] フィールドで、[日時を選択] ボタン ([必要な場合] フィールドのボタンをクリックする) をクリックします。
      2. 日付を今日に設定します。
      3. [送信] ボタンをクリックします。レコードはデータベースに保存されましたか?「NeedIt の [必要な場合] フィールドの今日の日付」ビジネスルールについて知っていることを基にすると、これは想定される動作ですか?
    5. [必要な場合] フィールドの値を予定の日付に設定します。
      1. [必要な場合] フィールドで、[日時を選択] ボタン ([必要な場合] フィールドのボタンをクリックする) をクリックします。
      2. 日付を今日ではなく、予定の日付に設定します。
      3. [送信] ボタンをクリックします。レコードはデータベースに保存されましたか?NeedIt テーブルのビジネスルールについて知っていることを基にすると、これは想定される動作ですか?

テストテンプレートを作成する

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [管理] > [テストテンプレート] を開きます。
  2. [新規] ボタンをクリックします。
  3. テストテンプレートを次のように設定します。
      名前 ビジネスルールテスト - NeedIt (Business Rule Test - NeedIt)
      説明 ユーザーの作成、レコードの挿入、すべての必須フィールドの値の確認、結果のログ記録 (Create a user, insert a record, verify all mandatory fields have values, log results)
  4. [他のアクション] メニュー (レコードを保存してフォームで操作を続行する) をクリックし、[保存] メニューアイテムを選択して、レコードを保存します。
  5. テストステップを [テストテンプレート] フィールドに追加します。
    1. [テストテンプレートのロック解除 (Unlock Test template)] ボタン (編集用のテストテンプレートのロックを解除する) をクリックします。

    2. [検索] フィールドを使用して「ユーザーの作成」テストステップを追加

      1. [検索]フィールドに「作成」と入力します。
      2. 選択リストから [ユーザーの作成] テストステップを選択します。
        [検索] フィールドを使用して「ユーザーの作成」テストステップを追加
    3. [検索] フィールドを使用して、テンプレートにテストステップを追加します。

        レコードの挿入
        レコードの検証
      1. ログ
        テンプレートには 4 つのステップがあります
  6. [更新] ボタンをクリックします。
  7. 次の演習で、このテンプレートを使用してテストします。

演習 (19/40)

演習:テンプレートからテストを作成する

この演習では、前回の演習で作成したテストテンプレートを使用して、新しい NeedIt レコード用に 3 つのテストを作成します。3 つのテストすべてで、以下を行います。

  • ユーザーを作成
  • レコードを挿入
  • レコードを検証
  • テストをログに記録

さらに、3 つのテストのそれぞれにおいて [必要な場合] フィールドに日付を設定します。日付は各テストで異なります。

  • 過去
  • 今日
  • 予定

準備

作成するテストは、NeedIt アプリケーションの一部です。NeedIt が現在のスコープであることを確認します。

  1. ServiceNow ブラウザーのメインウィンドウで、[設定] ボタン (設定を開く) をクリックします。
  2. [開発者] ペインを開きます。
  3. [アプリケーション] フィールドを使用して、現在のアプリケーションが NeedIt であるかを検証します。
  4. 必要に応じて、[ヘッダーにアプリケーションピッカーを表示]トグルを選択済み (緑) に設定して、ServiceNow ヘッダーに現在のアプリケーションを表示します。
    現在のアプリケーションスコープが NeedIt であるかを検証する

テストの作成 - 予定

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。

  2. [新規] ボタンをクリックします。

  3. テストを次のように設定します。

      名前 必要な場合 - 予定
  4. [保存] ボタンをクリックします。

  5. テストテンプレートを追加します。

    1. [テストステップ] 関連リストで、[テストテンプレートを追加] ボタンをクリックします。
    2. テストテンプレートを選択して設定します。
        テンプレート ビジネスルールテスト - NeedIt (Business Rule Test - NeedIt)
        テーブル NeedIt
    3. [追加] ボタンをクリックします。
  6. テストでは、[説明] フィールドを調べます。テストテンプレートにより、[説明] フィールドのテキストが作成されました。

  7. ユーザーの作成」テストステップを設定します。

    1. [テストステップ] 関連リストで、[ユーザーの作成] リンクをクリックします。
    2. テストステップ変数を設定します。
        Jodie
        Whittaker
        ロール admin
        このユーザーの代理操作を行う 選択済み (オン)
    3. [更新] ボタンをクリックします。
  8. レコード挿入」テストステップを設定します。

    1. [テストステップ] 関連リストで、[レコード挿入] リンクをクリックします。

    2. [必要な場合] フィールドの値を設定します。

      1. [ファイルを選択] ボタン ([日付を選択] ボタンをクリックすると、日付ピッカーが開きます。) をクリックします。
      2. [必要な場合] フィールドの値を <未来の日付を選択> に設定します。
      3. [保存 (Enter)] ボタンをクリックします。
    3. [要求先] フィールドの値を設定します。

      1. [要求先] フィールドの [データピルピッカー] ボタン ([展開] ボタン) をクリックします。
      2. [ステップ 1:ユーザーの作成] をクリックします。
      3. [ユーザー] 参照をクリックします。
        [要求元] フィールドに新しいユーザーを使用します。ステップ 1:ユーザーの作成 -> ユーザー
    4. [要求先メールアドレス (Requested for email)] フィールドの値を.@example.com に設定します。

      1. [要求先メールアドレス (Requested for email)] フィールドの [データピルピッカー] ボタン ([展開] ボタン) をクリックします。
      2. [ステップ 1:ユーザーの作成] をクリックします。
      3. [ユーザー] 参照の [展開] ボタン ([展開] ボタン) をクリックします。
      4. [名] フィールドを選択します。
      5. ピリオドを入力します。
      6. (ステップ 1:ユーザーの作成 ➔ ユーザー ➔ 姓) データピルを追加します。
      7. @example.com」と入力してメールアドレスを完了します。
        [要求元メールアドレス (Requested for email)] フィールドに新しいユーザーのメールアドレスを作成します。
    5. 各フィールドの [削除] ボタンをクリックして、[要求タイプ] フィールドと [必要なもの (What needed)] フィールドを削除します。

      [必要な場合] フィールドを除くすべての必須フィールドをテストステップから削除します。

    質問[要求タイプ] および [必要なもの (What needed)] フィールドではなく、[必要な場合][要求先][要求先メールアドレス (Requested for email)] のフィールドに値を設定したのはなぜですか?

    回答[要求先][要求先メールアドレス (Requested for email)] にデフォルト値はありませんが、フォームを開くときにクライアントスクリプトによってこれらのフィールドに値が入力されるためです。NeedIt フォームの [要求タイプ] フィールドと [必要なもの (What needed)] フィールドにはデフォルト値があります。テストの [要求タイプ] フィールドと [必要なもの (What needed)] フィールドを空白のままにすると、テストの実行時にデフォルト値の代わりに null が使用されます。

    レコードの挿入が完了した「必要な場合 - 過去」テスト。

    1. [更新] ボタンをクリックします。
  9. レコードの検証」テストステップを設定します。

    1. [テストステップ] 関連リストで、[レコードの検証] リンクをクリックします。
    2. [レコード] フィールドの隣にある [データピルピッカー] ボタン ([展開] ボタン) をクリックします。
    3. [ステップ 2:レコードの挿入] をクリックします。
    4. [レコード] をクリックします。
    5. 検証するフィールド値を設定します。
        [要求先] [次の値に等しい] [(ステップ 1:ユーザーの作成➔ユーザー)]
        [要求先メールアドレス (Requested for email)] [次の値に等しい] [(ステップ 1: ユーザーの作成➔ユーザー➔名)。(ステップ 1:ユーザーの作成➔ユーザー➔姓)@example.com]
        [要求タイプ] [次の値に等しい] [法務]
        [必要なもの] [次の値に等しい] [法務 1]
      1. [必要な場合] [空でない]
        「レコードの検証」テストステップを設定します。
    6. [更新] ボタンをクリックします。
  10. ログ」テストステップを設定します。

    1. [テストステップ] 関連リストで、[ログ] リンクをクリックします。

    2. [ログ] フィールドに、「予定の日付が設定されている「必要な場合」テストは成功するはずです。テストによって挿入されたレコード:」というテキストを入力します (コロンの後にスペースを含める)。

    3. [ログ] フィールドの [データピルピッカー] ボタン ([展開] ボタン) をクリックし、(ステップ 2:レコードの挿入 ➔ レコード) を選択します。

      ログメッセージには、データピルによって挿入された文字列と動的な値が含まれます。

    4. [更新] ボタンをクリックします。

テスト

  1. [テスト実行] ボタンをクリックします。

    質問:このテストでクライアントテストランナーの選択を求められないのはなぜですか?

    回答:このテストのすべてのテストステップはサーバーベースであり、クライアントテストランナーを必要としないためです。

  2. [テストを実行] ダイアログを確認します。テストは合格しているはずです。

  3. [結果に移動] ボタンをクリックします。

  4. [ステップ結果] 関連リストを確認します。すべてのテストステップのステータスが [成功] になっているはずです。

    [ステップ結果] 関連リストの [ステータス] 列の値は、4 つのテストステップすべてが [成功] になっています。

「必要な場合 - 予定」テストの改善

[必要な場合] の日付が、テストにハードコードされていることにお気付きかもしれません。つまり、テストを実行するには、テストを手動で変更する必要があるということです。日付をハードコーディングする代わりに、サーバー側の JavaScript を使用して動的に日付を設定します。

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。

  2. 編集する「必要な場合 - 予定」テストを開きます。

  3. [テストステップ] 関連リストで、[レコードの挿入] テストステップをクリックして編集用に開きます。

  4. GlideSystem daysAgo() メソッドに詳しくない場合は、サーバー側の API ドキュメントをお読みください。

  5. [必要な場合] フィールドの値を動的に設定します。

    1. 必要な場合javascript:gs.daysAgo(-3)
      JavaScript と GlideSystem メソッドを使用して日付を動的に設定する

    質問:日付のメソッドに負の数を渡すのはなぜですか?

    回答:メソッドには、過去を意味する「Ago」という単語が含まれています。メソッドに正の数を渡すと、過去の経過時間が示されます。たとえば、「gs.daysAgo(3)」は過去 3 日間を意味します。Ago メソッドに負の数を渡すことは予定を意味します。たとえば、「gs.daysAgo(-3)」は 3 日先を意味します。

  6. [更新] ボタンをクリックします。

  7. 前の演習と同じ手法を使用して、「必要な場合 - 予定」テストを再度実行し、テスト結果を確認します。すべてのテストステップが正常に完了しているはずです。

課題 - 過去と今日

開発者向けのヒント:「必要な場合 - 予定」のテストフォームの [テストをコピー] ボタンは、この課題に役立ちます。

質問:前回の演習で行ったテストに基づいて、ユーザーは、「必要な場合」を過去の日付にして NeedIt レコードを保存できますか?

回答:「NeedIt の [必要な場合] フィールドの日付」ビジネスルールでは、[必要な場合] フィールドの日付値が 今日の日付または過去の日付の場合、新しい NeedIt レコードは保存されません。新しい NeedIt レコードには、「必要な場合」の予定の日付を指定する必要があります。

例として、「必要な場合 - 予定」のテストを使用し、さらに 2 つのテストを作成します。

  • 必要な場合 - 過去
    • このテストは、「必要な場合 - 予定」テストと同じでなければなりません。ただし、過去の [必要な場合] フィールド値をテストする点が異なります。
    • 必要な場合の日付が過去:javascript:gs.daysAgo(3)
    • 「レコード挿入」テストステップは不合格になるはずです。
    • ログ」テストステップを更新して、テストの不合格が予想されることを示します。
  • 必要な場合 - 今日
    • このテストは、「必要な場合 - 今日」テストと同じでなければなりません。ただし、今日の [必要な場合] フィールド値をテストする点が異なります。
    • 必要な場合の日付が今日:javascript:gs.minutesAgo(-20)
    • 「レコード挿入」テストステップは不合格になるはずです。
    • ログ」テストステップを更新して、テストの不合格が予想されることを示します。

2 つのテストを作成した後、テストを実行して、予想する結果が得られることを確認します。両方のテストが不合格になるはずです。

質問:「必要な場合 - 過去」と「必要な場合 - 今日」のテストが不合格になると予想されるのはなぜですか?

回答:「NeedIt の [必要な場合] フィールドの日付」ビジネスルールでは、[必要な場合] の日付が予定の日付であるかを検証します。[必要な場合] の日付が予定の日付でない場合、ビジネスルールによりレコードは挿入されません。ビジネスルールが機能している場合、「必要な場合 - 過去」および「必要な場合 - 今日」のテストは、レコードの挿入に失敗するはずです。「レコード挿入」テストステップは不合格になります。

記事 (20/40)

テストの成功をアサート

前回の演習では、「NeedIt の [必要な場合] フィールドの日付」ビジネスルールにより新しいレコードを保存できなかったため、「必要な場合 - 過去」のテストは不合格でした。テストは不合格でしたが、不合格は予想通りの結果でした。不合格は予想通りの結果だったので、このテストステップは成功したと言えます。アプリケーションのテストを作成する際、開発者はいくつかのテストステップの成功基準を定義できます。

[アサーションタイプ] フィールドを使用して、テストステップの成功基準を指定します。たとえば、「レコード挿入」テストステップの [アサーションタイプ] の選択肢は次のとおりです。

  • レコードが正常に挿入されました:レコードが挿入された場合にテストステップは成功します。
  • レコードが挿入されませんでした:レコードが挿入されなかった場合に、テストステップは成功します。
    「レコード挿入」テストステップは、レコードが挿入されたとき、またはレコードが挿入されないときに成功をアサートできます。

テストステップが異なれば、[アサーションタイプ] フィールド値も異なります。「レコードのクエリ」テストステップでは、[アサーションタイプ] の値が「レコードの挿入」テストステップとは異なっています。

  • クエリに一致するレコードが少なくとも 1 つあります:クエリが 1 つ以上のレコードを返す場合、テストステップは成功です。
  • クエリに一致するレコードがありません:クエリで一致するレコードが見つからない場合、テストステップは成功です。
    「レコードのクエリー」テストステップでは、クエリーが値を返す場合と返さない場合に成功をアサートできます。

テストステップのアサートオプションは、ServiceNow Docs サイトにあります。

開発者向けのヒント:テストステップの予想される結果と一致するように [アサーションタイプ] を設定し、予想される結果と一致したときにテストが成功するようにします。

演習 (21/40)

演習:テストの成功をアサートする

この演習では、NeedIt レコードが作成されていない場合に、失敗ではなく成功を報告するように、「必要な場合 - 過去」および「必要な場合 - 今日」のテストを更新します。「必要な場合 - 過去」および「必要な場合 - 今日」のテストでは、「NeedIt の [必要な場合] フィールドの日付」ビジネスルールが正しく機能している場合に、レコードの作成に失敗することが想定されています。成功を報告するには、レコード作成の失敗が想定されていることをアサートするように、「レコード挿入」テストステップの [アサーションタイプ] を設定します。

「必要な場合 - 過去」テストを更新する

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。
  2. 編集する「必要な場合 - 過去」テストを開きます。
  3. レコード挿入」テストステップを更新します。
    1. [テストステップ] 関連リストで、[レコードの挿入] テストステップをクリックして編集用に開きます。
    2. [アサーションタイプ] フィールドを [レコードが挿入されませんでした] に設定します。
    3. [更新] ボタンをクリックします。
  4. レコード検証」および「ログ」テストステップを削除します。

質問:「レコード検証」および「ログ」テストステップを削除したのはなぜですか?

回答:「必要な場合 - 過去」テストには検証すべきレコードが挿入されていないため、「レコード検証」テストステップを削除できます。レコードを挿入できない場合でも [レコードの挿入] が成功するようにアサーションタイプが設定されているため、失敗が予想されることを示すログメモは不要になりました。

「必要な場合 - 過去」テストをテストする

  1. [テスト実行] ボタンをクリックします。
  2. [テストを実行] ダイアログを確認します。テストは成功しているはずです。
  3. [結果に移動] ボタンをクリックします。
  4. [ステップ結果] 関連リストを確認します。「レコード挿入」テストステップの [サマリー] に含まれる情報に注意してください。

課題

レコードが作成された場合に「必要な場合 - 今日」テストが成功するよう次のように更新します。

  • 必要な場合 - 今日
    • レコードが挿入された場合にテストステップが成功するように、「レコード挿入」テストステップ設定を変更します。
    • レコード検証」および「ログ」テストステップを削除します。
    • テストを実行して、テストが正常に完了したことを確認します。

記事 (22/40)

テストスイート

テストスイートは、関連するテストやその他のテストスイートを単一ジョブとして実行するための論理的な階層グループです。たとえば、前回の演習で作成されたテストは、同じビジネスルールによって処理される 3 つのケースをテストしているため、関連しています。前回の演習では、テストは個別に実行されましたが、同じグループの一部として実行する方が理にかなっています。

前回の演習で作成した 3 つのテストを実行するテストスイートには、次のような階層があります。

テストスイートには、同じ階層レベルの 3 つのテストが含まれています

この例では、テストスイートの「NeedIt アプリのテストスイート」は、テストとテストスイートの階層になっています。

階層は複数のレイヤー深度にすることができ、テストと他のテストスイートを組み合わせて構成できます。

最上位レベルは、「NeedIt アプリのテストスイート」です。階層内の残りのテストとテストスイートは、「NeedIt アプリのテストスイート」の子孫です。

テストスイート階層では、テストは子になれますが、親にはなれません。

テストスイートは、親にも子にもなれます。テストスイートの「メールアドレス構文の検証」は、次のようになっています。

  • NeedIt アプリのテストスイート」の子スイート
  • 別のテストスイート」の親スイート

開発者向けのヒント:あるテストがテストスイート階層に複数回含まれている場合、そのテストは 1 回だけ実行されます。

記事 (23/40)

テストスイートの作成

テストスイートを作成するには、Application Navigator を使用して [Automated Test Framework (ATF)] > [スイート] を開きます。[新規] ボタンをクリックします。

テストスイートの名前説明を入力します。

名前と説明の入力から開始します。

[保存] ボタンをクリックします。

テストの追加

[テストスイートテスト] 関連リストで、[新規] ボタンを使用してテストスイートの新しいテストを作成します。既存のテストをスイートに追加するには、[新規行を挿入...] をダブルクリックし、テストの名前を入力します。リストからテストを選択し、[保存 (Enter)] ボタンをクリックします。

スイートに既存のテストを追加します。

[実行順序] フィールドによって、テストを実行する順序が決まります。ATF は、テストが追加された順序に基づいて実行順序を自動的に決定します。開発者は、[実行順序] フィールドの値を変更して、テスト実行の順序を変更できます。

[不合格時に中止] フィールドは、テストが不合格になった場合にテストスイートの実行を停止するかどうかを示します。デフォルト値は false です。false は、テストが不合格になった場合でもスイートの残りの部分のテストを続行することを意味します。

ベースラインテストである基本 UI テストは、スイートに含まれています。

テストスイートの追加

[子テストスイート] 関連リストで、[新規] ボタンを使用してテストスイートの新しいスイートを作成します。新しいテストスイートを設定します。[親スイート] フィールドは自動的に設定されます。

別のスイート内にテストスイートを作成すると、[親スイート] フィールドの値は自動的に設定されます。

既存のテストスイートを子として追加する場合は、編集する子テストスイートを開きます。[親スイート] フィールドに値を手動で設定し、レコードを保存します。

既存のスイートを別のスイートに追加する際には、親スイートを手動で設定します。

[子テストスイート] 関連リストには、現在のスイートを親とするすべてのスイートが表示されます。

子スイート

記事 (24/40)

テストスイートの実行

テストスイートを実行するには、[テストスイートを実行] ボタンをクリックします。

[テストスイートを実行] ボタンをクリック

テストスイートにクライアント側スクリプトを実行するテストステップが含まれている場合は、クライアントテストランナーを選択するように求められます。新しいテストランナーを開始するか、既存のテストランナーを選択した後、[テストスイートを実行] ボタンをクリックします。

テストランナーを選択し、[テストスイートを実行] ボタンをクリック

テストスイートの実行が完了したら、[テストスイートを実行] ダイアログウィンドウに結果が表示されます。[テストスイートを実行] ダイアログに表示されるテスト結果は、テストスイート階層に従います。

[テストスイートを実行] ダイアログは、テストおよびテストスイートベースで成功または不合格を示します。

[結果に移動] ボタンをクリックして、テストスイートの結果レコードを表示します。結果は、テスト結果ごと、および子テストスイート結果ごとにグループ化されます。

結果は、テスト結果ごと、および子テストスイート結果ごとにまとめられる

[子テストスイート結果] 関連リストで、[階層リストの表示] アイコン (矢印をクリックして、スイートのテストを表示または非表示にします) をクリックして、スイートのテストを表示します。

テストスイートの結果は階層表示

テストの [プレビュー] アイコン (テストには、テストステップにドリルダウンするための [プレビュー] アイコンがあります。) をクリックして、テストステップの結果を確認します。

スイートの結果から、[プレビュー] をクリックしてテストステップの結果を確認します。

開発者向けのヒント:クライアントテストランナーでのテストの実行速度が遅い場合は、ServiceNow コミュニティのブログ「How to avoid ATF testing failures (ATF テストの不合格を回避する方法)」を確認してください。

記事 (25/40)

テストスイートの再実行

ATF によって検出された問題を修正した後、開発者はスイート全体を再度実行しないで、テストスイートの不合格になったテストを再実行できます。[不合格になったテストを再実行] ボタンをクリックして、テストスイートの不合格になったテストのみを実行します。

テストスイートに失敗があった場合、不合格になったテストを再実行する

ATF は、再実行テスト用の新しいスイート結果階層を作成します。進行中の作業者、テスト結果、およびテストスイートの結果レコードは、以前のテストスイートと同じスイート階層を示します。以前のランで合格したテストやスイートは含まれません。

不合格になったテストの結果のみが [テストスイートを再実行 (Re-run Test Suite)] ダイアログに表示される

不合格になった子スイートまたはテストを削除または無効化してからスイートを再実行すると、ATF は再実行時にそのスイートまたはテストを実行しません。

不合格になったテストのスイートに子スイートまたはテストを追加してから再実行すると、ATF は追加されたスイートまたはテストを再実行しません。

演習 (26/40)

演習:テストスイートを作成して実行する

この演習では、NeedIt アプリという親テストスイートを作成して実行します。親テストスイートには、子テストスイートが含まれます。

親テストスイート - NeedIt アプリを作成する

  1. 作成するテストスイートは、NeedIt アプリケーションの一部です。前回の演習と同じ戦略を使用して、NeedIt が現在のスコープであることを確認します。
  2. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [スイート] を開きます。
  3. [新規] ボタンをクリックします。
  4. 新しいスイートを設定します。
      名前 NeedIt アプリ (NeedIt App)
      説明 NeedIt アプリケーションのテストスイート (Test Suite for the NeedIt application)
  5. [保存] ボタンをクリックします。

子テストスイート - [必要な場合] フィールド NeedIt アプリを作成する

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [スイート] を開きます。
  2. [新規] ボタンをクリックします。
  3. 新しいスイートを設定します。
      名前 [必要な場合] フィールド NeedIt アプリ (When needed Field NeedIt App)
      親スイート NeedIt アプリ (NeedIt App)
      説明 NeedIt の [必要な場合] フィールドの日付でビジネスルールをテストし、過去の日付、今日、未来の 3 つのケースで機能することを確認します。
  4. [保存] ボタンをクリックします。
  5. 以前の演習で作成した「必要な場合 - 過去」テストをスイートに追加します。
    1. [テストスイートテスト] 関連リストまでスクロールします。
    2. [新規行を挿入] をダブルクリックします。
    3. [検索] フィールドに「必要な」と入力し、リストから [必要な場合 - 過去] テストを選択します。
    4. [保存 (Enter)] ボタン ([OK] ボタンは [検索] フィールドの右側にあります) をクリックします。
  6. スイートにさらに 2 つのテストを追加します。
      必要な場合 - 今日
      必要な場合 - 予定
  7. [更新] ボタンをクリックします。
  8. [必要な場合] フィールド NeedIt アプリ (When needed Field NeedIt App) スイートが、NeedIt アプリ (NeedIt App) スイートの子スイートであることを検証します。
    1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [スイート] を開きます。
    2. NeedIt アプリ (NeedIt App) テストスイートレコードを開きます。
    3. [子テストスイート] 関連リストを開きます。
    4. [必要な場合] フィールド NeedIt アプリ (When needed Field NeedIt App) スイートが関連リストにあるかを検証します。

質問NeedIt アプリ (NeedIt App) テストスイートの正しい階層を示しているのはどの図でしょうか?

A、B、C、または D を選択


回答:正解は C です。[必要な場合] フィールド NeedIt アプリ (When needed Field NeedIt App) スイートは、NeedIt アプリ (NeedIt App) の子スイートで、3 つのテストが用意されています。

NeedIt アプリのテストスイートの実行

  1. NeedIt アプリ (NeedIt App) テストスイートレコードで、[テストスイートの実行] ボタンをクリックします。

  2. [テストスイートの実行] ダイアログを確認します。NeedIt アプリ (NeedIt App) スイートは成功するはずです。

    NeedIt アプリスイートは成功しました。

  3. [テストスイートを実行] ダイアログで、[必要な場合] フィールド NeedIt アプリ (When needed Field NeedIt App) スイートの [展開] ボタン ([展開] ボタンをクリックして階層を展開する) をクリックし、テスト結果を表示します。すべてのテストを表示するには、スクロールしなければならない場合があります。

    [必要な場合] フィールド NeedIt アプリスイートは成功しました。

  4. [結果に移動] ボタンをクリックします。

  5. [テスト結果][子テストスイート結果]、および [すべてのテストスイート結果] を調べて、どのような情報が含まれているかを確認します。

演習 (27/40)

演習:NeedIt アプリテストスイートにテストを追加する

この演習では、NeedIt アプリ (NeedIt App) のテストスイートに追加するテストを作成します。テストでは、NeedIt フォームの [要求先メールアドレス (Requested for email)] フィールドが [要求先] フィールドに記載されているユーザーの正しいメールアドレスであるかどうかを判断します。

準備 - クライアントスクリプトの動作の詳細確認

  1. 以前の演習でまだ開いていない場合は、NeedIt アプリケーションを編集用に開きます。

    1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。

    2. Studio で NeedIt アプリケーションへのリンクをクリックして開きます。

  2. NeedIt Set Requested for クライアントスクリプトを調べます。

    1. Studio で、アプリケーションエクスプローラーを使用して、[クライアント開発 (Client Development)] > [クライアントスクリプト] > [NeedIt Set Requested for] を開きます。
    2. NeedIt Set Requested for のロジックを調べて、クライアントスクリプトの機能を把握します。ServiceNow のスクリプティングにあまり慣れていない場合は、[説明] フィールドとスクリプトのコメントを使用して、スクリプトの動作を判断してください。
  3. NeedIt Populate Email Field クライアントスクリプトを調べます。

    1. Studio で、アプリケーションエクスプローラーを使用して、[クライアント開発 (Client Development)] > [クライアントスクリプト] > [NeedIt Populate Email Field] を開きます。
    2. NeedIt Populate Email Field のロジックを調べて、クライアントスクリプトの機能を把握します。ServiceNow のスクリプティングにあまり慣れていない場合は、[説明] フィールドとスクリプトのコメントを使用して、スクリプトの動作を判断してください。
  4. NeedIt レコードを作成します。

    1. ServiceNow ブラウザーのメインウィンドウに戻り、Application Navigator を使用して [NeedIt] > [新規作成] を開きます。
    2. フォームで [要求先] フィールドの値を確認します。この値は、クライアントスクリプトによって現在ログインしているユーザーに設定されています。
    3. [要求先メールアドレス (Requested for email)] フィールドの値に注意してください。この値は、クライアントスクリプトによって [要求先] のメールアドレスに設定されています。
    4. [要求先] フィールドの値を Fred Luddy に変更します。
    5. [要求先メールアドレス (Requested for email)] の新しい値に注意してください。新しい NeedIt レコードを保存する必要はありません。
  5. Fred Luddy のメールアドレスが正しく設定されているかどうかを検証します。

    1. Application Navigator を使用して [ユーザー管理] > [ユーザー] を開きます。
    2. Fred Luddy のユーザーレコードを開きます。
    3. NeedIt レコードに表示されたメールアドレスが、Fred のユーザーレコードのメールアドレスと一致するかを検証します。

テストを作成する

  1. Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。
  2. [新規] ボタンをクリックします。
  3. テストを次のように設定します。
      名前 NeedIt Set Requested for とメール
      説明 2 つの NeedIt アプリクライアントスクリプトをテストします:NeedIt Set Requested for と NeedIt Populate Email Field
  4. [保存] ボタンをクリックします。

テストステップを追加

演習のこのセクションでは、テストステップをテストに追加します。「ユーザーの作成」テストステップでは、作成されたレコードにメールアドレスが含まれていないため、このテストには「代理操作」テストステップを使用します。

  1. 代理操作」テストステップを追加します。

    1. [テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。
    2. [テストステップを追加] ダイアログで、[サーバー] カテゴリを選択してから、[代理操作] テストステップを選択します。
    3. [次へ] ボタンをクリックします。
    4. 代理操作」テストステップを設定します。
        ユーザー Fred Luddy
    5. [送信] ボタンをクリックします。
  2. [モジュールに移動] テストステップを追加して、新しい NeedIt フォームを開きます。

    1. [テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。
    2. [テストステップの追加] ダイアログで、[Application Navigator] カテゴリを選択してから、[モジュールに移動] テストステップを選択します。
    3. [次へ] ボタンをクリックします。
    4. モジュールに移動」テストステップを設定します。
      1. [モジュール] フィールドの [リストから参照] ボタン ([リストから参照] ボタンは、[モジュール] フィールドの右側にあります。) をクリックします。
      2. [アプリケーションメニュー] で needit が含まれている (*needit) モジュールを検索します。
      3. リストから [新規作成] タイトルをクリックします。
        ServiceNow には多くの新規作成モジュールがあります。[アプリケーションメニュー] でフィルターを適用して、適切なものを選択します。

    質問:このテストで、テストステップ「新しいフォームを開く」ではなく「モジュールに移動」を使用するのはなぜですか?

    回答:「モジュールに移動」テストステップでは、テストユーザーが選択したモジュールにアクセスできるかどうかを検証できるためです。この演習では、テストステップを使用して、NeedIt アプリケーションの [新規作成] モジュールを開きます。これにより、「新しいフォームを開く」テストステップと同じフォームが開きますが、それに加えてモジュール検証が行われます。

    1. [送信] ボタンをクリックします。
  3. フィールド値の検証」テストステップを追加します。

    1. [テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。
    2. [テストステップを追加] ダイアログで、[フォーム] カテゴリを選択してから、[フィールド値の検証] テストステップを選択します。
    3. [次へ] ボタンをクリックします。
    4. フィールド値の検証」テストステップの条件を設定します。ヒント:[データピルピッカー] ボタン (代理操作ステップからの出力変数を条件の入力として使用します。) を使用して、「代理操作」テストステップ出力変数を条件の入力として使用します。
        [要求先] [次の値に等しい] [(ステップ 1:代理操作 ➔ ユーザー)]
    5. [AND] ボタンをクリックしてから、「フィールド値の検証」テストステップの 2 番目の条件を設定します。
      1. [要求先メールアドレス (Requested for email)] [次の値に等しい] [(ステップ 1:代理操作 ➔ ユーザー ➔ メール)]
        [要求先] および [要求先メールアドレス (Requested for email)] フィールド値をテストする
    6. [送信] ボタンをクリックします。

「NeedIt Set Requested for とメール」テストを実行する

前の演習で習得したスキルを使用して、「NeedIt Set Requested for とメール」テストを実行します。3 つのテストステップがすべて正常に完了するはずです。

「NeedIt Set Requested for とメール」テストを NeedIt アプリのテストスイートに追加する

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [スイート] を開きます。
  2. NeedIt アプリ (NeedIt App) のテストスイートを編集用に開きます。
  3. NeedIt Set Requested for とメール」テストを NeedIt アプリ (NeedIt App) のスイートに追加します。
    1. [テストスイートテスト] 関連リストで、[新規行を挿入...] をダブルクリックします。
    2. 検索フィールドに「NeedIt」と入力し、リストから [NeedIt Set Requested for とメール] テストを選択します。
    3. [保存 (Enter)] ボタン ([保存 (Enter)] ボタンは [検索] フィールドの右側にあります) をクリックします。
      「NeedIt Set Requested for とメール」テストをスイートに追加する

質問NeedIt アプリ (NeedIt App) テストスイートの正しい階層を示しているのはどの図でしょうか?

A、B、C、または D を選択


回答:正解は B です。「NeedIt Set Requested for とメール」テストは、NeedIt アプリスイートに直接接続されます。[必要な場合] フィールド NeedIt アプリの子スイートも、NeedIt アプリ (NeedIt App) スイートに直接接続されます。

NeedIt アプリのテストスイートの実行

  1. NeedIt アプリ (NeedIt App) テストスイートレコードで、[テストスイートの実行] ボタンをクリックします。

  2. [ブラウザーを選択] ダイアログで、新しいクライアントテストランナーを開始するか、既存のランナーが存在する場合はそれを選択します。

  3. [テストスイートを実行] ボタンをクリックします。

  4. クライアントテストランナーで、スイートのテスト実行状況を確認します。テストはすぐに行われる可能性がありますが、次の点に注意してください。

    1. 実行中のテスト
    2. テスト対象
    3. フォームの送信によって発生したエラーメッセージ
  5. テストが完了したら、テストスイートの実行に使用したウィンドウに戻ります。

  6. [テストスイートの実行] ダイアログを確認します。「NeedIt Set Requested for とメール」テストが成功しているはずです。

    予想されるスイートの結果は、テストに合格し、子スイートが不合格になることです。

  7. [結果に移動] ボタンをクリックします。

  8. [テスト結果][子テストスイート結果]、および [すべてのテストスイート結果] を調べて、どのような情報が含まれているかを確認します。

記事 (28/40)

パラメーター化されたテスト

実行ごとに異なるテストデータで、パラメーター化されたテストを複数回実行します。

パラメーター化されたテストでは:

  • テストデータを変更するためにテストステップを複製する必要がなくなります。
  • テストアクションをテストデータから分離することでテストの再利用を拡大します。
  • データセットごとに個別のテスト結果を生成します。

パラメーター化されたテストが実行されると、Automated Test Framework はパラメーターをデータセット値で置き換えます。たとえば、開発者はインシデントレコードを作成して検証するテストを作成できます。パラメーターを使用して、テストをデータセットの各行を基に複数回実行し、結果が予想と一致するかを検証します。カテゴリ[ハードウェア] の場合、テストでは [アサイン先グループ][ハードウェアサポート] に設定されているかを検証します。カテゴリ[問い合わせ/ヘルプ] の場合、テストでは [アサイン先グループ][トリアージ] に設定されているかを検証します。

パラメーター化されたテストでは、データセットからのデータを使用して、異なるデータでテストを複数回実行します。

記事 (29/40)

パラメーター化されたテストの作成

パラメーター化されたテストを作成するには、テストフォームで [パラメーター化されたテストの有効化] オプションを選択します。[パラメーター化されたテストの有効化] オプションを選択すると、[パラメーター定義][テスト実行データセット]、および [パラメーター化されたテスト結果] の関連リストが表示されます。

パラメーター化を設定する前に、[他のアクション] メニュー (レコードを保存してフォームで操作を続行する) をクリックし、[保存] メニューアイテムを選択します。

パラメーターの作成

パラメーターは、開発者がテストステップでデータセットからテストステップに値を渡すために使用できる変数です。パラメーターは共有または排他にすることができます。

  • 共有パラメーター:任意のパラメーター化されたテストで使用可能なパラメーターです。共有パラメーターは、グローバルアプリケーションスコープ内でのみ作成できます。
  • 排他パラメーター:現在のテストでのみ使用可能なパラメーターです。

共有パラメーターの作成

複数のテストで使用される変数の共有パラメーターを作成します。たとえば、複数のテストを異なるユーザーとしてテストする必要がある場合があります。共有パラメーターを作成して変数を一度作成してから、パラメーター化されたテストでその変数を使用します。

[パラメーター定義] 関連リストで、[共有パラメーターを追加] ボタンをクリックします。[共有パラメーターを追加] ボタンが使用できない場合は、現在のアプリケーションスコープがグローバルではありません。注釈により、共有パラメーターはグローバルアプリケーションスコープでのみ作成できることがユーザーに通知されます。

注釈には次のように表示されます。「現在 NeedIt のアプリケーションを選択していますが、グローバルアプリケーションの共有パラメーターのみを追加できます。新しい共有パラメーターを追加する場合は、グローバルに切り替えます。」

注釈の [新しい共有パラメーターを追加する場合は、グローバルに切り替えます] リンクをクリックするか、アプリケーションピッカーを使用してグローバルアプリケーションスコープに切り替えます。

共有パラメーターを設定します。設定オプションは、作成されたパラメーターのタイプによって異なります。

[タイプ] が [文字列] に設定され、[列ラベル] が [ユーザー] に設定され、[列名] が [u_user] に設定され、[最大長] が [80] に設定された共有パラメーター。

  • タイプ:パラメーターのデータ型です。
  • 列ラベル:データセットを作成するとき、またはテストステップで変数を選択するときに表示されるラベルです。
  • 列名:スクリプト内や ATF で、変数にアクセスするために使用される名前です。この値は [列ラベル] に基づいて自動的に設定されますが、パラメーターを送信する前に変更できます。列名は、すべてのパラメーターで一意である必要があります。

排他パラメーターの作成

アプリケーションスコープを、スコープ対象のアプリケーションに設定します。[パラメーター定義] 関連リストで、[排他パラメーターを追加] ボタンをクリックします。排他パラメーターを設定します。設定オプションは、作成されたパラメーターのタイプによって異なります。

[タイプ] が [選択肢] に設定され、[列ラベル] が [カテゴリ] に設定され、[列名] が [u_category] に設定された排他パラメーター。

データセットの作成

データセットは、テストの実行時に使用されるランタイムデータです。データセット内の各レコードは、パラメーター値セットと呼ばれます。各パラメーター値セットに対してテストが実行されます。[テスト実行データセット] 関連リストを使用して、パラメーター化されたテストで使用するデータを設定します。

[新規] ボタンを使用してデータセットレコードを作成するか、[インポート] ボタンを使用して複数のデータセットレコードを一度に作成します。

3 つのパラメーター値セットを含む [テスト実行データセット] 関連リスト。

データセットレコードの作成

[テスト実行データセット] 関連リストで、[新規] ボタンをクリックします。[新規パラメーター値の設定] ダイアログで、テストで使用するすべてのパラメーターの値を設定します。すべての共有パラメーターと排他パラメーターは、パラメーター値セットで設定できます。

[カタログ] パラメーターが [ハードウェア] に設定され、[アサイン先グループ] パラメーターが [Hardware Support] に設定された [新規パラメーター値セット] ダイアログ。

データセット内のパラメーター値セットごとにこのプロセスを繰り返します。

データセットのインポート

[テスト実行データセット] 関連リストで、[インポート] ボタンをクリックします。[テスト実行データセットのインポート] ダイアログで、インポートの設定を行います。

[カタログ] パラメーターが [ハードウェア] に設定され、[アサイン先グループ] パラメーターが [Hardware Support] に設定された [新規パラメーター値セット] ダイアログ。

インポート動作を設定します。インポートされた値は、既存のデータセットにパラメーター値セットを追加したり、既存のパラメーター値セットを新しいデータで置き換えたりするのに使用できます。

[Excel テンプレートをダウンロード] ボタンをクリックしてスプレッドシートをダウンロードし、インポートする値セットを入力します。[ファイルを選択] ボタンをクリックして、インポートする入力済みスプレッドシートを選択します。[アップロード] ボタンをクリックして、データセットをインポートします。

データの適用

入力としてパラメーターを受け入れるテストステップフィールドには、[データピルピッカー] ボタンがあります。

パラメーターを受け入れるフィールドには、[参照を挿入] ボタンがあります

[データピルピッカー] ボタンにより、入力変数で使用できるパラメーターを含むステップのリストが開きます。前のテストステップからの出力変数もリストに含まれる場合があります。[パラメーター] をクリックして、テストに使用できるパラメーターのリストを開きます。

選択するパラメーターのリストが表示されます。

右側の列で出力変数をクリックして、入力変数に挿入します。

パラメーターは、入力変数を入力するために使用されます。

演習 (30/40)

演習:パラメーター化されたテストを作成する

NeedIt アプリケーションには、x_58872_needit.needit_userx_58872_needit.admin の 2 つのロールがあります。いずれかのロールを持つユーザーは、NeedIt レコードを作成できます。

この演習では、パラメーター化されたテストを作成して、各ロールを持つユーザーが [NeedIt] > [新規作成] モジュールを開けること、およびこのロールを持つユーザーにフィールドが表示され、NeedIt レコードを作成できることを検証します。

パラメーター化されたテストを有効にしてテストを作成する

テストでパラメーター化されたテストを有効にして、パラメーターとデータセットを作成します。

  1. 現在のアプリケーションスコープが NeedIt であることを確認します。
  2. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。
  3. [新規] ボタンをクリックします。
  4. テスト構成を更新します。
      名前 NeedIt モジュールの作成 (Create NeedIt Module)
      パラメーター化されたテストの有効化 選択済み (オン)
      説明 さまざまな NeedIt ロールを持つユーザーがモジュールとフォームにアクセスして、NeedIt レコードを作成できることを確認するパラメーター化されたテスト。
  5. [保存] ボタンをクリックします。

パラメーターを作成する

ユーザーの作成」ステップには、新しいユーザーに適用する、およびロールが必要です。演習のこのセクションでは、これらの各フィールドのパラメーターを作成します。

質問[パラメーター定義] 関連リストで [共有のパラメーターを追加] ボタンを使用できますか?なぜですか、それともなぜそうではそうではないのですか?

回答:選択したアプリケーションスコープが NeedIt であるため、[共有のパラメーターを追加] ボタンは使用できません。[共有のパラメーターを追加] ボタンは、グローバルアプリケーションスコープでのみ使用できます。

  1. [パラメーター定義] 関連リストで、[排他パラメーターを追加] ボタンをクリックします。
  2. [名] パラメーターを設定します。
      タイプ 文字列
      ラベル
      列名 (この値は自動的に入力されます)
      最大長 40
  3. [送信] ボタンをクリックします。
  4. [排他パラメーターを追加] ボタンをクリックします。
  5. [姓] パラメーターを設定します。
      タイプ 文字列
      ラベル
      列名 (この値は自動的に入力されます)
      最大長 40
  6. [送信] ボタンをクリックします。
  7. [排他パラメーターを追加] ボタンをクリックします。
  8. [ロール] パラメーターを設定します。
      タイプ 参照
      ラベル ロール
      列名 (この値は自動的に入力されます)
      参照 ロール
  9. [送信] ボタンをクリックします。

名、姓、ロールの各パラメーターが定義されている [パラメーター定義] 関連リスト。

データセットを作成する

演習のこのセクションでは、テスト時に使用するパラメーターのデータセットを作成します。テストする NeedIt アプリケーションの各ロールにつき、1 つのレコードを作成します。

  1. [テスト実行データセット] 関連リストで、[新規] ボタンをクリックします。
  2. 新しいパラメーター値セットを構成します。
      NeedIt
      User
      ロール x_58872_needit.needit_user
  3. [送信] ボタンをクリックします。
  4. 2 番目のパラメーター値セットを作成します。
      NeedIt
      Admin
      ロール x_58872_needit.admin

NeedIt ユーザー用と NeedIt 管理者用のパラメーター値セットを含む [テスト実行データセット] 関連リスト。

テストステップを作成する

パラメーター化されたテストを使用するための最後のステップでは、パラメーターを使用するテストステップを設定します。演習のこのセクションでは、「ユーザーの作成」、「モジュールに移動」、「フィールドステータスの検証」の各テストステップをテストに追加します。「ユーザーの作成」テストステップでは、パラメーター値を使用します。

  1. [テストステップ] 関連リストに切り替えます。

  2. [テストステップ] 関連リストで、[テストステップを追加] ボタンをクリックします。

  3. [テストステップの追加] ダイアログで、[サーバー] カテゴリを選択してから、[ユーザーの作成] テストステップを選択します。

  4. [次へ] ボタンをクリックします。

  5. ユーザーの作成」テストステップを設定します。

      (パラメーター➔名)
      (パラメーター➔姓)
      ロール (パラメーター➔ロール)

    [名]、[姓]、および [ロール] フィールド用に指定されたデータピルが設定されている、「ユーザーの作成」テストステップの変数セクション。

  6. [送信] ボタンをクリックします。

  7. [モジュールに移動] テストステップを追加して、新しい NeedIt フォームを開きます。

    1. [テストステップを追加] ボタンをクリックします。

    2. [テストステップの追加] ダイアログで、[Application Navigator] カテゴリを選択してから、[モジュールに移動] テストステップを選択します。

    3. [次へ] ボタンをクリックします。

    4. モジュールに移動」テストステップを設定します。

      1. [モジュール] フィールドの [リストから参照] ボタン ([リストから参照] ボタンは、[モジュール] フィールドの右側にあります。) をクリックします。
      2. [アプリケーションメニュー] で needit が含まれている (*needit) モジュールを検索します。
      3. リストで [新規作成] タイトルをクリックします。
        ServiceNow には多くの新規作成モジュールがあります。[アプリケーションメニュー] でフィルターを適用して、適切なものを選択します。
    5. [送信] ボタンをクリックします。

  8. 新しい NeedIt フォームのフィールドを検証するための「フィールドステータスの検証」テストステップを追加します。

    1. [テストステップを追加] ボタンをクリックします。

    2. [テストステップを追加] ダイアログで、[フォーム] カテゴリを選択してから、[フィールドステータスの検証] テストステップを選択します。

    3. [次へ] ボタンをクリックします。

    4. フィールドステータスの検証」テストステップを設定します。

      1. 表示フィールドを確認します。

        1. [表示のロック解除 (Unlock Visible)] ボタンをクリックします。

        [表示のロック解除 (Unlock Visible)] ボタン。

        1. [利用可能] スラッシュバケットで、[番号] を選択します。
        2. [アイテムを追加] ボタンをクリックして、[番号][選択済み] スラッシュバケットに移動します。
        3. このプロセスを繰り返して、他のフィールドの可視性を確認します。
            優先度
            ステータス
            簡単な説明
            説明
      2. 必須フィールドを確認します。

        1. [必須のロックを解除 (Unlock Mandatory)] ボタンをクリックします。

        2. 選択済みスラッシュバケットにフィールドを追加して、必須フラグを確認します。

            要求元
            要求先メールアドレス (Requested for email)
            要求タイプ
            必要なもの (What needed)
            必要な場合

          完了した「フィールドステータスの検証」テストステップ。

    5. [送信] ボタンをクリックします。

テスト

両方のユーザーについてのテストが正常に完了したかを検証します。

  1. [テスト実行] ボタンをクリックします。
  2. [ブラウザーを選択] ダイアログで、新しいテストランナーを開始するか、既存のランナーが開いている場合はそれを選択します。
  3. [テスト実行] ボタンをクリックします。
  4. テストステップの実行中にクライアントテストランナーを監視します。テストステップが終了し、クライアントテストランナーで「テストの実行を待機しています」と表示されたら、「NeedIt モジュールの作成 (Create NeedIt Module)」テストが開かれているブラウザータブに戻ります。
  5. [テストを実行] ダイアログを確認します。テストは成功しているはずです。
  6. [結果に移動] ボタンをクリックします。
  7. [テスト結果] 関連リストを確認します。リスト内の各レコードは、異なる値セットで実行されたテストであることに注意してください。

課題

パラメーター化されたテストを NeedIt アプリ (NeedIt App) テストスイートに追加します。テストスイートをテストして、すべてのテストが正常に完了したかを検証します。

課題ソリューション

テストを NeedIt アプリ (NeedIt App) テストスイートに追加するには、[NeedIt アプリ (NeedIt App)] テストスイートを開きます。[NeedIt モジュールの作成 (Create NeedIt Module)] テストを [テストスイートテスト] 関連リストに追加します。

これで、[テストスイートテスト] 関連リストに、「NeedIt Set Requested for とメール」と「NeedIt モジュールの作成」の 2 つのテストが含まれるようになります。

さらにテストを構築してアクセスを検証する場合は、スイート内でアクセステストをグループ化することをお勧めします。

記事 (31/40)

Scheduling

ATF 開発者は、テストスイートを特定の日時に実行するようにスケジュールできます。スケジュール済みのテストスイートの実行が終了すると、指定されたユーザーに通知されます。

テストスイートの実行をスケジュールするための一般的な手順は、次のとおりです。

  1. スケジュールを作成します。
    1. 頻度を設定します。
    2. 時間を設定します。
  2. テストスイートをスケジュールに割り当てます。
    1. ユーザーをウォッチリストに追加します。
    2. テストスイートにクライアント側テストが含まれている場合:
      1. クライアントテストランナーのブラウザーとブラウザーのバージョンを選択します。
      2. クライアントテストランナーの OS と OS のバージョンを選択します。
  3. スケジュール済みのテストスイートにクライアントテストステップが含まれている場合は、スケジュール済みのクライアントテストランナーを作成します。
    スケジュール済みのテストが完了するとメールが送信される

記事 (32/40)

スケジュールの作成

スケジュールを作成するには、[Automated Test Framework (ATF)] > [スケジュール] を開き、[新規] ボタンをクリックします。

新規スケジュールを設定します。この例では、名前は「デモスケジュール」です。[実行] フィールドの値は [日次] です。

  • 名前:スケジュールのわかりやすい名前です。
  • アクティブ:ServiceNow スケジューラーにスケジュールを追加する場合に選択します。選択しない場合、スケジュールは実行されません。
  • 実行:スケジュールを実行する頻度を選択します。選択肢には、[日次][週次][月次][定期的][1 回][オンデマンド][ビジネスカレンダー:エントリ開始]、または [ビジネスカレンダー:エントリ終了] があります。
  • 時刻、日、開始、繰り返し間隔、日数、時間:これらのフィールドは、フォームの特定の [実行] フィールド値にのみ対応しており、スケジュールをいつ実行するかを指定するために使用されます。
  • 条件節[条件] スクリプトフィールドを表示する場合に選択します。
  • 条件:テストスイートのスケジュールを設定どおりに実行するかどうかを決定するサーバー側スクリプトです。

条件スクリプト

条件スクリプトは、ATF スケジュールではオプションです。条件スクリプトは、スケジュールされた時間が満たされたときに評価されます。条件スクリプトの最後の行は、true または false と評価する必要があります ( true または false を返すのではなく、true または false と評価します)。条件スクリプトが false と評価された場合、スケジュール内のテストスイートは実行されません。サンプルスクリプトでは、ATF スケジュールは午後 7:00 に実行されるように設定された日次スケジュールです。条件スクリプトにより、スケジュールが日次スケジュールであっても、週末にはテストスイートが実行されないようになっています。

条件スクリプトは true または false と評価

開発者向けのヒント[今すぐ実行] ボタンを使用してスケジュールをテストする場合、条件スクリプトは評価されません。

テストスイートを追加

テストスイートをスケジュールに追加するには、[スイートのスケジュール (Schedule Suites)] 関連リストまでスクロールし、[新規] ボタンをクリックします。スケジュール済みのスイート実行レコードを設定します。

テストスイート、クライアントテストランナー (該当する場合)、OS (該当する場合)、およびウォッチリストを選択します。この例では、テストスイート:自分のデモテストスイート、スケジュール:デモスケジュール、ウォッチリスト:admin@servicenow.com

  • 実行順序:スケジュール上のスイート実行の順序。このフィールドが空の場合、ServiceNow はスケジュールに追加された順にスイートを実行します。
  • テストスイート:スケジュールに追加する ATF テストスイートです。
  • ウォッチリスト:スケジュールが完了したときにメール通知を受信するユーザーのリストです。
  • ブラウザー名:テストスイートに UI (クライアント側) テストステップがある場合は、実行するステップのブラウザーを選択します。ブラウザーには、スイートの実行時に使用する、実行中のスケジュール済みクライアントテストランナーが必要です。[任意] に設定すると、ATF は利用可能なスケジュール済みクライアントテストランナーを使用します。このブラウザーのバージョンで利用できるスケジュール済みクライアントテストランナーがない場合、ATF はスイートを実行しません。
  • 次で始まるブラウザーバージョン:テストスイートに UI (クライアント側) テストステップがある場合、スケジュール済みクライアントテストランナーは、この OS で実行する必要があります。[任意] に設定すると、ATF は利用可能なスケジュール済みクライアントテストランナーを使用します。この OS で利用できるクライアントテストランナーがない場合、ATF はスイートを実行しません。
  • OS 名:テストスイートに UI コンポーネントが含まれている場合、スケジュール済みクライアントテストランナーは、この OS で実行する必要があります。この OS で利用できるクライアントテストランナーがない場合、ATF はスイートを実行しません。
  • 次で始まる OS バージョン:テストスイートに UI コンポーネントが含まれている場合、スケジュール済みクライアントテストランナーの OS のバージョンは、この文字列で始まる必要があります。この OS バージョンで利用できるクライアントテストランナーがない場合、ATF はスイートを実行しません。

開発者向けのヒント:1 つのスケジュールで複数のブラウザー/ブラウザーバージョン/OS/OS バージョンで同じスイートをテストできるように、テストスイートをスケジュールに複数回表示することができます。

ATF は複数のブラウザーと OS をテストできます。

記事 (33/40)

スケジュール済みのクライアントテストランナー

ATF は、スケジュール済みのクライアントテストランナーを使用して、クライアント側のテストステップを含むテストスイートが組み込まれているスケジュールを実行します。スケジュール済みのクライアントテストランナーは、スケジュール済みのテストスイートのみを実行します。

スケジュール済みのクライアントテストランナーを作成するには、[Automated Test Framework (ATF)] > [実行] > [スケジュール済みのクライアントテストランナー] を開きます。スケジュールのテストスイートを実行するすべてのブラウザー/ブラウザーバージョン/OS/OS バージョンで、この手順を繰り返します。

スケジュール済みのクライアントテストランナーは、手動で開始したテストやテストスイートを実行しません。

ATF 管理者は、[Automated Test Framework (ATF)] > [実行] >[スケジュール済みのアクティブなテストランナー] モジュールを使用して、実行中のスケジュール済みテストランナーを表示できます。

スケジュール済みのテストスイートに指定されたブラウザー/ブラウザーバージョン/OS/OS バージョンが利用できない場合、ATF はそのテストスイートをスキップします。

ブラウザー/ブラウザーバージョン/OS /OS バージョンは、スケジュール済みのクライアントテストランナーで利用可能であること

記事 (34/40)

スケジュール済みテスト通知

スケジュール済みテストスイートが実行されると、スケジュール済みのスイート実行レコードの [ウォッチリスト] にあるユーザーとメールアドレスは、テストスイート結果レポートをメールで受信します。

ウォッチリストのユーザーとメールアドレスがメールでレポートを受信

テストスイート結果

テストスイート結果メールは、スケジュール、スイート、およびテストレベルでの実行結果を示すクリック可能なレポートです。

テストスイート結果メールはクリック可能

ATF 管理者は、[Automated Test Framework (ATF)] > [管理] > [プロパティ] モジュールを使用してメールのプロパティを変更できます。構成可能なオプションは次のとおりです。

  • 合格したテストの結果を表示するかどうか (デフォルトでは、不合格になったテスト結果のみ表示)
  • 表示するテスト結果の最大数 (デフォルトは 10)
  • スイートの結果を印刷するときの最大深度 (デフォルトは 20)
  • 結果を示す色:不合格、エラー、合格、スキップ、キャンセル

ウォッチリスト

ウォッチリストを編集するには、[ウォッチリストのロック解除 (Unlock Watch list)] ボタン (ウォッチリストのロックを解除して編集する) をクリックします。

ユーザーまたはメールアドレスをウォッチリストに追加

演習 (35/40)

演習:メール送信を有効にする

ATF で通知を送信するには、個人開発者インスタンス (PDI) でメール送信を有効にする必要があります。PDI のデフォルトでは、メール送信は無効になっています。通常、メールの有効化は ServiceNow 管理者の担当であり、ATF 開発者の担当ではありません。この演習では、メール送信を有効化します。

注意:開発者サイトの「通知」モジュールで作業したことがある場合は、既にメール送信が有効になっている可能性があります。

メール送信の有効化

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [システム診断] > [メール診断] を開きます。メール送信が非稼働中であるかを検証します。
    メールの送信は無効です
  2. [グローバル] スコープに切り替えます。
    1. ServiceNow バナーにアプリケーションピッカーを追加した場合は、アプリケーションピッカーを使用してスコープをグローバルに変更します。
      アプリケーションピッカーを使用してスコープをグローバルに設定する
    2. ServiceNow バナーにアプリケーションピッカーを追加していない場合:
      1. ServiceNow バナーの [設定] ボタン ([設定] ボタンは、ServiceNow バナーの右端のボタンです) をクリックします。
      2. [開発者] ペインを選択し、[アプリケーション] フィールドを使用してスコープを [グローバル] に変更します。
      3. ServiceNow バナーにアプリケーションピッカーを追加するには、[ヘッダーにアプリケーションピッカーを表示] オプションを有効にします (オプション)。
      4. [システム設定] ダイアログを閉じます。
        [システム設定] で [アプリケーション] フィールドの値を [グローバル] に設定
  3. メール送信を有効にします。
    1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [システムのプロパティ] > [メールプロパティ] を開きます。

    2. [送信メール設定] 列で、[メール送信の有効化] を選択します。

      [はい/いいえ] ボックスをオンにして、メール送信を有効にします。

    3. [保存] ボタンをクリックして、設定の変更を保存します。

  4. 情報メッセージの [メール診断] リンクをクリックして、[メール診断] ページを開きます。
    情報メッセージ内のメール診断リンク
  5. メール送信が稼働中であることを検証します。
    メール送信は稼働中です
  6. スコープを [NeedIt] に戻します。
    スコープを [NeedIt] に戻す

演習 (36/40)

演習:スケジュールを作成して実行する

この演習では、毎月 1 日に実行されるスイートスケジュールを作成して実行します。

準備

スイートで不合格になったテストを含めて、不合格テストが結果にどのように表示されるかを確認します。

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [テスト] を開きます。
  2. NeedIt Set Requested for とメール」テストを編集用に開きます。
  3. [テストをコピー] ボタンをクリックします。
  4. テストの名前を「NeedIt 不合格テスト」に変更します。
  5. [他のアクション] メニュー (レコードを保存してフォームで操作を続行する) をクリックし、[保存] メニューアイテムを選択して、レコードを保存します。
  6. フィールド値の検証」テストステップを更新して、テストの不合格を確認します。たとえば、条件 [要求先メールアドレス (Requested for email)] [次の値に等しい] [(ステップ 1:代理操作 ➔ ユーザー ➔ メール)][要求先メールアドレス (Requested for email)] [次の値と異なる] [(ステップ 1:代理操作 ➔ ユーザー ➔ メール)] に変更します。
  7. [更新] ボタンをクリックします。
  8. NeedIt 不合格テスト」テストを NeedIt アプリ (NeedIt App) テストスイートに追加します。

スイートスケジュールを作成する

  1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [Automated Test Framework (ATF)] > [スケジュール] を開きます。
  2. [新規] ボタンをクリックします。
  3. スイートスケジュールを設定します。
      名前 NeedIt アプリスイート (NeedIt App Suites)
      アクティブ選択済み (オン)
      実行 毎月
      日付 1
      時間 [時間] [02] [00] [00]
  4. [保存] ボタンをクリックします。

スケジュール済みスイートを追加

  1. [スケジュール済みのスイート] 関連リストまでスクロールし、[新規] ボタンをクリックします。
  2. 新しいスケジュール済みのスイート実行レコードを設定します。
      テストスイート NeedIt アプリ (NeedIt App)
      ブラウザー名 任意
      OS 名 任意
  3. メールアドレスを ウォッチリストに追加します。
    1. [ウォッチリストのロック解除 (Unlock Watch list)] ボタン ([ウォッチリストのロック解除 (Unlock Watch list)] ボタン) をクリックします。
    2. 個人または仕事用のメールアドレスを [メールアドレスの入力] フィールドに入力します。
    3. [メールアドレスを追加] ボタン (メールアドレスをウォッチリストに追加する) をクリックします。
  4. [送信] ボタンをクリックします。

NeedIt アプリスイートスケジュールを実行する

  1. [今すぐ実行] ボタンをクリックして、スケジュールスイートを実行します。
  2. [スケジュール済みのスイートを実行] 結果ダイアログを調べて、スケジュールが実行されなかった理由を特定します。

質問:スケジュールが実行されなかったのはなぜですか?

回答:クライアント側 (UI) テストステップを含むスケジュールを実行するには、スケジュール済みのクライアントテストランナーが必要なためです。現在、アクティブなクライアントテストランナーは存在しません。

スケジュール済みのクライアントテストランナーが存在しません

スケジュール済みのクライアントテストランナーを起動して再実行する

  1. Application Navigator で、[Automated Test Framework (ATF)] > [実行] > [スケジュール済みのクライアントテストランナー] を右クリックし、[新しいタブでリンクを開く (Open Link in New Tab)] メニューアイテム (またはブラウザーの「リンクを新しいタブで開く」メニューアイテム) を選択します。
  2. NeedIt アプリスイート (NeedIt App Suites) のスケジュールで、[今すぐ実行] ボタンをクリックします。
  3. スケジュール済みのクライアントテストランナーが実行されているブラウザータブに切り替えます。実行中の NeedIt アプリスイート (NeedIt App Suites) スケジュールのテストステップが表示されるはずです。
  4. スケジュールの実行が完了したら、[スケジュールスイートの実行 (Run Schedule Suites)] ダイアログを調べて結果を確認します。

テストスイートの結果メールを調べる

  1. メールアプリケーションで、スケジュールによって送信された「NeedIt アプリのテストスイート結果」メールを開きます。メールが届くまで 1、2 分待つ必要があるかもしれません。メールが届かない場合は、スパムフォルダーを確認してください。
  2. メールの内容を確認してください。調査したいリンクのいずれかをクリックします。

質問NeedIt 不合格テストの結果のみがメールに含まれるのはなぜですか?

回答:デフォルトでは、不合格のテスト結果のみがメールに表示されます。メール内のすべてのテスト結果を表示するには、[Automated Test Framework (ATF)] > [管理] > [プロパティ] を開き、[スケジュール済みのスイート結果の電子メールに表示される結果のブール値] プロパティの選択を解除 (オフ) します。

プロパティの選択を解除する

別のブラウザーでスケジュールを実行する

  1. それでも開かない場合は、NeedIt アプリスイート (NeedIt App Suites) のスケジュールを開いて編集します。

  2. [スケジュールスイート] 関連リストで、NeedIt アプリ (NeedIt App) テストスイートの [プレビュー] ボタン (NeedIt アプリの左側にある [プレビュー] ボタンをクリックします) をクリックします。

    プレビューを開く

  3. [レコードを開く] ボタンをクリックします。

  4. テストに使用していたものとは異なるブラウザーや OS を使用するように [クライアントの制約] を設定します。自分が使用可能なブラウザーや OS に応じて値を設定します。たとえば、Chrome で作業している場合は、ブラウザーを Firefox に設定します。ブラウザーを変更したら、[更新] ボタンをクリックします。

  5. [クライアントの制約] で設定した OS のブラウザーに移動します。

  6. 新しいブラウザーで、admin ユーザーとして個人開発者インスタンスにログインします。

  7. Application Navigator で、[Automated Test Framework (ATF)] > [実行] > [スケジュール済みのクライアントテストランナー] を開き、スケジュール済みのクライアントテストランナーを開きます。

  8. 開発作業を行っていたブラウザーに戻り、NeedIt アプリスイート (NeedIt App Suites) のスケジュールを実行します。

  9. 2 番目のブラウザーに移動し、スケジュール済みのクライアントテストランナーでスケジュールが実行されるのを確認します。

  10. スケジュールが完了したら、メールを調べて、スケジュールの結果が予想どおりであるかを確認します。

  11. 開発作業を行っていたブラウザーに戻り、Application Navigator を使用して [Automated Test Framework (ATF)] > [実行] > [スケジュール済みのアクティブなテストランナー] を開きます。

  12. スケジュール済みのクライアントテストランナーのレコードを 2 番目のブラウザーで開きます。

  13. [削除] ボタンをクリックして、2 番目のブラウザーで開かれたスケジュール済みのクライアントテストランナーを終了します。

  14. レコードの削除を確認するメッセージが表示されたら、[削除] ボタンをクリックします。

  15. 2 番目のブラウザーに戻り、スケジュール済みのクライアントテストランナーのステータスが [切断] になっていることを確認します。ブラウザータブを閉じます。

  16. スケジュール済みの他のクライアントテストランナーが実行されている場合は、それも削除します。

スケジュールからメールアドレスを削除する - オプション

NeedIt アプリスイート (NeedIt App Suites) のスケジュールに基づく月次メールを受信したくない場合は、自分のメールアドレスをウォッチリストから削除します。

  1. それでも開かない場合は、NeedIt アプリスイート (NeedIt App Suites) のスケジュールを開いて編集します。
  2. [スケジュールスイート] 関連リストで、NeedIt アプリ (NeedIt App) テストスイートの [プレビュー] ボタン (NeedIt アプリの左側にある [プレビュー] ボタンをクリックします) をクリックします。
  3. [レコードを開く] ボタンをクリックします。
  4. ウォッチリスト[ロック解除] ボタン (ウォッチリストのロックを解除して編集する) をクリックします。
  5. メールアドレスをクリックして選択し、[選択したアイテムを削除] ボタン ([削除] ボタンをクリックします。) をクリックします。
  6. [更新] ボタンをクリックします。

演習 (37/40)

演習:「Automated Test Framework の使用」の作業を保存する (オプション)

開発者は、GitHub のようなソースコントロールアプリケーションを使用して、個人開発者インスタンス (PDI) の外部で変更をコミット (完了した作業を保存) できます。アプリケーションに対する変更内容をコミットして、作業をソースコントロールに保存します。

この演習では、このモジュールで完了した作業を GitHub リポジトリに保存します。

注意:ServiceNow が開発者プログラムの学習コンテンツで GitHub を使用する方法の詳細と、作業を保存する方法に関するビデオを見るには、『GitHub ガイド』を参照してください。

変更をコミット (Commit Changes)

  1. NeedIt アプリケーションが Studio で開かれていない場合は、ここで開きます。

    1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。

    2. [アプリケーションを選択] ダイアログで、このアプリケーションをクリックします。

  2. [ソースコントロール] メニューを開き、[変更をコミット] メニューアイテムを選択します。

    [変更をコミット (Commit Changes)] メニューアイテムを選択

  3. コミットする更新を選択します。

    1. [<アプリケーション> のソースコントロールにコミットするファイルを選択] ダイアログで、[すべての Update Sets] を選択します。
    2. コミットするアプリケーションファイルを確認します。
    3. [続行] ボタンをクリックします。

    ソースコントロールにコミットするファイルを選択

  4. [NeedIt のソースコントロールにコミットするファイルを確認] ダイアログで、「「Automated Test Framework の使用」モジュールが完了しました」などのコミットのコメントを入力します。

  5. [コミットファイル] ボタンをクリックします。

    コミットメッセージを入力

  6. [変更をコミット] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

    変更が正常にコミットされました

    注意:変更のコミットに失敗した場合は、フォークしたリポジトリ URL ではなく ServiceNow のリポジトリ URL を [URL] フィールドに入力している可能性があります。GitHub 接続問題のトラブルシューティング方法については、『GitHub ガイド』の 「GitHub 問題のトラブルシューティング」を参照してください。

記事 (38/40)

Automated Test Framework の知識をテストする

Automated Test Framework (ATF) の理解度を確認しますか?以下の質問は、自分の進捗状況を評価するのに役立ちます。質問ごとに回答を決定し、質問の任意の場所をクリックして回答を表示します。

質問:ATF テストとスイートの実行がデフォルトで無効になっているのはなぜですか?

  1. テストとスイートは、実際のデータを使用する本番インスタンスでのみ実行する必要があります。
  2. テストとスイートは、非本番インスタンスでのみ実行する必要があります。
  3. テストをアクティブにする前に、テストとスイートを構築する必要があります。
  4. テストには HB の鉛筆で回答する必要があります。
  5. テストとスイートは、本番環境に移行する前の非本番インスタンスでテストする必要があります。


回答:正解は 2 です。ATF ロールバックステップがテスト中に実行されたとしても、テストはデータに影響を与える可能性があります。テストとスイートは、非本番インスタンスでのみ実行し、本番環境では決して実行しないでください。代わりに、テストのために本番インスタンスを非本番インスタンスにクローンする必要があります。


質問:別のユーザーとしてテストを実行するにはどうすればよいですか?複数の回答が正解の場合があります。

  1. ユーザーの作成」テストステップを使用します。
  2. ユーザーの作成と代理操作」テストステップを使用します。
  3. テストを実行する前に、ユーザーの代理操作を行います。
  4. テストを実行する前に、ユーザーとしてログインします。
  5. 代理操作」テストステップを使用します。


回答:正解は 15 です。「ユーザーの作成」と「代理操作」のテストステップを使用すると、テストのために別のユーザーの代理操作を行うことができます。「ユーザーの作成」テストステップでは、必ずこのユーザーの代理操作を行うようにステップを設定してください。「ユーザーの作成と代理操作」テストステップは存在しません。ユーザーが ATF テストを実行する権限を持っていない場合があるため、テストを実行する前にユーザーの代理操作を行ったり、ユーザーとしてログインしたりしても機能しません。


質問:テストでテストステップを順序付ける方法を説明しているのは次のうちどれですか?複数の回答が正解の場合があります。

  1. [テストステップ] 関連リストで [順序] フィールドを設定します。
  2. ステップを実行順序にドラッグアンドドロップします。
  3. ステップをテストに追加するときにステップを挿入する場所を選択します。
  4. [テストステップ] 関連リストで [実行順序] フィールドを設定します。
  5. ステップは、実行順に作成する必要があります。


回答:正解は 34 です。ステップをテストに追加するときに、[テストステップを追加] ダイアログの [次の後に挿入] 選択リストを使用して、新しいテストステップを挿入する場所を選択します。または、[実行順序] の値を変更してステップを並べ替えます。

テストステップには [順序] フィールドがありません。ドラッグしてテストステップを並べ替えることができるインターフェイスはありません。テストステップは、作成後に並べ替えることができます。


質問:テストの、あるステップのデータを後のステップでどのように使用しますか?

  1. テストステップオブジェクトを開くスクリプトを作成して、後のステップで使用するデータを取得します。
  2. [データ] パネルでステップをクリックし、後のステップで使用するデータを選択します。
  3. テストで変数を作成し、テストの実行時に変数を入力するスクリプトを記述します。
  4. [参照] ボタンをクリックし、テーブルからレコードを選択します。
  5. [データピルピッカー] ボタンをクリックし、データピルピッカーから変数を選択します。


回答:正解は 5 です。出力変数を使用する前のステップを選択できます。データは、インターフェイスでデータピルとして表されます。前のステップのデータにアクセスするためのスクリプトは必要ありません。


質問:テストテンプレートの目的は何ですか?

  1. テストテンプレートは、一般にテストを簡単に作成できるようにするための再利用可能なテストステップのセットです。
  2. テストテンプレートは、トレーニングのナレッジチェックを簡単に作成できるようにするための再利用可能な質問のセットです。
  3. テストテンプレートは、さまざまなデータでテストするために、さまざまな値を指定して実行できる再利用可能なテストです。
  4. テストテンプレートは、複数のテストを単一のジョブとしてまとめて実行するための関連するテストの階層グループです。
  5. テストテンプレートは順序付けられた一連のテストステップであり、ServiceNow でのテストを自動化します。


回答:正解は 1 です。テストテンプレートを使用すると、同様のテストをより迅速かつ簡単に作成できます。

パラメーター化されたテストで、異なるデータを使用して単一のテストを実行します。スイートで、関連するテストをグループ化して、複数のテストを単一の実行としてまとめて実行します。テストが、一連の順序付けられたステップであり、テストを自動化します。


質問:正誤問題?開発者は、レコードの挿入に失敗してもテストステップが成功するように、予想される結果をテストステップからアサートできます。


回答:正解は正しいです。開発者は、想定結果に基づくアサーションを使用してテストステップを設定できます。


質問:次のうち、テストランナーの目的はどれですか?

  1. クライアント側のテストステップを実行する
  2. サーバー側のテストステップを実行する
  3. スケジュールに従ってテストを実行する
  4. 特定のブラウザーでテストを実行する
  5. 異なるデータで実行する


回答:正解は 1 です。テストランナーのフルネームは、クライアントテストランナーです。テストランナーは、テストに含まれるクライアント側のテストステップを実行します。テストランナーは特定のブラウザーで起動できますが、主な目的はクライアント側のテストステップを実行することです。


質問:テストスイートが実行されているときに、開発者が、不合格になったテストのみを再実行するにはどうすればよいですか?複数の回答が正解の場合があります。

  1. 問題を修正し、テストスイート結果レコードの [不合格になったテストを再実行] ボタンをクリックします。
  2. 問題を修正し、テストスイートを再実行します。
  3. 問題を修正し、テストスイート結果レコードから不合格になったテストを開き、[テストを再実行] ボタンをクリックします。
  4. 問題を修正し、[テストスイートの実行] ダイアログで [不合格になったテストを再実行] ボタンをクリックします。
  5. すべてのテストが成功する適切なタイミングでスイートを実行するようにスケジュールします。


回答:正解は 14 です。不合格になったテストの実行方法に関係なく、テストを再実行する前に失敗を修正する必要があります。

問題を修正してテストスイートを再度実行すると、不合格になったテストだけでなく、すべてのテストが実行されます。[テストスイート結果] の個々のテスト結果からテストを再実行することはできません。


質問:開発者は、パラメーター化されたテスト用のテスト実行データセットをどのように作成できますか?複数の回答が正解の場合があります。

  1. テーブルにリンクし、テーブル内のすべてのレコードに対してテストを実行します。
  2. パラメーター値セットを手動で作成します。
  3. データを含むスプレッドシートをインポートします。
  4. データソースへの REST Web サービス呼び出しを作成します。
  5. ランダムデータを生成する JavaScript を作成します。


回答:正解は 23 です。パラメーター値セットは、手動で作成することも、スプレッドシートからインポートすることもできます。インポートプロセスでは、入力するテンプレートスプレッドシートが作成されます。


質問:次のうち、ATF でのスケジューリングについて正しいのはどれですか?複数の回答が正解の場合があります。

  1. スケジューリングでは、テストを特定の日時に実行するようにスケジュールできます。
  2. スケジュールは、特定のブラウザーとブラウザーのバージョンをテストするように設定できます。
  3. スケジュールは、特定のオペレーティングシステムとオペレーティングシステムのバージョンをテストするように設定できます。
  4. スケジュールは、設定された頻度で実行されます。
  5. スケジュールは、完了後にユーザーのウォッチリストに結果を送信します。


回答:正解は 4 です。これは引っ掛け問題です。スケジューリングでは、テストではなく、テストスイートを特定の日時に実行するように設定できます。開発者は、スケジュール自体ではなく、スケジュールに割り当てられたテストスイートでブラウザー、オペレーティングシステム、およびウォッチリストの詳細を設定します。


記事 (39/40)

「Automated Test Framework の使用」モジュールのまとめ

コアコンセプト:

  • Automated Test Framework (ATF) は、インスタンスでテストを実行するための ServiceNow アプリケーション
    • テスト主導型開発
    • 回帰テスト
    • ルーチンインスタンステスト
  • デフォルトでは、ATF はテストとテストスイートの実行が無効になっているため、ATF 管理者により、テストおよびテストスイート実行機能の有効化が必要
  • 本番インスタンスでは絶対に ATF を実行しないこと
  • テストは、設定されたテストステップで構成済み
  • 多くのテストは、テスト中に正しいロールが適用されるように、「代理操作」テストステップで開始
  • クライアント側のテストステップには、クライアントテストランナーが必要
  • 開発者は手動でテストを実行可能
  • あるテストステップからの出力変数を別のテストステップの入力変数として使用可能
  • テストテンプレートは再利用可能なテストステップのセットで、テストをすばやく作成するために使用可能
  • テストスイートは、テストおよびその他のテストスイートの論理的な階層グループ
  • 開発者は手動でテストスイートを実行可能
  • スケジュール済みテストスイートは、指定された頻度で自動的に実行
  • スケジュール済みテストスイートは、ウォッチリストのユーザーにメールでレポートを送信
  • クライアント側のテストステップを含むスケジュールされたテストスイート:
    • スケジュール済みのクライアントテストランナーを必要とする
    • テスト用のブラウザーや OS を割り当てることができる
  • スケジュール済みテストスイートのメールレポートに含まれるクリック可能なリンクにより、テストスイート、テスト、およびテスト結果を参照可能
  • ATF 管理者は、成功したテストを報告するかどうかなど、スケジュール済みテストスイートのメールレポートプロパティを設定可能

記事 (40/40)

「Automated Test Framework の使用」を完了した後の参考資料

お疲れさまでした。「Automated Test Framework の使用」モジュールが完了しました。自動テストへの関心に基づいて、さらに次のことも学んでいただけます。