Automatic test platform and test method based on resource scheduling

Abstract

The invention discloses an automatic test platform and a test method based on resource scheduling, and relates to an automatic test technology. Comprising a resource scheduling module deployed in a server and an AutoTester for testing a host; the resource scheduling module responds to a code merging request through a GitLab WebHook monitor, the equipment state monitoring unit maintains an equipment state machine model in real time, and the equipment scheduling unit adopts a dual-mode mechanism: a binding mode specifies an equipment ID to execute tasks, and a weighted automatic allocation mode dynamically allocates tasks according to idle time of equipment. According to the method, GitLab WebHook is deeply integrated, a task triggering mechanism driven by a GitLab code merging event is adopted, and the defect that a traditional testing system is disjointed with a development process is overcome; meanwhile, a dual-mode scheduling mechanism is adopted, the equipment utilization rate and the test efficiency are remarkably improved, and the problems of resource competition and resource idleness caused by traditional static binding are solved.

Description

Technical Field

[0001] The present invention relates to automated testing technology, in particular to an automated testing platform and testing method based on resource scheduling. Background Art

[0002] With the advancement of automotive electronics and the increase in vehicle functionality, vehicles have become intelligent, connected, and electric mobile terminals. Consequently, the complexity of in-vehicle software has also increased with the increase in functionality, leading to a significant increase in software code size and posing new challenges for software testing. Existing automated testing methods rely primarily on static device binding. Users manually create test tasks and are required to specify specific device IDs. Tasks are then assigned to target devices in a fixed manner. Device clusters lack real-time status monitoring, and task triggering relies solely on manual operation or preset timers, failing to respond to development process timing (such as code merges). This approach results in low device utilization, disconnects from CI / CD processes, and poor scalability. Adding new devices requires reconfiguration and rebinding of tasks, and running multiple tasks in parallel can easily lead to device resource contention and even overload. To address this, we present an automated testing platform and method based on resource scheduling. Summary of the Invention

[0003] The purpose of the present invention is to provide an automatic testing platform based on resource scheduling. The combination of a dual-mode scheduling mechanism and deep integration with GitLab has been tested and verified to have extremely low event triggering delay, thereby overcoming the problems mentioned in the background technology.

[0004] The present invention can be implemented through the following technical solution: an automatic testing platform based on resource scheduling, including a resource scheduling module deployed on a server and an automated testing tool AutoTester deployed on a test host: The resource scheduling module includes an interface interaction unit, a GitLab WebHook listener, a device status monitoring unit, and a device scheduling unit. The interface interaction unit provides a login interface, a host management interface, a device management interface, a task list interface, and a result details interface. The GitLab WebHook listener is used to receive code merge request messages from the GitLab repository and determine the request status. The device status monitoring unit regularly collects device heartbeat signals through device proxy probes, updates the device status database, and the state controller maintains the device state machine model. The device scheduling unit polls the device status database and uses a dual-mode scheduling mechanism to distribute test tasks to corresponding devices. The automated testing tool AutoTester is integrated into the project to be tested and pushed to the GitLab repository. It includes Python scripts, Lua scripts, and batch processing commands to complete the compilation, downloading, and burning of the project to be tested.

[0005] A further technical improvement of the present invention is that: in the same local area network, multiple test hosts or computer devices can access the server and load the resource scheduling module. Each test host can be connected to multiple devices to form a test host-device tree topology, supporting multi-task concurrent testing.

[0006] A further technical improvement of the present invention is that the dual-mode scheduling mechanism includes a binding mode and a weighted automatic allocation mode: Binding mode: The test task is bound to a specific device ID, and the task is tested on the specified device; Weighted automatic allocation mode: Test tasks are assigned based on device type. When all target devices are in the test state, the task is added to the waiting queue. When only one target device is idle, the task is assigned directly. When multiple target devices are idle, the priority weight is calculated based on the continuous idle time. The longer the idle time, the greater the weight, and the task is assigned to the high-weight device first.

[0007] A further technical improvement of the present invention is that the automated testing tool AutoTester captures the source code and header file path of the project to be tested through a Python script, triggers compilation through a Lua script to generate a .hex firmware file, and controls the JLink or PE downloader to execute firmware burning through batch commands.

