Self-Service Order Testing Architecture and Evolution for Didi Ride-Hailing Platform

Business background: Didi's ride-hailing service is a core business with a complex system architecture and a high iteration frequency. The order chain involves many downstream services and multiple product categories (e.g., premium, fast, etc.). Typical testing scenarios such as A) carpool (two passengers, same area, one driver handling two orders) and B) consecutive order dispatch (driver receives a new order before finishing the previous one) are costly to construct manually, requiring multiple terminals and extensive coordination.

Order testing process: The order transaction chain connects upstream client requests to downstream services such as order management, pricing, and settlement. The core flow assembles requests from the client, calls downstream middle‑platform services, and completes the ride.

In the early stage (pre‑2015), order testing relied entirely on end‑device simulation ("端造单测试"): real passenger apps generated orders and real driver apps completed them. This approach offers high fidelity but suffers from low success rates, complex proxy configuration, and high manual effort for complex scenarios.

From 2015 to 2020, a tool‑based approach ("工具化造单测试") was introduced. The tool provides four core capabilities: Order scenario library – maintains parameters for core scenarios. Order flow – mock passenger and driver full‑process testing panel. Driver flow – mock driver full‑process panel. General API request – supports interface testing.

Since 2020, a self‑service testing capability ("自助化造单测试") has been built on top of the existing tool. It enables visual, standardized, and intelligent order generation. The architecture includes a visual link assembly interface, scenario sharing pool, and intelligent data pre‑population.

Key improvements of the self‑service approach:

Visual link assembly – users can build scenario chains by dragging and dropping components.

Scenario sharing – a shared pool allows cross‑team reuse of tested scenarios.

Reduced initialization cost – parameters are auto‑filled from logs or templates.

Application effects: Over 330 order test scenarios have been created, supporting more than 500 monthly active users for debugging and execution.

Summary and outlook: The order testing capability has evolved through end‑device, tool‑based, and self‑service stages, improving efficiency and usability. Future work will focus on left‑shift testing empowerment (early defect detection) and intelligent scenario construction (traffic analysis, replay, one‑click scenario generation).