Multi-user scene driven game test method and device and electronic equipment

Abstract

The invention provides a game test method and device driven by a multi-person scene and electronic equipment, and the method comprises the steps: configuring a plurality of game accounts based on a preset test case; the game account has a corresponding behavior model; generating a game control message for each game account based on the behavior model of the game account and the account state of other game accounts through a game account control node, and sending the game control message to a game server, so that the game server returns response data corresponding to the game control message to the game account control node; and determining a test result of the test case based on the response data. In the mode, a plurality of game accounts are configured, the game control message is sent to the game server through the behavior model of the game account, and the actual game operation of the player is simulated, so that the automatic test of the multi-player online game is realized, the labor cost is reduced, and the test efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer software testing technology, and more specifically, to a multi-player scenario-driven game testing method, apparatus, and electronic device. Background Technology

[0002] Testing of multiplayer online games typically relies on manual testing teams to perform functional verification, multiplayer interaction checks, and performance testing. This process involves the testing team manually executing game operations according to test cases, recording any problems and anomalies encountered, and then submitting a test report to the development team. Developers then re-verify the game manually after resolving the issues. This method is labor-intensive, struggles to simulate real user load, is inefficient, and prone to errors, leading to low accuracy. While functional testing using the game's application programming interface (API) can directly verify the correctness of each function by calling the backend interface, this approach lacks coverage of complete game scenarios and processes, making it difficult to verify data changes caused by multiplayer interaction and simulate complex state transitions in real games. Furthermore, it incurs high maintenance costs. Summary of the Invention

[0003] In view of this, the purpose of this disclosure is to provide a multiplayer scenario-driven game testing method, device, and electronic device to achieve automated testing of multiplayer online games, reduce labor costs, and improve testing efficiency.

[0004] In a first aspect, embodiments of this disclosure provide a multi-player scenario-driven game testing method, which includes: configuring multiple game accounts based on preset test cases; each game account having a corresponding behavior model; generating game control messages for each game account based on the game account's behavior model and the account status of other game accounts through a game account control node, and sending the game control messages to a game server, so that the game server returns response data corresponding to the game control messages to the game account control node; updating the account status of each game account with the response data returned by the game server; and determining the test results of the test cases based on the response data.

[0005] Secondly, this disclosure provides a multi-player scenario-driven game testing device, comprising: a game account configuration module for configuring multiple game accounts based on preset test cases; each game account having a corresponding behavior model; a game control message generation module for generating game control messages for each game account through a game account control node, based on the game account's behavior model and the account status of other game accounts, and sending the game control messages to a game server, so that the game server returns response data corresponding to the game control messages to the game account control node; the account status of each game account is updated with the response data returned by the game server; and a test result determination module for determining the test results of the test cases based on the response data.

[0006] Thirdly, embodiments of the present invention provide an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-mentioned multi-player scene-driven game testing method.

[0007] Fourthly, embodiments of the present invention provide a machine-readable storage medium storing machine-executable instructions. When the machine-executable instructions are invoked and executed by a processor, the machine-executable instructions cause the processor to implement the aforementioned multi-player scene-driven game testing method.

[0008] The embodiments of the present invention bring the following beneficial effects:

[0009] The aforementioned multiplayer scenario-driven game testing method, apparatus, and electronic device configure multiple game accounts based on preset test cases. Each game account has a corresponding behavioral model. A game account control node generates game control messages for each game account based on its behavioral model and the account status of other game accounts, and sends these messages to the game server. The game server then returns corresponding response data to the game account control node. Based on the response data, the test results of the test cases are determined. This method configures multiple game accounts and sends game control messages to the game server using the game account's behavioral model, simulating actual player actions. This achieves automated testing of multiplayer online games, reducing manual costs and improving testing efficiency.

[0010] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure are realized and obtained through the structures particularly pointed out in the description, claims and drawings.

[0011] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0013] Figure 1 A flowchart illustrating a multiplayer scene-driven game testing method provided in this embodiment of the disclosure;

[0014] Figure 2 A schematic diagram of a hierarchical state transition architecture for a game tournament provided in this embodiment of the present disclosure;

[0015] Figure 3 This is a schematic diagram of a game testing system structure provided in an embodiment of the present disclosure;

[0016] Figure 4 This is a schematic diagram of the structure of a multiplayer scene-driven game testing device provided in an embodiment of the present disclosure;

[0017] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0019] Traditional game testing primarily relies on manual testing teams to perform tasks such as functional verification, multi-player interaction testing, and performance testing. The workflow typically involves the testing team manually executing game operations according to test cases, testers recording problems and anomalies encountered during testing, submitting bug reports to the development team, and then manually verifying the bugs again after development has fixed them.

[0020] This approach has the following limitations: it requires a large amount of human resources for testing, especially in multiplayer game scenarios; test coverage depends on the experience and time investment of testers; it is difficult to conduct large-scale concurrent testing and cannot simulate real user load; repetitive testing leads to human fatigue and reduces test accuracy; and test data collection and analysis are inefficient.

[0021] In some cases, image recognition-based UI automation testing can be used to verify game functionality by simulating actual player interface operations. The workflow typically involves: 1. Recording a pre-defined sequence of actions or writing an image recognition-based test script; 2. Replaying the actions on the actual game client and capturing interface feedback; 3. Verifying the action results through image comparison or OCR recognition; 4. Generating a test report indicating interface anomalies.

[0022] This method requires running on a real game client and relies on screen image recognition and pixel comparison. It typically only supports testing from a single client and a single player's perspective, with a fixed workflow that struggles to adapt to interface changes. This method has the following limitations: it cannot support multi-client collaborative testing scenarios; it is extremely sensitive to changes in interface layout and style; it is slow and inefficient; it is difficult to verify the correctness of server-side data; and it is unsuitable for verifying complex game functions that require multi-role collaboration.

[0023] In some cases, a functional testing approach targeting the game server's API can be adopted to verify the correctness of each function by directly calling the backend interface. The workflow typically involves: defining a list of test APIs and expected response results; writing test cases for single API calls; executing API calls sequentially and verifying the return values; and generating an API call success rate report.

[0024] This method bypasses the client and directly tests the server-side interface, using a single API or a simple combination of APIs as the test unit. It focuses on the format and field correctness of the interface return values ​​and relies on manually constructed test data. However, this method has the following limitations: it lacks coverage of complete game scenarios and processes, cannot verify data changes caused by multi-user interactions, struggles to simulate complex state transitions in real games, is difficult to construct test data, has high maintenance costs, and cannot test problems arising from client-server interactions.

[0025] The aforementioned methods are generally designed based on a single client or single user perspective, lacking systematic testing capabilities for multi-user interaction scenarios. For example, traditional manual testing requires organizing a large number of testers online simultaneously, resulting in high coordination costs, unstable personnel status, and difficulty in ensuring test consistency; UI automation testing focuses on a single interface operation flow and cannot simultaneously control the collaborative behavior of multiple clients; API testing solutions cannot realistically reproduce the complex data dependencies and state changes generated by multi-user interactions. Consequently, many game functions that rely on multi-user interaction mechanisms (such as team formation, guild wars, and multi-user dungeons) cannot be fully validated, and related issues are often only discovered by users after the product is launched.

[0026] The methods described above typically only verify a single aspect (such as UI display or API return values), lacking the ability to verify data consistency throughout the entire game's interactive flow. For example, manual testing relies on the tester's subjective judgment, making it difficult to accurately verify complex data changes; UI automation testing only focuses on visible interface elements and cannot verify underlying data changes; API testing struggles to construct complete game flows and data state chains, resulting in insufficient realism in test scenarios. Consequently, issues such as data flow problems between various game systems, logical errors under boundary conditions, and data inconsistencies during multi-player interactions are difficult to detect effectively, severely impacting the game experience and fairness.

