How a Java‑Based Traffic Replay Platform Boosts Test Efficiency and Coverage

Construction Purpose

In daily testing work, teams encounter problems such as the need to verify original interface logic after service or component upgrades, high complexity of business scenarios requiring extensive regression time, incomplete manual traffic scenario coverage, and costly traffic simulation for performance testing.

Simple systems can be handled with conventional automation tools, but complex systems require a more effective method to lower testing costs and achieve automation.

By capturing real traffic from the production environment and replaying it in a designated environment, the platform provides a test environment that closely mirrors reality, enabling more efficient issue detection.

Platform Overview

The platform is primarily implemented in Java, extending the

jvm-sandbox-repeater

framework with extensive custom development to suit internal use cases. Business teams record traffic in the production environment (recording only, no replay) and replay the recorded traffic in a simulated environment for regression verification.

Construction Process

The traffic‑replay platform was built in four phases:

Basic capability construction.

Noise reduction optimization and further feature completion.

Small‑scale promotion and experience accumulation.

Deep collaboration with users to meet real‑world pain points.

Technical Architecture

Layered Architecture

The platform consists of four layers:

Platform Capability Layer: Provides change analysis, traffic recording, replay, rule configuration, inspection, test case management, result comparison, and data recycling.

Agent Layer: Offers recording and replay plugins for various components, communicating with the platform to report traffic and replay results.

Data Layer: Stores rule configurations, recorded traffic, and replay results.

Infrastructure Layer: Underlying environment and external facilities.

Deployment Architecture

A traffic‑replay instance is deployed in the production environment (recording only). Other environments that need to use the recorded traffic also deploy an instance. Recorded traffic is synchronized in real time to the target environment for replay.

Core Functions

Application Integration: Applications enable a switch to connect to the traffic‑replay platform; an agent is automatically attached during deployment, registers the application, and establishes bidirectional communication.

Traffic Recording: The platform sends recording configurations to agents, which capture traffic based on deduplication, sampling rate, amount, time, and scope, then report it to the platform. Recorded traffic is stored in Kafka and persisted to a database.

Traffic Replay: Recorded traffic is dispatched to agents for replay; agents execute requests and report results back, which are stored similarly.

Result Comparison: Recorded and replayed results are compared, with noise‑reduction configurations applied, and failures are categorized.

Technical Challenges and Solutions

6.1 Traffic Collection and Filtering

To avoid impacting production stability, only selected instances record traffic with limits on time, path, and volume. High‑QPS interfaces dominate collected traffic, making low‑QPS flows hard to capture.

Solution: Apply different sampling rates per path, limit per‑interface record count, use header and parameter rules for de‑duplication, and tag traffic by key attributes for fast retrieval.

6.2 Asynchronous Traffic Control

When asynchronous sub‑calls are present, the entry call may return before the sub‑call finishes, causing incomplete recordings.

Solution: Generate a TraceId for each request, propagate it across threads, and after the main flow reports, allow asynchronous sub‑calls to report separately, merging them during replay.

6.3 Noise Reduction Techniques

Replay failures can be caused by noise such as code changes, timestamps, random numbers, configuration differences, or array order.

Solutions include:

Manual Noise Reduction: Configure fields to ignore or focus on in responses and sub‑call parameters.

Algorithmic Noise Reduction: Mock time and random functions; use parameter similarity for matching.

Mechanism Noise Reduction: Dual‑path replay comparing baseline and replay environments to filter noise.

6.4 High Cost of Replay Failure Investigation

Failures stem from random numbers, token expiry, timestamps, environment differences, code changes, etc. Complex call trees increase debugging difficulty.

Solution: Categorize failure reasons, provide call topology for comparison, highlight configuration differences, allow export/import of failing traffic for offline debugging, and display parameter mismatches for sub‑calls.

Promotion Considerations

The platform excels in scenarios like data acquisition, interface refactoring, migration, and component upgrades, offering clear advantages over manual testing. However, it cannot fully replace conventional testing due to incomplete traffic capture, single‑interface focus, and the need for complementary automation tools.

Continuous noise‑reduction iteration is essential; otherwise, the cost of handling noise outweighs the platform’s benefits.

Building and using the platform incurs costs: plugin adaptation, devising effective noise‑reduction strategies, and requiring testers to have some white‑box knowledge.

Future Plans

Planned integrations include:

Connecting with automated testing platforms to compose recorded single‑interface traffic into complex scenario cases, reducing script maintenance.

Linking with precision testing platforms to automatically recommend recorded cases based on code changes.

Providing recorded traffic as a data source for performance testing platforms.