Vehicle-mounted software automatic test method, device, equipment and medium

Abstract

The application discloses a kind of vehicle-mounted software automation test method, device, equipment and medium, is related to the field of automobile electronic control technology, method includes: in response to test task trigger request, obtain test configuration information, based on test configuration information from multiple test nodes Match target test node in idle state;Lightweight instruction package is sent to target test node, to indicate target test node according to address information in lightweight instruction package to file server pull material file and according to material file to execute test task;Receive the execution state information that target test node is in test execution period and is reported in real time, according to execution state information monitoring test progress;After receiving the test result that target test node uploads after completing test task, the initiator of test task trigger request is returned with the notification containing test result.The application can realize automatic trigger scheduling, issue lightweight instruction to improve the efficiency of vehicle-mounted software automation test.

Description

Technical Field

[0001] This application relates to the field of automotive electronic control technology, specifically to an automated testing method, apparatus, equipment, and medium for vehicle-mounted software. Background Technology

[0002] With the rapid development of intelligent connected vehicles, the iteration speed and complexity of in-vehicle software have increased unprecedentedly, placing higher demands on the efficiency of its quality verification. Currently, automated testing of in-vehicle software mainly faces the following technical problems: First, poor linkage with continuous integration pipelines. Existing testing solutions are mostly deployed in silos, unable to be deeply integrated with CI toolchains, resulting in automated testing relying on manual triggering, making it difficult to achieve the goal of "test as you write" after code submission, and leading to low test triggering efficiency. Second, the transmission method of test materials leads to excessive bandwidth consumption. Traditional centralized distribution mechanisms push bulky physical materials such as firmware, test cases, and configuration files directly from the cloud platform to each test node, severely consuming network bandwidth resources in multi-node concurrent testing scenarios, restricting the scalability of large-scale concurrent testing. Third, the scheduling of test resources lacks an intelligent matching mechanism. Different test tasks have different requirements for the operating system base, hardware interface, and dedicated environment of test nodes. Existing solutions lack a precise matching strategy based on environment tags, often resulting in tasks being assigned to incompatible nodes and failing to execute. Fourth, there are blind spots in monitoring during test execution and a lack of abnormal intervention methods. The existing system cannot obtain fine-grained progress data of test nodes during execution. When nodes crash or resources are suspended, maintenance personnel cannot remotely perform operations such as forced termination and environment cleanup. They can only intervene manually, which results in bench resources being occupied for a long time and seriously reduces the utilization efficiency of test resources.

[0003] To address the aforementioned issues, some existing solutions achieve a degree of automated iterative testing by mounting the executable file under test to a cloud server and executing the test using a simulator, while also collecting runtime logs. However, these solutions still have several shortcomings: First, file synchronization in the execution environment relies on traditional network mounting methods, resulting in low synchronization efficiency in large-scale concurrent scenarios and insufficient compatibility with modern CI / CD pipelines. Second, test judgments are primarily based on log text analysis, lacking structured test conclusion judgment models, and do not involve the scheduling and allocation of test resources or the monitoring of the execution process. This makes it difficult to meet the comprehensive requirements of automated testing systems in high-frequency iteration scenarios for automotive software, particularly regarding trigger immediacy, scheduling accuracy, process observability, and anomaly intervention. Summary of the Invention

[0004] This application provides a method, apparatus, equipment, and medium for automated testing of vehicle software, which can solve the technical problem of low efficiency in automated testing of vehicle software in the prior art.

[0005] In a first aspect, embodiments of this application provide an automated testing method for in-vehicle software, the automated testing method for in-vehicle software comprising: In response to a test task triggering request, test configuration information is obtained, and a target test node in an idle state is matched from multiple test nodes based on the test configuration information; A lightweight instruction packet is sent to the target test node to instruct the target test node to pull the material file from the file server according to the address information in the lightweight instruction packet and to execute the test task according to the material file; Receive the execution status information reported in real time by the target test node during the test execution cycle, and monitor the test progress based on the execution status information; After receiving the test results uploaded by the target test node after completing the test task, a notification containing the test results is returned to the initiator of the test task triggering request.

[0006] In conjunction with the first aspect, in one implementation, the step of responding to a test task triggering request, obtaining test configuration information, and matching a target test node in an idle state from multiple test nodes based on the test configuration information includes: In response to a test task trigger request, test configuration information is parsed and obtained. The test configuration information includes at least the project identifier, hardware type, and bill of materials file. The test task type is identified based on the bill of materials file. The test task types include bulk package acceptance testing, integration smoke testing, and protocol stack testing. Based on the project identifier and hardware type, determine the target node label required to execute the test task; The target node label is matched with the preset node labels of each test node, and the test nodes with matching labels are selected as the initial node set. Nodes that are currently in task execution or agent process abnormality are removed from the initial selection node set to obtain the target test nodes.

