How to Spot Performance Issues Early in Functional Testing

01 Introduction

Most previous sharing about stress testing comes from dedicated QA, but the author, who handles both functional testing and stress testing, reflects on how to detect and resolve potential performance problems during the functional testing phase, thereby easing the burden on later stress testing.

In a game’s Spring Festival red‑packet activity, the team‑creation interface allowed 200 k users to generate over 390 k teams, far exceeding the requirement of “one user can create only one team”. This case illustrates how concurrent issues discovered only during stress testing can waste time and resources.

Functional testing usually verifies single‑request correctness, yet real business scenarios involve high concurrency (e.g., flash sales, reward redemption, team limits). Relying solely on stress testing may miss hidden logic bugs.

Identifying concurrency problems early gives developers time to fix and optimize, preventing progress blocks during stress testing.

02 Value of Coordinating Functional Testing and Stress Testing

Two real‑world problems are presented:

Points Redemption Over‑Issuance

Problem: Concurrent redemption caused excess reward distribution.

Root Cause: Code lacked effective concurrency control.

Testing Gap: Functional testing and stress testing responsibilities were unclear, so neither covered the concurrent redemption scenario.

Mini‑Program Performance Issues

Problem: Users could not query any performance data.

Root Cause: Redis design flaw – cache kept full structured data (up to 3 MB per user) for 5 minutes, exhausting memory under heavy load.

Testing Gap: Lack of communication between functional testing and stress testing missed the concurrency risk.

03 How Functional Testing Analyzes Business Pressure Points

Client‑Side Performance Risks

High‑frequency actions should use debounce and throttling (e.g., reward redemption buttons, list refreshes).

Validate that each user action triggers the expected single API call; avoid redundant or premature calls.

Check large request bodies (file uploads, long text) that can waste bandwidth.

Detect high‑frequency polling that creates unnecessary server load.

Core Interface Concurrency Verification

Single‑user single‑interface concurrency tests (e.g., daily sign‑in limits, redemption limits).

Single‑user multi‑interface concurrency tests (e.g., scarce resource grabs, flash‑sale stock control).

Multi‑user multi‑interface composite concurrency tests (e.g., concurrent reads/writes, counter increments, delete‑while‑write scenarios).

Server‑Side Review and Pre‑Check

Login‑state protection to prevent malicious bulk requests.

Optimize deep pagination and sharding for large data sets.

Pre‑compute heavy calculations (e.g., card‑pack probabilities) to reduce real‑time load.

04 Collaboration Between Functional Testing and Stress Testing

Stress‑test evaluation should use recent QPS data from live projects, prioritize high‑traffic entry points, and map business scenarios to testing priorities.

Stress‑test scenario design should focus on core business interfaces, especially those with high concurrency risk, and verify that test coverage matches actual client call patterns.

Review stress‑test reports to ensure scenarios are realistic (e.g., logged‑in vs. logged‑out states) and that performance boundaries meet business expectations.

05 Summary

To reduce stress‑test workload, functional testing must focus on the 20 % of core business that covers 80 % of risk, such as reward‑related interfaces in red‑packet activities. By analyzing client behavior, verifying API correctness under concurrency, and reviewing server implementations, functional testing becomes an essential part of performance assurance, enabling early detection of issues and smoother overall testing pipelines.