Design and Process of Functional and Interface Test Cases

Background

Functional test case design and interface test case design exist independently: functional cases verify page functionality, while interface cases verify input and output parameters. Although functional testing on the UI includes API testing, some service‑level logic cannot be covered by UI tests.

Typical business testing scenarios include:

A: "Is the functional testing done? Have we tested the interfaces?"

B: "Interface testing is done, now we wait for functional testing..."

C: "The main smoke flow works, but some scenarios require both functional and interface verification!"

D: "This scenario cannot be validated by a single interface; it must be tested together with the UI functionality."

These scenarios illustrate the layered approach of separating functional and interface testing, a common practice in recent years. Below is the proposed process and design thinking.

Process Design Idea

Functional Design Idea

[Pre] Create or Edit Automated Test Cases

1. If the automation platform already has an API test case, adjust its parameters or test‑scenario conditions according to business requirements and save the case.

2. If no API test case exists, use the provided API documentation to input specific or parameterized values, debug the API, and generate an automated test case based on business test conditions.

[During] Bind or Generate Automated Test Cases

1. Bind Cases

On the case library page, a zzcase mind‑map node can be linked to one API case (one‑to‑many or many‑to‑one relationships). One zzcase functional node can bind to one API case, while one API case can be bound to multiple zzcase nodes.

Select a zzcase functional node, right‑click → Associate Automation, then in the Bind tab search for the corresponding API case in the automation suite and bind it.

Bound nodes can be edited to re‑bind a different API case.

The API case list supports quick search; click to select and bind.

After saving, the zzcase node displays an “API” marker.

Saving the zzcase functional case automatically calculates the number and proportion of bound API cases.

2. Add New Cases

Similar to the binding mode, on the case library page, a zzcase mind‑map node can generate one API case; the created API case is automatically bound to the node. Batch generation is also supported.

Select a mind‑map node, right‑click → Associate Automation, then in the Add New tab choose the appropriate API based on business and service, click Add, and the new API case is automatically bound to the node.

[Post] Automated Test Case Execution and Results

1. In the case library or test plan page, open the API case list; both single and batch execution are supported.

2. Execute the automated cases; results are automatically pushed and a link to the test report is provided.

3. After execution, verify code coverage; using API automation improves verification efficiency and test quality.

Summary

Maintain the habit of conducting API testing during business testing.

When mapping business functions to APIs, supplement API cases into the business test flow to achieve left‑shift testing.

Use a combined functional‑plus‑API case model and measure case quality via business scenario coverage.

Reduce tool‑switching across platforms to improve testing efficiency.

Support rapid iteration and improve code‑coverage verification efficiency.

Limitations

The zzcase embeds another platform page; dynamic loading leads to slow response.

API data from the automation platform can be unstable and requires dynamic loading.

The mind‑map case page currently does not support API debugging.

Future Plans

Explore a zzcase data‑construction platform to quickly generate test data during functional testing and feed it back into tests.

Explore integration with a UI platform for one‑click regression and UI verification during functional testing.