[0027] The methods described above typically lack effective isolation and rapid replication capabilities for the testing environment, resulting in a strong dependence on the environment during the testing process. During testing, shared test servers cause interference between test cases; the environment state is difficult to reset, making it impossible to guarantee consistency at the starting point of the test; and complex server dependencies make it difficult to quickly deploy the same test conditions across different environments. This leads to poor consistency in test results, difficulty in reproducing problems, and low testing efficiency, failing to support the needs of continuous integration and automated regression testing.

[0028] The aforementioned methods typically lack a systematic test scenario modeling and management mechanism, resulting in a huge workload for test scenario creation and maintenance. For example, manual testing requires manually building the account states needed for each test; UI automated test scripts are sensitive to interface changes and have high maintenance costs; API testing requires manually constructing a large amount of complex test data, which is difficult to cover real game scenarios. This leads to insufficient test coverage, a heavy test maintenance burden, difficulty in keeping up with the rapid iteration pace of the game, and increased quality risks.

[0029] The aforementioned methods generally lack modular design and flexible test orchestration capabilities, making it difficult to adapt to different game types and testing needs. For example, the test process is rigid, making it difficult to dynamically adjust the test path based on test results; test code reusability is poor, requiring repeated development of test cases for similar functions; and there is a lack of standardized test components and reusable test pattern libraries. This results in low test development efficiency, an inability to quickly respond to the testing needs of new game features and scenarios, and increases the workload of the testing team and project risks.

[0030] The methods mentioned above each have their own focus, but none of them can effectively address the functional verification needs of complex multiplayer online games, especially for game functional testing in competitive and social multiplayer interaction scenarios. They have significant shortcomings in areas such as multiplayer collaborative testing, realistic scenario simulation, and end-to-end data verification, and cannot meet the depth and breadth requirements of modern online games for testing.

[0031] Based on this, the present disclosure provides a multi-player scenario-driven game testing method, apparatus, and electronic device, which can be applied to scenarios requiring game testing.

[0032] See Figure 1 First, we will introduce a multiplayer scene-driven game testing method provided by an embodiment of the present invention. The method includes the following steps:

[0033] Step S102: Configure multiple game accounts based on preset test cases; each game account has a corresponding behavior model.

[0034] Test cases typically describe the testing tasks performed on a software product, including test objectives, test environment, input data, test steps, expected results, and test scripts. The purpose of test cases is to verify whether the software meets specific requirements. When the software runs on a game server, it can form a game system.

[0035] The test tasks described in the test cases may require multiple game accounts to complete. For example, if the test task is to test whether the game system's processing efficiency for certain game data can reach a preset efficiency threshold when 1000 game accounts log in simultaneously, then 1000 game accounts need to be logged in at the same time. In this case, 1000 game accounts need to be configured.

[0036] In practical applications, communication between game accounts and game servers is typically controlled via terminal devices. During testing, game accounts can be controlled through game account control nodes, each of which can be considered a network node. Each game account control node can control one or more game accounts. Specifically, a game account control node can be a server or a cloud server, and can reside within a distributed storage system.

[0037] In practical applications, different game accounts can be controlled by running different threads on the game account control node, or by running different coroutines. Coroutines are lightweight execution units that consume fewer system resources than threads. A single process can efficiently manage hundreds or even thousands of coroutines, each configured with a game account.

[0038] When configuring game accounts, it's necessary to simulate the game accounts used by real users, including account name, password, level, and friend relationships with other accounts. Game account attributes often correspond to the business they belong to; in a gaming business, it might also be necessary to configure the game character attributes of the account user. Test cases will also limit the type and attributes of the game account.

[0039] The behavioral models corresponding to the aforementioned game accounts are typically pre-built. Specifically, they can be built based on historical operation data of the game account or on the operational logic of the game system. The behavioral models can cover most game system usage scenarios, or they can be specific to the game system usage scenario corresponding to the current test case.

[0040] Different game accounts can have the same behavioral model; for example, in some single-use scenarios, different users' game operations are usually the same. However, different game accounts can also have different behavioral models. For instance, when game accounts use different types of game characters, the logic generating game operations in the game scenario differs, requiring the establishment of corresponding behavioral models.

[0041] Step S104: The game account control node generates game control messages for each game account based on the game account's behavior model and the account status of other game accounts, and sends the game control messages to the game server, so that the game server returns the response data corresponding to the game control messages to the game account control node; the account status of each game account is updated with the response data returned by the game server.

[0042] For each game account, it is necessary to determine the game operation required by the game account based on the game account's behavior model, and then generate a game control message that can represent the game operation performed. This game control message is then sent to the game server to simulate the game control message sent by the business client to the game server after the user performs a game operation through a real business client.

[0043] Game account actions may alter the game system environment on the game server. For example, a game account might change the quantity of a certain virtual item in the game system through specific actions. Other game accounts' actions will be constrained by this altered game system environment. Game accounts need to be aware of other game accounts' actions, determine the necessary changes to the game system environment, and further determine their own required actions based on their behavioral models and the changed game system environment.

[0044] In some cases, a game account's actions can be influenced by the account status of other game accounts. For example, in a game, a virtual character controlled by one game account might only use healing skills when that character is injured. Therefore, a game account also needs to obtain the account status of other game accounts to determine its own game actions based on those account statuses and behavioral models.

[0045] After sending the game control message corresponding to the game account to the game server, the game server receives the game control message, processes the game control message, queries and modifies the data in the game system, and returns response data to the game account control node. The response data usually includes the processing result or query result of the game control message.

[0046] Step S106: Based on the response data, determine the test results of the test cases.

[0047] After receiving the response data from the game system, the response data can be parsed to obtain the parsing results. Test cases typically include expected results, and the parsed results can be compared with the expected results to obtain the test results.

[0048] The aforementioned multiplayer scenario-driven game testing method configures multiple game accounts based on preset test cases. Each game account has a corresponding behavioral model. A game account control node generates game control messages for each game account based on its behavioral model and the account status of other game accounts. These messages are then sent to the game server, prompting the game server to return corresponding response data to the game account control node. Based on this response data, the test results for the test cases are determined. This method configures multiple game accounts and sends game control messages to the game server using their behavioral models, simulating actual player actions. This achieves automated testing of multiplayer online games, reducing manual costs and improving testing efficiency.

[0049] The following embodiment provides a specific method for configuring multiple game accounts based on preset test cases.

[0050] In practical implementation, account type parameters need to be determined based on pre-set test cases. Multiple account types can be pre-defined, and the test cases can describe which account types are needed in the test tasks. Parsing the test cases yields the account type parameters. Then, at least one target node is determined from the pre-set game account control nodes. Multiple game account control nodes can be set up using a distributed system, with each node typically having a limit on the number of game accounts it can control. Based on the required number of game accounts described in the test cases, the number of control nodes needed can be determined, and based on the idle status of each control node, the node matching the required number can be selected as the target node. Then, multiple coroutines are run through the determined target nodes; each coroutine corresponds to one game account. The corresponding game account is then configured through the coroutines based on the account type parameters. Each game account control node manages the account status of the game accounts it controls and generates game control messages corresponding to that game account through the execution logic of the behavior model corresponding to each game account, implementing the game operations that the game account should perform in the test cases.

[0051] Typically, game account instances are pre-set, which can be considered a generic template. Then, a coroutine initializes the preset game account instance based on the account type parameter and loads the corresponding behavior model. Specifically, behavior models can be randomly selected from multiple options, and test cases can specify one or more behavior models as the behavior models corresponding to the game account; there are no restrictions here.

[0052] Typically, a communication protocol is pre-configured between game account control nodes, and different game account control nodes communicate with each other through this protocol. A game account control node can send the account status of the game accounts it manages to other game account control nodes via this protocol, achieving information sharing of game account status among all game account control nodes. Game account actions are usually sequential; the timing of the current game account's action can be determined based on the actions of other game accounts. Therefore, there is no need to synchronize the clocks of multiple game account control nodes; simply operating according to the local clock is sufficient to ensure the timing of actions.

