Home
Test Author Guide
This guide describes how to create test scripts in HCL OneTest™ Performance and enhances tests by applying different test elements such as dataset, variables, and verification points. This guide is intended for testers.
Editing tests
After you record a test, you can edit it to include datasets (to provide variable data rather than the data that you recorded), verification points (to confirm that the test runs as expected), and data correlation (to ensure that returned data is appropriate for the corresponding request). You can also add protocol-specific elements to a test. When you edit a test, the modified items appear in italic type. The italic type changes to regular type after you save the test.
Editing service tests
After you record a service test, you can edit the calls and message returns to include variable data (rather than the data that you recorded). You can add verification points (to confirm that the test runs as expected), transactions, conditional processing, and custom code.
Editing WSDL security profiles
To ensure that your service test uses the correct security protocols to access a SOAP-based service, you must specify a security profile for the (Web Service Description Language) WSDL file. After a security profile is set up, it can be reused in multiple web service calls.
Adding WS-Addressing to a security configuration
The WS-Addressing specification provides transport-neutral mechanisms that enable SOAP-based web services to communicate addressing information. You can use WSDL security algorithms to add WS-Addressing to your service tests.

Test Author Guide
This guide describes how to create test scripts in HCL OneTest™ Performance and enhances tests by applying different test elements such as dataset, variables, and verification points. This guide is intended for testers.
- Creating tests
  To create a test, you record representative interactions with an application.
- Editing tests
  After you record a test, you can edit it to include datasets (to provide variable data rather than the data that you recorded), verification points (to confirm that the test runs as expected), and data correlation (to ensure that returned data is appropriate for the corresponding request). You can also add protocol-specific elements to a test. When you edit a test, the modified items appear in italic type. The italic type changes to regular type after you save the test.
  - Editing HTTP tests
    After you record a test, you can edit it to include variable data rather than the data that you recorded and can include verification points to confirm that the test runs as expected. You can also edit the test to include [NB1] transactions, conditional processing, custom code, and standard header or custom header to a request or response.
  - Editing SAP tests
    After you record a test, you can edit it to include variable data (rather than the data that you recorded) and verification points (to confirm that the test runs as expected).
  - Editing Citrix tests
    After you record a test, you can edit it to include variable data (rather than the data that you recorded), verification points (to confirm that the test runs as expected), transactions, conditional processing, and custom code.
  - Editing service tests
    After you record a service test, you can edit the calls and message returns to include variable data (rather than the data that you recorded). You can add verification points (to confirm that the test runs as expected), transactions, conditional processing, and custom code.
    - Web service test editor overview
      With the test editor, you can inspect or customize a test that you recorded.
    - Verifying application behavior
      To check the expected behavior of the application during a service test, you can add verification points after a message return. During the run, verification points produce a pass, fail, error, or inconclusive status in the Web Service Verification Point report.
    - Working with Server Name Indication (SNI) recordings
      If you have recorded against a server that supports Server Name Indication (SNI), an extension of the TLS protocol, the recording session file displays true for the SNI Extension field. There might be a need for you to access both SNI and non-SNI applications from the same server. To run the same test without using the SNI extension, you can manually change the value to false.
    - Adding elements to a socket test
      A socket test provides the flexibility to add close, send, and receive elements to the test.
    - Managing JMS/MQ connections in a service test
      When you run a service test that includes JMS or MQ protocol, the socket connections are created and closed in the background. When you include multiple tests in a compound test or a schedule, in this context, is used to refer to both VU Schedule and Rate Schedule, multiple connections are created and closed. Starting from 9.2, when you run service tests in a schedule, you can select a pooling strategy for these JMS/MQ connections so that when the connections are created, they do not close and are reused subsequently for the other JMS/MQ calls, if required.
    - Editing WSDL security profiles
      To ensure that your service test uses the correct security protocols to access a SOAP-based service, you must specify a security profile for the (Web Service Description Language) WSDL file. After a security profile is set up, it can be reused in multiple web service calls.
      - WSDL security editor overview
        With the WSDL security editor you can create the SOAP algorithm stacks that are associated with a web service operation. Algorithm stacks contain digital certificate information and the security algorithms that are applied to messages to perform secure communication with a web service.
      - Creating security profiles for WSDL files
        You can create SOAP security profiles for the web service calls or message returns that require message encryption, signature or other advanced security algorithms.
      - Using a security policy
        The WS-Policy specification enables web services to use XML to publish their security policies either as part of the Web Services Description Language (WSDL) file (compliant with the WS-PolicyAttachment specification) or as a separate XML document. With the WSDL Security Editor, you can create a security profile that uses a policy that complies with the WS-Policy specification.
      - Adding security stacks
        To provide better WSDL security, you can make use of many security algorithms in the service test.
      - Implementing a custom security algorithm
        You can define your own security algorithms for SOAP security profiles by implementing custom security Java™ interfaces that can be used in the WSDL security editor. With custom security algorithms, you can implement proprietary security algorithms that transform the XML before sending and after receiving message content.
      - Adding WS-Addressing to a security configuration
        The WS-Addressing specification provides transport-neutral mechanisms that enable SOAP-based web services to communicate addressing information. You can use WSDL security algorithms to add WS-Addressing to your service tests.
    - Testing asynchronous services
      Use the asynchronous callback services for inter-object communications in a service test.
    - Creating a reliable messaging call structure
      You can create a test structure dedicated to testing service calls based on the WS-ReliableMessaging specification.
  - Editing Socket tests
    Improve the Socket tests by adding test elements.
  - Editing Kerberos tests
    You can change the Kerberos realm, user name, and password when editing tests.
  - Adding test elements
    You can add a variety of elements to a test, such as transaction blocks, IF-THEN conditions, loops, and comments.
  - Searching within tests
    Search request data or response content by right-clicking in the data or content and selecting Find. To search for specific element types and to display the results in a table, click Select. For a still more powerful search and replace, use the Test Search function.
  - Exporting a test
    To share the test scripts with manual testers or reviewers who do not have the workbench, export the test scripts to text files. You can export one file at a time.
  - Copying test assets with dependencies
    You can export test assets, and then import them into another project or workspace without losing any dependencies. Test assets include projects, schedules, and tests. You can export and import test assets to collaborate with other testers.
  - Disabling portions of a test
    When you disable portions of a test, you can still see the disabled portion, but it is not executed during a run. You can also disable portions of a schedule by using the following procedure.
  - Running test elements in random order
    You can record multiple user scenarios in a test and then run each scenario in a random order. To do this, you put each scenario under a random selector and then select the proportion of time that the scenario should be run.
  - Renaming test assets
    As your test assets increase and become more complex, you might want to rename them. Use the Eclipse Rename function or save the assets under a different name.
  - Deleting test assets
    As your test assets grow and become more complicated, you might want to delete the assets that you no longer use.
  - Debugging custom code for tests and compound tests
    If you have custom code added to a test or a compound test, you can debug the custom code for any errors by clicking the Debug button.
  - Providing tests with variable data (datasets)
    You can produce more realistic tests by changing them to use datasets. During execution, a test that uses a dataset replaces a value in the recorded test with variable test data that is stored in the dataset. This substitution allows each virtual user to generate a different request to the server.
  - Test variables
    A test variable is a user-defined, name-value pair that stores and refers to information throughout a test and between tests.
  - Correlating response and request data
    For a test to run correctly, a request that is sent to a server might need to use a value that was returned by a previous request. By ensuring that this data is correlated accurately, you can produce better performance tests.
  - Data transformation
    You can transform HTTP application specific data such as binary data and encoded data to a more readable format to use data correlation.
