Full‑Chain Load Testing Traffic Models: Business‑Model Implementation, Record‑Replay, and Gray Split

Full‑chain load testing has become increasingly popular, and many vendors now offer their own solutions. This article shares insights on three widely used traffic‑model approaches for end‑to‑end performance testing.

Business‑Model Implementation

This approach starts with a thorough analysis of the company's business flow, often represented as a tree‑like structure where the root is the user entry (e.g., login or homepage API) and leaves are various user exit points. Because real business flows can be complex with many branches, the model is usually simplified by aggregating or decomposing the tree into manageable sub‑paths, then implementing each path and finally merging them to simulate the overall traffic.

Implementation typically involves either tooling or scripting. The author prefers using Java and Groovy scripts: each API is wrapped in a method, parameters become method arguments, and each virtual user is represented as an object whose attributes store user‑specific data. By invoking these methods with controlled frequencies, the traffic of the whole business chain can be simulated.

Traffic Recording and Replay

Recording real traffic and replaying it is the easiest way to obtain a realistic load model. The author mentions a Go‑based replay tool called goreplay , which leverages Go's high performance. Most companies build on native engines and add wrappers to adapt recorded logs or use dedicated traffic storage/analysis platforms.

The main difficulty of this method is the "invisibility" of traffic: recordings can be massive (hundreds of thousands to millions of requests), making visualization hard. Small‑volume APIs may be missed, and recordings only reflect the traffic during the capture window. To cover time‑varying traffic, multiple recordings from different periods must be merged, which adds complexity.

Gray Split

Gray split, inspired by gray‑release concepts, routes a portion of live traffic to specific machines for stress testing. It combines the realism of recorded traffic with lower development effort, avoiding the need for extensive scripting. However, because it uses real user data, any failure can have uncontrolled impact, and it still inherits the visibility challenges of recorded traffic.

Have Fun ~ Tester！

FunTester Framework Architecture Overview

JMeter Chinese Manual

FunTester Environment Basics

HTTP API Testing Basics

WebSocket Client Wrapper

Micro‑Benchmarking to Refine Load Test Results

Measuring Asynchronous API Latency in Load Tests

LT Browser – Responsive Site Testing Tool

Formatting JSON Output to Console

Java NIO in API Automation

Android App Testing Knowledge Base

Spock and Mockito for Unit Testing