Job Runnerのテスト実行とは、作成したジョブを気軽にテストできる機能です。次のような特徴があります。
実行時間を一切消費しません。何度実行しても料金はかかりません
一連のカスタマイズを実行した結果の、レコードの中身を確認することが可能です
kintoneから実際にレコードを読み込みます（APIリクエスト数を消費します）
kintoneへのレコードの追加・更新は一切行いません（APIリクエスト数を消費しません）
外部連携システムとの接続は一切行いません
以下、具体的に使い方をご紹介します。
テスト実行の方法
Job Runnerの画面上「ジョブ生成・設定」ボタンの左隣に、「このページをテスト実行」ボタンがありますので、これをクリックします。
なお、テスト実行はあくまでもページ単位での実行になりますのでご注意ください。
kintoneアプリのWebhookの場合
kintoneアプリのWebhookの場合は、「このページをテスト実行」ボタンを押すと次の様なダイアログが表示されます。
操作の種類
・レコードを追加した
・レコードを編集した
・レコードのステータスを変更した
・レコードを削除した
・コメントを書き込んだ
の５つからテストしたい操作の状況を指定して下さい。
レコード番号
このレコードに対して操作を行い、Webhookが動いた という仮定でテストを行います。
テストに適したレコード番号をセットして下さい。
操作ユーザー
ユーザーのログイン名を入力してください。
kintoneには存在しないログイン名(ダミーの値)でも実行する事ができます。
定期実行タスクの場合
定期実行タスクの場合は、「このページをテスト実行」ボタンを押すとそのページのカスタマイズが即座に実行されます。
テスト実行後
もしそのページの設定にエラーがあれば、その旨がすぐに指摘されますので、内容に従って修正しましょう。
そのページの設定にエラーがなければ、即座に別のタブで「ジョブ実行ログ」画面が起動し、テスト実行が開始されます（ブラウザにポップアップブロックが設定されている場合には、その設定を解除しておいてください）。
ジョブ実行ログの見かた
ジョブ実行ログの画面では、「実行データ」と「ログ」の2つのタブがあります。
「実行データ」タブについて
実行データのタブでは、それぞれのアクションや、最終的に処理対象となったレコードの一覧などの結果を確認することができます。それぞれのアクションをクリックして、中身を確認してみてください。
このとき、『≪ 値はありません ≫』という結果のアクションが表示されることがあります。
その場合は、そのアクションは表示の通り値を返すアクションではなく、値を確認することはできない事を示しています。
「ログ」タブについて
ジョブが実行したログ全体が出力されます。エラー時の原因調査はもちろん、kintoneに送ったリクエストや本来追加/更新するはずのレコードの内容など、ジョブの動作の内容すべてを確認することが可能です。
たとえば、「SKIP calling kintone API」という表示とともに、本来kintoneに送るはずだったリクエストの内容も出力されていますので、この内容を元にエラー時の原因調査をすることができます。
実行時エラーがあった場合の見かた
エラーがあった場合、先頭にエラーメッセージが表示されています。内容を確認の上、設定を修正してください。
こちらの例では、APIトークンの権限が不足していることが分かります。kintone側の権限設定を確認・修正して、再度テスト実行してみてください。
実行時エラーがなかった場合の見かた
たとえばこのような設定を例に取り、テスト実行をしてみます。会社マスターのレコード数を数え、集計用のアプリに追加するだけの簡単なカスタマイズになります。
ここでは「レコード全行が準備できた時」の条件でレコードの取得アクション（アクション６）とつながっているのがポイントです。
これをテスト実行してエラーがなければ、次のような形で実行後のデータが見えるようになります。
「終了時の処理対象レコード」の表示
このカスタマイズで『終了時に処理をした』対象のアプリと、それぞれのレコードの中身が確認できます。
この『終了時に処理をした』レコード、というのは、Job Runnerおよび実行データタブを理解するためのポイントになりますので、のちほど説明します。
また上の画面の通り、終了時に処理をしたレコードが100行より多い場合には、表示は100行で打ち切られますのでご注意ください。
「追加されるレコード」「更新されるレコード」の表示
追加されるレコード・更新されるレコードの後ろにある(340)などという数字は、アプリIDになります。
ここでは、このカスタマイズでこのアプリに追加される（はず）のレコードが表示されます。
なおテスト実行では、実際にkintoneへの追加・更新はされませんので、安心してお試し頂く事ができます。
逆に言うと、レコードを追加したり更新するテストは出来ませんので、これは実際にジョブを動かしてご確認ください（たとえば、レコード追加時の重複エラーなどは、テスト実行では再現・確認することはできません）。
それぞれのアクション番号の表示
それぞれのアクション番号では、その結果を確認できます。
なお、実行データタブでは、各アクションは設定ファイル内の順序や実行順ではなく、アクション番号の昇順に並びますのでご注意ください。
テスト実行を途中のアクションで止める方法
アクション番号の隣りにある「テスト実行停止位置に設定する」をクリックすると、そのアクションが実行されたときにテスト実行が停止されます。これは、アクショングラフ上でも指定することが可能です。 これを利用すると、指定したアクションが実行されるタイミングで、ジョブ全体の実行が停止されます（停止するのはテスト実行の場合のみですので、ご注意ください）。
条件が満たされ、やることを実行する直前で停止しますので、複雑な条件を設定したような場合に、その条件が実行中に満たされているかどうかを確実に確認することが出来るようになります。
やることを実行する直前で停止するので、そのやることは実行されません。言い方を変えると、やることを「なにもしない」に変更し、そのときに実行を停止する、というような機能になります。
例えば上記のような設定をすると、アクション番号10番の条件が満たされたときに、ジョブは停止します。ジョブ実行ログの「実行データ」や「ログ」で、停止する最後の瞬間に処理していたレコードなどを確認することが可能です。
『終了時に処理をした』という概念について
前述の『終了時に処理をした』という概念について解説します。
例として、このように「レコード１行が準備できた時」で1行ずつすべてのレコードを書き換える、というカスタマイズで考えてみます（動作の説明のためのカスタマイズなので、あまり実用的ではないのですが）。
これをテスト実行すると、「終了時の処理対象レコード」には1行しか表示されていません。ここが先程と異なるポイントです。
これは、最終的に1行しか処理しなかったわけではなく、「終了時の処理対象レコード」が1行だった、ということになりますので、勘違いしないように注意してください。
動作原理的にいいますと、「レコード１行が準備できた時」で処理しているレコードは、それぞれ1行毎に別の世界に区切られており、ほかの世界の内容を見ることはできません。ですのでここでは、最後に処理された1行が、終了時の処理対象レコードとして表示されている、というわけです。
言い換えると、「終了時の処理対象レコード」とは、最後に「レコード○行が準備できた時」で準備・処理されたレコード、ということになります。
まとめ
この「テスト実行」機能により、Job Runnerのジョブ作成がより簡単になることを願っております！
ご不明な点がございましたら、チャットサポートまでお気軽にお問い合わせください。