[0007] In conjunction with the first aspect, in one implementation method: The bill of materials file includes: automated test environment dependencies, test configuration file dependencies, and firmware flashing artifacts; The node labels include: operating system base type, project-specific environment identifier, and integration environment type.

[0008] In conjunction with the first aspect, in one implementation method: The lightweight instruction package includes material download address information, execution startup script path, and node identity authentication token. The material download address information includes software firmware download address, use case set download address, and configuration file download address.

[0009] In conjunction with the first aspect, in one implementation, sending a lightweight instruction packet to the target test node to instruct the target test node to retrieve material files from the file server according to the address information in the lightweight instruction packet and to execute test tasks according to the material files includes: The lightweight instruction package is sent to the target test node. The target test node parses the material download address information according to the received lightweight instruction package and initiates identity authentication with the file server according to the node identity authentication token. After successful identity authentication, the target test node actively pulls the physical material files from the file server based on the material download address information and stores the pulled physical material files in the local isolation sandbox. The target test node reads the path to the execution startup script and starts the test task corresponding to the entity material file in the local isolated sandbox.

[0010] In conjunction with the first aspect, in one implementation, receiving the execution status information reported in real time by the target test node during the test execution cycle, and monitoring the test progress based on the execution status information, includes: The execution status information of the current test is collected at preset time intervals, and the execution status information is encapsulated into a status synchronization message; The status synchronization message is reported to the test cloud platform through the status synchronization interface, and the test cloud platform updates the full life cycle status chain of the test task according to the received status synchronization message. The execution status information includes the percentage of material retrieval progress, the identifier of the current execution stage, the name of the current execution test case, the number of real-time passed test cases and the number of failed test cases, and the status of the status chain is either creating, queuing, initializing, executing or settling results.

[0011] In conjunction with the first aspect, in one implementation, monitoring the test progress based on the execution status information includes: The test cloud platform determines whether the target test node has experienced a crash, resource suspension, or execution timeout based on the execution status information reported by the target test node. If so, an abnormal state is determined, and an intervention command is sent to the target test node through the emergency console; If not, the test progress will continue to be monitored based on the execution status information. Intervention commands include forced termination commands, step skip commands, environment reset commands, or physical restart commands.

[0012] Secondly, embodiments of this application provide an automated testing device for in-vehicle software, the automated testing device for in-vehicle software comprising: The response module is used to respond to the test task triggering request, obtain test configuration information, and match the target test node in an idle state from multiple test nodes based on the test configuration information. The execution module is used to send a lightweight instruction packet to the target test node, instructing the target test node to pull the material file from the file server according to the address information in the lightweight instruction packet and execute the test task according to the material file; The monitoring module is used to receive the execution status information reported in real time by the target test node during the test execution cycle, and monitor the test progress based on the execution status information. The notification module is used to return a notification containing the test results to the initiator of the test task triggering request after receiving the test results uploaded by the target test node after completing the test task.

[0013] Thirdly, this application provides an automated testing device for vehicle software, which includes a processor, a memory, and an automated testing program for vehicle software stored in the memory and executable by the processor. When the automated testing program for vehicle software is executed by the processor, it implements the steps of the automated testing method for vehicle software as described in any of the above embodiments.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing an automated testing program for vehicle software, wherein when the automated testing program for vehicle software is executed by a processor, it implements the steps of the automated testing method for vehicle software as described in any of the above embodiments.

[0015] The beneficial effects of the technical solutions provided in this application include: This embodiment of the application obtains test configuration information and matches idle target nodes from multiple test nodes accordingly. This ensures that the selected node currently has the ability to execute tasks, avoiding the assignment of tasks to occupied or abnormal nodes and reducing the time consumed by task waiting and retries. This embodiment sends lightweight instruction packets to the target test node. Lightweight instruction packets have small data sizes and consume very little bandwidth. The physical material files are actively pulled from the file server by the target test node based on the address information of the lightweight instruction packet. This transforms material transmission from centralized push from the cloud platform to distributed pull from nodes, avoiding network congestion caused by the cloud platform simultaneously pushing large files when multiple nodes are concurrent. During execution, the target test node reports execution status information in real time. The test cloud platform can monitor the test progress based on the received status information, allowing the task initiator or administrator to know which stage the test has reached and whether it is running normally, without needing to log in to the node to understand the execution status. Furthermore, after the target test node completes the test, it uploads the test results to the test cloud platform. The test cloud platform then returns a notification containing the test results to the initiator of the test task triggering request, enabling the initiator to directly know the final test conclusion without manual querying or summarizing, thus realizing a closed loop of data flow from triggering the request to returning the result. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the automated testing method for vehicle software provided in this application embodiment; Figure 2 This is a schematic diagram of the functional modules of the vehicle-mounted software automated testing device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the hardware structure of the vehicle-mounted software automated testing equipment involved in the embodiments of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0019] This application provides a method, apparatus, equipment, and medium for automated testing of vehicle software, which can solve the technical problem of low efficiency in automated testing of vehicle software in the prior art.

