A virtual data peripheral data-based mounting method and terminal

Abstract

The application provides a mounting method and terminal based on a virtual data peripheral, comprising: obtaining a main thread message loop of a target application, and creating a custom message type in the main thread message loop; receiving a mounting request, and parsing virtual data and an execution mode in the mounting request; based on a determination result of the execution mode, calling corresponding execution logic to mount the virtual data; and outputting a mounting result of the virtual data. The application realizes a lightweight and extensible test data mounting scheme based on message queue intervention, solves the problems of poor stability and limited extensibility of a traditional injection tool due to an asynchronous remote injection mode being unable to reliably intervene in a synchronous execution process, and provides a universal mounting mechanism that is adaptive to an environment, thereby improving the depth, flexibility and execution reliability of testing.

Description

Technical Field

[0001] This invention relates to the field of software development and testing, and in particular to a method and terminal for mounting virtual data peripherals. Background Technology

[0002] In the development and testing of game software, especially large-scale client games, testers often need to inject specific test data or scripts into the game process to verify functional logic, performance, or security. Related test data injection or mounting techniques, such as memory-modification-based auxiliary tools or remote thread injection techniques, generally suffer from limitations such as insufficient support for synchronous execution, poor execution stability and security, and limited flexibility and scalability. Testers find it difficult to dynamically select the most suitable execution mode according to testing needs and to manage the execution order and result collection of batch test tasks in an orderly manner. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a method and terminal for mounting virtual data peripherals, so as to realize the stable and secure injection and execution of virtual data peripherals into running system processes.

[0004] A method for mounting virtual peripheral data, the method comprising: Obtain the main thread message loop of the target application, and create a custom message type within the main thread message loop; Receive a virtual data mounting request, and parse the virtual data and execution mode in the mounting request; Based on the determination result of the execution mode, the corresponding execution logic is invoked to mount the virtual data to satisfy the custom message type; Output the mounting result corresponding to the execution mode to the main thread message loop.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A mounting terminal based on virtual data peripherals includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it performs the following steps: Obtain the main thread message loop of the target application, and create a custom message type within the main thread message loop; Receive a virtual data mounting request, and parse the virtual data and execution mode in the mounting request; Based on the determination result of the execution mode, the corresponding execution logic is invoked; Output the mounting result corresponding to the execution mode to the main thread message loop.

[0006] The beneficial effects of this invention are as follows: By acquiring the main thread message loop of the target application and creating custom message types, the main thread message loop is used for the system's native event-driven and task scheduling core. The custom message types serve as a channel for communication between external test logic and the main thread, constructing a stable and universal test mounting channel. This achieves adaptive support for multiple execution modes of the system, overcomes the limitations of traditional injection techniques in supporting synchronous execution, and avoids the stability risks of code hooks. Based on intelligent judgment and diversion of virtual data execution modes, tasks are automatically scheduled to the corresponding execution processor according to the judgment result of the execution mode, providing a unified task scheduling and result feedback mechanism. This allows for centralized orchestration and management of mixed test tasks, solving the problems of task dispersion and difficulty in result collection in traditional methods. Through extensible custom message types, flexible and standardized extension interfaces are provided for complex test scenarios, improving the depth of test coverage and the level of automation. By mounting test logic into the system's native execution flow in a message-based, non-immersive manner, test efficiency and automation are improved, while fundamentally ensuring the operational security of the target program and the stability and reliability of the test process. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a method for mounting virtual peripheral data provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the main thread identification and message mechanism construction provided in this embodiment of the invention; Figure 3 This is a flowchart of synchronous message creation and callback execution provided in an embodiment of the present invention; Figure 4 A flowchart illustrating the adaptive scheduling of execution modes provided in this embodiment of the invention; Figure 5 A flowchart of multi-threaded collaboration and sequence control provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a mounting terminal based on virtual data peripheral data provided in an embodiment of the present invention; Label Explanation: 1. A mounting terminal based on virtual data peripherals; 2. Processor; 3. Memory. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] Please refer to Figure 1 A method for mounting virtual peripheral data, comprising steps 110 to 140.

