A GoCron-based scheduled inspection task system and method

Abstract

This invention discloses a gocron-based scheduled inspection task system and method, belonging to the field of automated inspection technology. The technical problem it addresses is how to coordinate devices and actuators to achieve scheduled inspections and send execution result email reports. The system includes a scheduled task manager, a remote host, execution devices, a scheduled task scheduler, a scheduled task scheduling center, task executors, and a task log database. The scheduled task scheduler is used to schedule task commands and execution devices. The task executors write the execution results of each test case to the corresponding execution report and aggregate all execution reports for all test cases to obtain an aggregate report. The scheduled task scheduling center stores the execution results of each test case, the storage path of the aggregate report, and the execution time of the task command as task log data in the task log database, and uses this data to send task execution result notifications to users via email.

Description

Technical Field

[0001] This invention relates to the field of automated inspection technology, specifically to a timed inspection task system and method based on gocron. Background Technology

[0002] When configuring automated inspection tasks using a scheduled task management system, there are conflicts between device priorities and between tasks, conflicts between effective process cleanup and scheduled task email notification report sending, and report overwriting issues when multiple actuators are running. How to coordinate devices and actuators to achieve scheduled inspections and send execution result email reports are technical problems that need to be solved. Summary of the Invention

[0003] The technical objective of this invention is to address the above-mentioned shortcomings by providing a timed inspection task system and method based on gocron, thereby solving the technical problem of how to coordinate equipment and actuators to achieve timed inspections and send execution result email reports.

[0004] Firstly, the present invention provides a timed inspection task system based on gocron.

[0005] It includes a scheduled task management system, remote host, execution device, scheduled task scheduler, scheduled task scheduling center, task executor, and task log database;

[0006] The remote host is at least one, and each remote host is configured with the airtest framework and multiple test cases. The airtest framework is used to execute test cases.

[0007] There are multiple execution devices, and each execution device interacts with a corresponding remote host through ADB;

[0008] The scheduled task management system is a gocron-based scheduled task management system used to configure task commands and send task commands to the scheduled task scheduler;

[0009] The scheduled task scheduler is used to schedule task commands and execution devices, send task commands with the corresponding device number to the scheduled task scheduling center, send the task commands to the remote host through the scheduled task scheduling center, and track the task execution results.

[0010] The task executor is configured on a remote host and is used to parse task commands to obtain the device number of the corresponding execution device. For each task command, it is used to start a thread and call the airtest framework to execute the test cases specified in the task command in a loop. It is used to write the execution result of each test case to the corresponding execution report, and aggregate the execution reports of all test cases to obtain an aggregate report. It is used to store the aggregate report in a folder named after the device number of the corresponding execution device, and return the storage path of the aggregate report to the scheduled task center.

[0011] For each task command, the scheduled task center is used to obtain the execution result of each test case and the storage path of the aggregate report from the remote host, and store the execution result of each test case, the storage path of the aggregate report and the execution time of the task command as task log data in the task log database, and use it to send task execution result notifications to users via email.

[0012] The scheduled task manager is used to read and view task log data from the task log database.

[0013] Preferably, the timed task scheduler is used to schedule tasks for the execution device based on the task commands sent by the user through the following steps:

[0014] Distinguish whether the task command is a task that needs to be executed by the device.

[0015] If the task command is a task that needs to be executed by the execution device, the task flow is managed through Macaron.context, and the current status of the execution device is polled to determine whether the corresponding execution device is in an idle state;

[0016] If the corresponding execution device is idle, add the corresponding task to the execution queue, create a log space for the execution device in the task log database, and control the execution process through context.context. During execution, start multi-threading, interact with the remote host through the scheduled task center to execute task commands, track the task execution results, and release the execution device based on the execution results.

[0017] If the corresponding execution device is occupied, wait for the corresponding execution device to be released;

[0018] When the corresponding execution device is released, the task execution ends, or the task execution times out, the execution device is added to the blacklist to prevent other task commands from calling it. The corresponding task is added to the execution queue, and a log space corresponding to the execution device is created in the task log database. The execution process is controlled by context.context. During the execution process, multi-threading is started, and the task command is executed by interacting with the remote host through the timed task scheduling center. The task execution result is tracked, and the execution device is released based on the execution result.

[0019] The scheduled task center is used to update the corresponding log space with the execution results of each test case, the storage path of the aggregate report, and the execution time of the task command as task log data.