[0020] In a first aspect, embodiments of this application provide an automated testing method for in-vehicle software.

[0021] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the automated testing method for in-vehicle software provided in an embodiment of this application. Figure 1 As shown, the automated testing method for in-vehicle software specifically includes the following steps: Step S1: In response to the test task trigger request, obtain the test configuration information, and match the target test node that is in an idle state from multiple test nodes based on the test configuration information.

[0022] In this embodiment of the application, step S1 specifically includes the following steps: Step S11: In response to the test task trigger request, parse and obtain the test configuration information, which includes at least the project identifier, hardware type and bill of materials file.

[0023] Specifically, the test cloud platform receives test task trigger requests, which are either automatically initiated by the continuous integration pipeline via an API (Application Programming Interface) or manually created and initiated by the web interface. The test cloud platform parses the request to obtain the test configuration information carried within it.

[0024] The project identifier indicates the project origin of the current test task, the hardware type indicates the target hardware platform on which the software under test runs, and the bill of materials file lists the external dependent resources required for this test and their version information.

[0025] Step S12: Identify the test task type based on the bill of materials file. Test task types include package acceptance testing, integration smoke testing, and protocol stack testing.

[0026] Specifically, the bill of materials (BOM) file includes: dependencies for the automated testing environment, dependencies for test configuration files, and firmware flashing artifacts. Dependencies for the automated testing environment include the software components and their version information required for the testing framework and runtime environment. Dependencies for test configuration files include the configuration files for various parameters required for test execution. The firmware flashing artifacts are the binary files of the vehicle software firmware to be tested.

[0027] Step S13: Determine the target node labels required to perform the test task based on the project identifier and hardware type.

[0028] Specifically, node labels are pre-defined attribute identifiers on each test node, used to characterize the node's capabilities. Node labels include: Operating System Platform Type, Project-Specific Environment Identifier, and Integration Environment Type. The Operating System Platform Type indicates the operating system platform on which the node runs. The Project-Specific Environment Identifier indicates whether the node is configured with the compilation environment, debugging tools, or runtime dependencies required by the specific project. The Integration Environment Type indicates whether the node is equipped with dedicated hardware interfaces or communication protocol stacks to support integration testing.

[0029] Step S14: Match the target node label with the preset node labels of each test node, and select the test nodes with matching labels as the initial node set.

[0030] Specifically, the test cloud platform compares the target node label determined in step S13 with the preset node labels on each test node. When the preset node label on a test node completely matches the target node label, the test node is included in the initial node selection set. Test nodes whose labels do not completely match are not included in the initial node selection set.

[0031] Step S15: Remove nodes that are currently in task execution or agent process abnormal state from the initial node selection set to obtain the target test nodes.

[0032] Specifically, the test cloud platform performs status checks on each test node in the initial node selection set. This involves checking whether the node is currently executing other test tasks and whether the agent process on the node is running normally. The agent process is a resident service program running on the test node, responsible for maintaining communication with the test cloud platform and receiving execution instructions. The test cloud platform removes nodes from the initial node selection set that are currently executing tasks or whose agent processes are in an abnormal state, and uses the remaining nodes as target test nodes.

[0033] This ensures that test tasks are only assigned to nodes with a matching operating environment, avoiding situations where test execution fails due to environment incompatibility and requires rescheduling, reducing the number of invalid schedulings, and lowering the waiting delay caused by node unavailability after task distribution.

[0034] Furthermore, the test cloud platform maintains a test case library cluster. This cluster centrally stores test case files from different platforms and software versions, supporting the uploading of standard EXCEL format test cases and CANoe project format test cases, tag-based classification retrieval and download operations, and recording the global change history of each test case file. When retrieving test configuration information, if the configuration information carries a test case set identifier, the test cloud platform retrieves the corresponding platform-based test case set from the test case library cluster. If the configuration information carries a user-uploaded personalized test case file, the file is stored in a temporary area. If both exist, the platform-based test case set and the personalized test case file are merged and assembled into the final test case set used by the current task, and the storage address of the assembled test case set is included in the material download address information.

[0035] Step S2: Send a lightweight instruction packet to the target test node to instruct the target test node to pull the material file from the file server according to the address information in the lightweight instruction packet and execute the test task according to the material file.

