How ZTO Built a Unified Test Tool Platform to Boost Efficiency

Background

As ZTO Technology expanded, the testing team grew and the number of testing tools and platforms increased, leading to scattered resources, low sharing capability, poor tool reusability, no unified entry or standards, and no usage statistics. To address these issues, the ZTO Test Tool Platform was created to integrate resources, solve testing pain points, and enhance tool sharing.

Implementation Approach

The overall architecture is shown in the diagram below.

1. Implementation Principles

The platform follows ZTO's technology stack: the front end uses ZUI (a Vue wrapper) and the back end uses Titans (a SpringBoot wrapper). It leverages the company's front‑end and back‑end frameworks, reuses components, and adopts common modules such as database, messaging, and caching.

2. Code Structure

The code is divided into three main modules:

test-tool-admin : depends on the other two modules and contains Controllers, Services, AOP, etc.

test-tool-common : provides utility classes, enums, and exception definitions.

test-tool-dal : includes DTOs and mappers.

Service Integration and Usage Statistics

1) In the Controller layer, AOP intercepts methods whose names end with Feature, records information, and stores it in the database.

2) The Service layer calls encapsulated Java or Python services; all usage statistics flow through the Controller.

3) The configuration center (Apollo) maintains default parameters and configuration management.

Controller Implementation Details

Methods to be tracked end with Feature for easy AOP location. Dynamic configuration such as third‑party URLs is managed via Apollo. Other services are wrapped in OtherService and returned uniformly to the front end.

Practical Results

The platform must support data generation and integration with other platforms.

1. Data Generation

Testing often requires complex order and tracking data. Two traditional approaches (manual business logic or automated scripts) have high learning costs and low usability. The platform provides a data‑generation tool that lets users create orders, tracking records, and related logistics data without deep business knowledge.

Order creation flow:

The back‑end Controller merges user‑provided parameters with default Apollo parameters, builds the order request object, and calls the Service layer.

2. Tracking Generation

The platform supports common tracking events (receipt, dispatch, arrival, delivery, sign‑off). Users can add events as needed, and the front end provides components for provinces, cities, personnel, and sites, automatically filling codes and IDs.

3. MQ Messaging

The platform allows quick configuration of MQ messages via templates, supporting parameterization (UUID, timestamps, order numbers). Users can send messages and track their status.

4. Integration with Other Platforms

Custom Java or Python services are wrapped as HTTP interfaces and exposed through a common toolbox, allowing front‑end calls. Common third‑party tools (XML, JSON, time conversion) are embedded via iframes.

5. Data Statistics

The platform provides usage statistics for the past week, month, half‑year, and year, including feature, user, and department click rankings. These metrics help pinpoint user groups and guide targeted development.

Statistics are collected using the same AOP mechanism described earlier.

Summary

The test‑tool platform consolidates scattered testing resources, improves tool sharing, and supports data generation, order creation, tracking, MQ messaging, and integration with other services, thereby significantly enhancing testing efficiency across development, product, and quality teams. Future plans include low‑code component integration for rapid UI customization and automated code updates.