[0020] Preferably, if the task command is a task that needs to be executed by an execution device, it is determined whether the task command specifies a device number of the corresponding execution device. If so, it is determined whether the corresponding execution device is in an idle state. If not, an idle execution device is selected as the execution device of the task command, and the device number of the execution device is added to the task command and sent to the timed task scheduling center.

[0021] Preferably, the task executor is used to write the execution result data of each test case into the execution report of a single test case based on the template page template of the pre-configured value, and store it in a folder named using 'log' + device number;

[0022] After all test cases corresponding to the task command have been executed, the execution report of all test cases is written into the aggregate report based on the pre-configured value aggregate report template, and the aggregate report is stored in a folder named 'log' + device number;

[0023] The path used to configure the test case execution details link as 'log' + device number.

[0024] Preferably, for each test case in the task command, the task executor is used to invoke the airtest framework to execute the test cases specified in the task command in a loop through the following steps:

[0025] The test case is executed by calling the airtest framework. If the execution is successful, the success count is incremented by one, and the current execution result is used as the execution result of the test case.

[0026] If execution fails, the failure count is incremented by one, and the test case is executed by the airtest framework within a predetermined number of repetitions until it succeeds. The successful execution result is taken as the execution result of the test case, and the number of successful and failed executions is counted each time the test case is executed.

[0027] If the test case is executed by the airtest framework within a predetermined number of repetitions, and each execution fails, the execution result is taken as the execution result of the test case, and the number of successful and failed executions is counted each time the test case is executed.

[0028] Secondly, the gocron-based scheduled inspection task method of the present invention is used to perform inspections through the gocron-based scheduled inspection task system described in any one of the first aspects, the method comprising the following steps:

[0029] Configure task commands through the scheduled task management system and send the task commands to the scheduled task scheduler;

[0030] The scheduled task scheduler connects task commands and execution devices to perform task scheduling. The task command with the corresponding device number is sent to the scheduled task scheduling center, which then sends the task command to the remote host. The scheduled task scheduler also tracks the task execution results.

[0031] The device number of the corresponding execution device is obtained by parsing the task command through the task executor;

[0032] For each task command, a thread is started through the task executor and the airtest framework is called to execute the test cases specified in the task command in a loop. The execution result of each test case is written to the corresponding execution report, and the execution reports corresponding to all test cases are aggregated to obtain an aggregate report. The aggregate report is stored in a folder named after the device number of the corresponding execution device, and the storage path of the aggregate report is returned to the scheduled task scheduling center.

[0033] The system obtains the execution results of each test case and the storage path of the aggregate report from the remote host through the scheduled task center. The system stores the execution results of each test case, the storage path of the aggregate report, and the execution time of the task command as task log data in the task log database, and sends task execution result notifications to users via email.

[0034] View task log data through the scheduled task management system.

[0035] Preferably, task scheduling of task commands and execution devices includes the following steps:

[0036] Distinguish whether the task command is a task that needs to be executed by the device.

[0037] If the task command is a task that needs to be executed by the execution device, the task flow is managed through Macaron.context, and the current status of the execution device is polled to determine whether the corresponding execution device is in an idle state;

[0038] If the corresponding execution device is idle, add the corresponding task to the execution queue, create a log space for the execution device in the task log database, and control the execution process through context.context. During execution, start multi-threading, interact with the remote host through the scheduled task center to execute task commands, track the task execution results, and release the execution device based on the execution results.

[0039] If the corresponding execution device is occupied, wait for the corresponding execution device to be released;

[0040] When the corresponding execution device is released, the task execution ends, or the task execution times out, the execution device is added to the blacklist to prevent other task commands from calling it. The corresponding task is added to the execution queue, and a log space corresponding to the execution device is created in the task log database. The execution process is controlled by context.context. During the execution process, multi-threading is started, and the task command is executed by interacting with the remote host through the timed task scheduling center. The task execution result is tracked, and the execution device is released based on the execution result.

[0041] The scheduled task center updates the corresponding log space with the execution results of each test case, the storage path of the aggregate report, and the execution time of the task command as task log data.

[0042] Preferably, if the task command is a task that needs to be executed by an execution device, the timed task scheduler determines whether the task command specifies a device number for a corresponding execution device. If so, it determines whether the corresponding execution device is in an idle state. If not, an idle execution device is selected as the execution device for the task command, and the device number of the execution device is added to the task command before it is sent to the timed task scheduling center.

