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.
Creating tests
To create a test, you record representative interactions with an application.
Recording service tests
When you record a test, the test creation wizard records your interactions with the service, generates a test from the recording, and opens the test for editing. You can record a test session by invoking service calls with the generic service client or by using an existing client. You can also create a service test manually or from a Business Process Execution Language (BPEL) model.
Verifying WSDL syntax compliance for JMS services
Various Java™ Message Service (JMS) providers vary in the syntax used for describing services. Before testing JMS services, you must ensure that Web Services Description Language (WSDL) files comply with the requirements of the tool.

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.
  - Performance testing tips
    Use these tips to make HCL OneTest™ Performance run faster and more efficiently.
  - Creating a project
    The tests that you create, and the assets associated with the tests, reside in a project on your desktop. You can create the project separately, or you can simply record a test, which automatically creates a project named testproj.
  - Recording HTTP tests
    When you record a test, the test creation wizard records your interactions with a web-based application, generates a test from the recording, and opens the test for editing. You can record tests from Internet Explorer (which is the default on Windows™) or from another browser.
  - Recording SAP tests
    When you record a test, the test creation wizard records your interactions with the SAP server, generates a test from the recording, and opens the test for editing. You can record tests from the SAP GUI. You can also record SAP batch input tests that can be used to produce a heavy load on the server while minimizing the processing requirements for virtual testers.
  - Recording Citrix tests
    When you record a test, the test creation wizard records your interactions with the Citrix server, generates a test from the recording, and opens the test for editing. You can record a test session in the Citrix XenApp client.
  - Recording service tests
    When you record a test, the test creation wizard records your interactions with the service, generates a test from the recording, and opens the test for editing. You can record a test session by invoking service calls with the generic service client or by using an existing client. You can also create a service test manually or from a Business Process Execution Language (BPEL) model.
    - Service testing guidelines
      Before you can test a service, you must set up your test environment and incorporate these guidelines in order to produce reliable tests.
    - Verifying WSDL syntax compliance for JMS services
      Various Java™ Message Service (JMS) providers vary in the syntax used for describing services. Before testing JMS services, you must ensure that Web Services Description Language (WSDL) files comply with the requirements of the tool.
    - Configuring the environment for SOAP security
      SOAP security profiles require access to the libraries that implement encryption, signature, and other security algorithms that transform the XML messages before sending and after receiving them. You must prepare an environment with these libraries to use SOAP security, set the class path of the Java™ Runtime Environment (JRE) that Eclipse uses, and set the class path of the virtual machine that the Agent Controller uses.
    - Recording a service test with the generic service client
      You can record a service test by invoking service requests with the generic service client. After you have sent the requests and received the responses from the service, select the results in the History section of the generic service client to generate a test. If you do not have access to a dedicated client for the service calls, the generic service client is the easiest way to generate the calls and to record a test.
    - Recording a service test through a client program
      You can record tests for SOAP-based, XML, plain text, or binary services with any client program that uses the HTTP protocol. To record the test, the recorder intercepts the service calls and message returns between the client and the service. You can choose between an HTTP or SOCKS proxy recorder or a low-level socket recorder, depending on the capabilities of the client program.
    - Preparing to record a test for the HTTP/2 service
      To test a web service that is based on the HTTP/2 protocol, record a test by using the SOA extension of HCL OneTest™ Performance. Before recording the HTTP/2 service, follow the procedure in this topic to configure your computer.
    - Creating a service test from a BPEL model
      You can use Business Process Execution Language (BPEL) resources from your workspace to automatically generate a set of service tests that corresponds to the paths that are run in a synchronous BPEL model.
    - Creating a service test manually
      You can create a service test without recording by simply adding the test elements as required and manually editing the test element details in the test editor.
    - Creating a service test for WebSphere® MQ
      You can create an IBM® WebSphere® MQ test by adding the test elements as required and editing the test element details in the test editor.
    - Creating a service test for WebSphere Java MQ
      To test Java-based applications, create a service test and add the WebSphere Java MQ messages. You can create a service test by using Generic Service Client option or the New Service Test wizard .
    - Creating an XML call test manually
      You can create a test for a plain XML call over HTTP, JMS, or IBM® WebSphere® MQ, by simply adding the test elements as required and editing the test element details in the test editor.
    - Changing service test generation preferences
      You can change default test generation values by changing the preference settings. The default settings, however, are appropriate for recording in most cases.
  - Recording socket and TN3270 tests
    When you record a test, the test creation wizard records your interactions with the application under test, generates a test from the recording, and opens the test for editing.
  - Digital certificates overview
    The digital certificates feature enables you to run tests against servers that use Secure Sockets Layer (SSL) for applications that require client-side digital certificates to authenticate users.
  - Kerberos overview
    You can run HTTP tests against servers that use the Kerberos protocol for authentication.
  - Annotating a test during recording
    You can add comments, add transactions, or change a page name while you record a test. The advantage of adding these elements during (rather than after) recording is that you can place the annotations in the test exactly where you want. In addition, because annotations are part of the recorded test, they are regenerated when you regenerate the test. You can also insert split points into a test during record.
  - Recording sensitive session data
    You can keep recording session (.recsession) files to view the contents of a recording or to regenerate tests. However, if a recorded test contains sensitive information, you can choose to obfuscate, or encrypt, text strings in the recsession file.
  - Splitting a test during recording
    You can insert split points when you record a test. Split points allow you to generate multiple tests from a single recording that you can replay in a different order with a schedule.
  - Generating a new test from a recorded session
    You can generate a new test from a recorded session. For example, if you accidentally damage a test during editing, or if you want to change a test preference, you can regenerate the test instead of re-recording it. If split points were inserted in the recording, you can choose to generate a single test without split points.
  - Organizing test assets by type
    By clicking an icon, you can view your test assets in a logical order, in separate folders for tests, schedules, results, locations, and datasets.
- 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.
- 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.

Verifying WSDL syntax compliance for JMS services

Various Java™ Message Service (JMS) providers vary in the syntax used for describing services. Before testing JMS services, you must ensure that Web Services Description Language (WSDL) files comply with the requirements of the tool.

Procedure

In the project explorer or test explorer, locate and open the WSDL file for the JMS service that you want to test.
If necessary, you can import a WSDL file from the file system by clicking File > Import > File System.
Ensure that the following criteria are met in the syntax of the WSDL file that you use.
- Namespace: xmlns:jms="http://schemas.xmlsoap.org/wsdl/jms/"
- SOAP bindings are set to: transport="http://schemas.xmlsoap.org/soap/jms"
- JMS transports are defined either as a URL or as jms:address element
If the WSDL file is not compliant, edit the file so that it meets the criteria, and then save and close the file.

Example

For example, a JMS defined as a URL looks like this:

<soap:address location="jms:/queue?jndiConnectionFactoryName=UIL2ConnectionFactory;
             jndiDestinationName=queue/testQueue;
             initialContextFactory=org.jnp.interfaces.NamingContextFactory;
             jndiProviderURL=9.143.104.47"/>

A JMS defined as an address looks like this:

<jms:address destinationStyle="queue" 
             jndiConnectionFactoryName="myQCF"
             jndiDestinationName="myQ"
             initialContextFactory="com.ibm.NamingFactory" 
             jndiProviderURL="iiop://something:900/">
</jms:address>