Test method, device, electronic equipment, computer readable storage medium and computer program product

Abstract

This application provides a testing method, apparatus, electronic device, computer program product, and computer-readable storage medium. The method includes: in response to receiving a test instruction, acquiring pre-recorded test cases; for each operation data, controlling a first virtual object to perform a first operation corresponding to the operation data based on the operation data; when the first operation is a movement operation, acquiring target position data corresponding to the operation data from the test cases, verifying the position of the first virtual object based on the target position data, and obtaining a verification result; when the verification result indicates that the verification has failed, pausing the execution of the test cases, and updating the position of the first virtual object based on the target position data; resuming the execution of the test cases after the position update until a test result is obtained. This application enables timely position correction when the first virtual object exhibits positional deviation, avoiding test interruptions due to error accumulation, thereby effectively improving the continuity and success rate of testing.

Description

Technical Field

[0001] This application relates to computer technology, and more particularly to a testing method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] During game development and version iteration, to ensure the stability of various game functions, extensive and repetitive regression testing of existing content is typically required. Traditional purely manual testing methods are labor-intensive, inefficient, and prone to human error. Therefore, mainstream game development projects have widely adopted automated testing platforms to assist and optimize the testing process.

[0003] However, automated testing techniques in related technologies mainly focus on the mechanical recording and replay of surface-level interactive operation commands. When handling operations such as continuous movement, due to the lack of closed-loop verification of the actual physical spatial coordinates and underlying states of the controlled objects in the game, spatial and temporal deviations in execution results are easily generated when faced with environmental changes such as device frame rate fluctuations and differences in character movement speed, leading to problems such as test interruption or test failure. Summary of the Invention

[0004] This application provides a testing method, apparatus, computer-readable storage medium, and computer program product that can promptly correct the position of a first virtual object when a positional deviation occurs during the execution of test cases, thereby avoiding test interruption due to error accumulation and effectively improving the continuity and success rate of testing.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a testing method, the method comprising: In response to receiving a test instruction, a pre-recorded test case is obtained, wherein the test case includes at least one operation data for a first virtual object; For each of the operation data, based on the operation data, control the first virtual object to perform the first operation corresponding to the operation data; When the first operation is a movement operation, the target location data corresponding to the operation data is obtained from the test case, and the location of the first virtual object is verified based on the target location data to obtain the verification result; When the verification result indicates that the verification has failed, the execution of the test case is paused, and the position of the first virtual object is updated based on the target location data; Resume execution of the test cases after the location is updated until the test results are obtained.

[0006] This application provides a testing apparatus, including: The acquisition module is used to acquire pre-recorded test cases in response to receiving a test instruction, wherein the test cases include at least one operation data for a first virtual object; The control module is used to control the first virtual object to perform the first operation corresponding to each operation data, based on the operation data. The acquisition module is further configured to, when the first operation is a movement operation, acquire target location data corresponding to the operation data from the test case, perform location verification on the first virtual object based on the target location data, and obtain a verification result; The execution module is used to pause the execution of the test case and update the position of the first virtual object based on the target location data when the verification result indicates that the verification has failed. The execution module is also used to resume the execution of the test cases after the location is updated, until the test results are obtained.

[0007] In the above scheme, the control module is further configured to parse the operation data to obtain the operation control and operation parameters corresponding to the first operation; generate a control instruction based on the operation control and the operation parameters; and send the control instruction to the first virtual object to control the first virtual object to execute the first operation.

[0008] In the above scheme, the control module is further configured to determine the operation control corresponding to the first operation; when the operation control corresponding to the first operation is a target control used to control the movement of the first virtual object, the first operation is determined to be the movement operation; or, the operation intent corresponding to the first operation is determined; when the operation intent indicates that the first operation is used to control the movement of the first virtual object, the first operation is determined to be the movement operation.

[0009] In the above scheme, the execution module is further configured to determine the first position data after the first virtual object performs the first operation corresponding to the operation data; determine the position offset based on the first position data and the target position data; and determine the verification result as verification failed when the position offset is greater than a preset threshold.

[0010] In the above scheme, the execution module is further configured to determine the position corresponding to the first position data of the first virtual object as the starting position; determine the position corresponding to the target position data as the ending position; construct a movement path from the starting position to the ending position based on the starting position and the ending position; and control the first virtual object to update its position based on the movement path.

[0011] In the above scheme, the execution module is further configured to update the execution status of the test case from the running state to the paused state; correspondingly, the execution module is further configured to, in response to updating the execution status of the test case to the paused state, stop sending the control instruction corresponding to the next operation data in the test case to the first virtual object, and determine the current execution progress of the test case.

[0012] In the above scheme, the execution module is further configured to obtain the current execution progress of the test case, and obtain the remaining pending operation data from the test case based on the current execution progress; update the execution status to the running status, and control the first virtual object to execute each pending operation data in sequence; and generate the test result after each pending operation data has been executed.

[0013] In the above scheme, the execution module is further configured to obtain test status data of the first virtual object after executing each of the data to be executed, and obtain target status data of the first virtual object from the test case; when the test status data matches the target status data, obtain the running status data of the test case during execution; when the running status data does not contain abnormal data, generate a test result indicating that the test has passed.

[0014] In the above scheme, the execution module is further configured to determine the deviation information between the test state data and the target state data when the test state data does not match the target state data; or, when the running state data contains abnormal data, generate abnormal information based on the abnormal data; and generate a test result to characterize the test failure, wherein the test result to characterize the test failure includes at least one of the deviation information and the abnormal information.

[0015] In the above scheme, the execution module is further configured to, when the timing for generating the test case is reached, respond to receiving at least one second operation, generate operation data corresponding to each second operation; when the second operation is a movement operation for a second virtual object, determine the target location data of the second virtual object and the second operation; and construct the test case based on the operation data and the target location data corresponding to each second operation.

[0016] In the above scheme, the execution module is further configured to obtain the operation control and operation parameters corresponding to the second operation; and encapsulate the operation control and operation parameters into the operation data according to a preset format.

[0017] In the above scheme, the execution module is further configured to obtain first time information when each second operation is triggered; arrange the operation data and target position data corresponding to each second operation in a time sequence according to the first time information to obtain an operation sequence; obtain the target state data of the second virtual object after each second operation is executed; and generate the test case based on the operation sequence and the target state data.

[0018] In the above scheme, the execution module is further configured to parse the test cases to obtain multiple test nodes and second time information corresponding to each test node; determine the execution order between each test node based on each second time information; and establish the connection relationship between each test node based on the execution order to obtain a test node graph.

[0019] In the above scheme, the execution module is further configured to output the test node graph; in response to receiving an update instruction for a target test node in the test node graph, determine the update parameters corresponding to the update instruction; and perform data update processing on the target test node based on the update parameters to obtain the updated test node graph.

[0020] In the above scheme, the execution module is further configured to, in response to receiving the test instruction, obtain the test node diagram; execute each test node sequentially according to the connection relationship between each test node in the test node diagram; and obtain the test result after the execution of each test node is completed.

[0021] In the above scheme, the execution module is further configured to determine the number of times the position update is executed during the execution of the test case, and the position deviation data at each position update; when the number of times exceeds the number threshold, or the position deviation data reaches the preset condition, generate update prompt information for the test case, and output the update prompt information; in response to receiving a confirmation instruction for the update prompt information, replace the target position data in the test case with the first position data corresponding to the first virtual object to obtain a new test case.

[0022] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the testing method provided in the embodiments of this application.

[0023] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the testing method provided in this application when executed by a processor.

[0024] This application provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implements the testing method provided in this application.

[0025] The embodiments of this application have the following beneficial effects: In this embodiment, firstly, in response to a test command, pre-recorded operation data is acquired, and the first virtual object is automatically controlled to perform the corresponding operation, thus achieving automated testing of the first virtual object. This effectively reduces the cost of manual testing and improves the reusability and basic execution efficiency of the test. Secondly, for movement operations that are prone to errors in the virtual environment, this embodiment introduces a precise verification mechanism based on target position data. This mechanism can capture the positional offset of the virtual object during movement in real time and accurately. When a position verification failure is detected, the execution of the test case is paused, and the position of the first virtual object is updated. This effectively avoids the chain reaction where all subsequent interactive operations fail due to misalignment caused by incomplete preceding movement. Finally, after position calibration is completed, the execution of subsequent test cases is seamlessly resumed until the final test result is output. This enhances the robustness and fault tolerance of the automated testing framework, ensures the continuous execution capability of long-chain and complex test cases, and significantly reduces the probability of having to rerun the entire test case due to occasional movement errors, thereby effectively improving the continuity and success rate of testing. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the structure of the testing system provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the terminal 400 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the testing method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the process of controlling a first virtual object to perform a first operation, provided in an embodiment of this application. Figure 5 This is a flowchart illustrating the process of obtaining verification results provided in an embodiment of this application; Figure 6 This is a schematic diagram of the process for updating the position of the first virtual object according to an embodiment of this application; Figure 7 This is a schematic diagram of the process for obtaining test results provided in an embodiment of this application; Figure 8This is a schematic diagram of the process for constructing test cases provided in an embodiment of this application; Figure 9 This is another flowchart illustrating the construction of test cases provided in an embodiment of this application; Figure 10 This is a schematic diagram of the game interface during the recording stage provided in an embodiment of this application; Figure 11 This is a schematic diagram of the interface of the recording stage test tool provided in the embodiments of this application; Figure 12 This is a schematic diagram of position correction provided in an embodiment of this application; Figure 13 This is a schematic diagram of multiple test nodes provided in an embodiment of this application; Figure 14 This is a schematic diagram of the position verification and correction mechanism provided in the embodiments of this application; Figure 15 This is a schematic diagram of the technical architecture provided in the embodiments of this application; Figure 16 This is a technical architecture flow diagram provided in the embodiments of this application; Figure 17 This is a schematic diagram of the recording stage process provided in the embodiments of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0029] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0030] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0031] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0032] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0033] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0034] 1) Responding to: used to indicate the conditions or states on which the operation is performed depends. When the conditions or states on which it depends are met, one or more operations can be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0035] 2) Test Cases: A set of standardized instructions or documents designed in advance to verify whether a specific function in a software or game works as expected. These instructions include execution conditions, operation steps, input data, and expected results. In the context of automated testing, test cases typically involve converting manually demonstrated screen clicks, joystick drags, and other interactive behaviors into structured scripts with timestamps and coordinate information. This allows the testing system to automatically and repeatedly replay these operation steps and compare the final running state, thereby efficiently identifying program defects and ensuring the stability of product functions after each version update.

[0036] In game development and testing, each game version update requires retesting previously defined test cases to verify game functionality. Traditional manual testing methods are labor-intensive, inefficient, and prone to errors. To improve testing efficiency, most mainstream game projects now use Automated Testing Platforms (ATP) to record player actions and then replay these actions after each game version update. Current recording systems mainly consist of two steps: action recording and data storage. The system detects player interactions with user interface (UI) elements on the screen (such as button clicks and joystick drag events), saving data such as action type, timestamp, location information, and action parameters as test case files. During playback, the system reads the test case files, resimulates these interactions according to the recorded sequence and timing, and observes the game's performance to determine if it meets expectations.

[0037] However, for continuous, non-discrete operations (such as dragging in the joystick user interface, long-pressing the fishing button, etc.), due to the uncertainty of the operation result, the actual result of the operation during playback may differ from that during recording, leading to the failure of subsequent operations. When players control the character's movement with the joystick, due to factors such as speed differences caused by variations in character equipment during playback, game frame rate fluctuations, network latency, or game version logic updates, the character often cannot reach the precise target position recorded during recording. This positional deviation will cause subsequent operations that rely on precise positions (such as releasing skills on other game characters) to completely fail. Related technologies only record and replay UI operations, lacking a mechanism for recording and verifying the actual physical position or state result, and cannot solve the time synchronization problem caused by changes in movement speed. When test cases fail as a result, it is extremely difficult for testers to troubleshoot the root cause, ultimately leading to a very low reuse rate of recorded test cases and increasing the workload of a large amount of repetitive recording.

[0038] Therefore, it is evident that the testing methods in the relevant technologies suffer from at least the following problems: 1) Lack of underlying state recording and closed-loop verification mechanisms: The testing methods in related technologies only record and play back the surface-level "UI operation commands," completely ignoring the recording of the actual movement coordinates and physical state of the controlled entity. The system cannot detect whether the entity has truly reached the expected position during playback, nor does it have the ability to automatically correct deviations and adjust its position.

[0039] 2) Spatial position deviation in operation results: Due to uncontrollable factors such as differences in character attributes (such as changes in movement speed caused by equipment) and fluctuations in client frame rate, the displacement results during playback often have serious spatial errors compared to the recording. For example, the same 2-second joystick operation, due to the movement speed decreasing from 5 m / s to 3 m / s, will result in a 4-meter positional deviation, directly causing subsequent precise interactions based on that position (such as skill release) to fail.

