Test task scheduling method and device, equipment, medium and program product

Abstract

The embodiment of the invention provides a test task scheduling method and device, equipment, a medium and a program product, and the test task scheduling method comprises the steps that a test task instruction sent by a user operation interface is received, and the test task instruction comprises a selected application identifier, a test case and at least one tested terminal; a test task is distributed to at least one tested terminal in parallel, and the test task is used for deploying and running an application corresponding to the application identifier and executing the test case; and receiving test result data collected and reported by at least one tested terminal. Through receiving user instructions and performing unified scheduling, centralized management and parallel distribution of test tasks are realized, through automatic deployment, operation and data reporting, manual intervention is reduced, flow consistency is ensured, execution efficiency is improved, multi-device collaborative test is realized, test coverage rate and reliability are remarkably improved, and manual operation errors are reduced.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of automatic testing, in particular to a test task scheduling method, device, equipment, medium and program product. BACKGROUND

[0002] With the improvement of game complexity and the diversification of terminal devices, automatic testing has become a key to guarantee product quality. The current test needs to cover a large number of devices and versions, and the traditional manual execution method is inefficient and difficult to meet the needs of high-frequency iteration.

[0003] However, the traditional serial testing method is inefficient and cannot meet the massive testing demand. In multi-device distributed testing, the problems of low testing efficiency and insufficient resource utilization often occur.

[0004] Therefore, there is an urgent need for a solution that integrates centralized scheduling and automatic execution. SUMMARY

[0005] Therefore, the embodiments of the present application provide a test scheduling task method. One or more embodiments of the present application also relate to a test task scheduling device, a computing device, a computer readable storage medium and a computer program product to solve the technical defects in the prior art.

[0006] According to a first aspect of the embodiments of the present application, a test task scheduling method is provided, applied to a server, comprising: receiving a test task instruction sent by a user interface, wherein the test task instruction contains a selected application identifier, a test case and at least one terminal to be tested; distributing the test task to the at least one terminal to be tested in parallel, wherein the test task is used to deploy and run the application corresponding to the application identifier, and execute the test case; receiving the test result data collected and reported by the at least one terminal to be tested.

[0007] According to a second aspect of the embodiments of the present application, a test task scheduling method is provided, applied to a terminal to be tested, comprising: receiving a test task distributed by a server, the task containing an application identifier and a test case; deploying the application corresponding to the application identifier according to the application identifier; running the application and running the test case; collecting result data in the test process and reporting to the server.

[0008] According to a third aspect of the embodiments of the present application, a test task scheduling device is provided, applied to a server, comprising: The first receiving module is configured to receive a test task instruction sent by the user operation interface, wherein the test task instruction contains a selected application identifier, a test case and at least one terminal under test; The distribution module is configured to distribute the test task to the at least one terminal under test in parallel, wherein the test task is used to deploy and run an application corresponding to the application identifier and execute the test case; The second receiving module is configured to receive test result data collected and reported by the at least one terminal under test.

[0009] According to a fourth aspect of the embodiment of the present application, a test task scheduling device applied to a terminal under test is provided, comprising: The third receiving module is configured to receive a test task distributed by the server, wherein the task contains an application identifier and a test case; The deployment module is configured to deploy an application corresponding to the application identifier according to the application identifier; The running module is configured to run the application and run the test case; The collection module is configured to collect result data in a test process and report to the server.

[0010] According to a fifth aspect of the embodiment of the present application, a computing device is provided, comprising: A memory and a processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which realize the steps of the above test task scheduling method when executed by the processor.

[0011] According to a sixth aspect of the embodiment of the present application, a computer readable storage medium is provided, which stores computer programs / instructions, which realize the steps of the above test task scheduling method when executed by the processor.

[0012] According to a seventh aspect of the embodiment of the present application, a computer program product is provided, comprising computer programs / instructions, which realize the steps of the above test task scheduling method when executed by the processor.

[0013] One embodiment of the present application realizes receiving a test task instruction sent by a user operation interface, wherein the test task instruction contains a selected application identifier, a test case and at least one terminal to be tested; distributing the test task to the at least one terminal to be tested in parallel, wherein the test task is used to deploy and run an application corresponding to the application identifier, and execute the test case; and receiving test result data collected and reported by the at least one terminal to be tested. Through receiving a user instruction and unified scheduling, centralized management and parallel distribution of the test task are realized, through automatic deployment, running and data reporting, manual intervention is reduced, process consistency is ensured, execution efficiency is improved, multi-device collaborative testing is realized, test coverage and reliability are significantly improved, and human operation errors are reduced. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 is a schematic diagram of interaction of each end of a test task scheduling system provided by one embodiment of the present application; Figure 2 is a flowchart of a test task scheduling method provided by one embodiment of the present application; Figure 3 is a flowchart of another test task scheduling method provided by one embodiment of the present application; Figure 4 is a flowchart of a processing procedure of a test task scheduling method provided by one embodiment of the present application; Figure 5 is a structural schematic diagram of a test task scheduling device provided by one embodiment of the present application; Figure 6 is a structural schematic diagram of another test task scheduling device provided by one embodiment of the present application; Figure 7 is a structural block diagram of a computing device provided by one embodiment of the present application. DETAILED DESCRIPTION

[0015] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the present application. Some embodiments of the present application can be practiced in a variety of ways, and the present application is not limited to the specific embodiments described in this specification.

[0016] The terminology used in this description of one or more embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to limit the present application one or more embodiments. As used in this description of one or more embodiments of the present application and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0017] It should be understood that, although the terms first, second, etc. can be employed in describing various information in one or more embodiments of the present application, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another type of information. For example, a first can be termed a second, and, similarly, a second can be termed a first, without departing from the scope of one or more embodiments of the present application. The word "if" as used herein means "when" or "upon" or "in response to the determination" depending on the context.

[0018] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in one or more embodiments of the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0019] First, the terms involved in one or more embodiments of the present application are explained.

[0020] Linux: A kind of open source Unix-like operating system kernel, widely used in servers, embedded devices and personal computers.

[0021] rsync: Full name for "remote sync", Chinese translation for "remote synchronization", is a fast and efficient file synchronization tool, supporting incremental backup and data transmission between local or remote systems, only transmitting the difference part of the file.

[0022] ssh: Full name for "Secure Shell", Chinese translation for "Secure Shell", is an encrypted network protocol, used for secure remote login, command execution and file transfer, to ensure that communication is not eavesdropped or tampered with.

[0023] RPC: Full name for "Remote Procedure Call", Chinese translation for "Remote Procedure Call", is a distributed computing technology that allows programs to call functions or services on remote computers as if they were local calls.

[0024] UE4: Full name for "Unreal Engine 4", Chinese translation for "Unreal Engine 4", is the fourth generation game engine developed by Epic Games, providing complete graphics rendering, physical simulation and development tools, widely used in games and virtual simulation.

[0025] In the present application, a test task scheduling method is provided, and the present application also relates to a test task scheduling system, a test task scheduling device, a computing device, a computer readable storage medium, and a computer program product, which are described in detail one by one in the following embodiments.

[0026] Referring to Figure 1 , Figure 1 is a schematic diagram of interaction of each end of a test task scheduling system provided by an embodiment of the present application. The test task scheduling system comprises a user terminal, a server and a plurality of measured terminals. The user terminal is configured to receive a test task instruction sent by a user through a user operation interface, and send the test task instruction to the server, wherein the test task instruction comprises a selected application identifier, a test case and at least one measured terminal. The server is configured to receive the test task instruction sent by the user operation interface, and distribute the test task to the at least one measured terminal in parallel, wherein the test task is used to deploy and run an application corresponding to the application identifier, execute the test case, and receive test result data collected and reported by the at least one measured terminal. The measured terminal is configured to receive the test task distributed by the server, wherein the test task comprises the application identifier and the test case, deploy the application corresponding to the application identifier according to the application identifier, run the application and execute the test case, collect result data in the test process and report to the server.

