Pressure measurement method, pressure measurement system, and pressure measurement program product

Abstract

A pressure testing method, a pressure testing system and a pressure testing program product can realize efficient pressure testing of heavy interaction logic services such as games and social services while improving pressure testing coverage and maintainability. The pressure testing method is applied to the pressure testing system for controlling multiple virtual robots to perform multiple rounds of pressure testing tasks on the system under test. The virtual robot is a computing instance simulating the behavior of a client, comprising: a first step of dividing the multiple virtual robots into multiple collaboration units according to a preset collaboration configuration, and establishing an association relationship between the collaboration units and the virtual robots; a second step of generating a round identifier and binding the round identifier to the collaboration units and the virtual robots; a third step of completing wake-up based on synchronous call requests initiated by the virtual robots in the collaboration unit for the collaboration unit, realizing the consistent timing of the virtual robots in the collaboration unit; and a fourth step of performing round switching according to a preset round strategy.

Description

Technical Field

[0001] This disclosure relates to the field of software testing technology, and more particularly to the field of performance stress testing technology, specifically to a stress testing method, a stress testing system, and a stress testing program product. Background Technology

[0002] In the field of software engineering, performance testing is used to verify the carrying capacity, operational stability, response performance, and anomaly handling capabilities of business systems under high concurrency, high traffic, and high load scenarios. In particular, for business systems with multi-client collaborative interaction logic, such as game servers and social application servers, the corresponding performance testing needs to accurately simulate the collaborative behavior and timing relationships of multiple clients because their business logic highly depends on the collaborative interaction between multiple clients. This places extremely high demands on the collaborative support capabilities of the testing system.

[0003] Current load testing systems (such as JMeter, Locust, Gatling, and k6) primarily focus on load testing scenarios with independent requests from a single client. Their optimization efforts concentrate on basic capabilities such as load generation efficiency, request concurrency control, QPS / TPS, and response time statistics. However, for multi-client collaborative interaction scenarios, these existing load testing systems are not ideal. For business scenarios requiring multi-client collaboration, testers need to manually write a large amount of synchronous waiting, state verification, and exception handling logic when writing load test cases. As a result, not only does this lead to redundant and lengthy load test case code with extremely low reusability, but it also easily causes global deadlocks within the collaborative unit due to improper timing control and lack of exception handling, thus interrupting the load testing process. Moreover, existing load testing systems lack the ability to manage the global rounds of multi-client collaborative units. In scenarios requiring multi-round load testing, it is impossible to achieve synchronous round switching and state reset for all clients within the collaborative unit. As a result, problems such as chaotic round management and cross-contamination of business data from different rounds can easily occur, making it impossible to guarantee the accuracy of multi-round load testing results and the continuity of the load testing process. Summary of the Invention

[0004] This disclosure was developed in consideration of the above circumstances, and its purpose is to provide a load testing method that can achieve efficient load testing of highly interactive business logic such as games and social networking, while improving load testing coverage and maintainability. Based on this, this disclosure also provides a load testing system and a load testing program product.

[0005] One technical solution disclosed herein provides a load testing method applied to a load testing system. The load testing system controls multiple virtual robots to perform multiple rounds of load testing tasks on the system under test. The virtual robots are computational instances simulating client behavior. The load testing method includes: a first step, dividing the multiple virtual robots into multiple collaborative units according to a preset collaboration configuration, and establishing an association between the collaborative units and the virtual robots; a second step, generating round identifiers and binding the round identifiers to the collaborative units and the virtual robots; a third step, for each collaborative unit, waking it up based on a synchronization call request initiated by the virtual robot within that collaborative unit, thereby achieving consistent collaboration timing among the virtual robots within that collaborative unit; and a fourth step, performing round switching according to a preset round strategy.

[0006] The load testing method described in this technical solution, through the abstraction of multi-robot collaboration patterns and the design of synchronization primitives, enables efficient load testing of highly interactive logic businesses such as games and social networking. Furthermore, it allows test cases to concisely express multi-client collaboration processes, while supporting collaboration round management and synchronized restart of the entire team under high concurrency, thereby improving load testing coverage and maintainability. Attached Figure Description

[0007] Figure 1 This is a layered architecture diagram illustrating a stress testing system according to an embodiment of the present disclosure.

[0008] Figure 2 This is a schematic diagram illustrating the functional architecture and main data flow of a stress testing system according to an embodiment of the present disclosure.

[0009] Figure 3 This is a schematic diagram illustrating the processor registration center of a stress testing system according to an embodiment of the present disclosure.

[0010] Figure 4 This is a schematic diagram illustrating the message-driven module of a load testing system according to an embodiment of the present disclosure.

[0011] Figure 5 This is a schematic diagram illustrating the collaborative mode manager of a stress testing system according to an embodiment of the present disclosure.

[0012] Figure 6 This is a schematic diagram illustrating the synchronization primitive engine of a stress testing system according to an embodiment of the present disclosure.

[0013] Figure 7 This is a schematic diagram illustrating the robot manager of a stress testing system according to one embodiment of the present disclosure.

[0014] Figure 8 This is a schematic diagram illustrating the cycle manager of a stress testing system according to an embodiment of the present disclosure.

[0015] Figure 9 This is a flowchart illustrating a stress testing method according to an embodiment of the present disclosure.

[0016] Figure 10 This is a flowchart illustrating the stress testing initialization phase of a stress testing method according to an embodiment of the present disclosure.

[0017] Figure 11 This is a flowchart illustrating the basic stress testing mode of the collaborative stress testing execution phase of a stress testing method according to an embodiment of the present disclosure.

[0018] Figure 12 This is a flowchart illustrating the competitive condition stress testing mode of the collaborative stress testing execution phase of a stress testing method according to an embodiment of the present disclosure.

[0019] Figure 13 This is a flowchart illustrating the collaborative task stress testing mode of the collaborative stress testing execution phase of the stress testing method according to an embodiment of the present disclosure.

[0020] Figure 14 This is a flowchart illustrating the stress testing cycle switching stage of a stress testing method according to an embodiment of the present disclosure.

[0021] Figure 15 This is a flowchart illustrating the abnormal collaborative processing stage of the stress testing method according to an embodiment of the present disclosure. Detailed Implementation

[0022] (Terminology Explanation)

[0023] Before describing the specific embodiments of this disclosure, in order to clearly define the scope of the technical solution of this disclosure, the meanings of some terms involved in this disclosure will be explained first.

[0024] The “stress test” described in this disclosure refers to a performance test in the field of software engineering, used to test the load capacity, operational stability, response performance, and anomaly handling capabilities of the system under test when it is running under high concurrency, high traffic, and high load scenarios.

[0025] The “system under test” mentioned in this disclosure refers to a business system that undergoes stress performance testing, including but not limited to game servers, social application servers, and multi-user interactive business systems.

[0026] The "virtual robot (hereinafter referred to as the robot)" described in this disclosure refers to a computing instance created and controlled by the robot manager included in the load testing system described in this disclosure. It is used to simulate the behavioral logic of a real client and is the basic execution unit for load testing. The "virtual robot" described in this disclosure can independently execute business scripts, initiate synchronization / message waiting requests, etc.

[0027] The “synchronization primitives” mentioned in this disclosure refer to pre-defined standardized collaborative synchronization rules, which serve as the basis for achieving temporal consistency among virtual robots within a certain collaborative unit. These rules include, but are not limited to, preparing synchronization primitives, handshaking and pairing synchronization primitives, and completing synchronization primitives.

[0028] The following is for reference Figures 1 to 8 The pressure testing system 100 according to one embodiment of the present disclosure will be described.

[0029] (Overall architecture of the load testing system 100)

[0030] Figure 1 A layered architecture diagram of the pressure testing system 100 described in this embodiment is shown. Figure 2 It shows Figure 1 The diagram shows the functional architecture and main data flow of the load testing system 100. Figure 1 As shown, the load testing system 100 described in this embodiment adopts a layered and decoupled logical architecture, divided from top to bottom into a presentation layer 101, an orchestration layer 102, an execution layer 103, and a communication layer 104. Data interaction and command transmission between each layer are achieved through pre-defined standardized interfaces to ensure high maintainability and scalability. The presentation layer 101 serves as the user's (e.g., tester's) operation entry point, used to receive load testing configuration parameters, business scripts, and collaboration strategy settings. The orchestration layer 102 acts as the logical hub, including a processor registry center 200, a message-driven module 300, a collaboration mode manager 400, and a synchronization primitive engine 500. The orchestration layer 102 is mainly used to implement message processing logic reuse, external message parsing and routing, abstract orchestration of multi-robot collaboration modes, and execution of high-level synchronization logic. The execution layer 103 constitutes the execution carrier of the load testing system 100, including a robot manager 600 and a round manager 700. The execution layer 103 is primarily responsible for the full lifecycle management of the virtual robot and the global isolation and synchronous restart of load testing cycles. The communication layer 104 constitutes the interaction channel between the load testing system 100 and the system under test 900, for example, through the protocol adaptation submodule 301 in the message-driven module 300. In particular, the communication layer 104 supports message encapsulation and parsing of various communication protocols such as TCP, WebSocket, and HTTP.

[0031] (Functional implementation and input / output description of the main components)

[0032] <Processor Registry Center 200>

[0033] Figure 3A schematic diagram of the processor registration center 200 included in the stress testing system 100 described in this embodiment is shown. The processor registration center 200 is the carrier for realizing module-level message processor sharing. Its main functions include: uniformly receiving, storing, and managing registration requests of module-level message processors; establishing a mapping relationship of "business module - message type - processing logic"; and providing standardized message routing basis for the message-driven module 300. In this way, it can be ensured that various business messages of the system under test 900 can be accurately routed to the dedicated processing unit of the corresponding module. It should be noted that the "module-level message processor" mentioned here refers to a program execution unit belonging to a specific business module and dedicated to processing a unique type of business message under that module. For example, it is formed by binding the business module identifier, message type identifier, and processor logic entry point.

[0034] At the input level, the minimum input received by the processor registry 200 is the message type identifier and processor logic entry point sent through the presentation layer 101 located outside it.