[0053] The following embodiments provide a specific method for generating game control messages based on a behavior model of a game account and the account status of other game accounts.

[0054] The aforementioned game control messages can instruct game operations corresponding to a game account. When a game account performs a corresponding game operation, i.e., sends a game control message to the game server, it typically changes its own account status. For example, it can upgrade or downgrade the game account's level, change a certain account attribute, increase or decrease the number of virtual items the game account possesses, etc. Specifically, the game account's status can be updated based on the response data corresponding to the game control message. To facilitate game accounts' understanding of other game accounts' game operations and statuses, multiple game accounts' game operations and statuses can be stored in a pre-set database. In practical implementation, the game account control node can send the updated account status of the managed game accounts to the database, so that the database can synchronously update the game account's status. The database can use an incremental saving method to improve data processing efficiency.

[0055] Typically, the database also stores relevant parameters for the test cases. These parameters indicate the business tasks corresponding to each game account at each test progress stage. These parameters can indicate the type of game operation the game account needs to perform, the required operation parameters, and the target of the game operation. Business tasks are usually related to test steps. In some cases, a business task can be equivalent to a test step, or a business task may require multiple test steps to implement, or a test step may implement multiple business tasks; no restrictions are placed here.

[0056] Game account actions can advance the test progress described by test cases. The game account needs to retrieve game actions, account status, and relevant test case parameters for multiple game accounts from the database. Then, based on these parameters and the game account's behavior model, the target game action is determined. Specifically, based on these parameters, the current test progress can be determined, leading to the current business task for that game account. Then, based on the game account's current business task and behavior model, the target game action is determined, and the corresponding game control message is generated.

[0057] After the game account control node has controlled the game account it manages to perform the game operation for the current business task, it needs to poll the database for the account status of other game accounts. Then, based on the account status of multiple game accounts and the relevant parameters of the test cases, it determines whether the managed game account can proceed to the next business task.

[0058] For example, a test task requires five game accounts to sequentially send their locations in the virtual world to the game server, and then the game accounts exit the virtual world. After reading the corresponding data from the database and confirming that each game account has sent its location in the virtual world, the game account can determine that its current task is to control the exit from the virtual world, and at this point, it can generate the corresponding game control message for the exit operation.

[0059] In practice, game control messages need to be generated based on the game server's network communication protocol and the target game operation. This method can simulate the communication process between real terminal devices and game servers.

[0060] The aforementioned behavioral model is based on a hierarchical state transition architecture. This architecture is a method for organizing complex game behaviors into a multi-level decision-making structure. It forms a hierarchical progression from top-level strategic decisions to bottom-level specific operations, enabling virtual players to think and act at multiple levels, just like real players.

[0061] The hierarchical state transition architecture adopted by this method is specifically designed for the complex interaction scenarios of multiplayer online games. It effectively simulates the interaction behavior and game process changes between different players through a state machine model, and can accurately capture key state nodes in the game and achieve efficient test coverage.

[0062] A hierarchical state transition architecture typically comprises multiple levels; each level has corresponding judgment conditions (also called "transition conditions") and probability weights. Each level corresponds to a state in the game interaction scenario, meaning the game interaction scenario is broken down into discrete state points corresponding to multiple levels. Through the transition conditions corresponding to each level, transitions between that level and other levels, i.e., transitions between states, can be achieved. Each level has multiple corresponding basic operation units, which can be considered as the operation set corresponding to that level.

[0063] When a game account is in a certain game state, it can execute an operation corresponding to a basic operation unit within the level of that game state. This can also be considered as issuing a game control message to execute that basic operation unit. This operation, acting on the game interaction scenario, generates corresponding response data, causing the game account to transition from that game state to the next. For each level (game state), the execution event that allows the game account to enter the basic operation unit of that level can be considered the entry condition for that level; the execution event that allows the game account to transition from that level to the basic operation unit of the next level can be considered the exit condition for that level.

[0064] The test cases include multiple test steps, each with a corresponding game state. The test cases also typically predefine the operation sequence for each game account. This sequence usually consists of multiple game operations executed sequentially. The test result for each test step is determined by checking whether the account's state reaches the preset game state after some operations are performed.

[0065] The game account control node generates corresponding game control messages for each game account according to the game operation sequence required by the game account in the test case, so as to execute the corresponding game operation and realize the account state transformation of the game account.

[0066] Test cases can also be adjusted based on the account status of multiple game accounts. Multiple test paths can be pre-defined within a test case. Each test path typically includes multiple test steps. Test steps can be partially identical across different test paths. Entry conditions can be pre-defined for each test path, and these conditions are usually related to the game account's account status. When the game account's account status meets the entry conditions of a certain test path, the test path can be switched.

[0067] The switching process of the aforementioned test path can also be determined and implemented through a context-aware artificial intelligence model. Context awareness refers to the technology by which a system dynamically adjusts its behavior to provide more accurate services by collecting, analyzing, and utilizing contextual information (such as time, location, user state, scene semantics, etc.) related to the current environment or task. Specific settings can be configured according to requirements and are not limited here.

[0068] Taking a tournament system as an example, it can be composed of, for instance, [missing information]. Figure 2 The hierarchical state transition architecture shown is illustrated.

[0069] Each level can undergo state transitions based on conditional judgments and probability weights, ensuring both the logical consistency of behavior and simulating the uncertain decision-making process of real players by introducing random factors.

[0070] Taking the tournament process control as an example: starting from the registration stage, the system automatically changes from open to closed at a set time; after entering the group stage, it executes the grouping and matching logic to arrange the matches; in the knockout stage, it automatically executes the match-ups and advancement process based on the performance; finally, it enters the final stage, and automatically transitions to the awards ceremony after completion.

[0071] This architecture ensures that each stage of the tournament proceeds in an orderly manner. The system can automatically switch states according to preset conditions and time nodes, managing the entire event process without human intervention.

[0072] When determining the target game action, it is necessary to identify the target action unit from among the basic action units corresponding to multiple levels, based on the current business task of the game account, the judgment conditions and probability weights of each level of the hierarchical state transition architecture, and then determine the game action corresponding to the target action unit. Within the same level, different basic action units typically have corresponding probability weights. Determining the target action unit through probability weights can increase randomness and simulate the operation process of real players.

[0073] The following embodiments provide a specific method for determining the test results of test cases based on response data.

[0074] Upon receiving the response data, it can be parsed based on the game server's communication protocol format to obtain parsed data. This parsed data typically includes the results corresponding to the game control messages sent by the game account. Then, verification logic is executed based on the verification rules corresponding to the test cases to determine the matching result between the parsed data and the expected result. The verification rules are pre-defined and specify the verification logic; for example, if the parsed data exceeds a preset threshold, then the parsed data matches the expected result. Based on the matching result, the test result of the test case is determined. Each game account typically sends game control messages to the game server multiple times, and the game server correspondingly returns response data to the game account multiple times. The test results can record the matching result between the parsed response data and the expected result for each game control message sent by each game account, and can also compare the matching results for different game accounts, etc. Specific settings can be configured according to requirements and are not limited here.

[0075] The following examples illustrate a specific application in a game, where the method is... Figure 1 This method is implemented based on the method shown. To address the insufficient support for testing multiplayer functional scenarios, it establishes an intelligent robot collaborative system (also known as a "distributed virtual player collaborative control system"). By simulating the precise collaborative behavior of multiple virtual players, it achieves efficient testing of complex multiplayer game scenarios, solving the functional verification challenge in multiplayer interaction scenarios. To address the lack of precise numerical verification mechanisms, it establishes a full-link numerical acquisition and comparison system (also known as a "server-side automated numerical verification system") to achieve consistency verification from front-end display to back-end logic, ensuring the accuracy and stability of core game numerical calculations. To address the difficulty in verifying the correctness of complex gameplay functions, it provides an intelligent scenario construction and verification framework (also known as a "state-driven intelligent scenario testing auxiliary system"). Through standardized gameplay descriptions and automated execution mechanisms, it achieves comprehensive coverage and precise verification of complex game functions.

