Overview of RunnerGo Performance Testing Module and Its Features

The previous article explained how scene management is used; this supplement notes that scenes are only referenced by other modules, so changes in scene management do not affect scenes elsewhere, and that use‑case sets are used only in automated testing while scenes themselves are used in performance testing, with scenes not used in automated testing.

This article mainly explains the performance testing module.

Performance testing mainly consists of several parts: plan management, report management, and preset configuration.

Plan Management: This module mainly includes a plan list, plan search, and creating new plans.

Plan List: Provides start (execute), view (edit), copy, and delete functions; double‑clicking a row directly opens the plan for viewing or editing.

Search Plan: can filter by keyword and time.

Create New Plan: Requires selecting a plan type – normal task (manual trigger, immediate execution) or scheduled task (manual trigger, execution according to defined rules).

After entering a plan, the left pane allows searching, creating directories (groups), creating scenes, and importing scenes.

The right side displays the scene body where new scenes can be created or imported; the top‑right area is the plan execution zone, where recipients can be added (they receive an email with the report after execution) and the plan can be executed (running all scenes in the plan).

After creating a scene (same as in scene management), a task configuration area pops up on the right, requiring manual entry of task settings.

Control Mode: Centralized mode and individual mode.

Centralized mode: Simultaneous pressure – all configured concurrency (threads/coroutines) start together; when all finish, the next round of concurrency starts.

Individual mode: Individual pressure – all concurrency starts together; when any thread finishes, it is immediately restarted without waiting for others.

Load test modes include concurrency mode, step mode, error‑rate mode, response‑time mode, and requests‑per‑second mode; the warm‑up period defines how long only the initial concurrency can be started.

Concurrency Mode: Allows running by time or by rounds based on a fixed concurrency number to evaluate performance under constant load.

Step Mode: You can set a starting concurrency, then increase it by a step size up to a maximum, testing performance at each stage; after reaching the maximum, the plan continues for a stable duration before ending.

Example configuration: start concurrency 10; step size 20; step duration 100 seconds; max concurrency 100; stable duration 50 seconds.

The execution logic runs 10 c at 100 s, then 30 c for 100 s, then 50 c for 100 s, then 70 c for 100 s, then 90 c for 100 s, finally 100 c for 50 s, totaling a theoretical 550 seconds.

Error Rate Mode: Targets the error rate of a single interface; you can set a custom error‑rate threshold; if any interface exceeds the threshold, the plan stops automatically; if the threshold is not exceeded after reaching max concurrency, the plan runs the stable duration then ends.

When selecting error‑rate mode, the task configuration is similar to step mode, but you must choose error‑rate mode for the interface and enter a decimal threshold (e.g., 0.0001 means stop if error rate ≥ 0.01 %).

If multiple interfaces have error‑rate mode enabled, the plan stops as soon as any one meets the condition.

Response Time Mode: Uses the response times of all interfaces; each interface's response time is compared to a threshold; if any exceeds, concurrency stops increasing and after the stable duration the plan ends; if the max concurrency is reached without exceeding the threshold, the plan still runs the stable duration before ending.

When selecting response‑time mode, the task configuration mirrors step mode; you must select response‑time mode for the interface, choose a percentile line (50, 90, 95, 100, or 101 for average) or a custom line, and set the threshold (e.g., 95th percentile line with a 10 000 ms threshold stops the plan if the 95% response time exceeds 10 seconds).

Requests‑Per‑Second Mode: Based on the total number of requests per second across all interfaces; compare with a threshold; if the threshold is not reached after max concurrency, the plan stops automatically; if the threshold is reached, the plan continues with the defined step and max concurrency, then runs the stable duration before ending. The calculation is total requests divided by total run time.

When selecting RPS mode, the task configuration is the same as step mode; you must select RPS mode for the interface and provide a threshold. If the plan’s RPS exceeds the threshold, concurrency jumps to the max (e.g., 150) and runs the stable duration (e.g., 20 seconds).

If multiple interfaces have RPS mode enabled, the plan proceeds only after all interfaces reach or exceed their thresholds.

This brief introduction to RunnerGo’s functional modules and how to use them ends here; interested readers are encouraged to try it themselves.

GitHub address: https://github.com/Runner-Go-Team/RunnerGo

Gitee address: https://gitee.com/Runner-Go-Team/RunnerGo

If you appreciate the open‑source project, please give it a star – thank you!

RunnerGo has been open‑source for two months, earned the GVP‑Gitee most valuable open‑source project award, and will continue to improve to provide better testing software solutions for testers.