[0027] The test task scheduling system is applied to the test task scheduling system, the user terminal submits a task, the server uniformly schedules and distributes to a plurality of measured terminals in parallel, centralized management and efficient execution of the test task are realized, the server dynamically allocates the task according to the device state, the resource utilization rate is improved, the measured terminal automatically completes application deployment, case execution and data collection and reporting, manual intervention is reduced, three-party cooperation ensures test process automation and standardization, test coverage and execution efficiency are significantly improved, human error is reduced, large-scale device concurrent testing is supported, and testing reliability and traceability are enhanced.

[0028] Referring to Figure 2 , Figure 2 is a flowchart of a test task scheduling method provided by an embodiment of the present application, which specifically comprises the following steps.

[0029] Step 202: receiving a test task instruction sent by a user operation interface, wherein the test task instruction comprises a selected application identifier, a test case and at least one measured terminal.

[0030] The user operation interface is a graphical front-end platform for testers to interact with, for selecting and submitting test tasks. The test task instruction is a structured data packet containing application identifier, test case number, and list of terminals to be tested, serving as the input basis for task scheduling. The application identifier is a composite identifier used to uniquely identify a specific application instance, containing both the application name (e.g., "Game A") and its corresponding application version information (e.g., "Version B" or "v2.1.0"), ensuring accurate differentiation and localization of target applications in a testing environment with multiple versions coexisting, and avoiding deployment or execution errors due to identical names but different versions.

[0031] In actual application, the system provides clear operation entry to users through Web front-end page, and testers can complete task configuration in the browser. The front-end page displays the list of available application identifiers, the pre-set test case library, and the list of currently online terminals to be tested. Testers select the application identifier to be tested this time, such as "Application Identifier A", by checking or selecting by pulling down, and then select one or more test cases from the test case library, such as "Login Process Verification" and "Role Movement Stability Test". At the same time, one or more terminals to be tested in idle state are selected from the device list, such as "Device 001" and "Device 002". When all the options are configured, the "Submit Task" button is clicked, and the front-end organizes these selection items into a structured data object, usually encapsulated in JSON format, containing fields such as "app_version", "test_cases", and "target_devices". The data object is sent to the task receiving module of the server through HTTP or WebSocket protocol. After the server receives the request, it first performs data legality check, including checking whether the application identifier exists, whether the test case is valid, whether the terminal to be tested is online and not occupied, etc. After the verification, the task instruction is stored in the task queue or directly enters the scheduling process, waiting for further processing. The whole process realizes the visual configuration and standardized input of test tasks, ensuring that the instruction information is complete and accurate to be transmitted to the back-end of the system.

[0032] In a specific embodiment of the present application, the tester logs in to the Web platform and sees three main areas on the home page: the application identifier selection area lists "application identifier A" and "application identifier B"; the test case area displays multiple test cases such as "startup stability" and "UI response delay"; and the device list area displays three online devices "SteamDeck_01", "PC_Test_02", and "Switch_Sim_03". The tester successively checks "application identifier A", "startup stability", "SteamDeck_01", and "PC_Test_02", and clicks "submit". The front end packs these information into a JSON object, the content of which includes: "app_version": "A", "test_cases": ["startup_stability"], and "target_devices": ["SteamDeck_01", "PC_Test_02"]. The object is sent to the / api / task / create interface of the server through an HTTPS POST request. After receiving the object, the server parses the JSON, queries the database to confirm that "application identifier A" exists, the "startup_stability" test case has been defined, and "SteamDeck_01" and "PC_Test_02" are both in idle state. After the verification is passed, the task is written to the message queue, ready to be processed by the scheduling module.

[0033] Step 204: Distribute the test task to at least one terminal to be tested, wherein the test task is used to deploy and run the application corresponding to the application identifier, and execute the test case.

[0034] The distribution can be parallel distribution or serial distribution. Parallel distribution means that the server sends the test task to multiple terminals to be tested at the same time, rather than one by one. The test task contains the installation package information of the application identifier, the execution instruction of the test case, and the data collection requirement, which are used to guide the terminal to complete the whole process of deployment, running, and testing.

[0035] In practical applications, the server enters the task distribution stage immediately after receiving the test task instruction submitted by the user and completing the legality verification. The system first extracts the list of target terminals to be tested from the task instruction, and for each device in the list, the server independently establishes a communication connection channel. After the connection is established, the server pushes the test task data packet (such as application identifier, test case script, and collection configuration) to each terminal to be tested through a secure transmission protocol. The transmission process of the data packet is performed simultaneously among multiple devices without blocking each other. To ensure transmission reliability, the system can use an acknowledgement mechanism, and the terminal to be tested returns an acknowledgement signal after receiving the data packet, and the server records the distribution status. For unstable network or delayed device response, the system supports a retry mechanism to resend the task within a certain number of times to avoid task loss due to temporary failure. During the task distribution process, the server does not wait for the execution result of the previous device, but continuously pushes the task to all target devices to realize true parallel operation. After the distribution is completed, each terminal to be tested can independently start the deployment and execution process based on the local strategy without further intervention from the server, forming a decentralized execution mode.

[0036] In a specific embodiment of the present application, the server receives a test task instruction containing application identifier A, test case "start stability", and two terminals to be tested "device 001" and "device 002". The server simultaneously establishes SSH connections for "device 001" and "device 002". After the connection is established, the server pushes the compressed package containing the application identifier A installation package and the test script to the specified directory of the two devices through the rsync command. During the pushing process, the system monitors the transmission status, and if "device 001" does not return a reception confirmation within 3 seconds, the system automatically retries once. After both devices successfully receive the data packet, the server marks the task distribution as complete and does not wait for the device to start execution, immediately releasing resources to process the next task. After the two devices locally detect the arrival of the task packet, they automatically decompress and prepare the execution environment.

[0037] Further, the test task is distributed to at least one terminal to be tested, including: monitoring the working state of the at least one terminal to be tested; in the case that the target terminal to be tested is in an idle state, sending the test task to the target terminal to be tested, wherein the target terminal to be tested is any one of the at least one terminal to be tested; in the case that the target terminal to be tested is in a busy state, updating the test queue based on the terminal identifier of the target terminal to be tested and the test task.

[0038] Wherein, the working state includes "idle" (can receive new tasks) and "busy" (is executing tasks); the test queue is used to cache tasks to be executed, and is indexed by terminal identifier to realize queuing and waiting scheduling of tasks.

[0039] In practical applications, after receiving the test task instruction submitted by the user, the server starts the task distribution process. The system first extracts the target terminal list from the task instruction, and queries the current working state of each device in the list one by one. The state query is realized through a heartbeat mechanism or a state interface: the server sends a state request to the terminal under test, and the terminal returns an "idle" or "busy" status code, accompanied by the last active time and the current running task ID. For the target terminal under test that returns an "idle" state, the server immediately pushes the test task data packet to the device through a secure channel (such as SSH or HTTPS) to start the deployment process. For the target terminal under test that returns a "busy" state, the server does not immediately discard the task, but binds the task with the terminal identifier and writes it into the test queue. The test queue maintains a first-in, first-out task queue structure with the terminal identifier as the key. When a device completes the current task and reports an "idle" state, the server actively checks the test queue for pending tasks for the device, and if there are any, it immediately takes them out and pushes them, realizing automatic task continuation. The entire distribution process supports concurrent processing, and the state query and task sending of multiple devices are executed in parallel to ensure scheduling efficiency.

[0040] In a specific embodiment of the present application, the server receives a test task, and the target devices are "device 001" and "device 002". The system first sends a state query request to the two devices. Device 001 returns "idle", and the server immediately pushes the task package through the SSH channel. Device 002 returns "busy", and the server associates the task with the "device 002" identifier and writes it into the test queue. Three minutes later, device 002 completes the current task and sends an "idle" state notification to the server. After receiving the notification, the server queries the test queue and finds that there is a pending task, which is immediately taken out of the queue and pushed to device 002, ensuring that the task is not lost and is executed in order.

[0041] Based on this, through the state monitoring and queue management mechanism, the system realizes intelligent scheduling of task distribution, avoids resource conflicts, ensures automatic execution of tasks when the device is idle, and improves the accuracy of scheduling and the fault tolerance of the system.

