Service Tests

Record 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 BPEL model.

Service testing guidelines

Before testing a service, you must set up your test environment and incorporate these guidelines to produce reliable tests.

Test prerequisites

Before creating service tests, you might need to perform some initial tasks. These tasks depend on the transport and security protocols that are implemented by the web service under test.

• HTTP: This transport method is supported by default; no additional configuration is required.
• SSL: The workspace must contain the certificate keystore (JKS) files required for single or double authentication.
• Java. Message Service (JMS): The Web Services Description Language (WSDL) syntax must be compatible with the requirements of the product.

Test generation

When the test is generated, message call envelopes are created according to the XML schema definition (XSD). During this process, mandatory fields are created, and default choices are assumed. You can modify these elements in the test editor.

Encryption and security

The Java Runtime Environment (JRE) that the workbench uses must support the level of encryption required by the digital certificate that you select. For example, you cannot use a digital certificate that requires 256-bit encryption with a JRE that supports only 128-bit encryption. By default, the workbench is configured with restricted or limited strength ciphers. To use less restricted encryption algorithms, you must download and apply the unlimited jurisdiction policy files (local_policy.jar and US_export_policy.jar).

You can download unlimited jurisdiction policy files from this site: http://www.ibm.com/developerworks/java/jdk/security/50/

Click on IBM SDK Policy files, and then log in to developerWorks to obtain the unlimited jurisdiction policy files. Before installing these policy files, back up the existing policy files in case you want to restore the original files later. Then overwrite the files in /jre/lib/security/ directory with the unlimited jurisdiction policy files.

SSL Authentication

Service tests support simple or double SSL authentication mechanisms:

• Simple authentication (server authentication): In this case, the test client needs to determine whether the service can be trusted. You do not need to setup a key store. If you select the Always trust option, you do not need to provide a server certificat key store.

  To really authenticate the service, you can configure an certificate trust store, which contains the certificates of trusted services. In this case, the test will expect to receive a valid certificate.

• Double authentication (client and server authentication): In this case, the service needs to authenticate the test client according to its root authority. You must provide the client certificate keystore that needs to be produced to authenticate the test as a certified client.

When recording a service test through a proxy, the recording proxy sits between the service and the client. In this case, you must configure the SSL settings of the recording proxy to authenticate itself as the actual service to the client (for simple authentication), and as the client to the service (for double authentication). This means that you must supply the recording proxy with the adequate certificates.

When using stub services, you can also configure the SSL settings of the stub service to authenticate itself as the actual server. This means that you must supply the service stub with the adequate certificate.

NTLM and Kerberos Authentication

The product supports Microsoft NT LAN Manager (NTLMv1 and NTLMv2) and Kerberos authentication. The authentication information is recorded as part of the test during the recording phase.

To enable NTLMv2 support, you must add a third party library to the workbench.

Digital certificates

You can test services with digital certificates for both SSL and SOAP security protocol. Digital certificates must be contained in Java Key Store (JKS) keystore resources that are accessible in the workspace. When dealing with keystore files, you must set the password required to access the keys both in the security editor and the test editor. For SOAP security you might have to provide an explicit name for the key and provide a password to access the private keys in the keystore.

If you are deploying tests to agent computers, these files must also be added to the JRE that the IBM Agent Controller uses.

Limitations

Arrays are not supported.

Because of a lack of specification, attachments are not supported with the Java Message Service (JMS) transport. The envelope is directly sent using UTF-8 encoding.

All security algorithms are not always available for every Java Runtime Environment (JRE) implementation. If a particular security implementation is not available, add the required libraries to the class path of the JRE that this product uses.

The generic service tester displays the envelope as reflected in the XML document. However, security algorithms consider the envelope as a binary. Therefore, you must set up the SOAP security configuration so that incoming and outgoing messages are correctly encrypted but remain decrypted inside the test.

Performance

Virtual user performance depends on the implementation of the container application. For an HTTP transport, the product has been tested with a maximum of 900 concurrent vusers under Windows and 600 under Linux. For JMS, the maximum is 100 concurrent vusers, although this number can vary due to the asynchronous implementation of JMS. Beyond these values, connection errors might occur and the transaction rate will decrease.

Verify 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.

1. In the project explorer or test explorer, locate and open the WSDL file for the JMS service to test. If necessary, you can import a WSDL file from the file system by clicking File > Import > File System.
2. Ensure that the following criteria are met in the syntax of the WSDL file used.
   • 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
3. 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>

Record 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.