[0036] In this embodiment of the application, step S2 specifically includes the following steps: Step S21: The lightweight instruction package is sent to the target test node. The target test node parses the material download address information according to the received lightweight instruction package and initiates identity authentication with the file server according to the node identity authentication token.

[0037] Specifically, the lightweight instruction package includes material download address information, execution startup script path, and node authentication token. The material download address information includes the software firmware download address, test case set download address, and configuration file download address. The execution startup script path indicates the storage location of the test startup program. The node authentication token verifies the legitimate identity of the target test node.

[0038] After receiving the lightweight instruction packet, the target test node parses out the material download address information and the node authentication token. Based on the node authentication token, the target test node initiates an authentication request to the file server. The file server verifies the token to confirm that the node has the authority to retrieve materials.

[0039] The lightweight instruction package contains only address information and script paths, without any physical material files. It has a small data volume and consumes minimal network bandwidth during distribution. In scenarios with concurrent scheduling across multiple nodes, the cloud platform only needs to transmit small instruction packages to each node, avoiding network congestion caused by simultaneously pushing large firmware and use case files to multiple nodes.

[0040] Step S22: After successful identity authentication, the target test node actively pulls the physical material file from the file server based on the material download address information and stores the pulled physical material file in the local isolation sandbox.

[0041] Specifically, the entity material files include software firmware, test case sets, and configuration files. The target test node stores the downloaded entity material files in a local isolated sandbox. The isolated sandbox is an independent storage area on the target test node used to isolate material files between different test tasks, preventing file overwriting or contamination.

[0042] The physical material files are actively pulled from the file server by the target test node based on the address information, shifting the initiator of material transfer from the cloud platform to the test node, thus decoupling distribution and transmission. The file server does not need to maintain push connections with each node; it only needs to respond to the node's pull request, reducing the connection management overhead on the server side.

[0043] Step S23: The target test node reads the path to the execution startup script and starts the test task corresponding to the entity material file in the local isolated sandbox.

[0044] Specifically, the target test node reads the execution startup script path from the lightweight instruction package and locates the startup script under that path. The target test node runs this startup script within an isolated sandbox. The startup script loads the entity material files and starts the test task execution program, entering the test execution phase. The material files are stored in the local isolated sandbox, and the material files for different test tasks are isolated from each other at the file system level. This avoids execution anomalies caused by file path conflicts or overwriting during concurrent execution of multiple tasks, and also facilitates the overall cleanup of material files after the task is completed, preventing residual files from occupying storage space.

[0045] Step S3: Receive the execution status information reported in real time by the target test node during the test execution cycle, and monitor the test progress based on the execution status information.

[0046] In this embodiment of the application, step S3 specifically includes the following steps: Step S31: Collect the execution status information of the current test at preset time intervals, and encapsulate the execution status information into a status synchronization message.

[0047] Specifically, the target test node collects the execution status information of the current test task at preset time intervals. The execution status information includes the material retrieval progress percentage, the current execution stage identifier, the current execution test case name, the number of real-time passed test cases, and the number of failed test cases. The material retrieval progress percentage indicates the completion status of the physical material files downloaded from the file server to the local machine. The current execution stage identifier indicates the current stage of the test. The target test node encapsulates the collected execution status information and generates a status synchronization message. This covers the key nodes of the entire test execution process, providing fine-grained execution status data to the test cloud platform.

[0048] Step S32: The status synchronization message is reported to the test cloud platform through the status synchronization interface. The test cloud platform updates the full life cycle status chain of the test task based on the received status synchronization message.

[0049] Specifically, the target test node reports the status synchronization message encapsulated in step S31 to the test cloud platform through the status synchronization interface. This status synchronization interface is a pre-agreed data transmission channel between the test cloud platform and the test node, used to carry bidirectional transmission of execution status information.

[0050] After receiving the status synchronization message, the test cloud platform parses the execution status information and updates the full-cycle status chain of the test task based on the parsing results. The status chain characterizes the various stages a test task undergoes from creation to completion, including the following status nodes: New (meaning the task has been created but not yet entered the scheduling queue); Queuing (meaning the task has entered the scheduling queue and is waiting for idle node resources); Initializing (meaning the target test node is pulling materials and preparing the execution environment); Executing (meaning the test cases are running); Result Settlement (meaning the test execution has ended and test results are being summarized and uploaded). Therefore, the test cloud platform updates the status chain in real time based on the status synchronization message, enabling the task initiator to know the current stage of the task.

[0051] In this embodiment of the application, monitoring the test progress based on execution status information includes: The test cloud platform determines whether the target test node has experienced a crash, resource suspension, or execution timeout based on the execution status information reported by the target test node. If so, an abnormal state is determined, and an intervention command is sent to the target test node through the emergency console; If not, the test progress will be continuously monitored based on the execution status information.