[0042] Further, in the case where the target terminal under test is in an idle state, the test task is sent to the target terminal under test, including: when detecting that multiple terminals under test are in an idle state, grouping the terminals under test according to their device types; and distributing the test tasks to the terminals under test in the same device group in parallel.

[0043] Among them, the device type refers to the hardware or system classification of the terminal under test, such as a handheld device, a mobile device, a host device or a PC device, which is used to distinguish the running environment of different platforms; task grouping refers to grouping idle terminals with the same device type into a group as the basic unit for parallel task distribution.

[0044] In practical applications, the server initiates the task grouping and distribution process after confirming that multiple terminals under test are in an idle state. The system first obtains the device identifiers of all idle terminals and queries their device types through a pre-stored device information table. The device information table records the model, operating system, hardware configuration, and other attributes of each terminal. The server classifies idle terminals by device type based on the table. For example, "SteamDeck_01" and "SteamDeck_02" are classified into the "handheld device" group, and "Android_Phone_A" and "Android_Phone_B" are classified into the "mobile device" group. After grouping is complete, the system determines whether the current task supports the device type. If it does, the test task data packet is pushed to all idle terminals in the group simultaneously. The push process uses a parallel communication mechanism, and the sending task of each terminal is executed independently without blocking each other. The system supports priority scheduling by group, such as preferentially distributing resource-intensive test tasks to high-performance device groups or distributing compatibility test cases to specific platform groups. During distribution, the server continuously monitors the sending status, records successful and failed terminals, and ensures complete task coverage.

[0045] In a specific embodiment of the present application, the server detects four idle devices: two SteamDeck handhelds and two Android phones. The system queries the device information table and confirms that "SteamDeck_01" and "SteamDeck_02" belong to the "handheld device" type, and "Phone_A" and "Phone_B" belong to the "mobile device" type. The current test task is "handheld platform compatibility testing", which is only applicable to handheld devices. The system distributes the task in parallel to the two SteamDeck devices in the "handheld device" group through SSH, and pushes the task packet simultaneously. The two Android phones do not participate in this distribution due to type mismatch and remain in an idle state waiting for other tasks.

[0046] Based on this, by grouping by device type and distributing in parallel, the system realizes accurate placement and efficient execution of test tasks, ensures parallel testing of similar devices under the same conditions, and improves the comparability of test results and the rationality of resource utilization.

[0047] Further, the terminal under test is based on an open-source operating system; sending a test task to the target terminal under test includes: sending a secure remote connection instruction to the target terminal under test; controlling the target terminal under test to deploy an application corresponding to the application identifier through a command line interface of the open-source operating system; generating an application running test instruction and sending it to the target terminal under test to control the target terminal under test to run the application corresponding to the application identifier to execute the test case.

[0048] The open-source operating system refers to an operating system with open-source code, supporting custom modification and extension, such as a Linux distribution, having an open command line interface and rich system tools; and the secure remote connection instruction refers to establishing a secure communication channel with the terminal under test through an encryption protocol (such as SSH), to ensure the confidentiality and integrity of remote operation.

[0049] In actual application, the terminal under test is constructed based on a Linux open-source operating system, the system is pre-installed with an SSH server and configured with a password-free login key, to ensure that the server can be safely accessed. After the server determines that the target terminal under test is in an idle state, it first sends a secure remote connection instruction to the terminal under test, and establishes an encrypted communication channel through the SSH protocol. After the connection is established, the server uses the channel to send a series of command line instructions to the terminal under test, to control it to complete application deployment. The specific process includes: executing a directory creation command (such as mkdir) to establish an application installation path; synchronizing the installation package of the application identifier from the server to the local storage of the terminal under test through a file transfer command (such as scp or rsync); calling a system package manager (such as apt or dnf) or a decompression tool (such as tar) to complete decompression and dependency installation of the installation package; setting executable permissions and verifying the integrity of the main program file. After the deployment is completed, the server generates an application running test instruction, which contains a start command, running parameters and test case identifier, and sends it to the terminal under test through the same SSH channel. After receiving the instruction, the terminal under test executes the application start command (such as. / start.sh) in the command line environment, and loads the specified test case, to enter the automatic execution process. The entire process does not require manual intervention, and all operations are completed through scripted commands, to ensure that the execution process is repeatable and traceable.

[0050] In a specific embodiment of the application, the terminal under test is an operating system based on Debian Linux, pre-installed with an OpenSSH service and configured with public key authentication. The server connects the device through SSH, executes "mkdir / opt / test_app" to create an installation directory, uses the "rsync" command to synchronize "app_version_B.tar.gz" to the directory, then sends "tar -xzf app_version_B.tar.gz" to decompress the file, and executes "chmod +x start.sh" to set permissions. After the deployment is completed, the server generates a running instruction ". / start.sh --test-case=performance_01", and sends it to the terminal through SSH for execution, to start the application and run the specified test case.

[0051] Based on this, by using the command line capabilities of the open source operating system, the system realizes the remote automation control of the terminal under test, ensures the high controllability and consistency of the application deployment and test execution process, and provides a reliable technical foundation for large-scale automated testing.

[0052] Further, the application running test instruction is generated and sent to the target terminal under test, including: obtaining an application list file stored in the target terminal under test; parsing the application list file to determine the application identification information corresponding to the application identification; generating the corresponding application running test instruction according to the application identification information and the open source operating system, and sending the application running test instruction to the target terminal under test.

[0053] Wherein, the application list file refers to a configuration file recording the installed application information on the device, which is usually generated by the operating system or the application manager, and contains metadata such as application name, version number, installation path and start identification; the application identification information refers to a field used to uniquely identify an application instance, such as package name, application ID or executable file path; the application running test instruction refers to a complete command line instruction containing start command, parameter and environment configuration, which is used to start the specified application in the open source operating system and load the test case.

[0054] In practical application, before the server prepares to send the application running instruction to the target terminal under test, it first accesses the terminal file system through a secure remote connection channel (such as SSH), locates and obtains the application list file stored therein. The file is usually located in a system preset directory, such as “ / var / lib / app_manager / apps.json” or “~ / .config / app_list.conf”, and its format is JSON or INI, which records the detailed information of all installed applications. The server downloads the file to a local temporary buffer, and then performs parsing operation. The parsing process includes reading file content, building data structure, traversing application entries, and finding matching items according to the application identification specified in the task. For example, find the application entry with “version” field equal to “B”, and extract its “app_id” or “exec_path” as application identification information. After obtaining the identification, the server generates the corresponding running instruction in combination with the command line specification of the open source operating system. If the application identification is the package name, a protocol start command similar to “steam steam: / / run / 123456” is generated; if it is an executable path, a direct call command “ / opt / app_B / start.sh --test-mode” is generated. After the test case parameters are attached to the generated instruction, it is sent to the target terminal under test through the same remote connection channel for execution. The whole process does not need to pre-configure static path, and supports dynamic identification of different versions of application start mode.

[0055] In a specific embodiment of the present application, the server connects the target terminal under test through SSH, and obtains the "appmanifest_123456.acf" file located in the " / home / tester / .steam / steam / appmanifests / " directory. The file is an application list file generated by the Steam platform, which records the game ID, installation path and version information. The server parses the file and extracts "appid=123456" as the application identifier. In combination with the open source operating system environment, a start instruction "steamsteam: / / run / 123456 --skip-splash" is generated, and a test parameter "--test-case=launch_stability" is attached. The instruction is executed remotely through SSH to trigger the application startup process.

[0056] Based on this, by dynamically obtaining and parsing the application list file, the system realizes accurate identification of the target application identifier, avoids the maintenance cost brought by hard-coded paths, and improves the flexibility and adaptability of test instruction generation.

[0057] Step 206: Receive the test result data collected and reported by at least one terminal under test.