If you are testing a SOAP-based web service, ensure that you have access to a valid Web Services Description Language (WSDL) file. The wizard can import WSDL files from the workspace, the file system, a remote repository, or from a URL. Ensure that the WSDL files use the correct syntax for the test environment. The generic service client might not work with some WSDL files.

If you are using SSL authentication, ensure that you have the required key files in your workspace.

If you are using SOAP security, ensure that you have configured the environment with the correct libraries and configuration files.

If the response in a recording or test generation is in XML and the size of the XML data is higher than the value set in the XML Message Received maximum length field, the response is automatically converted to text to avoid any memory issues. To convert the full response to text, the tool checks the value set for Text Message Received maximum length. If the value is lesser than the size of the response, the response is truncated. The response to be in XML when the response size exceeds the value set in XML Message Received maximum length, you can manually increase the value for both recording and test generation. To change the value for recording, click Window > Preferences > Generic Service Client > Message Edition. To change the value for test generation, click Window > Preferences > Test > Test Generation > Service Test Generation.

To use a WS-SecurityPolicy that is included in a WSDL or an external XML file, you need to configure the security policy If a recording contains the Security Assertion Markup Language (SAML) token, the WS Security policy file must rely on the Service Token Service (STS) that produces the token. This token can then be used for encryption or other purposes as was designed.

Sample policy file that relies on SAML token:

<sp:SupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:IssuedToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<sp:Issuer>
<Address xmlns="http://www.w3.org/2005/08/addressing">http://9.143.105.204:8080/axis2/services/STS</Address>
</sp:Issuer>
<sp:RequestSecurityTokenTemplate>
<t:TokenType xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</t:TokenType>
<t:KeyType xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</t:KeyType>
<t:KeySize xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">256</t:KeySize>
</sp:RequestSecurityTokenTemplate>
<wsp:Policy>
<sp:RequireInternalReference/>
</wsp:Policy>
</sp:IssuedToken>
</wsp:Policy>
</sp:SupportingTokens>

1. In the Performance Test perspective, click the New Test from Recording toolbar button or click File > New > Test from Recording.
2. In the New Test from Recording wizard, click Create a test from a new recording, select Service Test, and click Next. If you are recording sensitive data, you can select a Recording encryption level.
3. On the Select Location page, select the project and folder where you want to create the test, type a name for the test, and click Next. If necessary, click Create Parent Folder to create a project or folder
4. On the Select Location page, select Generic Service Client. This option uses the generic service client if you do not have access to a dedicated client for the service calls.
5. Click Next. If this is the first time you are recording a web service test, read the Privacy Warning, select Accept, and click Finish to proceed. The generic service client opens.
6. If your service uses a transport or authentication protocol that requires overriding the default settings, then click the Transport tab and create an HTTP, Java Message Service (JMS), or IBM WebSphere MQ transport.
7. Click the Requests tab.
   • Click Add a WSDL file to use a WSDL file from the workspace, to import a WSDL file, or to link to a remote WSDL file.
   • Select the Add an endpoint file to create a call to an HTTP, JMS, or WebSphere MQ service.
8. After creating the call, click the Edit Data arrow to change the details of the call if necessary.
9. Click the Invoke arrow to invoke the service call. If the call was successful, the response is displayed under the View Response arrow.
10. To record a test with multiple calls, repeat steps 6 through 9.
11. When you have finished sending service requests, stop the recorder. You can do this by closing the generic service client or by clicking the Stop push button in the Recorder Control view. If you changed the network settings of the client program, you can revert to the default settings before closing the program. The Generate Service Test wizard opens.
12. Click Finish.

Alternatively, you can Use the generic service client to create, edit, and invoke the calls without recording. Successful responses are added to the Request History list. You can select calls in the Request History list, and click the Generate Test Suite icon .

Record 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.

The following recorders are available for recording traffic from an application:

• SOCKS proxy recorder: Use this recorder when no proxy connections are required.
• HTTP proxy recorder: Use this recorder when a proxy connections is required to connect to the network or when the client program does not support SOCKS.
• Socket recorder: Use this recorder for low-level network traffic when the client does not support proxies. This recorder does not support SSL authentication or encryption of any kind and is only available if the IBM Rational Performance Tester Extension for Socket Protocols is installed.

Regardless of the recorder used, the client program must use the HTTP network protocol.

