Inside FunTester: A Deep Dive into Its Testing Framework Architecture

The author revisits the FunTester testing framework and shares a newly created architecture diagram, produced with draw.io in about half a day. The diagram visualizes the framework’s layered structure: a foundational layer, a functional layer, a testing layer, and integration points for various upper‑level systems.

Project Base Modules

Single‑project, multi‑project, and multi‑protocol modules form the core of the base layer.

Common settings include request parameter formats for GET and POST, a unified header handling, authentication processing, and initial response handling that validates business code and response structures.

Test data management covers test users, API path management, project linkage, and utility classes for encryption, signature verification, and test backdoors.

Multi‑protocol support extends beyond HTTP to auxiliary protocols such as MySQL, Redis, and Socket, primarily used for script‑based testing, with a modest project‑level implementation for Socket.

Business Modules

Each business module is represented by a class that encapsulates properties, methods (acting as interface wrappers), and necessary utility functions. The modules handle response processing, extracting required values and performing simple business validations.

Testing Practice

The author outlines a test process and test case flow, referencing a previous article on unified API testing for functional, automation, and performance test cases. Functional test cases can be reused for automation and performance testing, while some are exclusive to performance testing.

Test Data Construction

Due to the diversity of scenarios, detailed data construction is not exhaustively described; data generation relies on encapsulated functional APIs and test backdoors.

Auxiliary Tools

Depending on specific requirements, the framework may employ moco api, JsonPath, and a project‑wide messaging mechanism ( 消息) to support various testing scenarios.