ATF（自動テスト）はテスト→ステップ→結果の3層

ServiceNow の Incident / Problem / Change は task を継承し、State という1本の状態を持つ「業務レコード」でした。ATF（Automated Test Framework）はこれらと役割が違い、アップグレードやカスタマイズの後で「画面やレコードがちゃんと動くか」を自動で確かめます。

ATF の画面の裏側もテーブルでできています。中心になるのは sys_atf_test（テスト本体）／ sys_atf_step（テストステップ）／ sys_atf_test_result（実行結果） の3つです。1つのテストが複数のステップを持ち、テストを実行すると結果が1レコード作られます。

この記事では、実際の sys_atf_test を起点に、ステップを保持する sys_atf_step、ステップの種類を決める sys_atf_step_config、実行結果を表す sys_atf_test_result とその状態（status）を、PDI の実機で確認します。テストとステップの関係、ステップの種類（step_config）、実行結果の status を、それぞれ実データの件数つきで並べます。

ServiceNow の Incident や設定画面は触ったことがあるが、ATF のテーブル構造（テスト→ステップ→結果）はこれから、という管理者・開発者向けです。

この記事で分かること

• sys_atf_test（テスト）と sys_atf_step（ステップ）が「1対多」でつながること

• ステップの順番は order、ステップの種類は step_config で決まること

• step_config（ステップの種類）が PDI で103種あり、Form / Server / REST などに分かれること

• 実行結果 sys_atf_test_result の status が取り得る値（Success / Failure / Error など）

• ATF 系テーブルが sys_metadata（設計物）と結果ログで階層が分かれていること

• 実機で確認するときに開く一覧URL

ATF（Automated Test Framework）とは

ATF（Automated Test Framework）は、ServiceNow の中でアプリケーション・カスタマイズ・設定が期待どおり動くかを自動でテストする仕組みです。フォームを開いてフィールドを入力し、レコードを保存し、結果を検証する一連の操作を「ステップ」として並べておくと、人間の代わりに ServiceNow がその手順を実行します。

アップグレードや変更のたびに画面を1つずつ手で確認する代わりに、ATF にテストを作っておけば同じ手順を繰り返し自動で確認できます。テストは「ステップの順序つきの並び」で、ServiceNow が各ステップを順に実行し、ステップごとと全体の成否を記録します。

テストの実行は事故防止のため初期状態では無効化されており、実行するには専用のプロパティを有効にします。この記事ではテーブル構造を確認します。テストの実行そのものは扱いません（今回の PDI では実行結果は0件でした）。

テスト → ステップ → 結果 の構造

ATF の中心は、テスト（sys_atf_test）と、そのステップ（sys_atf_step）、そして実行結果（sys_atf_test_result）の3つです。まずこの関係を押さえます。

今回確認した PDI（Zurich / OOTB＋デモデータ）では、次の関係でした。

• sys_atf_test（Test） … テスト本体。固有フィールドは11。name / active / description などを持つ。

• sys_atf_step（Test Step） … 1ステップ＝1レコード。固有フィールドは16。test フィールドで sys_atf_test を参照し、order（Execution order）で実行順を持つ。

• sys_atf_test_result（Test Results） … テストを実行するたびに作られる結果。固有フィールドは43。test で実行したテストを参照し、status で成否を持つ。

1つのテストが複数のステップを持ち（1対多）、テストを1回走らせるごとに結果レコードが1つ増えます。ステップは sys_atf_test の中に埋め込まれているのではなく、sys_atf_step という別テーブルに order 付きで並びます。

下のスクリーンショットは、PDI にあるテスト「ATF: Change Request ライフサイクルテスト」のフォームです。上半分がテスト本体（sys_atf_test）、下半分の Test Steps 関連リストが、そのテストに紐づく sys_atf_step です。Create a User → Open a New Form → Set Field Values → Submit a Form と、order 順にステップが並びます。