[0035] Message type identifiers are character or numeric identifiers used to distinguish different business messages. For example, in a game collaboration load testing scenario, the message type identifier for "match successful" can be set to the string constant MATCH_SUCCESS, and the message type identifier for "room creation complete" can be set to ROOM_CREATED. Within the same category, different business messages have unique identifiers that are not repeated.

[0036] The processor logic entry point is, for example, the program execution address that points to the specific message processing code; it is the entry point for implementing message business logic processing. Specifically, the processor logic entry point can be, for example, a Java method handle, a Python function object, a C++ function pointer, or a processing function entry point in a scripting language. It is mainly used to execute business logic such as the robot entering the room after a successful match and updating its status.

[0037] Preferably, as an extended input, the processor registry 200 can also receive the service module identifier and processor priority configuration.

[0038] Business module identifiers are used to delineate different business domains (such as matchmaking module, battle module). For example, a business module identifier can be set to MODULE_MATCH for game matchmaking, MODULE_BATTLE for battle, and MODULE_CHAT for chat.

[0039] The processor priority configuration is used to define the execution order when multiple processors correspond to the same message type. For example, numerical identifiers from 1 to 10 can be used, where the smaller the number, the higher the priority. Therefore, when multiple processors such as status update, logging, and data statistics need to be executed successively for the same message, they can be executed in order of priority. In addition, it should be understood that the above inputs are all passed in through the standardized registration interface of the presentation layer 101, and the interface uses a parameterized passing method to ensure the integrity and recognizability of the input data.

[0040] From an internal implementation perspective, as an example, the processor registration center 200 is built-in with a key-value pair mapping storage unit 201 and a registration verification logic unit 202.

[0041] The registration verification logic unit 202 is used to perform a legality check on the above received input parameters. The legality check includes verifying the uniqueness of the message type identifier and the validity of the processor logic entry. If the above preferred input is also included, the legality check also includes verifying the format compliance of the service module identifier. For example, the registration verification logic unit 202 checks whether there is currently a registration record with the service module being MODULE_MATCH and the message type being MATCH_SUCCESS. If the verification result shows that the above registration record already exists, it is determined as duplicate registration and rejected. At the same time, the registration verification logic unit 202 also checks whether the processor logic entry is a legal executable program address to avoid pointing to an invalid code segment.

[0042] After the verification passes, the key-value pair mapping storage unit 201 will establish and maintain a global message processor mapping table with the "message type identifier + service module identifier" as the combined key and the "processor logic entry + priority" as the value. For example, using <MODULE_MATCH, MATCH_SUCCESS> as the combined key and <handleMatchSuccessProcessor, priority 1> as the corresponding value, a globally retrievable mapping relationship is formed. In addition, the key-value pair mapping storage unit 201 also configures a dynamic update interface for the mapping table to support users (such as testers) to add, delete, or modify processors during the stress test. For example, based on this function, during the stress test, users can dynamically add message processors for the combat module or delete obsolete matching-related processors without restarting the entire stress test system 100.

[0043] At the output level, the minimum output of the processor registration center 200 includes message routing rules.

[0044] Message routing rules, for example, are standardized data structures generated based on a global message handler mapping table, containing the association between message type identifiers, business module identifiers, and corresponding processor logic entry points. The output object of these message routing rules is the message-driven module 300, which transmits data to the processor registration center 200 via internal inter-process communication. As an example, the generated message routing rule could be specifically: when a received external message belongs to the business module MODULE_MATCH and has a message type MATCH_SUCCESS, it is routed to the handleMatchSuccessProcessor processor to execute the corresponding logic.

[0045] Preferably, the processor registration center 200 can also output processor registration status information. This information includes whether registration was successful, failed, and the reason for failure (e.g., duplicate identifier, invalid entry). By outputting and feeding back this processor registration status information to the presentation layer 101, the registration configuration can be promptly detected and corrected. For example, the processor registration status information could be reported to testers as "Registration successful: Business module MODULE_MATCH, message type MATCH_SUCCESS," or "Registration failed: Message type identifier MATCH_SUCCESS already exists under the MODULE_MATCH module."

[0046] <Message-driven module 300>

[0047] Figure 4 A schematic diagram of the message-driven module 300 included in the load testing system 100 described in this embodiment is shown. The main functions of the message-driven module 300 include message sending, receiving, parsing, and routing between the framework and the system under test 900, as well as the execution of the robot message waiting-wake-up logic. In essence, the message-driven module 300 acts as a hub connecting the external system under test 900 with the internal collaborative logic. For example, in a 5-player team load testing scenario for a game, the message-driven module 300 acts as a "communication bridge" between the framework and the game server. Specifically, all message interactions between the robot and the game server (login response, matching request, room entry command, etc.), as well as the robot's logic of "waiting for a successful match message" and "continuing execution after receiving the message," are uniformly managed by the message-driven module 300.

[0048] At the input level, the minimum inputs received by the message-driven module 300 include message routing rules from the processor registry 200, external communication messages from the system under test 900, and message waiting requests from the robot.

[0049] Message routing rules are the basis for ensuring correct message routing. For example, a specific message routing rule for received messages could be: <Business Module Identifier: MODULE_MATCH, Message Type Identifier: MATCH_SUCCESS> → Processor Logic Entry Point: handleMatchSuccessProcessor. The specific meaning of this message routing rule is: when a message belonging to a matching module and of type "match successful" is received, it is directly routed to that processor to execute its logic.

[0050] External communication messages are raw data returned by the system under test (SUT) 900 based on a preset communication protocol, and also serve as external event sources that trigger the robot's collaborative logic. For example, after the game server completes the matchmaking for a 5-player team, it will push the following raw message to the stress test system 100: {"module":"MODULE_MATCH","msgType":"MATCH_SUCCESS","roomId":"10086","teamId":"Team_001"}. This message is the external input that triggers the robot to enter the room.

[0051] The message wait request is initiated by the robot when executing collaborative logic. It includes the robot identifier, collaborative unit identifier, round identifier, and target waiting message type, and serves as the input for implementing the "continue execution after receiving the specified message" collaborative mode. For example, after initiating a matching request, the Robot_001 robot in the Team_001 collaborative unit sends a wait request to the message-driven module 300: {"robotId":"Robot_001","teamId":"Team_001","runId":"RUN_20260228_001","waitMsgType":"MATCH_SUCCESS"}. This message wait request indicates that the robot needs to wait for a "match successful" message before continuing to execute subsequent logic.

[0052] Preferably, as an extended input, the message-driven module 300 can also receive communication protocol parameters and message timeout parameters. Communication protocol parameters define the parsing rules for messages (such as message header length and data segment encoding format). For example, when using the WebSocket protocol, the communication protocol parameters can be set to: 8-byte message header length, UTF-8 encoding for data segments, and a 30-second heartbeat interval to ensure correct parsing of WebSocket messages sent by the game server. Message timeout parameters set the maximum duration for which the robot waits for messages, preventing the robot from being blocked for extended periods. For example, the message timeout parameter can be set to 30 seconds. Therefore, if the robot waits for a "match successful" message for more than 30 seconds without receiving it, a timeout exception is triggered, preventing the robot from remaining in a waiting state indefinitely.

[0053] From an internal implementation perspective, the message-driven module 300 includes three core internal components: a protocol adaptation submodule 301, a message parsing and routing unit 302, and a wait-wake-up registration management unit 303.

[0054] The protocol adaptation submodule 301 is configured to decapsulate external communication messages (i.e., raw messages) according to communication protocol parameters to extract the core data segments and message type identifiers, and to convert the raw messages into internal message objects. For example, upon receiving a raw JSON message pushed by a game server, the protocol adaptation submodule 301 first verifies the validity of the message header, and then parses out core fields such as "module," "msgType," and "roomId." After parsing the core fields, the protocol adaptation submodule 301 encapsulates these core fields into a unified internal Message object, i.e., an internal message object, for easy subsequent routing and processing.

[0055] The message parsing and routing unit 302 is configured to receive the converted internal message object and match it with the corresponding processor logic entry point based on the message routing rules issued by the processor registration center 200. If the match is successful, the processor is invoked to execute the business logic. If the match fails, a message routing exception is generated. For example, after receiving the internal message object indicating a successful match, the message parsing and routing unit 302 searches the routing rules and matches the handleMatchSuccessProcessor processor based on the search results. After matching the processor, the processor is invoked to execute the business logic of "robot enters room, updates status". On the other hand, if an unregistered message type (such as "unknown_msg") is received, an exception message such as "message routing failed: no corresponding processor found" is generated.

[0056] The Wait-Wake-Up Registration Management Unit 303 has a built-in wait message registry. For example, the wait message registry uses "Robot Identifier + Collaboration Unit Identifier + Round Identifier" as its index and "Target Message Type + Waiting Status" as its storage value. The Wait-Wake-Up Registration Management Unit 303 is configured to, upon receiving a message waiting request from a robot, record the message waiting request in the wait message registry and set the robot's status to "Message Waiting Status". On the other hand, when the protocol adaptation submodule 301 parses a target message, it will search the aforementioned wait message registry, find the corresponding robot, and generate a wake-up signal to wake up that robot. For example, after receiving a message waiting request from Robot_001, the Wait-Wake-Up Registration Management Unit 303 records in the wait message registry: index "Robot_001+Team_001+RUN_20260228_001", storage value "MATCH_SUCCESS + Waiting". On the other hand, when the protocol adaptation submodule 301 parses the target message "MATCH_SUCCESS", it finds Robot_001 by searching the above-mentioned waiting message registry, generates a wake-up signal to wake up Robot_001 and releases its waiting state.

[0057] Furthermore, the message-driven module 300 can be further configured to automatically trigger the atomic count update of the shared storage module 800 (an optional element) when it parses a collaboration result message (such as 'transaction successful', 'item acquisition failed') from the system under test 900, without requiring the robot to additionally call the IncTeamData interface of the shared data access unit 604. For example, after parsing the 'item acquisition failed' message, the message-driven module 300 sends a count update instruction to the mode manager of the shared storage module 800 of the corresponding collaboration unit based on the preset mapping relationship of "message type - collaboration unit - counting rule". The shared storage module 800 then sends the count update instruction (the atomic counting rule of this count update instruction is predefined by the shared data access unit 604, such as "failure count +1"). Under the protection of the underlying locking mechanism, the shared storage module 800 updates and stores the 'failure count' result of the corresponding collaboration unit to improve the efficiency of load testing.

