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.
Emulating workloads
You emulate a workload by creating a schedule and adding user groups/rate runner groups, tests, and other elements to it.
Monitoring resource data
Resource Monitoring is used to capture data, such as processor or memory usage, while running a test schedule. It can provide a comprehensive view of a system under test, to help identify issues. You can monitor data sources from a local or cloud schedule, or from a Service.
Enabling resource monitoring
You can enable Resource Monitoring from the workbench to capture system resource data such as processor or memory usage.
Adding sources for resource monitoring data
If you enable resource monitoring, you must specify the sources of resource monitoring data. A cloud schedule can contain resource monitoring locations that can be in the local premises, in the cloud location, or in both the places.
Adding Java Virtual Machine sources
To capture resource monitoring data from a Java™ Virtual Machine (JVM), you must configure the data source.

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.
- 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.
  - Schedule overview
    A schedule is the "engine" that runs a test. However, schedules are much more than simple vehicles for running tests. You can design or emulate the real-life workload by creating various groups and dividing the load across different remote agents that generate load on the application under test. A schedule can be as simple as one virtual user or one iteration running one test, or as complicated as hundreds of virtual users or iteration rates in different groups, each running different tests at different times.
  - Creating a VU Schedule
    You can create a VU Schedule to accurately emulate the actions of individual users.
  - Creating a Rate Schedule
    By creating a Rate Schedule, you can model the different behaviors of how the application is accessed and measure the rate accuracy.
  - Using Application Performance Management in a schedule
    You can use Application Performance Management (APM) in a schedule to enable AppDynamics or Dynatrace applications and enhance the data collection during load testing by adding HTTP headers to the request in your HTTP tests. You can also use APM to monitor the performance of applications.
  - Think time overview
    Think time is a delay in the processing of a request to reproduce the time that a human would take to read or examine the data that is displayed from a previous user action. Think time is calculated from the time that a request is received (that is, the display is complete on the monitor) until the time that the user clicks a key or link to perform an action.
  - Working with agents
    If you have a significant workload to test, typically a single computer might not be able to process the load efficiently. You need to distribute the load across multiple computers, also called HCL OneTest™ Performance agents. The agents are installed on computers to generate the load on the application.
  - Adding a test to a schedule
    By adding a test to a schedule, in this context, is used to refer to both VU Schedule and Rate Schedule, you can emulate the action of an individual user.
  - Adding must run tests
    In a schedule, you can use the Finally block to specify tests that must be run after the main workload is completed, when the last stage duration is expired, or a schedule is stopped manually.
  - Assigning variables
    In addition to assigning variables at the test level, you can assign variables at the schedule, in this context, is used to refer to both VU Schedule and Rate Schedule level and User or Rate Runner group level. When you assign variables at the schedule level, all the tests and groups in the schedule can use the variable initial values, if they have the same variable names.
  - Defining performance requirements in schedules
    You can define performance requirements to specify the acceptable thresholds for the performance parameters in a schedule. The performance requirements that you define can also be used to validate the service-level agreements.
  - Repeating tests in a schedule
    By adding a loop to a schedule, in this context, is used to refer to both VU Schedule and Rate Schedule, you can repeat a test for a number of iterations and set the rate for running a test. If the loop contains a synchronization point, the synchronization point is released after the first iteration of the loop and stays released for all further iterations.
  - Creating rate generators in user groups
    A rate generator is a workload container that specifies the number of tasks that the virtual testers run in a given time period. For example, you might be testing an Order Entry group that completes 10 forms every hour, or you might be testing a web server that you want to be able to support 100 hits every minute. Use a rate generator to model this time-based behavior.
  - Running tests at a set rate
    To run a test at a set rate, you add a loop to the schedule to control the iteration rate, and then add tests to the loop. The tests, which are children of the loop, are controlled by the loop. If the loop contains a synchronization point, the synchronization point is released after the first iteration of the loop and stays released for all further iterations.
  - Running tests in random order
    A schedule that contains only user groups and tests will run each test in a user group sequentially. By adding a random selector to a schedule, you can repeat a series of tests in random order, thus emulating the varied actions of real users.
  - Adding a transaction to a schedule
    A transaction is a specific group of test elements whose performance you are interested in. When viewing the test results, you can view performance data about any transactions that you have added.
  - Emulating network traffic from multiple hosts
    By default, when you run a schedule, each virtual user has the same IP address. However, you can make each virtual user appear as though it is running on its own host. To do this, you configure IP aliases on the host computer, and enable IP aliasing in the schedule. When you run the schedule, the network traffic will appear to be generated by multiple hosts.
  - Monitoring resource data
    Resource Monitoring is used to capture data, such as processor or memory usage, while running a test schedule. It can provide a comprehensive view of a system under test, to help identify issues. You can monitor data sources from a local or cloud schedule, or from a Service.
    - Enablement of Resource Monitoring services for a schedule
      You can enable the Resource Monitoring service in HCL OneTest™ Performance for a performance schedule to monitor the resources in a schedule and capture the performance statistics of such resources during the run time of the schedule.
    - Enabling resource monitoring
      You can enable Resource Monitoring from the workbench to capture system resource data such as processor or memory usage.
      - Adding sources for resource monitoring data
        If you enable resource monitoring, you must specify the sources of resource monitoring data. A cloud schedule can contain resource monitoring locations that can be in the local premises, in the cloud location, or in both the places.
        Adding Apache HTTP Server sources
        To capture resource monitoring data from Apache HTTP Server, you must configure the data source.
        Adding Apache Tomcat sources
        To capture resource monitoring data from Apache Tomcat, you must configure the data source.
        Adding IBM DB2 sources
        To capture resource monitoring data from IBM® DB2®, you must configure the data source.
        Adding IBM Tivoli Monitoring sources
        To capture resource monitoring data from an IBM® Tivoli Enterprise™ Monitoring Server, you must configure the data source.
        Adding IBM WebSphere Performance Monitoring Infrastructure sources
        To capture resource monitoring data from the IBM® WebSphere® Performance Monitoring Infrastructure, you must configure the data source.
        Adding Java Virtual Machine sources
        To capture resource monitoring data from a Java™ Virtual Machine (JVM), you must configure the data source.
        Adding JBoss Application Server sources
        To capture resource monitoring data from JBoss Application Server, you must configure the data source.
        Adding Microsoft Windows Performance Monitor sources
        To capture resource monitoring data from Microsoft™ Windows™ Performance Monitor, you must configure the data source.
        Adding Oracle Database sources
        To capture resource monitoring data from Oracle Database, you must configure the data source.
        Adding Oracle WebLogic Server sources
        To capture resource monitoring data from Oracle WebLogic Server, you must configure the data source.
        Adding SAP NetWeaver sources
        To capture resource monitoring data from SAP NetWeaver, you must configure the data source.
        Adding Simple Network Management Protocol sources
        To capture resource monitoring data from a Simple Network Management Protocol (SNMP) agent, you must configure the data source.
        Adding UNIX rstatd sources
        To capture resource monitoring data from the UNIX™ rstatd daemon, you must configure the data source. UNIX rstatd is bundled with most Linux™ distributions.
  - Resource Monitoring Service
    When you apply load to a system under test, the system's resources are consumed increasingly. If the capacity of the resources does not match the load, you will notice performance degradation in the results. With the Resource Monitoring Service, you can continually observe the health of the system's resources.
  - Monitoring response time breakdown
    You can use response time breakdown to see statistics on any page element that is captured while running a test schedule or imported from historical data.
  - Setting log and statistic levels
    Within a schedule, you set the size and sampling rate of the test log and the problem determination log, as well as the statistics that are displayed during a run.

