10 April 2007 - 1.7 |
soapUI 1.5 provides extensive load-testing functionality allowing you to perform:
Any number of LoadTests can be created for a TestCase (using the TestCases "New LoadTest" popup-menu action), each with different strategies, assertions, etc. to validate/assess a TestCases and its TestSteps performance under different circumstances. LoadTests can be run both interactively in soapUI or from the commandline, allowing scheduled loadtests to be used for performance surveillance (for example).
Right click on a TestCase and selected "New LoadTest" (you can create any number of loadtests), this will open the following LoadTest view after prompting for a title:
The view is divided into 3 parts (top-down):
The log at the bottom has an additional tab showing the configured loadtest assertions:
When running a LoadTest, the configured assertions are applied and will generate an error in the log if not met:
Assertion errors can be double-clicked and will show a view displaying the entire request/response that failed the assertion;
A LoadTest is controlled by its limit (by time or number of requests), threadcount and strategy. There are currently 4 available strategies:
Since you can have multiple LoadTests for a TestCase, you can create several with different strategies / configurations. Also, you can run several tests simultaneously in soapUI so you can (for example) see how a Burst-strategy test affects the average time of a Simple strategy test
The toolbar actions include opening of 2 types of diagrams:
Both these are meant to be used for behavioural analysis, ie seeing trends over time. Exact values/legends are not shown;
A com.eviware.soapui.tools.SoapUILoadTestRunner
is available for running loadtests from the commandline,
the same arguments as described for the com.eviware.soapui.tools.SoapUILoadTestRunner
are valid, with the
introduction of -l<loadtest name>
, -r
for reporting and -f<folder name>
.
Failed results and error logs will be exported to text-files for viewing.
Functional testing has been enhanced in a number of ways, most notably by the introduction of a Properties teststep which can be used for global properties and of a Grooy teststep which allows you to do more or less "anything" in a testcase, for example data-driven testing, notifications, external integrations, etc...
Minor enhancements include:
The properties teststep allows you to define a number of properties which can further be loaded to/saved from a local file or URL (optionally specified by a system property). The defined properties can then be assigned/used from a groovy script or a ValueTransfer. The PropertiesStep editor is a simple table as follows:
The GroovyScript teststep allows you to execute an arbitrary Groovy script in your testcase. The script has full access to the soapUI object-model, allowing it to modify other teststeps, get external data, etc.
The shown script sets the property "boss" of another teststep to a "random" value