[0058] At the output level, the minimum outputs of the message-driven module 300 include message trigger events and robot wake-up signals.

[0059] Message trigger events are internal events that signify "the target message has arrived." The output object of these message trigger events is the synchronization primitive engine 500. By outputting the aforementioned message trigger event to the synchronization primitive engine 500, the execution of synchronization logic can be triggered. For example, after parsing the "MATCH_SUCCESS" message, the following message trigger event is generated: {"teamId":"Team_001","eventType":"MSG_ARRIVED","msgType":"MATCH_SUCCESS"}. After generating the above message trigger event, it is sent to the synchronization primitive engine 500 to trigger subsequent Handshake synchronization logic.

[0060] The robot wake-up signal is a control command used to release the robot from its message waiting state. The output target of this robot wake-up signal is the robot manager 600. By outputting the robot wake-up signal to the robot manager 600, the robot can be driven to continue executing subsequent collaborative logic. For example, the following wake-up signal can be generated: {"robotId":"Robot_001","teamId":"Team_001","cmd":"WAKE_UP","msgType":"MATCH_SUCCESS"}. After generating the above wake-up signal, it is sent to the robot manager 600 to notify the robot to end its waiting state and continue executing the logic for entering the room.

[0061] Preferably, the message-driven module 300 can also output message processing exception information. Message processing exception signals include exception types such as message parsing failure, message routing failure, and message waiting timeout. After generating the above message processing exception signals, these signals are fed back to the processor registration center 200, the interface of the system under test 900, and the robot manager 600, respectively. This enables precise tracing and handling of exceptions. For example, in the case of message parsing failure (such as an incorrect original message format), the following message processing exception information is output: "Message parsing failure: Team_001, message format does not conform to WebSocket protocol specification." As another example, in the case of message waiting timeout (such as the robot waiting 30 seconds without receiving a MATCH_SUCCESS message), the following message processing exception information is output: "Message waiting timeout: Robot_001, waiting for message type MATCH_SUCCESS, timeout period 30 seconds," facilitating coordinated exception handling by various elements.

[0062] <Robot Manager 600>

[0063] Figure 7A schematic diagram of the robot manager 600 included in the load testing system 100 described in this embodiment is shown. The robot manager 600 is the main execution carrier of the execution layer 103. The robot manager 600 is configured to complete the creation, initialization, status monitoring, context update, and destruction of virtual robots (hereinafter referred to as robots) according to the load testing configuration. This provides manageable and reusable robot instance resources for collaborative load testing. For example, in a 5-player team load testing scenario for a game, the robot manager 600 manages all robots uniformly. More specifically, the robot manager 600 is responsible for batch creation of, for example, 500 game operation robots, assigning a unique identity to each robot, real-time monitoring of whether robots are stuck / disconnected, resetting robot states when load testing rounds change, and restarting or removing malfunctioning robots. This ensures that all robots can stably participate in collaborative load testing.

[0064] At the input level, the minimum inputs received by the robot manager 600 include load testing configuration parameters from the presentation layer 101, a globally unique identifier from the round manager 700, and lifecycle control instructions from the collaboration mode manager 400 and the round manager 700.

[0065] The load testing configuration parameters include the total number of robot instances and the basic operating mode of the robots, which are the basis for creating robot instances. For example, the received load testing configuration parameters include the following information: the total number of robots is 500; the operating mode is collaborative load testing mode; and the single team size is 5 people.

[0066] Globally unique identifiers are crucial data for binding robot contexts to load testing rounds and collaboration units. These include robot identifiers, collaboration unit identifiers, and (global) round identifiers. For example, the received globally unique identifiers include robot identifiers "Robot_001~Robot_500", collaboration unit identifiers "Team_001~Team_100", and round identifiers "RUN_20260228_001". These identifiers allow each robot to be assigned to its corresponding team and load testing round.

[0067] Lifecycle control commands are the core commands for managing the entire lifecycle state of a robot, including creation commands, start commands, reset commands, and destruction commands. For example, the robot manager 600 receives lifecycle control commands including a context reset command from the cycle manager 700 and a faulty robot restart command from the collaboration mode manager 400, and performs the corresponding operations according to the received commands.

[0068] Preferably, as an extended input, the robot manager 600 is further configured to receive exception handling policies and execution script information. The exception handling policy defines how to handle robot malfunctions (e.g., restarting after a failure, removing from the team). For example, the exception handling policy could be set to "automatically restart once when the robot experiences a network timeout failure; if the restart fails, remove it from the collaboration unit." The execution script information consists of standardized code snippets (e.g., login script, team formation script) that execute business logic for the robot. For example, the received execution script contains the specific operational logic for the robot, such as scripts for automatically logging into an account, automatically joining a team, and automatically entering a room.

[0069] From an internal implementation perspective, the robot manager 600 includes a robot factory unit 601, an execution context management unit 602, and a status monitoring unit 603.

[0070] The robot factory unit 601 is configured to create a preset number of robot instances based on load testing configuration parameters, using techniques such as pooling. Each robot instance is allocated independent process or thread resources to avoid resource contention between instances. For example, based on load testing configuration parameters for 500 robots, the robot factory unit 601 creates 500 independent robot thread instances at once, forming a robot instance pool. This eliminates the need for repeated creation and destruction, improving load testing efficiency.

[0071] The execution context management unit 602 is configured to maintain an independent execution context data structure for each robot instance. This execution context data structure contains core data such as globally unique identifiers (robot identifier, collaboration unit identifier, round identifier), business status (e.g., login status, team status), and resource usage information. It can reset and update the context according to instructions from the round manager 700. For example, the execution context maintained for Robot_001 is {RobotID:Robot_001,TeamID:Team_001, RunID:RUN_20260228_001, Login Status: Logged In, Team Status: Teamed, Room ID:10086}. It should be noted that during round switching, only business data such as room ID and team status are cleared, while basic identifier information is retained.

[0072] The status monitoring unit 603 is configured to monitor the running status of each robot instance in real time. Specific monitoring methods may include, for example, a heartbeat detection mechanism. The running status of a robot instance includes at least six states: ready, executing, message waiting, synchronization waiting, fault, and completed. The status monitoring unit 603 is also configured to generate and report a lifecycle event when a change in robot status is detected. Furthermore, the status monitoring unit 603 is configured to execute corresponding fault handling logic according to an exception handling strategy when a robot fault is detected. For example, the status monitoring unit 603 is configured to send a heartbeat detection to Robot_001 every 2 seconds. If no response is received after 3 consecutive heartbeats, the robot is considered to be in a fault state. In response, the status monitoring unit 603 automatically executes a restart operation according to a preset exception handling strategy, generating and reporting a fault event.

[0073] Optionally, the robot manager 600 may also include a shared data access unit 604. The shared data access unit 604 is configured to: It provides standardized data writing interfaces (SetTeamData), data reading interfaces (GetTeamData), and atomic counting interfaces (IncTeamData) for virtual robots to use; After receiving the shared data operation request initiated by the virtual robot through the above standardized interface, the access permission is verified by 'collaboration unit identifier + robot identifier', and only the robot belonging to the collaboration unit is allowed to access the corresponding shared storage module 800; For the atomic counting interface (IncTeamData), for example, a CAS (Compare And Swap) mechanism is used to implement lock-free concurrent counting at the memory level. The step size of the atomic counting can be configured (the default step size is 1), and the counting result is bound to the current round identifier provided by the round manager 700 and stored in the shared storage module 800; and Feedback of shared data access statistics (such as read / write counts and counting results) to presentation layer 101 facilitates real-time monitoring of data flow during collaborative load testing by testers.

[0074] At the output level, the minimum output of the Robot Manager 600 includes a list of robot identifiers and robot lifecycle events.

[0075] The robot identifier list is a collection of all robot identifiers belonging to the same collaborative unit and serves as the primary basis for dividing collaborative units. This robot identifier list is output to the Collaboration Mode Manager 400. For example, the robot identifier list generated for Team_001 is [Robot_001, Robot_002, Robot_003, Robot_004, Robot_005]. After generating the above robot identifier list, it is sent to the Collaboration Mode Manager 400 for team division.

[0076] Robot lifecycle events are internal events that characterize changes in robot state, including event types such as creation complete, ready, fault, and completion. The output object for robot lifecycle events is the Collaboration Mode Manager 400. By outputting robot lifecycle events to the Collaboration Mode Manager 400, state updates of collaborative units can be triggered. For example, reporting the following robot lifecycle event to the Collaboration Mode Manager 400: {TeamID:Team_001, RobotID:Robot_001, Event: Fault, Reason: Network Timeout}. Subsequently, the manager can trigger team-wide collaborative exception handling based on this robot lifecycle event.

[0077] Preferably, the robot manager 600 can also output the robot's execution context information. The robot's execution context information includes the robot's complete operating status and business data. By feeding this information back to the round manager 700 and the collaboration mode manager 400, data support can be provided for round switching and collaborative control. For example, as a basis for determining round switching, the execution context of Robot_001 can be fed back to the round manager 700: the current RunID is RUN_20260228_001, and the business status is that the current round of operation has been completed.

[0078] Collaboration Mode Manager 400

[0079] Figure 5A schematic diagram of the collaboration mode manager 400 included in the load testing system 100 described in this embodiment is shown. The collaboration mode manager 400 constitutes the collaboration hub of the orchestration layer 102, used to realize multi-robot (including Dual and Team) collaboration modes. The collaboration mode manager 400 is configured to perform the division of collaboration units, maintenance of collaboration relationships, control of team lifecycle, and execution of abnormal collaboration handling logic while realizing the abstraction and management of multi-robot collaboration modes. For example, in a 5-player team load testing scenario for a game, the collaboration mode manager 400 acts as the "commander-in-chief" of all collaboration teams. Specifically, the collaboration mode manager 400 divides 500 robots into 100 5-player collaboration teams (Team_001 to Team_100) according to the Team mode configured by the testers, and monitors the status of each team in real time. Furthermore, in the event of a robot failure within a team, the collaboration mode manager 400 will actively coordinate with other robots to avoid deadlock, thereby ensuring the orderly progress of the entire collaborative load testing process.