[0008] A testing method based on the above automatic testing platform includes the following steps: S1. Deploy the resource scheduling module and AutoTester on the server and test host respectively; S2. Access the login interface and log in; S3. Add a test host in the host management interface and configure host parameters; Add devices and configure device parameters in the device management interface; Create a new test task in the task list interface and configure the task parameters. Then add the GitLabWebHook URL and Secret token of each test task to the integrated interface of the GitLab repository where the project to be tested is located to complete the configuration. S4. The code version changes and a merge request is made in the GitLab repository. S5. The GitLab WebHook listener receives the WebHook message push of the merge request, determines the merge request status, and determines whether to execute the test task; S6. Parse the WebHook message, obtain the GitLab repository URL and the project information to be tested, and output them to AutoTester. S7, the resource scheduling module distributes tasks based on the dual-mode scheduling mechanism and executes tests on the corresponding devices through AutoTester; S8. Test reports and logs are returned to the server and shared with the work group via Mattermost.

[0009] A further technical improvement of the present invention is that the judgment logic regarding the merge request status in step S5 includes: When the merge request status is "Opened", subsequent testing will continue, otherwise the testing will be terminated.

[0010] A further technical improvement of the present invention is that the device scheduling unit of the resource scheduling module in step S7 first confirms the test mode, then queries the device status database to obtain all device statuses of the target device type, filters idle devices, and assigns tasks to the highest weighted device.

[0011] A further technical improvement of the present invention is that the AutoTester execution process in step S5 includes: the Python script parses the project path to be tested and passes it to the Lua script, the Lua script calls the compilation tool chain to generate a .hex file; the batch command automatically selects JLink or PE downloader to complete the burning.

[0012] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention deeply integrates GitLab WebHook and adopts GitLab's code merge event-driven task triggering mechanism to automatically identify code merge events. The resource scheduling module obtains and parses push messages, thereby associating test tasks. This overcomes the defect of traditional testing systems being out of touch with development processes. By accurately parsing merge request events and automatically matching test tasks, the test trigger response time is shortened from more than 5 minutes required for manual operation to less than 1 second, greatly improving development and testing efficiency.

[0013] 2. The present invention adopts a dual-mode scheduling mechanism, flexibly selects corresponding test modes for different test tasks, continuously polls the device status database to obtain device status information, and then executes the allocation strategy according to the number of target type devices and whether they are in an idle state. When multiple target devices are in an idle state, priority weights are assigned according to the idle time of the devices. The higher the weight, the higher the priority of task allocation, so that the average equipment utilization rate is increased from 60% of the existing technology to more than 90%, effectively reducing the resource idle rate. At the same time, it can also prevent a single device from being overloaded.

[0014] 3. The present invention uses device proxy probes to perform heartbeat detection on the device and integrates a state machine model to achieve real-time warning of device abnormalities, which greatly improves the accuracy of abnormality identification and reduces the probability of false alarms caused by occasional abnormalities. Compared with the existing technology that relies entirely on manual inspections, the efficiency of fault detection is significantly improved.

[0015] 4. The present invention adopts a host-device tree topology architecture, which improves the expansion efficiency of the entire system. Under the same test scale, the task completion time is significantly reduced and the number of manual interventions is greatly reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] To facilitate understanding by those skilled in the art, the present invention is further described below with reference to the accompanying drawings.

[0017] Figure 1 This is a schematic diagram of the overall architecture of the automated testing platform of the present invention; Figure 2 It is a schematic diagram of the overall process of the present invention; Figure 3 This is a schematic diagram of executing the specific method of automated testing of the present invention. DETAILED DESCRIPTION

[0018] In order to further illustrate the technical means and effects adopted by the present invention to achieve the predetermined purpose of the invention, the specific implementation methods, structures, features and effects of the present invention are described in detail below in conjunction with the accompanying drawings and preferred embodiments.

[0019] See also Figure 1-3 As shown, an automatic testing platform based on resource scheduling includes a resource scheduling module developed based on a web interface and deployed in a server, and a composite script tool AutoTester deployed on a test host. The platform serves as a relay system for receiving code push from the GitLab hosting library and controlling the test host to execute test tasks. Within the same local area network, multiple test hosts or computer devices can access the server and load the resource scheduling module.