公式の Getting started with the Automated Test Framework（Zurich） が、テストはステップの順序つきの並びであり、ServiceNow が各ステップと全体の成否を報告する、と説明しています。

テストステップを1つ組み立てる（設定例）

構造だけでは「自分でテストを作るとどうなるか」が見えにくいので、上の「ATF: Change Request ライフサイクルテスト」の先頭が実機でどう並んでいたかを、order とステップ種類で書き出します。これは新しくテストを作るときにフォームへ積んでいく順番そのものです。

order     ステップ種類（step_config）  やること
-----------------------------------------------
100       Create a User                テスト用ユーザーを作る
200       Open a New Form              Change Request の新規フォームを開く
300〜800  Set Field Values             Short description などのフィールドに値を入れる
次        Submit a Form                フォームを保存して Change を作る

新しく Change のテストを作るなら、Test を1件作り、Test Steps 関連リストで「Add Test Step」を押し、step_config に Open a New Form を選んで対象テーブル（change_request）を指定します。続けて Set Field Values で埋めるフィールドと値を指定し、最後に Submit a Form を置く、という積み方になります。order は 100, 200, 300 のように間隔を空けておくと、後から間に差し込めます。

各ステップが何を対象にするかは、step_config（種類）→ table（対象テーブル）→ inputs（入力値）の3つで決まります。Open a New Form なら開く先のテーブル、Set Field Values なら埋めるフィールドと値が inputs に入ります。実機のステップを読むときも、この3つを順に見ると「どのテーブルに対して、どんな値で、何をするステップか」がたどれます。

ATF テーブルの継承（設計物と結果ログ）

ATF のテーブルは、継承の起点が2系統に分かれています。テストやステップは「設計物（metadata）」、結果は「実行ログ」として、別の階層に位置します。

今回確認した PDI（Zurich / OOTB）では、次のとおりでした。

• sys_atf_test / sys_atf_step / sys_atf_step_config / sys_atf_test_suite … いずれも sys_metadata（Application File）を継承。これらは Update Set で運ぶ「設計物」として扱われます。

• sys_atf_test_result … super_class が空で、どのテーブルも継承しないルートでした。実行ごとに増える結果ログは、設計物とは別系統です。

• 各ステップの結果（sys_atf_test_result_step）は、sys_atf_test_result_item を継承する別テーブルにあります。

テスト・ステップは sys_metadata 系、実行結果は独立系統、という分かれ方は、ATF を更新セットで移送するときの挙動につながります。テストとステップは Update Set に乗って運ばれ、実行結果は運ばれません。設計物と実行ログを別の階層に置いているためです。

テーブルの継承は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsys_atf_test^ORname=sys_atf_step

ステップの種類（step_config）

ステップが「何をするステップなのか」は、sys_atf_step 自体ではなく、step_config（Step Config）という参照先で決まります。フォームを開く、フィールドに値を入れる、レコードを作る、REST を呼ぶといった動作の種類が step_config です。

今回の PDI（Zurich / OOTB）では、step_config は103種ありました。カテゴリで分けると、Service Catalog 系、Server、Form、REST などに分かれます。代表的なカテゴリ別の種類数は次のとおりです。

Step Config のカテゴリ別内訳（全103種）

Service Catalog in Service Portal 19 / Server 16 / Form 12 / REST 11 / Service Catalog 10 / Service Portal 8 / List and Related List 6 / Email 6 / Custom UI 6 / Application Navigator 3 / Configurable Workspace 2 / Responsive Dashboards 2 / Reusable Test Utilities 1 / Reporting 1

実際に各ステップがどの step_config を使っているかを見ると、使用頻度には偏りがあります。今回の PDI の全ステップ（2257件）のうち先頭2000件をサンプルすると、Click a UI Action（268）／ Open an Existing Record（238）／ Impersonate（205）が上位でした。テストの多くが「誰かになりすまして（Impersonate）」「既存レコードを開き（Open an Existing Record）」「ボタンを押す（Click a UI Action）」という画面操作の基本動作で組み立てられています。