[0052] Specifically, a system crash event is characterized by the failure of a status synchronization message to arrive after a preset time threshold, resulting in the node being unresponsive. A resource suspension event is characterized by the current execution stage identifier in the execution status information remaining unchanged for multiple consecutive sampling periods, and the stage ending abnormally. An execution timeout event is characterized by the runtime of the current execution use case exceeding a preset time threshold.

[0053] When the testing cloud platform determines that the aforementioned abnormal event has occurred on the target testing node, it sends an intervention command to the target testing node. This intervention command is issued through a dedicated emergency console, which is a dedicated management interface provided by the testing cloud platform for authorized administrators or task initiators to operate.

[0054] Intervention commands include forced termination commands, step skip commands, environment reset commands, and physical restart commands. Forced termination commands instruct the target test node to immediately terminate the entire execution process of the current test task. Step skip commands instruct the target test node to skip the currently executing test case step and continue executing subsequent test cases. Environment reset commands instruct the target test node to restart the agent process or clear the resident data in the local isolation sandbox. Physical restart commands instruct the target test node to perform a restart operation on the physical device it resides in. Therefore, the test cloud platform can match the appropriate intervention command according to the anomaly type, completing remote recovery of abnormal nodes without requiring manual physical contact with the equipment. This reduces the waiting time caused by abnormal rack resource occupation and improves the utilization efficiency of test resources.

[0055] If the test cloud platform does not detect any abnormal events, it will continue to receive execution status information reported by the target test node according to the preset cycle to maintain monitoring of the test progress.

[0056] Step S4: After receiving the test results uploaded by the target test node after completing the test task, return a notification containing the test results to the initiator of the test task triggering request.

[0057] Specifically, the target test node collects various data files generated during test execution to form test results. Test results include at least one of the following: execution report files, in formats including at least one of HTML, XML, and JSON, used to record the execution results and statistical data of test cases; execution data outputs, i.e., process data files generated during the test; error screenshots, i.e., interface images captured when errors occur during test execution; and full device operation logs, i.e., system-level and application-level log data recorded by the target test node during test execution.

[0058] The target test node packages the collected test results and uploads them to the test cloud platform's storage service via a pre-established transmission channel. After receiving and storing the test results, the test cloud platform generates a notification message containing the test results. Based on the execution report file in the test results, the test cloud platform performs a structured assessment of the overall status of this test task. The assessment result includes any one of the following: successful execution, containing failed test cases, execution exception, or forced interruption. After the assessment is completed, the test cloud platform sends a test result notification containing the assessment result to the party that initiated the test task trigger request.

[0059] When a test task is triggered by a continuous integration pipeline via an API, the test cloud platform sends a notification back to the pipeline via an automated callback hook (webhook) so that the pipeline is informed of the final test results. When a test task is triggered manually via a web interface, the test cloud platform pushes a notification to messaging systems such as Lark, DingTalk, or email, according to pre-configured notification channels, to inform the task initiator.

[0060] In one specific embodiment, a cloud-based vehicle software automated testing system architecture is provided, the physical and logical architecture of which includes the following network entities: continuous integration server, test cloud platform, and distributed test node array.

[0061] The continuous integration server is equipped with continuous integration tools such as Jenkins to compile and build the vehicle software source code. Upon successful build, the server generates a firmware file for flashing and a test environment dependency package. The firmware file is in compressed format, and the test environment dependency package contains the software components and library files required for test execution.

[0062] The test cloud platform consists of a microservice cluster, serving as the core server of the system. It includes the following functional modules: a task gateway interface for receiving test task trigger requests and performing protocol parsing and routing; a dynamic scheduling engine for matching test nodes and allocating tasks; a test case management platform for managing the test case library cluster and assembling test cases; a real-time monitoring center for receiving execution status information reported by test nodes and monitoring test progress; and a data archiving and settlement engine for structured judgment and storage of test results. The test cloud platform also integrates an object file storage service for storing large amounts of material files, including firmware files, test case set files, and configuration files.

[0063] The distributed test node array is deployed on test benches, hardware-in-the-loop devices, or PCs. Each test node runs a lightweight node daemon, which is used to establish communication connections with the test cloud platform, receive command packets, and execute material retrieval and test tasks.

[0064] Each test node is configured with an underlying execution environment based on actual testing needs, including operating system type, hardware boards, and supporting testing software.

[0065] In another specific embodiment, a smoke test is performed on the vehicle firmware integration.

