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