[0040] 3) Time synchronization issues exist in the execution process: The test timeline in related technologies is forcibly bound to the operation instructions. When the controlled entity's speed decreases, resulting in a longer time to reach the target point, the playback system will still mechanically execute the next operation according to the original recording time, causing the action triggering time to be misaligned.

[0041] 4) Difficulty in anomaly attribution and troubleshooting: Under the black-box replay mechanism in related technologies, once subsequent node tests fail, the system cannot provide comparative data or visual prompts on the deviation of the character's position. Testers find it difficult to distinguish whether the character's position is incorrect or whether there is a problem with the game logic itself, which greatly increases the debugging burden.

[0042] 5) Severely degraded test assets with extremely low reuse rate: Due to the combined effects of the aforementioned spatial and temporal deviations, automated test cases are extremely fragile. Any minor environmental change or version update can cause a precipitous drop in test case pass rates, forcing testers to repeatedly re-encode test cases manually, which violates the original intention of automated testing: "record once, reuse long-term".

[0043] To address the aforementioned problems, this application provides a testing method, apparatus, device, computer-readable storage medium, and computer program product. These methods enable timely position correction when a first virtual object exhibits a positional deviation during test case execution, preventing test interruptions due to error accumulation and effectively improving test continuity and success rate. The following describes exemplary applications of the electronic device provided in this application. This electronic device can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and in-vehicle terminals, or as a server. Exemplary applications of the electronic device as a server terminal will be described below.

[0044] See Figure 1 , Figure 1 This is a schematic diagram of the structure of the testing system provided in the embodiments of this application. Figure 1The system involves a database 100, a server 200, a network 300, and a terminal 400. Terminal 400 connects to server 200 via network 300, which can be a wide area network (WAN), a local area network (LAN), or a combination of both. Pre-recorded test cases can be stored in database 100, which can be independent of server 200 or deployed on server 200. Figure 1 The database 100 is shown as an example, independent of the server 200.

[0045] In this system, terminal 400 responds to received test instructions by sending the instructions to server 200. Upon receiving the instructions, server 200 retrieves pre-recorded test cases from database 100 and sends these cases to terminal 400. Each test case includes at least one operation data point targeting a first virtual object. For each operation data point, terminal 400 controls the first virtual object to perform the corresponding first operation. When the first operation is a movement operation, terminal 400 retrieves the target location data from the test cases and verifies the location of the first virtual object using this data. If verification fails, a location update mechanism is triggered, pausing test case execution and updating the first virtual object's location based on the target location data. Execution resumes after the location update until the final test result is obtained.

[0046] In some embodiments, the test cases sent by the server 200 to the terminal 400 may be generated by the terminal 400 (or other terminals) in response to receiving at least one operation when the timing for generating test cases is determined. For each second operation, operation data corresponding to the second operation is generated, and when the second operation is a movement operation for a second virtual object, the target location data of the second virtual object and the second operation are determined. The test cases are then constructed based on the operation data and target location data corresponding to each second operation. The terminal 400 then sends the constructed test cases to the server 200.

[0047] In some embodiments, server 200 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminals and servers can be connected directly or indirectly via wired or wireless communication, which is not limited in this embodiment.

[0048] Taking the aforementioned terminal as an example, which is the electronic device being tested, see [link / reference]. Figure 2 , Figure 2 This is a schematic diagram of the structure of the terminal 400 provided in the embodiment of this application. Figure 2 The terminal 400 shown includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the terminal 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 440.

[0049] Processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0050] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0051] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0052] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0053] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0054] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc. Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.). The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0055] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A test apparatus 455 stored in memory 450 is shown. This apparatus can be software in the form of programs and plug-ins, and includes the following software modules: an acquisition module 4551, a control module 4552, and an execution module 4553. These modules are logically connected and can therefore be arbitrarily combined or further separated according to the functions they implement. The functions of each module will be described below.

[0056] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the test method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0057] The testing methods provided in this application will be described in conjunction with exemplary applications and implementations of the terminals provided in the embodiments of this application.

[0058] The following describes the testing method provided in the embodiments of this application. As mentioned above, the electronic device implementing the testing method of the embodiments of this application can be a terminal, a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0059] It should be noted that the test examples below are illustrated using game scenarios. Those skilled in the art, based on their understanding of the following text, can apply the test methods provided in the embodiments of this application to applications with spatial coordinate systems, such as virtual reality or augmented reality applications, metaverse platforms, digital systems, and autonomous driving test platforms, to perform motion trajectory verification, position synchronization testing, or automated traversal testing on virtual objects (such as virtual digital humans, simulated vehicles, drone models, etc.). All other application scenarios derived from the technical concepts and principles of this application, as well as automated testing schemes implemented using the same or similar principles, fall within the scope of protection claimed in this application.

[0060] See Figure 3 , Figure 3 This is a flowchart illustrating the testing method provided in the embodiments of this application, which will be combined with... Figure 3 The steps shown are explained.

[0061] In step 101, in response to receiving a test instruction, a pre-recorded test case is obtained, which includes at least one operation data for the first virtual object.

[0062] Here, a test command refers to a trigger signal used to initiate an automated testing process. Test commands can be triggered in various scenarios: they can be actively triggered by testers manually clicking the start button, selecting test cases, and confirming execution in a visual tool interface; they can be automatically triggered by the automated testing platform according to preset strategies during scheduled tasks, version build completion, etc.; or they can be remotely triggered via external system calls, interface requests, or debugging commands. Upon receiving the trigger signal, the terminal will uniformly recognize it as a valid test start command, and then begin loading the corresponding test cases and initiating the execution process. Pre-recorded test cases refer to a set of data collected and stored in advance to simulate user operations. The first virtual object refers to the virtual character or object to be tested in the virtual scene, and the operation data refers to the specific data used to describe user interaction behavior. This step refers to the device retrieving the pre-recorded test cases from storage after receiving the start test command. These test cases contain at least one set of operation-related data for controlling the first virtual object. For example, after receiving the command to start testing a game character, the device retrieves pre-recorded test cases containing operations such as game character movement and skill release.

[0063] In step 102, for each piece of operation data, the first virtual object is controlled to perform the first operation corresponding to the operation data based on the operation data.

[0064] Here, "operation data" refers to the basic data used to drive the first virtual object to perform actions. The first virtual object is the main object in the virtual scene that performs the actions. The first operation refers to the specific action behavior corresponding to the operation data, such as moving, jumping, releasing skills, interacting, picking up items, turning, etc., actions that the virtual object can perform. This step involves processing each set of operation data in the test case and, based on the defined content of the operation data, controlling the first virtual object to complete the corresponding action. For example, for a movement command recorded in the operation data, controlling the first virtual object to perform a forward movement action.

[0065] In some embodiments, see Figure 4 The step 102, "based on the operation data, control the first virtual object to execute the first operation corresponding to the operation data," can be achieved through steps 1021 to 1023, including: In step 1021, the operation data is parsed to obtain the operation control and operation parameters corresponding to the first operation.

[0066] Here, "operational data" refers to a structured collection of information pre-packaged in a unified format, fully recording user interaction behavior. It may include core content such as the triggering mechanism and specific characteristics of the operation. "Operational controls" refers to the virtual interface interaction elements or physical input components upon which the first operation is triggered, commonly including joysticks, skill release buttons, control buttons, pick-up interaction buttons, and view adjustment sliders. "Operational parameters" refers to numerical, state, or instructional information used to precisely describe the details of the first operation's execution, such as the sliding direction, angle, and duration of the joystick; the number of clicks and release timing of the skill button; and the pressure value and coordinate points of the touch operation. This step is the core link in the automated testing process, connecting the raw recorded data with executable control instructions. Its core function is to structurally decompose and parse the packaged and integrated operation data, filtering out invalid and redundant information, and accurately extracting the two key types of information required to execute the first operation: operation controls and operation parameters. This lays the foundation for generating accurate control instructions subsequently. For example, by analyzing a piece of operation data related to the movement of a virtual character, the operation control can be extracted as "main movement joystick", and the operation parameters are "sliding direction is 45 degrees forward and right, sliding distance is 80 pixels, and continuous pressing duration is 1.5 seconds"; as another example, by analyzing the operation data of skill release, the operation control can be obtained as "basic attack button", and the operation parameters are "click 3 times in a row, with an interval of 0.3 seconds between each click".

[0067] In step 1022, control instructions are generated based on the operation controls and operation parameters.

[0068] Here, control commands refer to standardized command information that conforms to the underlying execution protocol of the virtual environment and can be directly recognized and responded to by the first virtual object. They are the core medium connecting the operation parsing results with the execution of virtual object actions. This step is a crucial link in automated testing to ensure the operation is implemented. Its core function is to integrate, encode, and assemble the parsed operation controls and parameters according to a command format recognizable by the virtual environment, transforming scattered control and parameter information into standardized, executable commands. This ensures that the first virtual object can accurately understand and execute the corresponding first operation. For example, based on the parsed operation control "main joystick" and operation parameters "sliding direction 30 degrees forward and left, sliding distance 60 pixels, duration 2 seconds," a standardized control command containing the joystick identifier, movement vector, and execution duration is generated to drive the first virtual character to move in the specified direction and duration.

[0069] In step 1023, a control command is sent to the first virtual object to control the first virtual object to perform the first operation.

[0070] Here, standardized control commands generated are stably, accurately, and promptly sent to the first virtual object via the terminal's internal command transmission channel. This allows the first virtual object to respond according to the command requirements and complete the corresponding first operation, thereby fully reproducing the preset operational behavior in the test environment and ensuring that the test process proceeds as expected. For example, movement control commands containing movement direction, movement speed, and duration can be sent to a game character, causing the character to move forward strictly according to the trajectory and speed set in the commands.

[0071] In this embodiment, when the device controls the first virtual object to perform the first operation, it first parses the operation data, extracts the specific controls and corresponding parameter information involved in the operation, and then generates corresponding control instructions based on these controls and parameters. These instructions are then sent to the first virtual object to drive it to complete the specified action. This allows for accurate control of the virtual object to reproduce its original operational behavior in the test environment, thereby improving the accuracy of the test.

[0072] In some embodiments, after controlling the first virtual object to perform the first operation corresponding to the operation data, the operation type can also be determined through the following process, including: Determine the operation control corresponding to the first operation; when the operation control corresponding to the first operation is a target control used to control the movement of the first virtual object, determine that the first operation is a movement operation; or, determine the operation intent corresponding to the first operation; when the operation intent indicates that the first operation is used to control the movement of the first virtual object, determine that the first operation is a movement operation.

[0073] Here, "operation controls" refer to virtual interface interaction components or input controls triggered by the user when performing interactive actions, including movement joysticks, directional buttons, skill buttons, and interaction buttons; while "target controls" refer to predefined, dedicated controls specifically used to control the spatial position changes of the first virtual object in the virtual scene, such as movement joysticks and directional buttons; "operation intent" refers to the actual behavioral purpose that the operation aims to achieve, determined through a comprehensive judgment of operation data, operation logic, or the operation object; and "movement operation" refers to the type of operation that causes the first virtual object to undergo coordinate changes or positional shifts in virtual three-dimensional or two-dimensional space. The purpose of this step is to intelligently and accurately identify whether the first executed operation belongs to the movement category that will cause a positional change by either identifying the type of operation control or analyzing the operation intent. This provides a basis for determining whether to initiate the position verification and calibration process, ensuring that only operations that actually cause displacement enter the position verification stage. For example, if the target control corresponding to the current operation is detected to be a movement joystick or directional control key, then the operation is directly determined to be a movement operation; or, if the operation logic determines that the purpose of the current operation is to control the character to move from the current position to a specified position, then even if the movement control is not directly triggered, it can still be determined to be a movement operation based on the operation intent.

[0074] In this embodiment, after the first operation is completed, the system intelligently determines whether the action just performed is a movement operation that requires spatial displacement by identifying the type of control bound to the current operation or by analyzing the behavioral intent behind the operation. This allows for the accurate filtering of movement operations that require position verification, providing a foundation for subsequent position calibration mechanisms and improving the smoothness and efficiency of the testing process.

[0075] See also Figure 3 In step 103, when the first operation is a movement operation, the target position data corresponding to the operation data is obtained from the test case, and the position of the first virtual object is verified based on the target position data to obtain the verification result.

