テスト生成中に使用されるデータ相関アルゴリズムは既知のベスト・プラクティスに基づいています。 ただし、これらのベスト・プラクティスは絶えず進化しているため、自動データ相関中には、以下のようなさまざまなタイプのエラーが発生する可能性があります。
相関させる必要のある 2 つのパラメーターが異なる名前を保有する場合、自動データ相関はそれら 2 つのパラメーターが関係していることを認識しません。 例えば、この要求 http://www.example.com?id=12345 について考えます。 この要求を、ID=12345 ではなく、customer_ID=12345 を含むサーバー要求と相関させる必要があるとします。 この場合、ID パラメーターは customer_ID と相関させる必要があります。
通常、データ相関はサーバーから戻された応答値を後続の要求値にリンクします。自動相関アルゴリズムは、URL および POST データ内を検索して潜在的な一致を探します。しかし、パラメーターを戻す他のスキームも使用可能です。 例えば、この要求 http://www.example.com?id=12345 について考えます。 この要求を、ID=12345 ではなく名前とエンティティーのペア href name="customer_ID" entity="12345" を含むサーバー応答に相関させる必要があるとします。 この場合は、ID パラメーターを name="customer_ID" と、値 12345 を entity="12345" と相関させる必要があります。
パラメーターまたは値を、例えば JavaScript プログラムなどで計算されるためにテストでは名前が付いていない、以前のパラメーターや値と相関させる必要が生じる場合があります。 この場合、データを正確に相関させるには、そのパラメーターまたは値を計算する方法と場所を理解し、カスタム・コード・ブロックを使用する必要があります。カスタム・コードについて詳しくは、『カスタム・コードによるテストの実行の拡張』を参照してください。
例えば、Web アドレス http://www.example.com?login_stamp=12345_Apr_11_07 を考えてみます。ここで、login_timestamp の値はログイン ID と現在の日付を連結したものです。この場合、ログイン ID と日付を連結するカスタム・コードが必要です。
別の例として、サーバーがログイン ID と日付を別のエンティティー href "customer_id=12345" Date="Apr_11_07" として戻す場合を想定します。この場合、これらのパラメーターを別の参照に置き、カスタマー ID と日付を使用する次の要求で、個別に置換することができます。
自動データ相関はパターン・マッチングに基づいています。パラメーターまたはパラメーターの値は、正確に同じ、または似ている名前を持つ後続のパラメーターやパラメーターの値に相関します。 しかし、パラメーターの名前が正確に同じ、またはよく似ていても、実際にはまったく関係ない場合があります。この場合最良のケースでは、不要な相関が存在してもほとんど影響がない、または不適切な負荷が多少かかる程度です。しかし最悪の場合、アプリケーションは相関を予期していないため、再生中に問題が発生します。
データ相関を必要とするパラメーターは、テスト中に数多く現れます。 例えば、ユーザーのログイン時に最初に使用されるセッション ID パラメーターは、後続のすべての要求でも使用される可能性があります。テスト内のパラメーターの複数のインスタンスが同一でない場合は、相関アルゴリズムが誤ったインスタンスを使用する可能性があります。
通常、記録後の HTML 応答コンテンツは、<input type="username" name="User" id="aaa" value="John"/> のようになります。しかし、一部のアプリケーションは name 属性を動的に更新します。そのため、テストを再生すると、HTML 応答コンテンツは、<input type="username" name="idt020" id="aaa" value="John"/> のようになります。name 属性が動的に変更されるため、データ相関は発生せず、再生は失敗します。
そのような相関は、応答コード内の他の属性を相関させるための基礎として、ID ではなく name 属性を使用するツールに起因します。ID に基づいて応答を相関させるには、で、「オン」を選択します。