SOAtest web scenarios, including tests that are automatically-generated when you record from a browser and tests manually added with the Browser Playback tool, are designed to run in a browser. Load tests, however, don’t run in a browser. As a result, some configuration is necessary to reuse functional web tests in a load testing environment—where web tests are conducted by sending requests to the server.
SOAtest automatically configures your browser-based functional tests for load testing. It also validates them by executing them in a simulated load testing environment. This significantly reduces the setup required to create meaningful web load tests, and helps you to identify and resolve any potential load test issues before the load testing efforts actually begin.
This topic explains how to prepare your web scenarios for load testing. Sections include:
We recommend that you configure your tests for load testing as described in Configuring Tests and validate that they will work properly as described in Validating Tests.
However, if you do not want to run the configuration step (e.g., because you have already configured the tests and do not want to overwrite any manual configurations you added), configuration is not required as long as the validation step passes.
The Load Test perspective is designed to help you prepare your web scenarios for load testing. Choose Window> Perspective> Open Perspective> Parasoft Load Test to open the Load Test perspective.
This perspective is similar to the SOAtest perspective, but it also provides the following features:
Load tests take the set of requests that the browser test would use and sends those results outside of the browser context. Sometimes, browser requests become invalid when they are re-submitted outside of the browser—for instance, because a request contains session-dependent information such as session ID. In these cases, configuration is required. To facilitate configuration, SOAtest identifies such issues and automatically configures the requests to run in the browser-less load test environment.
In the configure mode, SOAtest:
This configuration is required when either:
Configuration will re-create all the existing load testing requests based on the application’s existing state. As a result, any existing load test configurations you have set up in SOAtest (for example, if you manually configured the URL or request body to be set using parameterized or scripted values) will be overwritten. |
Run the automated configuration as follows:
Next, validate tests as described in Validating Tests.
If you double-click on a Browser Playback tool in the Load Test Explorer (available in the Load Test perspective), you will see a special configuration panel that displays a list of the requests that the test is supposed to make. It shows both the URL, HTTP method, and request body, and allows you to modify these if desired. You can also add and remove requests using the controls on the right of the configuration panel.
Note that the method to invoke can be specified as a fixed value, parameterized value, or scripted value.
For details about parameterizing values, see Parameterizing Tests with Data Sources, Variables, or Values from Other Tests.
For details about scripting values, see Extensibility and Scripting Basics.
With fixed values, you can access data source values using ${var_name} syntax. You can also use the environment variables that you have specified. For details about environments, see Configuring Testing in Different Environments
If you want to use a dynamic value for any part of the request, you can parameterize requests with values from a data source or values extracted from another test—or with values resulting from custom scripting or fixed values.
To do this:
Note that if your functional test is already configured to use parameterized values, the configuration step will set up the tests so that the parameterized values will also be used for load testing.
When running the “Configure for Load Test” step, SOAtest executes the test suite twice and performs three kinds of automated configuration:
When you validate tests, SOAtest will run them in load testing mode and alert you to any outstanding issues that might impact your load testing—for example, incorrectly configured HTTP requests. This way, you can resolve these issues before the actual load testing begins.
Run the automated validation as follows:
If the validation succeeds, the Validate for Load Test tab will report that the test suite is ready to be used in Load Test.
If a potential issue is detected, it will report that n issues need to be resolved before this test suite can be used in Load Test. You can then review the reported issues in the Quality Tasks view.
To better determine what is occurring at each test step, you can have SOAtest display what happens when the load test requests are rendered in a browser. To do this, double-click the Browser Contents Viewer added to the related test.
This is especially helpful if you want to visualize why the test is not producing the expected results. For example, the rendered page might reveal that the login is not occurring properly. Using this tool, along with examining error messages, helps you identify and resolve the cause of problems.
During validation, SOAtest determines if any configuration needs to be done on the scenario—either automated configuration (by SOAtest) or manual configuration. If validation does not succeed, this indicates that you need to run the configuration step or—if you have already run the configure step—that you need to manually configure parameters.
If the dynamic parameters could not be auto-configured by “Configure for Load Test”, one or both of the following will happen:
If such issues occur, run “Configure for Load Test”. If “Configure for Load Test” has already been run and these errors are still occurring, you may need to manually configure the HTTP requests and/or parameters causing the problem.
There is one class of dynamic parameter values that SOAtest cannot configure automatically: values that are normally constructed or transformed by JavaScript in the browser. Since the (transformed) parameter values do not exist in any of the HTTP responses, SOAtest cannot extract them to be used where necessary in any HTTP requests.
These parameters need to be configured manually. Validation will alert you when these kinds of dynamic parameters are present and are required by the web application to be updated for each session.
Use the procedure described in How Do I Parameterize or Script Request Values.
Here is an example of a parameter that passes the current time to the server. This is a dynamic parameter, constructed by JavaScript, that is not present in any of the previous HTTP responses. It has been manually configured to be parameterized using a script that calculates and returns the current time.
As mentioned above, the browser is not used when load testing a web scenario. Instead, Load Test sends a series of requests to simulate the result of a user action in the browser. Thus, if you want to send binary data in the browser request, you need to configure the test so that Load Test does not send the contents as text. The most common use case would be when you need to submit a binary file through a web page.
After recording the scenario, first run the scenario using the "Configure for Load Test" Test Configuration" (as described in Configuring Tests). This will configure the scenario with dynamic parameters needed to make the request during load testing.
For example, assume that you are uploading a PDF binary file. Normally, if you submit a file through a web page, the request will use a Content-Type of "multipart/form-data", where the request body will look something like this:
-----------------------------7d9271373005fa Content-Disposition: form-data; name="comment1" first comment -----------------------------7d9271373005fa Content-Disposition: form-data; name="binaryFile"; filename="binary.pdf" Content-Type: application/pdf the contents of the file which will contain binary data if this is a PDF file -----------------------------7d9271373005fa Content-Disposition: form-data; name="comment2" second comment -----------------------------7d9271373005fa Content-Disposition: form-data; name="submit" submit -----------------------------7d9271373005fa-- |
To configure this example:
In the test’s Request Body tab, highlight the contents of the file and click Parameterize Selected Text.
If the PDF file is large, the contents might not fit in the text box that displays the request body. In that case:
|
fileContents and use a Scripted value.
For the scripted value, use the following Jython code (substituting your own path to the binary file).
from com.parasoft.api import IOUtil
from java.io import File
def readBinaryFile(context):
binaryFile = File("c:\\tmp\\binary.pdf")
return IOUtil.readBinaryFile(binaryFile) |
The scripted value must return a value of type byte[]. This is a Java type: you cannot return a Jython array. To create the byte[] value, you can use the utility method IOUtil.readBinaryFile(). You can also return a Jython jarray. (See the Jython documentation for more information on how to create a jarray object.)
Your request body should now use the parameterized ${fileContents} value:
-----------------------------7d9271373005fa
Content-Disposition: form-data; name="comment1"
first comment
-----------------------------7d9271373005fa
Content-Disposition: form-data; name="binaryFile"; filename="binary.pdf" Content-Type: application/pdf
${fileContents}
-----------------------------7d9271373005fa Content-Disposition: form-data; name="comment2"
second comment
-----------------------------7d9271373005fa Content-Disposition: form-data; name="submit"
submit
-----------------------------7d9271373005fa-- |
Now the contents of the PDF file will be sent as binary data when you either run the scenario in Load Test or when you run the scenario in SOAtest using the "Validate for Load Test" Test Configuration.
Sometimes Validate for Load Test fails because the server requires an HTTP header to be present for any requests that it receives—but this header is actually absent. In such cases, you can add a global custom HTTP header to be sent along with requests during a web browser load test.
This is done by calling the BrowserTestUtil.addHttpHeader() method (which is documented in SOAtest's public API) in an Extension Tool within the context of the scenario in which you need to add the header. Be sure to position this Extension tool before the tests that you want to add that header. The header will be added to all scenario tests that are executed after the Extension tool is executed.The header will be added for any requests that these tools make during the load test.
If you have multiple scenarios, add this Extension tool into each scenario. In such cases, we recommend defining this Extension Tool once as a global tool, and then adding it into the various scenarios where you want to use it. Or, you can create a .tst with it and access it as a reference .tst file.
Here is a sample Jython script that sets such a header:
from com.parasoft.api import *
def addHeader(x, context):
BrowserTestUtil.addHttpHeader("HeaderName", "HeaderValue", context) |
Note that this example uses Jython for the sake of simplicity, However, since this Extension tool will be used in the context of a load test, defining the script in Java will deliver the best performance:
In some cases, Google Web Toolkit applications append a custom HTTP header to all HTTP requests to prevent a security problem known as cross-site request forgery (XSRF). For example, this is done in applications using the smart-gwt toolkit. The custom header, which is called X-GWT-Permutation, is added to the request through GWT's JavaScript libraries.
In such situations, performing Validate for Load Test on GWT applications might cause a failure such as 500 - Internal Server Error Looking at server-side logs, you might see the following error logged:
java.lang.SecurityException: Blocked request without GWT permutation header (XSRF attack?)This happens because JavaScript does not get executed in a load test context—and without JavaScript execution, the X-GWT-Permutation header does not get set as part of the requests.
To remedy this, write a short script to add this header so that it gets sent along with all requests during a load test. To do this, add an Extension Tool before the first test in the scenario that fails because this header is absent.
X-GWT-Permutation.