[0043] Preferably, the execution result data of each test case is written into the execution report of a single test case through the template page template of the pre-configured value in the task executor, and stored in a folder named with 'log' + device number;

[0044] After all test cases corresponding to the task command have been executed, the execution reports of all test cases are written into the aggregate report using the pre-configured aggregate report template in the task executor, and the aggregate report is stored in a folder named 'log' + device number;

[0045] Configure the test case execution details link to the path 'log' + device number via the task executor.

[0046] Preferably, for each test case in the task command, the test cases specified in the task command are executed in a loop by calling the airtest framework through the task executor, including the following steps:

[0047] The test case is executed by calling the airtest framework. If the execution is successful, the success count is incremented by one, and the current execution result is used as the execution result of the test case.

[0048] If execution fails, the failure count is incremented by one, and the test case is executed by the airtest framework within a predetermined number of repetitions until it succeeds. The successful execution result is taken as the execution result of the test case, and the number of successful and failed executions is counted each time the test case is executed.

[0049] If the test case is executed by the airtest framework within a predetermined number of repetitions, and each execution fails, the execution result is taken as the execution result of the test case, and the number of successful and failed executions is counted each time the test case is executed.

[0050] The gocron-based timed inspection task system and method of the present invention have the following advantages:

[0051] 1. The execution device and the remote host are connected via ADB. The scheduled task scheduler schedules the scheduled tasks and the execution device. The scheduled task scheduler tracks the task execution results. The scheduled task scheduling center sends the execution result notification to the user via email. This can avoid conflicts between execution devices and between task execution and email notification.

[0052] 2. For task commands, the execution result data of each test case is written into the execution report of a single test case through the pre-configured value template page template, and stored in a folder named with 'log' + device number. The execution reports of all test cases are written into the aggregate report through the pre-configured value aggregation report template in the task executor, and the aggregate report is stored in a folder named with 'log' + device number, thus realizing the corresponding storage of task execution results. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] The invention will be further described below with reference to the accompanying drawings.

[0055] Figure 1 This is a block diagram of the timed task scheduling center in Example 1;

[0056] Figure 2 This is a block diagram of the task executor in Example 1;

[0057] Figure 3 This is a block diagram of the timed task scheduler in Example 1;

[0058] Figure 4 This is a flowchart of the timed inspection task method based on gocron in Example 2. Detailed Implementation

[0059] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments are not intended to limit the present invention. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments can be combined with each other.

[0060] This invention provides a gocron-based scheduled inspection task system and method to solve the technical problem of how to coordinate devices and actuators to achieve scheduled inspections and send execution result email reports.

[0061] Example 1:

[0062] This invention discloses a timed inspection task system based on gocron, comprising a timed task management system, a remote host, an execution device, a timed task scheduler, a timed task scheduling center, a task executor, and a task log database.

[0063] At least one remote host is required, and each remote host is configured with the Airtest framework and multiple test cases. The Airtest framework is used to execute test cases. Airtest is a cross-platform, image recognition-based UI automation testing framework suitable for games and apps, supporting Windows, Android, and iOS. Python includes the Airtest dependency package, and the patent can be directly referenced in the module where Python is the primary language. Poco is an automation testing framework based on UI control recognition, currently supporting Unity3d / cocos2dx-* / Android native apps / iOS native apps / WeChat mini-programs. The Poco SDK can also be integrated into other engines to use the source code.

[0064] There are multiple execution devices, each interacting with its corresponding remote host via ADB. ADB (also known as Android Debug Bridge) is a general-purpose command-line tool that allows users to communicate with emulator instances or connected Android devices. The ADB daemon acts as a server running on the phone, interacting with the PC client via TCP using an agreed-upon protocol to execute commands.

[0065] The gocron-based scheduled task management system is used to configure task commands and send them to the scheduled task scheduler. Developed in Go, it's a lightweight centralized scheduling and management system for scheduled tasks, and can be used as an alternative to linux-crontab. It allows users to specify task types and content, and view execution results and logs in real time.

[0066] The scheduled task scheduler is used to schedule task commands and execution devices. It sends task commands with the corresponding device number to the scheduled task scheduling center, which then forwards them to a remote host and tracks task execution results. The scheduled task manager is used to read and view task log data from the task log database.

