Game Stress Testing: Types, Metrics, and Robot Tools

Stress testing adds concurrent load to both server and client processes of a game to observe performance under high pressure; it is a crucial step before releasing features to ensure player experience and game reputation.

The four main stress‑test types are server stress testing, client stress testing, third‑party service testing, and cloud‑gaming testing. The first two target the game’s own processes, while the latter two focus on external services.

Server stress testing is needed for high‑traffic gameplay such as raids, login queues, or large‑scale battles, where many simultaneous players can overload the server and cause lag or logical errors.

Client stress testing simulates many on‑screen players or data‑heavy UI operations that may cause stutter; the threshold for acceptable performance is determined by the game’s frame‑rate requirements.

Third‑party service testing checks the stability of external APIs that the game relies on, and cloud‑gaming testing monitors issues like queueing, black screens, or connection failures when the cloud platform is overloaded.

Key performance indicators during stress testing include CPU, memory, I/O, and network traffic, as well as game log data such as LUA memory usage, online player count, CPU load, and the number of pending database queries. The DELAY metric (difference between game logic time and real time) helps identify bottlenecks; low DELAY (<1 s) indicates acceptable load.

Case analysis: When testing a database‑intensive feature, gradually increase concurrency until pending query count stays at zero; if it rises, calculate the maximum request‑processing rate based on log changes.

Stress‑test robots are commonly used to simulate real players. Server robots operate without a client, creating load via PATCH login calls, offering low maintenance and no extra hardware but lacking RPC interaction and network traffic simulation. Client robots retain full client‑server interaction, providing more realistic load at the cost of higher maintenance and hardware requirements.

Case analysis: A login‑module stress test showed good server metrics, but manual client testing revealed severe delay due to a single database connection bottleneck.

Server robots are mainly used for server‑side performance testing, while client robots are suited for multi‑player tasks, battles, and UI performance tests that require full client behavior.

Future articles will dive deeper into how to execute stress tests and analyze the results.