You can configure LoadComplete to correlate dynamic parameters in your scenarios automatically. However, in several cases, you may need to correlate the data manually.
Parameters that LoadComplete cannot correlate automatically
Dynamic parameters that have different names in responses and requests. If the names differ, LoadComplete does not “know” where to insert the data extracted from the server response.
Dynamic parameters that have the same name, but different values in responses and subsequent requests. The difference in values can mean the parameter value is changed on the client side.
The way, in which the data is changed, depends on the client application or script. LoadComplete cannot detect such changes, and, therefore, cannot correlate such requests automatically.
Parameters in semantic URLs.
For example, a web application can include dynamic parameters (like
userID) returned by the server to the web page’s URL:
LoadComplete’s empirical search algorithms do not detect the dependence of semantic URLs on response data. To correlate parameters in semantic URLs, you can create correlation rules or correlate the parameters manually.
How to correlate data in requests and server response data manually
1. Find parameters to correlate
If possible, ask the tested application’s developers about dynamic parameters used.
To find dynamic parameters, explore the recorded scenario in the Scenario editor:
Verify the recorded scenario.
Check whether the tested application worked as you expected, for example, whether a user could log in or add database entries successfully, the server returned the appropriate data and so on.
Examine the request and response data in the test log, check if the request list in the Details panel contains errors or warnings.
If you find out the application did not work properly, this may mean that it uses dynamic parameters you need to correlate.
Find the failed requests and examine their parameters. Learn what parameters are dynamic.
Typical examples of dynamic parameters are –
Session or client IDs used to identify the user during the session.
Database record identifiers added to the tested database and that then change during the test run.
Prices or product IDs in e-commerce applications.
Depending on the way the application passes parameters, search for them in –
The request’s header fields. You can find them in the Request Header panel of the request editor.
Pay attention to the first line of the header (the line that includes the web page’s URL). This line has the Request name in the Request Header panel.
The Request Body tab of the Request page or the Message Contents tab of the WebSocket Message page.
You can ask the application’s developers about the technology used.
2. Extract dynamic parameter values to variables
Define rules for extracting the dynamic parameter value to a variable.
1. Find responses that contain the parameter value generated by the server
For each dynamic parameter used in the scenario’s requests, find the first response that includes the generated parameter value. Parameters are typically included in the web page text or source code, therefore, pay attention to responses that correspond to web pages.
For Rich Internet Application scenarios, find the needed parameter in the table on Response Body page.
|You can group requests in the scenario by pages to have web page requests and responses distinguished more easily.
You can also use the search to find the needed response by the dynamic parameter name.
Be sure to find the first response that contains the data generated by the server. Otherwise, only part of your requests will correlate with the response data.
2. Save the parameter value to a variable
Once you have found the needed response, extract the parameter value to a variable:
For Rich Internet Application scenarios, select the needed parameter on the Response Body page and specify the variable that will store the parameter value.
For more information, see Extracting Data From Responses.
3. (Optional) Modify the extracted parameter
If the dynamic parameter received from the server is changed on the client side before it is used by subsequent requests, modify the parameter to match the data that the tested server expects.
4. Replace recorded values with variables
Replace the recorded parameters in requests with the variables holding the extracted data:
|Note:||Be sure to use the appropriate values. See Specifying Appropriate Request Data.|
After you specify data correlation rules, the Scenario editor shows the dependency between the requests and responses.
5. Ensure the scenario plays back correctly
Verify the scenario to make sure that you have created the correlation rules correctly.
|If the structure of a response returned by the server during the test run differs from the structure of the same response obtained during test recording, LoadComplete will fail to retrieve parameter values from the response. It will not save the values to variables and the correlation rules will fail.|
6. (Optional) Create an automatic correlation rule from a data replacer
After you add a data replacer to the Data Replacers panel, you can create a correlation rule from this replacer. LoadComplete will apply this rule automatically when it correlates responses and requests next time.
To create a rule, in the Data Replacers panel, simply right-click your data replacer and select Create Rule from the context menu:
|Note:||The replacer’s type should be User. Creating a correlation rule for other replacer types is meaningless.|
You can see the created rule in the Tools > Options > Recording > Data Correlation dialog, under the Converted node: