ServiceNow ATF Test Generatorの基本設定
ServiceNowのATF（Automated Test Framework）は、テスト自動化を実現する強力なツールです。この記事では、ATFを自動生成するATF Test Generatorの実践的な設定方法や成功のコツを詳しく解説します。
1. ATF Test Generatorとは？
ATFはServiceNowでテストの自動化を行うためのモジュールです。そして、ATF Test Generatorは、直近のユーザーの操作を解析してATFのテストを自動的に生成するツールです。
ただし、初回の設定では100%うまくいかないです。そこで私が人柱となり30時間以上かけて見つけた成功率の高まる設定を書き残したいと思います。
参考URL
2. ATF Test Generatorのセットアップ
ATFはデフォルトでインストールされていますが、ATF Test Generatorはストアアプリから追加でインストールする必要があります。まず、「Auto-generate Tests」からストア画面へ飛びます。ちなみに、このメニューはアプリをインストールしたら消えて別の名前になりますのでお気に入りに入れないでください。
Getします。
Plugin画面から「ATF Test Generator」で検索しモジュールをインストールします
3. 操作を便利にするためのお気に入り登録
プラグインのインストールが終わったら、以下の名前で検索をして名前を短くして登録しておきます。このメニューを延々と繰り返し使いますので必ず登録しておきましょう。順番も大切です。
- Test Generator
- Browser Orchestration Queur
- Suites
- Tests
- ATF - Properties
4. ATF Test Generatorの準備
まずは、「インシデントを作成してクローズするまで」という簡単なシナリオでATFを自動生成してみます。
Test Generatorをクリックします
Advancedにチェックをいれて、いくつかのパラメーターを設定します。
（チェックを入れずにそのまま実行すると、不要なテストが2000個くらいできてしまいます。意味ないです。）
パラメーターの意味
- Maximum Test Count: テスト生成の全体数を指定。
- Maximum test count per table: 各テーブルごとの最大生成数。
- Maximum test count per catalog item: 各カタログアイテムの最大生成数。
- Email: 生成完了時に通知を受け取るメールアドレス。
説明を見ると上記のように書いているのですがピンとこなかったので私なりの理解を以下に書きます。
私の理解
- Maximum Test Count: Test Steps（xxx）の最大値とイコールです（前述の図参考）
- Maximum test count per table: ServiceNow側のサーバーで行うランダムテストの最大数
- Maximum test count per catalog item: ServiceNow側のサーバーで行うカタログアイテムのランダムテストの最大数
- Email: 生成完了時に通知を受け取るメールアドレス
こんな感じです。
Presets（プリセット）の活用
Test Generatorを実行するとその時の設定を見直すことはできないので、まめにスクリーンショットを取っておくか試行錯誤用に１つプリセットを決めて毎回Saveしてしておくのがいいです。うまくいった設定の再実施もダメな設定の後に変化をつけるときも共に必要です。
5. フィルタ設定：Users、Tables、Service Catalog
Usersタブ
- 役割: どのユーザーを対象とするテストを生成するかを指定します。
-
おすすめ設定:
- 必要最小限のユーザー（1～5名）に絞ることで、テストの対象を明確化します。
- ユーザー数を増やしすぎると、まったく指定していないテーブルの不要なテストが増加するため注意が必要です。
Tablesタブ
- 役割: テスト生成の対象となるテーブルを指定します。
-
おすすめ設定:
- テーブルの数を2～3個程度に制限することで、無駄なテストを減らせます。
- 必要に応じてタスクテーブルや承認テーブルも忘れずに指定してください。
Service Catalogタブ
- 役割: カタログアイテムのテストを生成するかどうかを管理します。
-
おすすめ設定:
-
カタログアイテムのテストを生成しない場合は、フィルタ条件が0件になるよう設定してください。
-
特定のカタログアイテムだけを対象にする場合は、正確なNameを入力し、該当アイテムを絞り込みます。うまく設定できた場合は、右側のカテゴリなどが引用されます。
-
6. テスト生成の開始
-
必要な設定をすべて完了後、「Start Test Generation」ボタンをクリックします。
-
Browser Orchestration Queuesで進捗を確認します。「Completed」になるまで待機してください。このときに、対象ユーザーにImpersonateして自動生成したいテストを操作しておくと成功率が高くなりそうです。（推測です）。
テストはServiceNow社が管理するクラウドサーバーでランダムに試行されそこで合格したものだけが返されます。 つまり、パラメーターで設定したテストパターンが少なければランダムテストは失敗してテストは作成されません。反対に指定するユーザーやテーブルを増やしすぎると簡単にテストは自動生成されますが、まったく関係のないテーブルのテストが作成されてしまい使い物になりません。おそらく、直近のユーザーの行動でそのテーブルを触ったものやテーブルの拡張関係にあるテストがランダムで実施されるようです。
7. 自動生成されたテストの確認
結果のメール確認
パラメーター設定時にメールアドレスを指定しておくと完了時にメールが届きます。ノンプロインスタンスでメールを切っていたとしてもServiceNow側のサーバーからメールが送られてくるのでメールは届きます。
生成されたテストスイートの確認
ステータスがCompleteになると、以下のようにテストスイートが作成されます。テストが1つも作成されなくてもテストスイートは作成されます。良くできたテストスイートは名前を変えたりタグを設定しておくといいです。
生成されたテストの確認
- テストスイートを見るとその中にテストが複数作成されます。慣れないうちは思った通りのテストが作成されません。こちらもよくできたテストは名前を変えたりタグを設定して不要なテストは削除して必要なものを残してください。
以下のようにテストが作成されました。
中を見るとテストステップが作成されています。
以下のように、まだテストを1度もRunしていないのに合格したテストが１つあるのは、おそらくServiceNow側のサーバーでランダムにテストを行い、ほとんどのものが失敗し削除され合格したものだけがインスタンスに返される。というのを示している証拠だと思います。まるで蜘蛛の糸のような仕組みのようです。
-
後続のクローズまでの操作が不足する場合
前述のServiceNowのサーバー側でのテスト作成の理屈を考えれば納得できることですが、ランダムなテストでうまく行くのがサブミットまでであることが多く、後続のワークフローを回す操作はその過程で失敗し私たちの手元には届かないので、後続のフローは手で追加せざるを得ません。とはいえITSMツールで面倒なのは開始時のサブミットまでだったりするのでそれが自動化されるだけでも十分助かりますね。
- 出来上がったテストは操作が1つずつのレコードに分けられている
ServiceNow側でランダムに作られたテストは、フィールドの入力も値の確認も1フィールドずつ1レコードに分けられています。この点も編集しづらく見づらい点です。そしてvalidationのレコードが非常に多いです。
8. 最後に
以上がATF Test Generatorの基本的な設定です。何もわからないところから読んだ方は大まかな流れが理解できたのではないでしょうか。
ATF Test Generatorはまだまだ発展途上の機能なようで、一長一短あると思います。
実務で使うための仕上げまでを考えると、もしかしたら手で作ったほうがよっぽと正確で早いかもしれないです。それでも必ず成功するTestが作れるので、「初回作成時のガワづくり」として考えれば十分効率化が期待できる機能なのではないでしょうか。