If you are using SSL, the HTTP or SOCKS proxy can cause authentication problems because the proxy recorder relays traffic between the client and the server. Depending on the authentication method in place, the client might require that the proxy recorder authenticate itself as the server and the server might require that the proxy recorder authenticate as the client. If the client program requires an authenticated server, you must either have access to the server certificate keystore and provide it to the proxy recorder or configure the client to accept the default certificate from the proxy recorder instead of the certificate from the actual server.

If you are testing a SOAP-based web service, ensure that you have access to a valid Web Services Description Language (WSDL) file. The wizard can import WSDL files from the workspace, the file system, a remote repository, or from a URL. Ensure that the WSDL files use the correct syntax for the test environment. The generic service client might not work with some WSDL files.

If you are using SOAP security, ensure that you have configured the environment with the correct libraries and configuration files.

To record a service test with a client program:

1. In the Performance Test perspective, click the New Test from Recording toolbar button or click File > New > Test from Recording.
2. In the New Test from Recording wizard, click Create a test from a new recording, select Service Test, and click Next. If you are recording sensitive data, you can select a Recording encryption level.
3. On the Select Location page, select the project and folder to create the test in, type a name for the test, and click Next. If necessary, click Create Parent Folder to create a project or folder
4. On the Select Client Application page, select the type of client program to use. The program type defines the recorder that can be used. The following client program types are supported for recording a service test:
   • Managed Application: This option starts a specified program and uses a proxy or socket recorder to record the traffic.

     On the Managed Application Options page, click Browse to specify the Program path. If necessary, specify the Working directory, and type the command line Arguments that the program requires.

     If the program requires user input from a command-line interface, select Open console for user input.

   • Microsoft Internet Explorer or Mozilla Firefox: This option records traffic that is sent and received with either web browser.
   • Unmanaged Application: This option enables you to record traffic from one or multiple client programs that use a proxy. You must manually start the client programs and the proxy recorder records all traffic that is sent and received through the specified network port.
   • Generic Service Client: This option uses the generic service client if you do not have access to a dedicated client for the service calls.
5. On the Recorder Settings page, depending on the type of client program you selected, specify these details:
   1. If you selected Managed Application, specify the recording method.
      • Select Record traffic with the proxy recorder to record HTTP or SOCKS traffic through a proxy.
      • Select Record traffic with the socket recorder to record low-level network traffic for applications where a proxy cannot be used. This recorder does not support SSL authentication or encryption.

      When using proxy recording, you can filter out HTTP or HTTPS requests to a specific endpoints so that any requests to those endpoints are not recorded.

   2. If you selected Record traffic with the proxy recorder, specify whether the proxy recorder uses HTTP or SOCKS. Select HTTP if a connection to proxy is required or if your application does not support SOCKS.
   3. If you are using SSL authentication, specify the authentication settings for the proxy recorder. During the recording, the proxy recorder is between the client and the server.
      • If the server requires client authentication, you must provide the client certificate keystore for the proxy recorder to be authenticated by the server as though the proxy recorder were the client. Select The server requires a specific client certificate. Specify the filename and password of the server certificate keystore. If multiple certificates are required, click Multiple certificates, and click Add to specify a certificate keystore file name and password for each host name and port.

        The keystore must contain the private certificate of the client.

      • If the client requires server authentication, you must provide the server certificate keystore for the proxy recorder to be authenticated by the client as though the proxy recorder were the server. Select The client requires a specific server certificate, and click Add to specify a certificate keystore filename and password for each hostname and port. If you do not select this option, the proxy recorder provides its own default certificate.

        The keystore must contain the private certificate of the server.

   4. If you selected to use the HTTP proxy recorder, specify how to connect to the network. If necessary, specify an HTTP or SOCKS proxy or point to a proxy auto-configuration (PAC) file. Use this option if you are connecting to the service through a corporate proxy or firewall.
6. Click Next. If this is the first time you record a service test and you did not select a web browser for the client application, read the Privacy Warning, select Accept, and click Finish to proceed.
7. If you selected a proxy recorder with a managed or unmanaged application, change the network settings of the client program to use the proxy recorder. The method for changing the network settings depends on the client program. However, you must be able to set the following proxy settings in the program:
   • SOCKS or HTTP proxy: Specify the protocol that you selected for the proxy recorder in the wizard.
   • Host name: Set to localhost.
   • Port: Specify the port number that you selected for the proxy recorder in the wizard.
   To avoid unexpected results, revert to the previous proxy settings before you stop the recording.