[0067] In a specific implementation, the scheduled task scheduler is used to schedule tasks for the execution device based on the task commands sent by the user through the following steps:

[0068] (1) Distinguish whether the task command is a task that needs to be executed by the device.

[0069] (2) If the task command is a task that needs to be executed by the execution device, the task flow is managed through Macaron.context, the current status of the execution device is polled, and it is determined whether the corresponding execution device is idle.

[0070] If the corresponding execution device is idle, add the corresponding task to the execution queue, create a log space for the execution device in the task log database, and control the execution process through context.context. During execution, start multi-threading, interact with the remote host through the scheduled task center to execute task commands, track the task execution results, and release the execution device based on the execution results.

[0071] (3) If the corresponding execution device is occupied, wait for the corresponding execution device to be released;

[0072] When the corresponding execution device is released, the task execution ends, or the task execution times out, the execution device is added to the blacklist to prevent other task commands from calling it. The corresponding task is added to the execution queue, and a log space corresponding to the execution device is created in the task log database. The execution process is controlled by context.context. During the execution process, multi-threading is started, and the task command is executed by interacting with the remote host through the scheduled task center. The task execution result is tracked, and the execution device is released based on the execution result.

[0073] In the above process, if the task command is a task that needs to be executed by an execution device, it is determined whether the task command specifies a device number of the corresponding execution device. If so, it is determined whether the corresponding execution device is in an idle state. If not, an idle execution device is selected as the execution device of the task command, and the device number of the execution device is added to the task command and sent to the scheduled task scheduling center.

[0074] During automated inspection, when a manually triggered task or a scheduled task is scheduled to run, the scheduled task scheduler distinguishes whether the task requires device cooperation, determines the idle status of the required device, pauses or waits for the current execution status of the device based on priority, assigns the task for execution, prevents the device from being manually occupied, and tracks the execution results and terminal output. The device is automatically released after the task is actively terminated, timed out, or manually stopped, without affecting the execution of subsequent tasks. This effectively avoids the problem of conflicting execution failures caused by devices simultaneously executing two or more inspection tasks. Furthermore, different email notifications are sent based on the execution results of the scheduled tasks. When successful, a success email containing the test case inspection results is sent. When a timeout occurs, the task execution folder is traversed to retrieve the logs and rewrite them into the email template, with the subject changed to execution timeout notification.

[0075] The task executor is configured on a remote host to parse task commands and obtain the device number of the corresponding execution device. For each task command, it starts a thread and calls the airtest framework to execute the test cases specified in the task command in a loop. It writes the execution results of each test case to the corresponding execution report, aggregates the execution reports of all test cases to obtain an aggregate report, stores the aggregate report in a folder named after the device number of the corresponding execution device, and returns the storage path of the aggregate report to the scheduled task center.

[0076] In a specific implementation, the task executor is used to write the execution result data of each test case into the execution report of a single test case based on the pre-configured template page template, and store it in a folder named 'log' + device number; after all test cases corresponding to the task command have been executed, it is used to write the execution reports of all test cases into an aggregate report based on the pre-configured aggregate report template, and store the aggregate report in a folder named 'log' + device number; and it is used to configure the test case execution details link as the path 'log' + device number.

[0077] For each test case in the task command, the task executor is used to invoke the airtest framework to execute the test cases specified in the task command in a loop through the following steps:

[0078] (1) Call the airtest framework to execute the test case. If the execution is successful, increment the success count and use the current execution result as the execution result of the test case.

[0079] (2) If the execution fails, the failure count is incremented by one, and the test case is executed by the airtest framework within a predetermined number of repetitions until the execution is successful. The successful execution result is taken as the execution result of the test case, and the number of successful and failed executions is counted each time the test case is executed.

[0080] (3) If the test case is executed by the airtest framework within the predetermined number of repetitions and each execution fails, the execution result shall be taken as the execution result of the test case, and the number of successful and unsuccessful executions shall be counted each time the test case is executed.

