HTTP プロトコルはその性質上、ステートレスとなります。 HTTP は単純なリクエスト/レスポンス パラダイムに従います。 クライアント (サーバーとの通信に HTTP を使用するブラウザまたはアプリケーション/アプレット) はサーバーに対して TCP/IP 通信を開き、リクエストを送信し、サーバーからのレスポンスを受信します。 同一サーバーに対する同一のクライアントからの異なるリクエストは、同じ TCP/IP 接続経由または別の接続経由のいずれの場合も、お互いに関係性を持ちません。
一方、Web アプリケーションの場合は、単一のリクエストを、完全な HTML ページ、Web サーバーで開始されたユーザー セッション、ショッピング カート、登録済みの顧客といったより大きなエンティティに埋め込む必要があります。
そのためには、サーバーからクライアントに状態情報を転送する手段が必要となります。それにより、後続の HTTP リクエストでその情報を返すことができ、サーバーはリクエストを特定のユーザー セッション (登録済みの顧客が使用する仮想ショッピング カートなど) に関連付けて適切に応答することができます。
Web アプリケーションが状態情報の転送に使用する技術は Web ブラウザでも使用することができます。
有用な結果を配信する負荷テスト プロジェクトでは、実際のブラウザを使用した実際のユーザーによる Web サーバーへのアクセスをシミュレートする必要があります。 シミュレートを行わなければ、結果は無意味となります。
結果が無効となる場合がある - コンテキスト管理が不十分な場合、負荷テスト スクリプトで、他の問題が発生する中、各仮想ユーザーが同じセッションにログインし、同じアカウントを使用したり、同じショッピング カートを使用したりする結果になることがあります。 そのような場合、Web/アプリケーション サーバーへの影響は、実際のアプリケーションで発生すると考えられる同程度の負荷とはまったく異なるものになります。 よって、テスト結果は無意味となります。
エラーが気づかれないまま進む - 多くの場合、Web サーバーでは、エラー通知時に、HTTP ステータス コードが適切に使用されないことがあります。 代わりに、成功を示す HTTP ステータス コードが返され、アプリケーション レベルのエラー条件 (「サーバー過負荷」や「セッション タイムアウト」など) は HTML ドキュメント内に記述されます。 スクリプトの次の命令が前の結果を参照しない場合 (たとえば、必要なリンクが存在する場合) 、そのようなアプリケーション レベルのエラーは気づかれないまま進んでいきます。 何千もあるログ ファイルの中の何百万行ものコードをテスト担当者が調べて、そのようなエラーを見つけ出すことは不可能です。
そのため、コンテキスト管理によるサポートは、「自動検証」スクリプトを提供することで、エラー検出の向上に直接貢献しています。
スクリプトが再生できない - 詳細なコンテキスト管理の自動検証関数で見つかる再生エラーは生産的なものもありますが、コンテキスト管理が不適切であると、問題のある再生エラーが発生し、手動による面倒なカスタマイズが必要となったり、スクリプトをデバッグするために QA 要員を動員する必要が生じたりします。
詳細なコンテキスト管理を使用すると、そのような煩わしさが排除され、生産性の向上とテスト コストの削減につながります。