- Compound tests
  You can create compound tests to help you organize smaller tests into scenarios that can then be run end-to-end. You can combine tests from different extensions to achieve end-to-end flow.
- Simulating services with stubs
  Service stubs enable you to simulate the behavior of an actual service for a wide variety testing or integration purposes.
- Sending service requests with the generic service client
  The generic service client enables you to send requests to services for which you do not have a convenient client and to view the responses returned by the service.
- Emulating workloads
  You emulate a workload by creating a schedule and adding user groups/rate runner groups, tests, and other elements to it.

Adding WS-Addressing to a security configuration

The WS-Addressing specification provides transport-neutral mechanisms that enable SOAP-based web services to communicate addressing information. You can use WSDL security algorithms to add WS-Addressing to your service tests.

Before you begin

Before adding WS-Addressing to a security configuration, you must have a service test with requests and responses that are related to a valid WSDL.

Procedure

To add WS-Addressing to a WSDL security algorithm:

Open the test, select a service request, and in the Raw Transaction Data view, select Enable the display of the XML document after the security processing.
On the Request Stack page, click Edit WSDL Security .
Tip: If you need to edit separate security or processing algorithms for incoming responses, click Show Response Stack to add a Response Stack page to the editor.
The WSDL security editor opens.
Select the Algorithm Stacks page of the WSDL security editor, and in the Security Algorithm list, select or create a security algorithm.
In the Stack Contents list, click Add > WS-Addressing and specify the settings that are implemented by the service.

WS-Addressing Algorithm

Use this block if your service uses either WS-Addressing 2004/08 or the WS-Addressing 1.0 Core standard.

Namespace

Specify the namespace for either WS-Addressing 2004/08 or WS-Addressing 1.0 Core.

Action if request uses WS-Addressing

Select the action to complete if WS-Addressing is already in the request.

Replace anonymous address in Reply-to with:

Select this option to generate the specified address in the Reply-to header instead of an anonymous address.

Remove WS-Addressing from response

Select this option to strip any WS-Addressing headers from the response.
Save the WSDL security algorithm, and select the test editor.
The WS-Addressing namespace and header XML content is displayed in the Raw Transaction Data view.