[0081] During application, each designated execution device relies on the airtest framework to execute each specified test case in a loop. When executing a single script, the execution result is obtained through the airtest's CustomAirtestCase class. The execution device number is parsed from the task command generated by the scheduled task center. A self-developed template is used to write all data into the execution report of a single test case, which is stored in a folder named 'log' + device number. After all tasks are completed, a self-developed aggregation report template is used to write the aggregation results into an aggregation report. The test case execution details link is configured as a path of 'log' + device number, which supports direct access via nginx configuration, effectively avoiding the problem of repeatedly overwriting the execution results in the log folder when multiple devices execute the same test case.

[0082] For each task command, the scheduled task center obtains the execution results of each test case and the storage path of the aggregate report from the remote host. It also stores the execution results of each test case, the storage path of the aggregate report, and the execution time of the task command as task log data in the task log database, and sends task execution result notifications to users via email.

[0083] In a specific implementation, the scheduled task center is used to update the corresponding log space with the execution results of each test case, the storage path of the aggregate report, and the execution time of the task command as task log data.

[0084] During application, the scheduled task center is responsible for maintaining a connection with the remote host, distributing task commands to the remote host, and confirming the start of task execution. After execution, it retrieves the task execution results from the remote host, saves the execution time, terminal output, report address, and other results to the task log database, parses all data, and sends a task execution result notification.

[0085] The process for executing scheduled inspection tasks through the system is as follows:

[0086] (1) Because the system interacts with the terminal device through adb to execute automated tasks, the task executor needs to be configured first: when the execution command is received, a new thread is started to execute the automated task command. The original method of airtest is introduced to execute each test case script to obtain the report and write it into the template. After the execution is completed, the execution results of all tasks are collected to generate an aggregate report and store it in a folder named with the primary key device number.

[0087] Secondly, a timed task scheduler needs to be configured to send signals to the task executor: The timed task scheduler needs to periodically retrieve idle tasks and devices from the task pool and device pool, confirm the idle status of the devices, whether they are in the task blacklist, reasonably allocate matching tasks and execution devices, generate task execution commands and send them to the remote host to invoke the task executor, confirm whether the task executor has successfully started a new inspection thread through the command feedback from the remote host, and after receiving a notification that the execution device has been occupied, it is responsible for interacting with the remote host to stop the device task being executed by the task executor, releasing the device, and sending an execution stop notification to the timed task scheduling center.

[0088] Finally, configure the scheduled task center to maintain a connection with the scheduler on the remote host, distribute tasks into the database, obtain inspection task result reports, and send execution result notifications.

[0089] Using gocron as a scheduled task management system, scheduled tasks that need to be executed on specific devices can cause device conflicts when a new task requiring the same device is about to start before the previous task has finished executing and timed out. The device terminal will then report a connection refusal, ultimately causing both tasks to fail simultaneously. This system utilizes the adb terminal in conjunction with shell commands to manage process PIDs, effectively resolving the device conflict problem during execution.

[0090] When an automated inspection script enters an infinite loop, it causes a massive accumulation of adb process cache on the device, making it impossible to kill the current task process using the killsignal method in the Golang dependency package. The patent addresses this by forcibly killing the timed-out task process via the terminal and by configuring the timeout email in the scheduled task system. This resolves the issue of emails failing to be sent after forcibly killing the terminal process, and also solves the conflict between cleaning up the process and sending email notifications after a scheduled task times out.

[0091] The scheduled task system effectively integrates with automated inspection tasks by requesting interfaces from other cooperating systems. It clearly defines the priority of applications on the test platform, ensuring that the equipment is not manually occupied during the execution of scheduled tasks, and that the equipment is not interrupted by scheduled tasks that are about to begin using the equipment when it is manually occupied.

[0092] The task flow is managed using Macaron.context. Before starting a task, the current status of the device is polled. If the device is not idle, the polling continues and the device is occupied immediately when it is idle. The task is added to the execution queue, a log space is created, and the execution process is controlled using context.context.execution. If the execution fails, an email notification is sent. If the execution is successful, the terminal output is read as taskResult, stored in the log, and the device is released.

[0093] The executor is based on Python, operating independently of the Airtest IDE. It uses Python for cross-platform UI automation testing and generates aggregated reports. The execution process is controlled by ctx, which can stop the task at any time. Except for successful executions where the executor automatically sends an email as configured, in other cases, a scheduled task background reads the report from the node log in the log folder created in the executor, writes it to the template page using the template dependency package, and sends the email with the page content.

[0094] Example 2:

[0095] This invention provides a method for scheduled inspection tasks based on gocron. The method utilizes the gocron-based scheduled inspection task system disclosed in Example 1 for inspection and includes the following steps:

[0096] S100. Configure task commands through the scheduled task management system and send the task commands to the scheduled task scheduler;

[0097] S200: The scheduled task scheduler connects the task commands and execution devices to perform task scheduling. The task commands with the corresponding device numbers are sent to the scheduled task scheduling center. The scheduled task scheduling center sends the task commands to the remote host and tracks the task execution results through the scheduled task scheduler.

[0098] S300: Obtain the device number of the corresponding execution device by parsing the task command through the task executor;

[0099] S400. For each task command, a thread is started through the task executor and the airtest framework is called to execute the test cases specified in the task command in a loop. The execution result of each test case is written to the corresponding execution report, and the execution reports corresponding to all test cases are aggregated to obtain an aggregate report. The aggregate report is stored in a folder named after the device number of the corresponding execution device, and the storage path of the aggregate report is returned to the scheduled task scheduling center.

[0100] S500 obtains the execution results of each test case and the storage path of the aggregate report from the remote host through the scheduled task center, and stores the execution results of each test case, the storage path of the aggregate report, and the execution time of the task command as task log data in the task log database, and sends task execution result notifications to users in the form of email.

[0101] S600: View task log data through the scheduled task management system.

[0102] Task scheduling for task commands and execution devices includes the following steps:

[0103] (1) Distinguish whether the task command is a task that needs to be executed by the device.

[0104] (2) If the task command is a task that needs to be executed by the execution device, the task flow is managed through Macaron.context, the current status of the execution device is polled, and it is determined whether the corresponding execution device is idle.

[0105] (3) If the corresponding execution device is idle, add the corresponding task to the execution queue and create a log space corresponding to the execution device in the task log database. Control the execution process through context.context. During the execution process, start multi-threading, interact with the remote host through the timed task scheduling center to execute task commands, track the task execution results, and release the execution device based on the execution results.

[0106] (4) If the corresponding execution device is occupied, wait for the corresponding execution device to be released;

[0107] (5) When the corresponding execution device is released, the task execution ends, or the task execution times out, the execution device is added to the blacklist to prevent other task commands from calling it, the corresponding task is added to the execution queue, and a log space corresponding to the execution device is created in the task log database. The execution process is controlled by context.context. During the execution process, multi-threading is started, and the task command is executed by interacting with the remote host through the timed task scheduling center. The task execution result is tracked, and the execution device is released based on the execution result.

[0108] The scheduled task center updates the corresponding log space with the execution results of each test case, the storage path of the aggregate report, and the execution time of the task command as task log data.

[0109] If the task command is a task that needs to be executed by an execution device, the timed task scheduler determines whether the task command specifies a device number for a corresponding execution device. If so, it determines whether the corresponding execution device is in an idle state. If not, an idle execution device is selected as the execution device for the task command, and the device number of the execution device is added to the task command before it is sent to the timed task scheduling center.

[0110] The execution result data of each test case is written to the execution report of a single test case using the pre-configured template page template in the task executor, and stored in a folder named with 'log' + device number; after all test cases corresponding to the task command have been executed, the execution reports of all test cases are written to the aggregate report using the pre-configured aggregation report template in the task executor, and the aggregate report is stored in a folder named with 'log' + device number; the test case execution details link is configured to the path of 'log' + device number through the task executor.

[0111] For each test case in the task command, the airtest framework is invoked through the task executor to execute the test cases specified in the task command in a loop, including the following steps:

[0112] (1) Call the airtest framework to execute the test case. If the execution is successful, increment the success count and use the current execution result as the execution result of the test case.

[0113] (2) If the execution fails, the failure count is incremented by one, and the test case is executed by the airtest framework within a predetermined number of repetitions until the execution is successful. The successful execution result is taken as the execution result of the test case, and the number of successful and failed executions is counted each time the test case is executed.

[0114] (3) If the test case is executed by the airtest framework within the predetermined number of repetitions and each execution fails, the execution result shall be taken as the execution result of the test case, and the number of successful and unsuccessful executions shall be counted each time the test case is executed.

[0115] The present invention has been shown and described in detail above with reference to the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above embodiments, those skilled in the art will know that more embodiments of the present invention can be obtained by combining the code review methods in the different embodiments. These embodiments are also within the protection scope of the present invention.