[0010] Step 110: Obtain the main thread message loop of the target application and create custom message types within it. For example, for a target game or application, identify its main thread and monitor its message queue. Without disrupting the original message processing logic, create "blank" positions in the message processing chain where custom processing branches can be inserted, and define corresponding custom message types for the test functions to be executed.

[0011] Step 120: Receive mount requests and parse the virtual data and execution mode in the mount requests. For example, receive mount requests from test scripts or external tools, parse the test data content contained therein and the expected execution mode of the data, that is, determine the execution mode of the virtual data in the main thread.

[0012] Step 130: Based on the execution mode determination result, call the corresponding execution logic to mount virtual data; to satisfy the custom message type. For example, based on the execution mode determination result, call the execution logic corresponding to the determination result to mount virtual data; to prepare for the custom message type.

[0013] Step 140: Output the virtual data mounting result to the main thread message loop. For example, after execution, return the virtual data mounting result for subsequent judgment and recording.

[0014] As described above, the beneficial effects of this invention are as follows: By acquiring the target application's main thread message loop and creating custom message types, a stable and universal test mounting channel is constructed, achieving adaptive support for both synchronous and asynchronous execution modes of the system. This overcomes the limitations of traditional injection tools in supporting synchronous execution and avoids the stability risks of directly hooking code. Based on intelligent judgment and distribution of virtual data execution modes, a unified task scheduling and result feedback mechanism is provided, enabling centralized orchestration and management of mixed test tasks and solving the problems of task dispersion and difficulty in result collection in traditional testing methods. Simultaneously, through extensible custom message types, flexible and standardized extension interfaces are provided for complex test scenarios, improving the depth of test coverage and the level of automation. While improving testing efficiency and automation, it fundamentally ensures the operational security of the target program and the stability and reliability of the testing process, providing an efficient and scalable automated testing support system for system development and testing.

[0015] Further, step 130 includes step 131.

[0016] Step 131: Select and call the execution processor bound to the execution mode determination result. For example, select and call the execution processor bound to the determination result based on the execution mode determination result, thereby achieving adaptive processing for different execution modes.

[0017] As described above, by intelligently binding predefined processors to execution modes, the system automatically calls either synchronous or asynchronous execution processors based on the execution mode determination result. This achieves adaptive mounting for different execution environments, ensuring both the accuracy and timing of synchronous execution while leveraging the efficiency and concurrency advantages of asynchronous execution. This mechanism enables the testing system to flexibly allocate execution resources according to actual needs, improving the intelligence level and execution efficiency of test task scheduling.

[0018] Furthermore, step 130 includes steps 132 and 133.

[0019] Step 132: If the execution mode is determined to be synchronous execution mode, the synchronous execution processor converts the virtual data into message content recognizable by the custom message type and drives the main thread's message loop to process the message content. For example, if the execution mode is determined to be synchronous execution mode, the synchronous execution processor encapsulates the incoming virtual data and its parameters into structured instructions that conform to the main thread's message format and drives the main thread's message loop to process the message content.

[0020] Step 133: If the execution mode determination result is asynchronous execution mode, then the asynchronous execution processor is invoked. The asynchronous execution processor is used to create an independent execution environment for the virtual data and establish a result synchronization mechanism with the execution environment. For example, if the execution mode determination result is asynchronous execution mode, the asynchronous execution processor is invoked. The asynchronous execution processor is used to create an independent execution environment for the virtual data and establish a result synchronization channel with the main thread or monitoring thread, ensuring that state changes, exception information, or output results generated during asynchronous execution can be captured in real time and fed back to the unified test management framework to support subsequent task scheduling and result aggregation.