[0066] After developers submit their code, the continuous integration server automatically performs compilation and packaging operations, generating a firmware package for flashing. Once built, the continuous integration server initiates a test task trigger request to the gateway interface of the test cloud platform via the Open API (Open Application Programming Interface). The test configuration information carried in this request includes the following fields: project name, task type (integration smoke test), deliverable version number (XXX3522823AA), and the platform-specific test case set identifier that is prioritized.

[0067] After receiving the trigger request, the gateway interface of the test cloud platform parses the request to obtain the test configuration information. The dynamic scheduling engine determines the target node label based on the test configuration information, scans the heartbeat status of all currently active test nodes, and filters out test nodes whose node status is idle and whose labels meet the following conditions: the label contains "Integrated Smoke Test Bench" and "CANoe Environment". Upon successful matching, the dynamic scheduling engine generates a lightweight instruction package in JSON format, with a data size in the KB level. The lightweight instruction package does not contain physical material files, but only the following information: the download address of the firmware file, the download address of the test case file, and the storage path of the test startup script. The dynamic scheduling engine then sends this lightweight instruction package to the daemon process of the target test node.

[0068] After receiving the lightweight instruction packet, the daemon process of the target test node parses out the download addresses of each material file. Based on these download addresses, the daemon process initiates a material retrieval request to the file storage service via the internal network, sequentially downloading the firmware package, environment dependency files, and test case packages. Once the download is complete, the daemon process stores each material file in a local isolated sandbox and reads the startup script path, performing environment initialization operations within the sandbox. After initialization, it drives the test bench and the control board under test to execute smoke test cases according to the instructions in the startup script.

[0069] During test execution, the daemon process of the target test node reports execution status information to the real-time monitoring center of the test cloud platform at preset time intervals via the WebSocket protocol and HTTP interface. Execution status information includes the percentage of material retrieval progress, the identifier of the current execution stage, the name of the current execution test case, and the real-time pass / fail count. The web interface of the test cloud platform renders the test progress in real time based on the received execution status information. When a CAN bus anomaly is detected causing the control board under test to crash, the progress monitoring of the test cloud platform shows that the current execution stage has not changed after exceeding a preset time threshold. At this time, the test task initiator sends an intervention command through the emergency task console of the test cloud platform. This intervention command can be a skip command or a forced termination command. The test cloud platform sends this intervention command to the daemon process of the target test node. After receiving the command, the daemon process calls the operating system's process termination primitive to close the current test script and release system resources to prevent the test bench from being occupied for an extended period due to process freeze.

[0070] After the test task terminates, termination conditions include normal termination upon completion of all test cases and forced termination upon receiving an intervention command. The daemon process of the target test node collects various data generated throughout the entire test cycle, including structured test reports, full runtime logs, CAN message capture records, and screenshots of error reports. The daemon process compresses and packages the collected data and uploads it to the file storage service of the test cloud platform. The data archiving and settlement engine of the test cloud platform parses the uploaded test results, extracts the number of passed and failed test cases from the execution report, and performs a structured judgment based on the task termination method, marking the final state as "Forced Interruption_Including Failed Test Cases". The test cloud platform sends a notification containing the test conclusion back to the continuous integration server through a preset Webhook address, enabling the continuous integration pipeline to know the final status of this test. Simultaneously, the test cloud platform pushes a message containing the deliverable version number and a link to access the test results to the relevant personnel in the project group through the open interface of the enterprise's internal instant messaging tool. Thus, the complete data loop from code submission, build triggering, test execution to result feedback is completed.

[0071] During initial startup, the test node registers its configuration information with the test cloud platform via a node daemon. This configuration information includes the IP address, hostname, system kernel version, hardware configuration parameters, and node tag. The node tag characterizes the node's environmental capabilities, including the operating system platform type, project-specific environment identifier, and integration testing environment type.

[0072] In another specific embodiment, platform-based operation and maintenance support and management functions are provided, including two aspects: remote node operation and maintenance and use case library management.

[0073] For remote node operation and maintenance, the test cloud platform provides a web-based management interface. Through this interface, the test cloud platform receives operation and maintenance instructions for specific test nodes. These instructions are then encapsulated by the test cloud platform and sent to the daemon process of the target test node. The operation and maintenance instructions include at least one of the following types: cache clearing instructions, used to instruct the target test node to clear resident data in its local working directory; proxy restart instructions, used to instruct the target test node to restart its daemon process; and physical restart instructions, used to instruct the target test node to perform a restart operation on its physical device. Upon receiving these instructions, the daemon process invokes the corresponding operating system interface or system command to execute the corresponding operation.