Claims

1. A gocron-based timing patrol task system, characterized in that The timing task management system, the remote host, the execution device, the timing task scheduler, the timing task scheduling center, the task executor and the task log database are included; The remote host is at least one, and each remote host is configured with an airtest framework and a plurality of test cases, and the airtest framework is used to execute the test cases; The execution device is shared by a plurality of execution devices, and each execution device interacts with the corresponding remote host through ADB; The timing task management system is a gocron-based timing task management system, which is used to configure task commands and send the task commands to the timing task scheduler; The timing task scheduler is used to schedule the task commands and the execution device, send the task commands added with the device number of the corresponding execution device to the timing task scheduling center, send the task commands to the remote host through the timing task scheduling center, and track the task execution result; The task executor is configured in the remote host, and is used to parse the task commands to obtain the device number of the corresponding execution device; for each task command, a thread is started and the airtest framework is called to execute the test cases specified in the task command, the execution result of each test case is written into the corresponding execution report, and the aggregated report is obtained by aggregating the execution reports corresponding to all test cases; the aggregated report is stored in a folder named with the device number of the corresponding execution device, and the storage path of the aggregated report is returned to the timing task scheduling center; For each task command, the timing task scheduling center is used to obtain the execution result of each test case and the storage path of the aggregated report from the remote host, and stores the execution result of each test case, the storage path of the aggregated report and the execution time of the task command as task log data in the task log database, and sends the task execution result notification to the user in the form of email; The timing task management system is used to read and view the task log data from the task log database.

2. The gocron-based timing patrol task system according to claim 1, wherein The timing task scheduler is used to schedule the execution device based on the task command sent by the user by the following steps: Distinguish whether the task command is a task that needs to be executed by the execution device, If the task command is a task that needs to be executed by the execution device, the task flow is managed by Macaron.context, the current state of the execution device is polled, and it is judged whether the corresponding execution device is in an idle state; If the corresponding execution device is in an idle state, the corresponding task is added to the execution queue, a log log space corresponding to the execution device is created in the task log database, and the execution process is controlled by context.context, in which multiple threads are started, the remote host is interacted with through the timing task scheduling center to execute the task command, and the task execution result is tracked, and the execution device is released based on the execution result; If the corresponding execution device is occupied, the corresponding execution device is waited to be released; When the corresponding execution device is released, the task execution ends or the task execution times out, the execution device is added to the blacklist to prohibit other task command calls, the corresponding task is added to the execution queue, a log log space corresponding to the execution device is created in the task log database, and the context.context control execution process is controlled. In the execution process, multi-threading is started, the remote host is interacted with through the timing task scheduling center to execute the task command, and the task execution result is tracked. Based on the execution result, the execution device is released; The timing task scheduling center is used to update the execution result of each test case, the storage path of the aggregated report, and the execution time of the task command as task log data to the corresponding log log space.

3. The gocron-based timing patrol task system according to claim 2, wherein If the task command is a task that needs to be executed by the execution device, it is judged whether the task command specifies the device number of the corresponding execution device. If yes, it is judged whether the corresponding execution device is in an idle state; if no, an execution device in an idle state is used as the execution device of the task command, and the device number of the execution device is added to the task command and sent to the timing task scheduling center.

4. The gocron-based timing patrol task system according to claim 1, wherein The task executor is used to write the execution result data of each test case into the execution report of a single test case based on the template page template of the pre-provisioned value, and store it in a folder named 'log' + device number; After all the test cases corresponding to the task command are executed, the task executor is used to write the execution report of all the test cases into the aggregated report based on the aggregated report template of the pre-provisioned value, and store the aggregated report in a folder named 'log' + device number; The test case execution details link is configured as the path of 'log' + device number.

5. The gocron-based timing patrol task system according to claim 1, wherein For each test case of the task command, the task executor is used to call the airtest framework to execute the test case specified in the task command by the following steps: Call the airtest framework to execute the test case. If the execution is successful, the number of execution successes is incremented by one, and the current execution result is taken as the execution result of the test case; If the execution fails, the number of execution failures is incremented by one, and the airtest framework is called to execute the test case within a predetermined number of repetitions until the execution is successful. The execution result of the execution success is taken as the execution result of the test case, and the number of execution successes and execution failures is counted each time the test case is executed; If the airtest framework is called to execute the test case within a predetermined number of repetitions, each execution fails, and the execution result is taken as the execution result of the test case, and the number of execution successes and execution failures is counted each time the test case is executed.