[0021] As described above, by distinguishing between synchronous and asynchronous execution modes and adapting them to corresponding processor mechanisms, precise matching and efficient collaboration between test tasks and the execution environment are achieved. This ensures consistency in execution order and state in scenarios requiring strict timing control, fully leverages system resources in concurrent tasks, and guarantees controllable and traceable test processes and results through a standardized result synchronization mechanism, thereby improving the overall coordination and reliability of the automated testing system.

[0022] Further, step 132 includes steps 1321 to 1323.

[0023] Step 1321: Generate message parameters based on the virtual data using the synchronous execution processor. For example, the synchronous execution processor performs structured parsing on the received virtual data, extracts operation instructions, parameter values, and context dependency information related to the test function, and generates message parameter objects that can be identified and processed in the main thread message loop.

[0024] Step 1322: Construct a synchronous message containing message parameters and a custom message type. For example, based on the generated message parameters and a preset custom message type identifier, construct a synchronous message body that conforms to the target application's message format, ensuring that the message structure includes the message type identifier, parameter payload, and necessary metadata so that the main thread can correctly route and execute the corresponding function.

[0025] Step 1323: Send the synchronization message to the main thread's message queue so that the message loop responds to the message content. For example, through inter-thread communication mechanisms or system APIs, the constructed synchronization message can be safely inserted into the main thread's message queue. The insertion position can be controlled sequentially according to the test logic requirements. When the main thread processes the message in sequence in its message loop, it will trigger the callback processing logic bound to the custom message type, thereby executing the corresponding test function in the synchronous environment.

[0026] As described above, by standardizing and encapsulating virtual data and converting it into a format conforming to the target application's main thread message processing specifications, seamless integration and collaborative operation of the test logic and the system's underlying message processing mechanism are achieved. This lightweight mounting method based on message queue intervention does not require direct modification or intrusive hooking of the application's source code or execution flow, fundamentally avoiding program crashes, security risks, or compatibility issues that may be caused by traditional code injection, thus ensuring the stable operation of the target system. Through precise control of message insertion position and execution order, it is ensured that the test function can be triggered and executed strictly according to the preset timing in the main thread environment, achieving high-fidelity reproduction and verification of complex interaction processes.

[0027] Furthermore, step 1323 includes steps 1324 to 1326.

[0028] Step 1324: Identify the custom message type through the message loop dispatch logic in the main thread. For example, in the message processing loop of the main thread, the system's original message dispatcher judges based on the message type identifier in the message structure. When the identifier is detected to match the pre-registered custom message type, it is confirmed that the message is a test instruction message to be processed and marked as a special message category that needs to be processed by custom logic.

[0029] Step 1325: Invoke the first callback function pre-associated with the custom message type and pass the message parameters to the first callback function. For example, the message dispatch logic searches for and calls the first callback function bound to the custom message type in the preset callback mapping table, and passes the message parameters encapsulated in step 1322 as input to the callback function to ensure that the test logic can obtain the complete execution context.

[0030] Step 1326: The first callback function executes the business logic corresponding to the virtual data. For example, the first callback function parses and executes the test behavior described in the incoming message parameters, such as simulating user operations, triggering in-game events, verifying function responses, etc., and maintains synchronization with the main thread during execution to ensure that the test process does not affect the normal flow of the original business logic.

[0031] As described above, by encapsulating the test logic into callback functions that are deeply integrated with the main thread's message mechanism, test tasks are executed in the queue within the original system flow. This not only avoids strong dependence on the external execution environment but also ensures that the test logic can be scheduled and executed in the same way as the system's native behavior. Thus, while improving test reliability, it maintains the consistency and coordination of the entire system at the execution level.

[0032] Further, step 133 includes steps 1331 to 1333.

