Backend Development 8 min read

Automated Testing Strategies for Complex Transaction Systems at Xianyu

Xianyu tackled the high‑cost manual testing of its multi‑scenario transaction platform by implementing JVM‑sandbox traffic‑recording tools (Doom/Blizzard and Phoenix) for interface‑level replay, service‑oriented link testing, and shadow‑DB isolation, enabling automated end‑to‑end validation across dozens of applications and business modes.

Xianyu Technology
Xianyu Technology
Xianyu Technology
Automated Testing Strategies for Complex Transaction Systems at Xianyu

Background : Xianyu, a vertical transaction community app, supports diverse business scenarios such as C2C, consignment, rental, face‑to‑face deals, and inspection‑guaranteed transactions. A single verification flow may involve 39 state‑machine nodes, span more than 10 applications, involve six business departments, and dozens of interfaces.

Problem : Rapid iteration relies heavily on manual testing, causing low ROI. Two main issues are (1) high communication cost and low iteration efficiency due to strong dependence on the middle platform, and (2) difficulty maintaining stable, incremental releases across varied transaction modes.

Testing Strategy – Automation : To reduce manual effort, Xianyu explored interface‑to‑link testing solutions. The goal is to ensure each interface works while guaranteeing end‑to‑end correctness.

Interface Layer : Traditional script‑based testing is costly. Industry‑accepted approaches use traffic replay. Two main ideas are described:

• Black‑box: capture live request/response traffic, replay in an identical environment, and assert results. Suitable for GET APIs but problematic for write operations due to data pollution and environment dependencies. • White‑box (mock‑based): capture external middleware/RPC responses during recording and mock them during replay, focusing on local code logic.

Alibaba’s internal solutions include two JVM‑AOP based implementations:

• Doom/Blizzard : Uses a Java agent (ASM) to record parameters, return values, and sub‑calls, uploading data for offline replay. The replay client re‑executes the interface locally, mocking sub‑calls, and compares results.

- 主干链路上的每一个MTOP接口,以及接口的上下游依赖 - 内部应用、中台应用、外部商家的依赖 - 数据流以及TDDL梳理

• Phoenix : Built on JVM‑Sandbox, records method calls, parameters, return values, and order in a chain structure. Replay mocks sub‑calls without requiring code changes or JVM argument modifications, making it less invasive.

Link Layer : For cross‑application verification, Xianyu adopts service‑oriented testing (Thub + microservices) to decouple dependencies in the test environment. Business‑wide link nodes are identified, and service‑wrapped interfaces are exposed for ordering, inspection, etc.

Shadow‑DB Platform : Uses shadow databases to isolate production and test data, enabling full‑link pressure testing and data‑change comparison across code versions.

Summary : Xianyu employs a JVM‑Sandbox based traffic recording solution at the interface layer, shadow‑link inspection for daily checks, and service‑oriented automation for self‑testing and full‑link validation.

Outlook : Future work includes exploring Flutter and end‑to‑end intelligent testing solutions to further reduce manual effort and strengthen quality across the transaction ecosystem.

BackendmicroservicesAutomated Testingquality assuranceflow recordingService Virtualization
Xianyu Technology
Written by

Xianyu Technology

Official account of the Xianyu technology team

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.