[0076] This method, by addressing the three core issues mentioned above, will significantly improve the quality assurance capabilities of multiplayer online games, reduce testing costs, accelerate game iteration and release processes, and provide strong technical support for game development teams.

[0077] The core principle of the aforementioned distributed virtual player collaborative control system is as follows: A distributed control architecture based on central scheduling is designed to achieve precise collaborative operations among multiple virtual players. This system ensures accurate simulation and verification of multi-player interaction behavior through unique state synchronization and timing control algorithms. Its key technologies include: a virtual player intelligent decision-making engine based on a character behavior state machine, supporting behavior orchestration under complex conditions; a millisecond-level synchronized distributed instruction scheduling mechanism to ensure precise collaboration of multi-player behaviors; and adaptive scene perception capabilities, enabling virtual players to dynamically adjust their behavior according to the real-time game status.

[0078] The core principle of the aforementioned server-side automated numerical verification system is as follows: It establishes a fully automated verification framework for server-returned data, achieving precise verification of the game logic's correctness by comparing expected results with actual server responses. Its key technologies include: an automatic server response data capture mechanism that accurately acquires and parses various types of game data returned by the server; a rule engine-based server-side data verification framework that supports multi-dimensional data verification under complex conditions; and an automated test report generation system that transforms complex verification results into intuitive and easy-to-understand test reports.

[0079] The core principle of the aforementioned state-driven scenario-based intelligent testing assistance system is as follows: Through precisely controlled virtual player simulation technology, each virtual player executes behaviors according to a preset test scenario, realizing the testing and verification of complex gameplay and providing testers with powerful auxiliary tools. Its key technical points are: The gameplay testing framework based on a state transition model breaks down complex game scenarios into a series of clearly defined discrete state points and transition conditions between states. Each state has clear entry and exit conditions and a set of executable operations, enabling precise control and verification of the testing process; The step-by-step scenario construction mechanism executes test steps according to preset order and conditions and verifies intermediate states. Each test step corresponds to a specific state in the game, and the system drives the game to transition from one state to another through a predefined sequence of operations; The context-aware test execution engine intelligently adjusts subsequent test behaviors based on the current account state. The system continuously monitors the actual running state of the game and dynamically selects the most suitable test path based on state changes, ensuring that the test can adapt to various possible state changes within the game.

[0080] In frame-synchronized multiplayer online game testing, virtual players simulated complete protocol interactions with the server, achieving network behavior indistinguishable from real clients. When multiple virtual players were deployed to the same game scene, each virtual player independently executed preset state transition logic, and these behaviors were distributed to all other players in the scene (including other virtual players and real test clients) through the frame synchronization mechanism.

[0081] For example, when testing team-based dungeon gameplay, the system can deploy three virtual players to simulate team members. Each virtual player executes a different role's combat strategy according to preset state logic: the tank role executes a state loop of "attracting enemy attention - taking damage - using taunt skills," the healer role executes a state loop of "monitoring teammates' health - casting healing spells - avoiding damage," and the DPS role executes a state loop of "finding targets - unleashing combos - dodging attacks." These virtual player behaviors are transmitted in real time via frame synchronization network protocols, allowing testers to verify the integrity of multiplayer cooperative gameplay in a real network environment, greatly reducing the complexity and resource requirements of manual testing.

[0082] This method innovatively integrates a distributed virtual player collaboration system, a server-side automated numerical verification system, and a state-driven automated scene construction system, bringing significant technological breakthroughs and practical value to multiplayer online game testing. Specific beneficial effects are as follows:

[0083] 1. Significantly Improved Testing Efficiency: By utilizing a distributed virtual player collaborative control system, fully automated simulation of multi-user scenarios is achieved, improving testing efficiency by over 300%. Compared to traditional manual testing, which requires multiple testers to work together, this method allows a single test engineer to complete multi-user scenario testing of the same scale, significantly reducing labor and communication costs.

[0084] By leveraging the step-by-step scenario building mechanism within the state-driven scenario automation system, test execution speed is increased by up to 500%. The system can accurately execute pre-set test steps without requiring manual waiting or operation, enabling complex scenario tests that would normally take hours to complete to within tens of minutes, significantly improving test iteration speed.

[0085] 2. Improved Test Accuracy and Coverage: Relying on the rule engine of the server-side automated numerical verification system, the accuracy of test data verification has increased from 85% to over 99.5%. The system can automatically capture and accurately compare the complex data structures returned by the server, avoiding common oversights in manual verification and significantly reducing missed tests and false positives.

[0086] Based on the character behavior state machine in the distributed virtual player system, the test scenario coverage has been improved by 200%. The system can simulate various complex combinations of user behaviors, covering edge scenarios that are difficult to reach with traditional testing, and effectively discovering deep-seated functional defects and performance bottlenecks.

[0087] 3. Reduced R&D and maintenance costs: Through automated test reports from the server-side numerical automation verification system, defect location time has been reduced by 70%. The system can accurately record every step of the testing process and server response. When an anomaly is detected, it can immediately provide detailed on-site data and reproduction steps, significantly shortening the problem analysis time for developers.

[0088] By leveraging a state-driven scenario-based automated build system, regression testing costs have been reduced by 65%. When a new version is released, the system can automatically execute existing test scenarios to quickly verify functional integrity without the need to redesign test cases or allocate testing manpower, significantly reducing the quality assurance costs of version iterations.

[0089] 4. Comprehensive Improvement in Product Quality: Relying on the millisecond-level synchronization mechanism of the distributed virtual player system, the number of timing-related bugs that were difficult to detect in traditional testing increased by 40%. The system can precisely control the operation sequence of multiple players, revealing hidden problems that only appear under specific operation sequences, effectively improving product stability and user experience.

[0090] By combining a server-side data validation framework with state-driven testing, over 85% of potential server-side numerical logic errors can be captured before product release. This significantly reduces the incidence of online anomalies, decreases the number of emergency fixes and version rollbacks, and improves the product's market reputation and user satisfaction.

[0091] This algorithm and architecture design are highly adaptable, applicable not only to multiplayer online game testing but also extending to automated testing scenarios for other complex interactive systems, such as financial trading systems and social networking platforms. It exhibits significant technological spillover effects and industry-leading value. Through the innovative combination of state-driven and distributed control, it solves the long-standing technical challenge of balancing automation and accuracy in multiplayer online game testing, providing a novel solution and practical example for upgrading testing technology across the entire industry.

[0092] The above method can simulate large-scale real-world user operation scenarios, enabling automated verification of game server logic and numerical calculations. The system consists of four main components: a test management server, virtual player control nodes, a data verification engine, and a results analysis platform. The overall architecture is as follows: Figure 2As shown, the overall architecture includes a test management server, virtual player control nodes (equivalent to the aforementioned "game account control nodes," also known as "control nodes"), a data verification engine, and a results analysis platform.

[0093] The test management server is the central control unit of the entire system, and its main functions are as follows:

[0094] 1. Test case management: Store, distribute, and schedule pre-defined test cases.

[0095] 2. Node Coordination and Synchronization: Coordinate the operation synchronization between multiple virtual player control nodes to ensure the consistency of testing in a distributed environment.

[0096] 3. Test process control: Control the start, pause, resumption and termination of the overall test process, but do not directly interfere with the real-time interaction between nodes.

[0097] 4. Data collection and integration: Collect raw test data from each node and perform preliminary integration.

[0098] 5. Test process control: Control the start, pause, resumption and termination of the overall test process.

[0099] The test management server plays the role of the "brain" in the architecture, from which all critical decisions are made.