[0033] Step 1331: Create an asynchronous execution thread and allocate virtual data to it. For example, after receiving virtual data that needs to be processed asynchronously, the asynchronous execution processor dynamically creates an independent execution thread and allocates the virtual data and its associated execution parameters to that thread, enabling it to execute test tasks concurrently with the main thread, thereby improving the utilization of system resources and test execution efficiency.

[0034] Step 1332: Create a result listening thread and configure a second callback function associated with a custom message type to bind the second callback function to the result listening thread. For example, to ensure that asynchronous execution results can be captured in a timely manner and incorporated into a unified test management process, the system creates a dedicated result listening thread and registers a second callback function associated with a specific custom message type within it. This second callback function serves as the response entry point when the asynchronous task completes, forming a binding relationship with the listening thread to ensure that the result feedback mechanism remains connected to the main thread's message system.

[0035] Step 1333: Monitor the status of the asynchronous execution thread through a result listening thread and execute the second callback function upon completion. For example, the result listening thread continuously monitors the running status of the asynchronous execution thread, and when it detects that the execution has completed, including normal termination or abnormal termination, it triggers the pre-bound second callback function. This callback function is responsible for receiving the asynchronous execution result and converting it into a message or event that can be further processed in the main thread or the test framework, thereby achieving closed-loop management of asynchronous test tasks.

[0036] As described above, by constructing a dual-threaded collaborative mechanism of asynchronous execution thread and result listening thread, a result synchronization path connecting with the main thread's message system is established while ensuring the concurrent execution capability of test tasks. This design fully leverages the advantages of asynchronous execution in resource utilization and response speed, and ensures the controllability of the testing process and the traceability of results through a structured listening and callback mechanism, thereby achieving the systematization and automation of task scheduling and state management in complex multi-threaded testing scenarios.

[0037] Furthermore, step 1333 includes step 1334.

[0038] Step 1334: The result listening thread waits for event notifications from the asynchronous execution thread, or periodically checks the shared state flag updated by the asynchronous execution thread. If the shared state flag meets preset conditions, the asynchronous execution thread's state is "execution complete," and the second callback function is executed. For example, the result listening thread can use a passive listening method, waiting for the asynchronous execution thread to actively send an event notification when the task ends, such as through a semaphore, event object, or message; or it can use an active polling method, periodically checking the shared state flag updated by the asynchronous execution thread, such as a flag variable, counter, or status register. If an event notification is detected, or if the shared state flag meets the preset completion conditions (e.g., the flag is set to "complete"), the asynchronous execution thread's state is determined to be "execution complete," and the second callback function associated with that state is triggered to process the task result and execute subsequent logic.

[0039] As described above, by providing two optional thread synchronization mechanisms—event-driven and state polling—the system's adaptability under different execution environments and performance requirements is enhanced. The event notification mechanism is suitable for scenarios with high real-time response requirements, minimizing result feedback latency; the state polling mechanism is suitable for frameworks that need to be compatible with legacy systems or cannot rely on event notifications, enhancing the solution's versatility and robustness. This flexible state monitoring strategy ensures reliable connection between asynchronous test task execution and result callbacks, providing a guarantee for the stable operation of the test system in multi-threaded, high-concurrency environments.

[0040] Further, step 110 obtains the main thread message loop of the target application, including steps 111 to 113.

[0041] Step 111: Traverse the process and thread list of the target application. For example, use the process management interfaces provided by the operating system, such as the CreateToolhelp32Snapshot and Thread32First / Next APIs in Windows, to obtain all thread handles and their basic information for the target application process, and construct a thread list that can be traversed and analyzed.

[0042] Step 112: Identify the main thread from the process thread list based on the thread startup sequence characteristics and whether it holds window message processing callbacks. For example, during the traversal of the thread list, the main thread is identified according to the following criteria: First, the main thread is usually the first thread created in the process, and its startup time is the earliest; second, the main thread is usually responsible for handling the window message loop, which can be verified by checking whether it is associated with a window handle or whether it has a message queue callback mechanism. Combining the above characteristics, the main thread is accurately identified from multiple threads.