[0076] Here, target position data refers to the standard coordinates, orientation, and posture information that the first virtual object should reach after performing the corresponding movement operation, recorded during the test case recording phase. This serves as the baseline for position verification. Position verification refers to the process of comparing the actual position of the first virtual object after performing the movement operation with the baseline target position, calculating the deviation, and determining whether it exceeds the standard. Verification result refers to the conclusion obtained after deviation comparison, determining whether the position verification is qualified and whether correction is needed. The purpose of this step is to accurately verify the actual position of the first virtual object after identifying the movement operation, using the standard position in the test case as a reference. It promptly identifies positional deviations caused by factors such as fluctuations in the operating environment, frame rate changes, and logical anomalies, providing a clear basis for determining whether to trigger pause or correction processes, ensuring that subsequent test operations do not fail due to positional deviations. For example, after the first virtual object performs a movement operation, its actual coordinates, orientation, and other positional information in the virtual scene are compared item by item with the target position pre-recorded in the test case to obtain the result of whether the position verification passes.

[0077] In some embodiments, see Figure 5 Step 103, "verifying the location of the first virtual object based on the target location data and obtaining the verification result," can be achieved through steps 1031 to 1033, including: In step 1031, the first position data after the first operation corresponding to the first virtual object's operation data is determined.

[0078] Here, the first position data refers to the actual coordinates, orientation, and spatial posture information of the first virtual object in the virtual scene after completing the first operation. This information serves as the true basis for subsequent position deviation calculations. The purpose of this step is to collect and determine the real spatial position of the first virtual object in the virtual world in real time after the movement operation is completed. This provides accurate and reliable measured data for subsequent comparison with target position data and offset calculations, ensuring the authenticity and accuracy of position verification. For example, after the first virtual character completes the specified movement operation, its final coordinates, orientation, and other actual position information in the scene are read and recorded in real time.

[0079] In step 1032, the position offset is determined based on the first position data and the target position data.

[0080] Here, the position offset refers to the sum of the distance difference, direction difference, and coordinate deviation between the actual position of the first virtual object obtained through spatial calculation and the expected standard position. It can intuitively quantify the degree of position deviation. The purpose of this step is to perform numerical calculations on the actual position and the target position, transforming the fuzzy position deviation into a comparable and quantifiable indicator, providing accurate data support for subsequent judgment and verification of whether it has passed.

[0081] In step 1033, when the position offset is greater than a preset threshold, the verification result is determined to be that the verification failed.

[0082] Here, the preset threshold refers to the maximum reasonable range of positional deviation allowed for the first virtual object, serving as a unified standard for determining whether the position exceeds the limit. The verification result refers to the final verification conclusion derived from the comparison between the positional offset and the preset threshold. The purpose of this step is to compare the quantified positional offset with the allowable deviation range, clearly determining whether the position after this movement operation meets the test requirements. This quickly distinguishes between normal errors and abnormal offsets, providing a clear basis for subsequent decisions on whether to initiate pause and position correction processes. For example, if the preset threshold is one coordinate unit, and the calculated positional offset exceeds this value, the position verification will be deemed unsuccessful.

[0083] In this embodiment, during position verification, the actual coordinates of the virtual object in the game world after completing the action are first obtained, and then compared with the expected target coordinates recorded in the test case to calculate the error distance. If this spatial offset exceeds the allowable range, the position verification is deemed a failure. This quantifies the degree of position deviation, thereby accurately identifying positional misalignments caused by uncontrollable factors such as frame rate fluctuations or changes in movement speed, thus improving the accuracy of position verification for the first virtual object.

[0084] See also Figure 3 In step 104, when the verification result indicates that the verification has failed, the execution of the test case is paused, and the position of the first virtual object is updated based on the target location data.

[0085] Here, a failed verification indicates that the positional offset of the first virtual object has exceeded the allowable range, affecting the accuracy of subsequent tests. Pausing test case execution means temporarily halting the issuance and execution of subsequent test case instructions without changing the current scene state. Position update refers to correcting the deviated first virtual object to the expected standard position based on the target position data, eliminating the impact of the offset. The purpose of this step is to promptly interrupt the testing process upon identifying abnormal positional offsets, avoiding cascading failures in subsequent operations and distorted test results due to positional errors. Simultaneously, it performs precise positional correction of the first virtual object, providing a reliable prerequisite for subsequent test resumption and ensuring stable execution of test cases. For example, if a game character's movement position is detected to deviate beyond the allowable range, the execution of the current test case is immediately paused, and the character is corrected to the specified standard position according to the target position data.

[0086] In some embodiments, see Figure 6The step 104, "updating the position of the first virtual object based on the target location data," can be implemented through steps 1041 to 1044, including: In step 1041, the position corresponding to the first position data of the first virtual object is determined as the starting position.

[0087] Here, the starting position refers to the actual position of the first virtual object in the position correction process, which is used as the starting point for movement correction and subsequent construction of the correction path. The purpose of this step is to accurately locate the starting point of position correction, ensuring that the correction process is based on the actual deviation state, making subsequent path planning more in line with the actual scene, and making position correction smoother and more natural.

[0088] In step 1042, the location corresponding to the target location data is determined as the endpoint location.

[0089] Here, the endpoint location refers to the expected standard location that the first virtual object needs to reach during the location correction process, which is also the target end point of this correction path. The purpose of this step is to clarify the final goal of the location correction, using the predefined standard location in the test case as the correction endpoint, ensuring that subsequent path planning and location correction revolve around the expected goal, and guaranteeing that the corrected location is consistent with the requirements of the test case.

[0090] In step 1043, a movement path from the starting position to the ending position is constructed based on the starting position and the ending position.

[0091] Here, the movement path refers to a reasonable and executable route planned for the first virtual object from its starting position to its ending position, ensuring a smooth position correction process that conforms to the scene logic. The purpose of this step is to automatically generate a smooth and reasonable correction route based on the determined correction start and end points, combined with the spatial structure and movement rules of the virtual scene. This avoids logical anomalies caused by direct teleportation, making the position update process closer to the real-world operating state.

[0092] For example, if the starting position coordinates are (90, 90) and the ending position coordinates are (100, 100), first calculate the direction vector and straight-line distance between the two points, then divide the entire route into multiple consecutive small coordinate segments according to a fixed step size. Connecting these points in sequence forms a straight-line path from the starting point to the ending point. The first virtual object can complete the path movement by moving these points in sequence.

[0093] In some embodiments, environmental information such as terrain, obstacles, and colliders in the virtual scene needs to be combined with a path planning algorithm to generate a safe and collision-free correction route. A reasonable path is planned between the starting and ending points that avoids obstacles and smoothly corrects the position, ensuring that the first virtual object does not experience clipping, jamming, or logical anomalies during position correction, and that the correction process conforms to the physical rules of the virtual scene. For example, if the starting position coordinates of the first virtual object are (90, 90) and the ending position coordinates are (100, 100), and there is a wall obstacle between the two points, making a straight line impassable, the path planning algorithm will detect the obstacle and first plan a zigzag path from (90, 90) to (90, 100) and then to (100, 100), or automatically find detourable passage nodes, connecting multiple walkable points sequentially to ultimately form a complete movement path that avoids obstacles and safely reaches the ending point from the starting position.

[0094] In step 1044, the first virtual object is controlled to update its position based on the movement path.

[0095] Here, the movement path is a pre-planned, safe, and obstacle-avoiding correction route, containing a series of continuous waypoints and directions of travel. Position update refers to the entire process of the first virtual object moving along the specified path, ultimately reaching the target position and completing the correction. The purpose of this step is to issue continuous movement control commands based on the generated path, driving the first virtual object to move smoothly, efficiently, and compliantly from the starting position to the ending position, completing automatic correction without disrupting the scene logic, and ensuring that subsequent test steps can continue to execute in the correct position.

[0096] In this embodiment, when it is determined that the position of the first virtual object has deviated, a movement path is planned using the current actual position of the first virtual object as the starting point and the expected target position as the ending point. The first virtual object is then controlled to move along this path to the correct target position. This guides the first virtual object to automatically correct its position, correcting the position deviation without interrupting the overall testing process, ensuring that subsequent behavior is consistent with expectations, and improving the stability and accuracy of test case execution.

[0097] In some embodiments, "pausing the execution of test cases" in step 104 can be achieved through the following process: The execution status of the test case is updated from running to paused. Correspondingly, in response to updating the execution status of the test case to paused, the control command corresponding to the next operation data in the test case is stopped from being sent to the first virtual object, and the current execution progress of the test case is determined.

[0098] Here, the execution status is used to mark the current stage of a test case in real time. The running status indicates that the test case is executing instructions normally in sequence. The paused status indicates that the test process is temporarily suspended and no new operation instructions are issued. The current execution progress is the overall progress information of the completed steps, the currently paused steps, and the subsequent steps to be executed, which can be used as the basis for resuming execution. The purpose of this step is to safely and systematically pause the entire test process when the position is abnormal, avoiding chain errors caused by the continued execution of subsequent instructions due to position deviation. At the same time, it accurately records the current execution breakpoint and progress information, ensuring that execution can be resumed from the breakpoint after the position is corrected, without repeating or losing steps, and maintaining the integrity and stability of the test process.

[0099] In this embodiment, when the testing process needs to be paused, the status label of the current test task is switched to paused, and the issuance of subsequent action commands is immediately cut off. The current test case's execution progress is recorded. This allows for a safe interruption of the current test execution process, temporarily freezing the test case's execution progress without affecting the scenario state. Once the position correction is complete and the first virtual object returns to its expected position, the status label is restored to normal execution, and subsequent test steps continue from the previously recorded breakpoint. This ensures the entire testing process is coherent, stable, and timely, preventing subsequent operation misalignments, execution chaos, or test case failures, thereby improving the stability and success rate of automated testing.

[0100] See also Figure 3 In step 105, the execution of test cases resumes after the location is updated until the test results are obtained.

[0101] Here, resuming test case execution means restarting the paused test process from the previously recorded breakpoint and continuing to execute the remaining unfinished operation steps in sequence. The test result refers to the final judgment obtained after all test cases have been executed, determining whether the test runs normally, meets expected logic, and whether any anomalies exist. The purpose of this step is to ensure that after the first virtual object completes position correction and returns to the expected standard position, the subsequent test process continues from the pause breakpoint, guaranteeing that the entire test case is executed completely, coherently, and unaffected by abnormal offsets, ultimately outputting a true and valid test conclusion and ensuring the complete closed loop of the automated test process. For example, after the virtual character is corrected to the target position, the execution of subsequent operation instructions resumes from the pause point, completing the remaining interaction and verification steps in sequence, and outputting the final result of whether the test case passed after all steps are executed.

[0102] In this embodiment, firstly, in response to a test command, pre-recorded operation data is acquired, and the first virtual object is automatically controlled to perform the corresponding operation, thus achieving automated testing of the first virtual object. This effectively reduces the cost of manual testing and improves the reusability and basic execution efficiency of the test. Secondly, for movement operations that are prone to errors in the virtual environment, this embodiment introduces a precise verification mechanism based on target position data. This mechanism can capture the positional offset of the virtual object during movement in real time and accurately. When a position verification failure is detected, the execution of the test case is paused, and the position of the first virtual object is updated. This effectively avoids the chain reaction where all subsequent interactive operations fail due to misalignment caused by incomplete preceding movement. Finally, after position calibration is completed, the execution of subsequent test cases is seamlessly resumed until the final test result is output. This enhances the robustness and fault tolerance of the automated testing framework, ensures the continuous execution capability of long-chain and complex test cases, and significantly reduces the probability of having to rerun the entire test case due to occasional movement errors, thereby effectively improving the continuity and success rate of testing.

[0103] In some embodiments, see Figure 7 The step 105, "resume execution of test cases after location update until test results are obtained," can be achieved through steps 1051 to 1053, including: In step 1051, the current execution progress of the test case is obtained, and the remaining data of operations to be executed is obtained from the test case based on the current execution progress.

[0104] Here, the current execution progress refers to the breakpoint information recorded when the test case pauses, and the pending operation data is the set of all unexecuted operation instructions in the test case from the breakpoint until the end of the test case. The purpose of this step is to accurately locate and extract the subsequent operations that need to be executed based on the recorded breakpoint progress, ensuring that execution can resume from the breakpoint upon test recovery, without repeating completed steps or omitting any pending instructions, thus maintaining the continuity and correctness of the test flow. For example, if the test case triggers a pause when executing the fifth operation, based on this execution progress, it continues to read the data of the sixth and subsequent unexecuted operations as the basis for resuming execution after test recovery.

[0105] In step 1052, the execution status is updated to the running status, and the first virtual object is controlled to execute each operation data to be executed in sequence.