[0058] Among them, the test result data refers to various types of information generated by the terminal under test during the execution of the test task, including application running logs, performance monitoring data (such as CPU occupancy, memory usage, frame rate), screenshot or screen recording files, use case execution status (success / failure) and custom collection indicators; reporting refers to the transmission process of sending the locally generated data to the server's designated interface through the network protocol.

[0059] In practical applications, the server specifies the target address and communication protocol for data reporting of the measured terminal in the task distribution stage. When the measured terminal completes the test case execution, the data collection and reporting process is automatically triggered. The terminal first packages and compresses the locally generated log files, performance data records, screenshots, etc. to form a unified data package, and attaches meta information (such as task ID, device identification, execution timestamp). Subsequently, the data package is sent to the data receiving interface of the server through a pre-set secure transmission channel (such as HTTPS or SFTP). The server receiving module listens to the specified port, and once it receives the upload request, it immediately performs data integrity verification, such as verifying the file hash value and checking the validity of the meta information. After verification, the data package is stored in a distributed file system or database, and the task status is updated to "data reported". The system supports a breakpoint resume mechanism, and if the network is interrupted during reporting, the measured terminal can continue transmission from the breakpoint after recovery, avoiding repeated uploads. For large-scale data (such as long-time screen recording), the system can support fragmented upload, and the server automatically merges after receiving. After reporting is completed, the server can trigger subsequent processing procedures, such as automatically generating test reports or notifying users of task completion.

[0060] In a specific embodiment of the present application, two measured terminals "device 001" and "device 002" complete the test task, and each generates a log file, memory usage curve data, three key frame screenshots, and execution results (success / failure) locally, which are packaged into a tar.gz format file with the task ID "T20250916001" and device number in the file name. The two devices upload the data package to the / api / report / upload interface of the server through the HTTPS protocol. The server receiving module verifies the file signature and task ID for legality, and after confirming that there is no error, stores the file in the object storage system, and marks the "device 001" and "device 002" sub-tasks of the "T20250916001" task in the task management database as "data received". The system then starts the report generation service to read the reported data and generate a comprehensive test report.

[0061] Further, before receiving the test task instruction sent by the user operation interface, it further includes: obtaining a pre-recorded input operation record file, wherein the operation record file contains input operation data recorded in time sequence; generating a test case based on the input operation record file, wherein the test case is used to record the input corresponding operation in time sequence.

[0062] Among them, the input operation record file refers to the input event data captured by the system during the actual operation of the user and stored in time sequence, including key, click, swipe, joystick movement and other operations and their corresponding timestamps; the test case refers to a structured task unit containing executable operation sequences, used to restore user behavior in automated execution.

[0063] In practical applications, the system starts the use case generation process in advance before receiving the test task instruction sent by the user operation interface. First, the recorded input operation record file is obtained from the specified storage path or remote server. The file is usually generated by the test personnel when performing the target operation process on the real device, and the format is structured data (such as JSON or binary sequence), and each record contains the operation type (such as "KEY_DOWN", "MOUSE_MOVE"), operation parameters (such as key value, coordinates), and precise timestamp (such as "16:07:01.234"). After the system reads the file, the time sequence structure is parsed, and the operation flow is reconstructed in chronological order. Subsequently, the system encapsulates the parsed operation data as the execution instruction set of the test case, and each input operation is converted into the corresponding automated execution command. For example, "press the space bar" is mapped to the simulated input instruction, and "move to coordinates (100, 200)" is converted into the mouse or touch simulation command. The generated test case is stored in the test case library in a standard format, and is attached with meta information (such as use case name, recording device, application scenario) for subsequent task scheduling calls. This process supports batch processing of multiple record files, automatically generates multiple test cases, and significantly reduces the script development workload.

[0064] In a specific embodiment of the present application, the system obtains an input operation record file named "login_to_main_menu.record" from the storage server, which records the complete operation process from application startup to main interface loading completion, containing 327 input events with timestamps. The system parses the file, identifies key operation sequences such as "power key press", "user login input", "confirmation button click", and converts them into an automated test instruction set. Each instruction is marked with an execution time interval, and a test case named "automatic login process" is generated and stored in the test case library. Subsequent test tasks can directly select this use case without the need to rewrite scripts.

[0065] Based on this, by converting real operation records into executable test cases, the system realizes the automatic generation of test cases, reduces the cost of manual writing, ensures the high consistency of test behavior and real user operation, and improves the coverage and credibility of the test.

[0066] Further, before obtaining the pre-recorded input operation record file, it further includes: receiving a recording request sent by a user operation interface; recording input operation information of the terminal under test during recording; generating an input operation record file according to the time sequence of the input operation information and storing it.

[0067] The input operation record file refers to input event data captured by the system and stored in time sequence during actual operation of the user, including key, click, swipe, joystick movement and corresponding time stamp; the test case refers to a structured task unit containing executable operation sequence, used to restore user behavior in automatic execution.

[0068] In actual application, the system starts the case generation process in advance before receiving the test task instruction sent by the user operation interface. First, the recorded input operation record file is obtained from the specified storage path or remote server. The file is usually generated by the test personnel when performing the target operation process on the real device, and the format is structured data (such as JSON or binary sequence), each record contains operation type (such as "KEY_DOWN", "MOUSE_MOVE"), operation parameter (such as key value, coordinate) and accurate time stamp (such as "16:07:01.234"). After the system reads the file, the time sequence structure is parsed, and the operation flow is reconstructed in time sequence. Then, the system encapsulates the parsed operation data as the execution instruction set of the test case, and each input operation is converted into the corresponding automatic execution command. For example, "press the space bar" is mapped to the simulated input instruction, and "move to coordinate (100, 200)" is converted to the mouse or touch simulation command. The generated test case is stored in the test case library in a standard format, and is attached with meta information (such as case name, recording device, application scenario) for subsequent task scheduling call. The process supports batch processing of multiple record files, automatically generates multiple test cases, and significantly reduces the script development workload.

[0069] In a specific embodiment of the application, the system obtains an input operation record file named "login_to_main_menu.record" from the storage server, which records the complete operation process from application startup to main interface loading completion, containing 327 input events with time stamps. The system parses the file, identifies the key operation sequence such as "power key press", "user login input" and "confirmation button click", and converts it into an automatic test instruction set. Each instruction is marked with an execution time interval, a test case named "automatic login process" is generated, and stored in the test case library. The subsequent test task can directly select the case without re-writing the script.

[0070] Therefore, by converting real operation records into executable test cases, the system realizes the automatic generation of test cases, reduces the cost of manual writing, ensures the high consistency of test behavior and real user operation, and improves the coverage and credibility of the test.

[0071] Further, after receiving the test result data collected and reported by the at least one terminal under test, the method further comprises: performing format uniform processing on the test result data; storing the processed test result data and the corresponding test task in association; generating a test execution report and sending the test execution report to the user operation interface.

[0072] The format uniform processing refers to converting original data (such as log text, performance indicators, screenshots, and screen recordings) from different terminals into a unified structured or semi-structured format within the system, facilitating subsequent analysis and parsing. The association storage refers to establishing a mapping relationship between the processed test data and the original test task (such as task ID, application identifier, test case, and terminal under test), ensuring data traceability. The test execution report refers to a comprehensive document generated based on the processed data, including task execution overview, result statistics, key indicator charts, and exception details, used to visually display the test completion to the user.

[0073] In actual application, after receiving the test result data reported by the at least one terminal under test, the server starts a data post-processing process. The system first decompresses and classifies the original data packet, identifying the log files, performance data files, and screenshot images contained therein. Subsequently, the system performs format standardization operations on different types of data: for text logs, the system extracts timestamps, log levels, and message contents, converts them into JSON format entries, and sorts them by time; for performance data (such as CPU, memory, and frame rate), the system uniformly samples them into time series data with fixed time intervals and normalizes the units (such as FPS, MB, and %); for image data, the system renames the files and embeds meta information (such as device model, test step, and timestamp), and stores them in a standard image format. After format processing, the system parses the task ID carried in the data packet, finds the corresponding test task record in the task management database, and obtains the application identifier, test case list, target device, and other context information of the task.