8. Use the client program to perform the actions to test. You can use the Recorder Test Annotations toolbar to add comments, record synchronizations, or take screen captures during the recording.
   • To add a comment to the recorded test, click the Insert comment icon .
   • To add a screen capture to the recorded test, click the Capture screen icon . Screen and window captures make your tests easier to read and help you visualize the recorded test. You can change the settings for screen captures and add a comment to the image.
   • To manually add a synchronization point to the recording, click the Insert synchronization icon .
   • To manually add a transaction folder to the recording, click the Start Transaction icon and Stop Transaction icon to start and stop the transaction.
   • To insert a split point into the recorded test, click the Split point icon . With split points, you can generate multiple tests from a single recording, which you can replay in a different order with a schedule.
9. After finishing the user tasks in the client program, stop the recorder. You can do this by closing the client program or by clicking the button Stop in the Recorder Control view. If you changed the network settings of the client program as described in step 8, you can revert to the default settings before closing the program. The Generate Service Test wizard opens.
10. If you inserted a split point during the recording, on the Destination page, specify the location for the split test or merge the split recordings together.
11. On the Service Test Generation Options page, if you are testing a SOAP-based web service, specify a Web Services Description Language (WSDL) file from the workspace or click Add to import a WSDL or to link to a remote WSDL file.
12. Click Finish.

Results

A progress window opens while the test is generated. On completion, the Recorder Control view displays the Test generation completed message, the test navigator lists your test, and the test opens in the test editor.

Create a service test from a BPEL model

You can use 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.

Tests are stored in test projects. If your workspace does not contain a test project, the test creation wizard creates one, enabling you to change its name. To store a test in a specific project, verify that the project exists before you record the test.

If you are using SSL authentication, ensure that you have any required key files in your workspace.

If you are using Java. Message Service (JMS), ensure that you have configured the environment with the correct libraries and configuration files. Ensure that the WSDL files use the correct syntax for the test environment.

If you are using SOAP security, ensure that you have configured the environment with the correct libraries and configuration files.

BPEL models must be synchronous. Asynchronous BPEL models are not supported.

Ensure that the BPEL models refer to the WSDL files in a valid import statement, for example:

<bpws:import importType="http://www.w3.org/2001/XMLSchema" location="foo.wsdl" namespace="http://foo"/> 

Relative file paths, such as: "../../foo.wsdl" are not supported.

Ensure that you have one or more valid Web Services Description Language (WSDL) files and the associated BPEL model in your workspace. Only the calls to services with a valid web service binding are taken into account. For example, if the BPEL model was produced in IBM Websphere Integration Developer, then services must be exported with the following web service bindings:

<bpws:invoke name="myOperation" operation="myOperation" partnerLink="IServicePartner" portType="ns3:IService" wpc:displayName="myOperation" wpc:id="20">

Only BPEL invoke activities are considered for generating tests. Any BPEL receive and reply activities are ignored.

Websphere Integration Developer does not generate the required soapAction attributes for the soap operations in the WSDL files. Please edit the generated WSDL files, as follows for every operation: <soap:operation soapAction=""/>.

To create a service test from a BPEL model:

1. In the Performance Test perspective, click File > New > Other > Test > Test Assets > BPEL to Web service test, and then click Next.
2. Click Browse to select a BPEL file from the workspace, and click Next.
3. On the Web service test generation page, change the number of paths by specifying how activities and sequences from the flow of the BPEL model are processed. Each path generates one test.
   1. In the Flow section, select how any concurrent sequences that are found in the flow will be converted into paths.
   2. In the Switch section, select whether to test otherwise activities from the flow.
   3. In the Throw section, select how throw activities from the flow are converted into paths.
   4. In the Invoke section, select whether to test inline catches inside invoke activities from the flow.
   5. Select Enable data correlation in generated tests to automatically create references in the generated test elements by propagating variables to the parameters of the web service call and message return elements.
4. Click Recount paths to update the number of paths to test, and click Next. One test is generated for each path.
5. For WSDL operations that are bound to multiple ports, you must select one port that is to be used for the test.

   Under each test that will be generated, the Operations list displays the WSDL operations that are bound to multiple ports.

   If no WSDL operations are displayed under the tests, this means that all operations are bound to a single port. In this case, skip step 6.

   1. In the Operations list, expand a test and select a WSDL operation that requires binding.
   2. In the Binding ports list, select the port to use to test the selected WSDL operation.
   3. Repeat steps a and b for each WSDL operation that requires binding.
6. Click Next.
7. Select a location and a name for the new folder where the tests generated from the BPEL model are created, and click Finish.

Results

A new folder is created in the Test Navigator containing the generated service tests. These tests are generated with default message content and must be edited with valid input values.

