Backend Development 5 min read

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.

转转QA
转转QA
转转QA
Design and Implementation of a Unified Test Data Construction Platform at Zhuanzhuan

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.

BackendautomationWorkflowplatformtest data
转转QA
Written by

转转QA

In the era of knowledge sharing, discover 转转QA from a new perspective.

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.