[0100] The testing system adopts a distributed autonomous management model for coordination, and the responsibilities of each component are as follows:

[0101] 1. Node self-governance: Each virtual player node manages its internal state and execution logic independently, without the need for real-time intervention from a central server.

[0102] 2. The test management server has limited responsibilities: starting test tasks and distributing initial parameters; collecting test results from each node; and not participating in real-time coordination between nodes.

[0103] 3. Inter-node coordination method: Nodes directly exchange status information through an agreed communication protocol; a local clock synchronization mechanism is used to ensure the timing of operations; and the game scene status is automatically coordinated through preset rules.

[0104] Taking tournament functionality testing as an example: the test management server is only responsible for initiating the test task and specifying the number of virtual players and their behavior patterns participating in the tournament. Each virtual player node autonomously completes: the tournament registration process; matching opponents and conducting matches; recording match results; and claiming rewards. After the test, each node feeds back the execution results to the test management server. This decentralized design makes the system more scalable, reduces dependence on a central server, and ensures consistency of test behavior through built-in protocols.

[0105] For tournament modes common in multiplayer competitive games, this method implements a dedicated test case set that can simulate large-scale tournaments with up to hundreds of virtual players participating simultaneously, and monitor server performance metrics and game balance data in real time, effectively identifying performance bottlenecks and game mechanism defects under high concurrency conditions.

[0106] The virtual player control node is the execution unit in the system. Each node can manage multiple virtual player instances simultaneously, and its main responsibilities include:

[0107] 1. Virtual Player Lifecycle Management: Responsible for the creation, initialization, operation, and destruction of virtual players.

[0108] 2. Game client communication: Establish a connection with the actual game client to simulate real user input.

[0109] 3. Status Maintenance and Synchronization: Maintain the internal status of virtual players and keep it synchronized with the management server.

[0110] 4. Action Execution and Feedback: Execute test commands from the management server and feed back the execution results to the management server.

[0111] Each control node can run independently on different physical or virtual machines, supporting horizontal scaling of the system.

[0112] The virtual player control node simulates real user input in the following way:

[0113] 1. Network Protocol Simulation: The virtual player control node will implement the same communication protocol as the game server, directly constructing network data packets that conform to the game protocol specifications, simulating the requests sent by the real client.

[0114] 2. Message Construction: Based on the testing requirements, the system will generate network messages corresponding to various game operations (such as movement, attack, use of skills, etc.). These messages are completely consistent with the messages generated by real players through the game client in terms of format and content.

[0115] 3. Timing control: Send these instructions at reasonable time intervals and operation frequencies to simulate the operation rhythm and habits of real players.

[0116] 4. Status Tracking: Receive and parse the data returned by the game server, maintain the current state of the virtual player in the game, and ensure the continuity and rationality of subsequent operations.

[0117] During testing, upon node initialization, the node manager starts, establishes a connection with the test management server, and receives the test configuration. The node manager then invokes the player factory to create a specified type and number of virtual players according to the task requirements. The behavior engine generates game actions based on the state machine definition and sends them to the game server via the communication module. The data collector receives the responses and feeds them back to the behavior engine for further decision-making.

[0118] Among them, the "Player Factory" is the core component in the control node responsible for creating and managing virtual player instances. Specifically, it can call the createPlayer(type,count) method of the Player Factory to select the corresponding player template according to the type parameter to initialize a virtual player instance, load the corresponding state machine model, connect to the game server, and start executing autonomous behavior.

[0119] This design allows the system to simulate a large number of virtual players on limited hardware resources while maintaining good performance and stability.

[0120] This approach eliminates the need to launch actual game client software; instead, it simulates client behavior directly at the network layer, thereby significantly improving system performance and scalability.

[0121] The data verification engine focuses on verifying data returned by the game server, and its functions include:

[0122] 1. Data capture: Obtain communication data results between virtual players and the server.

[0123] 2. Rule execution: Verify and analyze the acquired data according to preset rules.

[0124] 3. Anomaly detection: Automatically identifies data anomalies that do not conform to expectations.

[0125] 4. Validation report generation: Generate a structured validation result report.

[0126] The data processing flow of the data verification engine includes: data acquisition and parsing process: the data collector receives raw data from the virtual player node, and the protocol parser converts the binary data into a structured format; rule execution process: the parsed data is fed into the rule engine, the rule engine loads applicable rules from the rule repository, and executes the verification logic; result processing process: the matcher compares the actual and expected results, the anomaly detector analyzes the deviation pattern, and the report formatter generates a standard verification report.

[0127] The data verification engine supports multiple game protocol formats and can be configured to adapt to the communication mechanisms of different games. The rules can cover multiple dimensions such as accurate numerical comparison, state transition verification, and time sequence relationship checking. It uses machine learning algorithms to identify data anomaly patterns and supports unsupervised learning to discover unknown types of anomalies.

[0128] The aforementioned rule definition and execution mechanism is based on DSL (Domain-Specific Language) rule description, allowing testers to define verification logic in a manner close to natural language; it supports rule combination and inheritance, and complex verification can be built from basic rules; it provides rule testing and optimization tools to ensure the correctness of the rules themselves and their execution efficiency; the data verification engine can be deployed independently or integrated into the virtual player control node.

[0129] The results analysis platform is the system's data processing and display center, providing the following functions:

[0130] 1. Visualize test results: Transform complex test data into intuitive charts and reports.

[0131] 2. Trend Analysis: Conduct trend analysis based on historical test data to identify potential problems.

[0132] 3. Anomaly Clustering: Classify and cluster discovered anomalies to help locate the root cause of the problem.

[0133] 4. Abnormal Alarm: Abnormal results are alerted to the designated user.

[0134] 5. Report generation and distribution: Generate standardized test reports and support automatic distribution.

[0135] The data flow processing chain of the results analysis platform includes: data reception and processing: the data receiver obtains data from the test management server, and the data processor performs cleaning, standardization and transformation; multidimensional analysis and processing: the processed data is distributed to the visualization engine (for intuitive display), the trend analysis module (for historical comparison) and the data storage (for persistence); anomaly handling and reporting: the trend analysis results are passed to the anomaly clustering module, the identified anomalies trigger the alarm system and are provided to the report generator.

[0136] The real-time data processing adopts a streaming architecture, supporting real-time analysis of large-scale test data; the intelligent anomaly detection process combines statistical models and machine learning algorithms to achieve multi-dimensional anomaly pattern recognition; and it automatically selects the most suitable visualization method based on data characteristics to improve data interpretation efficiency.

[0137] The results analysis platform includes an anomaly clustering module, which can automatically associate similar anomalies to help locate the root cause of problems; based on historical data analysis, it can provide early warnings of potential quality risks; and it can also automatically compare the differences between the current test and historical benchmarks to quantify performance changes.

[0138] The results analysis platform's distributed storage supports long-term storage of test data and analysis results, automatically archives anomalies to form a knowledge base for rapid future problem diagnosis, and supports cross-version and cross-project test result comparison and analysis.

[0139] System overall architecture description:

[0140] 1. Data flow path:

[0141] Control flow: Testers configure tasks through the test management server, which distributes tasks to each control node, and the control nodes drive the virtual players to execute them.

[0142] Test data stream: Virtual players interact with the game server, collect server response data, transmit it to the data verification engine for verification, and report the verification results to the management server.

[0143] Analysis Result Stream: The management server aggregates data, the result analysis platform processes the data, generates reports and alarms, and provides feedback to the testers.

[0144] Test management server: The central nervous system of the system, responsible for task scheduling, status synchronization and data aggregation, ensuring consistency and coordination in the distributed test environment.

[0145] Control Nodes and Virtual Players: Deployed through an N-to-M relationship, one control node can manage multiple virtual players, achieving load balancing and resource optimization.

[0146] Data verification engine: Independent of the control node, it focuses on the analysis and verification of server response data, reducing system coupling.