[0074] For test case library management, the test cloud platform provides a test case library management interface. During the new project introduction phase, test engineers upload test case files to the test case library cluster through this interface. Test case files include CANoe project dependency packages and test data matrices in EXCEL format. During upload, test engineers add tags to the test case files. These tags identify the applicable project version or test phase for the test case file, enabling version-based management of the test case files. Uploaded test case files can be retrieved and referenced using tags. Other test tasks can directly associate the corresponding test case sets by specifying tags during the configuration phase, without needing to copy test case files from the local machine to the target node. This avoids version inconsistencies caused by manually copying test case files between multiple nodes.

[0075] This embodiment of the application obtains test configuration information and matches idle target nodes from multiple test nodes accordingly. This ensures that the selected node currently has the ability to execute tasks, avoiding the assignment of tasks to occupied or abnormal nodes and reducing the time consumed by task waiting and retries. This embodiment sends lightweight instruction packets to the target test node. Lightweight instruction packets have small data sizes and consume very little bandwidth. The physical material files are actively pulled from the file server by the target test node based on the address information of the lightweight instruction packet. This transforms material transmission from centralized push from the cloud platform to distributed pull from nodes, avoiding network congestion caused by the cloud platform simultaneously pushing large files when multiple nodes are concurrent. During execution, the target test node reports execution status information in real time. The test cloud platform can monitor the test progress based on the received status information, allowing the task initiator or administrator to know which stage the test has reached and whether it is running normally, without needing to log in to the node to understand the execution status. Furthermore, after the target test node completes the test, it uploads the test results to the test cloud platform. The test cloud platform then returns a notification containing the test results to the initiator of the test task triggering request, enabling the initiator to directly know the final test conclusion without manual querying or summarizing, thus realizing a closed loop of data flow from triggering the request to returning the result.

[0076] Secondly, embodiments of this application also provide an automated testing device for vehicle-mounted software.

[0077] In one embodiment, reference is made to Figure 2 , Figure 2 This is a schematic diagram of the functional modules of the vehicle-mounted software automated testing device provided in an embodiment of this application. Figure 2 As shown, the in-vehicle software automated testing device includes: The response module is used to respond to test task triggering requests, obtain test configuration information, and match the target test node that is in an idle state from multiple test nodes based on the test configuration information; The execution module is used to send lightweight instruction packets to the target test node, instructing the target test node to pull material files from the file server according to the address information in the lightweight instruction packet and execute test tasks according to the material files; The monitoring module is used to receive the execution status information reported in real time by the target test node during the test execution cycle, and monitor the test progress based on the execution status information. The notification module is used to send a notification containing the test results to the initiator of the test task after receiving the test results uploaded by the target test node after completing the test task.

[0078] The functions of each module in the above-mentioned vehicle software automated testing device correspond to the steps in the above-mentioned vehicle software automated testing method embodiment, and their functions and implementation processes will not be described in detail here.

[0079] Thirdly, embodiments of this application provide an automated testing device for vehicle software. The automated testing device for vehicle software includes a processor, a memory, and an automated testing program for vehicle software stored in the memory and executable by the processor. When the automated testing program for vehicle software is executed by the processor, it implements the steps of the automated testing method for vehicle software as described in any of the above embodiments.

[0080] Vehicle-mounted software automated testing equipment can be devices with data processing capabilities, such as personal computers (PCs), laptops, and servers.

[0081] Reference Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of the in-vehicle software automated testing equipment involved in the embodiments of this application. In this embodiment, the in-vehicle software automated testing equipment may include a processor, a memory, a communication interface, and a communication bus.

[0082] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0083] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting components within the vehicle-mounted software automated testing equipment, as well as interfaces used for interconnecting the vehicle-mounted software automated testing equipment with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0084] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0085] The processor can be a general-purpose processor, which can call the vehicle software automated testing program stored in the memory and execute the vehicle software automated testing method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the vehicle software automated testing program is called can be referred to in the various embodiments of the vehicle software automated testing method of this application, and will not be repeated here.

[0086] Those skilled in the art will understand that Figure 3 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0087] Fourthly, embodiments of this application provide a computer-readable storage medium storing an automated testing program for vehicle software, wherein when the automated testing program for vehicle software is executed by a processor, it implements the steps of the automated testing method for vehicle software as described in any of the above embodiments.

[0088] The present application provides a computer-readable storage medium storing an automated testing program for vehicle software, wherein when the automated testing program for vehicle software is executed by a processor, it implements the steps of the automated testing method for vehicle software as described above.

[0089] The method implemented when the vehicle software automated testing program is executed can be referred to in various embodiments of the vehicle software automated testing method of this application, and will not be repeated here.