[0074] The system establishes a bidirectional association between the processed data and the task, writes the data into a distributed database or object storage system, and supports quick retrieval by task, device, and version. Subsequently, the system calls a report generation engine to extract key indicators such as test case pass rate, average frame rate, maximum memory usage, and error log quantity from the associated data, and generates a test execution report based on a preset template. The report is output in HTML web page or PDF format, containing status cards, trend charts, failed test case lists, and screenshot thumbnails. After the report is generated, the system pushes the report generation completion notification and access link to the user operation interface through WebSocket or message queue, allowing the tester to view the report in real time.

[0075] In a specific embodiment of the application, the server receives test result data packets reported by two terminals "device 001" and "device 002". The system converts the log of "device 001" into structured JSON, extracts its frame rate data and unifies it as one per second; the screenshot file of "device 002" is renamed as "device002_step3.png" and additional meta information is attached. After processing, the system queries the database according to the task ID "T20250916005" to obtain the corresponding "application identifier B" and "start stability test" use case, and stores all data associated with the task. The report generation module extracts the average frame rate of the two devices (58FPS and 55FPS respectively), the memory peak (850MB and 920MB) and the error log summary, generates an HTML report containing comparison charts, and pushes a "test report generated" message to the user through the front-end notification center.

[0076] Based on this, through format unification and associated storage, the system realizes standardized management and efficient traceability of test data, combined with automatic report generation, improves the completeness and readability of test feedback, and provides a reliable basis for quality evaluation.

[0077] In the automated testing system, different platform devices (such as SteamDeck, iOS, PS5) have significant differences in system architecture, running environment and deployment method. If a unified deployment strategy is adopted, it is easy to cause installation failure or abnormal execution. To this end, further, before distributing the test task to at least one terminal under test, it further includes: determining the device platform type of the target terminal under test, wherein the target terminal under test is any one of the at least one terminal under test; determining the corresponding environment configuration scheme according to the device platform type; generating the deployment instruction corresponding to the device platform type based on the selected environment configuration scheme; and encapsulating the deployment instruction into the test task.

[0078] Among them, the device platform type refers to the operating system or hardware platform category to which the terminal under test belongs, such as Linux-based handheld console, Android mobile device, Windows PC or dedicated host system; the environment configuration scheme is a set of deployment parameters predefined for a specific platform, including dependency library list, permission configuration, startup method and file path specification; the deployment instruction is an executable command sequence generated based on the scheme, used to guide the terminal to complete application installation and environment preparation.

[0079] In practical applications, the server first obtains the equipment meta information of the target terminal to be tested before distributing the test task to at least one terminal to be tested, and extracts the equipment platform type from the equipment meta information. The information can come from the attributes reported during equipment registration or be obtained by querying the equipment management database through the equipment ID. After determining the platform type, the system retrieves the environment configuration scheme matched with the platform type from the configuration library. For example, if the target equipment is SteamDeck (based on Linux), the scheme including rsync transmission, tar decompression, chmod permission setting, and Steam protocol startup is selected; if the target equipment is an Android device, the scheme including ADB installation of APK, permission granting, and Activity startup is selected. Based on the selected scheme, the system dynamically generates corresponding deployment instructions, such as Shell commands, ADB commands, or RPC call sequences. These instructions are structured and packaged as part of the test task, together with application version, test case, and other information. When the task is distributed, the deployment instructions are sent to the target terminal to be tested together with the task data for local execution environment preparation. The entire process realizes a closed loop of “platform identification—scheme matching—instruction generation—task packaging”, ensuring that the deployment logic is strictly aligned with the equipment characteristics.

[0080] For the step of “determining the corresponding environment configuration scheme according to the equipment platform type”, one optional way is a static mapping table mechanism, that is, a key-value pair mapping of platform type and configuration scheme is established in advance, which is suitable for scenarios with fixed platform type and stable scheme. Another optional implementation way is a dynamic strategy engine, that is, configuration parameters are combined in real time according to detailed equipment attributes (such as OS version and CPU architecture), which is suitable for scenarios with serious platform fragmentation and requiring fine-grained adaptation.

[0081] In a specific embodiment of the application, the server prepares to distribute a test task to “device 001”, first queries the equipment registration table, and confirms that the equipment platform type of the device is “SteamDeck (Linux)”. The system loads the corresponding scheme from the configuration library, including the steps of “synchronizing the installation package using rsync”, “decompressing to / home / steam / app”, “setting executable permissions”, and “starting through the steam: / / protocol”. According to the above steps, the deployment instruction sequence is generated: ["rsync -av app_vB.tar.gz / home / steam / ", "tar -xzf app_vB.tar.gz", "chmod +x start.sh", "steam steam: / / run / 123456"]. These instructions are packaged into the “deployment_commands” field of the test task JSON object and sent to device 001 together with the task.

[0082] Therefore, by the platform type driven deployment instruction generation mechanism, the system realizes adaptive adaptation of test tasks to heterogeneous devices, avoids deployment failure caused by platform differences, and improves the reliability and universality of cross-platform automated testing.

[0083] The application is applied to the test task scheduling method, centralized management and parallel distribution of test tasks are realized by receiving user instructions and unified scheduling, manual intervention is reduced by automatic deployment, running and data reporting, process consistency is guaranteed, execution efficiency is improved, multi-device collaborative testing is realized, test coverage and reliability are significantly improved, and human operation errors are reduced.

[0084] Referring to Figure 3 , Figure 3 is a flowchart of another test task scheduling method provided by an embodiment of the application, and specifically includes the following steps.

[0085] Step 302: receiving a test task distributed by a server, wherein the test task contains an application identifier and a test case.

[0086] The test task refers to a structured instruction package generated and issued by the server, containing an application identifier (such as a version number or an installation package path) and a test case identifier (such as a case number or a script name); receiving refers to the process of the terminal under test obtaining the task data from the server through network communication, ensuring accurate transmission and reliable acquisition of task instructions.

[0087] In actual application, the terminal under test continuously runs a client daemon process, which listens to task push messages from the server. When the server sends a test task through a secure channel (such as SSH, WebSocket or HTTPS), the client process receives the data packet, first performs decryption and integrity check to prevent data tampering or damage. After passing the check, the task package content is parsed, and the application identifier information (such as “application identifier A”) and the test case list (such as “case 001, case 002”) are extracted. The parsing result is written into a local task configuration file for subsequent execution module reading. The system supports multiple task receiving modes: in the active push mode, the server directly pushes the task to the specified port of the terminal, and the terminal responds to the confirmation immediately after receiving; in the polling mode, the terminal periodically queries the server whether there is a new task, and if there is, it pulls and confirms the reception. After the task receiving is completed, the terminal updates its state to “task received, ready to execute”, and can send a state synchronization message to the server to ensure that the task scheduling system masters the real-time state of the device. The whole receiving process does not need manual intervention, ensuring that the task information is accurately and timely transmitted to the execution environment.

[0088] In a specific embodiment of the application, a SteamDeck device is used as the terminal under test. The client daemon running on the device connects to the server task center through a WebSocket. When the server distributes a test task containing the application identifier "B" and the test case "performance test_01", the task is sent to the device in JSON format through the established WebSocket channel. After receiving the data, the device verifies the message signature using the pre-shared key to confirm the legitimacy of the task source. Then it parses the JSON content, extracts "app_version": "B" and "test_cases": ["performance_test_01"], and writes these information to the local configuration file " / config / current_task.json". After receiving the task, the device returns a "RECEIVED" status code to the server and updates its own status to "task ready" to wait for the subsequent deployment process to start.

[0089] Step 304: Deploy the application corresponding to the application identifier according to the application identifier.

[0090] Wherein, the application identifier refers to a unique identifier used to identify the software iteration state, such as version number or build number; deployment refers to the whole process of installing the specified version of the application package on the terminal under test, including decompression, installation, permission configuration and dependency handling, so that it has an executable state.