[0106] Here, the execution status is updated to running status, indicating that the test case has ended its pause and re-entered the normal execution process. The pending operation data consists of the complete operation information in the test case that has not yet been completed and needs to be executed sequentially. The purpose of this step is to formally resume the test execution process after the position correction is completed and the breakpoint information is confirmed to be correct. It drives the first virtual object to execute the remaining operations one by one according to the preset order, so that the test can continue smoothly, continuously, and orderly from the breakpoint. This ensures that the entire test process is uninterrupted, without repetition, and without omissions, and ultimately completes all the execution logic of the test case.

[0107] In step 1053, after each operation data to be executed is completed, test results are generated.

[0108] Here, the test result refers to the real-time assessment of whether the virtual object responds normally, whether its position matches expectations, and whether its logic is correct after a single operation step is completed. The purpose of this step is to verify and record the execution effect after each operation is completed following resumption, thereby collecting test results. This allows for real-time monitoring of the test execution status and provides data support for subsequent analysis, ensuring that anomalies are traceable and results are verifiable.

[0109] In this embodiment, once the first virtual object is corrected to the correct position, the previously recorded pause progress is retrieved, all remaining operation data from the test cases that have not yet been executed is collected, and then the state is switched back to run mode. The first virtual object is then controlled to execute the remaining operation data sequentially, and finally, a complete test result is given. In this way, subsequent test steps can be seamlessly connected after the correction is completed, ensuring the continuity and integrity of the test process.

[0110] In some embodiments, "generating test results" in step 1053 can be achieved through the following process: Obtain the test status data of the first virtual object after executing each operation data to be executed, and obtain the target status data of the first virtual object from the test case; when the test status data matches the target status data, obtain the running status data of the test case during execution; when the running status data does not contain abnormal data, generate a test result indicating that the test has passed.

[0111] Here, the test status data includes the actual position, posture, behavioral results, and scene response information of the first virtual object after performing the operation; the target status data is the standard state that should be reached after the operation is completed, as predetermined by the test case; the running status data is real-time information on system logic, command issuance, frame rate stability, and module operation during test execution; and the exception data includes exception information such as command execution failure, logic errors, behavioral abnormalities, stuttering, or unexpected events. This step employs a dual matching and verification mechanism: first, it verifies whether the actual state of the virtual object matches the target state; then, it verifies whether there are any exceptions during the execution process. Only when both requirements are met is the test considered passed, thus ensuring the accuracy, rigor, and reliability of the test results. For example, after each operation is completed, the actual state of the character is first compared with the preset target state, and then it is confirmed that there are no errors or exceptions in the entire execution process, ultimately generating a test pass result.

[0112] In this embodiment, when judging whether a test is successful, not only is the actual state after the virtual object's action is completed compared with the expected state, but also, assuming complete state alignment, an additional check is made to see if there are any error messages during the underlying operation. Only when both checks are completed without any abnormalities is the test considered successful. This allows for a multi-dimensional and rigorous evaluation of the test results, thereby improving the comprehensiveness and accuracy of the verification results.

[0113] In some embodiments, exceptional situations may also be handled through the following procedures: When the test status data does not match the target status data, determine the deviation information between the test status data and the target status data; or, when the running status data contains abnormal data, generate abnormal information based on the abnormal data; generate a test result to characterize the test failure, wherein the test result to characterize the test failure includes at least one of deviation information and abnormal information.

[0114] Here, deviation information quantifies the difference between the actual and expected states, including detailed information such as deviation type, deviation value, and deviation location. Anomaly information is extracted from data such as errors, stutters, lost instructions, and logical exceptions encountered during execution, providing specific descriptions and location information for these anomalies. The purpose of this step is to accurately collect and record the detailed reasons for state mismatches or operational anomalies when tests fail to meet expectations. The deviation information and anomaly information are integrated into the failed test results, forming a localizable, traceable, and analyzable failure report, facilitating subsequent troubleshooting and test case optimization. For example, when the actual position of the character differs from the target position, the specific coordinate deviation is recorded; when an error occurs during execution, the anomaly type and the timing of its occurrence are recorded, ultimately generating a failed test result containing the aforementioned detailed information.

[0115] In this embodiment, if the actual state of the first virtual object after execution does not match the target state, or if abnormal data is found in the running status data, the specific deviations and error information will be further extracted and summarized into a test result containing this specific diagnostic information. This provides testers with detailed and intuitive data to troubleshoot problems, reduces the difficulty of diagnosing and debugging anomalies during testing, reduces the time cost of manually locating problems, and further improves the reliability, efficiency, and problem reproducibility of the test.

[0116] In some embodiments, see Figure 8 Test cases can also be constructed through steps 201 to 203, including: In step 201, when the timing for generating test cases is reached, in response to receiving at least one second operation, operation data corresponding to each second operation is generated.

[0117] Here, the generation timing refers to the effective trigger moment when preset conditions are met and the test case recording state is formally entered. Only after entering this timing will subsequent operations be recognized and recorded as test case content. For example, the generation timing is considered to have been reached when the user actively clicks the record button, enters the specified test scenario, receives the start recording instruction, meets the preset process trigger conditions, or detects the user's first valid interactive operation, thus initiating the operation data collection and generation process. The second operation is the real interactive behavior initiated by the user in the virtual scenario, including operations such as moving virtual objects, adjusting the viewpoint, releasing skills, using props, and scene interaction, as well as system-level operations such as logging in, entering the scenario, switching pages, configuring parameters, starting the test, pausing, and exiting. Operation data is executable instruction information formed after the user's interactive actions are standardized and structured and recorded. The purpose of this step is to capture each step of the user's interactive behavior in real time when the recording conditions are met, converting discrete manual operations into standardized data that can be played back and verified, providing the original data foundation for subsequently building complete and executable test cases. For example, after entering the recording mode, the user's movement, clicks, skill releases, and other operations are captured in real time, and corresponding structured instruction data is generated for each step of the operation.

[0118] In some embodiments, "generating operation data corresponding to the second operation" in step 201 can be achieved through the following process, including: Obtain the operation controls and operation parameters corresponding to the second operation; encapsulate the operation controls and operation parameters into operation data according to a preset format.

[0119] Here, the operation controls are the interface elements, virtual buttons, or functional components triggered by user interaction; the operation parameters are the quantitative information such as the corresponding numerical value, direction, position, duration, and level of the operation; the preset format is a predefined, standardized data structure that can be used for subsequent parsing and playback; and the operation data is an executable and storable operation record formed by encapsulating control information and parameter information. The purpose of this step is to decompose the user's actual interaction behavior into identifiable and reusable structured data, unifying the format and standardizing it, providing a stable and reliable data foundation for the recording, storage, playback, and verification of subsequent test cases. For example, after obtaining the virtual joystick control and its movement direction and displacement parameters, it is encapsulated into standard operation data according to a preset binary or key-value pair format.

[0120] In this embodiment, when players or testers interact with the screen, the system captures the specific buttons or joystick controls they touch, along with corresponding parameters such as the sliding range and click force. This fragmented information is then packaged and archived according to a standard data structure recognizable by the terminal. This allows for the structured and standardized preservation of the user's original interactive commands, improving the standardization and accuracy of the generated operation data.

[0121] See also Figure 8 In step 202, when the second operation is a movement operation on the second virtual object, the target position data of the second virtual object corresponding to the second operation is determined.

[0122] Here, the target location data refers to the expected standard location information that the second virtual object should reach after completing this movement operation, including key state data such as coordinates, orientation, and height for subsequent verification. The purpose of this step is to bind the user-initiated movement operation with the corresponding expected result during test case recording, forming a standard target location that can be used for subsequent automated testing and comparison, ensuring accurate verification of whether the movement has met the standard during playback. For example, after the user drags the character from the starting point to a designated location through a movement operation, the terminal collects the coordinates and orientation of that location as target location data for subsequent testing.

[0123] In step 203, test cases are constructed based on the operation data and target location data corresponding to each second operation.

[0124] Here, a test case is a complete executable test script formed by structurally integrating the data of each operation step with the corresponding target location data according to the execution sequence, and supplementing it with information such as test case identifiers, execution rules, and verification logic. The purpose of this step is to transform discrete operation records and expected location results into an automated and precisely verifiable test process through standardized structured integration, ensuring that test cases possess the core characteristics of being replayable, repeatable, and traceable. For example, in actual implementation, the operation execution sequence assigns a unique step index to each operation data step, binds the operation data with the target location data corresponding to that operation, and then encapsulates metadata such as test case identifiers, execution priorities, and exception thresholds, ultimately generating a complete test case in a structured format.

[0125] In this embodiment, when recording player actions to generate test cases, not only are the buttons pressed by the player recorded, but also, once it is detected that the player is manipulating a second virtual object to move, the target position data of the second virtual object on the game map is immediately captured and recorded. Then, based on the operation data and target position data corresponding to each second operation, test cases are constructed. In this way, test cases containing physical state and spatial position can be established at the underlying level, improving the comprehensiveness and accuracy of test case construction, and providing effective data support for the position calibration mechanism during subsequent testing.

[0126] In some embodiments, see Figure 9 Step 203, "constructing test cases based on the operation data and target location data corresponding to each second operation," can be achieved through steps 2031 to 2034, including: In step 2031, the first time information when each second operation is triggered is obtained.

[0127] Here, the first piece of information includes the timestamp when the second operation is triggered, and may also include the operation interval, operation duration, and sequence number. The purpose of this step is to record precise timing information for each user operation, ensuring that test cases not only include the operation content and target location but also possess a complete time dimension. This guarantees that automated playback can strictly reproduce the rhythm, sequence, and timing of user operations, improving the realism and consistency of test playback. For example, when a user sequentially triggers movement, click, and skill operations, the trigger time of each operation and the interval between each operation and the previous one are recorded. This timing information, along with operation data and target location data, is incorporated into the test case to achieve precise playback with a timeline.

[0128] In step 2032, based on the first time information, the operation data and target position data corresponding to each second operation are arranged in time sequence to obtain the operation sequence.

[0129] Here, the initial time information is used to uniquely identify the triggering order and execution sequence of each secondary operation. The operation sequence is a continuous and ordered combination of operation data and target location data, strictly sorted according to chronological order. The purpose of this step is to organize scattered operations and location information into an ordered process that can be executed sequentially based on precise timing, ensuring that test cases can accurately reproduce the user's actual operation sequence and rhythm during playback, avoiding execution anomalies caused by timing discrepancies. For example, by arranging the timestamps of each operation in ascending order, the corresponding operation data and target location data are concatenated in chronological order to form a complete and coherent operation sequence.

[0130] In step 2033, the target state data of the second virtual object after each second operation is executed is obtained.

[0131] Here, the target state data is the set of standard states that the second virtual object should meet after the corresponding operation is completed. This includes key benchmark information for automated verification, such as position coordinates, orientation angle, model pose, scene hierarchy, and interaction markers. The purpose of this step is to establish comparable expected results for each operation, enabling precise verification of whether the virtual object has reached the expected state during subsequent testing, providing a reliable basis for test result determination. For example, after operations such as movement, interaction, and skill release are completed, data such as the character's position, orientation, and action state are collected and recorded as the standard target state for subsequent automated verification.

[0132] In step 2034, test cases are generated based on the operation sequence and target state data.

[0133] Here, the sequential operation process is bound one by one with the corresponding expected target state data, and encapsulated into complete test cases that can be directly loaded, automatically executed, and automatically compared, realizing a complete transformation from real user operations to automated test scripts. For example, multi-step operation instructions arranged in sequence are associated and integrated with target state data such as position, orientation, and behavior corresponding to each step, generating standardized test cases that support fully automatic playback, step-by-step verification, and repeatable execution.

[0134] In this embodiment, first time information of each second operation is obtained, and the corresponding operation data and target position data are sequentially arranged according to this time information to form an operation sequence. Subsequently, the target state data of the second virtual object after each second operation is executed is obtained, and finally, test cases are generated based on the operation sequence and target state data. In this way, the timing logic of the real operation can be accurately reproduced, effectively improving the timing accuracy, data integrity, and execution reliability of the test cases.

[0135] In some embodiments, test cases may also be processed through the following process: The test cases are analyzed to obtain multiple test nodes and the second time information corresponding to each test node; the execution order between each test node is determined based on the second time information; the connection relationship between each test node is established based on the execution order to obtain the test node graph.

[0136] Here, a test node is the smallest operational unit with independent execution and verification logic, derived from a test case. The second time information includes the preset trigger timing, sequence number, and execution interval for each test node. The connection relationship is the logical dependency between nodes, whether sequential or parallel. The test node graph is a structured execution topology result organized by nodes according to time sequence and logic. The purpose of this step is to parse linear test cases into a schedulable, traceable, and visualized topology, facilitating precise time-sequence scheduling and real-time progress tracking. It also supports logical expansion of complex processes and the location of exception breakpoints. For example, test cases can be broken down into multiple independent test nodes, sorted by timestamp and sequence number, and a connection relationship established where the next node proceeds after the previous node completes its execution, ultimately forming a test node graph that can be executed automatically.