[0080] At the input level, the minimum input received by the collaboration mode manager 400 includes a list of robot identifiers from the robot manager 600, robot lifecycle events from the robot manager 600, and synchronization status notifications from the self-synchronization primitive engine 500.

[0081] As mentioned above, the robot identifier list is the basic data for dividing collaborative units. For example, the received robot identifier list specifically consists of [Robot_001, Robot_002, Robot_003, Robot_004, Robot_005] corresponding to Team_001, [Robot_006, Robot_007, Robot_008, Robot_009, Robot_010] corresponding to Team_002, and so on, totaling a set of robot identifiers for 100 teams.

[0082] As mentioned above, robot lifecycle events are the core basis for sensing changes in robot state and triggering collaborative control. For example, a received lifecycle event might be: {TeamID:Team_001, RobotID:Robot_001,Event: Fault, Reason: Network Timeout}. Upon receiving such a robot lifecycle event, the Collaboration Mode Manager 400 will be triggered to handle abnormal collaboration within Team_001.

[0083] Synchronization status notifications are used to determine whether the synchronization logic of collaborative units is complete. For example, a received synchronization status notification might be: {TeamID:Team_001, SyncType:prepare, Status: Synchronization Complete}. This notification indicates that all robots within Team_001 have completed their synchronization preparation and can proceed to the next stage of collaboration.

[0084] Preferably, as extended input, the collaboration mode manager 400 can also receive collaboration mode configuration and collaboration unit size parameters. The collaboration mode configuration specifies the collaboration mode used for the current load test (Singular single-robot mode, Dual dual-robot pairing mode as a multi-robot collaboration mode, and Team multi-robot mode). For example, the configured collaboration mode is Team mode. Specifically, all robots perform collaborative load testing in teams of 5. The collaboration unit size parameter defines the number of robots in the multi-robot mode (e.g., the number of pairs in Dual mode or the number of team robots in Team mode). For example, the configured collaboration unit size is 5, meaning each Team contains 5 robots.

[0085] From an internal implementation perspective, the collaboration mode manager 400 includes a collaboration unit division unit 401, a team lifecycle management unit 402, and an exception collaboration handling unit 403.

[0086] The collaboration unit partitioning unit 401 is configured to group the robot identifier list according to the collaboration mode configuration and collaboration unit size parameters. Specifically, in Singular mode, each robot is an independent collaboration unit. In Dual mode, robots are divided into collaboration units by pairing them up. In Team mode, robots are divided into collaboration units according to the preset team size. After partitioning, the collaboration unit partitioning unit 401 assigns a unique collaboration unit identifier to each collaboration unit and establishes a mapping relationship between "collaboration unit identifier - robot identifier list". Simultaneously, the collaboration unit partitioning unit 401 also associates each collaboration unit with an independent shared storage module 800. This shared storage module 800 has a built-in key-value pair storage structure, supporting read and write operations indexed by 'collaboration unit identifier + data key name'. Furthermore, for scenarios with concurrent access by multiple robots, a locking mechanism is configured for the atomic counting operation (IncTeamData) to ensure accurate and conflict-free counting results. For example, in a certain Team mode, the collaboration unit division unit 401 divides the robots into 100 collaboration units based on a list of 500 robot identifiers and a team size of 5 people. Each unit is assigned a unique identifier (such as Team_001 to Team_100), and the following mapping relationship is established: Team_001 → [Robot_001, Robot_002, Robot_003, Robot_004, Robot_005], Team_002 → [Robot_006, Robot_007, Robot_008, Robot_009, Robot_010], and so on.

[0087] The team lifecycle management unit 402 is configured to maintain the lifecycle status of all collaborative units. The lifecycle status includes at least five states: Building, Ready, Executing, Completed, and Abnormal. The team lifecycle management unit 402 dynamically updates the collaborative unit status based on robot lifecycle events and synchronization status notifications. For example, when all robots in Team_001 complete prepare synchronization, the team lifecycle management unit 402 updates Team_001's status from "Ready" to "Executing." As another example, when all robots in Team_001 complete this round of collaboration logic, the team lifecycle management unit 402 updates its status to "Completed."

[0088] The anomaly coordination processing unit 403 is used to resolve the "team deadlock" problem. Specifically, when a robot malfunction lifecycle event is received, the anomaly coordination processing unit 403 determines the state of the corresponding collaborative unit as "abnormal" and generates an anomaly wake-up command. This prevents other robots within the collaborative unit from becoming permanently blocked while waiting for the malfunctioning robot. For example, upon receiving a lifecycle event indicating a robot malfunction (Robot_001), the anomaly coordination processing unit 403 marks the state of Team_001 as "abnormal" and sends an anomaly wake-up command to the synchronization primitive engine 500, waking up all robots in the Team_001 team that are in a waiting state, thus preventing team deadlock.

[0089] At the output level, the minimum output of the Collaboration Mode Manager 400 includes collaboration unit identifiers and collaboration control commands.

[0090] The collaboration unit identifier is a unique identifier for each collaboration unit. This identifier is output to both the synchronization primitive engine 500 and the round manager 700. By outputting the collaboration unit identifier to the synchronization primitive engine 500 and the round manager 700, the synchronization logic and round management can be linked. For example, the output collaboration unit identifiers might be Team_001, Team_002, ..., Team_100. The synchronization primitive engine 500 executes the corresponding synchronization logic for each team based on these identifiers, while the round manager 700 manages the round switching for each team based on these identifiers.

[0091] The collaborative control instructions include synchronization start instructions, synchronization wake-up instructions, and exception interruption instructions. The synchronization start and wake-up instructions are output to the synchronization primitive engine 500 to drive the execution of synchronization logic. The exception interruption instruction is output to the round manager 700 to trigger round exception handling. For example, the output synchronization wake-up instruction is specifically {TeamID:Team_001, Cmd:WakeUp, SyncType:prepare}. The synchronization primitive engine 500 wakes up all robots in the Team_001 team that are in a synchronization waiting state according to this instruction. For example, the output exception interruption instruction is specifically {TeamID:Team_001, Cmd:Abort, Reason:RobotFault}. The round manager 700 marks the current round of the Team_001 team as abnormally abandoned according to this instruction.

[0092] Preferably, the collaboration mode manager 400 can also output collaboration unit status information, which includes the real-time lifecycle status of all collaboration units. By feeding this information back to the presentation layer 101, testers can easily monitor the load testing progress in real time. For example, the output collaboration unit status information might be: Team_001: Executing, Team_002: Completed, Team_003: Error, ... Testers can use this information to understand the load testing status of each team in real time.

[0093] (v) Synchronization Primitive Engine 500

[0094] Figure 6 A schematic diagram of the synchronization primitive engine 500 included in the load testing system 100 described in this embodiment is shown. The synchronization primitive engine 500 is used to realize multi-robot collaborative synchronization, and it is configured to encapsulate and execute synchronization primitives. The synchronization primitives include at least three types: "prepare (team-wide synchronization preparation)," "Handshake (pair handshake pairing)," and "wait_whole_team_finish (team-wide synchronization completion)." By adopting the synchronization primitive engine 500, the waiting and wake-up problems in the multi-client collaboration process can be solved, ensuring the timing correctness of the collaboration logic. For example, in a 5-player team load testing scenario for a game, after the 5 robots of Team_001 log in, the prepare primitive ensures that all members are ready before entering the team formation process. When the matching success message arrives, the Handshake primitive ensures that all robots receive the message and enter the room synchronously. After all robots complete this round of operations, the wait_whole_team_finish primitive triggers the entire team to uniformly end this round, avoiding round confusion.

[0095] At the input level, the minimum input received by the synchronization primitive engine 500 includes collaboration unit identifiers and collaboration control instructions from the collaboration mode manager 400, synchronization call requests from the robot, and message triggering events from the message-driven module 300.

[0096] The collaboration unit identifier is used to define the scope of the synchronization primitive, and the collaboration control command is used to control the start, wake-up, and interruption of the synchronization logic. For example, if the received collaboration unit identifier is Team_001, the collaboration control command is {TeamID:Team_001, Cmd:WakeUp, SyncType:prepare} (that is, to wake up the robot in the Team_001 team that is in the prepare synchronization waiting state).

[0097] Synchronization call requests are initiated by robots when executing collaborative logic. They include the robot identifier, collaborative unit identifier, round identifier, and primitive type, and are used to trigger the execution of synchronization logic. For example, the prepare synchronization call request initiated by Robot_001 is: {RobotID:Robot_001, TeamID:Team_001, RunID:RUN_20260228_001, SyncType:prepare}. Simultaneously, the other four robots in the team will also initiate similar requests.

[0098] Message-triggered events are used to link message-driven logic and synchronization logic to achieve a collaborative process where synchronization is triggered upon message arrival. For example, a received message-triggered event might be: {TeamID:Team_001, Event:MsgArrived,MsgType:MATCH_SUCCESS}. This means that Team_001 has received a "match successful" message, which can trigger subsequent Handshake synchronization.

[0099] Preferably, as extended input, the synchronization primitive engine 500 can also receive a synchronization scenario identifier and a synchronization timeout parameter. The synchronization scenario identifier is used to distinguish different synchronization application scenarios (such as login synchronization and matching synchronization). For example, it can be set to "login_sync" to represent prepare synchronization during the login phase, and "match_sync" to represent Handshake synchronization during the matching phase. The synchronization timeout parameter is used to set the maximum duration of synchronization waiting to avoid the robot being in a synchronization waiting state for an extended period. For example, the synchronization timeout parameter can be set to 30 seconds. If the prepare synchronization wait for Team_001 exceeds 30 seconds and all members have not completed, a timeout exception is triggered.