[0020] The resource scheduling module includes a web-based interface interaction unit, which users use to configure relevant parameters. The resource scheduling module also integrates the GitLab WebHook listener, device status monitoring unit, and device scheduling unit. Among them, the interface interaction unit includes the login interface, host management interface, device management interface, task list interface and result details interface.

[0021] The GitLab WebHook listener is used to receive push notifications of code merge requests from GitLab repositories and determine the status of the requests to determine whether to execute the test task. The device status monitoring unit regularly uploads heartbeat signals through the device proxy probe to obtain the device status and update it to the device status database. The state controller maintains the device state machine model, which greatly improves the accuracy of anomaly identification and reduces the probability of false alarms caused by occasional anomalies. The device scheduling unit continuously polls the device status database to obtain the status of various types of devices connected to the corresponding host. The device scheduling unit uses a dual-mode scheduling mechanism for task scheduling, including binding mode and weighted automatic allocation mode: The binding mode specifically means that the test task is bound to a specific device ID, that is, the test task is specified to be tested on this device; The weighted automatic allocation mode means that the test task is undertaken by a certain type of device. There are usually multiple devices of this type at the same time. If all devices of this type are in the test state, the test task will be placed in the waiting queue; if there is only one device of this type in the idle state, the test task will be directly loaded to the device for testing; if there are multiple devices of this type in the idle state, the device will be given a priority weight based on the continuous idle time after the last task is completed. The longer the continuous idle time, the greater the priority weight. The test task will be loaded on the corresponding device according to the size of the priority weight.

[0022] It should be noted that each test host is connected to multiple devices of the same or different types, thereby building a test host-device tree topology, thereby enabling concurrent testing of multiple test tasks on different types of devices.

[0023] The composite scripting tool AutoTester uses Python, Lua scripts, and batch processing commands to efficiently control the compilation, downloading, and burning of test projects. AutoTester consists of project files and is integrated with the project under test. It is pushed to the GitLab repository along with the project under test. Specifically: The Python script automatically captures the path information for the source code and header files of the project under test. This critical information is then passed to the Lua script. Leveraging its flexibility and lightweight nature, the Lua script further processes this path information and triggers the compilation process to generate the required .hex format firmware file. During the burning process, this platform uses JLink as the primary downloader and automatically manages the burning of .hex files for different configuration sets through batch commands. To enhance the downloader's versatility and compatibility, this platform has also added adaptation processing for the PE downloader, ensuring the platform's adaptability to different hardware platforms and burning requirements.

[0024] The test process based on the above automatic test platform includes the following steps: Step 1: Test platform deployment Users deploy the AutoTester automated testing tool on the test host and the resource scheduling module on the server.

[0025] Step 2: Log in and configure the test host The user accesses the login interface of the resource scheduling module to log in, and adds the test host and configures parameters such as host address, network port, delay and other parameters in the host management interface.

[0026] Step 3: Configure the test equipment Users can add test devices and configure parameters such as device type, burning method, USB port, etc. in the device management interface.

[0027] Step 4: Create a new test task and configure parameters In the task list interface, users create a new test task and configure parameters such as task type, device type, target device, and other parameters. They also add the GitLab WebHook URL and Secret token corresponding to the test task to the corresponding locations in the integrated interface of the GitLab repository where the project to be tested is located, and complete the configuration.

[0028] Step 5: Code version iteration and merge request When the code version changes, a merge request is submitted to the GitLab repository.

[0029] Step 6: Receive and determine the status of the merge request The GitLab WebHook listener of the resource scheduling module receives the WebHook message push of the merge request and determines the status of the merge request. If the status of the merge request is not Opened, the test task will not be further executed. Otherwise, the test task will continue to be executed.

[0030] Step 7: Parse WebHook message push and transmit it to AutoTester The listener parses the WebHook message, obtains the GitLab repository URL and the project to be tested information, and outputs it to AutoTester. AutoTester compiles, downloads, and burns the project to be tested based on the parsed information.

[0031] Step 8: Schedule and execute test tasks The resource scheduling module automatically distributes test tasks to corresponding devices based on the current test mode and the device status of each type of device. AutoTester deploys the code to be tested corresponding to the test task on the corresponding device for automated testing.

[0032] Step 9. Test result return and output After the test is completed, the test report and log are returned to the server and can be viewed and exported in the result details interface. At the same time, the server can automatically send the test report to the specified channel of Mattermost.

