Evolution and Architecture of a Transaction Service Testing Framework

Overview The testing of transaction‑related business faces high repetitive workload, diverse order types, and sensitive business logic, leading to low efficiency and the need for extensive regression testing.

Objectives 1. Perform pre‑testing before integration or front‑end hand‑off so functional tests focus on UI interaction. 2. Isolate core business for environment checks, smoke tests, and lightweight regression. 3. Visualize test cases with sharing and scheduling capabilities. 4. Provide data construction to reduce effort for complex end‑to‑end scenarios. 5. Collect performance data with configurable concurrency for load testing. 6. Recommend test cases automatically for small feature regressions.

Development Process

All In One Initially, all test code—including service initialization, data construction, test cases, and verification—was placed in @Test methods to respond quickly to requirements.

Extraction of Common Methods As test cases grew, duplicate initialization, data setup, and validation logic appeared. Repeated code and similar logic were abstracted into reusable utilities, forming an initial framework. Further abstraction led to more efficient test authoring and higher coverage, with test patterns based on state changes, workflow branches, settlement verification, and UI text checks.

Based on State

Based on Process

Project Separation and Data Construction The codebase was split into two modules: zzserver-core provides low‑level service calls and data builders (e.g., publishing products, creating orders with specific states), while zzserver contains the actual test cases. This separation enables a data‑construction platform that lets testers generate complex scenarios with simple UI inputs.

Project Structure After Adding Data Construction

Checklist A checklist suite was introduced to continuously verify core transaction flows (forward and reverse processes, red packets, activities) and validate inventory, order status, payment routing, and financial reconciliation, reducing manual regression effort during frequent releases.

Performance Testing With growing traffic, performance testing became essential. Leveraging existing test cases and the UI‑driven test platform, a TestNG‑based load framework simulates realistic user behavior (browsing, ordering, paying, refunding) and captures metrics such as QPS, response time, and server resource usage via agents and RMI‑based data collection.

Data Collection Strategy

Performance Test Execution Flow

Test Case Types The framework classifies test cases into five categories: (1) state‑based tests covering order or product state transitions; (2) branch‑coverage tests for promotional activities; (3) settlement verification tests for financial correctness; (4) capability‑based tests exercising state‑machine extensions; and (5) UI‑text verification tests for list and detail pages.

Overall Structure and Lightweight Release Test cases are built on top of service calls, data builders, and utility classes. Additional subsystems are integrated to increase value and efficiency. Continuous extraction and refinement of test cases produce checklists that are automatically recommended based on code diffs, with Jacoco feedback on coverage, enabling developers to perform self‑service regression before deployment.

Interface Testing Project – Core + Extensions