[0147] Results analysis platform: Multiple components work together to form a complete analysis loop, from visualization to anomaly detection to report generation.

[0148] The control nodes in this method support horizontal scaling and can be dynamically added or removed according to the test scale; components communicate with each other through standardized interfaces, making it easy to replace and upgrade individual modules; containerized deployment allows system resources to be dynamically adjusted according to the load.

[0149] This method employs a hierarchical state transition architecture, decomposing complex game behaviors into composable basic operation units. The system supports condition triggering and probability transfer mechanisms, giving virtual player behavior a certain degree of randomness and adaptability, and more realistically simulating the player's decision-making process.

[0150] This method can execute test steps and verify intermediate states in a preset order and under preset conditions. Each test step corresponds to a specific state in the game. The system drives the game to transition from one state to another through a predefined sequence of operations.

[0151] This method employs an incremental synchronization algorithm that transmits only state change data, ensuring behavioral consistency in a distributed environment. It also performs intelligent resource scheduling, where the node manager dynamically adjusts the number of virtual players based on CPU, memory, and network load to guarantee test quality.

[0152] This method supports dynamically loading behavioral models of different game types through configuration files or APIs; it provides behavior recording and playback functions, and can build virtual player models based on real player behavior; it has a built-in exception handling mechanism to ensure that an exception of a single virtual player does not affect the overall testing process.

[0153] The system supports dynamically loading behavior models for different game genres via configuration files or APIs.

[0154] 1. Configuration file loading: Test engineers can write behavioral model configuration files in JSON / XML format, which are automatically loaded and parsed by the system at startup.

[0155] 2. Dynamic API loading: During testing, APIs such as LoadBehaviorModel("aggressive_midlaner") can be called to switch behavior models.

[0156] 3. Recording and playback: It can record real player behavior data, analyze and extract behavioral patterns, and build new behavioral models.

[0157] This modular design allows the system to flexibly adapt to the needs of different testing scenarios, and can quickly switch the behavior patterns of virtual players without recoding, greatly improving testing efficiency and coverage.

[0158] This system architecture effectively solves the challenges of multi-player collaborative testing, accurate numerical verification, and complex gameplay validation in traditional game testing, significantly improving the quality assurance capabilities of multiplayer online games. By combining containerization technology with computer software testing, it achieves an unprecedented level of testing automation and intelligence.

[0159] In a test of the main city's player capacity and skin rendering performance in a game, it was necessary to verify the client's rendering performance and server response stability when 30 players were online simultaneously, wearing skins of different quality. When implemented manually, this required organizing 30 testers online simultaneously. Testers needed to precisely execute test instructions, wear designated skins, and reach designated locations, resulting in high coordination difficulty. Manual operation also made it difficult to guarantee the consistency and repeatability of test conditions. Subsequently, client performance data from each tester needed to be manually collected and analyzed. Overall, the testing cycle was lengthy, consuming significant time from organizing personnel to data analysis.

[0160] When implementing an API-based containerized testing solution, the first step is to develop an intelligent robot. This involves creating automated scripts based on the game API to simulate player behavior, including core operations such as character login, skin and equipment customization, and location movement. Next, an independent testing environment is deployed using containerization technology, configured with test containers capable of simulating different network conditions and hardware specifications. Thirty simulated player instances are launched with a single click, each configured with different levels of skin resources, precisely controlling the timing and spatial distribution of simulated players entering the main city. Finally, automated data collection is performed, monitoring and recording key client performance metrics in real time, such as FPS, memory usage, and rendering time, while automatically capturing server-side response data and network communication latency. This approach reduces the time required for manual testing from half a day to within 30 minutes, significantly improving testing efficiency. It also eliminates human error, ensures consistent testing conditions, frees up resources for a 30-person testing team, allowing for parallel testing of other tasks, achieving resource optimization, and enabling easy adjustment of test scale to assess performance boundaries. Furthermore, it accurately records the specific conditions causing performance degradation, facilitating problem localization for the development team.

[0161] During the probability verification testing of blind box lottery games, it is necessary to accurately verify the actual acquisition probability of core reward items in the blind box lottery system to ensure consistency with the designed probability and prevent external release incidents caused by probability anomalies. When using traditional manual testing methods, manual testing is limited by time and manpower, making it difficult to obtain statistically sufficient samples. Manual recording and calculation are prone to human error, the single test process is cumbersome, requiring the repetition of a large number of identical operations, and the result analysis is delayed. Data processing and analysis require additional time and cannot quickly respond to anomalies. Sampling verification has limitations and is difficult to perform stratified probability verification based on different user characteristics (such as new users and paying users).

[0162] When implementing a containerized testing solution, the first step is to develop an intelligent lottery bot. This involves developing a dedicated API call module to simulate player lottery behavior, supporting configuration of different user types, number of draws, and trigger conditions. Multiple lottery test instances are then containerized and deployed, supporting simultaneous simulation of thousands of lottery operations for large-scale parallel testing. Different test parameters (such as first draw for new users, multiple draws for active users, etc.) are configured to verify probability performance under various scenarios. During testing, each lottery result is automatically recorded, and the probability distribution is calculated in real time. Early warning thresholds are set, and an alarm is immediately triggered when the actual probability deviates from the design probability beyond the allowable range. Furthermore, a professional test report containing probability distribution charts and confidence interval analysis can be automatically generated, providing historical data comparison and tracking probability trends.

[0163] The test report may include the following:

[0164] 1. Execution summary: test time, test environment, total number of samples; test parameter configuration, such as server version and configuration table version.

[0165] 2. Probability Analysis: Comparison of theoretical and actual probabilities for items of various rarity; acquisition probability and 95% confidence interval for core reward items; verification results of the pity system trigger.

[0166] 3. Anomaly detection: probability deviation analysis and risk assessment; test results under special boundary conditions, such as the distribution of results from 99 consecutive samplings.

[0167] 4. Compliance Conclusion: Whether the probability system meets the design expectations; whether it meets the probability requirements published in the game; probability comparison analysis between versions.

[0168] This method enables precise verification: through over 100,000 sampling tests, the accuracy of probability verification is improved to a 99.9% confidence level; the manual verification process, which previously required several days, is shortened to a full test within one hour, improving testing efficiency; probability deviations can be promptly identified and corrected before version release, avoiding player churn and reputational damage caused by probability issues; a complete probability verification report is provided, meeting the regulatory requirements of the game industry; and when probability anomalies are detected, the code modifications or configuration changes causing the problem can be precisely located.

[0169] When conducting full functionality testing of the tournament, it is necessary to verify the correctness of the entire tournament process, including the registration, points-based matches, knockout stages, and finals, as well as the settlement mechanisms at each stage. Manual testing requires 16-32 testers to participate in the entire tournament simultaneously; the testing period is long, potentially taking 4-6 hours from registration to the end of the finals; manual testing cannot cover all tournament scenarios, such as tie-breaking and reconnection issues; and it requires manually checking each player's score changes, rank advancements, and other data, making result verification tedious.

[0170] When implementing a containerized testing solution, multi-stage simulations can be performed. First, a robot is developed to simulate players automatically registering, competing, and responding to random in-game events. Then, different skill levels are designed for the robot to simulate a real competition environment. During the registration phase, accounts are created in batches and tournament registration is completed. In the points-based stage, the robot participates in multiple rounds of competition according to a preset strategy. In the knockout stage, the correct execution of the advancement and elimination mechanisms is simulated. In the final stage, the final rankings and reward distribution are verified. The system automatically compares the results of each round with the expected score changes to verify the correctness of the advancement list, check the accuracy of reward distribution, and finally display the execution results.