Adding Java™ Virtual Machine sources

To capture resource monitoring data from a Java™ Virtual Machine (JVM), you must configure the data source.

Before you begin

The Java™ Management Extensions must be configured on the server that is running the JVM. Following are sample arguments to pass to the JVM:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8880
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Procedure

On the Location page, specify the connection and authentication information for the computer that is running the JVM. If you need to change the port that is used to communicate with the server, change the information in Connection. The port number must match the port that you specified when configuring Java™ Management Extensions on the server.
If administrative security is enabled on the JVM computer, select Administrative security enabled.
1. Type the user ID and password in Authentication.
2. Select Save Password to save your password locally. If you do not save your password, you might be prompted for it (depending on the host system configuration) when you edit the configured location or when you run test schedules that use the location.
On the Resource page, select the type of data to capture. The tree view shows the counter groups and counters that are available from the computer running the JVM. Be selective; monitoring all possible resource data requires substantial amounts of memory. Hold your mouse pointer over a counter to see details about what that counter measures.
Configure the option on the Options page.
1. In Polling Interval specify in seconds the interval for collecting resource data. For example, if you accept the default of 5 seconds, counter information is collected at 5-second intervals from the specified host during the schedule run.
2. In Timeout Interval, type a time value in seconds. If the resource monitoring host does not respond within this amount of time during a schedule run, an error is logged.
To collect the resource monitoring data for the system under test that is in the cloud, in the Cloud Options tab, click the Location in Public Cloud check box.
Click Next.
Specify a location and name and click Finish.