[0091] In actual application, after receiving the task instruction containing the application identifier, the terminal under test immediately starts the deployment process. The system first determines the application installation directory according to the local configuration and checks whether the same version of the application exists in the directory. If it exists and the verification is passed, it skips the installation step and directly enters the preparation state; if it does not exist or the version does not match, it obtains the installation package of the corresponding version from the preset path or remote server. The installation package acquisition method can include reading from the cache directory pushed by the server, downloading through HTTP / HTTPS or using rsync synchronization. After obtaining the installation package, the system performs the corresponding installation operation according to the application type: for compressed package format (such as tar.gz), it performs decompression and sets the execution permission; for package management format (such as deb or rpm), it calls the system package manager to install. During the installation process, the system automatically handles the dependent libraries, such as downloading and installing the required runtime environment through the package management tool. After the deployment is completed, the system verifies whether the application main program exists and whether the integrity of the key files meets the standard, and records the deployment result to the local log. If the deployment fails, the system can try to obtain the installation package from the backup source or perform cleaning and retry to ensure the deployment success rate.

[0092] In a specific embodiment of the application, a terminal under test receives a task requiring the deployment of "application identifier B". The terminal checks the local " / apps / " directory and does not find the "version_B" folder. The system then synchronizes with the server through rsync to obtain the "app_version_B.tar.gz" installation package and stores it in the " / tmp / " directory. Then the decompression command is executed to release the file to the " / apps / version_B / " path, and the main program file is set to executable permission. Next, the system reads the dependency list file in the same directory and calls the package manager to automatically install the missing Python and OpenCV libraries. After deployment is complete, the system checks whether " / apps / version_B / start.sh" exists, calculates the hash value of the installation package and compares it with the expected value, confirms that there is no error, updates the deployment status to "ready", and records the timestamp and version information to the local log file.

[0093] Step 306: Run the application and run the test case.

[0094] Among them, running the application means starting the deployed application program to enter an interactive running state; running the test case means executing the test logic according to the predefined operation sequence or automated script during application running, including input simulation, state checking and process verification.

[0095] In actual application, after the terminal under test completes application deployment and confirms that the environment is ready, it automatically triggers the application startup process. The system calls the startup script or executable file of the application through the command line, passes in the necessary startup parameters (such as headless mode, debug switch or configuration file path), and ensures that the application runs in the mode required for testing. After the application starts, the system monitors its process state, confirms that the application has entered a stable running state by checking the process ID, port occupation or log output. Once the application is ready, the terminal immediately loads the test case script associated with the current task. The script is usually written in a configuration file or a lightweight scripting language (such as Python or Lua) and contains instructions such as operation sequence, waiting time, assertion condition, etc. The system executes each step of the script in sequence, such as simulating user input (key press, click), calling remote interface (RPC), reading application state or verifying interface elements. During execution, the system dynamically adjusts the waiting time according to the actual response to avoid operation timeout or omission due to device performance differences. After the test case is executed, the system summarizes the execution results, marks success or failure, and generates an execution log for subsequent analysis.

[0096] In a specific embodiment of the present application, after the terminal being tested completes the deployment of "application identifier B", it executes the start script " / apps / version_B / start.sh --headless" to start the application in a non-interface mode. The system confirms through polling the process list that the main process "app_core" is running and the memory occupation is stable. Subsequently, the test script located at " / test_cases / performance_test_01.py" is loaded, which defines a series of operations: first, simulate clicking the "start game" button through ADB, and wait for 3 seconds; then, call the RPC interface "setPlayerLevel(50)" to set the character level; then, send 10 consecutive jump instructions, with an interval of 500 milliseconds each time; finally, verify whether the character position meets the expectation. The system executes each step in the order of the script, records the execution time and result of each step. When all operations are completed, the script returns a "PASS" state, and the terminal writes the execution log to a local file.

[0097] Step 308: Collect the result data during the test process and report to the server.

[0098] Among them, the result data refers to various observable information generated during the test execution process, including application running log, system performance indicators (such as CPU, memory, frame rate), interface screenshot, exception stack, use case execution status and custom monitoring data; reporting refers to the process of transmitting the collected data to the server through the network to the specified receiving endpoint, ensuring timely data collection.

[0099] In actual application, the terminal being tested starts the data collection module during the test task execution phase. This module runs in parallel with the application running and use case execution process, and monitors system resource usage in real time. It reads CPU occupancy, memory usage, disk I / O and network bandwidth performance data regularly through system interfaces, and records them in time series format. At the same time, the log output of the application is redirected to a specified file, and the collection module listens to the log stream in real time, extracts key events (such as startup completion, error throwing, use case passing) and marks the timestamp. For graphical testing scenarios, the system captures screen images at a preset frequency (such as every 5 seconds), or actively captures interface states at key operation nodes (such as use case start, failure point). All collected data is stored in a structured file set in the local temporary directory according to task ID and device identifier. When the test use case is executed or the reporting trigger condition (such as timed reporting, task completion) is reached, the terminal starts the reporting process. The system packages the collected data into a compressed file and sends it to the server's preset receiving interface through a secure transmission protocol (such as HTTPS or SFTP). During transmission, it supports breakpoint resume and data verification to ensure integrity. After reporting is completed, local data copies can be retained or cleaned up according to the strategy to save storage space.

[0100] In a specific embodiment of the application, the terminal being tested starts a data collection module while executing the "Performance Stress Test_01" use case. The module reads system performance data once per second, records CPU and memory usage curves; listens to application log files, capturing all "ERROR" level logs; and intercepts three screen images at the beginning, intermediate checkpoint, and end of the use case. After the test is completed, the system packages the performance data files, log fragments, and screenshots into "report_T20250916001_device001.tar.gz", and uploads them to the server " / api / report / upload" interface through an HTTPS POST request. After receiving the files, the server verifies the file hash values, stores them if no errors are found, and triggers the report generation process.

[0101] When applied to the test task scheduling method, the terminal being tested receives the test task issued by the server, automatically completes application deployment, startup, and use case execution, realizes unattended test process, parses the application identifier and installs it through an automated script or tool, ensures environment consistency, accurately executes test operations during running, collects log and performance data in real time, and reports them to the server, reduces manual intervention throughout the process, avoids operation errors, improves test stability and reproducibility, supports parallel execution of multiple devices, significantly improves test efficiency and coverage, and guarantees the accuracy and traceability of test results.

[0102] The following describes the test task scheduling method provided by the application in combination with the accompanying Figure 4 The test task scheduling method provided by the application is further described below with the application of the test task scheduling method in game automated testing as an example. In the application, Figure 4 FIG. 1 shows a process flow diagram of a test task scheduling method according to an embodiment of the application, which specifically includes the following steps.

[0103] Step 402: Configure a game account and a system account on the device.

[0104] Specifically, a game account and a system account are configured on the device. For example, a test-specific Steam account (such as "test_user") and a system login account (such as "steam_test") are pre-set to ensure that the automated script can automatically log in and run the game, avoiding manual input of credentials each time.

[0105] Step 404: Select the game installation package to be executed, the device to be run, and the use case to be executed through the Web front end, and select different data types to be collected according to different requirements.

[0106] Specifically, the game version A installation package to be executed, the device to be run, and the use case to be executed are selected through the Web front end, and the data types such as frame rate and memory consumption can be selected according to requirements. For example, the tester checks "game version A installation package", specifies "SteamDeck device A", selects "character jumping test case", and checks the data collection option.

[0107] Step 406: The server receives the execution instruction of the Web front end, and checks whether the current device is in an idle state.

[0108] Specifically, after the server receives the Web front end instruction, the device state is checked. For example, the database is queried to find that the state of device A is "idle", and the task is immediately prepared for distribution.

[0109] Step 408: If the device is in a busy state, the server will queue the task for processing and send it after the previous task is executed.

[0110] Specifically, if the device is in a busy state, the server will queue the task. For example, device A is running a game version B test, and the newly submitted game version A task is added to the queue, waiting for the current test to complete.

[0111] Step 410: If it is idle, send the task to the device to be run.

[0112] Specifically, if the device is idle, the server sends the task to the device. For example, the server confirms that device A is idle, and sends an instruction package (including the game version A installation path and the test case) through a secure channel.