6. A method for gocron-based timing patrol task, characterized in that The method for performing inspection by the gocron-based timing inspection task system according to any one of claims 1-5, the method comprising the following steps: Configure a task command through the timing task management system, and send the task command to the timing task scheduler; The task command and the execution device are scheduled by the timing task scheduler, the task command with the device number of the corresponding execution device is sent to the timing task scheduling center, the task command is sent to the remote host by the timing task scheduling center, and the task execution result is tracked by the timing task scheduler; The device number of the corresponding execution device is obtained by parsing the task command by the task executor; For each task command, a thread is started and the airtest framework is called to execute the test case specified in the task command, the execution result of each test case is written into the corresponding execution report, and the aggregated report is obtained by aggregating the execution reports of all test cases, the aggregated report is stored in a folder named with the device number of the corresponding execution device, and the storage path of the aggregated report is returned to the timing task scheduling center; The execution result of each test case and the storage path of the aggregated report are obtained from the remote host by the timing task scheduling center, and the execution result of each test case, the storage path of the aggregated report, and the execution time of the task command are stored as task log data in the task log database, and the task execution result notification is sent to the user in the form of email; The task log data is viewed by the timing task management system.

7. The gocron-based timing patrol task method according to claim 6, wherein The task command and the execution device are scheduled, including the following steps: Distinguish whether the task command is a task that needs to be executed by the execution device, If the task command is a task that needs to be executed by the execution device, the task flow is managed by Macaron.context, the current state of the execution device is polled, and it is judged whether the corresponding execution device is in an idle state; If the corresponding execution device is in an idle state, the corresponding task is added to the execution queue, the log log space corresponding to the execution device is created in the task log database, and the execution process is controlled by context.context, in the execution process, multiple threads are started, the timing task scheduling center is interacted with the remote host to execute the task command, and the task execution result is tracked, and the execution device is released based on the execution result; If the corresponding execution device is occupied, wait for the corresponding execution device to be released; When the corresponding execution device is released, the task execution ends or the task execution times out, the execution device is added to the blacklist to prohibit other task commands from calling, the corresponding task is added to the execution queue, the log log space corresponding to the execution device is created in the task log database, and the execution process is controlled by context.context, in the execution process, multiple threads are started, the timing task scheduling center is interacted with the remote host to execute the task command, and the task execution result is tracked, and the execution device is released based on the execution result; The execution result of each test case, the storage path of the aggregated report, and the execution time of the task command are updated as task log data to the corresponding log log space by the timing task scheduling center.

8. The gocron-based timing patrol task method according to claim 7, wherein If the task command is a task that needs to be executed by a device, the timing task scheduler determines whether the task command specifies a device number of a corresponding execution device, and if so, determines whether the corresponding execution device is in an idle state; if not, an execution device in an idle state is selected as the execution device of the task command, and the device number of the execution device is added to the task command and sent to the timing task scheduling center.

9. The gocron-based timing patrol task method according to claim 6, wherein The execution result data of each test case is written into the execution report of a single test case by using the template page template of the pre-configured value in the task executor, and stored in a folder named 'log' + device number; After all the test cases corresponding to the task command are executed, the execution reports of all the test cases are written into the aggregate report by using the aggregate report template of the pre-configured value in the task executor, and the aggregate report is stored in a folder named 'log' + device number; The test case execution details link is configured as the path of 'log' + device number by the task executor.

10. The gocron-based timing patrol task method according to claim 6, wherein For each test case of the task command, the task executor calls the airtest framework to execute the test case specified in the task command, including the following steps: The airtest framework is called to execute the test case, and if the execution is successful, the number of successful executions is incremented by one, and the current execution result is taken as the execution result of the test case; If the execution fails, the number of failed executions is incremented by one, and the airtest framework is called to execute the test case within a predetermined number of repetitions until the execution is successful, and the execution result of the successful execution is taken as the execution result of the test case, and the number of successful executions and the number of failed executions are counted each time the test case is executed; If the airtest framework is called to execute the test case within a predetermined number of repetitions, and each time the execution fails, the execution result is taken as the execution result of the test case, and the number of successful executions and the number of failed executions are counted each time the test case is executed.

Images