[0100] From an internal implementation perspective, the synchronization primitive engine 500 has designed a synchronization barrier management unit 501, a handshake pairing management unit 502, and a team completion detection unit 503 for the three types of synchronization primitives.

[0101] The synchronization barrier management unit 501 corresponds to the implementation of the prepare primitive, and it has a built-in counter statistics subunit 501A. When a prepare synchronization call request is received from a robot within the collaboration unit, the counter statistics subunit 501A accumulates the number of requests. When the accumulated number reaches the collaboration unit size, the synchronization condition is determined to be met, and a synchronization completion status notification is generated. For example, in the prepare synchronization of Team_001, the synchronization barrier management unit 501 initializes a counter for the team and the current round identifier (e.g., RunID:RUN_20260228_001), with an initial value of 0. The counter increments by 1 for each prepare request received from a robot. When the counter accumulates to 5 (team size), synchronization is determined to be complete, and a "Team_001 prepare synchronization complete" status notification is generated.

[0102] The handshake pairing management unit 502 implements the Handshake primitive and has a built-in pairing request queue. When it receives a Handshake synchronization call request from a robot, it stores the request in the pairing request queue and completes robot pairing according to preset pairing rules (such as pairing all robots). When all requests in the pairing request queue have been paired, a synchronization completion status notification is generated. For example, in the Handshake synchronization of Team_001, the handshake pairing management unit 502 collects Handshake requests from 5 robots, stores them in the pairing request queue, completes pairing of all robots, determines synchronization completion, and generates a "Team_001 Handshake Synchronization Complete" status notification to ensure that all robots enter the room synchronously.

[0103] The team completion detection unit 503 corresponds to the implementation of the `wait_whole_team_finish` primitive, and it has a built-in state aggregation subunit. The state aggregation subunit is used to summarize the synchronization completion status of all robots within the collaboration unit in real time. When all robots have completed their current round of business logic and initiated a synchronization call request, the entire team is determined to be complete, and a synchronization result event is generated. For example, in the team completion synchronization of Team_001, the state aggregation subunit summarizes the completion requests of all robots. When all 5 robots initiate `wait_whole_team_finish` requests, the entire team is determined to be complete, and a synchronization result event "Team_001's current round of collaboration complete" is generated. In addition, the synchronization primitive engine 500 also has a built-in synchronization interruption handling subunit 504. When an abnormal wake-up command is received from the collaboration mode manager 400, this subunit immediately terminates all currently executing synchronization logic and wakes up robots in a waiting state. For example, when the collaboration mode manager 400 issues an abnormal wake-up command for Team_001 (a fault caused by Robot_001), the synchronization interruption processing subunit 504 terminates the wait_whole_team_finish synchronization logic of Team_001, wakes up all robots in the waiting state, and avoids team deadlock.

[0104] At the output level, the minimum output of the Synchronization Primitive Engine 500 includes synchronization status notifications and synchronization result events.

[0105] Synchronization status notifications include at least three types: synchronization waiting, synchronization complete, and synchronization interrupted. The output object of the synchronization status notification is the collaboration mode manager 400. By outputting the synchronization status notification to the collaboration mode manager 400, the status update of the collaborative unit can be driven. For example, the output synchronization status notification is {TeamID:Team_001, SyncType:prepare, Status: Synchronization Complete}. Based on this synchronization status notification, the collaboration mode manager 400 updates the status of Team_001 from "Ready" to "Executing".

[0106] Synchronization result events include at least two types: synchronization completion of collaborative units and synchronization interruption due to an exception. The output object of synchronization result events is the round manager 700. By outputting synchronization result events to the round manager 700, a load testing round switch can be triggered. For example, the output synchronization result event is {TeamID:Team_001, RunID:RUN_20260228_001, Result: Complete}. The round manager 700 triggers a round switch for Team_001 based on this synchronization result event, generating a new round identifier, i.e., a new runid.

[0107] Preferably, the synchronization primitive engine 500 can also output synchronization timeout events. By feeding back the synchronization timeout event to the collaboration mode manager 400, the exception handling logic of the collaboration unit can be triggered. For example, the output synchronization timeout event is {TeamID:Team_001, SyncType:prepare, Event: Timeout, Duration: 30 seconds}. The collaboration mode manager 400 performs exception collaboration handling for Team_001 based on this synchronization timeout event, avoiding long-term team blocking.

[0108] (vi) Round Manager 700

[0109] Figure 8 A schematic diagram of the round manager 700 included in the load testing system 100 described in this embodiment is shown. The round manager 700 is used for global management of load testing rounds. Its main functions include generating globally unique round identifiers (runids) and monitoring the round execution status of collaborative units to achieve isolation, switching, and synchronous restart of load testing rounds. For example, in a 5-player team load testing scenario for a game, the round manager 700 plays the role of round scheduling in the load testing process. Specifically, the round manager 700 generates a unique round identifier, i.e., runid (such as RUN_20260309_001, RUN_20260309_002), for each round of load testing to ensure complete isolation of business data and robot status in different rounds. When Team_001 completes its round of collaboration, a round switch is automatically triggered, a new runid is generated, and the robot context is reset. In addition, when a team encounters an anomaly, the round is marked as discarded to prevent erroneous data from affecting subsequent rounds and to ensure the accuracy of load testing data.

[0110] At the input level, the minimum inputs received by the round manager 700 include collaboration result events from the collaboration mode manager 400 (or the synchronization primitive engine 500) and round control policies from the presentation layer 101.

[0111] The collaboration result event is used to determine whether the collaboration unit has completed this round of load testing. For example, the received collaboration result event is specifically {TeamID:Team_001, RunID:RUN_20260309_001, Result: Complete}, which indicates that the Team_001 team has completed all collaboration logic in the RUN_20260309_001 round.

[0112] Round control strategies include whether to automatically poll and whether to restart the round after an anomaly, used to manage the execution logic of the round. For example, the configured round control strategy is "automatically poll for 100 rounds, and restart the current round of load testing for the corresponding team after an anomaly".

[0113] Preferably, as extended input, the round manager 700 can also receive a round interval parameter and a round limit parameter. The round interval parameter defines the waiting time between two adjacent load testing rounds. For example, the round interval parameter can be set to 5 seconds. That is, after Team_001 completes its current round, it will wait 5 seconds before entering the next load testing round. The round limit parameter sets the maximum number of load testing rounds to prevent the load testing from running indefinitely. For example, the round limit parameter can be set to 100 rounds. That is, after all teams complete 100 rounds of load testing, the load testing system 100 will automatically terminate the load testing process.

[0114] From an internal implementation perspective, the round manager 700 includes a round identifier generation unit 701, a round status management unit 702, and a round switching control unit 703.

[0115] The round identifier generation unit 701, for example, uses a "globally unique identifier algorithm" to generate the round identifier, i.e., runid. This algorithm can be implemented by combining timestamps, random numbers, or auto-incrementing sequences to ensure that the runid for each load testing round is globally unique, avoiding interference between business data and synchronization logic from different rounds. For example, the round identifier generation unit 701 can combine the date (20260309) and an auto-incrementing sequence to generate runids: RUN_20260309_001 (round 1), RUN_20260309_002 (round 2), ..., RUN_20260309_100 (round 100). Furthermore, each runid is globally unique, ensuring complete isolation of robot states and business data across different rounds.

[0116] The round status management unit 702 is used to maintain a global round status table. The global round status table is indexed by `runid` and associated with the collaboration unit identifier and the round execution status (in progress, completed, or abnormally abandoned). The round status management unit 702 updates the execution status of each round in the global round status table in real time. For example, the global round status table records `RUN_20260309_001 → Team_001: Completed`, `Team_002: In progress`, and `Team_003: Abolished`, to reflect the round status of each team in real time.

[0117] The round switching control unit 703 is the execution unit for round management. When a synchronization completion event is received from a collaborative unit, the round switching control unit 703 determines that the execution status of the corresponding round is "completed" and executes the corresponding action according to the round control strategy. If continued polling is required, a new runid is generated by the round identifier generation unit 701. If the round limit has been reached, the load test is terminated. On the other hand, when a synchronization abnormal interruption event is received from a collaborative unit, the round switching control unit 703 determines that the execution status of the corresponding round is "abnormally abandoned" and, according to the round control strategy, chooses to generate a new runid to restart the round or terminate the load test of the collaborative unit. For example, when Team_001 completes the RUN_20260309_001 round, the round switching control unit 703 generates a new runid, RUN_20260309_002, triggering the round switching of Team_001. On the other hand, when Team_003 triggers an abnormal interruption due to a malfunction of its internal robot, the round switching control unit 703 marks round RUN_20260309_001 as abnormally discarded, generates a new runid, and restarts the current round of load testing for Team_003.

[0118] At the output level, the minimum output of the round manager 700 includes a global round identifier (runid, or round identifier for short) and round control instructions.

[0119] The output objects of the round identifier are the Robot Manager 600 and the Collaboration Mode Manager 400, used to bind the robot execution context with the state of the collaborative unit in rounds. For example, the output round identifier is specifically RUN_20260309_002. The Robot Manager 600 binds this round identifier to all robot execution contexts of Team_001 to ensure that the state of the current load test is isolated from the previous round.

[0120] Round control instructions include round switching instructions, context reset instructions, and round discard instructions. Round switching and context reset instructions are output to the robot manager 600 to drive the robot into the next round of load testing. Round discard instructions are output to the collaboration mode manager 400 to update the round execution status of the collaboration unit. For example, the output context reset instruction is specifically {TeamID:Team_001, RunID:RUN_20260309_002, Cmd: Reset Context}. The robot manager 600 clears the previous round's business status (such as room ID, team status) of the Team_001 team robot according to this context reset instruction and binds a new runid, i.e., a new round identifier. The output round discard instruction is specifically {TeamID:Team_003, RunID:RUN_20260309_001, Cmd: Discard Round}. The collaboration mode manager 400 marks the current round status of Team_003 as abnormal according to this round discard instruction.