[0137] In this embodiment, the linear test script file is broken down, each independent action node and its trigger time are extracted, and then these action nodes are connected one by one with logical lines according to their chronological order to draw a visual flowchart structure, resulting in a test node diagram. This transforms the tedious and complex underlying data into a structured graphical display, facilitating macroscopic visual management and analysis by testers.

[0138] In some embodiments, the test node graph can also be updated through the following process: Output the test node graph; in response to receiving an update instruction for a target test node in the test node graph, determine the update parameters corresponding to the update instruction; based on the update parameters, perform data update processing on the target test node to obtain the updated test node graph.

[0139] Here, the test node diagram is a visual execution topology structure used for display, editing, and scheduling; the target test node is the selected test unit in the node diagram that needs to be modified; the update command is an operation command initiated by the user to edit, modify, adjust, or reconfigure; the update parameters are the specific content used to modify the operation data, timing information, verification rules, or status data corresponding to the node; and the data update processing is the process of replacing, correcting, and rebinding the target node in real time according to the update parameters. The purpose of this step is to support visual editing and dynamic adjustment of the test process, allowing direct modification of node content, timing, or logic without re-recording, thus improving the maintainability and flexibility of test cases. For example, after the visual test node diagram is output in the interface, the user selects a moving node and initiates a modification command. The terminal corrects the node's operation data and target status according to the passed update parameters, generates and saves the updated test node diagram for subsequent automated test execution.

[0140] In this embodiment, a test node graph is first output. Upon receiving an update instruction for a target test node in the graph, the update parameters corresponding to the instruction are determined, and the data of the target test node is updated according to these parameters to obtain the updated test node graph. This provides an intuitive means of editing test cases, effectively improving the editability and flexibility of the test node graph, and ensuring the convenience and accuracy of test case adjustments.

[0141] In some embodiments, the test node graph can also be performed through the following process: In response to receiving a test command, the test node graph is obtained; according to the connection relationship between each test node in the test node graph, each test node is executed sequentially; after the execution of each test node is completed, the test result is obtained.

[0142] Here, test commands are used to trigger the start and execution of the automated testing process; the test node graph is a topological execution structure organized according to temporal and logical relationships, used to determine the execution path and scheduling rules; the connection relationships reflect the predecessors and successors, execution dependencies, and order between test nodes; the test results are the step-level verification conclusions obtained by comparing the actual state with the target state after the execution of a single node. The purpose of this step is to automatically execute all test nodes according to a predetermined logic and order based on the visualized and structured test node graph, achieving fully automated execution and point-by-point verification, ensuring that the testing process is orderly, traceable, and reproducible. For example, after receiving a test start command, the test node graph is loaded, and each step of the operation and verification is executed sequentially according to the relationship between nodes. After each test node is completed, the corresponding step test results are generated in real time.

[0143] In this embodiment, after receiving the test instruction, a test node graph is obtained, and each test node is executed sequentially according to the connection relationship between the nodes. After the execution of each test node is completed, the corresponding test result is generated. In this way, the test can be carried out strictly according to the set structural relationship, which improves the rigor and orderliness of script execution in complex test scenarios, and effectively improves the orderliness, stability and traceability of test execution results.

[0144] In some embodiments, test cases can also be optimized through the following process: Determine the number of times the test case performs position updates during execution, as well as the position deviation data for each update; when the number of updates exceeds a threshold or the position deviation data reaches a preset condition, generate and output an update prompt message for the test case; in response to receiving a confirmation instruction for the update prompt message, replace the target position data in the test case with the first position data corresponding to the first virtual object to obtain a new test case.

[0145] Here, the frequency of automatic position correction during testing is used to statistically analyze the number of times the system triggers corrections. Position deviation data records the difference between the actual and target positions during each correction. The frequency threshold and preset conditions together form the basis for determining whether test cases need optimization. Update prompts alert users to deviations between the current test case and the actual operating scenario, suggesting calibration. The first position data is the stable, effective position after multiple corrections. The new test case is a reusable version after adaptive position data updates. This step aims to statistically analyze correction behavior and deviation levels in real time during automated testing, automatically identify test case mismatches caused by changes in scenario, version, or logic, and support one-click updates of the target position to the stable actual position. This improves the robustness of test cases, reduces maintenance costs, and avoids frequent abnormal corrections due to unreasonable fixed position data. For example, if the position frequently shifts and triggers corrections during multiple executions, and the threshold is exceeded, optimization is prompted. After user confirmation, the stable actual position replaces the original target position, generating a new, more adaptable test case.

[0146] In this embodiment, the number of position updates and the position deviation data for each update are statistically analyzed during the execution of the test cases. When the number of updates exceeds a threshold or the deviation reaches a preset condition, a test case update prompt is automatically generated and output. Upon receiving a confirmation instruction, the original target position data is replaced with the actual position data of the first virtual object, generating a new test case. This automatically optimizes and corrects coordinate errors accumulated over long-term iterations, greatly extending the lifecycle and reusability of automated test cases, and effectively improving the adaptability and long-term execution stability of the test cases.

[0147] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0148] This application provides a complete recording and position verification system for continuous control operations, comprising two core stages: recording and playback. The system not only supports closed-loop position verification of joystick interactive controls but can also be extended to support result verification of other continuous non-discrete operation controls, such as long-pressing a fishing button. The game client process and the automated testing platform process run independently, interacting in real-time at high frequency via a bidirectional network socket communication mechanism.

[0149] In the basic movement test case scenario, during the recording phase, the player controls a virtual character to move forward for a specified time (e.g., two seconds) using a joystick control. During this process, the automated testing platform accurately records the joystick control's trajectory (including starting position, drag direction, and operation time), and extracts the character's position information in the 3D world at key time points (e.g., the starting coordinates at zero seconds and the ending coordinates at two seconds). After the operation is complete, the automated testing platform saves the above interaction data and 3D position data as a test case file in a preset structured text format. In the playback phase, the system reissues the joystick operation commands according to the recording order and timing, and monitors the character's physical position in real time. The system determines whether the character reaches the expected ending coordinates within the specified time. If the character fails to reach the target coordinates due to uncontrollable factors such as in-game movement speed decay (i.e., a positional deviation occurs), the system immediately triggers an intelligent position correction mechanism. During this correction period, the system will forcibly pause the execution time of the test case flow graph (while the time flow in the game world continues uninterrupted and remains normal), and a position correction prompt will pop up on the visualization interface of the automated testing platform. At the same time, the system will control the character to move to the expected end coordinates by calling the pathfinding interface provided by the game project team or the simple pathfinding algorithm built into the testing platform. Only after the character has accurately landed will the system release the pause state and resume the test case timeline to continue playing subsequent instructions.

[0150] See Figure 10 , Figure 10 This is a schematic diagram of the game interface during the recording stage provided in an embodiment of this application. Figure 10 As shown, the interface displays the game screen 10-1 and the joystick control 10-2.

[0151] See Figure 11 , Figure 11 This is a schematic diagram of the interface of the recording stage testing tool provided in an embodiment of this application. Figure 11As shown, the interface displays the automated testing tool, which is recording joystick operations and character position information. The interface includes two main functional areas: the test case editing area 11-1, which arranges condition judgment nodes (used for logical true / false branch judgment), result judgment nodes (marking the success or failure status of test cases), and process execution nodes (displaying single-step time consumption and action logic) in the form of a graphical connection node diagram; below is the timeline area 11-2, which uses multiple independent tracks to intuitively present the trigger distribution and duration of various touch events.

[0152] In some embodiments, the test tool interface also includes a test case management area on the left, which displays and manages all test assets in a directory tree structure; a toolbar area at the top, which provides recording control and node retrieval functions; an attribute panel area on the right, which displays detailed parameters of the currently selected node in real time (such as the exit rule after the action is completed, the type of interactive control being recorded, the current coordinates of the role, etc.); and a runtime log area at the bottom, which is used to print node flow status, socket connection information, and underlying exception debugging information in real time.

[0153] See Figure 12 , Figure 12 This is a schematic diagram of position correction provided in an embodiment of this application. For example... Figure 12 As shown, when the first virtual object 12-1 fails to reach the target position 12-2, the execution time of the test case is paused, and a position correction prompt is displayed on the process interface of the automated testing tool. Then, the first virtual object is moved to the target position 12-2, and the execution time of the test case resumes after reaching the target position 12-2.

[0154] In complex combat test scenarios involving multiple movements and skill releases, the system demonstrated exceptionally robust multi-node independent verification capabilities. For example, a player sequentially performed the actions of "moving to the first target point," "releasing a skill to target number one," "moving to the second target point," and "releasing a skill to target number two." During the recording phase, the system recorded the corresponding character coordinates at the moment each independent joystick operation ended, providing a precise spatial reference for subsequent combos. During the playback phase, the system performed independent verification and correction for each movement action. When the first movement was replayed, if a spatial deviation existed, the system immediately froze the test flow graph time and implemented spatial correction. After the character accurately reset, the timeline was restored, ensuring that the first skill release accurately hit the target. The subsequent second movement and skill release triggered the same closed-loop logic. This mechanism ensured that each position correction was independent, and thanks to the time freeze and synchronous recovery capabilities, it guaranteed that the timing of the entire complex test case remained absolutely correct.

[0155] See Figure 13 , Figure 13This is a schematic diagram of multiple test nodes provided in an embodiment of this application. For example... Figure 13 As shown, this includes test node 13-1, test node 13-2, and test node 13-3. Before testing begins, test cases are validated. If validation is successful, each test node is executed sequentially; if validation fails, the test is deemed a failure. After each test node completes, its status is checked. If it is incorrect, the test is deemed a failure; if it is successful, the next step is executed until all test node steps are completed, at which point the test is deemed a success.

[0156] See Figure 14 , Figure 14 This is a schematic diagram of the position verification and correction mechanism provided in an embodiment of this application. Figure 14 As shown, it includes the following steps: In step 1401, the first operation is performed.

[0157] Here, the automated testing platform in the terminal begins to replay the specific actions in the test cases, such as a click or swipe on the screen.

[0158] In step 1402, it is determined whether the operation control of the first operation is a joystick control.

[0159] Here, we check if the action just performed was "sliding the virtual joystick" to control the character's movement. Joystick-controlled movement is prone to positional errors during playback, while ordinary button clicks typically don't require complex coordinate corrections. If the result is yes, proceed to step 1403; if the result is no, proceed to step 1404.

[0160] In step 1403, it is determined whether the location verification function is enabled.

[0161] Here, confirm whether the position verification function is enabled in the current test configuration. Sometimes testing may only care whether the character moves, not whether the movement is accurate; only when this function is enabled is subsequent precise correction necessary. If the result is yes, proceed to step 1405; if the result is no, proceed to step 1404.

[0162] In step 1404, subsequent operations are performed.

[0163] This indicates that the previous action did not require position correction (possibly because it was not a joystick operation, or the verification function was not enabled, or the position was not off to begin with). In that case, proceed with the normal procedure and continue playing back the next test action in the recording.

[0164] In step 1405, the target position of the recording stage is read.

[0165] Here, the system will review the previously recorded test cases to find out the exact coordinates on the map where the game character finally stopped after performing the joystick action during the recording phase.

[0166] In step 1406, the positional deviation between the current position of the first virtual object and the target position is determined.

[0167] Here, we calculate the actual position of the game character (the first virtual object) during the current playback, and how much the distance differs from the standard position read in the previous step. Simply put, we calculate how far the character has strayed from its intended location.

[0168] In step 1407, it is determined whether the position deviation is greater than the deviation threshold.

[0169] Here, we check whether the "distance of deviation" exceeds the allowable tolerance range (threshold). If the result is yes, proceed to step 1408; if the result is no, proceed to step 1404.

[0170] In step 1408, the execution time of the test cases is paused.

[0171] Here, because the character has gone astray, extra time is needed to correct it. To prevent this extra correction time from disrupting the original timing of the recording (such as causing subsequent skills to miss), the system will pause the test clock, temporarily freezing time.

[0172] In step 1409, the first virtual object is controlled to move to the target position.

[0173] Here, the testing platform takes over control of the game, manipulating the first virtual object in the game to move towards the correct target coordinates (or move it directly there) to correct errors.

[0174] In step 14010, it is determined whether the first virtual object has moved to the target location.

[0175] Here, the coordinates of the first virtual object are detected in real time to determine whether the first virtual object has moved to the target position. If the determination result is negative, step 1409 is executed; if the determination result is positive, step 14011 is executed.

[0176] In step 14011, the execution time of the test case is restored, and subsequent operations continue.