[0113] Step 412: After receiving the task, the client performs a series of environment deployment, downloads and installs the game, and downloads the required tools.

[0114] Specifically, the client receives the task and performs environment deployment. For example, device A automatically downloads the game version A installation package to the local cache and installs the Python dependency library (such as "pip install opencv").

[0115] Step 414: Use rsync to push files to the game console to install games and pull game logs, etc.

[0116] Specifically, use rsync to push files to install games. For example, use rsync to synchronize the game version A installation package to the " / home / steam / game_versionA" directory of the SteamDeck.

[0117] Step 416: Obtain the game ID in the game library according to the record file under the user directory.

[0118] Specifically, the game ID is obtained according to the user directory record file. For example, the Steam user directory file is parsed to extract the game ID "123456" for subsequent startup.

[0119] Step 418: ssh remotely connects the game machine and starts the game using the control command according to the game ID.

[0120] Specifically, ssh remotely connects and starts the game. For example, the "steam steam: / / run / 123456" command is executed to automatically start the game version A.

[0121] Step 420: Register UE4 input mapping listener to obtain player input operation records.

[0122] Specifically, register UE4 input mapping listener. For example, register a listener in the engine to capture player key presses (such as "press W key to move") and mouse events.

[0123] Step 422: Repeat registration of UE4 input mapping listener.

[0124] Specifically, the input listening mechanism is repeatedly registered to ensure that all operations (such as jumping and attacking) are captured completely.

[0125] Step 424: Start recording player input, character information, and camera information frame by frame and generate a record file.

[0126] Specifically, start recording frame by frame. For example, capture input instructions (such as "press space to jump"), character coordinates, and camera angles every frame to generate a "rec_001.dat" file.

[0127] Step 426: Use case execution & data collection: when deployed, start executing the specified use case and start the data collection tool.

[0128] Specifically, execute the use case and start data collection. For example, run the "character movement test case" and start the frame rate monitoring tool to collect real-time data.

[0129] Step 428: Frame-by-frame playback according to the record file, frame-by-frame playback for input, and other information playback according to time interpolation.

[0130] Specifically, frame-by-frame playback according to the record file. For example, execute input instructions in the order of the record file, and the character position is smoothly transitioned through linear interpolation.

[0131] Step 430: Use RPC scheme to call in-game functions for automated testing.

[0132] Specifically, in-game functions are invoked using RPC. For example, the character's health is automatically set by invoking the API "setPlayerHealth(50)" through RPC.

[0133] Step 432: After the use case is executed, the collected data is reported to the platform for display.

[0134] Specifically, the data is reported after the use case is executed. For example, frame rate data and error logs are packaged and uploaded to the Web platform to generate a visual report.

[0135] Step 434: After all tasks are executed, the device state returns to the idle state, waiting for the server to assign new tasks.

[0136] Specifically, the device returns to the idle state after the task is completed. For example, device A cleans up temporary files and updates the status to "idle" to wait for new tasks.

[0137] Step 436: The server receives the test result data collected and reported by the at least one terminal under test.

[0138] Specifically, the server receives the test result data. For example, it receives the "success / failure status" and "average frame rate 60FPS" data reported by device A.

[0139] The above steps 402-436 are applied to build an automated distributed testing system, which supports unified management of multiple platform devices (such as SteamDeck, mobile devices, and host computers), implements application installation, startup, file transfer, and script execution, significantly reduces manual intervention and script development costs; for fixed testing processes, code writing is eliminated, ensuring consistent test results for different performance devices; through intelligent data collection and flexible configuration, non-professionals can easily perform testing tasks, replacing repetitive manual operations, reducing human error rates, improving testing efficiency and coverage, and helping teams focus on core problem analysis and optimization.

[0140] Corresponding to the above method embodiments, the present application also provides test task scheduling device embodiments, Figure 5 is a structural diagram of a test task scheduling device provided by an embodiment of the present application. As shown in Figure 5 The device comprises: A first receiving module 502 configured to receive a test task instruction sent by a user operation interface, wherein the test task instruction contains a selected application identifier, a test case, and at least one terminal under test; A distribution module 504 configured to distribute the test task to the at least one terminal under test, wherein the test task is used to deploy and run the application corresponding to the application identifier and execute the test case; The second receiving module 506 is configured to receive the test result data collected and reported by the at least one terminal under test.

[0141] Optionally, the distribution module 504 is further configured to monitor the working state of the at least one terminal under test; send a test task to a target terminal under test in a case where the target terminal under test is in an idle state, the target terminal under test being any one of the at least one terminal under test; and update the test queue based on the terminal identifier of the target terminal under test and the test task in a case where the target terminal under test is in a busy state.

[0142] Optionally, the distribution module 504 is further configured to, when detecting that a plurality of terminals under test are in an idle state, group the test tasks according to the device types of the plurality of terminals under test; and distribute the test tasks to the terminals under test in the same device group.

[0143] Optionally, a secure remote connection instruction is sent to the target terminal under test; the target terminal under test is controlled to deploy an application corresponding to the application identifier through a command line interface of the open source operating system; an application running test instruction is generated and sent to the target terminal under test, so as to control the target terminal under test to run the application corresponding to the application identifier to execute the test case.

[0144] Optionally, an application list file stored in the target terminal under test is obtained; the application list file is parsed to determine the application identifier information corresponding to the application identifier; and the application running test instruction corresponding to the application identifier information and the open source operating system is generated and sent to the target terminal under test.

[0145] Optionally, the test task scheduling device further comprises a recording module configured to obtain a pre-recorded input operation record file, wherein the operation record file contains input operation data recorded in time sequence; and generate a test case based on the input operation record file, wherein the test case is used to record the input operation in time sequence.

[0146] Optionally, the recording module is further configured to receive a recording request sent by the user operation interface; record the input operation information of the terminal under test during the recording; and generate the input operation record file in time sequence based on the input operation information and store the input operation record file.

[0147] Optionally, the test task scheduling device further comprises a generating module configured to perform format uniformity processing on the test result data; store the processed test result data and the corresponding test task in association; generate a test execution report and send the test execution report to the user operation interface.

[0148] The test task scheduling device is applied to the test task scheduling device, centralized management and parallel distribution of test tasks are realized through receiving user instructions and unified scheduling, manual intervention is reduced through automatic deployment, operation and data reporting, process consistency is guaranteed, execution efficiency is improved, multi-device collaborative testing is realized, test coverage and reliability are significantly improved, and human operation errors are reduced.

[0149] Figure 6 is a structural schematic diagram of another test task scheduling device provided by an embodiment of the application. As shown in Figure 6 the device comprises: A third receiving module 602 is configured to receive a test task distributed by a server, wherein the task contains an application identifier and a test case. A deployment module 604 is configured to deploy an application corresponding to the application identifier according to the application identifier. An operation module 606 is configured to run the application and run the test case. A collection module 608 is configured to collect result data in a test process and report to the server.

[0150] The test task scheduling device is applied to the test task scheduling device, the measured terminal receives the test task distributed by the server, automatically completes application deployment, startup and case execution, realizes unattended test process, parses the application identifier through an automatic script or tool and installs, ensures environment consistency, accurately executes test operation in a running process, collects log, performance and other data in real time and reports to the server, reduces manual intervention in the whole process, avoids operation errors, improves test stability and reproducibility, supports multi-device parallel execution, significantly improves test efficiency and coverage, and guarantees accuracy and traceability of test results.

[0151] The above is a schematic scheme of a test task scheduling device of the embodiment. It should be noted that the technical scheme of the test task scheduling device and the technical scheme of the test task scheduling method described above belong to the same concept, and the technical scheme of the test task scheduling device is not described in detail. Details can be referred to the description of the technical scheme of the test task scheduling method.

[0152] Figure 7 A structural block diagram of a computing device 700 provided by an embodiment of the application is shown. The components of the computing device 700 include but are not limited to a memory 710 and a processor 720. The processor 720 is connected with the memory 710 through a bus 730, and a database 750 is used to save data.