[0121] Preferably, the round manager 700 can also output round status information, which may include the currently executing round, the rounds completed, and the number of abnormal rounds. By feeding back the round status information to the presentation layer 101, it is convenient for testers to collect load testing data. For example, the output round status information may specifically be "Current round is round 50, 49 rounds completed, 1 round abnormal". Testers can use this information to monitor the load testing progress and health in real time.

[0122] (One implementation method of the pressure testing method)

[0123] The following description, based on the above description of the pressure testing system 100 described herein, refers to... Figures 9 to 15 The present invention will describe a pressure testing method according to one embodiment.

[0124] First, the core logic of the pressure testing method described in this embodiment will be explained.

[0125] Figure 9 A flowchart illustrating the core logic of the stress testing method described in this embodiment is shown. The stress testing method described in this embodiment is applied to the stress testing system 100 described above, so that the stress testing system 100 controls multiple virtual robots to perform multiple rounds of stress testing tasks on the system under test 900.

[0126] like Figure 9 As shown, the pressure testing method described in this embodiment mainly includes four steps: the first step ST100, the second step ST200, the third step ST300, and the fourth step ST400.

[0127] In the first step ST100, according to the preset collaboration configuration, multiple virtual robots are divided into multiple collaboration units, and the association between the collaboration units and the virtual robots is established.

[0128] In the second step ST200, round identifiers are generated and these round identifiers are bound to the aforementioned collaborative units and virtual robots that have established associations.

[0129] In the third step ST300, for the collaborative unit, a ring is completed for these virtual robots based on the synchronization call request initiated by the virtual robot in the collaborative unit, so as to achieve the consistency of the collaborative timing of the virtual robots in the collaborative unit.

[0130] In the fourth step ST400, the round switching is performed according to the preset round strategy.

[0131] The following will describe the specific control of the stress testing method described in this embodiment based on the core logic described above.

[0132] (I) Initialization phase of stress test

[0133] Figure 10 A flowchart of the load testing initialization phase of the load testing method described in this embodiment is shown. The goal of the load testing initialization phase is to complete the configuration loading, resource creation, and status readiness of each module in the load testing system 100. Through the coordinated linkage of each module, parameter consistency verification is achieved, laying the foundation for subsequent collaborative load testing execution and ensuring that each module interacts in an orderly manner according to preset logic after the load testing process starts.

[0134] <Step ST001>

[0135] Testers complete the preset collaboration configuration, load test configuration parameters and round control strategy settings through the presentation layer 101, and call the registration interface of the processor registration center 200, passing in the message type identifier of the target business module and the corresponding processor logic entry to complete the registration of the module-level message processor.

[0136] The preset collaboration configuration includes collaboration modes and collaboration unit identifier configuration requirements. Collaboration modes are divided into single-robot mode and multi-robot mode (including Dual dual-robot pairing mode and Team multi-robot mode). In single-robot mode, a single virtual robot is an independent collaboration unit. In multi-robot mode, two or more virtual robots form a collaboration unit. Round control strategies can be determined based on one or more of the following: whether automatic polling is used, the maximum number of load testing rounds, and the interval between adjacent rounds.

[0137] For example, testers configure the following information on the presentation layer 101 interface: The collaboration mode is set to Team multi-robot mode, with a team size of 5 people, a total of 500 robots, a maximum of 100 rounds, and a round interval of 5 seconds.

[0138] Next, the testers passed the following parameters through the standardized registration interface: The business module identifier is MODULE_MATCH, the message type identifier is MATCH_SUCCESS, and the processor logic entry point is handleMatchSuccessProcessor.

[0139] This completes the registration of the module-level message processor, which will be used for subsequent processing of business logic after a successful match.

[0140] <Step ST002>

[0141] After being verified by the internal registration and verification logic unit 202, the processor registration center 200 generates a message routing rule containing the association between "business module identifier - message type identifier - processor logic entry point" and sends the rule to the message driving module 300 through internal inter-process communication.

[0142] The verification content of the registration verification logic unit 202 includes the uniqueness of the message type identifier and the validity of the processor logic entry. If there are extended inputs such as business module identifiers, their format compliance must also be verified. For example, after verifying the uniqueness of the identifier "MODULE_MATCH+MATCH_SUCCESS" and the validity of the handleMatchSuccessProcessor entry, the processor registration center 200 generates the following routing rules to provide a basis for subsequent message routing: <MODULE_MATCH, MATCH_SUCCESS> → handleMatchSuccessProcessor.

[0143] <Step ST003>

[0144] After receiving the above message routing rules, the message-driven module 300 completes the communication protocol adaptation with the system under test 900 (such as a game server) through the internal protocol adaptation submodule 301, initializes the message sending and receiving channel, clears the wait-wake registry, and enters the message receiving ready state.

[0145] Communication protocol adaptation must be performed according to the communication protocol parameters configured in the presentation layer 101. For example, the WebSocket protocol parameters can be set to "8-byte header length, UTF-8 encoding for data segments, and 30-second heartbeat interval" to ensure that the module can correctly parse the messages sent by the system under test 900.

[0146] <Step ST004>

[0147] Meanwhile, the robot manager 600, based on the load testing configuration parameters issued by the presentation layer 101, uses pooling technology through the robot factory unit 601 to create a preset number of robot instances. Each instance is assigned a unique robot identifier, and all robot identifiers are aggregated into a robot identifier list, which is then reported to the collaboration mode manager 400. Each robot instance created by the robot factory unit 601 is allocated independent process or thread resources to avoid resource contention between instances. For example, 500 independent robot thread instances can be created at once, assigned unique identifiers from Robot_001 to Robot_500, and grouped according to collaboration mode to generate a robot identifier list ([Robot_001], [Robot_002]... in single-robot mode; [Robot_001-Robot_005], [Robot_006-Robot_010]... in Team mode), which is then reported to the collaboration mode manager 400 for collaboration unit division.

[0148] <Step ST005>

[0149] After receiving the robot identifier list, the collaboration mode manager 400, based on the preset collaboration configuration, groups the robot identifier list according to the collaboration mode. It assigns a unique collaboration unit identifier to each collaboration unit according to the collaboration unit identifier configuration requirements, establishing a mapping relationship between "collaboration unit identifier - robot identifier list," and then sends the collaboration unit identifier and collaboration unit size information to the synchronization primitive engine 500. For example, in single-robot mode, each robot is assigned an independent collaboration unit identifier (e.g., Team_001 corresponds to Robot_001, Team_002 corresponds to Robot_002); in multi-robot Team mode, based on the size parameter of 5 people / team, the 500 robots are divided into 100 collaboration units, with unique identifiers assigned from Team_001 to Team_100, establishing a mapping relationship. Team_001→[Robot_001-Robot_005], Team_002→[Robot_006-Robot_010]...Team_100→[Robot_496-Robot_500].

[0150] Next, all collaborative unit identifiers and the size information of each unit are simultaneously sent to the synchronization primitive engine 500 for defining the scope of the synchronization logic.

[0151] <Step ST006>

[0152] The Collaboration Mode Manager 400 reports the list of identifiers for all collaborative units to the Round Manager 700, triggering the generation of the initial round identifier (runid). The Round Manager 700, through the Round Identifier Generation Unit 701, generates the first globally unique runid using a globally unique identifier algorithm. This algorithm can be implemented using any of the following: timestamp, auto-incrementing sequence, or random number. For example, combining the date (20260309) with an auto-incrementing sequence generates the runid: RUN_20260309_001. The Round Manager 700 binds this round identifier to all collaborative unit identifiers and robot identifiers, generating a round status table (initially in "in progress"), and sends the round identifier and context reset command to the Robot Manager 600 for robot context initialization.

[0153] <Step ST007>

[0154] After receiving the round identifier, the robot manager 600 binds the robot identifier, collaboration unit identifier, and initial runid to the execution context of each robot instance through the execution context management unit 602, completing the execution context initialization. Simultaneously, the status monitoring unit 603 updates the status of all robots to "ready" and generates a robot lifecycle event (ready) to be reported to the collaboration mode manager 400. The execution context data structure includes core data such as a globally unique identifier and business status (e.g., login status, team status). Furthermore, only business data is cleared during round switching, while basic identifier information is retained. For example, the execution context bound to Robot_001 is {RobotID:Robot_001, TeamID:Team_001, RunID:RUN_20260309_001, Login status: Not logged in, Team status: Not in a team}.

[0155] After receiving the robot lifecycle event (ready), the Collaboration Mode Manager 400 updates the status of all collaborative units to "ready".

[0156] At this point, the initialization phase of the load test is complete, and all core components have entered the load test execution ready state, waiting for the start command to trigger the subsequent collaborative load test process.

[0157] (II) Collaborative stress testing execution phase

[0158] The goal of the collaborative load testing execution phase is to achieve collaborative interaction among multiple robots within a single collaborative unit and complete the core business logic of this round of load testing.

[0159] This phase supports three load testing modes: basic load testing mode and race condition load testing mode.

[0160] The following sections will elaborate on the collaborative interaction logic of the three modes. Each collaborative unit executes the corresponding process in parallel according to the configured mode.

[0161] Figure 11 A flowchart of the basic stress testing mode of the collaborative stress testing execution phase of the stress testing method described in this embodiment is shown.

[0162] <Basic load testing mode>

[0163] The basic load testing mode is suitable for simple collaborative scenarios without shared data interaction. The core business logic includes login, team formation, matching, and entering the room, without relying on the shared data access unit 604 and the shared storage module 800.

[0164] <Step ST008>

[0165] The robot manager 600 sends a start command to all robots in the collaborative unit. This start command includes core information such as the collaborative unit identifier and round identifier, for example, {TeamID:Team_001, Cmd: Start, RunID:RUN_20260309_001}. Upon receiving the command, the robots execute a preset login script to complete the login operation for the tested system 900 (e.g., a game server)—sequentially entering account and password, selecting a role, and entering the game lobby. Next, they initiate a synchronization call request to the synchronization primitive engine 500. This synchronization call request includes the robot identifier, collaborative unit identifier, current load test round identifier, and the synchronization primitive type identifier corresponding to the synchronization primitive. For example, Robot_001 initiates the following prepare synchronization primitive request to ensure the entire team is synchronized and ready: {RobotID:Robot_001, TeamID:Team_001, RunID:RUN_20260309_001,SyncType:prepare}.