[0171] In this approach, the entire tournament process testing time was reduced from 4-6 hours to 45 minutes, significantly improving efficiency. A single test can simulate 8 different competition scenarios, which is 4 times that of manual testing, covering most testing scenarios. In one version update, automated testing discovered 3 edge case issues (bugs) that manual testing failed to find. It can also generate a summary of the competition process at each stage through data reports, automatically record and mark abnormal situations (errors in score calculation, abnormal advancement logic), and provide the pass / fail status of key functional points, so that relevant personnel can understand the game test results in a timely manner.

[0172] This method provides a full-link testing and verification system for multiplayer online games, with three core innovations:

[0173] (1) Distributed virtual player collaborative control system: capable of simulating the behavior patterns of up to hundreds of real players and supporting complex multi-player interaction scenario testing;

[0174] (2) Server-side automated numerical verification system: Real-time monitoring and verification of game numerical balance and consistency to ensure fair and reasonable game mechanics;

[0175] (3) State-driven scenario intelligent test assistance system: Automatically identify and construct test scenarios through state machine model, greatly improving test coverage and efficiency.

[0176] For the above method embodiments, see Figure 4 The illustrated multiplayer scene-driven game testing device includes:

[0177] The game account configuration module 402 is used to configure multiple game accounts based on preset test cases; each game account has a corresponding behavior model.

[0178] The game control message generation module 404 is used to generate game control messages for each game account through the game account control node, based on the behavior model of the game account and the account status of other game accounts, and send the game control messages to the game server, so that the game server returns the corresponding response data of the game control messages to the game account control node; the account status of each game account is updated with the response data returned by the game server.

[0179] The test result determination module 406 is used to determine the test results of test cases based on the response data.

[0180] The aforementioned multiplayer scenario-driven game testing device configures multiple game accounts based on preset test cases. Each game account has a corresponding behavioral model. A game account control node generates game control messages for each game account based on its behavioral model and the account status of other game accounts. These messages are then sent to the game server, prompting the game server to return response data to the game account control node. Based on the response data, the test results for the test cases are determined. This method configures multiple game accounts and sends game control messages to the game server using their behavioral models, simulating actual player actions. This achieves automated testing of multiplayer online games, reducing manual costs and improving testing efficiency.

[0181] The aforementioned game account configuration module is also used for: determining account type parameters based on preset test cases; determining at least one target node from preset game account control nodes, and running multiple coroutines through at least one target node; and configuring game accounts based on account type parameters through coroutines.

[0182] The aforementioned game account configuration module is also used to: initialize a preset game account instance based on the account type parameter through a coroutine, and load the behavior model corresponding to the game account instance.

[0183] The aforementioned game control message indicates the game operation corresponding to the game account; the aforementioned device further includes: an account status update module, used to update the account status of the game account based on the response data corresponding to the game control message; and an account status storage module, used to store the game operations and account status corresponding to multiple game accounts through a preset database.

[0184] The database also stores relevant parameters for test cases; these parameters are used to indicate the business tasks corresponding to each game account under each test progress; the game control message generation module is also used to: read game operations, account status, and relevant parameters of test cases corresponding to multiple game accounts from the database; determine the target game operation based on the game operations, account status, relevant parameters of test cases, and the behavior model of the game accounts; and generate game control messages corresponding to the target game operation.

[0185] The aforementioned game control message generation module is also used to generate game control messages based on the game server's network communication protocol and the target game's operations.

[0186] The aforementioned game control message generation module is also used to: determine the current business task of a game account based on the game operations, account status, and relevant parameters of test cases corresponding to multiple game accounts; and determine the target game operation based on the current business task and behavior model of the game account.

[0187] The above behavioral model is implemented based on a hierarchical state transition architecture; the hierarchical state transition architecture includes multiple levels; each level has corresponding judgment conditions and probability weights; each level has corresponding multiple basic operation units; the game control message generation module is also used to: determine the target operation unit from the basic operation units corresponding to multiple levels based on the current business task of the game account, the judgment conditions and probability weights of each level of the hierarchical state transition architecture; and determine the game operation corresponding to the target operation unit as the target game operation.

[0188] The aforementioned test result determination module is also used to: parse the response data based on the communication protocol format of the game server to obtain parsed data; execute verification logic based on the verification rules corresponding to the test cases to determine the matching result between the parsed data and the expected result; and determine the test result of the test cases based on the matching result.

[0189] This embodiment also provides an electronic device, including a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor. The processor executes the machine-executable instructions to implement the above-described multiplayer scene-driven game testing method, for example:

[0190] Based on preset test cases, multiple game accounts are configured; each game account has a corresponding behavior model; through the game account control node, game control messages are generated for each game account based on the game account's behavior model and the account status of other game accounts, and sent to the game server, so that the game server returns the corresponding response data to the game account control node; the account status of each game account is updated with the response data returned by the game server; based on the response data, the test results of the test cases are determined.

[0191] In the above method, multiple game accounts are configured, and game control messages are sent to the game server through the behavior model of the game accounts to simulate the actual game operation of the players, thereby realizing the automatic testing of multiplayer online games, reducing manual costs and improving testing efficiency.

[0192] Optionally, the steps of configuring multiple game accounts based on preset test cases include: determining account type parameters based on preset test cases; determining at least one target node from preset game account control nodes, and running multiple coroutines through at least one target node; configuring game accounts based on account type parameters through coroutines.

[0193] Optionally, the above steps of configuring a game account based on account type parameters via coroutines include: initializing a preset game account instance based on account type parameters via coroutines, and loading the behavior model corresponding to the game account instance.

[0194] Optionally, the game control message indicates the game operation corresponding to the game account; the method further includes: updating the account status of the game account based on the response data corresponding to the game control message; and storing the game operations and account status corresponding to multiple game accounts in a preset database.

[0195] Optionally, the database also stores relevant parameters of the test cases; these parameters are used to indicate the business tasks corresponding to each game account under each test progress; the step of generating game control messages based on the behavior model of the game account and the account status of other game accounts includes: reading the game operations, account status, and relevant parameters of the test cases corresponding to multiple game accounts from the database; determining the target game operation based on the game operations, account status, relevant parameters of the test cases, and the behavior model of the game accounts; and generating the game control message corresponding to the target game operation.

[0196] Optionally, the above steps for generating game control messages corresponding to the target game operation include: generating game control messages based on the game server's network communication protocol and the target game operation.

[0197] Optionally, the steps for determining the target game operation based on the game operations, account status, test case parameters, and game account behavior model corresponding to multiple game accounts include: determining the current business task of the game account based on the game operations, account status, and test case parameters corresponding to multiple game accounts; and determining the target game operation based on the current business task and behavior model of the game account.

[0198] Optionally, the above behavioral model is implemented based on a hierarchical state transition architecture; the hierarchical state transition architecture includes multiple levels; each level has corresponding judgment conditions and probability weights; each level has multiple corresponding basic operation units; the steps to determine the target game operation based on the current business task and behavioral model of the game account include: determining the target operation unit from the basic operation units corresponding to multiple levels based on the current business task of the game account, the judgment conditions and probability weights of each level of the hierarchical state transition architecture; and determining the game operation corresponding to the target operation unit as the target game operation.

[0199] Optionally, the steps for determining the test results of test cases based on response data include: parsing the response data based on the communication protocol format of the game server to obtain parsed data; executing verification logic based on the verification rules corresponding to the test cases to determine the matching result between the parsed data and the expected result; and determining the test results of the test cases based on the matching result.

[0200] See Figure 5 As shown, the electronic device includes a processor 100 and a memory 101. The memory 101 stores machine-executable instructions that can be executed by the processor 100. The processor 100 executes the machine-executable instructions to implement the above-described multiplayer scene-driven game testing method.

[0201] Furthermore, Figure 5 The electronic device shown also includes a bus 102 and a communication interface 103, with the processor 100, the communication interface 103 and the memory 101 connected via the bus 102.