Create 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.

Tests are stored in test projects, which are test projects that include a source folder. You must create a test project before creating a test.

Ensure that you have a valid WSDL file in your workspace. Ensure that the WSDL files use the proper syntax for the test environment.

If you are using SSL authentication, ensure that you have any required key files in your workspace.

If you are using SOAP security, ensure that you have configured the environment with the proper libraries and configuration files.

1. In the workbench, click File > New > Other > Test > Test Assets > Service Test or click the New Service Test toolbar button.
2. Select a project and then, in Test file name, type a name for the test. The name that you type is the base name for the recording, test, and other required files. You see these files in standard Navigator or the Java. Package Explorer with their distinguishing suffixes, but you see only the simple (test) name in the Test Navigator.
3. Click Finish.
4. To add a web service call, select the test element in the test editor, click Add, and then select Web Service Request.
5. Select the WSDL file that corresponds to the call and click Finish.
6. Edit the web service request element and add all the required information to make a valid call.
7. Select the Protocol tab to configure the transport protocol for this call. If necessary, click Change to configure the transport protocol for the entire test, including proxy and HTTPS parameters.
8. On the web service call, click Update Return. This opens the Return Preview window, displaying the data that will be used to perform the call.
9. Click Update Test. This performs the web service call and creates a message return element with the return data. If a message return element already exists, then it is updated with latest return data. The message return test element enables you to implement data correlation and content-based verification points.

Create 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.

Tests are stored in test projects, which are Java. projects that include a source folder. You must create a test project before creating a test.

Ensure that you have a valid Web Services Description Language (WSDL) file for a WebSphere MQ service in your workspace.

If you are using SSL authentication, ensure that you have any required key files in your workspace.

If you are using SOAP security, ensure that you have configured the environment with the correct libraries and configuration files.

1. In the workbench, click File > New > Other > Test > Test Assets > Service Test or click the New Service Test toolbar button.
2. Select a project, and then, in Test file name, type a name for the test. The name that you type is the base name for the recording, test, and other required files. You see these files in the standard Navigator or the Java Package Explorer with their distinguishing suffixes, but you see only the simple (test) name in the Test Navigator.
3. Click Finish.
4. To add a service call, select the test element in the test editor, click Add, and then select Web Service Call.
5. Select the WSDL file that corresponds to the call, and click Finish.
6. Select the Protocol tab to configure the transport protocol for this call. On the Protocol page of the new call element, the MQ protocol is automatically generated with the values from the WSDL file. If necessary, click Change to configure the transport protocol for the entire test, including proxy and WebSphere MQ parameters.
   • If the WebSphere MQ server is running on the local computer, select Using local queue manager.
   • If the server is on a remote computer, clear Using local queue manager, and type the IP address or hostname, port, and client channel.
7. On the web service call, click Update Return. This opens the Return Preview window, displaying the data that will be used to perform the call.
8. Click Update Test. This performs the web service call and creates a message return element with the return data. If a message return element already exists, then it is updated with latest return data. With the message return test element, you can implement data correlation and content-based verification points.

Create a service test for a plain XML call

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.

Tests are stored in test projects, which are Java. projects that include a source folder. You must create a test project before creating a test.

If you are using SSL authentication, ensure that you have any required key files in your workspace.

If you are using SOAP security, ensure that you have configured the environment with the correct libraries and configuration files.

1. In the workbench, click File > New > Other > Test > Test Assets > Service Test or click the New Service Test toolbar button.
2. Select a project, and then, in Test file name, type a name for the test and click Next. The name that you type is the base name for the recording, test, and other required files. You see these files in the standard Navigator or the Java Package Explorer with their distinguishing suffixes, but you see only the simple (test) name in the Test Navigator.
3. On the Select Service Call Interface page, select whether you want to create a test using a plain XML call interface or a Web service call interface. If you select web service call interface, select or add a WSDL file and then, select port to which the call will be binded. Click Next.
4. On the Configure Protocol page, select either HTTP, JMS or WebSphere MQ as the protocol and then, specify the options for the selected Protocol configuration.
5. On the Select Root Element page, you can select an XSD and then, select a root element for the call.
6. Click Finish.

Change 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.

1. Click Window > Preferences > Test > Web Services Test Generation
2. Select the setting to change.

   Time out delay used for call

   This is the default time out for web service calls. If the web service does not respond within this period, an error is produced.

   Think time default value

   This is the default think time for generated tests.

3. After changing a setting, click Apply.