ステップの種類は Form 系・Server 系のように動作の場所で分類されています。UI 操作系の各ステップの詳細は公式の UI test steps（Zurich） に一覧されています。

step_config の一覧は、次のURLで確認できます。

https://<YourInstance>/sys_atf_step_config_list.do?sysparm_query=active=true^ORDERBYcategory

実行結果の状態（sys_atf_test_result.status）

テストを実行すると sys_atf_test_result が作られ、その成否は status フィールドに入ります。task 系の State が「業務の進み具合」を表すのに対し、ATF の status は「テストの実行結果」を表します。

今回確認した PDI（Zurich / OOTB）では、status の選択肢は10件で、value = label は次のとおりでした。

pending=Pending / waiting=Waiting / running=Running /
success=Success / failure=Failure / skipped=Skipped /
error=Error / canceled=Canceled / paused=Paused /
success_with_warnings=Success with Warning(s)

Failure（テストが期待と違った）と Error（テスト自体が実行できなかった）が別の値になっています。アサーションに失敗したのか、ステップがそもそも動かなかったのかを status で区別できるためです。Success with Warning(s) のように、成功だが警告つき、という状態もあります。

結果レコードには status のほかに、run_time（実行時間）や first_failing_step（最初に失敗したステップ）も入ります。first_failing_step は sys_atf_test_result_step を参照するので、「どのステップで落ちたか」を結果から直接たどれます。

実行結果は、次のURLで確認できます。

https://<YourInstance>/sys_atf_test_result_list.do

主なフィールド（Test / Step / Result）

3つのテーブルの主なフィールドを並べると、それぞれの役割が見えてきます。

• sys_atf_test は name / active / description と、parameterized testing の有効化など「テストの設定」を持つ。

• sys_atf_step は test（親テスト）・order（実行順）・step_config（種類）の3つが軸。さらに table（対象テーブル）や inputs（入力値）で、そのステップが何に対して何をするかを保持する。

• sys_atf_test_result は test（実行したテスト）・status（結果）・run_time（時間）・first_failing_step（失敗箇所）で、実行の記録を持つ。

ステップを読むときは、step_config（種類）→ table（対象）→ inputs（入力値）の順に見ると、「どのテーブルに対して、どんな値で、何をするステップか」が分かります。

全フィールドは、次のURLで一覧できます。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_atf_step^elementISNOTEMPTY

ATF テーブルの件数と周辺設定

ATF の規模感と周辺の設定も実測しました。今回確認した PDI（Zurich / OOTB＋デモデータ・active 中心・2026-06-22 確認）では、次のような件数でした。

Test Results が0件です。これは「テストは191件あるが、この PDI では一度も実行されていない」ことを意味します。ATF の実行は初期状態で無効化されているため、OOTB の PDI では結果が空になります。

Test Steps が2257件と多いのは、1つのテストが平均で十数ステップを持つためです（今回見たテストでは20〜26ステップのものもありました）。テストの「数」だけでなく「ステップの総量」で見ると、ATF の作り込み具合が分かります。

Test Suite まわりの件数

Test Suite（sys_atf_test_suite）は48件、テストとの紐付け（sys_atf_test_suite_test）は171件でした。Step Config（sys_atf_step_config）は全103件のうち active は102件です。

自分のインスタンスでは、次のURLで各一覧を開けます。

Tests        : https://<YourInstance>/sys_atf_test_list.do
Test Steps   : https://<YourInstance>/sys_atf_step_list.do?sysparm_query=ORDERBYtest
Test Suites  : https://<YourInstance>/sys_atf_test_suite_list.do

ServiceNow における ATF テーブルのまとめ

• ATF の中心は sys_atf_test（テスト）・sys_atf_step（ステップ）・sys_atf_test_result（結果）の3テーブル。テストとステップは1対多、テストを実行するたびに結果が1件増えます。