[0043] Step 113: Obtain the main thread's message loop. For example, after identifying the main thread, use system APIs such as GetQueueStatus and PeekMessage, or memory analysis methods, to locate and obtain the message queue structure and message dispatch function entry point corresponding to the thread, thereby establishing an access and control channel for the main thread's message loop.

[0044] As described above, by combining the thread creation sequence and message handling responsibilities, accurate identification and location of the main thread are achieved. This approach is not only applicable to common graphical user interface applications but can also be extended to various message-driven system processes, demonstrating strong versatility and applicability. Accurately obtaining the main thread's message loop structure lays a reliable technical foundation for subsequent message injection and mounting execution, ensuring that the entire test mounting process can proceed within the correct execution context.

[0045] Further, in step 110, a custom message type is created in the main thread message loop, including steps 114 and 115.

[0046] Step 114: Save the entry address of the original message handler in the main thread's message loop. For example, before intervening in the main thread's message processing flow, first obtain and save the entry address of the original message dispatch function or message callback function in the system. This ensures that while mounting custom message types, the system's original message processing capabilities can be fully preserved, providing a technical foundation for subsequent message forwarding or process recovery.

[0047] Step 115: Modify the message distribution logic of the main thread message loop, adding a branch for judging custom message types, and updating the processing of custom message types to the newly registered message handler. For example, insert a branch for recognizing and processing custom message types at key nodes in the message distribution process. When the message type matches the preset custom representation, the system will automatically route it to the newly registered message handler, which will be responsible for executing the functions related to the test logic; if it does not match, it will still be handled by the original, saved message handler according to the original process, thus embedding an extensible test execution channel without interfering with the normal functioning of the system.

[0048] As described above, while maintaining the integrity of the original message processing architecture, a secure integration of test logic and the system's native message mechanism is achieved by inserting controllable and reversible message processing branches. This design pattern ensures the smooth mounting and execution of custom message types while minimizing stability risks caused by modifications to critical system processes, thus guaranteeing operational stability. It possesses excellent reversibility and isolation; the original logic can be fully restored after the task is completed, and the execution process is constrained by system scheduling, without interfering with normal business flow, providing consistent and sustainable support for long-term, repeatable automated testing.

[0049] Please refer to Figure 2 The following describes specific application embodiments of this application. This application can apply the above solution to game automated testing and data-driven mounting scenarios, including the following steps: S21. After the test system starts, it iterates through the thread list of the target game process, accurately identifies the main thread based on the thread startup sequence and window message processing characteristics, and obtains its message loop structure. After obtaining the main thread's message loop, it saves the entry address of the original message handler and inserts a judgment branch for the custom message type into the message dispatch logic. It defines and registers the corresponding message types and their corresponding processing callbacks according to the test requirements, such as "execute combat command" and "send chat message." This is equivalent to step 110.

[0050] S22. The test management terminal issues a test task package. The system parses the virtual data and execution mode contained within it. Based on the determination result of the execution mode, it selects and calls the corresponding execution processor. Synchronous tasks enter the main thread message mounting process, while asynchronous tasks are assigned to independent threads for execution. This is equivalent to steps 120 and 130.

[0051] S23. In synchronous execution mode, the virtual data is encapsulated into a synchronous message conforming to the main thread message format and injected into the specified position of the main thread message queue. After the main thread identifies the custom message type in the message loop, it calls the pre-registered callback function to execute the corresponding business logic and synchronously returns the execution result. This is equivalent to steps 132 to 1326.

[0052] S24. If asynchronous execution mode is used, an independent asynchronous execution thread is created to run the test task, and a dedicated result listening thread is created synchronously to determine the callback function associated with the custom message type. The listening thread monitors the execution status of the asynchronous thread through event notification or status polling mechanisms, and triggers a callback to return the result upon task completion. Regardless of synchronous or asynchronous execution, the execution status and results of all test tasks are collected and fed back through a unified interface, supporting testers to monitor, analyze, and schedule the execution process. This is equivalent to steps 133 to 1334.