[0033] The above description is merely a preferred embodiment of the present invention and does not constitute any form of limitation to the present invention. Although the present invention has been disclosed as a preferred embodiment as above, it is not intended to limit the present invention. Any person skilled in the art can make some changes or modifications to equivalent embodiments using the technical contents disclosed above without departing from the scope of the technical solution of the present invention. However, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention are still within the scope of the technical solution of the present invention.

Claims

1. An automatic testing platform based on resource scheduling, characterized in that: It includes the resource scheduling module deployed on the server and the automated testing tool AutoTester deployed on the test host: The resource scheduling module includes an interface interaction unit, a GitLab WebHook listener, a device status monitoring unit, and a device scheduling unit; the interface interaction unit provides a login interface, a host management interface, a device management interface, a task list interface, and a result details interface; the GitLab WebHook listener is used to receive code merge request messages from the GitLab repository and determine the request status; the device status monitoring unit regularly collects device heartbeat signals through device proxy probes, updates the device status database, and the state controller maintains the device state machine model; the device scheduling unit polls the device status database and uses a dual-mode scheduling mechanism to distribute test tasks to corresponding devices; The automated testing tool AutoTester is integrated into the project to be tested and pushed to the GitLab repository. It contains Python scripts, Lua scripts, and batch processing commands to complete the compilation, downloading, and burning processes of the project to be tested.

2. The automatic test platform based on resource scheduling according to claim 1, characterized in that: In the same local area network, multiple test hosts or computer devices can access the server and load the resource scheduling module. Each test host can be connected to multiple devices to form a test host-device tree topology, supporting multi-task concurrent testing.

3. The automatic test platform based on resource scheduling according to claim 1, characterized in that: The dual-mode scheduling mechanism includes a binding mode and a weighted automatic allocation mode: Binding mode: The test task is bound to a specific device ID, and the task is tested on the specified device; Weighted automatic allocation mode: assign test tasks based on device type. When all target devices are in the test state, the task is added to the waiting queue. When only one target device is idle, the task is directly assigned. When multiple target type devices are idle, the priority weight is calculated based on the continuous idle time. The longer the time, the greater the weight, and tasks are preferentially assigned to high-weight devices.

4. The automatic test platform based on resource scheduling according to claim 1, characterized in that: The automated testing tool AutoTester captures the source code and header file paths of the project to be tested through a Python script, triggers compilation through a Lua script to generate a .hex firmware file, and controls the JLink or PE downloader to execute firmware burning through batch commands.

5. A testing method for the automatic testing platform according to any one of claims 1 to 4, characterized in that: The steps include: S1. Deploy the resource scheduling module and AutoTester on the server and test host respectively; S2. Access the login interface and log in; S3. Add a test host in the host management interface and configure host parameters; Add devices and configure device parameters in the device management interface; Create a new test task in the task list interface and configure the task parameters. Then, add the GitLab WebHook URL and Secret token of each test task to the integrated interface of the GitLab repository where the project to be tested is located to complete the configuration. S4. The code version changes and a merge request is made in the GitLab repository. S5. The GitLab WebHook listener receives the WebHook message push of the merge request, determines the merge request status, and determines whether to execute the test task; S6. Parse the WebHook message, obtain the GitLab repository URL and the project information to be tested, and output them to AutoTester. S7, the resource scheduling module distributes tasks based on the dual-mode scheduling mechanism and executes tests on the corresponding devices through AutoTester; S8. Test reports and logs are returned to the server and shared with the work group via Mattermost.

6. An automatic testing method according to claim 5, characterized in that: The logic for determining the merge request status in step S5 includes: When the merge request status is "Opened", subsequent testing will continue, otherwise the testing will be terminated.

7. An automatic testing method according to claim 5, characterized in that: In step S7, the device scheduling unit of the resource scheduling module first confirms the test mode, then queries the device status database to obtain all device statuses of the target device type, filters idle devices, and assigns tasks to the highest-weighted device.

8. An automatic testing method according to claim 5, characterized in that: The AutoTester execution process in step S5 includes: the Python script parses the path of the project to be tested and passes it to the Lua script, the Lua script calls the compilation tool chain to generate a .hex file; the batch command automatically selects JLink or PE downloader to complete the burning.

Images