Design and Implementation of a Unified Test Data Construction Platform at Zhuanzhuan
This article describes the background, challenges, and solution of building a UI‑driven, cross‑business test data construction platform that integrates HTTP, RPC, SQL, and Redis calls, provides a block‑based front‑end builder, and adds workflow visualization to reduce communication overhead.
Background Constructing test data is essential for testing, especially cross‑business testing, and each business typically maintains its own data‑construction services (web services, RPC, SQL, Redis commands). To enable easy cross‑functional usage, a UI‑driven, configurable platform is required.
Problems
Each team’s data‑construction tools are scattered across web services, RPC interfaces, SQL scripts, and Redis commands, making them cumbersome to use and often requiring local downloads or execution on business platforms.
In a platformized environment, data‑construction providers must also develop front‑end pages, diverting focus from core data‑construction logic and wasting resources.
Teams lack detailed knowledge of each other’s business, leading to high communication costs when trying to leverage another team’s data‑construction capabilities.
Solution
Build a unified data‑construction platform that integrates data‑construction services from various business lines and executes HTTP, RPC, SQL, and Redis calls based on configuration.
Provide a block‑based front‑end builder so data‑construction engineers only need to focus on the construction logic, without worrying about UI implementation.
On top of the above, add a workflow diagram feature that links each node to a data‑construction interface, allowing cross‑business users to visually identify required data and reduce communication overhead.
Architecture Overview
The platform consists of front‑end block modules that store generated page data in a database, a front‑end parser that renders pages from the structured data, and a simple yet powerful overall structure that supports rich UI generation. The workflow diagram (implemented with GGEditor, previously go.js) maps each node directly to a data‑construction use case, further minimizing communication.
Diagram
Front‑end block module: stores generated page structures in the database.
Front‑end parser: renders pages based on the stored structures.
The overall architecture is concise and the generated interfaces are sufficiently rich.
With the workflow feature, each node directly corresponds to a data‑construction case, reducing communication costs (the workflow implementation switched from go.js to GGEditor).
The Zhuanzhuan team has integrated data‑construction across business lines using this approach; after several iterations the technology and implementation are clear and effective. Interested readers are welcome to discuss further.
转转QA
In the era of knowledge sharing, discover 转转QA from a new perspective.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.