[0177] Here, once the position of the first virtual object has been successfully aligned to the standard position, the system will release the execution time pause state in step 1408, allowing the test clock to continue running and smoothly continue executing the next operation in the test case.

[0178] See Figure 15 , Figure 15 This is a schematic diagram of the technical architecture provided in the embodiments of this application. The technical architecture of the embodiments of this application adopts a strict decoupled layered design, which is divided into an external project implementation layer 15-1, a test platform intermediate layer 15-2, and a recording and playback core system layer 15-3.

[0179] The project implementation layer 15-1 is used to obtain the character's position and control its movement. The external project implementation layer 15-1 requires the game development team to connect to and implement the standard character position provider interface. This interface mandates that the external project provide a joystick control determination method (to inform the system whether the currently triggered interactive control belongs to the joystick attribute), and provide a target coordinate pathfinding movement method or a direction vector movement method, in order to grant the system the underlying permissions to control the physical character.

[0180] The middleware layer 15-2 of the test platform acts as a connecting hub, defining the specific specifications of the aforementioned interfaces and incorporating a singleton-based character position manager. This manager is specifically responsible for registering and calling interface instances, as well as verifying their completeness and validity. To ensure backward compatibility, this layer also includes a simple pathfinding algorithm as a backup solution; when external projects do not provide advanced pathfinding support, the system will call this built-in algorithm to calculate direction vectors frame-by-frame to drive character movement; if external projects have not even implemented basic character control interfaces, the manager will silently disable the position correction function, but this will not affect the normal operation of basic recording and playback functions.

[0181] The recording and playback core system layer 15-3 is used to call interfaces to obtain character positions during recording, verify positions and automatically correct them during playback, and expand the message structure to add character position information fields. It includes a graph-structured recording manager responsible for collecting interaction trajectories and entity coordinates, a touch graph action execution unit responsible for replay operations and triggering automatic compensation logic, and a touch recording synchronization message body specifically designed to carry spatial information by expanding the character coordinate attribute field. This decoupled architecture ensures that the testing platform can not only interface with game projects of different architectures, but also accurately filters out non-joystick control position detection actions through a pre-defined joystick control determination method, greatly avoiding wasted computing power. The system also provides general extension capabilities through a highly abstract interface configuration mechanism, applicable not only to joystick controls, but also to other continuous non-discrete operation controls such as long-pressing the fishing button, and specifically verifying their unique results (such as successful fishing status, fishing rod attribute determination, etc.).

[0182] See Figure 16 , Figure 16 This is a technical architecture flow diagram provided in the embodiments of this application. For example... Figure 16As shown, a clear layered and decoupled design is presented, from the underlying operation recording and playback to the upper-level specific game business access. The recording and playback system 16-1 includes basic components responsible for touch action playback, recording management, and touch synchronization message extension. These components are responsible for reading and writing operation data and calling the position correction module, position verification module, position recording module, and time management module in the core functional module 16-2 downstream. To ensure the universality of the test platform, a test middleware layer 16-3 is extended, with the CharacterPositionManager as the core hub. It not only has a built-in SimplePathfinding mechanism as a backup solution, but more importantly, it abstracts a standard protocol interface (ICharacterPositionProvider) for obtaining character positions. Ultimately, this design allows the project team's implementation layer 16-4 to seamlessly connect to the entire position verification system by implementing this standardized interface according to their specific game underlying code. This perfectly realizes a technical underlying framework that has both position verification and correction closed-loop capabilities, can be flexibly reused in different game projects, and highly decouples the automated test platform from the specific game logic.

[0183] See Figure 17 , Figure 17 This is a schematic diagram of the recording stage process provided in an embodiment of this application. Figure 17 As shown, it includes the following steps: In step 1701, the second operation is detected.

[0184] Here, automated testing tools deployed in the terminal are used to detect the actions performed by testers or players on the screen (such as pressing a button or swiping the screen). This is the first step in recording the game's automated script.

[0185] In step 1702, it is determined whether the operation control for the second operation is a joystick control.

[0186] Here, we identify the UI element that was just interacted with. If it's a virtual joystick controlling character movement, more data needs to be recorded because it involves spatial displacement within the game world; if it's a regular button (such as a skill or inventory button), the processing is relatively simple. Specifically, if the result is yes, proceed to step 1703; if the result is no, proceed to step 1708.

[0187] In step 1703, the starting position and rotational orientation of the second virtual object are obtained.

[0188] Here, before the second virtual object moves, we first record the current position coordinates of the game character (second virtual object) in the game, as well as the direction the character is facing (rotation posture).

[0189] In step 1704, the touch trajectory of the second operation is recorded.

[0190] This section records information such as the specific path, force, and duration of the finger swipe in the "joystick area." This raw finger swipe data is used to allow the computer to simulate the exact same operation during later playback.

[0191] In step 1705, the end position and rotation orientation of the second virtual object are obtained.

[0192] Here, when the joystick is released and the movement ends, the system will again obtain the precise coordinates and orientation of the second virtual object on the map.

[0193] In step 1706, structured data is created.

[0194] Here, we package and organize the series of scattered operation information (such as action type, control identifier, etc.) that we just collected into a standard format that the program can understand.

[0195] In step 1707, the character position information is populated into the structured data.

[0196] Here, the starting coordinates, ending coordinates, and rotation posture of the character obtained in steps 1703 and 1705, which are specifically for joystick operations, are written into the data package that was just created, making the data corresponding to this movement operation more complete.

[0197] In step 1708, the touch trajectory of the second operation is recorded and structured data is created.

[0198] Here, if you simply tap a regular button or swipe the screen, there's no need to record complex map coordinates. The system only records the touch trajectory of the operation and directly packages this basic action information into structured data.

[0199] In step 1709, the structured data is sent to the automated testing tool.

[0200] Here, the terminal sends the packaged structured data to the automated testing platform for further processing.

[0201] In step 17010, the structured data is saved as test cases.

[0202] Here, after receiving this data, the automated testing platform writes it sequentially into a file (such as a JSON file) for long-term storage. This file becomes a complete automated test script, resulting in the final test cases.

[0203] The entire lifecycle operation of this application embodiment is divided into a recording stage (operation recording, location recording, data storage) and a playback stage (operation playback, location verification, location correction).

[0204] During the frame-by-frame update method in the recording phase, the system continuously detects and categorizes terminal input. When a button press is detected, the system locates the corresponding interface's hierarchical path based on the screen touch point and immediately calls the joystick control determination method in the character position manager. If confirmed as a joystick control, the system immediately extracts the current starting coordinates and starting rotation orientation of the physical character and temporarily caches them in the touch event data body. This operation is then converted into input commands for the game engine to drive the character. In the button movement processing phase, the system only continuously records the two-dimensional screen trajectory of the finger dragging and never repeatedly extracts the character's three-dimensional physical coordinates. When the button release processing method is triggered, indicating the end of the operation, the system verifies the joystick identity again and then accurately extracts the character's ending coordinates and ending rotation orientation. Next, the system instantiates a touch recording synchronization message body, fills the start and end coordinate data into the extended character coordinate attribute field and marks it as valid, and finally pushes the message via a socket to the independent process where the remote test platform resides through the flow graph debug manager's sending method. After receiving it, the test platform converts it into a touch graph action execution unit and attaches it to the current flow graph node. Finally, all action logic, timestamps, and coordinate data are packaged into a preset structured text format (i.e., a test flow graph file) and persisted to disk. The processed message objects are then released back into the memory object pool for reuse.

[0205] During the playback phase, the test system progressively advances based on a three-level nested architecture: "parallel flow layer manages parallel flow graph node layer, and node layer manages touch graph action execution unit layer." For each action execution unit, its internal periodic detection execution method is responsible for dispatching pre-recorded screen touch coordinates frame by frame to simulate dragging. When all touch points within the action's lifecycle have been dispatched and the code logic enters the end state setting method, it intercepts the normal exit process and triggers position verification first.

[0206] The position verification logic is precisely designed to execute the instant the action exits, rather than performing frame-by-frame checks. The system first calls the trigger position verification method to sequentially verify whether the position extension function is enabled, whether the target control is a joystick, and whether the coordinate validity flag is true. After successful verification, the system calls the core verification and correction position methods to obtain the character's true coordinates in the current game world and calculate the physical straight-line deviation between these coordinates and the recorded target coordinates. Here, the system introduces a dynamic position tolerance threshold configuration mechanism: for combat tests with extremely high precision requirements, the tolerance threshold can be tightened to within 0.5 meters; for more relaxed scene exploration tests, the tolerance threshold can be relaxed to 2 meters. If the calculated deviation distance is less than or equal to the tolerance threshold, the position is correct, and the system will normally call the base class's end-state setting method, causing the action units to sequentially enter the almost-stopped state until the completed state; if the deviation exceeds the tolerance threshold, the system will set a position correction flag, forcibly preventing the call to the base class's end-state setting method, causing the current action unit to deadlock in the running state, and immediately call the timeline pause setting method to completely freeze the time progression of the test flow graph, before officially starting the position correction procedure.

[0207] In the position correction logic, the system prioritizes calling the efficient target coordinate pathfinding and movement method provided by the external project to implement cross-terrain obstacle avoidance compensation; if the call fails, it downgrades to using the platform's built-in simplified pathfinding algorithm. During the lengthy correction run cycle, since the action unit is still stuck in the running state, its frame-by-frame triggered periodic detection execution method no longer advances any test time, but instead specifically calls the position correction state detection method. If this method detects that simplified pathfinding is being used, it calls the movement state update method every frame to calculate and normalize the direction vector, continuously approaching the target. Once the state detection method confirms that the distance between the character and the target has been reduced to within the tolerance range, the system immediately issues a stop movement command, calls the timeline recovery method to unfreeze the flow graph, and calls back the end state setting method again, finally allowing the action unit to enter the about-to-stop state and trigger the node exit callback method, so that the entire test business flow can seamlessly connect to the next node. To ensure robustness in extremely harsh environments, if this correction run takes more than ten seconds, the system will output a warning operation log and try other compensation logic; if the target is completely unreachable, the system will determine that the correction has failed and suspend the test case for manual intervention.

[0208] To ensure the ultimate performance of this massive system in complex game environments, this application's embodiments implement several deep optimizations at the underlying level. Regarding the spatial data recording strategy, high-frequency full-process coordinate sampling is abandoned, replaced by a simplified strategy of low-frequency sampling only at the beginning and end of touch events. Simultaneously, verification calculations are also specifically and deliberately performed at the end of the action's lifecycle, and the entire process is subject to strict joystick type pre-filtering, completely avoiding unnecessary computational consumption caused by frame-by-frame table scanning and non-displacement controls.

[0209] At the underlying data structure level, the system forcibly abandons the traditional floating-point two-dimensional vector data structure, and fully adopts fixed-point two-dimensional vectors for spatial calculations. This not only significantly reduces the resident occupation of physical memory, but also eliminates the root cause of verification misjudgments caused by the inconsistent precision of floating-point operations across different devices. All collected screen coordinates have undergone adaptive resolution normalization. In addition, the system has fully introduced an object pool lifecycle management mechanism for massive amounts of high-frequency socket communication message bodies, which greatly alleviates the frame rate fluctuations and stuttering phenomena in the game process caused by memory garbage collection.

[0210] The core function of the recording and playback system in this application is to continuously detect user input through an update method during each frame refresh of the game, and to handle various touch operations using three methods: touch press, touch move, and touch release. The system focuses on accurately recording, verifying, and correcting the character's position for joystick UI operations, ensuring that the character's position remains consistent with the recording position during playback, thus guaranteeing the accuracy and reliability of test cases. The entire system's operation flow closely revolves around the two core stages of recording and playback, with each stage interconnected and working collaboratively, balancing data simplicity with efficient system operation.

[0211] During the recording phase, the system's touch operation processing and position recording logic are tightly integrated. When a touch is detected, the system first locates the UI element corresponding to the touch location and obtains its UI path. Then, it uses the joystick UI judgment method of the character position management instance to confirm whether the UI is a joystick UI. If it is determined to be a joystick UI, the system obtains the character's starting position and rotation information through the character position management instance and temporarily stores this key data in the character's starting position and starting rotation fields of the touch event data, laying the foundation for subsequent position verification. During the touch movement, the system continuously records the touch trajectory but does not record the character's position information. This is because position information is only recorded at the two key nodes of the touch start and end. This design preserves the complete trajectory of the operation while avoiding unnecessary data redundancy. When the touch operation ends, the system again determines whether the UI is a joystick UI. If confirmed, it obtains the character's ending position and rotation information, creates a recorded touch synchronization message, and fills the character's complete position information (including the starting and ending positions and rotation) into the character position field of the message, completing the position recording for a single joystick operation.

