ブラウザ操作ログから堅牢なテストシナリオへ
手動でWebテストシナリオを作成するのは時間がかかり、ミスも起こりがちです。JMeterのプロキシ経由でブラウザ操作を記録すれば、実際のHTTPリクエストの順序を正確に捉え、数時間ではなく数分で現実的なパフォーマンステストの土台を築くことができます。
記録機能の核となるのが「HTTP(S) Test Script Recorder」です。これはプロキシとして動作し、ブラウザとWebサーバー間の通信を傍受します。適切な設定が、クリーンな記録を得るための鍵となります。
記録直後のデータには、画像、CSS、JavaScriptファイルといった静的アセットへのリクエストなどの「ノイズ」が大量に含まれています。これらを除外することが、効率的で的を絞ったテストシナリオを作成する第一歩です。
フィルタリングにより不要なサンプラーが大幅に減り、サーバーサイドのロジックに集中したテストが可能になります。
記録されたスクリプトは単なる出発点です。信頼性の高いテストにするためには、動的なデータを扱い、ユーザー入力をパラメータ化し、検証を追加する必要があります。これらは最も一般的に直面する課題です。
多くのアプリケーションでは、セキュリティのために動的トークン（CSRFトークンやセッションIDなど）が使用されます。記録されたトークンは一度のセッションでしか有効でなく、再実行すると失敗します。
「正規表現抽出」などの後処理要素を使い、サーバーのレスポンスから動的な値を抽出します。それを変数（例: `${csrf_token}`）に格納し、後続のリクエストで使用します。
記録には、ログイン時に使用した特定のユーザー名やパスワードがそのまま含まれます。複数のユーザーをシミュレートするには、これらの固定値を置き換える必要があります。
「CSV Data Set Config」要素を使用します。ユーザー情報を含むCSVファイルを作成すると、JMeterがそのファイルからデータを読み込み、各仮想ユーザーがユニークなデータ（例: `${username}`, `${password}`）でテストを実行できます。
デフォルトでは、JMeterは可能な限り高速にリクエストを送信しますが、これは実際のユーザー行動とは異なります。ユーザーは操作の合間に一時停止します（思考時間）。
「トランザクションコントローラ」内に「一様乱数タイマ」などを追加します。これにより、ステップ間に現実的なランダムな遅延が挿入され、より正確な負荷プロファイルが作成されます。
ステータスコードが「200 OK」でも、ページが正しいとは限りません。サーバーが成功コードと共にエラーページを返す可能性があります。テストではレスポンス内容の検証が必要です。
サンプラーに「Response Assertion」を追加します。ログイン後の「ようこそ、[ユーザー名]さん」や目的のページのタイトルなど、成功を確認するための特定のテキストが存在するかをチェックするように設定します。
記録されたリクエストがフラットに並んでいるだけでは、可読性が低く分析も困難です。関連するステップを「トランザクションコントローラ」でグループ化し、ユーザーの操作フローに沿った、クリーンで論理的な構造を作成しましょう。
タイマーを追加することで、サーバーへの瞬間的な過負荷を防ぎ、より自然なユーザーフローをシミュレートできます。このグラフは、タイマーがリクエストのペースを調整し、非現実的な初期スパイクではなく持続的な負荷を生み出す様子を示しています。
タイマーは、テスト期間を通じて安定した現実的な負荷パターンを作り出します。