[0166] <Step ST009>

[0167] After the synchronization primitive engine 500 detects that all robots in the collaborative unit have initiated synchronization call requests, it executes the wake-up logic based on the preset preparation synchronization primitives. If some robots fail to initiate requests within the preset time, the synchronization primitive engine 500 triggers a synchronization timeout, waking up the robots in the waiting state. When the synchronization conditions are met (or the timeout is triggered), the synchronization primitive engine 500 generates a synchronization completion status notification and reports it to the collaborative mode manager 400.

[0168] <Step ST010>

[0169] The Collaboration Mode Manager 400 updates the status of the collaboration unit to "Executing" and sends a synchronization wake-up command to the Synchronization Primitive Engine 500 to wake up all waiting robots.

[0170] <Step ST011>

[0171] After being awakened, the robots complete the team formation and matching requests according to a preset script. Specifically, the team leader robot sends a team creation request, and the team member robots send a join request. After the team is formed, the team leader sends a matching request, and the tested system 900 returns a "waiting for matching" response. At this time, all robots send a message waiting request to the message-driven module 300. The message waiting request includes the robot identifier, the collaboration unit identifier, the round identifier, and the target waiting message type (such as "MATCH_SUCCESS"). Based on this, the message-driven module 300 updates the robot status to "message waiting" and records it in the waiting message registry.

[0172] <Step ST012>

[0173] After the tested system 900 completes the matching, it pushes a communication message containing the target message type. The message-driven module 300 parses the communication message and calls the corresponding processor to execute business logic according to the message routing rules. Simultaneously, the message-driven module 300 also searches the waiting message registry and generates a robot wake-up signal based on the search results, sending it to the robot manager 600, and simultaneously sending a message trigger event to the synchronization primitive engine 500.

[0174] <Step ST013>

[0175] After receiving the wake-up signal, the robot manager 600 updates the robot status to "in progress" and initiates a handshake pairing synchronization primitive call request to the synchronization primitive engine 500. After the synchronization primitive engine 500 completes the pairing of all robots, it circles the robot.

[0176] <Step ST014>

[0177] After being awakened, the robot sends a "confirm entry into room" request to the tested system 900, completing the core business logic for this round. After completing the core business logic for this round, it initiates a request to the synchronization primitive engine 500 to complete the synchronization primitive (wait_whole_team_finish), waiting for the entire team to uniformly end the process for this round.

[0178] Figure 12 A flowchart is shown of the competitive condition stress testing mode in the collaborative stress testing execution phase of the stress testing method described in this embodiment.

[0179] <Race Condition Stress Testing Mode>

[0180] The competitive condition stress test mode is suitable for scenarios where multiple robots compete for resources (such as item grabbing). The core business logic includes login, synchronization readiness, resource grabbing, and competition data statistics. It relies on the shared data access unit 604 and the shared storage module 800.

[0181] <Step ST008A>

[0182] The robot manager 600 sends a start command to all robots in the collaborative unit. The start command includes the collaborative unit identifier, round identifier, and competition test configuration parameters (such as the target competing resource ID and the number of competition attempts). For example, the start command is {TeamID:Team_002, Cmd: Start, RunID:RUN_20260310_005, Config:{ResID:ID_1001, TryCount:100}}.

[0183] <Step ST009A>

[0184] After receiving the above start command, the robot executes the login script to complete the 900 login of the system under test, and at the same time loads the special business script for competitive testing.

[0185] <Step ST010A>

[0186] After logging in, the robots sequentially send "prepare" requests to the synchronization primitive engine 500. Once the cumulative number of requests reaches the collaborative unit size, the synchronization primitive engine 500 generates a synchronization completion notification and reports it to the collaboration mode manager 400. The collaboration mode manager 400 updates the unit status to "in progress" and sends a wake-up command to wake up all robots.

[0187] <Step ST011A>

[0188] After being awakened, the robot simultaneously sends a resource preemption request to the system under test (SUT) 900. The request includes the robot identifier, the collaborative unit identifier, and the resource ID. After initiating the preemption request, the robot calls the atomic counting interface (IncTeamData) through the shared data access unit 604 to record the number of attempts. The interface call parameters are bound to the round identifier, and the CAS mechanism ensures accurate concurrent counting. After the SUT 900 returns the preemption result, the robot stores its own preemption state to the shared storage module 800 through the data writing interface (SetTeamData).

[0189] <Step ST012A>

[0190] After the above preemption process is repeated for a preset number of attempts, all robots send a request to the synchronization primitive engine 500 to complete the synchronization primitive (wait_whole_team_finish), waiting for the entire team to end the current round of the process.

[0191] Figure 13 A flowchart of the collaborative task load testing mode in the collaborative load testing execution phase of the load testing method described in this embodiment is shown.

[0192] <Collaborative Task Load Testing Mode>

[0193] The collaborative task stress test mode is suitable for scenarios where multiple robots work together to complete complex goals (such as defeating a BOSS). The core business logic includes login, synchronization readiness, task configuration, division of labor and collaboration, and task progress update. It relies on the shared data access unit 604 and the shared storage module 800.

[0194] <Step ST008B>

[0195] The robot manager 600 sends a start command to all robots in the collaborative unit. The start command includes the collaborative unit identifier, round identifier, collaborative task configuration (such as task objective and task duration), and role assignment information. For example, the start command is {TeamID:Team_003, Cmd: Start, RunID:RUN_20260310_005, Config:{BossID:BOSS_007, Duration:180}, Role:{Leader:Robot_021}}. After receiving the above start command, the robots execute the login script to complete the login to the tested system 900. The leader robot loads the task initialization script, and the member robots load the task execution script.

[0196] <Step ST009B>

[0197] After logging in, the robot sequentially sends prepare synchronous primitive call requests to the synchronization primitive engine 500. Once the cumulative number of requests reaches the target, the synchronization primitive engine 500 generates a synchronization completion notification, and the collaboration mode manager 400 updates the unit status to "in progress" and sends a wake-up command.

[0198] <Step ST010B>

[0199] After being awakened, the team leader robot writes the task configuration parameters through the write interface (SetTeamData) of the shared data access unit 604, and the parameters are bound to the round identifier. The member robots read the configuration parameters through the read interface (GetTeamData) to complete the loading of their own execution context.

[0200] <Step ST011B>

[0201] Once all robots are loaded, they initiate a handshake pairing synchronization primitive call request to the synchronization primitive engine 500. After the synchronization primitive engine 500 completes the pairing of all robots, it wakes them up. The robots execute collaborative logic according to their roles. During execution, the team leader updates the task progress to the shared storage module 800 in real time through the write interface, and the members obtain the real-time status and adjust the execution logic through the read interface.

[0202] <Step ST012B>

[0203] Once the task duration ends or the objective is achieved, all robots send a request to the synchronization primitive engine 500 to complete the synchronization primitive (wait_whole_team_finish), waiting for the entire team to finish the current process.

[0204] (III) Stress Testing Cycle Switching Phase

[0205] Figure 14 A flowchart of the pressure testing cycle switching stage of the pressure testing method described in this embodiment is shown.

[0206] Once a single collaborative unit completes its core collaborative business logic for the current round, and all robots initiate a `wait_whole_team_finish` synchronous call request, the load testing round switching phase begins. The goal of this phase is to achieve global isolation, switching, and reset of load testing rounds, ensuring that business data from different rounds does not overlap and that the load testing process remains continuous and smooth. Simultaneously, based on the round control strategy, it is determined whether to continue polling or terminate the load testing.

[0207] <Step ST020>

[0208] Once all robots within a collaborative unit initiate a wait_whole_team_finish synchronization primitive call request, the synchronization primitive engine 500 detects the synchronization completion status of that collaborative unit and generates a "Collaborative Unit Synchronization Complete" synchronization result event, which is forwarded to the round manager 700 via the collaboration mode manager 400. The round status management unit 702 of the round manager 700 updates the global round status table in real time. When it is detected that all collaborative units have completed the current round of load testing, a round switch is triggered.

[0209] <Step ST021>

[0210] The cycle manager 700 executes subsequent operations according to the preset cycle strategy (including whether to automatically poll, the upper limit of the load testing cycle, and the interval between adjacent cycles). If the upper limit of the cycle has not been reached, a new cycle identifier (runid) is generated using a globally unique identification algorithm (e.g., based on timestamp, auto-incrementing sequence, or random number), the global cycle status table is updated, the new runid is bound to all collaborating unit identifiers and robot identifiers, and cycle switching instructions and context reset instructions are generated and sent to the robot manager 600. If the upper limit of the cycle has been reached, a command to terminate the load testing is generated and sent to all relevant modules or units.

[0211] <Step ST022>