[0212] The moment the touch is released, the system triggers the touch release method, officially initiating the data storage process. First, a recorded touch synchronization message is created. If the operation corresponds to a joystick UI and system extension functions are enabled, the previously stored character start position and rotation are extracted from the touch event data, supplemented with the currently acquired end position and rotation, and the validity flag is set to true, completing message filling. Then, the message is sent to the remote debugging system, i.e., the automated testing tool process, via the sending method of the node graph debugging management instance. In the automated testing tool process, the message is converted into a test node graph touch operation and stored in the corresponding node. Each operation corresponds to a complete UI interaction process, including key data such as operation type, timestamp, and location information. A node can contain multiple operations, thus forming a complete logical flow for the test case. Finally, the system releases the sent messages to the object pool, reducing memory overhead and improving system performance through object reuse.

[0213] The entire test case is stored in JavaScript Object Notation (JSON) format, essentially a test flow graph. Its core structure includes four parts: node information, operation information, position information, and connection relationships. Node information corresponds to each operation step, including node type, execution conditions, etc.; operation information is stored within the node, corresponding to the complete UI operation process, carrying details such as operation type, timestamp, and position information; position information only applies to joystick UI operation records, including the character's position and orientation at the start and end of the touch; and connection relationships define the execution order between nodes, connecting the logical flow of the entire test case. Automated testing tools can visualize this JSON-formatted test flow graph as a node diagram, making it easy for testers to view and edit, thus facilitating the testing process.

[0214] The recording phase design fully embodies the principles of simplicity and efficiency. Character positions are recorded only at the start and end of joystick UI touches, and this position information is uniformly stored in a message-level character position field. This avoids repeatedly recording position data for each frame or movement point, effectively reducing data redundancy. Furthermore, the position recording logic is triggered only for the joystick UI; non-joystick UIs do not execute this operation, significantly improving system efficiency and data accuracy. In addition, the system provides an interface abstraction for interaction logic with external project character systems through character positions. External projects only need to implement this interface to complete integration. If this interface is not implemented, the system will only disable the position correction function without affecting basic recording and playback functions, achieving decoupling between the system and external projects and improving system compatibility and scalability.

[0215] During the replay phase, the system executes test cases based on the flow graph architecture. The entire architecture is divided into three levels: parallel node graph (overall flow graph), parallel node graph nodes, and test node graph touch operation. The execution process is progressive and orderly. First, in the overall flow layer, the system reads the JSON file of the test cases, parses it into a parallel node graph structure, and then iterates through all running nodes in the update method of the overall flow graph in each frame. Next, in the node layer, each node iterates through all running operations in its own update method in each frame, and is responsible for managing the lifecycle of the operations. Finally, in the operation layer, each touch operation in the test node graph corresponds to a complete joystick UI interaction process, and its running logic is different depending on whether it is in the position correction state: if position correction is in progress, the operation will only check the position correction state and will not advance the test case time, but the game time will run normally; if correction is not in progress, the execution of the touch movement points will be gradually advanced. When all movement points have been executed, the set completion method will be called to trigger position verification; if position correction is required after verification, the system will pause the test case time, keeping the operation in the running state until the correction is completed, and then the operation will enter the stopped state; after the update method of the next frame node detects the stopped state of the operation, it will call the exit method, so that the operation officially enters the completed state and completes the replay of one operation.

[0216] Position verification is a crucial step in the replay phase, triggered precisely at the end of the operation's lifecycle, specifically when the "Setup Complete" method is called. The entire verification process is rigorous and orderly. Within the "Setup Complete" method, the system first checks if position correction is in progress. If correction is in progress, the basic "Setup Complete" method is not called, maintaining the operation's running state while pausing the test cases. Next, it checks if all touch movement points have completed. If not, the basic "Setup Complete" method is called directly, putting the operation into a stopped state to ensure the test cases proceed normally. If all movement points have completed, the position verification process is triggered. After the position verification method is called, it sequentially checks if extended functions are enabled, if the current operation's UI is a joystick UI, and if the position information is valid. Only when all three conditions are met will the "Verify and Correct Position" method be called to execute the specific verification logic. In the position verification and correction method, the enabled status of extended functions is double-checked. Then, the current character's position information is obtained; if it cannot be obtained, no further correction operation is performed. Next, the deviation distance between the current character's position and the target position is calculated. If the deviation distance is less than or equal to the preset position tolerance, the position is considered correct, no correction is needed, and the basic setup completion method is called to put the operation into a stopped state. If the deviation distance exceeds the tolerance, the test case time is paused (game time continues to run normally), a correction flag is set, and the "Move Character to Target Position" method is called to begin position correction, while maintaining the operation's running state to ensure the correction process is not interrupted. During position correction, the "Check Position Correction" method is called every frame in every frame update method to continuously check whether the character has reached the target position. If a simplified pathfinding algorithm is used, the character's movement state is also updated every frame. When the character reaches the target position, movement stops, test case time resumes, and the setup completion method is called again to allow the operation to enter a stopped state, completing the entire position verification process.

[0217] The position verification design follows the principles of precision and efficiency, with key strategies revolving around verification timing, UI filtering, tolerance configuration, and state control. Verification timing is chosen after all movement points are completed, avoiding position checks every frame and effectively reducing system computational overhead. By using the joystick UI judgment method within the character position management instance, position verification is triggered only for joystick UI operations; non-joystick UI operations do not execute this logic, further improving system efficiency. Position tolerance can be flexibly configured according to game type and testing needs. For high-precision requirements such as combat testing (e.g., extreme dodging, precise positioning), the tolerance should be set within 0.5 meters. When using a joystick to control the character for long-distance map running, large-scale open-world exploration, or triggering large-area triggers (e.g., entering...), the tolerance is adjusted accordingly. In specific town scenarios (approaching and waking up non-player characters), since the main purpose of this type of continuous joystick directional movement is to guide the character to the approximate target area, and displacement deviations can easily occur during long-distance movement due to client frame rate fluctuations, animation transitions, or minor physical collisions in the terrain, pixel-level absolute precision positioning is not required. Therefore, for low-precision needs such as exploration testing, the tolerance can be relaxed to 2 meters, balancing the accuracy and flexibility of the test. During position correction, the operation status is controlled by whether the position correction is in progress, ensuring that the correction process is not interrupted and guaranteeing the effectiveness of the correction.

[0218] When the position verification detects a position deviation exceeding the tolerance, the system initiates a position correction process. The core of this process is pausing the test case execution time, using a pathfinding algorithm to move the character to the target position, and resuming test case execution after correction. Regarding the pathfinding method, the system prioritizes using the interface provided by external projects to move the character to the target position, as these interfaces are typically better suited to the game's complex terrain and obstacles, offering higher reliability and efficiency. If the external project does not implement this interface or the interface returns a failure, the ATP simplified pathfinding algorithm is used as an alternative. The ATP simplified pathfinding algorithm calculates the direction vector from the current position to the target position, normalizes it, and controls the character's movement towards the target position. It checks every frame whether the character has reached the target position and stops moving immediately upon arrival. In terms of the correction checking mechanism, during correction, the update method in each frame only executes the position correction check method, without advancing the test case execution time, ensuring the focus of the correction logic. Simultaneously, it continuously checks every frame whether the character has reached the target position, and in simplified pathfinding scenarios, it also updates the movement status, ensuring efficient progress of the correction process. In terms of time management, only the test case time is paused during the calibration process, while the game time continues to run normally. This avoids causing other logical anomalies in the game due to calibration. Once calibration is complete, the test case time is immediately restored to ensure that subsequent operations are executed at the correct time. Furthermore, the system has an exception handling mechanism designed for the calibration process. If the calibration time exceeds 10 seconds, it is considered a timeout, and the system will record a warning message and attempt other calibration methods. If calibration fails, such as when the target location is unreachable, the system will record an error message and pause the test case, awaiting manual intervention, thus ensuring system stability.

[0219] The time management mechanism is a core technical detail in the position correction process, directly affecting the accuracy of test case execution. When the system detects that the position deviation exceeds the tolerance and requires correction, it pauses the test case time using the pause method set in the parallel node graph, while the game time continues to run normally, ensuring that other logic within the game is not affected. After pausing, the per-frame update method no longer advances the test case time, but the position correction-related logic will execute normally, and the operation will remain in the running state, avoiding entering a stopped state and preventing the correction process from being interrupted. When the character reaches the target position and the position correction is completed, the system resumes the test case time using the pause method set in the parallel node graph, ensuring that subsequent operations can be executed according to the preset timeline, guaranteeing the integrity and accuracy of the test cases.

[0220] To further improve system performance, the solution incorporates optimization strategies across multiple dimensions. Regarding position recording, character positions are only recorded at the start and end of joystick UI touches, and this position information is uniformly stored in the character position field at the message level. This avoids repeated recording for each frame or movement point, significantly reducing data volume. Furthermore, position recording is not triggered outside of the joystick UI, reducing unnecessary computation. For position verification, verification is triggered only after all movement points are completed, rather than every frame, and is only performed on joystick UI operations, further reducing computational resource overhead. In terms of position correction, the update method for each frame only executes position correction check logic during correction, without performing other unnecessary computations. Simultaneously, message objects are managed through an object pool, reducing memory reclamation pressure and improving system smoothness. Regarding data structures, fixed-point numbers are used instead of two-dimensional vectors, effectively reducing memory usage. Coordinates are also normalized to adapt to devices with different resolutions, improving system compatibility.

[0221] Overall, the position verification and correction scheme of this game operation recording and playback system focuses on the position management of joystick UI operations. Through precise recording and efficient storage during the recording phase, and orderly execution, rigorous verification, and flexible correction during the playback phase, it ensures the accuracy of test case playback. The scheme design balances data simplicity and system efficiency, while decoupling enhances compatibility and scalability. Furthermore, multi-dimensional performance optimization ensures stable system operation in various game scenarios, providing reliable technical support for game testing.

[0222] In summary, implementing the testing method provided by this technical solution will bring about a leapfrog technological advancement in the field of automated software testing, producing at least the following significant beneficial effects: Completely eradicates the persistent problem of result deviation in continuous non-discrete operations: Relying on a pioneering dual recording and closed-loop correction mechanism based on actual physical coordinates, regardless of whether the playback environment experiences drastic changes in movement speed due to equipment changes, severe frame drops caused by differences in device performance, or even the randomness of the game engine's underlying components (such as drift triggered by changes in fishing rod attributes), the system can forcibly correct the entity coordinates and states to the recording baseline through an intelligent compensation mechanism. This increases the execution accuracy of test cases from the traditional 60-70% to over 95%.

[0223] Test asset reuse has increased exponentially: successfully breaking the destructive impact of game iteration updates on historical test cases. Even when new versions significantly change the underlying character movement logic, existing test cases can still run perfectly thanks to their extremely robust adaptive correction capabilities. This has caused the cross-version reuse rate of test cases to soar from an extremely low 30% to 40% to over 85%, directly eliminating more than 60% of the repetitive recording workload.

[0224] This results in a dramatic reduction in testing costs and a leap in efficiency: Due to the increased reuse rate, the frequency of manual re-recording has plummeted. For example, in a typical medium-sized R&D project, each version update previously required eight to thirty-three hours of manual re-recording of fifty to one hundred failure test cases; after deploying this implementation, the number of test cases to maintain has been reduced to ten to twenty, and the time required has drastically decreased to two to seven hours, resulting in a direct reduction of up to 75% in testing manpower costs. The fully automated, silent error correction also allows test engineers to focus their valuable energy on deeper defect analysis.

[0225] Ensuring absolutely precise timeline synchronization and high reliability: The unique timeline separation and freezing mechanism ensures that the time pointer of the test logic remains absolutely still during the lengthy spatial compensation pathfinding process; the timeline only resumes flow after spatial fitting is complete. This highly consistent timing management eliminates the disaster of action misalignment triggers, ensuring that the absolute reliability of the final test results consistently exceeds the 95% industrial red line.

[0226] Provides a transparent and clear underlying anomaly attribution and debugging chain: When an occasional, extremely complex environmental anomaly causes a test case to fail completely, the system will output in real time deep status data such as position deviation difference, timeout circuit breaker warning, and correction compensation movement trajectory through the log matrix. Testers have completely bid farewell to the era of "black box investigation" relying on blind guessing from video recordings, and can directly and quickly identify engine defects based on underlying coordinate differences.

[0227] Possessing boundless versatility and industry adaptability potential: The decoupled architecture and underlying principles of this solution not only support mainstream virtual joystick controls, but its abstract interface specifications also allow the system to be easily applied to testing any continuous, non-discrete control, such as long-press charging, continuous spell casting, and fishing progress control. The system also reserves broad pathways for advancement to advanced areas such as multi-character group position verification, adaptive dynamic tolerance intelligent adjustment, and predictive spatial correction, demonstrating extremely high value for industry promotion.

