AOP‑Based System‑Level Test Decoupling: Design, Implementation, and Benefits

Background: System‑level testing can uncover broader issues but incurs high cost due to many modules and the need to monitor overall system health. To improve efficiency and quality, systems are often split into independent subsystems for test decoupling.

Test decoupling is motivated by better controllability, higher precision, improved efficiency, increased stability through mock data, and reduced resource consumption.

Challenges include constructing mock data for dependent subsystems, generating realistic online request data for DIFF and performance tests, and maintaining test quality.

Research: Three existing decoupling approaches are surveyed:

Approach 1 – Data/log synchronization with mock isolation (suitable for small, read‑only systems).

Approach 2 – Netbridge/capture/tcpcopy packet capture and replay (suitable for many read‑only systems, works at network layer).

Approach 3 – AOP‑based decoupling (suitable for read‑write systems with many stateful data sources, works at application layer).

The AOP‑based approach addresses limitations of the first two methods, such as the need for protocol adaptation and high maintenance cost.

Overall Solution: The AOP‑based design targets complex business systems with heavy business logic, numerous interfaces, mixed read/write traffic, and Java modules. It consists of three stages: online data recording, data management, and offline replay testing.

Key characteristics: high efficiency (real‑time online recording, no manual intervention), high fidelity (customizable sampling matching real user behavior), and stability (consistent input/output across modules).

AOP works by inserting code via pre‑compilation and runtime dynamic proxies, allowing recording and replay functionality. Configuration includes defining aspects, handling serialization/deserialization (JSON compression), and managing data storage.

Data flow: online sampling recording → compression and storage → transfer to big‑data platform → offline replay.

The solution differs from network‑layer approaches by operating at the application layer, avoiding protocol adaptation, requiring no topology changes, and supporting both online and offline modes with a unified component.

Two example scenarios illustrate the workflow for testing a single module (A) and a pair of modules (A+B), covering online recording, data selection, component injection, replay activation, test execution, and result analysis.

Integration steps for new modules include placing the logging component, configuring AOP rules, and enabling recording mode.

Tool characteristics: generality (Java‑wide, customizable replay data), ease of use (one‑time module integration, no code changes, real‑time recording), and fidelity (high‑quality sampling, near‑real‑time updates).

Application Cases: The approach is used in DIFF, performance, pressure, and fault testing across five complex business systems, covering over 90% of online traffic interfaces and uncovering nearly 200 critical issues.

Deployment involves a five‑step process: tool integration, online recording, traffic filtering, offline replay testing, and test report generation/analysis.

Future Plans: Enhance generality by expanding AOP plugins, improve stability via broader serialization support, and increase efficiency through better data management and customization guidance.

Author: Yang Fangfang, MSc in Computer Science from Harbin Institute of Technology, Senior Test Development Engineer at Baidu Commercial Services Quality Department.