Set the data that the test log collects


+

Search Tips   |   Advanced Search

 

Overview

The test log shows the events that occurred during a run. By setting the level of information that is collected for a schedule run, you can control whether you receive individual response-time statistics for Percentile reports and information about verification points. You can set the level of detail for each type of event: errors, warnings, and other events.

The level of information collection directly affects log sizes. Depending on the setting that you select, the logs can become quite large. By limiting the log level and collecting the information from a representative sample of users, you can decrease log size and still have sufficient information for analysis.

For example, if you are debugging a test, you might set all three What to Log fields to All or Action Details. These settings produce large test logs, especially if tests are long or you are running a large number of users. Large test logs, in turn, increase the test log transfer time, and might even cause computer to run out of disk.

To reduce transfer times and the likelihood of running out of disk, sample information from a very small subset of users; smaller even than the default of 5 users per user group. A fixed sampling rate samples the same number of virtual users from each group. A percentage sampling rate samples a percentage of virtual users from each group, but guarantees that at least one user is sampled from a group.


Set the amount of information collected in the test log and the rate of sampling

  1. In the Test Navigator, browse to the schedule, and double-click it.

  2. In the Schedule Contents area, click the name of the schedule.

  3. Go to the Test Log page.

  4. Select the types of events to collect under What to Log.

    You can collect errors only, errors and warnings, or all events. In other words, Also show warnings and And also show all other types are unavailable until you select Show errors and failures. Similarly, And also show all other types is unavailable until you select Also show warnings. If none of the What to Log check boxes are selected, no test log events are collected.

  5. For each type of event, set the Log Level to one of the following options:

    Option Description
    Schedule Actions Collect events corresponding to actions executed in the schedule:

    • Overall schedule verdict.

      Pass All verification points matched or received the expected response.

      For example, a response code verification point is set to PASS when the recorded response code is received during playback. If test does not contain verification points, PASS means that the connection succeeded.

      Fail At least one verification point did not match the expected response or that the expected response was not received.
      Error One of the following results:

      • Primary request was not successfully sent to the server
      • No response was received from the server
      • Response was incomplete or could not be parsed.

    • Start and stop time of the schedule, each user group, each virtual user, and each test invocation.

    • Start and stop time of each loop iteration, if loops are set in the schedule.

    • Start and stop time of each selector, if selectors are set.

    Primary Test Actions Typically, you set data collection at this level. Primary test actions include schedule actions, plus the following actions:

    • Test verdict, test start, and test stop events.

    • Loop iteration start and loop iteration stop events, if loops are present in the test.

    • Transaction start and stop events, if transactions are present in the test.

    • For HTTP tests, Page title verification points. With this option you can see any page title verification points that you have set. The following events are collected:

      • The page verdict. You see a page verdict only if a connection problem occurs or if you have set verification points. Any failures or errors are rolled up to the test verdict level.

      • The start and stop time of each page.

      • The start and stop time of each loop, and the number of iterations of each loop, if you have set loops within a page.

      • The start and stop time of each transaction, and the duration of each transaction, if you have set page-level transactions in test.

    • For SAP tests, SAP screen information, such as SAP screen title verification points.

    • For Citrix tests...

      • connection elements
      • window events
      • image synchronizations

    • For SIP tests Primary Test Actions and Secondary Test Actions both provide the request URI header; for example...

        INVITE sip:esx4vm1:5060 SIP/2.0

    • For socket tests, connect, send, receive, and close elements.

    Secondary Test Actions Secondary test actions include primary test actions, plus this information:

    • For HTTP tests, request-level events.

      To collect information about response code or response size verification points that you have set, set data collection at this level of detail or greater.

      • The time that the first byte and last byte were sent.

      • The time that the first byte and last byte were received.

      • The character set of the response data.

      • Expected and actual values of page-level verification points that you have defined.

      • HTTP think events.

      • The start and stop time of each transaction, and the duration of each transaction, if you have set request-level transactions in test.

    • For SAP tests, SAP element information (primarily Set Property or Call Method actions).

    • For Citrix tests, synchronization points, delays, text elements, and logoff elements.

    • For SIP tests, statistics are identical to Primary Test Actions.

    • For socket tests, this option does not apply.

    Action Details Action details include secondary test actions, plus this information:

    All For HTTP, SAP, and Citrix tests, All and Action Details provide the same information.

    For SIP tests, messages about errors and failures, but only if Show errors and failures is also selected. Otherwise, All and Action Details provide the same information.

    For socket send and receive actions, the exchanged data is also available in the test log, by means of attachments.

  6. To set a sampling rate, select...

      Only sample information from a subset of users

    The number or the percentage that you select is applied to each user group.

    For user groups at remote locations (that is, on agent computers), the number or percentage that you select is distributed evenly among each location.

    Option Description
    Fixed number of users Number is applied to each user group. Assume that schedule contains two user groups. One group contains four users, and one group contains 1000 users. If you specify 2 for this option, two users are sampled from each group.
    Percentage of users Percentage is applied to each user group—but at least one user will be sampled from each group. Assume that schedule contains two user groups. One group contains four users, and one group contains 1000 users. If sampling rate is 10%, one user is sampled from the first group, and 100 users are sampled from the second group. If sampling rate is 25%, one user is sampled from the first group, and 250 users are sampled from the second group.


Example

The default setting, to log all errors and warnings, as well as primary test actions, fits most purposes. However, you can log any type of information, from no information to all information from all users, although neither is a typical situation.

If you are debugging a test, you might set all three What to Log fields to All or Action Details. These settings produce large test logs, especially if tests are long or you are running a large number of users. Large test logs, in turn, increase the test log transfer time, and might even cause computer to run out of disk.


Related tasks

  • Set the statistics displayed during a run
  • Set the problem determination level