[0053] Through the above application examples, this invention implements a complete game test data mounting process, from main thread identification, message mechanism extension, intelligent task scheduling to unified feedback of execution results. This method achieves adaptive support for both synchronous and asynchronous execution environments without intruding on the game's core code, improving the stability, flexibility, and execution efficiency of automated testing. It is suitable for various game testing scenarios such as functional testing and interactive process verification.

[0054] Please refer to Figure 3 The following describes specific application examples of this application. This application can apply the above solution to the message-based task execution and result callback management scenario in game automated testing, including the following steps: S31. Based on the testing requirements, encapsulate the test functions to be executed, such as "perform monster-fighting operations" and "send chat messages," into structured message parameters, and determine the corresponding custom message types. This is equivalent to steps 1321 and 1322.

[0055] S32. The system determines whether a new custom message type needs to be registered for the current test function. If so, the system dynamically inserts a judgment branch for that message type into the main thread's message processing logic and binds it to the corresponding processing callback function. This is equivalent to step 115.

[0056] S33. Append the encapsulated test data to the registered custom message type and insert the message into the main thread's message queue through a message injection mechanism. After the main thread identifies the message type in the message loop, it calls the bound callback function to execute the corresponding business logic. Configure a dedicated result callback function for the executed message type to receive status and result data after the task execution is complete. This is equivalent to steps 1323 and steps 1324 to 1326. S34. Determine whether the current task needs to synchronously wait for the execution result based on the test configuration. If yes, proceed to the result acquisition process; otherwise, the task ends directly. This is equivalent to steps 120 and 130.

[0057] S35. Obtain the result data returned by the callback function after the message execution is completed through a synchronous waiting mechanism, and feed the result back to the test management system. This is equivalent to step 140.

[0058] Through the above application examples, this invention implements a complete process for synchronous execution and result management of game test tasks based on message injection. This method encapsulates test functions as messages, dynamically expands message types, injects execution data, and binds result callbacks, enabling safe and orderly execution of test tasks in the main thread environment. It also ensures that execution results are traceable and verifiable, making it suitable for game function testing scenarios requiring strict timing control and state synchronization.

[0059] Please refer to Figure 4 The following describes a specific application embodiment of this application. This application can apply the above solution to the adaptive execution mode scheduling scenario of game testing tasks, including the following steps: S41. After receiving the task instruction, the test system first parses and obtains the data type corresponding to the task, and determines whether it belongs to the synchronous or asynchronous execution type. The system makes a judgment based on the data type. If it is asynchronous execution, it enters the asynchronous execution branch; if it is synchronous execution, it enters the synchronous execution branch. This is equivalent to step 120.

[0060] S42. If the execution is determined to be asynchronous, the system creates an independent execution thread and assigns the test task to that thread. A dedicated message callback thread is created for the asynchronous execution task to monitor the asynchronous execution result and synchronize with the main thread. The message callback thread continuously monitors the status of the asynchronous execution thread, waiting for its completion and triggering the callback. If the execution is determined to be synchronous, the system encapsulates the test task into a synchronous message content conforming to the main thread's message format. The encapsulated synchronous message is injected into the main thread's message queue, and execution is triggered by the main thread's message loop, completing the test task within the synchronous context. After the task is completed, the system ends the current scheduling process and prepares to receive the next test task. This is equivalent to steps 1331 to 1333 and steps 1321 to 1326.

[0061] Through the above application examples, this invention implements a complete adaptive execution scheduling mechanism for game testing tasks. This mechanism can automatically select synchronous or asynchronous execution modes based on task characteristics, ensuring both execution efficiency and reliability for different types of tasks. The synchronous execution mode ensures timing accuracy through message injection, while the asynchronous execution mode improves system resource utilization through thread separation. Both are seamlessly integrated through a unified task scheduling framework, providing a flexible and efficient execution solution for complex game testing scenarios.