[0228] The following description continues to illustrate the exemplary structure of the testing device 455 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the test device 455 in the memory 450 may include: The acquisition module 4551 is used to acquire pre-recorded test cases in response to receiving a test instruction, wherein the test cases include at least one operation data for a first virtual object; Control module 4552 is used to control the first virtual object to perform the first operation corresponding to each operation data based on the operation data; The acquisition module 4551 is further configured to, when the first operation is a movement operation, acquire target location data corresponding to the operation data from the test case, perform location verification on the first virtual object based on the target location data, and obtain a verification result; The execution module 4553 is used to pause the execution of the test case and update the position of the first virtual object based on the target location data when the verification result indicates that the verification has failed. The execution module 4553 is also used to resume the execution of the test cases after the location is updated, until the test results are obtained.

[0229] In some embodiments, the control module 4552 is further configured to parse the operation data to obtain the operation control and operation parameters corresponding to the first operation; generate a control instruction based on the operation control and the operation parameters; and send the control instruction to the first virtual object to control the first virtual object to perform the first operation.

[0230] In some embodiments, the control module 4552 is further configured to determine the operation control corresponding to the first operation; when the operation control corresponding to the first operation is a target control for controlling the movement of the first virtual object, the first operation is determined to be the movement operation; or, the operation intent corresponding to the first operation is determined; when the operation intent indicates that the first operation is used to control the movement of the first virtual object, the first operation is determined to be the movement operation.

[0231] In some embodiments, the execution module 4553 is further configured to determine the first position data after the first virtual object performs the first operation corresponding to the operation data; determine the position offset based on the first position data and the target position data; and determine the verification result as verification failed when the position offset is greater than a preset threshold.

[0232] In some embodiments, the execution module 4553 is further configured to determine the position corresponding to the first position data of the first virtual object as the starting position; determine the position corresponding to the target position data as the ending position; construct a movement path from the starting position to the ending position based on the starting position and the ending position; and control the first virtual object to update its position based on the movement path.

[0233] In some embodiments, the execution module 4553 is further configured to update the execution status of the test case from the running state to the paused state; correspondingly, the execution module 4553 is further configured to, in response to updating the execution status of the test case to the paused state, stop sending the control instruction corresponding to the next operation data in the test case to the first virtual object, and determine the current execution progress of the test case.

[0234] In some embodiments, the execution module 4553 is further configured to obtain the current execution progress of the test case, and obtain the remaining pending operation data from the test case based on the current execution progress; update the execution status to the running status, and control the first virtual object to execute each pending operation data in sequence; and generate the test result after each pending operation data has been executed.

[0235] In some embodiments, the execution module 4553 is further configured to obtain test status data of the first virtual object after executing each of the data to be executed, and obtain target status data of the first virtual object from the test cases; when the test status data matches the target status data, obtain the running status data of the test cases during execution; when the running status data does not contain abnormal data, generate a test result indicating that the test has passed.

[0236] In some embodiments, the execution module 4553 is further configured to: determine deviation information between the test state data and the target state data when the test state data does not match the target state data; or, generate abnormal information based on the abnormal data when the running state data contains abnormal data; and generate a test result to characterize the test failure, wherein the test result to characterize the test failure includes at least one of the deviation information and the abnormal information.

[0237] In some embodiments, the execution module 4553 is further configured to, upon reaching the timing for generating the test case, respond to receiving at least one second operation, generate operation data corresponding to each second operation; when the second operation is a movement operation on a second virtual object, determine the target location data of the second virtual object and the second operation; and construct the test case based on the operation data and the target location data corresponding to each second operation.

[0238] In some embodiments, the execution module 4553 is further configured to obtain the operation control and operation parameters corresponding to the second operation; and encapsulate the operation control and operation parameters into the operation data according to a preset format.

[0239] In some embodiments, the execution module 4553 is further configured to acquire first time information when each of the second operations is triggered; arrange the operation data and target position data corresponding to each of the second operations in a time sequence according to the first time information to obtain an operation sequence; acquire target state data of the second virtual object after each of the second operations is executed; and generate the test case based on the operation sequence and the target state data.

[0240] In some embodiments, the execution module 4553 is further configured to parse the test cases to obtain multiple test nodes and second time information corresponding to each test node; determine the execution order between each test node based on each of the second time information; and establish the connection relationship between each test node based on the execution order to obtain a test node graph.

[0241] In some embodiments, the execution module 4553 is further configured to output the test node graph; in response to receiving an update instruction for a target test node in the test node graph, determine update parameters corresponding to the update instruction; and perform data update processing on the target test node based on the update parameters to obtain an updated test node graph.

[0242] In some embodiments, the execution module 4553 is further configured to, in response to receiving the test instruction, obtain the test node diagram; execute each test node sequentially according to the connection relationship between each test node in the test node diagram; and obtain the test result after the execution of each test node is completed.

[0243] In some embodiments, the execution module 4553 is further configured to determine the number of times the position update is executed during the execution of the test case, and the position deviation data at each position update; when the number of times exceeds the number threshold, or the position deviation data reaches a preset condition, generate update prompt information for the test case, and output the update prompt information; in response to receiving a confirmation instruction for the update prompt information, replace the target position data in the test case with the first position data corresponding to the first virtual object to obtain a new test case.

[0244] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the test method described above in this application.

[0245] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the test method provided in this application. For example, ... Figure 3 The test method is shown.

[0246] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0247] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0248] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored in a portion of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0249] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0250] In summary, through the embodiments of this application, firstly, by responding to test instructions and acquiring pre-recorded operation data, and automatically controlling the first virtual object to execute the corresponding operation, automated testing of the first virtual object is achieved, effectively reducing the cost of manual testing and improving the reusability and basic execution efficiency of the test. Secondly, for movement operations that are prone to errors in the virtual environment, the embodiments of this application introduce a precise verification mechanism based on target position data, which can capture the positional offset of the virtual object during movement in real time and accurately. When the position verification fails, the execution of the test case is paused, and the position of the first virtual object is updated, effectively avoiding the chain reaction that all subsequent interactive operations will fail due to misalignment caused by the previous movement not being in place. Finally, after the position calibration is completed, the execution of subsequent test cases is seamlessly resumed until the final test result is output, enhancing the robustness and fault tolerance of the automated testing framework, ensuring the continuous execution capability of long-chain and complex test cases, and significantly reducing the probability that the entire test case needs to be rerun due to occasional movement errors, thereby effectively improving the continuity and success rate of testing.

[0251] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A testing method, characterized in that, The method includes: In response to receiving a test instruction, a pre-recorded test case is obtained, wherein the test case includes at least one operation data for a first virtual object; For each of the operation data, based on the operation data, control the first virtual object to perform the first operation corresponding to the operation data; When the first operation is a movement operation, the target location data corresponding to the operation data is obtained from the test case, and the location of the first virtual object is verified based on the target location data to obtain the verification result; When the verification result indicates that the verification has failed, the execution of the test case is paused, and the position of the first virtual object is updated based on the target location data; Resume execution of the test cases after the location is updated until the test results are obtained.

2. The method according to claim 1, characterized in that, The step of controlling the first virtual object to execute the first operation corresponding to the operation data based on the operation data includes: Parse the operation data to obtain the operation controls and operation parameters corresponding to the first operation; Based on the operation controls and the operation parameters, control instructions are generated; The control command is sent to the first virtual object to control the first virtual object to perform the first operation.

3. The method according to claim 1, characterized in that, After controlling the first virtual object to execute the first operation corresponding to the operation data, the method further includes: Determine the operation control corresponding to the first operation; When the operation control corresponding to the first operation is a target control used to control the movement of the first virtual object, the first operation is determined to be the movement operation. Alternatively, determine the operational intent corresponding to the first operation; When the operation intent indicates that the first operation is used to control the first virtual object to move, the first operation is determined to be the movement operation.

4. The method according to claim 1, characterized in that, The step of verifying the location of the first virtual object based on the target location data to obtain the verification result includes: Determine the first position data after the first virtual object performs the first operation corresponding to the operation data; The position offset is determined based on the first position data and the target position data; When the position offset is greater than a preset threshold, the verification result is determined to be a verification failure.

5. The method according to claim 1, characterized in that, The step of updating the location of the first virtual object based on the target location data includes: The position corresponding to the first position data of the first virtual object is determined as the starting position; The location corresponding to the target location data is determined as the destination location; Based on the starting position and the ending position, construct a movement path from the starting position to the ending position; Control the first virtual object to update its location based on the movement path.

6. The method according to claim 1, characterized in that, The pause execution of the test case includes: Update the execution status of the test case from running to paused; Correspondingly, the method further includes: In response to updating the execution status of the test case to the paused state, the sending of control instructions corresponding to the next operation data in the test case to the first virtual object is stopped, and the current execution progress of the test case is determined.

7. The method according to claim 6, characterized in that, The step of resuming execution of the test case after the location update until the test result is obtained includes: Obtain the current execution progress of the test case, and obtain the remaining pending operation data from the test case based on the current execution progress; The execution state is updated to the running state, and the first virtual object is controlled to execute each of the pending operation data in sequence; After each of the aforementioned operations is completed, the test results are generated.

8. The method according to claim 7, characterized in that, The generation of the test results includes: Obtain the test status data of the first virtual object after executing each of the data to be executed, and obtain the target status data of the first virtual object from the test case; When the test status data matches the target status data, the running status data of the test case during execution is obtained; If the running status data does not contain abnormal data, a test result indicating that the test has passed is generated.

9. The method according to claim 8, characterized in that, The method further includes: When the test state data does not match the target state data, the deviation information between the test state data and the target state data is determined; Alternatively, when the running status data contains abnormal data, abnormal information is generated based on the abnormal data; Generate test results to characterize a failed test, wherein the test results to characterize a failed test include at least one of the deviation information and the anomaly information.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: When the timing for generating the test case is reached, in response to receiving at least one second operation, operation data corresponding to each second operation is generated; When the second operation is a movement operation on the second virtual object, determine the target location data of the second virtual object corresponding to the second operation; The test cases are constructed based on the operation data and target location data corresponding to each of the second operations.

11. The method according to claim 10, characterized in that, The generation of operation data corresponding to the second operation includes: Obtain the operation control and operation parameters corresponding to the second operation; The operation controls and operation parameters are encapsulated into operation data according to a preset format.

12. The method according to claim 10, characterized in that, The step of constructing the test cases based on the operation data and target location data corresponding to each second operation includes: Obtain the first time information when each of the second operations is triggered; Based on the first time information, the operation data and the target location data corresponding to each second operation are arranged in time sequence to obtain an operation sequence; Obtain the target state data of the second virtual object after each of the second operations is executed; The test cases are generated based on the operation sequence and the target state data.

13. The method according to claim 12, characterized in that, The method further includes: The test cases are analyzed to obtain multiple test nodes and the second time information corresponding to each test node; The execution order between each of the test nodes is determined based on each of the second time information. Based on the execution order, the connection relationship between each test node is established to obtain the test node graph.

14. The method according to claim 13, characterized in that, The method further includes: Output the test node diagram; In response to receiving an update instruction for a target test node in the test node graph, determine the update parameters corresponding to the update instruction; Based on the updated parameters, the target test node is processed to update the data, resulting in an updated test node graph.

15. The method according to claim 13, characterized in that, The method further includes: In response to receiving the test instruction, the test node diagram is obtained; According to the connection relationship between the test nodes in the test node diagram, each test node is executed sequentially. After each test node is completed, the test results are obtained.

16. The method according to claim 1, characterized in that, The method further includes: Determine the number of times the position update is executed during the execution of the test case, and the position deviation data for each position update; When the number of times exceeds the number of times threshold, or when the position deviation data reaches the preset condition, an update prompt message for the test case is generated and the update prompt message is output. In response to receiving a confirmation instruction for the update prompt information, the target location data in the test case is replaced with the first location data corresponding to the first virtual object to obtain a new test case.

17. A testing apparatus, characterized in that, The device includes: The acquisition module is used to acquire pre-recorded test cases in response to receiving a test instruction, wherein the test cases include at least one operation data for a first virtual object; The control module is used to control the first virtual object to perform the first operation corresponding to each operation data, based on the operation data. The acquisition module is further configured to, when the first operation is a movement operation, acquire target location data corresponding to the operation data from the test case, perform location verification on the first virtual object based on the target location data, and obtain a verification result; The execution module is used to pause the execution of the test case and update the position of the first virtual object based on the target location data when the verification result indicates that the verification has failed. The execution module is also used to resume the execution of the test cases after the location is updated, until the test results are obtained.

18. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method described in any one of claims 1 to 16.

20. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method according to any one of claims 1 to 16.

Images