[0153] The computing device 700 also includes an access device 740 that enables the computing device 700 to communicate via one or more networks 760. Examples of such networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or combinations of such networks, such as the Internet. The access device 740 can include one or more of any type of network interface (for example, a network interface card (NIC)) such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC).

[0154] In one embodiment of the present application, the above-mentioned components of the computing device 700, as well as other components not shown in FIG. 7, can be connected to each other by a bus. It should be understood that Figure 7 the components of the computing device 700 can be connected to each other by other means, for example, through a series or parallel connection, a memory-mapped I / O, a stand-alone, or a dedicated operation mode. Figure 7 The computing device structure diagram shown is only for the purpose of example, and is not a limitation on the scope of the present application. Those skilled in the art can add or replace other components as needed.

[0155] The computing device 700 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (for example, a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (for example, a smartphone), a wearable computing device (for example, a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or a personal computer (PC). The computing device 700 can also be a mobile or stationary server.

[0156] The processor 720 is configured to execute computer program / instructions that implement the steps of the above-mentioned test task scheduling method when executed by the processor.

[0157] The various embodiments in the present application are described in a progressive manner, and the same or similar parts among the various embodiments can be referred to each other. Each embodiment focuses on the difference from other embodiments. In particular, the computing device embodiment is described simply because it is basically similar to the test task scheduling method embodiment, and the relevant part can be referred to the description of the test task scheduling method embodiment.

[0158] An embodiment of the present application further provides a computer readable storage medium storing computer programs / instructions, which are executed by a processor to realize the steps of the test task scheduling method.

[0159] The various embodiments in the present application are described in a progressive manner, and the same or similar parts among the various embodiments can be referred to each other. Each embodiment focuses on the difference from other embodiments. In particular, the computer readable storage medium embodiment is described simply because it is basically similar to the test task scheduling method embodiment, and the relevant part can be referred to the description of the test task scheduling method embodiment.

[0160] An embodiment of the present application further provides a computer program product, which includes computer programs / instructions, which are executed by a processor to realize the steps of the test task scheduling method.

[0161] The above is a schematic scheme of the computer program product of the embodiment. It should be noted that the technical scheme of the computer program product and the technical scheme of the test task scheduling method belong to the same concept, and the details of the technical scheme of the computer program product which are not described in detail can be referred to the description of the technical scheme of the test task scheduling method.

[0162] The above describes a specific embodiment of the present application. Other embodiments are within the scope of the appended claims. In some cases, the acts or steps recited in the claims can be performed in a different order than the order in which they are recited and still accomplish desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.

[0163] The computer readable medium can include any entity or apparatus capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, software distribution medium, etc. It should be noted that the computer readable medium can include appropriate additions or subtractions according to the requirements of patent practice. For example, according to the patent practice in some regions, the computer readable medium does not include electrical carrier signals and telecommunication signals.

[0164] It should be noted that, for the foregoing method embodiments, in order to facilitate description, each is described as a combination of a series of acts, but those skilled in the art should appreciate that the embodiments of the present application are not limited by the order of the described acts, because according to the embodiments of the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should appreciate that the embodiments described in the specification are all preferred embodiments, and the acts and modules involved are not necessarily essential to the embodiments of the present application.

[0165] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0166] The preferred embodiments of the present application disclosed above are only used to help explain the present application. The alternative embodiments do not describe all the details and do not limit the present application to the specific embodiments described. Obviously, according to the content of the embodiments of the present application, many modifications and changes can be made. The present application selects and describes these embodiments in order to better explain the principles and practical applications of the embodiments of the present application, so that those skilled in the art can well understand and utilize the present application. The present application is limited only by the claims and their full scope and equivalents.

Claims

1. A test task scheduling method, characterized in that, Applied to the server side, including: Receive test task instructions sent by the user interface, wherein the test task instructions include the selected application identifier, test cases and at least one terminal under test; A test task is distributed to the at least one terminal under test, wherein the test task is used to deploy and run the application corresponding to the application identifier and execute the test cases; Receive test result data collected and reported by at least one of the tested terminals.

2. The method according to claim 1, characterized in that, The distribution of test tasks to the at least one terminal under test includes: Monitor the working status of at least one of the tested terminals; When the target terminal under test is in an idle state, a test task is sent to the target terminal under test, wherein the target terminal under test is any one of the at least one terminal under test; When the target terminal under test is in a busy state, the test queue is updated based on the terminal identifier of the target terminal under test and the test task.

3. The method according to claim 2, characterized in that, The step of sending a test task to the target terminal under test when the target terminal under test is in an idle state includes: When multiple terminals under test are detected to be in an idle state, tasks are grouped according to the device type of the multiple terminals under test; Test tasks are distributed in parallel to the terminals under test within the same device group.

4. The method according to claim 2, characterized in that, The terminal under test is built on an open-source operating system; sending the test task to the target terminal under test includes: Send a secure remote connection command to the target terminal under test; Control the target terminal under test to deploy the application corresponding to the application identifier through the command line interface of the open source operating system; The system generates application run test instructions and sends them to the target terminal under test to control the target terminal under test to run the application corresponding to the application identifier and execute the test cases.

5. The method according to claim 4, characterized in that, The process of generating application run test commands and sending them to the target terminal under test includes: Obtain the application list file stored in the target terminal under test; Parse the application list file to determine the application identifier information corresponding to the application identifier; Based on the application identification information and the open-source operating system, a corresponding application run test command is generated and sent to the target terminal under test.

6. The method according to claim 1, characterized in that, Before receiving the test task instruction sent by the user interface, the method further includes: Obtain a pre-recorded input operation log file, wherein the operation log file contains input operation data recorded in a time sequence; Test cases are generated based on the input operation record file, wherein the test cases are used to record the operations corresponding to the input according to the time series.

7. The method according to claim 6, characterized in that, Before obtaining the pre-recorded input operation log file, the method further includes: Receive recording requests sent from the user interface; Record the input operation information of the terminal under test during the recording period; The input operation information is used to generate an input operation record file according to the time sequence and then stored.

8. The method according to claim 1, characterized in that, After receiving the test result data collected and reported by the at least one tested terminal, the method further includes: The test result data is formatted uniformly. The processed test results data are associated with and stored with the corresponding test tasks; Generate a test execution report and send it to the user interface.

9. The method according to claim 1, characterized in that, Before distributing the test task to the at least one terminal under test, the method further includes: Determine the device platform type of the target terminal under test, wherein the target terminal under test is any one of the at least one terminal under test; Determine the corresponding environment configuration scheme based on the device platform type; Based on the selected environment configuration scheme, generate deployment instructions corresponding to the device platform type; The deployment instructions are encapsulated into a test task.

10. A test task scheduling method, characterized in that, Applied to the terminal under test, including: Receive test tasks distributed by the server, wherein the test tasks include application identifiers and test cases; Deploy the application corresponding to the application identifier according to the application identifier; Run the application and run the test cases; Collect the results data during the test and report them to the server.

11. A test task scheduling device, characterized in that, Applied to the server side, including: The first receiving module is configured to receive test task instructions sent by the user interface, wherein the test task instructions include a selected application identifier, test cases and at least one terminal under test. The distribution module is configured to distribute test tasks to the at least one terminal under test, wherein the test tasks are used to deploy and run the application corresponding to the application identifier and execute the test cases; The second receiving module is configured to receive test result data collected and reported by the at least one tested terminal.

12. A test task scheduling device, characterized in that, Applied to the terminal under test, including: The third receiving module is configured to receive test tasks distributed by the server, wherein the task includes an application identifier and test cases; The deployment module is configured to deploy the application corresponding to the application identifier based on the application identifier; The runtime module is configured to run the application and the test cases; The data acquisition module is configured to collect the result data during the test process and report it to the server.

13. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the test task scheduling method according to any one of claims 1-10.

14. A computer-readable storage medium, characterized in that, It stores a computer program / instruction that, when executed by a processor, implements the steps of the test task scheduling method according to any one of claims 1-10.

15. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the steps of the test task scheduling method according to any one of claims 1-10.

Images