Skip to content

The Replay View

The Replay View gives you real-time visibility into replay execution: transaction-by-transaction status, HTTP connections, and dataset row usage. This is where you watch replays succeed or fail, diagnose problems, and verify that your configuration is correct.

When to use it: During replay to catch failures as they happen. After replay to review which transactions failed and why. During debugging to inspect connection details and dataset values.

Opening the Replay View: Window → Show View → Replay (or Window → Show View → Other... → Load Tester → Replay)

Replay View Layout

By default, the Replay View shares a window pane with the Content View (bottom panel). To see both simultaneously, drag the Replay View tab to a different pane (e.g., right side) so you can watch transactions execute while viewing response content. See Navigating the UI for layout customization.

Replay View Overview

Replay View showing the summary panel and Connections tab

The Replay View displays replay status in a compact summary panel with detailed tabs below.

Summary Panel (Top)

The top panel shows high-level replay status:

Field Description What It Tells You
Testcase Name of the test case being replayed Identifies which test case you're viewing
Status Current replay state: Playing, Stopped, Paused, or Thinking (think time delay between pages) Shows whether replay is actively executing, finished, or waiting
Current Page Title and URL of the page currently being replayed (or the last page replayed when stopped) Helps you track progress through the test case
Duration Elapsed time since replay started (includes think time) Total time replay has been running (not server response time)
Errors Number of failed transactions encountered so far Red number indicates failures. Click to see details in the Connections tab
Pages Page count: current / total (e.g., "Pages: 4 of 4") Shows how far through the test case you are
URLs Transaction count: current / total (e.g., "URLs: 4 of 4") Tracks progress within the current page
Tab Area Bottom area switches between Connections and Datasets tabs Provides detailed debugging information for connections in flight or dataset values in use

Connections Tab

Connections tab showing active HTTP connections

The Connections tab shows every HTTP connection established during replay, including connection state, transaction count, and current activity.

Each row represents one TCP/HTTP connection to a server. Modern web applications routinely open multiple connections, both to different hosts and as parallel connections to the same host.

Connections Table Columns

Column Description How to Use It
Connection # Sequential connection number (starts at 0) Identifies connections in diagnostic logs
Host Name Server hostname or IP address (e.g., www.example.com, api.example.com) Shows which servers the test case connects to
State Connection status: Connected, Idle, Closed, Failed Failed indicates network problems (connection refused, timeout)
Transaction Count Number of HTTP requests sent on this connection Shows connection reuse (higher = more efficient)
Current URL URL currently being requested on this connection Identifies which transaction is in progress

Multiple connections to different hosts is perfectly normal for modern web apps (main server, CDN, API servers). Failed connections mean the server is down, a firewall is blocking traffic, or DNS resolution failed. A low transaction count per connection may indicate connection pooling issues where the client opens too many connections instead of reusing them.

Datasets Tab

Datasets tab showing the current dataset row values

The Datasets tab shows which dataset rows are currently in use by the virtual user during replay. This helps verify that datasets are configured correctly and that the virtual user is using the expected data.

What datasets show: If your test case uses datasets (for usernames, passwords, test data, etc.), this tab displays the current row values for each dataset.

Datasets Table Columns

Column Description How to Use It
Dataset Name Name of the dataset (e.g., Users, Products, Credentials) Identifies which dataset this row comes from
Field Name Column name within the dataset (e.g., username, password, productID) Shows which field values are displayed
Value Actual value from the current row (e.g., jdoe, P@ssw0rd123, PROD-456) Verifies the virtual user is using correct data

Example:

If your test case uses a dataset named Users with columns username and password, the Datasets tab might show:

Dataset: Users
  username = "jdoe"
  password = "P@ssw0rd123"

This tells you the virtual user is currently using the first row from the Users dataset (or whichever row was selected based on dataset configuration).

This matters because you can verify the virtual user picked the right row, check whether the password value is what you expect (useful when debugging authentication failures), and confirm that each replay actually uses different data.

The Replay View menu (click the down-arrow icon in the top-right corner of the view) provides dataset management options.

Replay View menu with Remember/Reset dataset options

Remember Dataset Position

Default: Enabled (checked)

When enabled, Load Tester remembers which dataset row was last used and automatically advances to the next row on the next replay. This lets you replay the same test case multiple times with different data without manually resetting anything.

Example:

  • Replay 1: Uses username = "user1" (row 1 of dataset)
  • Replay 2: Automatically uses username = "user2" (row 2 of dataset)
  • Replay 3: Automatically uses username = "user3" (row 3 of dataset)

When to disable: When you want every replay to start at row 1, for instance if you're debugging with a specific test user and need consistent behavior.

Reset Dataset State

What it does: Immediately resets all datasets back to row 1 (first row). The next replay will start from the beginning of each dataset.

When to use:

  • After running multiple replays: To go back to the first dataset row
  • Before running a load test: To ensure all virtual users start from row 1
  • When debugging: To replay with the same data as the first replay

How it works: Click Replay View menu → Reset Dataset State. The next replay will use row 1 of each dataset (instead of continuing from where the last replay left off).

Common Replay View Usage Patterns

Pattern 1: Watching Replay Execute in Real Time

Scenario: You want to see transactions succeed or fail as they happen.

How to use Replay View:

  1. Open Replay View: Window → Show View → Replay
  2. Start replay: Click Play (▶️) button
  3. Watch the Connections tab: Transactions appear as they execute
  4. If a transaction fails:
  5. Error Count field increments (shows red number)
  6. Failed transaction shows Failed state in Connections tab
  7. Click the failed transaction row to see error details

What to look for:

  • ✅ All transactions show "Connected" or "Idle" state: Success
  • ❌ Any transactions show "Failed" state: Investigate why (connection refused, timeout, HTTP error)

Pattern 2: Debugging Dataset Configuration

Scenario: Your test case uses datasets, and you want to verify the virtual user is using the correct data.

How to use Replay View:

  1. Open Replay View and select the Datasets tab
  2. Start replay
  3. Watch the Datasets tab during login or data entry transactions
  4. Verify:
  5. Is the username correct?
  6. Is the password correct?
  7. Is the virtual user using the expected row from the dataset?

If the Datasets tab is empty:

  • The test case isn't configured to use datasets (no dataset modifiers configured)
  • Dataset assignment might be configured for load testing only (not replays)

Pattern 3: Comparing Multiple Replays

Scenario: You ran replay #1, made configuration changes, and ran replay #2. You want to compare results.

How to use Replay View:

  1. Run first replay, note the results (errors, timing, dataset values)
  2. Make configuration changes (update ASM, adjust extractors, etc.)
  3. Run second replay
  4. Compare:
  5. Did error count decrease (configuration improved)?
  6. Did different dataset rows get used (Remember Dataset Position advanced the row)?
  7. Did connections succeed this time (server issue resolved)?

Tip: Use replay names to identify which configuration changes were applied. Right-click the replay in the Test Case Editor → Rename to give it a meaningful name (e.g., "Before ASM Fix", "After Auth Config").

Ask the AI About Replay View Interpretation

If you're unsure what the Replay View is showing or why connections are failing:

My Replay View shows several "Failed" connections. Can you help me understand
what's causing these failures and how to fix them?

The AI can:

  • Interpret connection states and explain what "Failed" means in your context
  • Analyze dataset values to verify correct data is being used
  • Explain why error count is incrementing and which transactions failed
  • Guide you through systematic debugging using Replay View data
  • Compare multiple replays to identify configuration changes that improved results

Next Steps

After using the Replay View:

For configuration topics: