検査対象となるURLを記録するクロールの管理方法は大きく分けて3つの方法があります。
- ほぼ全ての画面を一気にクロールしてまとめる方法
- 細かくシナリオ単位でクロールする方法
- 修正頻度によってクロールを分ける方法
オススメは2か3のシナリオ単位でクロールする方法です。
次にそれぞれの利点、欠点を書きますので、お客様の環境に合わせてご検討ください。
(1)ほぼ全ての画面を一気にクロールしてまとめる方法
利点
検査したい全ての画面を全てクロール時にアクセスするため、最初の1回のクロール作業と検査も1回実行するのみで完了するため楽な方法です。
欠点
1回の検査範囲が広いため、検査完了までに時間がかかります。検査は対象画面のパラメータ数や、対象サーバからのレスポンス時間に大きく依存するため、検査対象画面が増えるほど検査時間も伸びます。
後から検査対象の画面が増えたり、既存画面の入力項目（パラメータ）が増えた場合には、再度クロール作業が必要になりますので、もう一度全ての画面のクロールが必要になります。（SeleniumなどのE2Eツールを使って自動化していればクロールは楽にはなります）
(2)細かく機能単位でクロールする方法（オススメ）
VAddyのクロール数に上限は設けていないので、機能単位でクロールを作成することをおすすめしています。
利点
１回の検査時間が短くなりますので、必要な箇所だけ素早く何回でも検査できます。開発中に修正・テストを繰り返す場合に便利です。
複数の機能をまとめて１つのクロールにまとめてしまうと一部の機能に変更があった場合でもクロール全体を作り直す必要があります。機能ごとにクロールを分けておけば、クロールの作り直しは変更があった機能に関連するもののみになります。
クロールを細かく分割すると、サイト全体を検査するときにはクロール単位に検査を実行する必要がありますが、クロール連続実行機能をご利用いただくと複数のクロールをまとめて連続実行することができます。
また、VAddyで配布しているコマンドツールを使って、複数のクロールの定期実行や連続実行など、お客様のスケジュールに合わせた診断を実施することもできます。複数クロールの検査の自動化方法は、こちらをご覧ください。
(3)修正頻度によってクロールを分ける方法
(1)と(2)の中間的な形で、アプリケーションの画面の改修頻度によってクロールを分ける方法です。
頻繁に画面の仕様が変わる（例えばフォームの項目が増える）ような箇所は(2)のように細かくシナリオを分け、画面仕様がほぼ変わらない箇所はまとめて1つのクロールにします。
利点
仕様変更がない画面はクロールの変更も発生しないため、1つのクロールにまとめることで検査回数が減って管理が楽になります。
仕様変更が頻繁な画面は、フォームの項目が増えるタイミングでその箇所だけクロールし直しすれば良いので管理が楽になります。
欠点
どの画面が仕様変更が少ないか考えてクロールしないといけません。この方法でも、結局シナリオを細かく分割する箇所が増えると(2)と同じ欠点が現れます。
【関連リンク】