[0090] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0091] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0092] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0093] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0094] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0095] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0096] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An automated testing method for vehicle-mounted software, characterized in that, The automated testing method for in-vehicle software includes: In response to a test task triggering request, test configuration information is obtained, and a target test node in an idle state is matched from multiple test nodes based on the test configuration information; A lightweight instruction packet is sent to the target test node to instruct the target test node to pull the material file from the file server according to the address information in the lightweight instruction packet and to execute the test task according to the material file; Receive the execution status information reported in real time by the target test node during the test execution cycle, and monitor the test progress based on the execution status information; After receiving the test results uploaded by the target test node after completing the test task, a notification containing the test results is returned to the initiator of the test task triggering request.

2. The automated testing method for vehicle-mounted software according to claim 1, characterized in that, The step of responding to a test task trigger request, obtaining test configuration information, and matching a target test node in an idle state from multiple test nodes based on the test configuration information includes: In response to a test task trigger request, test configuration information is parsed and obtained. The test configuration information includes at least the project identifier, hardware type, and bill of materials file. The test task type is identified based on the bill of materials file. The test task types include bulk package acceptance testing, integration smoke testing, and protocol stack testing. Based on the project identifier and hardware type, determine the target node label required to execute the test task; The target node label is matched with the preset node labels of each test node, and the test nodes with matching labels are selected as the initial node set. Nodes that are currently in task execution or agent process abnormality are removed from the initial selection node set to obtain the target test nodes.

3. The automated testing method for vehicle-mounted software according to claim 2, characterized in that: The bill of materials file includes: automated test environment dependencies, test configuration file dependencies, and firmware flashing artifacts; The node labels include: operating system base type, project-specific environment identifier, and integration environment type.

4. The automated testing method for vehicle-mounted software according to claim 1, characterized in that: The lightweight instruction package includes material download address information, execution startup script path, and node identity authentication token. The material download address information includes software firmware download address, use case set download address, and configuration file download address.

5. The automated testing method for vehicle-mounted software according to claim 4, characterized in that, The step of sending a lightweight instruction packet to the target test node to instruct the target test node to retrieve the material file from the file server according to the address information in the lightweight instruction packet and to execute the test task according to the material file includes: The lightweight instruction package is sent to the target test node. The target test node parses the material download address information according to the received lightweight instruction package and initiates identity authentication with the file server according to the node identity authentication token. After successful identity authentication, the target test node actively pulls the physical material files from the file server based on the material download address information and stores the pulled physical material files in the local isolation sandbox. The target test node reads the path to the execution startup script and starts the test task corresponding to the entity material file in the local isolated sandbox.

6. The automated testing method for vehicle-mounted software according to claim 1, characterized in that, The step of receiving the execution status information reported in real time by the target test node during the test execution cycle, and monitoring the test progress based on the execution status information, includes: The execution status information of the current test is collected at preset time intervals, and the execution status information is encapsulated into a status synchronization message; The status synchronization message is reported to the test cloud platform through the status synchronization interface, and the test cloud platform updates the full life cycle status chain of the test task according to the received status synchronization message. The execution status information includes the percentage of material retrieval progress, the identifier of the current execution stage, the name of the current execution test case, the number of real-time passed test cases and the number of failed test cases, and the status of the status chain is either creating, queuing, initializing, executing or settling results.

7. The automated testing method for vehicle-mounted software according to claim 6, characterized in that, Monitoring test progress based on the execution status information includes: The test cloud platform determines whether the target test node has experienced a crash, resource suspension, or execution timeout based on the execution status information reported by the target test node. If so, an abnormal state is determined, and an intervention command is sent to the target test node through the emergency console; If not, the test progress will continue to be monitored based on the execution status information. Intervention commands include forced termination commands, step skip commands, environment reset commands, or physical restart commands.

8. An automated testing device for vehicle-mounted software, characterized in that, The in-vehicle software automated testing device includes: The response module is used to respond to the test task triggering request, obtain test configuration information, and match the target test node in an idle state from multiple test nodes based on the test configuration information. The execution module is used to send a lightweight instruction packet to the target test node, instructing the target test node to pull the material file from the file server according to the address information in the lightweight instruction packet and execute the test task according to the material file; The monitoring module is used to receive the execution status information reported in real time by the target test node during the test execution cycle, and monitor the test progress based on the execution status information. The notification module is used to return a notification containing the test results to the initiator of the test task triggering request after receiving the test results uploaded by the target test node after completing the test task.

9. An automated testing device for vehicle-mounted software, characterized in that, The vehicle-mounted software automated testing equipment includes a processor, a memory, and a vehicle-mounted software automated testing program stored in the memory and executable by the processor, wherein when the vehicle-mounted software automated testing program is executed by the processor, it implements the steps of the vehicle-mounted software automated testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an automated testing program for vehicle software, wherein when the automated testing program for vehicle software is executed by a processor, it implements the steps of the automated testing method for vehicle software as described in any one of claims 1 to 7.

Images