Home
Test Execution Specialist Guide
This guide describes tasks that you can perform on schedules, test execution with custom code, and Extending HCL OneTest™ Performance to support other protocols. This guide is intended for testers or test execution specialists.
Extending HCL OneTest™ Performance to support other protocols
The HCL OneTest™ Performance Extensibility Software Development Kit (SDK) enables you to create extensions to support testing new protocols without modifying the core product code. You can create an extension that provides functionality for testing other protocols in addition to the HTTP protocol support that is standard in HCL OneTest Performance.
Extending the run-time environment
The run-time environment defines the plug-ins on which all other plug-ins depend. The run-time environment is responsible for defining a structure for plug-ins and the implementation detail behind them.
Extending subsystem management during a test run
A subsystem is a collection of classes in a discrete component within the performance testing engine that provides a service to many actions. For example, in test execution, the KernelWait subsystem manages think and sleep time for virtual users while a test is running.
SampleAction.java code sample
This is an example of SampleAction.java.

Test Execution Specialist Guide
This guide describes tasks that you can perform on schedules, test execution with custom code, and Extending HCL OneTest™ Performance to support other protocols. This guide is intended for testers or test execution specialists.
- Running schedules with performance testing
  After you have added the user groups, tests, and other items to a schedule, and you are satisfied that it represents a realistic workload, you run the schedule.
- Extending test execution with custom code
  You can extend how you run your tests by writing custom Java™ code and calling the code from the test. You can also specify that results from the tests that are affected by your custom code be included in reports.
- Extending HCL OneTest™ Performance to support other protocols
  The HCL OneTest™ Performance Extensibility Software Development Kit (SDK) enables you to create extensions to support testing new protocols without modifying the core product code. You can create an extension that provides functionality for testing other protocols in addition to the HTTP protocol support that is standard in HCL OneTest Performance.
  - Protocol extension structure
    Before organizing your extension, note the restrictions and guidelines provided in this topic.
  - Extending the test recorder
    To generate a test, the data exchanged by an application and another entity such as a server must be recorded. The recorded data is then processed to generate a test.
  - Extending the test generation framework
    Test generation consists of processing the recorded data and producing a test.
  - Contributing annotations
    An annotation is an action that a user performs during a recording session. Annotations are used to document or structure the test generated from the recording.
  - Extending the load test behavior model
    The load test behavior model (LTBM) is a model of the behavior of a performance test in HCL OneTest™ Performance.
  - Extending data correlation
    Data correlation is the process of extracting data that is returned from a server, and then sending it back to the server in a subsequent request.
  - Extending the test editor
    The performance testing software provides application programming interface (API) classes for extending the test and performance tools platform (TPTP) to write new editors and protocol extensions.
  - Contributing error handlers
    An error handler is associated with an error condition. Error handlers specify the action to take when a specified error condition occurs. Error handlers are provided for conditions such as verification-point failures, connection failures, server timeouts, and data-correlation problems. You can add new types of errors and error handlers.
  - Extending the schedule component
    When you extend the schedule component in performance testing, another plug-in can contribute options to a schedule. Those options can be set up to persist in the schedule model, and a corresponding user interface can be displayed for editing the new options.
  - Extending code generation
    The code generation subsystem maps Load Test Behavior Model (LTBM) elements to objects of the code generation element model (IModelElement), which in turn are mapped to objects of its ILanguageElement class. As a result, a language element tree is created that contains all equivalent elements of the behavior model test element tree and at the same time determines the structure of code to be generated.
  - Extending the run-time environment
    The run-time environment defines the plug-ins on which all other plug-ins depend. The run-time environment is responsible for defining a structure for plug-ins and the implementation detail behind them.
    - Blocked Action detection
      The performance testing execution engine provides the capability of detecting that an Action is blocked. The definition of blocked is provided by the author of the Action. The definition is provided as an amount of time an Engine Worker Thread is allowed to be unresponsive in the course of executing the Action before it is considered blocked. The performance testing execution engine logs the detection of blocked actions at level FINEST in the Problem Determination Log. In the simplest case, the run would be hung, and discovery of the blocked action would come from examining the Problem Determination log after clicking Stop to end the run.
    - Extending subsystem management during a test run
      A subsystem is a collection of classes in a discrete component within the performance testing engine that provides a service to many actions. For example, in test execution, the KernelWait subsystem manages think and sleep time for virtual users while a test is running.
      - Informing the test engine that the subsystem exists
        Subsystems are identified to the performance test engine with extensions. Typically, a new protocol indicates in its plugin.xml file the class name of the subsystem that it is providing. This example modifies an existing performance test plug-in and specifies the class name of the sample plug-in in the plugin.xml file.
      - Creating a simple test and VU Schedule
        You must create a simple performance test and VU Schedule. By creating and playing back a test and a VU Schedule, code is generated for both. Later, you will modify the generated test code so that the test contains a special action that uses the sample subsystem.
      - Adding SampleAction and SampleSubsystem to the project
        Import the performance test and schedule source files into the testproj project.
      - Running the schedule with SampleAction using SampleSubsystem
        Modify the generated test code to use SampleAction, so that the subsystem is active during the next playback.
      - SampleAction.java code sample
        This is an example of SampleAction.java.
      - SampleSubsystem.java code sample
        This is an example of SampleSubsystem.java.
    - Extending initialization and finalization during a test run
      You can specify code for your protocol to be executed by the HCL OneTest™ Performance engine threads at strategic points during startup and shutdown. For example, you can specify code to load libraries, unload libraries, or perform other initialization or cleanup as required by the protocol.
    - Public APIs for run time
      The public APIs contain the public interfaces and classes that you can use to extend the run-time environment functionality.
  - Extending the test log viewer
    After running a test, the test results are saved in a test log. Use the Test Log viewer to check the results for specific events, such as the script start and end, loop, invocation, message, or verdict.
  - Extending evaluation results
    Reports are a specification of how performance test data should be extracted from the statistical model and presented to the user.

SampleAction.java code sample

This is an example of SampleAction.java.

SampleAction.java

package customcode;

import com.ibm.rational.test.lt.kernel.IKSubsystem;
import com.ibm.rational.test.lt.kernel.action.IContainer;
import com.ibm.rational.test.lt.kernel.action.impl.KAction;

public class SampleAction extends KAction {
	final String subsystemName = "test.SampleSubsystem";
	private boolean serviced = false;

	public SampleAction(IContainer arg0, String arg1) {
		super(arg0, arg1);
		// TODO Auto-generated constructor stub
	}

	public void execute() {
		if (serviced) {
			reportMessage("SampleAction execute():  service completed");
			finish();
		} else {
			IKSubsystem subsystem = getSubsystem(subsystemName);
			if (subsystem != null) {
				reportMessage("SampleAction execute():  requesting service");
				subsystem.enqueue(this);
			} else {
				reportMessage("SampleAction execute():  Cannot find subsystem '" + subsystemName + "'");
				finish();
			}
		}
	}
	
	public void setServiced() {
		serviced = true;
	}
}