Overview of the Commercial Testing Platform and Its Future Roadmap

The article introduces a commercial testing platform used by an advertising team, detailing its architecture, core components, monitoring and scheduling mechanisms, current advantages and shortcomings, and outlines planned enhancements to improve data construction, result recording, and anti‑fraud coverage.

转转QA
转转QA
转转QA
Overview of the Commercial Testing Platform and Its Future Roadmap

Earned revenue is the goal of every company, and most internet firms have a commercial team responsible for online advertising services such as ad placement, retrieval, and strategy. At ZhaiZhai, this team grew rapidly from scratch, and as the business matured, higher testing methods and tools were required; this article briefly introduces the current functions of the commercial testing platform and its future plans.

Simplified Advertising Display Process

The display flow involves accounts, products, presentation, billing, and anti‑fraud services. Accounts cover registration, binding, and recharge; products include creation, synchronization, review, and deletion; presentation includes creation and modification, while billing and anti‑fraud operate in tandem. To support business growth, QA engineers developed tools to improve testing efficiency, leading to the commercial testing platform described below.

Commercial Testing Platform

The platform consists of four parts: a test toolset, online monitoring, main‑process regression, and scheduled tasks. The toolset provides CRUD operations for accounts, products, and placements, as well as validation of retrieval results and generation of billing links. Online monitoring calls the retrieval API, captures the product list on the page, and compares the two to detect discrepancies. Main‑process regression ensures that iterative requirements do not break the core flow from product publishing to final billing. A scheduled task periodically cleans up test accounts and garbage data to improve user experience and revenue, while another task detects missing online displays promptly.

To simplify service calls across environments, the platform adopts the same WF+SCF architecture used by online services. WF’s architecture includes a presentation layer that receives page requests and validates parameters, a logic layer that invokes SCF services and handles complex result judgments (including scheduled tasks), and a foundation layer providing essential data and configuration files.

Retrieval validation, online monitoring, and billing result queries are complex; the article uses retrieval validation as an example. First, the retrieval service returns a set A of displays matching the input parameters. Then the database is queried for the display table to obtain set B. After filtering out non‑matching items, the two sets are compared, and the differences are displayed. This method avoids “self‑validation” and mitigates cache effects, providing an objective check of retrieval correctness.

Scheduled tasks are implemented with the open‑source Elastic‑Job framework. By reading configuration files, multiple tasks are loaded and registered to the company‑wide Elastic Job management platform for graphical management. This approach replaces direct Linux crontab usage to align with the company’s technology stack and facilitate future extensions.

Platform Advantages

Rapid construction of offline and online test data, shortening data preparation time.

Use of WF+SCF architecture simplifies integration with internal tools and platforms.

Clear architecture that is easy to extend.

Git‑based development supports multi‑person collaboration.

Current Shortcomings

Execution results and monitoring outcomes are not recorded, lacking notification functionality.

The platform is highly specialized with low generality, limiting usefulness for other business lines.

Early‑stage coarse development left the overall architecture in need of further optimization.

Future Plans

Gradually implement result recording, monitoring logs, and notifications.

Increase monitoring granularity.

Continuously optimize test data construction.

Add parsing of online logs to generate more realistic test data.

Provide prompts and help to lower usage cost and support future self‑testing.

Achieve full coverage of anti‑fraud strategies.

Continuously add tools to accommodate future business expansion.

Terminology

CPC: Cost Per Click – the cost incurred each time an ad is clicked.

CPM: Cost Per Mille – the cost for an ad to be shown to one thousand users.

CPS: Cost Per Sale – advertising cost calculated based on the number of actual product sales.

CTR: Click‑Through‑Rate – the ratio of ad clicks to ad impressions.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendmonitoringAdvertisingautomationtesting
转转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

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.