• ステップの実行順は order、種類は step_config で決まります。step_config は今回の PDI で103種あり、Form / Server / REST / Service Catalog などに分かれます。

• 実際のステップは Impersonate / Open an Existing Record / Click a UI Action のような画面操作系が多く使われていました（使用頻度の上位）。

• 実行結果の status は10種で、Failure（期待と違う）と Error（実行できない）を区別します。run_time や first_failing_step で「どこで何秒かけて落ちたか」までたどれます。

• テーブルの継承は2系統。テスト・ステップ・Step Config・Suite は sys_metadata（設計物）、Test Result は独立系統（実行ログ）です。

• 今回の PDI では Tests 191・Test Steps 2257・Test Results 0（未実行）でした。ATF の実行は初期状態で無効のため、結果が空でした。

ATF を調べるときは、「テスト1件に対してステップが order 順に並ぶ」構造を押さえ、各ステップの step_config（種類）と、実行後の sys_atf_test_result（status）をセットで見ると読み解きやすくなります。

実機を見て気づいたこと

• 全191件のテストのうち active は37件でした。デモに入っているテストの多くは無効化された状態で、そのままでは実行されません。

• 各ステップの実行結果（sys_atf_test_result_step）は、テスト結果本体の sys_atf_test_result ではなく sys_atf_test_result_item を継承する別テーブル（固有フィールド4）でした。結果の本体とステップ単位の結果を、あえて別クラスに分けている設計です。

次に読むなら

次に扱うなら、Test Suite（sys_atf_test_suite）による複数テストのグループ化と実行、parameterized testing（データ駆動テスト）、そして実際にテストを実行したときの sys_atf_test_result / sys_atf_test_result_step の中身です。テスト結果から first_failing_step をたどって失敗箇所を特定する流れは、ATF を運用に乗せるときに毎回使います。これらは本記事の構造の先にあたり、別記事で扱う予定です。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• ATF：Automated Test Framework（自動テストフレームワーク）

• テスト（sys_atf_test）：ステップの順序つきの並び。テストの本体

• テストステップ（sys_atf_step）：テスト内の1動作。order で順序、step_config で種類が決まる

• Step Config（sys_atf_step_config）：ステップの種類の定義（Form / Server / REST など）

• テスト結果（sys_atf_test_result）：テストを実行するたびに作られる結果レコード

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

テーブル定義        : sys_db_object_list.do?sysparm_query=nameSTARTSWITHsys_atf_test^ORname=sys_atf_step
テスト一覧          : sys_atf_test_list.do
テストステップ一覧   : sys_atf_step_list.do?sysparm_query=ORDERBYtest
Step Config 一覧    : sys_atf_step_config_list.do?sysparm_query=active=true^ORDERBYcategory
フィールド一覧      : sys_dictionary_list.do?sysparm_query=name=sys_atf_step^elementISNOTEMPTY
status の選択肢      : sys_choice_list.do?sysparm_query=name=sys_atf_test_result^element=status^inactive=false^ORDERBYsequence
テスト結果一覧       : sys_atf_test_result_list.do

検証範囲とおことわり

• 確認した範囲：sys_atf_test / sys_atf_step / sys_atf_test_result の継承・固有フィールド数・主要フィールドと参照先、test→step→result の構造、status の選択肢（10種）、Step Config のカテゴリ分布（103種）、ステップ種別の使用分布、各テーブルのレコード件数、周辺設定件数。すべて PDI（Zurich / 2026-06-22 確認）の OOTB＋デモデータで取得しています。

• 確認していない範囲（断定しません）：テストの実行挙動と実行結果の中身（Test Results が0件のため実測不可）、Test Suite の実行・スケジュールの動き、parameterized testing の動作、Custom UI / Browser 実行の内部、各 Business Rule / ACL の内部スクリプト挙動、テスト実行を有効化するプロパティの扱い。これらは別記事で扱います。