ATF Test Generatorは、ServiceNowの自動テスト機能であるAutomated Test Framework(ATF)のテストを、インスタンスに入っているデータから自動で作る機能です。単体のテストツールとしてダウンロードするものではなく、ServiceNow Storeの無償アプリ「ATF Test Generator and Cloud Runner」をインスタンスにインストールして使います。同じアプリに、生成したテストをServiceNow側のヘッドレスブラウザで実行するCloud Runnerが入っています。
この記事では、ServiceNow公式ドキュメント(Brazil版とAustralia版)とServiceNow Storeの掲載情報(2026年11月時点)をもとに、次の内容を扱います。ATF本体の基本、生成されるテストの中身、導入前に満たす条件、生成から実行・スケジュールまでの手順、CI/CDパイプラインからCloud Runnerを呼ぶ方法、生成したテストが残らないときの確認点です。画面名やプロパティ名は英語UIの表記に合わせています。
まとめ
- ATF Test Generator and Cloud RunnerはServiceNow製の無償Storeアプリです。2026年11月時点の最新版は3.2.1(2026年8月27日公開)で、Brazil・Australia・Zurich・Yokohamaに対応しています。
- 生成対象はフォーム、サービスカタログのアイテム、レコードプロデューサーの回帰テストです。インスタンスの既存データからテストを組み立て、生成中に成功したテストだけがスイートに残ります。
- アプリの操作には原則adminロールが必要で、ATFの管理ロールであるatf_test_adminでは操作できません。3.1.1(2026年7月)からは、sn_atf_tg.cloud_runner_adminロールがあれば、adminでなくてもCloud Userの設定とテスト生成の開始ができます。
- インストールすると、mTLSを有効化する変更要求(CHG)が自動で起票され、アプリケーションノードがローリング再起動します。オンプレミス環境では使えません。
- Cloud Runnerでスイートを実行すると、テストは並列かつ無作為な順で動きます。同時に使えるCloud Runnerは既定で2つです。CI/CD APIの testsuite/run に run_in_cloud=true を付けると、パイプラインからもCloud Runnerで流せます。
- ATFのテスト実行は、本番での誤実行を防ぐため既定で無効です。生成と実行は開発・テスト用インスタンスで行います。
ATF(Automated Test Framework)の基本とTest Generatorの位置付け
テスト・テストステップ・スイートの関係
ATFは、アップグレードやアプリ開発、更新セットの適用のあとに、インスタンスが以前と同じように動くかを確かめるServiceNow標準の自動テスト機能です。Brazil版の公式解説では、次のレコードで構成されると説明されています。
| 構成要素 | テーブル | 役割 |
|---|---|---|
| Test | sys_atf_test | 検証したい機能ごとのテスト |
| Test step | sys_atf_step | テスト内の1操作と実行順 |
| Step configuration | sys_atf_step_config | ステップの種類と入出力変数 |
| Test suite | sys_atf_test_suite | テストを順に束ねた単位 |
| Test result | sys_atf_test_result | 所要時間・状態・スクリーンショット |
テストが作ったデータと変更は、実行後にロールバックされます。テスト用インスタンスを汚さずに同じテストを繰り返せるのは、この仕組みがあるからです。テスト結果とスイート結果は既定で作成から30日後に削除されます。アップグレード前後の比較に使うなら、保持期間を延ばすか無期限保持を有効にします。
フォームを開く・値を入れるといった画面を伴うステップは、クライアントテストランナーと呼ばれるブラウザのタブで動きます。テストの実行に使えるのはデスクトップのブラウザだけで、タブレットやモバイルのブラウザでは実行できません。
ATFのロールと実行を有効にするプロパティ
ATFのロールは3つあり、プロパティを変更できるかどうかで管理者と設計者を分けています。
| ロール | できること |
|---|---|
| atf_test_admin | テスト・スイートの作成と実行、ATFプロパティの変更 |
| atf_test_designer | テスト・スイートの作成と実行(プロパティは閲覧のみ) |
| atf_ws_designer | RESTステップ用の基本認証プロファイルの設定 |
ATF自体は既定で有効ですが、テストの実行は本番での誤実行を防ぐため既定で無効です。手動実行には sn_atf.runner.enabled を、スケジュールやCI/CD APIからの実行には sn_atf.schedule.enabled を true にします。後者が false のままCI/CD APIを呼ぶと、「Scheduled test/suite execution is disabled.」というエラーが返ります。公式は、データ破損や停止を避けるため開発・テスト用のインスタンスでだけ実行するよう求めています。
ATFで検証できる画面とできない画面
ATFが対応しているのは、クラシックのリストとフォームを含むCore UIです。Next Experienceのうち、UI Builderで作ったページ(リストやフォームのコンポーネントを置いたページを含む)とランディングページは非対応で、公式は今後のリリースで対応予定としています。
一方、Configurable Workspaceのページは、テストステップのカテゴリ「Configurable Workspace」でテストできます。Australia版の手順では、Open Workspace Pageステップでワークスペースを開き、Page Inspectorをコンポーネントにドラッグして、そのコンポーネントの操作と期待値をTest Pageステップとして記録します。ただし、ATF Test Generatorが自動で作るのはクラシックのフォームとカタログのテストです。ワークスペースのテストは手動で作ります。
ATF Test Generator and Cloud Runnerの概要
ATF本体では、テストステップを組み合わせてテストを作るか、Quick Start Testsをコピーして調整します。どちらの方法でも、どの画面をどのデータで確かめるかは人が決めます。この作成の手間と、テストを動かすブラウザを用意する手間をそれぞれ肩代わりするのが、ATF Test Generator and Cloud Runnerです。ServiceNowの基盤全般はServiceNowの機能一覧と価格の解説にまとめています。
| 項目 | 内容(2026年11月時点) |
|---|---|
| 提供元・価格 | ServiceNow/無償(Store表記Free) |
| アプリのスコープ | sn_atf_tg |
| 最新版 | 3.2.1(2026年8月27日公開) |
| 対応ファミリー | Brazil/Australia/Zurich/Yokohama |
| 必要なロール | admin(3.1.1以降は一部を専用ロールで可) |
| 主な依存プラグイン | com.glide.automated_testing_framework ほか |
| 設定するプロパティ | sn_atf.runner.enabled を true |
依存プラグインには、ATF本体のほかにmTLS用のcom.glide.auth.mutual、UI Builder(com.glide.uxbuilder)、Next Experienceの各種UIコンポーネントが並びます。ATFのメニューにある「Auto-generate Tests」は、このアプリが未導入のときだけ表示され、選ぶとStoreのアプリページへ案内されます。Australia版の公式ドキュメントでは、Upgrade Consoleのツールの1つとしても紹介されています。
ATF Test Generator and Cloud Runnerのリリース履歴
このアプリは2022年11月の1.0.7で登場し、Storeアプリとして数か月おきに更新されています。旧来の解説記事やフォーラムの回答は書かれた時点の版で機能の有無が違うため、次の表で版を合わせて読むと食い違いを避けられます。表は公式のリリースノートとStoreの掲載情報から作成しています。
| 版(公開月) | 主な変更 |
|---|---|
| 1.0.7(2022年11月) | 初版。自動生成とCloud Runner、2並列まで無償 |
| 2.0.4(2023年8月) | カタログアイテムとレコードプロデューサーの生成に対応 |
| 2.1.11(2023年11月) | 生成プリセットと条件ビルダーを追加 |
| 2.2.5(2024年2月) | スコープ別の保存、REST APIとサーバー側APIを追加 |
| 2.4.6(2024年8月) | カタログのテストにフローを動かすステップを追加 |
| 2.5.4(2024年11月) | フォームのテストにもフローのステップを追加 |
| 3.1.1(2026年7月) | sn_atf_tg.cloud_runner_adminロール、REST APIの非同期実行 |
| 3.2.1(2026年8月27日) | 一部ユーザーがロール欄を見られない不具合を修正 |
2.2.5で入ったアプリ独自のREST APIでは、テストの開始・キャンセル・状態照会、テスト生成の開始・キャンセル、Cloud Userの設定ができます。パイプラインからの呼び方は後述のCI/CDの章で扱います。
ATF Test Generatorが生成するテストの対象と中身
フォーム・カタログアイテム・レコードプロデューサーの生成対象範囲
ServiceNow Storeの製品ページの説明では、生成できるのはフォーム、サービスカタログのアイテム、サービスカタログのレコードプロデューサーの回帰テストです。任意のビジネスロジックを検証するテストを書かせる機能ではありません。「以前と同じ入力で、同じようにレコードが作られるか」を確かめる回帰テストの土台を大量に作る用途に向いています。回帰テストの範囲の決め方はリグレッションテスト(回帰テスト)の解説で扱っています。
既存データを使ってテストを組み立てる流れ
生成されたテストは、最初にフォーム上のフィールドを検証し、必須フィールドにはサンプルデータから値を入れます。必須ステップごとに検証を挟み、送信後に最後のレコード検証を行う構成です。スイートに入るのは、生成中に成功したテストだけです。
サービスカタログのアイテムにフローやフローロジックが紐づいている場合は、レコード検証とレコード照会のあとにフローを動かすステップも生成されます。これらはすべてサーバー側のステップで、フロー名を含むログメッセージで始まり、フローの状態を示すログメッセージで終わります。フロー関連の生成は次の3つのシステムプロパティで制御します。
| プロパティ | 役割 |
|---|---|
| sn_atf_tg.enable_flow_generation | フロー用ステップの生成(既定true) |
| sn_atf_tg.unsupported_flow | 生成から外すフロー(カンマ区切り) |
| sn_atf_tg.unsupported_flow_logic | 生成から外すフローロジック(カンマ区切り) |
カタログ以外でも、トリガー種別がCreated・Updated・Created or Updatedのフローに対応しています。カタログアイテムに紐づくフローは1つですが、それ以外のトリガー種別には複数のフローが紐づくことがあります。
導入前に確認する前提条件
インストールはStoreから行いますが、公式ドキュメントが注記しているとおりインスタンスの通信設定に手が入ります。ほかのStoreアプリと同じ感覚で入れると、想定外の再起動が起きます。事前に確認する項目は次のとおりです。
| 確認項目 | 公式の記載 |
|---|---|
| ロードバランサー | ADCv2であること(違えばNow Supportへ) |
| mTLS | 導入時に自動で有効化(KB1639216) |
| 再起動 | CHG適用でノードがローリング再起動 |
| 利用できない環境 | オンプレミス、SPP SP、NSC、一部の規制市場 |
| 利用できる政府・保護環境 | GCC、SPP EU、SPP AU(Yokohamaから) |
| 操作できるユーザー | admin(3.1.1以降は専用ロールでも一部可) |
オンプレミスで使えないのは、テストの生成と実行にServiceNowのクラウド基盤への接続が必要だからです。オンプレミスでブラウザを自動で立ち上げてUIテストを回したい場合は、Dockerで動かすHeadless Browserという従来の仕組みを使い続けることになります。
このアプリは生成時に実データを読み、テストを実行します。導入先は本番ではなく、開発・テスト用インスタンスにします。
Cloud Userの設定からテスト生成までの手順
Cloud Userの選定(インストール後に1回)
最初に、クラウド側のブラウザがログインに使うユーザーを登録します。All > Automated Test Framework (ATF) > Administration > Select Cloud User を開き、adminロールを持つユーザーを選んで送信します。登録時にクラウドブラウザを起動して実際にログインを試すため、完了まで時間がかかります。
ここで選ぶクラウド側のユーザーは、adminロールを持っている必要があります。一方、この設定画面を操作する側は、3.1.1以降ならsn_atf_tg.cloud_runner_adminロールでも構いません。Brazil版の操作手順にはadmin必須という記載が残っていますが、3.1.1のリリースノートでは、Cloud Userの設定とテスト生成の開始に専用ロールを使えることが明記されています。
公式は、自分がadminであっても専用のadminユーザーを用意することを推奨しています。次のいずれかに当てはまるユーザーは登録に失敗します。
- ユーザーが見つからない、無効化されている、ロックアウトされている
- パスワードのリセットが必要になっている
- adminロールを持たない、読み取り専用、Web services only に設定されている
Test Generatorの実行とプリセット
次に All > Automated Test Framework (ATF) > Administration > Test Generator を開きます。Advancedを選ばずに進めると、全テーブルを対象に生成します。Advancedを選ぶと、対象テーブルや生成数を指定できます。
| Advancedの項目 | 内容 |
|---|---|
| Maximum Test Count | 生成するテスト総数の上限 |
| Maximum test count per table | テーブルごとの上限 |
| Maximum test count per catalog item | カタログアイテムごとの上限(既定10) |
| Create separate update sets per scope | スコープごとに更新セットを分ける |
| Scope for generating tests | スコープ別更新セットを作らない場合の保存先(既定Global) |
| 生成完了の通知先 | |
| Presets | 条件のひな形の保存・呼び出し |
プリセットでは、Users・Tables・Service Catalogの各タブに条件を作り、どのデータから生成するかを絞り込めます。初回から全テーブルで回すのは避けます。インシデントや変更など運用で実際に使うテーブルとカタログアイテムに絞り、上限を小さくして結果を確かめるほうが、失敗の原因を追いやすくなります。
Start Test Generation を押すと生成が始まります。生成処理は同時に1つしか動かず、2つ目以降はキューに入ります。進行状況は Administration > Browser Orchestration Queue で確認できます。生成には時間がかかるため、公式は通知メールを定期的に確認するよう案内しています。
ATF Generated Suiteでの生成結果の確認
生成されたテストは Suites の「ATF Generated Suite」に入ります。テストは生成されるそばから表示されますが、生成が終わるまでスイートを実行しないよう公式は推奨しています。生成時に作られるレコードは更新セットに記録されます。生成のたびに新しい更新セットを作りたくない場合は、sn_atf_tg.generation.create_separate_update_set を false にします(既定はtrue)。
Cloud Runnerでの実行とスケジュール
Pick a BrowserでのCloud Runnerの選択
スイートでは「Run Test Suite」、個別テストでは「Run Test」を押すと Pick a Browser ダイアログが開き、手元のブラウザで新しいテストランナーを起動するか、Cloud Runnerで実行するかを選べます。Cloud Runnerを選ぶと、ServiceNowがホストするヘッドレスブラウザでテストが動きます。進捗バーを閉じても実行は続きます。
Cloud Runnerでスイートを実行すると、スイート内のテストは並列で動きます。実行順は無作為で、スイートに設定した実行順序とabort on failureは無視されます。前のテストが作ったレコードを次のテストが使う、という依存関係のあるスイートはこのままだと失敗します。同時に使えるCloud Runnerは既定で2つで、5つ追加で購入できます。
Cloud Runnerの選択肢を利用者に見せたくない場合は、atf_cloud_runner.radio_visible を false にするとダイアログから消えます。なお、実行中のテストデータは一時的にServiceNowのデータセンターにあるブラウザセッションに置かれ、すべての実行が終わると削除されます。
スケジュール実行と夜間実行
All > Automated Test Framework (ATF) > Schedules で New を選び、名前・有効化・アプリケーション・実行頻度・時刻を入れます。保存後、実行対象のテストスイートをスケジュールに関連付けます。「Run in cloud」は新規スケジュールでは既定でtrueですが、アプリ導入前からあるスケジュールではfalseのままです。既存のスケジュールをCloud Runnerに移すには、1件ずつこの項目を切り替えます。子テストのブラウザ名を変えても、Cloud Runnerで実行されます。
クライアントテストランナー・Headless Browserとの違い
ATFのUIテストを動かすブラウザは3通りあります。人がブラウザを開いておく方式は、スケジュール実行の時刻にランナーが起動していないと動きません。
| 方式 | ブラウザの用意 | 位置付け |
|---|---|---|
| クライアントテストランナー | 利用者がタブを開いておく | ATF標準 |
| Headless Browser | Dockerで自前運用 | レガシー(オンプレはこちら) |
| Cloud Runner | ServiceNowがホスト | 公式推奨 |
クライアントテストランナーでスケジュール実行する場合、macOSのChromeやSafariでは画面ロックやタブの非表示で実行が大幅に遅くなり、タイムアウトすることがあります。公式は画面がロックされない仮想マシンで動かすよう案内しています。Cloud Runnerに寄せれば、こうした端末側の制約を受けません。
CI/CDパイプラインからCloud Runnerでスイートを流す手順
更新セットやアプリの適用後にパイプラインからテストを流すには、ServiceNow標準のCI/CD APIを使います。Australia版のAPIリファレンスでは、POST /api/sn_cicd/testsuite/run に run_in_cloud というクエリパラメータがあり、true を渡すとCloud Runnerで実行します(既定は false)。false のままUIテストを含むスイートを流すと、スケジュール済みのクライアントテストランナーかHeadless Browserが必要になります。
| エンドポイント | 用途 |
|---|---|
| POST testsuite/run | スイートを開始し進捗IDを返す |
| GET progress/{progress_id} | 状態(0=Pending〜4=Canceled)を返す |
| GET testsuite/results/{result_id} | 成功・失敗・エラー・スキップの件数 |
呼び出すユーザーには、adminロールか sn_cicd.sys_ci_automation ロールが必要です。どちらも無いと403が返ります。スイートは test_suite_sys_id か test_suite_name のどちらかで指定します。進捗の status は 0=Pending、1=Running、2=Successful、3=Failed、4=Canceled で、完了すると応答の links.results.id に結果のIDが入ります。
次のスクリプトは、Cloud Runnerでスイートを流し、終わるまで30秒ごとに進捗を確かめて、スイートが成功しなければ非0で終わります。待機の上限は既定1,800秒で、環境変数ATF_TIMEOUT_SECONDSで変えられます(この値は記事の例として決めたもので、ServiceNowの仕様値ではありません)。GitHub ActionsやJenkinsのジョブで、更新セットの適用完了を確認した後に実行する想定です。実行環境にはBash、curl、jqが必要です。SN_INSTANCEにはスキームや末尾のスラッシュを含めないホスト名を、SN_USERとSN_PASSには認証情報を、SUITE_SYS_IDには対象スイートのsys_idを設定します。エンドポイントと応答の項目名は上記APIリファレンスの記載に合わせており、jqでの値の取り出しはリファレンスに載っている応答例で確かめています。
#!/usr/bin/env bash
# 更新セット適用後にATFスイートをCloud Runnerで流し、失敗があれば非0で終わる
set -euo pipefail
: "${SN_INSTANCE:?}" "${SN_USER:?}" "${SN_PASS:?}" "${SUITE_SYS_ID:?}"
api="https://${SN_INSTANCE}/api/sn_cicd"
run=$(curl -sS -X POST -u "${SN_USER}:${SN_PASS}" -H 'Accept: application/json' \
"${api}/testsuite/run?test_suite_sys_id=${SUITE_SYS_ID}&run_in_cloud=true")
progress_id=$(jq -r '.result.links.progress.id // empty' <<<"$run")
[ -n "$progress_id" ] || { jq -r '.result.error' <<<"$run"; exit 2; }
while :; do
prog=$(curl -sS -u "${SN_USER}:${SN_PASS}" -H 'Accept: application/json' \
"${api}/progress/${progress_id}")
status=$(jq -r '.result.status' <<<"$prog")
case "$status" in
0|1)
if [ "$SECONDS" -ge "${ATF_TIMEOUT_SECONDS:-1800}" ]; then
echo 'ATF polling timed out' >&2
exit 124
fi
sleep 30
;;
*) break ;;
esac
done
result_id=$(jq -r '.result.links.results.id // empty' <<<"$prog")
[ -n "$result_id" ] || { jq -r '.result.status_detail, .result.error' <<<"$prog"; exit 2; }
res=$(curl -sS -u "${SN_USER}:${SN_PASS}" -H 'Accept: application/json' \
"${api}/testsuite/results/${result_id}")
jq '.result | {test_suite_status, rolledup_test_success_count, rolledup_test_failure_count, rolledup_test_error_count}' <<<"$res"
[ "$(jq -r '.result.test_suite_status' <<<"$res")" = "success" ]
アプリ独自のCloud Runner Test Runner REST API(POST /api/now/sn_atf_tg/test_runner。REST API ExplorerでのAPI名はOne-click regression testing for ATF)でも、テストやスイートをCloud Runnerで開始できます。ただし、この独自APIはadminロールが必須です。CIのサービスアカウントにadminを渡したくない場合は、sn_cicd.sys_ci_automationロールで呼べるCI/CD APIを使います。
ATF Generated Suiteに残るのは生成中に成功したテストです。ただし、生成時に成功したことは、更新セットの適用後やCloud Runnerの並列実行でも成功することを保証しません。合否は適用後の再実行結果で判定します。手作業で作ったスイートを同じ経路で流すときは、テスト同士がデータを共有していないかを先に確かめます。パイプライン全体への組み込み方はスモークテストをCI/CDに組み込む方法も参考になります。ServiceNowのテストを開発プロセスに組み込む設計は、当社のDevOps・CI/CD導入支援でも支援しています。
「テスト生成」と名の付くServiceNow機能の見分け方
ServiceNowには、ATFのテストを作る機能がほかにもあります。名前が似ているため、社内で「テスト生成を使う」と言ったときにどれを指すのかがずれやすくなります。2026年11月時点の公式ドキュメントで確認できるものを並べると次のとおりです。
| 機能 | 入力 | 状況 |
|---|---|---|
| ATF Test Generator and Cloud Runner | インスタンスの既存データ | Storeアプリ・無償 |
| Test generation(生成AI) | 自然言語のプロンプト | Australiaから非推奨化の準備中 |
| Build AgentのATFテスト生成 | 構築・編集中のアプリ | Australia・既定は無効 |
| UI Test Script | Build Agentとの対話 | Australia・Testing Library形式 |
生成AI系のTest generationは、Australiaリリースから将来の非推奨化に向けた準備段階に入っています。新規インスタンスでは非表示になりインストールもされませんが、サポートは続きます。以前はnow.assist.creatorロールが必須でしたが、Now Assist for Creatorの累積リリースノートによると、Yokohama Patch 8でこの要件は外れました。
Build AgentのATFテスト生成は、有効化の手順によると、IDEのServiceNow Ottoパネルで Settings > General を開き、「Sync ATF tests with app」を有効にして使います。この設定と「Run UI ATF tests」はどちらも既定で無効です。有効にすると、アプリの構築とインストールが終わるたびに「Generate automated tests for this application?」と尋ね、承認するとテストを生成してサーバー側のテストを自動で実行します。公式ドキュメントはこの機能をTest Agentと呼び、ServiceNow Communityの公式ブログ(2026年7月2日)はAustraliaでGAになったと説明しています。Build Agentでのテストの解説によると、Test Agentが作ったテストはCloud Runnerのレーンで動きます。そのため、テストを実行するにはATF Test Generator and Cloud RunnerのインストールとCloud Userの設定が必要です。Build Agentでアプリを作る予定があるインスタンスでも、このStoreアプリは先に入れておくことになります。
UI Test Scriptは、独自UIのテストコードをBuild Agentとの対話で作成する機能です。利用できるのはTesting Library構文の一部です。生成したスクリプトはATFの1ステップとして、クライアントテストランナーで動きます。
選び方は入力で決まります。既に運用しているフォームとカタログの回帰テストを揃えたいならATF Test Generator、Build Agentで新しく作るアプリのテストを書かせたいならBuild AgentのATFテスト生成、独自UIの検証ならUI Test Scriptです。AIでテストケースを作る考え方は、ServiceNowに限らない一般論としてAIテスト自動化の解説で整理しています。
生成したテストが残らない・失敗するときの確認点
生成が完了しても、スイートに残るテストが少ない場合があります。スイートには生成中に成功したテストしか残らないため、入力データが今の画面仕様と合わないテーブルほどテストが残りません。ServiceNow Communityの日本語フォーラムには、変更管理などのテーブルに絞って生成したところテストステップがすべて消えていたという報告があります。この報告では、Now Supportから「プリセットの条件に合わないテストは生成後に削除される」と回答されたと書かれています。原因を切り分けるときは、次の順で確認します。
- Browser Orchestration Queue(BOQ)のジョブを開き、ログを確認する。ログインのリダイレクト失敗や、要求送信後のAPIキー削除による失敗はここに記録されます。
- クライアントスクリプトでログイン後の画面遷移をカスタマイズしていないか確認する。ADCv2の設定不備と組み合わさると、クラウドブラウザがログインできません。
- 対象がUI Builderで作ったページやランディングページではないか確認する。ATFはこれらのNext Experience要素に未対応です。
- プリセットの対象テーブルとカタログアイテムを絞り、上限を小さくして再生成する。
生成テストに含まれるのは、基本的なフォームのステップとサーバー側のステップだけです。Service Portalの独自ウィジェットやワークスペースを中心に運用しているインスタンスでは、自動生成の対象外の画面と、ATF自体が対応しない画面を分けて工数を見積もります。Configurable WorkspaceのページはPage Inspectorで手動作成し、UI Builderで作ったページは手動テストか別のテスト手段で確かめます。テストの配分の考え方はテストピラミッドの解説が参考になります。
よくある質問
ATF Test Generatorは無料で使えますか?
ServiceNow Storeでの価格表記はFreeで、アプリ自体は無償でインストールできます。Cloud Runnerは既定で2つまで同時に使え、それ以上が必要なら5つ追加で購入できます。
本番インスタンスにインストールしてもよいですか?
推奨されません。ATFのテスト実行は本番での誤実行を防ぐため既定で無効になっており、公式は開発・テスト用のインスタンスでだけ実行するよう求めています。このアプリはsn_atf.runner.enabledをtrueにする前提なので、導入先は開発・テスト用インスタンスにします。
オンプレミスのServiceNowで使えますか?
使えません。ServiceNowのクラウド基盤への接続が必要なためです。SPP Singapore、National Security Cloud、一部の規制市場も対象外です。GCC、SPP EU、SPP AUではYokohamaから利用できます。
ATF(Automated Test Framework)とATF Test Generatorの違いは何ですか?
ATFはテスト・テストステップ・スイートを作って実行するServiceNow標準の仕組みで、プラグインcom.glide.automated_testing_frameworkとして既定で有効です。ATF Test GeneratorはそのATFのテストを既存データから自動で作るStoreアプリで、生成されたものは通常のATFテストとしてスイートに入ります。
Cloud Runnerで実行するとテストの順番はどうなりますか?
スイートをCloud Runnerで実行すると、スイート内のテストは並列かつ無作為な順で動き、実行順序とabort on failureの設定は無視されます。前のテストの結果に依存するテストは、自分で必要なデータを作るように書き換えるか、Cloud Runnerを使わずに実行します。