[0202] The memory 101 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0203] The processor 100 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 100 or by instructions in software form. The processor 100 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The methods disclosed in the embodiments of this disclosure can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 101, and the processor 100 reads the information in memory 101 and, in conjunction with its hardware, completes the method of the aforementioned embodiments.

[0204] This embodiment also provides a machine-readable storage medium storing machine-executable instructions. When the machine-executable instructions are called and executed by the processor, the machine-executable instructions cause the processor to implement the above-mentioned multi-player scenario-driven game testing method.

[0205] This disclosure provides a multiplayer scene-driven game testing method, apparatus, and electronic device, including a computer-readable storage medium storing program code. The program code includes instructions that can be used to execute the methods described in the preceding method embodiments, for example:

[0206] Based on preset test cases, multiple game accounts are configured; each game account has a corresponding behavior model; through the game account control node, game control messages are generated for each game account based on the game account's behavior model and the account status of other game accounts, and sent to the game server, so that the game server returns the corresponding response data to the game account control node; the account status of each game account is updated with the response data returned by the game server; based on the response data, the test results of the test cases are determined.

[0207] In the above method, multiple game accounts are configured, and game control messages are sent to the game server through the behavior model of the game accounts to simulate the actual game operation of the players, thereby realizing the automatic testing of multiplayer online games, reducing manual costs and improving testing efficiency.

[0208] Optionally, the steps of configuring multiple game accounts based on preset test cases include: determining account type parameters based on preset test cases; determining at least one target node from preset game account control nodes, and running multiple coroutines through at least one target node; configuring game accounts based on account type parameters through coroutines.

[0209] Optionally, the above steps of configuring a game account based on account type parameters via coroutines include: initializing a preset game account instance based on account type parameters via coroutines, and loading the behavior model corresponding to the game account instance.

[0210] Optionally, the game control message indicates the game operation corresponding to the game account; the method further includes: updating the account status of the game account based on the response data corresponding to the game control message; and storing the game operations and account status corresponding to multiple game accounts in a preset database.

[0211] Optionally, the database also stores relevant parameters of the test cases; these parameters are used to indicate the business tasks corresponding to each game account under each test progress; the step of generating game control messages based on the behavior model of the game account and the account status of other game accounts includes: reading the game operations, account status, and relevant parameters of the test cases corresponding to multiple game accounts from the database; determining the target game operation based on the game operations, account status, relevant parameters of the test cases, and the behavior model of the game accounts; and generating the game control message corresponding to the target game operation.

[0212] Optionally, the above steps for generating game control messages corresponding to the target game operation include: generating game control messages based on the game server's network communication protocol and the target game operation.

[0213] Optionally, the steps for determining the target game operation based on the game operations, account status, test case parameters, and game account behavior model corresponding to multiple game accounts include: determining the current business task of the game account based on the game operations, account status, and test case parameters corresponding to multiple game accounts; and determining the target game operation based on the current business task and behavior model of the game account.

[0214] Optionally, the above behavioral model is implemented based on a hierarchical state transition architecture; the hierarchical state transition architecture includes multiple levels; each level has corresponding judgment conditions and probability weights; each level has multiple corresponding basic operation units; the steps to determine the target game operation based on the current business task and behavioral model of the game account include: determining the target operation unit from the basic operation units corresponding to multiple levels based on the current business task of the game account, the judgment conditions and probability weights of each level of the hierarchical state transition architecture; and determining the game operation corresponding to the target operation unit as the target game operation.

[0215] Optionally, the steps for determining the test results of test cases based on response data include: parsing the response data based on the communication protocol format of the game server to obtain parsed data; executing verification logic based on the verification rules corresponding to the test cases to determine the matching result between the parsed data and the expected result; and determining the test results of the test cases based on the matching result.

[0216] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0217] Furthermore, in the description of the embodiments of this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this disclosure based on the specific circumstances.

[0218] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of this disclosure, in essence, or the parts that contribute to the prior art, or parts of the technical solutions, can be embodied in the form of software products. These computer software products are stored in a storage medium and include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0219] In the description of this disclosure, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this disclosure and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0220] Finally, it should be noted that the above embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A multi-player scenario-driven game testing method, characterized in that, The method includes: Multiple game accounts are configured based on preset test cases; each game account has a corresponding behavioral model. The game account control node generates game control messages for each game account based on the behavior model of the game account and the account status of the multiple game accounts, and sends the game control messages to the game server, so that the game server returns response data corresponding to the game control messages to the game account control node; the account status of each game account is updated with the response data returned by the game server; Based on the response data, the test results of the test cases are determined.

2. The method according to claim 1, characterized in that, The steps for configuring multiple game accounts based on preset test cases include: Determine account type parameters based on preset test cases; At least one target node is determined from the preset game account control nodes, and multiple coroutines are run through the at least one target node; The game account is configured through the coroutine based on the account type parameter.

3. The method according to claim 2, characterized in that, The steps of configuring a game account based on the account type parameter via the coroutine include: The coroutine initializes a preset game account instance based on the account type parameter and loads the behavior model corresponding to the game account instance.

4. The method according to claim 1, characterized in that, The game control message indicates the game operation corresponding to the game account; The method further includes: Based on the response data corresponding to the game control message, update the account status of the game account; The game operations and account status corresponding to the multiple game accounts are stored in a preset database.

5. The method according to claim 4, characterized in that, The database also stores relevant parameters for the test cases; these relevant parameters are used to indicate the business tasks corresponding to each game account under each test progress. The steps of generating game control messages based on the behavior model of the game account and the account status of other game accounts, and sending the game control messages to the game server, include: Read the game operations, account status, and relevant parameters of the test cases corresponding to the multiple game accounts from the database; Based on the game operations, account status, relevant parameters of the test cases, and the behavioral model of the game accounts corresponding to the multiple game accounts, the target game operation is determined. Generate the game control message corresponding to the target game operation.

6. The method according to claim 5, characterized in that, The step of generating the game control message corresponding to the target game operation includes: Based on the network communication protocol of the game server and the target game operation, a game control message is generated.

7. The method according to claim 5, characterized in that, Based on the game operations, account status, relevant parameters of the test cases, and the behavioral model of the game accounts corresponding to the multiple game accounts, the steps to determine the target game operation include: Based on the game operations, account status, and relevant parameters of the test cases corresponding to the multiple game accounts, the current business task of the game account is determined; Based on the current business tasks and behavior model of the game account, the target game operation is determined.

8. The method according to claim 7, characterized in that, The behavioral model is implemented based on a hierarchical state transition architecture; the hierarchical state transition architecture includes multiple levels; each level has corresponding judgment conditions and probability weights; Each level has multiple corresponding basic operation units; Based on the current business tasks and behavior model of the game account, the steps to determine the target game operation include: Based on the current business task of the game account, the judgment conditions and probability weights of each level of the hierarchical state transition architecture, the target operation unit is determined from the basic operation units corresponding to the multiple levels. The game operation corresponding to the target operation unit is determined as the target game operation.

9. The method according to claim 1, characterized in that, The steps for determining the test result of the test case based on the response data include: Based on the communication protocol format of the game server, the response data is parsed to obtain parsed data; Based on the verification rules corresponding to the test cases, the verification logic is executed to determine the matching result between the parsed data and the expected result; Based on the matching results, the test results of the test cases are determined.

10. A multi-player scene-driven game testing device, characterized in that, The device includes: The game account configuration module is used to configure multiple game accounts based on preset test cases; each game account has a corresponding behavior model. The game control message generation module is used to generate game control messages for each game account through the game account control node, based on the behavior model of the game account and the account status of other game accounts, and send the game control messages to the game server, so that the game server returns response data corresponding to the game control messages to the game account control node; the account status of each game account is updated with the response data returned by the game server; The test result determination module is used to determine the test result of the test case based on the response data.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the multiplayer scene-driven game testing method according to any one of claims 1-9.

12. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores machine-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the multi-player scene-driven game testing method according to any one of claims 1-9.

Images