[0062] Please refer to Figure 5 The following describes specific application embodiments of this application. This application can apply the above solution to multi-threaded collaboration and sequence control scenarios in game testing tasks, including the following steps: S51. Based on testing requirements, configure the sorting of synchronous tasks that need to be executed sequentially in the main thread, clarifying the execution order between tasks. Configure the execution order of asynchronous tasks that can be executed concurrently in sub-threads, clarifying the dependencies and triggering conditions between tasks. Set a unique status identifier for each asynchronous task to track the task execution status and results in subsequent processes. This is equivalent to steps 131 to 133 and step 1333.

[0063] S52. The system continuously checks the status flags of asynchronous tasks to determine whether the task has been completed and returned a result. When an asynchronous task has not yet been completed, the system enters a waiting state, continuously monitoring the flag status until the task is completed. Once the completion of a preceding asynchronous task is detected, the system immediately triggers the execution of the next asynchronous task that depends on that result, forming a task chain execution. When all configured asynchronous tasks have been executed, the current task scheduling process ends. This is equivalent to steps 1334 and 140.

[0064] Through the above application examples, the present invention achieves fine-grained sequential control and collaborative scheduling of synchronous and asynchronous tasks in game testing. This mechanism not only ensures the precise timing of synchronous tasks in the main thread, but also effectively manages the dependencies between asynchronous tasks. Through the identification mechanism, it realizes real-time control and intelligent triggering of task status, providing reliable execution order guarantees for complex multi-threaded game testing scenarios and improving the coordination and execution efficiency of test tasks.

[0065] Please refer to Figure 6 A mounting terminal 1 based on virtual data peripherals includes a memory 3, a processor 2, and a computer program stored on the memory 3 and running on the processor 2. When the processor 2 executes the computer program, it implements each step of the above-mentioned mounting method based on virtual data peripherals.

[0066] In summary, this invention provides a method and terminal for mounting virtual data peripherals, constructing a lightweight test data mounting system with the main thread message loop as its core, adaptive execution mode scheduling as its support, and an extensible message mechanism as its carrier. This method, by identifying and intervening in the application's main thread message queue, achieves secure and non-intrusive functional extensions to synchronous and asynchronous execution environments, fundamentally avoiding the stability risks and compatibility issues associated with traditional code injection or remote thread techniques.

[0067] Based on intelligent judgment and routing of execution modes, the system provides a unified task scheduling framework and result feedback mechanism, enabling centralized orchestration and management of mixed test tasks. This solves the problems of task dispersion, environment fragmentation, and difficulty in result collection in traditional testing methods. Through flexibly extensible custom message types and standardized callback interfaces, this solution provides a highly flexible and reusable functional expansion path for complex testing scenarios, supporting multi-dimensional in-depth testing of game functions, interaction processes, and performance.

[0068] Furthermore, the system achieves reliable collaboration and closed-loop management of multi-threaded tasks by constructing a dual-threaded cooperation mechanism of asynchronous execution threads and result monitoring threads, along with an event / polling-based state synchronization strategy. Combined with sequence control and flag-driven mechanisms, the system can achieve fine-grained scheduling of test task execution processes, meeting the needs of different scenarios from strictly sequential execution to high-concurrency asynchronous execution.

[0069] This method is applicable to scenarios such as game functional testing, automated verification, interactive process reproduction, and stress testing. By constructing a complete, stable, and scalable test data mounting and execution framework, it effectively solves the technical limitations of traditional testing tools in terms of synchronization support, scalability, and stability, improves the automation level, execution reliability, and system compatibility of the testing process, and provides efficient and sustainable technical support for the quality assurance of games and other software products.