[0212] After receiving the round switching command and the new round identifier, the robot manager 600 resets the context according to the mode differences. In the basic load testing mode, only the robot's previous round's business status data (such as room ID and matching status) is cleared, while basic information such as robot identifier and collaboration unit identifier is retained, and the new runid is bound to the execution context. In the race condition load testing mode, in addition to resetting the context, the shared data access unit 604 also needs to archive the competition data (such as the number of preemption attempts and success / failure statistics) bound to the current round in the shared storage module 800. In the collaborative task load testing mode, in addition to resetting the context, the shared storage module 800 needs to clear the task configuration and progress data (such as the BOSS's remaining health and role assignments) bound to the current round.

[0213] <Step ST023>

[0214] After the context reset is completed, the robot manager 600 sends a start command to all robots, and the robots enter the collaborative execution process of the next round of load testing, repeating the corresponding mode logic of the collaborative load testing execution phase until the preset load testing round is completed.

[0215] <Step ST024>

[0216] If some collaborative units complete a round of load testing while others do not, the round manager 700 will wait until all collaborative units have completed the round before triggering a global round switch to ensure that all collaborative units maintain consistent round progress. If a collaborative unit's current round is abandoned due to an anomaly, the round manager 700 will generate a new round identifier for that unit and drive it to restart the current round of load testing, without affecting the round progress of other normally functioning collaborative units.

[0217] (iv) Anomaly Collaborative Handling Phase

[0218] Figure 15 A flowchart of the abnormal collaborative processing stage of the stress testing method described in this embodiment is shown.

[0219] Optionally, the above-mentioned load testing method also includes an anomaly collaborative handling phase. The goal of the anomaly collaborative handling phase is to quickly respond to various anomalies during the load testing process (such as robot failure, synchronization timeout, message routing failure, etc.), remove the blocking state of collaborative units, handle faulty nodes, avoid a single anomaly causing a global deadlock, ensure the continuous and uninterrupted load testing process, and guarantee the robustness of the load testing.

[0220] <Step ST030>

[0221] During the load test, the status monitoring unit 603 of the robot manager 600 monitors the running status of each virtual robot in real time. If an anomaly is detected in a robot (such as network timeout, no response, or offline failure), a lifecycle event containing the robot identifier, collaboration unit identifier, current round identifier, and reason for the anomaly is generated and reported to the collaboration mode manager 400. Furthermore, the robot's status is marked according to a preset anomaly handling strategy (such as automatic restart or team removal).

[0222] <Step ST031>

[0223] Upon receiving an abnormal lifecycle event, the collaboration mode manager 400 performs a forced wake-up operation on the collaboration unit containing the virtual robot, updating the collaboration unit's status to "abnormal," sending an abnormal wake-up command to the synchronization primitive engine 500, and simultaneously sending an abnormal interruption command to the message-driven module 300. Upon receiving the commands, the synchronization primitive engine 500 terminates all ongoing synchronization logic within the collaboration unit, waking up robots in a synchronization waiting state. Upon receiving the commands, the message-driven module 300 deletes all message waiting records for the collaboration unit, waking up robots in a message waiting state, thus preventing other robots from becoming permanently blocked due to waiting for faulty nodes.

[0224] <Step ST032>

[0225] Subsequently, the collaboration mode manager 400 reports the synchronization result event of "collaboration unit synchronization abnormal interruption" to the round manager 700. The round manager 700 discards the current round identifier corresponding to the collaboration unit, generates a new round identifier (based on timestamp, auto-incrementing sequence or random number) through a globally unique identifier algorithm, and sends the new round identifier and context reset command to the robot manager 600.

[0226] <Step ST033>

[0227] After receiving the above instructions, the robot manager 600 handles the faulty robot according to the exception handling strategy (if the restart is successful, it is retained; if the restart fails, it is removed from the collaborative unit and a backup robot is added), and at the same time, it completes the context reset. Specifically, it clears the business status data of all robots in the previous round of the collaborative unit, retains basic information such as robot identifier and collaborative unit identifier, and binds the new round identifier to the execution context. If it is a race condition or a collaborative task stress test mode, it also needs to clean up the abnormal data (such as incomplete competition statistics and interrupted task progress) bound to the abandoned round in the shared storage module 800.

[0228] After the context reset is complete, the robot manager 600 sends a start command to all robots in the collaborative unit, driving them to re-enter the collaborative execution process of this round of load testing, ensuring that the overall load testing is not affected by single point of failure.

[0229] If multiple collaborative units experience anomalies simultaneously, the anomaly handling process for each unit is executed independently. The Round Manager 700 generates a new round identifier for each anomalous unit and restarts the corresponding round of load testing. Normal collaborative units are not disturbed and continue to execute the current round. After all units complete the current round, they uniformly enter the next round switch to ensure the overall progress and data accuracy of the load testing.

[0230] Furthermore, this disclosure also provides a load testing program product, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the load testing method provided in various optional implementations of the above embodiments.

[0231] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A load testing method applied to a load testing system, wherein the load testing system controls multiple virtual robots to perform multiple rounds of load testing tasks on the system under test, wherein the virtual robots are computational instances simulating client behavior, characterized in that, The pressure testing method includes: The first step is to divide the multiple virtual robots into multiple collaborative units according to the preset collaborative configuration, and establish the association between the collaborative units and the virtual robots. The second step is to generate a round identifier and bind the round identifier to the collaborative unit and the virtual robot. The third step involves waking up the virtual robot within the collaborative unit based on a synchronization call request initiated by the virtual robot in that unit, thereby ensuring the consistency of the collaborative timing of the virtual robots within the unit. The fourth step is to perform round switching according to the preset round strategy.

2. The pressure testing method according to claim 1, characterized in that, The preset collaboration configuration includes preset collaboration modes and collaboration unit identifier configuration requirements. In the first step, The multiple collaborative units are divided according to the collaborative mode, and a collaborative unit identifier is assigned to each collaborative unit according to the collaborative unit identifier configuration requirements, thereby establishing a mapping relationship between the collaborative unit identifier and the virtual robot.

3. The pressure testing method according to claim 2, characterized in that, The collaboration modes include single-robot mode and multi-robot mode. The single-robot mode is a mode in which a single virtual robot is treated as a collaborative unit. The multi-robot mode is a mode in which two or more virtual robots are treated as a collaborative unit.

4. The pressure testing method according to claim 2, characterized in that, In the third step, when it is detected that all the virtual robots in the collaborative unit have initiated the synchronization call request, the virtual robots in the collaborative unit are woken up based on the preset synchronization primitive.

5. The pressure testing method according to claim 4, characterized in that, The synchronization call request includes the robot identifier of the virtual robot, the identifier of the collaborative unit, the identifier of the current stress test round, and the type identifier of the synchronization primitive corresponding to the synchronization primitive.

6. The pressure testing method according to claim 4, characterized in that, The synchronization primitives include preparation synchronization primitives, handshake pairing synchronization primitives, and completion synchronization primitives.

7. The pressure testing method according to claim 4, characterized in that, In the third step, The system determines whether all virtual robots within the collaborative unit have completed the synchronization request within a preset time period. If it is determined that the synchronization call request has not been completed within the preset time period, a synchronization timeout is triggered and the virtual robots in the collaborative unit that have not yet completed the synchronization call request are awakened.

8. The pressure testing method according to claim 1, characterized in that, In the fourth step, The round switching is performed after all the collaborating units have completed the load testing task for the current round. When performing the round switching, the execution context of the virtual robot is reset.

9. The pressure testing method according to claim 8, characterized in that, The round strategy includes any one of the following: whether to automatically poll, the upper limit of the number of load testing rounds, and the interval between adjacent rounds.

10. The pressure testing method according to claim 1, characterized in that, The round identifier is determined by any one of a timestamp, an auto-incrementing sequence, and a random number.

11. The pressure testing method according to claim 1, characterized in that, In the third step, The operating status of the virtual robot is detected. If an abnormality is detected in the operating state of the virtual robot, Forcefully wake up the collaborative unit where the virtual robot is located, and The round identifier of the current round in which the collaborative unit is located is discarded, and a new round identifier is generated for the collaborative unit.

12. A load testing system, wherein the load testing system controls multiple virtual robots to perform multiple rounds of load testing tasks on the system under test, wherein the virtual robots are computational instances simulating client behavior, characterized in that, The pressure testing system includes: A robot manager configured to create and manage the plurality of virtual robots and maintain the execution context of each virtual robot; A collaboration mode manager is configured to divide the multiple virtual robots into multiple collaboration units according to a preset collaboration configuration, and establish an association between the collaboration units and the virtual robots. A message-driven module is configured to send, receive, and parse messages between the load testing system and the system under test, and to execute the message waiting and wake-up logic of the virtual robot. A synchronization primitive engine, configured to wake up the virtual robots within the collaborative unit based on synchronization call requests initiated by the virtual robots within that collaborative unit, thereby achieving consistent collaboration timing among the virtual robots within the collaborative unit; and A round manager is configured to generate round identifiers and bind the round identifiers to the collaborative unit and the virtual robot, and to perform round switching according to a preset round strategy.

13. The pressure testing system according to claim 12, characterized in that, The preset collaboration configuration includes preset collaboration modes and collaboration unit identifier configuration requirements; The collaboration mode manager is configured to divide the multiple collaboration units according to the collaboration mode, and assign a unique collaboration unit identifier to each collaboration unit according to the collaboration unit identifier configuration requirements, and establish a mapping relationship between the collaboration unit identifier and the virtual robot.

14. The pressure testing system according to claim 13, characterized in that, The collaboration modes include single-robot mode and multi-robot mode. In the single-robot mode, the collaboration mode manager treats each virtual robot as an independent collaboration unit. In the multi-robot mode, the collaboration mode manager treats two or more virtual robots as a collaborative unit.

15. The pressure testing system according to claim 13, characterized in that, The synchronization primitive engine is configured as follows: Detect whether all the virtual robots within the collaborative unit have initiated the synchronization call request; and When it is detected that all the virtual robots have initiated the synchronization call request, the virtual robots in the collaborative unit are woken up based on the preset synchronization primitive.

16. The pressure testing system according to claim 15, characterized in that, The synchronization call request includes the robot identifier of the virtual robot, the identifier of the collaborative unit, the identifier of the current stress test round, and the type identifier of the synchronization primitive corresponding to the synchronization primitive. The synchronization primitive engine is configured to match the synchronization primitive type identifier with the synchronization primitive type identifier, and wake up the virtual robot in the collaborative unit based on the matched synchronization primitive.

17. The pressure testing system according to claim 15, characterized in that, The synchronization primitive engine is further configured as follows: Determine whether all the virtual robots within the collaborative unit have completed the synchronization call request within a preset time period; If the task is deemed incomplete, a synchronization timeout is triggered, and the virtual robot in the collaborative unit that is in a synchronization waiting state is awakened.

18. The pressure testing system according to claim 12, characterized in that, The round manager is configured to generate and send round switching instructions and a new round identifier when all collaborating units have completed the current round of load testing. The robot manager is further configured to, upon receiving the round switching instruction and the new round identifier, assign the new round identifier to the virtual robot and reset the execution context of the virtual robot.

19. A stress testing program product, the stress testing program product comprising a computer program, characterized in that, The computer program is executed by a processor to implement the stress testing method according to any one of claims 1 to 11.

Images