[0070] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for mounting virtual peripheral data, characterized in that, include: Obtain the main thread message loop of the target application, and create a custom message type within the main thread message loop; Receive mount request, and parse the virtual data and execution mode in the mount request; Based on the determination result of the execution mode, the corresponding execution logic is invoked to mount the virtual data to satisfy the custom message type; The mounting result of the virtual data is output to the main thread message loop.

2. The method for mounting virtual peripheral data according to claim 1, characterized in that, The determination result based on the execution mode, invoking the corresponding execution logic, includes: Based on the determination result of the execution mode, the execution processor bound to the determination result is selected and invoked.

3. The method for mounting virtual peripheral data according to claim 1, characterized in that, Based on the determination result of the execution mode, the corresponding execution logic is invoked to satisfy the custom message type, including: If the execution mode determination result is synchronous execution mode, then the virtual data is converted into message content that can be recognized by the custom message type by the synchronous execution processor, and the message loop of the main thread is driven to process the message content. If the determination result of the execution model is asynchronous execution mode, then the asynchronous execution processor is invoked. The asynchronous execution processor is used to create an independent execution environment for the virtual data and establish a result synchronization mechanism with the execution environment.

4. The method for mounting virtual peripheral data according to claim 3, characterized in that, If the execution mode determination result is synchronous execution mode, then the virtual data is converted into message content recognizable by the custom message type by the synchronous execution processor, and the message loop of the main thread is driven to process the message content, including: The synchronous execution processor generates message parameters based on the virtual data; Construct a synchronization message that includes the message parameters and the custom message type; The synchronization message is sent to the message queue of the main thread so that the message loop responds to the message content.

5. The method for mounting virtual peripheral data according to claim 4, characterized in that, Sending the synchronization message to the message queue of the main thread so that the message cyclically responds to the message content includes: The custom message type is identified through the message loop dispatch logic in the main thread; Invoke the first callback function pre-associated with the custom message type, and pass the message parameters to the first callback function; The business logic corresponding to the virtual data is executed by the first callback function.

6. The method for mounting virtual peripheral data according to claim 3, characterized in that, If the determination result of the execution model is asynchronous execution mode, then the asynchronous execution processor is invoked. The asynchronous execution processor is used to create an independent execution environment for the virtual data and establish a result synchronization mechanism with the execution environment, including: Create an asynchronous execution thread and allocate the virtual data to the asynchronous execution thread; Create a result listening thread and configure a second callback function associated with the custom message type to bind the second callback function to the result listening thread; The result listening thread monitors the state of the asynchronous execution thread and executes the second callback function upon completion.

7. The method for mounting virtual peripheral data according to claim 6, characterized in that, The step of monitoring the state of the asynchronous execution thread through the result listening thread and executing the second callback function upon completion includes: The result listening thread waits for event notifications issued by the asynchronous execution thread, or periodically checks the shared state flag updated by the asynchronous execution thread. If the shared state flag meets preset conditions, the asynchronous execution thread's state is "execution complete," and the second callback function is executed.

8. The method for mounting virtual peripheral data according to claim 1, characterized in that, The process of obtaining the main thread message loop of the target application includes: Iterate through the list of processes and threads of the target application; Based on the thread startup timing characteristics and whether it holds a window message processing callback, the main thread is identified from the process thread list; Obtain the main thread message loop of the main thread.

9. The method for mounting virtual peripheral data according to claim 1, characterized in that, The creation of custom message types in the main thread message loop includes: Save the entry address of the original message handler in the main thread message loop; Modify the dispatch logic of the main thread message loop, add a judgment branch for the custom message type, and update the processing of the custom message type to the newly registered message processor.

10. A mounting terminal based on virtual data peripheral data, characterized in that, It includes a memory, a processor, and a computer program stored on the memory and running on the processor, wherein the processor executes the computer program to implement each step of the mounting method based on virtual data peripheral data as described in any one of claims 1 to 9.

Images