Automobile software testing method, device, system, medium and equipment

Abstract

The invention discloses an automobile software test method, device and system, a medium and equipment, and the method comprises the steps: obtaining a test task of to-be-tested automobile software, obtaining a plurality of target test cases corresponding to the test task from a test case library, and storing the test cases corresponding to a plurality of automobile software in the test case library; target test racks are matched for target test cases from test racks to be selected in a rack resource library, rack resource information of multiple test racks is stored in the rack resource library, and the target test racks matched with at least two target test cases are different; the target test case is executed, so that in the execution process of the target test case, a target interface matched with the target test case is called from the interface database, and interaction with a corresponding target test rack is carried out through the target interface; and obtaining a target test result corresponding to each target test case. The feasibility of the automobile software can be verified in a real automobile environment, so that the applicability of a test result is improved.

Description

Technical Field

[0001] This application belongs to the field of software testing technology, and in particular relates to a method, apparatus, system, medium and equipment for testing automotive software. Background Technology

[0002] As cars become increasingly intelligent, the amount of automotive software is growing exponentially, posing challenges to the testing of automotive software.

[0003] In related technologies, a cloud-based continuous integration pipeline is built to automatically pull code and assemble packages, executing test tasks in parallel within a distributed cloud testing environment. A task scheduler manages test case dependencies, generates basic test reports (including pass rates and time statistics), and supports concurrent testing across multiple devices to improve efficiency. However, the testing scope of automotive software testing methods in these technologies is limited, and the applicability of the test results is poor. Summary of the Invention

[0004] The embodiments of this application provide an automotive software testing method, apparatus, system, medium, and equipment, which can at least to some extent verify the feasibility of automotive software in a real vehicle environment, thereby improving the applicability of the test results.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] The first aspect of this application provides a method for testing automotive software, including: Obtain the test task of the vehicle software to be tested, and obtain multiple target test cases corresponding to the test task from the test case library, wherein the test case library stores multiple test cases corresponding to the vehicle software. For each target test case, a target test bench is matched from the candidate test benches in the test bench resource library. The test bench resource library stores test bench resource information for multiple test benches, and at least two target test cases are matched with different target test benches. The target test case is executed so that during the execution of the target test case, the target test case calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface. The interface database encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench. Obtain the target test results corresponding to each target test case.

[0007] Optionally, obtaining multiple target test cases corresponding to the test task from the test case library includes: Obtain the target file directory specified by the test task; Based on the target file directory, multiple target files conforming to preset naming rules are obtained from the test case library, wherein each target file includes at least one test case; The test cases contained in the multiple target files are used as multiple target test cases corresponding to the test task.

[0008] Optionally, the step of obtaining multiple target files conforming to preset naming rules from the test case library based on the target file directory includes: Based on the target file directory, obtain multiple candidate files under the target file directory from the test case library; The filenames of each candidate file are scanned. If a candidate file's filename includes a target field, then that candidate file is selected as the target file.

[0009] Optionally, matching a target test bench for the target test case from the candidate test benches in the test bench resource library includes: If the target test case has a bench label, then the target test bench corresponding to the bench label is obtained from the candidate test benches in the bench resource library.

[0010] Optionally, the test bench resource information includes status information, which includes an idle status. Matching a target test bench for the target test case from the candidate test benches in the test bench resource library includes: If the target test case does not have a bench tag, then a test bench that is idle is queried from the bench resource library as the candidate test bench, and the target test bench is randomly matched for the target test case based on the candidate test bench.

[0011] Optionally, the test bench resource information includes status information, which includes a non-idle status. After matching a target test bench for the target test case from the candidate test benches in the test bench resource library, the method further includes: Update the status information of the target test bench in the bench resource library to non-idle status.

[0012] Optionally, executing the target test case, such that during execution, the target test case calls a target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface, includes: Obtain the target test script for the target test case; The target test script is executed so that during its execution, the target test script calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface.

[0013] Optionally, executing the target test case includes: The target test cases are executed in parallel using multiple processes.

[0014] Optionally, each target test bench is matched with multiple target test cases, and executing the target test cases includes: If the plurality of target test cases include version upgrade test cases, execute the version upgrade test cases; After the version upgrade test case is executed, other test cases among the multiple target test cases are executed.

[0015] Optionally, before executing the target test case, the method further includes: The test environment of the target test bench is initialized.

[0016] Optionally, the target interface includes at least one of the following types of interfaces: instruction execution and distribution interface, test tool interface, diagnostic interface, test environment preparation interface, test result detection interface, and test report generation interface.

[0017] Optionally, the test task of acquiring the software of the vehicle under test includes: The test task for the automotive software under test is obtained from the continuous integration and continuous deployment pipeline. The continuous integration and continuous deployment pipeline, after detecting a code change event of automotive software in the code repository, uses the automotive software with the code change event as the automotive software under test and generates a test task for the automotive software under test.

[0018] Optionally, the continuous integration and continuous deployment pipeline and / or the code repository are deployed on a cloud server.

[0019] Optionally, after obtaining the target test result corresponding to each target test case, the method further includes: Based on the test results of each target, a test report for the vehicle software under test is generated.

[0020] Optionally, after generating the test report for the vehicle software under test, the method further includes: The test report is uploaded to a cloud server, so that the cloud server performs at least one of the following steps: The test report is converted into a first display report, and the first display report is sent to the designated recipient for display. The test report is stored in the test database; A second display report is generated based on the test report, and the second display report is sent to the designated recipient for display.

[0021] Optionally, the automotive software may be one or more of the following: Ethernet communication software, controller area network software, diagnostic software, network management software, data distribution service software, process management software, status management software, mode management software, calibration software, time synchronization software, perception software, fusion software, prediction software, and planning and control software; and / or The hardware carrier of the automotive software includes one or more of the following: in-vehicle network equipment, debugging equipment, programmable power supply, relay equipment, and intelligent driving domain controller.

[0022] A second aspect of this application provides an automotive software testing apparatus, comprising: The first acquisition unit is used to acquire the test task of the vehicle software to be tested, and to acquire multiple target test cases corresponding to the test task from the test case library, wherein the test case library stores multiple test cases corresponding to the vehicle software. A matching unit is configured to match a target test bench from the candidate test benches in the test bench resource library for each target test case, wherein the test bench resource library stores test bench resource information of multiple test benches, and at least two target test cases are matched with different target test benches. An execution unit is used to execute the target test case, so that during the execution of the target test case, the target test case calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface. The interface database encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench. The second acquisition unit is used to acquire the target test result corresponding to each target test case.

[0023] Optionally, when retrieving multiple target test cases corresponding to the test task from the test case library, the first retrieval unit is used to: Obtain the target file directory specified by the test task; Based on the target file directory, multiple target files conforming to preset naming rules are obtained from the test case library, wherein each target file includes at least one test case; The test cases contained in the multiple target files are used as multiple target test cases corresponding to the test task.

[0024] Optionally, when retrieving multiple target files conforming to preset naming rules from the test case library based on the target file directory, the first retrieval unit is used to: Based on the target file directory, obtain multiple candidate files under the target file directory from the test case library; The filenames of each candidate file are scanned. If a candidate file's filename includes a target field, then that candidate file is selected as the target file.

[0025] Optionally, when matching a target test bench for the target test case from the candidate test benches in the test bench resource library, the matching unit is used to: If the target test case has a bench label, then the target test bench corresponding to the bench label is obtained from the candidate test benches in the bench resource library.

[0026] Optionally, the test bench resource information includes status information, which includes an idle status. When matching a target test bench for the target test case from the candidate test benches in the test bench resource library, the matching unit is used to: If the target test case does not have a bench tag, then a test bench that is idle is queried from the bench resource library as the candidate test bench, and the target test bench is randomly matched for the target test case based on the candidate test bench.

[0027] Optionally, the test bench resource information includes status information, which includes a non-idle status. After matching a target test bench for the target test case from the candidate test benches in the test bench resource library, the device is further configured to: Update the status information of the target test bench in the bench resource library to non-idle status.

[0028] Optionally, when executing the target test case, such that during execution, the target test case calls a target interface adapted to the target test case from the interface database and interacts with the corresponding target test bench through the target interface, the execution unit is used to: Obtain the target test script for the target test case; The target test script is executed so that during its execution, the target test script calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface.

[0029] Optionally, when executing the target test case, the execution unit is used to: The target test cases are executed in parallel using multiple processes.

[0030] Optionally, each target test bench is matched with multiple target test cases. When executing the target test cases, the execution unit is used to: If the plurality of target test cases include version upgrade test cases, execute the version upgrade test cases; After the version upgrade test case is executed, other test cases among the multiple target test cases are executed.

[0031] Optionally, before executing the target test case, the execution unit is further configured to: The test environment of the target test bench is initialized.

[0032] Optionally, the target interface includes at least one of the following types of interfaces: instruction execution and distribution interface, test tool interface, diagnostic interface, test environment preparation interface, test result detection interface, and test report generation interface.

[0033] Optionally, when acquiring the test task of the vehicle software under test, the first acquisition unit is used to: The test task for the automotive software under test is obtained from the continuous integration and continuous deployment pipeline. The continuous integration and continuous deployment pipeline, after detecting a code change event of automotive software in the code repository, uses the automotive software with the code change event as the automotive software under test and generates a test task for the automotive software under test.

[0034] Optionally, the continuous integration and continuous deployment pipeline and / or the code repository are deployed on a cloud server.

[0035] Optionally, after obtaining the target test result corresponding to each target test case, the device is further configured to: Based on the test results of each target, a test report for the vehicle software under test is generated.

[0036] Optionally, after generating the test report for the vehicle software under test, the device is further configured to: The test report is uploaded to a cloud server, so that the cloud server performs at least one of the following steps: The test report is converted into a first display report, and the first display report is sent to the designated recipient for display. The test report is stored in the test database; A second display report is generated based on the test report, and the second display report is sent to the designated recipient for display.

[0037] Optionally, the automotive software may be one or more of the following: Ethernet communication software, controller area network software, diagnostic software, network management software, data distribution service software, process management software, status management software, mode management software, calibration software, time synchronization software, perception software, fusion software, prediction software, and planning and control software; and / or The hardware carrier of the automotive software includes one or more of the following: in-vehicle network equipment, debugging equipment, programmable power supply, relay equipment, and intelligent driving domain controller.

[0038] A third aspect of this application provides an automotive software testing system, comprising: The interface layer includes an interface database, which encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench. The test case layer communicates with the interface layer. The test case layer includes a test case library, which stores multiple test cases corresponding to automotive software. An execution control layer, communicatively connected to the test case layer, is used to acquire test tasks for the vehicle software under test, and to retrieve multiple target test cases corresponding to the test tasks from a test case library. For each target test case, a target test bench is matched from the candidate test benches in the test bench resource library, wherein the test bench resource library stores test bench resource information for multiple test benches, and at least two target test cases are matched with different target test benches. The target test cases are executed so that during execution, the target test cases call target interfaces adapted to the target test cases from the interface database, and interact with the corresponding target test benches through the target interfaces. The target test results corresponding to each target test case are then obtained.

[0039] A fourth aspect of this application provides a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to perform the operation as described in any of the methods in the first aspect.

[0040] A fifth aspect of this application provides an electronic device including one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to perform the operation as described in any of the methods in the first aspect.

[0041] The one or more technical solutions provided in the embodiments of the present invention achieve at least the following technical effects or advantages: The automotive software testing method of this application includes: obtaining a test task for the automotive software to be tested; obtaining multiple target test cases corresponding to the test task from a test case library, wherein the test case library stores multiple test cases corresponding to the automotive software; for each target test case, matching a target test bench from a pool of candidate test benches in a test bench resource library, wherein the test bench resource library stores test bench resource information for multiple test benches, and at least two target test cases are matched with different target test benches; executing the target test case, such that during execution, the target test case calls a target interface adapted to the target test case from an interface database, and interacts with the corresponding target test bench through the target interface, wherein the interface database encapsulates the interfaces required for the multiple automotive software test cases to interact with the test bench; and obtaining the target test result corresponding to each target test case.

[0042] Therefore, this embodiment of the application, by enabling test cases to interact with automotive test benches, closely correlates the execution environment of the test cases with real-vehicle simulations. This makes the testing scope more aligned with real-vehicle needs, allowing for the verification of the feasibility of automotive software in a real-vehicle environment, thereby improving the applicability of the test results. Furthermore, this embodiment of the application encapsulates the interfaces required for interaction between multiple automotive software test cases and the test benches through an interface database. This allows for the invocation of corresponding target interfaces to interact with the test benches as needed during test case execution, improving interface reusability. Additionally, this embodiment of the application allocates multiple target test cases corresponding to the test tasks of the automotive software under test to different target test benches, enabling the parallel execution of target test cases on different target test benches, thus improving testing efficiency.

[0043] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can derive other drawings from these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating an embodiment of the automotive software testing method of this application is shown; Figure 2 A detailed flowchart of step S10 in an embodiment of this application is shown; Figure 3 A detailed flowchart of step S102 in an embodiment of this application is shown; Figure 4 This paper illustrates a schematic diagram of the matching process between target test cases and target test benches according to an embodiment of this application. Figure 5 A first detailed flowchart of step S30 of an embodiment of this application is shown; Figure 6 A second detailed flowchart of step S30 of an embodiment of this application is shown; Figure 7 A structural diagram of an automotive software testing apparatus according to an embodiment of this application is shown; Figure 8 A structural diagram of an automotive software testing system according to an embodiment of this application is shown; Figure 9 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0045] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0046] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0047] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different models and / or processor devices and / or microcontroller devices.

[0048] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0049] It should also be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such uses of these terms can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described.

[0050] As cars become increasingly intelligent, the amount of automotive software is growing exponentially, posing challenges to the testing of automotive software.

[0051] In related technologies, a cloud-based continuous integration pipeline is built to automatically pull code and assemble packages, executing test tasks in parallel within a distributed cloud testing environment. A task scheduler manages test case dependencies, generates basic test reports (including pass rates and time statistics), and supports concurrent testing across multiple devices to improve efficiency. However, the testing scope of automotive software testing methods in these technologies is limited, and the applicability of the test results is poor.

[0052] In view of this, embodiments of this application provide an automotive software testing method. This method interacts test cases with an automotive test bench, making the execution environment of the test cases closely related to real-vehicle testing. The testing scope better matches the needs of real-vehicle testing, enabling verification of the feasibility of automotive software in a real-vehicle environment, thereby improving the applicability of test results. Furthermore, embodiments of this application encapsulate the interfaces required for interaction between multiple automotive software test cases and the test bench through an interface database. This allows for the invocation of corresponding target interfaces to interact with the test bench as needed when executing test cases, improving interface reusability. Additionally, embodiments of this application allocate multiple target test cases corresponding to the test tasks of the automotive software under test to different target test benches, enabling parallel execution of target test cases on different target test benches, thus improving testing efficiency.

[0053] The automotive software testing method of this application embodiment will be described below with reference to the accompanying drawings.

[0054] Figure 1 A flowchart illustrating an embodiment of the automotive software testing method of this application is shown.

[0055] Understandably, in an automotive software testing environment, multiple test benches and test control terminals (such as computers) can be deployed. These test benches and test control terminals together constitute the testing and verification environment for automotive software. The test benches can be used to realistically simulate the vehicle's network, power supply, and sensor environments, while the test control terminals can be used to execute test cases and interact with the test benches, thereby testing and verifying the automotive software.

[0056] The first aspect of this application provides an automotive software testing method, which can be executed on the aforementioned test control terminal. The method includes, but is not limited to: Step S10. Obtain the test task of the vehicle software to be tested, and obtain multiple target test cases corresponding to the test task from the test case library, wherein the test case library stores multiple test cases corresponding to the vehicle software. In some embodiments, the test task for acquiring the vehicle software under test includes: The test task for the automotive software under test is obtained from the continuous integration and continuous deployment pipeline. The continuous integration and continuous deployment pipeline, after detecting a code change event of automotive software in the code repository, uses the automotive software with the code change event as the automotive software under test and generates a test task for the automotive software under test.

[0057] Understandably, in the automotive software development process, the Continuous Integration and Continuous Deployment (CI / CD) pipeline is the engine driving rapid and high-quality software delivery. This pipeline monitors software code development activities in real time through event listeners integrated into the code repository. Once a code change event is detected, such as a new code commit or merge request (e.g., a code developer commits new software code to a code repository (e.g., GitLab), the pipeline is triggered, marking the changed software component as automotive software and creating a corresponding test task for it.

[0058] It should be noted that the automotive software testing method in this application embodiment can be implemented based on the PyTest automated testing framework. After creating a new test task in the continuous integration and continuous deployment pipeline, the entry point of the PyTest automated testing framework can be called to distribute the test task.

[0059] In some embodiments, the continuous integration and continuous deployment pipeline and / or the code repository are deployed on a cloud server.

[0060] Understandably, by deploying continuous integration and continuous deployment pipelines and / or code repositories on cloud servers, automotive software development teams can collaborate on development by accessing the cloud code repository via the internet, regardless of their location. When a code commit event is triggered, the powerful computing resources provided by the cloud service provider automatically launch a temporary and standardized build environment. This environment is dynamically created on demand and released immediately after code compilation, dependency management, and software image packaging are completed. Subsequently, the generated test tasks and related components are distributed to the local testing site via a secure network channel.

[0061] The test case library storing multiple test cases corresponding to automotive software can refer to a test case library built based on the PyTest automated testing framework. The following is an illustrative explanation of the test case library construction process.

[0062] Based on the principles of structured and standardized testing, and through in-depth analysis of automotive software product requirements, the testing team must collaborate closely with software engineers to transform written requirements, functional points, and non-functional requirements into executable and verifiable test cases. Test cases for different automotive software can be written using specific formats to improve their reusability. These test cases can cover various levels, including unit testing, integration testing, system testing, and vehicle testing. Each test case should clearly indicate its test objectives, preconditions, input data, execution steps, and expected results.

[0063] In addition to requirement-based positive testing exceptions, black-box testing methods such as boundary value analysis, equivalence class partitioning, and error guessing can be introduced, supplemented by white-box test cases for complex logic modules to ensure code coverage. As testing activities continue, the test case library itself also needs a dynamic evolution mechanism. For example, defects discovered during testing can be traced back to their root causes, not only fixing the defects themselves but also analyzing their reasons. Based on this analysis, corresponding regression test cases can be added to the test case library, forming a closed loop of defect-driven test case improvement. Thus, a continuously optimized test case library will provide a solid guarantee for software quality.

[0064] In this embodiment, the automotive software includes one or more of the following: underlying software, middleware, basic services, perception, fusion, planning and control software, etc. The underlying software may include: Ethernet communication software, controller area network software, diagnostic software, and network management software; the middleware may include: data distribution service software, process management software, state management software, and mode management software; the basic service software may include: calibration software and time synchronization software.

[0065] The following provides examples of test cases for different automotive software.

[0066] For underlying software, test cases focus on communication reliability, real-time performance, and standards compliance. For example, for Ethernet communication software, test cases might include: "verifying that the end-to-end transmission delay of critical messages is less than 10ms under full bandwidth load," and "verifying the correctness of the SOME / IP service discovery mechanism and whether services can be published / subscribed normally when online / offline." For Controller Area Network (CAN) software, test cases might include: "simulating whether CAN communication can automatically recover within a specified time without losing critical messages after a short-term physical bus failure," and "verifying whether the arbitration mechanism of CANFD messages is normal after the data field acceleration phase." For diagnostic software, test cases might include: "verifying whether the ECU can correctly return the current firmware version number by sending a 22 read data identifier service via a diagnostic tool," and "simulating sending three consecutive 1002 session control service requests to verify whether the ECU can successfully switch to and maintain an extended diagnostic session." For middleware, test cases focus on the efficiency of data distribution and the robustness of system state management. For example, for data distribution service software, test cases may include "creating multiple data publishers and subscribers to verify the accuracy of topic-based data routing and filtering functions," and "simulating a network environment with data packet loss to verify whether the persistence function can ensure that historical data is correctly received by newly joined subscribers." For state management software, test cases may include: "simulating the system's power-on, power-off, and sleep-wake processes to verify whether the software can strictly follow the predefined state machine for switching and perform the correct initialization or deinitialization operations in each state."

[0067] For basic service software, test cases focus on the accuracy and consistency of the services. For example, for calibration software, test cases may include: "Verifying the ECU's ability to respond in real time and correctly save the new parameters in non-volatile memory by modifying the engine idle target speed calibration parameters online via the CCP / XCP protocol," and "Verifying the management of access permissions for calibration parameters, such as ensuring that read-only parameters cannot be modified." For time synchronization software, test cases may include: "Simulating network jitter between the ECU (as a time slave node) and the master clock to verify that its clock synchronization algorithm can converge the time error to within ±1 microsecond," and "Simulating master clock failure to verify that the backup clock switching mechanism can be correctly triggered."

[0068] For perception software, test cases may include: "Injecting image sequences containing complex scenes such as occlusion and backlighting into the camera perception algorithm to verify whether it can continuously output a list of valid targets such as vehicles and pedestrians, and whether the false detection rate and missed detection rate are below the threshold."

[0069] For fusion software, test cases may include: "simulating a scenario where radar and camera have different distance and orientation measurements of the same target, verifying whether the fusion algorithm can weight the data according to confidence level and output a more accurate and stable target trajectory."

[0070] For planning and control software, test cases may include: "Simulating a scenario where the vehicle in front suddenly decelerates during a lane change in a simulation environment, verifying whether the planning module can generate a safe and smooth lane change or following trajectory while meeting comfort constraints, and whether the control module can execute it accurately."

[0071] It is understandable that the automated execution of test cases requires test scripts. Therefore, in this embodiment, in addition to creating a test case library, a test script corresponding to each test case can also be created, so that the test script can be used as a carrier for automated test case testing to achieve automated software testing.

[0072] In some embodiments, the hardware carrier of the automotive software includes one or more of the following: in-vehicle network equipment, debugging equipment, programmable power supply, relay equipment, and intelligent driving domain controller.

[0073] For example, an in-vehicle network device includes: One or more of the following: Ethernet devices, CAN (Controller Area Network) network devices, and CANFD (Controller Area Network with Flexible Data Rate) network devices.

[0074] For example, the debugging device includes one or more of a serial port device and an ADB (Android Debug Bridge) device.

[0075] It is understood that the hardware carrier of the aforementioned vehicle is the device under test in the embodiments of this application, and the aforementioned hardware carrier is deployed in one or more test benches.

[0076] In some embodiments, other testing equipment may also be included, such as: 1. Sensors and Actuators. Sensors include, for example, in-vehicle Ethernet / camera video injectors and GNSS (Global Navigation Satellite System). Actuators include, for example, steering torque simulators and brake load simulators, used to simulate the actual working load of the actuators on a bench to verify the correctness of the control software output.

[0077] 2. Vehicle Motion and Dynamics Driver: A device that integrates a six-degree-of-freedom motion platform, a visual system, and a steering wheel force feedback system.

[0078] 3. Other key domain controllers and gateways. For example, the cockpit domain controller: as the core of the in-vehicle infotainment system and human-machine interface, it is the direct carrier for running the operating system, application software, and UI rendering software. The body domain controller: responsible for controlling body accessories such as windows, doors, lights, and wipers; its hardware is the carrier for running body control logic, power management, and diagnostic software. The central gateway: as the data hub of the entire vehicle network, its hardware is the carrier for running communication management software such as routing and forwarding, protocol conversion, and network security firewalls.

[0079] 4. Dedicated diagnostic and flashing tools. Diagnostic and flashing tools, such as engineering diagnostic instruments or mass production diagnostic instruments, are embedded devices that run specific diagnostic application software. They are indispensable hardware carriers for performing operations such as ECU software flashing, fault code reading, and parameter configuration.

[0080] It is understood that the test device under test and other test devices in the embodiments of this application provide a real and controllable software test execution environment for the upper layer (e.g., a computer).

[0081] Figure 2 A detailed flowchart of step S10 of an embodiment of this application is shown.

[0082] In some embodiments, obtaining multiple target test cases corresponding to the test task from the test case library includes: Step S101. Obtain the target file directory specified by the test task; Understandably, step S101 is the path-finding phase for test task execution. By parsing the test task descriptor, the target file directory corresponding to the vehicle software under test can be located. When a test task is deployed in the continuous integration pipeline, the test task is not a simple instruction, but a structured data packet (which can be in JSON or XML format). The data packet contains a file field specifying the target file directory. By parsing these fields, one or more explicit target file directory paths can be obtained. This path is essentially a logical index in the test case library, which may correspond to the module name, functional component, or path in the code repository of the vehicle software under test. For example, the task-specified directory might be " / test_cases / domain_controller / planning / ", indicating that this test focuses on the "Intelligent Driving Domain Controller - Planning Module". Obtaining the target file directory avoids scanning the entire test case library, enabling efficient screening of test cases, defining a clear scope for subsequent test case retrieval, thereby improving task scheduling efficiency and reducing resource overhead.

[0083] Step S102. Based on the target file directory, obtain multiple target files that conform to the preset naming rules from the test case library, wherein each target file includes at least one test case; Understandably, after determining the search scope, step S102 is used for intelligent filtering and batch retrieval within the target file directory. For example, based on naming rules predefined in the testing framework, all files in the target file directory are scanned to ensure accurate identification of the target files. For instance, the rules might require all test case files to be prefixed with "test_" and suffixed with ".py" or ".xml"; or require the filename to contain the ID of the requirement being tested, such as "REQ_ADAS_FCW_001". By traversing the target file directory and its subdirectories, and utilizing file system APIs or version control tools (such as Git), all target files conforming to the rules are filtered out, forming a list of target files. This ensures that test scripts that have undergone standardized management and are strongly relevant to the current testing task are selected, excluding interference from irrelevant resources such as configuration files, documents, and temporary files.

[0084] Figure 3 A detailed flowchart of step S102 of an embodiment of this application is shown.

[0085] In some embodiments, obtaining multiple target files conforming to preset naming rules from the test case library based on the target file directory includes: Step S1021. Based on the target file directory, obtain multiple candidate files under the target file directory from the test case library; Understandably, step S1021 is the initial screening stage of test case file retrieval. Through a breadth-first search, all potentially relevant files in the target file directory are initially collected. After receiving the target file directory path parsed in the previous step, the system calls the file system operation interface to initiate a recursive traversal of the target file directory. This traversal will visit all subfolders under this path, aiming to obtain an initial set of files as comprehensive as possible, i.e., a list of "candidate files". For example, when the target directory is / test_cases / domain_controller / , the system will include all files in this directory and its subdirectories such as perception / , fusion / , planning / , etc., in the candidate range.

[0086] Step S1022. Scan the filenames of each candidate file. If the filename of a candidate file includes a target field, then the candidate file is selected as the target file.

[0087] In step S1022, after obtaining the list of candidate files, one or more "target fields" are extracted according to the naming conventions defined in the predefined test architecture. These target fields are key identifiers for test case classification and identification. For example, target fields might represent test types like "smoke" or "regression," or functional modules like "diagnostic" or "can_fd" (CANFD communication), or requirement numbers like "req_2024_." Each candidate file's filename is scanned one by one to check if it contains any of the specified target fields. This matching process is generally case-insensitive and supports wildcards or regular expressions for enhanced flexibility. Through this step, files containing the target fields are identified as target files, while files not containing the target fields are filtered out.

[0088] Step S103. Use the test cases contained in the multiple target files as multiple target test cases corresponding to the test task.

[0089] In some embodiments, after obtaining multiple target files, the method further includes: The target file is mapped to a test case object that the test execution engine can recognize and invoke.

[0090] For script files (such as Python), the system identifies all functions starting with "test_" or test classes inheriting from a specific base class through module import or reflection. For data files (such as Excel or YAML), it parses each row or block of data, converting it into a parameterized test case instance. Ultimately, the system outputs a complete and structured list of target test cases. This list is then passed to the scheduler, which distributes the test cases to the corresponding test benches for execution, thus automating the process from task definition to test case readiness and laying the foundation for subsequent test execution.

[0091] Step S20. For each target test case, match a target test bench from the candidate test benches in the test bench resource library, wherein the test bench resource library stores test bench resource information of multiple test benches, and at least two target test cases are matched with different target test benches; It is understood that the test bench in this application embodiment can refer to a hardware-in-the-loop (HIL) system built at a test site to verify automotive software. Its core function is to simulate the operating environment of the target software in a real vehicle. By integrating real ECU hardware, a vehicle and sensor model running in real-time on a processor, and a complete bus network (such as CAN or Ethernet), it constitutes a controlled and reproducible closed-loop test platform. This platform enables automotive engineers to efficiently perform functional verification, performance testing, fault injection, and automated regression testing before vehicle production, and is a key infrastructure for ensuring the functional safety, reliability, and quality of automotive software.

[0092] In this embodiment of the application, by obtaining bench resource information of several test benches at the automotive software testing site, a bench resource library can be constructed, thereby pooling and managing each test bench, providing resource application and reclamation interfaces for the upper-layer scheduler, ensuring that resources are not repeatedly allocated or conflicted, and maximizing resource utilization.

[0093] The following is an example of how to construct a rack resource library.

[0094] When each test bench is added to the database, it is abstracted into a set of structured attribute information (bench resource information), including but not limited to: hardware resources, software and environment, and status information. Hardware resources record the core configuration of the test bench, such as the domain controller model, ECU hardware version, network type (CAN / CANFD / vehicle Ethernet), power management module model, and connected sensor simulators (e.g., GNSS simulator, video injector) or actuator loads. Software and environment describe its software environment, such as operating system version, pre-installed underlying software (AUTOSAR version), debugging toolchain (e.g., ADB, CANoe), and supported test scripting languages ​​(e.g., Python, CAPL). Status information is collected and updated in real-time by a lightweight agent deployed on the test bench, including its current status (e.g., idle, occupied, faulty, under maintenance), the currently executing task ID, and the estimated remaining task time.

[0095] After abstracting the test bench into a set of structured attribute information, this attribute information is stored in the test bench repository, which provides a RESTful API interface (Representational...). The StateTransferApplicationProgrammingInterface (SIP) interface represents the state transfer application programming interface. This interface allows the test framework to query bench resource information in real time and match it according to the requirements of the target test cases, thereby forming a centrally managed, dynamically updated, and globally visible test bench resource pool.

[0096] In some embodiments, matching a target test bench for the target test case from the candidate test benches in the test bench resource library includes: If the target test case has a bench label, then the target test bench corresponding to the bench label is obtained from the candidate test benches in the bench resource library.

[0097] Understandably, by parsing the target test cases, it's possible to identify whether they have predefined specific bench labels. Bench labels can be abstract codes representing the functional and resource requirements of the target test cases for their required testing environment. For example, "hw_autosar_4.3" indicates a test bench supporting classic AUTOSAR 4.3 is required, "network_eth_switch" indicates a need for an automotive Ethernet switch, and "sensor_camera_injection" indicates a need for camera video injection capabilities.

[0098] Once it's confirmed that the target test case carries a bench tag, a query request is initiated to the bench resource library. This query request is not a blind resource scan, but rather uses these tags as filtering conditions to quickly retrieve the target test bench containing the specified tags from all currently available or idle candidate test benches. For example, if a test case is tagged with both "domain_controller_ad" and "can_fd", the matching process will look for benches that satisfy both tags, excluding devices that only support traditional CAN or belong to cockpit domain control.

[0099] Therefore, this tag-based matching strategy can efficiently complete resource scheduling, ensuring that target test cases can be executed on test benches with the necessary hardware and software capabilities, thus guaranteeing the effectiveness of the tests. It also improves the utilization rate of test bench resources and the scheduling efficiency of test tasks, making it a key link in realizing the parallel automated execution of large-scale and multi-type test tasks.

[0100] In some embodiments, the test bench resource information includes status information, the status information including an idle status, and the step of matching a target test bench for the target test case from the candidate test benches in the test bench resource library includes: If the target test case does not have a bench tag, then a test bench that is idle is queried from the bench resource library as the candidate test bench, and the target test bench is randomly matched for the target test case based on the candidate test bench.

[0101] Understandably, when the target test case does not have a bench label, it may be a general-purpose or resource-insensitive test case, with no special hardware or software dependencies on the execution environment. In this case, a query is initiated to the bench resource library, with the core filtering condition being that the status information equals the idle state. This quickly identifies all currently available test benches, which may vary in model and configuration, but are all ready to perform basic testing tasks. Subsequently, a target test bench is randomly assigned to the test case from among the candidate test benches using a random algorithm. This random matching method has several advantages: First, it achieves load balancing, avoiding excessive concentration of use of certain high-performance or newly configured benches while other benches remain idle for extended periods, thereby improving the overall utilization efficiency of the resource library; second, it simplifies the scheduling logic, eliminating the need for complex priority calculations or resource capacity assessments, resulting in fast decision-making and low computational resource overhead; third, this indiscriminate allocation strategy actually helps to discover hidden defects that only surface under specific environments, increasing the coverage and robustness of the tests.

[0102] Figure 4 This illustration shows a schematic diagram of the matching process between target test cases and target test benches in an embodiment of this application.

[0103] like Figure 4 As shown, for a target test case, it is determined whether a test bench is specified for the target test case. If so, the test case is precisely assigned to the specified target test bench and the test is executed. After the test is completed, the test bench resources are released. If not, an idle test bench is dynamically assigned and the test is executed. After the test is completed, the test bench resources are released.

[0104] In some embodiments, the bench resource information includes status information, the status information including a non-idle status, and after matching a target test bench for the target test case from the candidate test benches in the bench resource library, the method further includes: Update the status information of the target test bench in the bench resource library to non-idle status.

[0105] Understandably, updating the status information of a target test bench in the bench resource library after matching it with a target test case ensures data consistency and scheduling reliability. This achieves real-time synchronization between the physical status of the test bench and the digital records in the bench resource library. Once the scheduling algorithm makes a decision to assign a target test bench to a target test case, a status update request can be initiated through the management interface provided by the bench resource library. This request will change the status information of the target test bench from idle to non-idle. The non-idle status can be a broad category or further refined into more precise sub-status values. For example, "Assigned": indicates that the bench has been reserved for a task, but the test has not yet officially started; "Under Testing": indicates that the bench is executing a test script and is in a busy working state; "Waiting": indicates that the bench has completed the current test but is currently uploading results, cleaning up the environment, or waiting for the next instruction.

[0106] Understandably, updating the status of the target test bench can prevent multiple test tasks from being scheduled to the same test bench simultaneously, thereby avoiding resource conflicts and test execution chaos.

[0107] Step S30. Execute the target test case so that during the execution of the target test case, the target test case calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface. The interface database encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench. In some embodiments, the target interface includes at least one of the following types of interfaces: instruction execution and distribution interface, test tool interface, diagnostic interface, test environment preparation interface, test result detection interface, and test report generation interface.

[0108] For example, the test tool interface may be one or more of the CANoe interface and the CANape interface; the diagnostic interface may be one or more of the DoCAN interface and the DoIP interface; and the command execution and distribution interface may be one or more of the SSH (Secure Shell) interface, the SCP (Secure Copy Protocol) interface, the ADB interface, and the serial port.

[0109] Specifically, the test environment preparation interface refers to the interface that initializes and configures the test bench before test case execution. The test result detection interface refers to the interface that acquires, monitors, and asserts test data from the test bench in real time during or after test execution. The test report generation interface refers to the interface that collects, formats, and persists test results (including pass / fail status, detailed logs, timing data, error screenshots, etc.) after test completion.

[0110] In this embodiment, an interface database provides standardized interface adaptation, addressing the fragmentation problem of the toolchain. The construction of the interface database is a systematic project used to standardize, centralize, and decouple the interaction interfaces between test cases and test benches.

[0111] The following is an example of how to build an interface database.

[0112] First, interface abstraction and definition can be performed. The underlying control commands, communication protocols, and APIs of various test benches (such as HIL benches and diagnostic benches) are analyzed, and their common interactive operations are abstracted into unified logical interfaces. Clear input and output parameters and behavioral specifications are defined for these interfaces, such as "connect to bench," "send CAN message," "execute diagnostic session control," and "read measurement signals." Next, interface implementation and encapsulation are performed. For each defined logical interface, specific adapter code or configuration files are written to bridge the standard interface with bench-specific hardware drivers or software tools (such as CANoe and vTESTstudio). For example, the "command issuance interface" might encapsulate CANoe's CAPL function calls at the underlying level, while the "diagnostic interface" encapsulates the specific implementation details of ODS or UDS services. Finally, the database entry and lifecycle management phase is performed. All encapsulated and tested interfaces are registered in a centralized interface database with their metadata (such as interface type, functional description, applicable bench model, and version number). The interface database continuously maintains the version, status, and dependencies of all interfaces.

[0113] Thus, through the interface database, test case developers are freed from direct dependence on specific test bench hardware. They can achieve seamless interaction with heterogeneous testing environments simply by declaratively calling standardized target interfaces in the database, which greatly improves the reusability, maintainability, and reliability of automated processes of test cases.

[0114] Figure 5 A first detailed flowchart of step S30 of an embodiment of this application is shown.

[0115] In some embodiments, executing the target test case, such that during execution, the target test case calls a target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface, includes: Step S301. Obtain the target test script for the target test case; Understandably, a target test case is a specification document that defines the test objective, preconditions, input data, and expected results. Its automated execution relies on an entity—the test script. After matching the target test case to a suitable target test bench, the corresponding target test script can be located and retrieved from a version-controlled script repository based on the target test case's unique identifier (such as ID or name). This script file (usually in Python, CAPL, or XML format) is the carrier of the automated implementation of the target test case, encoding all necessary control logic, decision flows, and verification points. The retrieval process is not a simple file download; it may involve version verification to ensure the script version is compatible with the software under test; it may also include dependency checks to ensure all necessary library functions or configuration files are in place. Then, the target test script is securely deployed to the test execution machine (e.g., a process) connected to the target test bench, preparing static code for the next stage of dynamic interaction.

[0116] Step S302. Execute the target test script so that during the execution of the target test script, it calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface.

[0117] Understandably, once the test execution engine (such as pytest) starts the target test script, the script begins to run line by line. The script doesn't necessarily contain low-level commands directly coupled to specific bench hardware or proprietary tools; instead, it uses predefined function names to make calls to the interface database. For example, when the script needs to control the bench power supply, it calls an abstract interface like `power_supply.set_voltage(12.5)`. Upon receiving the request, the interface database routes and translates it into specific instructions that the underlying bench can recognize. This could involve controlling the programmable power supply via SCPI (Standard Commands for Programmable Instruments) commands, or simulating a network management message in CANoe using CAPL (CAN Access Programming Language) code. This decouples the test logic from the hardware control. The entire interaction process is bidirectional: the target test script sends control signals to the target test bench through the command issuance interface and the diagnostic interface, then reads response signals and bus data from the bench through the test result detection interface, and outputs structured test results using the test report generation interface. In this way, the target test script can interact with complex test bench environments in a standardized and portable manner.

[0118] In some embodiments, executing the target test case includes: The target test cases are executed in parallel using multiple processes.

[0119] For example, the test scheduler or execution engine, acting as the main process, does not execute the target test cases and their matching bench resources sequentially after acquiring a batch of test cases to be executed. Instead, it dynamically creates a group of child processes based on the current system's computing resources (such as the number of CPU cores and memory capacity) and the availability of bench resources. Each child process is given an independent execution environment, specifically responsible for hosting and running a specific target test case. These child processes are completely isolated from each other in terms of memory space and runtime state, thereby avoiding mutual interference between test scripts, variables, or environment configurations, and ensuring the accuracy and independence of test results.

[0120] This significantly reduces the execution time of large test suites that would otherwise take hours or even days to complete, enabling rapid test feedback and supporting agile development and continuous integration. Secondly, it allows for full utilization of test bench resources, reducing idle time and thus lowering overall testing costs. Furthermore, process-level isolation enhances the robustness of test execution; even if one test process crashes due to unforeseen circumstances, it will not affect the normal execution of other parallel processes, ensuring the overall progress of the testing task.

[0121] Figure 6 A second detailed flowchart of step S30 of an embodiment of this application is shown.

[0122] In some embodiments, each target test bench is matched with multiple target test cases, and executing the target test cases includes: Step S303. If the plurality of target test cases include version upgrade test cases, execute the version upgrade test cases; When multiple target test cases on the same target test bench include version upgrade test cases (such as ECU software flashing or firmware update tests), they are scheduled for execution in the highest priority order. The execution process of the version upgrade test case involves downloading the specified new version software package to the ECU on the test bench via a diagnostic interface or refresh protocol, and completing subsequent operations such as verification and activation. This aims to establish a known and unified software benchmark environment for all subsequent tests, preventing batch test failures due to mismatches between the ECU software version on the test bench and the expected test case version, thus ensuring the effectiveness of subsequent testing processes.

[0123] Step S304. After the version upgrade test case is executed, execute the other test cases in the plurality of target test cases.

[0124] In some embodiments, prior to executing the target test case, the method further includes: The test environment of the target test bench is initialized.

[0125] It is understandable that initializing the test environment of the target test bench before executing the target test cases is a crucial prerequisite for ensuring the reliability of the test results. This initialization can be accomplished by calling the test environment preparation interface. For example, firstly, the hardware state is reset, such as by cyclically powering on and off the ECU under test using a programmable power supply to clear any potential abnormal states. Secondly, the software environment is configured, such as closing irrelevant background processes, starting necessary simulation models (e.g., vehicle dynamics model, virtual ECU), loading the specified communication database (DBC, LDF, etc.), and configuring measurement and calibration tools. Finally, communication connections are established, all bus channels (CAN / CAN FD, Ethernet, etc.) are initialized, and sessions with the diagnostic tool and refresh tool are established. This eliminates interference caused by remnants from previous tests or environmental differences.

[0126] Step S40. Obtain the target test results corresponding to each target test case.

[0127] Understandably, after the target test case is executed, the return value or exit status code of the test script can be captured, serving as the top-level conclusion (e.g., pass, fail, error) for that target test case. Furthermore, by calling the test result detection interface, process data can be extracted from the test bench, measurement equipment, and analysis tools. This includes bus communication logs, waveforms of measurement signals, diagnostic response messages, internal state variables of the controller, and performance metrics (e.g., CPU load, memory usage). Additionally, detailed execution logs and standard outputs generated by the target test script and framework during the test can be collected. All this structured and unstructured data will be uniformly encapsulated and bound to the target test case, forming a data package of the target test results. This provides a data foundation for subsequent result analysis, report generation, and quality assessment.

[0128] In some embodiments, after obtaining the target test result corresponding to each target test case, the method further includes: Step S50. Combine the test results of each target to generate a test report for the vehicle software under test.

[0129] In some embodiments, after generating a test report for the vehicle software under test, the method further includes: Step S60. Upload the test report to the cloud server so that the cloud server performs at least one of the following steps: Step S601. Convert the test report into a first display report, and send the first display report to the designated recipient for display; Step S602. Store the test report in the test database; Step S603. Generate a second display report based on the test report, and send the second display report to the designated recipient for display.

[0130] It should be noted that in the embodiments of this application, steps S601-S603 are parallel and have no sequential relationship.

[0131] In step S601, after receiving the test report (usually structured JSON or XML data), the cloud server invokes a report rendering service to transform it into a more human-readable and understandable first-view report, such as a visually appealing HTML webpage, a PDF document, or a rich text card integrated with internal enterprise communication tools (such as Slack or DingTalk). This transformation process includes extracting key conclusions (such as pass rates and lists of failed test cases), generating visual charts (such as test trend graphs and defect distribution pie charts), and hiding lengthy raw log data. Subsequently, the cloud server distributes the presentation report to designated recipients (such as the development team, test manager, or project leader) via email, instant messaging, or webhooks, proactively delivering test conclusions and accelerating problem discovery and communication efficiency.

[0132] In step S602, the cloud server persistently stores the test report as a data record in the test database. For example, key metadata from the test report (such as test time, software version, test case ID, pass / fail status, performance metrics, etc.) is structured, parsed, and stored in the database. This lays the data foundation for subsequent in-depth data analysis, quality trend prediction, test performance evaluation, and the construction of a quality dashboard.

[0133] In step S603, the second presentation report differs from the first presentation report in that its generation logic and target audience can differ. It is not a simple format conversion of the original report, but a higher-level report generated by aggregating, correlating, and analyzing historical and current test data stored in the database. For example, it might be a test pass rate trend report across multiple versions, a stability radar chart for a specific functional module, or a coverage analysis report related to requirements. This type of report is geared towards a more macro-level management role for strategic decision-making. The system automatically generates such reports on a schedule (e.g., daily, weekly) and distributes them to designated recipients, providing them with a comprehensive view of quality that goes beyond a single test.

[0134] Based on the above disclosure, this application embodiment obtains the test task of the vehicle software under test, acquires multiple target test cases corresponding to the test task from a test case library, wherein the test case library stores test cases corresponding to multiple vehicle software; for each target test case, a target test bench is matched for the target test case from the candidate test benches in the test bench resource library, wherein the test bench resource library stores test bench resource information of multiple test benches, and at least two target test cases are matched with different target test benches; the target test case is executed, so that during the execution of the target test case, a target interface adapted to the target test case is called from the interface database, and the target interface interacts with the corresponding target test bench, wherein the interface database encapsulates the interfaces required for multiple vehicle software test cases to interact with the test bench; and the target test result corresponding to each target test case is obtained. Therefore, this application embodiment, by interacting the test cases with the vehicle's test bench, makes the execution environment of the test cases closely related to real-vehicle testing, the test scope more in line with real-vehicle needs, and can verify the feasibility of the vehicle software in a real-vehicle environment, thereby improving the applicability of the test results. Furthermore, this application embodiment encapsulates the interfaces required for interaction between multiple automotive software test cases and test benches through an interface database. This allows for the invocation of corresponding target interfaces to interact with the test bench as needed during test case execution, improving interface reusability. Additionally, this application embodiment allocates multiple target test cases corresponding to the test tasks of the automotive software under test to different target test benches, enabling parallel execution of target test cases across different target test benches and improving testing efficiency.

[0135] Furthermore, this application's embodiments, based on deep CI / CD integration, automated resource scheduling, and multi-rack parallel testing mechanisms, achieve unattended end-to-end automotive software testing, reducing manual operations, shortening testing cycles, and significantly improving resource utilization and test throughput. By constructing a test database and a custom parsing dashboard (second display report), it enables automatic aggregation and correlation analysis of multi-source test data, effectively breaking down data silos, supporting system-level quality assessment and cross-layer root cause localization, and improving problem localization efficiency.

[0136] Figure 7 A structural diagram of an automotive software testing apparatus according to an embodiment of this application is shown.

[0137] A second aspect of this application provides an automotive software testing apparatus 200, comprising: The first acquisition unit 201 is used to acquire the test task of the car software to be tested, and to acquire multiple target test cases corresponding to the test task from the test case library, wherein the test case library stores multiple test cases corresponding to the car software. The matching unit 202 is used to match a target test bench from the candidate test benches in the test bench resource library for each target test case, wherein the test bench resource library stores test bench resource information of multiple test benches, and at least two target test cases are matched with different target test benches. The execution unit 203 is used to execute the target test case, so that during the execution of the target test case, the target test case calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface. The interface database encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench. The second acquisition unit 204 is used to acquire the target test result corresponding to each target test case.

[0138] Optionally, when retrieving multiple target test cases corresponding to the test task from the test case library, the first retrieval unit is used to: Obtain the target file directory specified by the test task; Based on the target file directory, multiple target files conforming to preset naming rules are obtained from the test case library, wherein each target file includes at least one test case; The test cases contained in the multiple target files are used as multiple target test cases corresponding to the test task.

[0139] Optionally, when retrieving multiple target files conforming to preset naming rules from the test case library based on the target file directory, the first retrieval unit is used to: Based on the target file directory, obtain multiple candidate files under the target file directory from the test case library; The filenames of each candidate file are scanned. If a candidate file's filename includes a target field, then that candidate file is selected as the target file.

[0140] Optionally, when matching a target test bench for the target test case from the candidate test benches in the test bench resource library, the matching unit is used to: If the target test case has a bench label, then the target test bench corresponding to the bench label is obtained from the candidate test benches in the bench resource library.

[0141] Optionally, the test bench resource information includes status information, which includes an idle status. When matching a target test bench for the target test case from the candidate test benches in the test bench resource library, the matching unit is used to: If the target test case does not have a bench tag, then a test bench that is idle is queried from the bench resource library as the candidate test bench, and the target test bench is randomly matched for the target test case based on the candidate test bench.

[0142] Optionally, the test bench resource information includes status information, which includes a non-idle status. After matching a target test bench for the target test case from the candidate test benches in the test bench resource library, the device is further configured to: Update the status information of the target test bench in the bench resource library to non-idle status.

[0143] Optionally, when executing the target test case, such that during execution, the target test case calls a target interface adapted to the target test case from the interface database and interacts with the corresponding target test bench through the target interface, the execution unit is used to: Obtain the target test script for the target test case; The target test script is executed so that during its execution, the target test script calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface.

[0144] Optionally, when executing the target test case, the execution unit is used to: The target test cases are executed in parallel using multiple processes.

[0145] Optionally, each target test bench is matched with multiple target test cases. When executing the target test cases, the execution unit is used to: If the plurality of target test cases include version upgrade test cases, execute the version upgrade test cases; After the version upgrade test case is executed, other test cases among the multiple target test cases are executed.

[0146] Optionally, before executing the target test case, the execution unit is further configured to: The test environment of the target test bench is initialized.

[0147] Optionally, the target interface includes at least one of the following types of interfaces: instruction execution and distribution interface, test tool interface, diagnostic interface, test environment preparation interface, test result detection interface, and test report generation interface.

[0148] Optionally, when acquiring the test task of the vehicle software under test, the first acquisition unit is used to: The test task for the automotive software under test is obtained from the continuous integration and continuous deployment pipeline. The continuous integration and continuous deployment pipeline, after detecting a code change event of automotive software in the code repository, uses the automotive software with the code change event as the automotive software under test and generates a test task for the automotive software under test.

[0149] Optionally, the continuous integration and continuous deployment pipeline and / or the code repository are deployed on a cloud server.

[0150] Optionally, after obtaining the target test result corresponding to each target test case, the device is further configured to: Based on the test results of each target, a test report for the vehicle software under test is generated.

[0151] Optionally, after generating the test report for the vehicle software under test, the device is further configured to: The test report is uploaded to a cloud server, so that the cloud server performs at least one of the following steps: The test report is converted into a first display report, and the first display report is sent to the designated recipient for display. The test report is stored in the test database; A second display report is generated based on the test report, and the second display report is sent to the designated recipient for display.

[0152] Optionally, the automotive software may be one or more of the following: Ethernet communication software, controller area network software, diagnostic software, network management software, data distribution service software, process management software, status management software, mode management software, calibration software, time synchronization software, perception software, fusion software, prediction software, and planning and control software; and / or The hardware carrier of the automotive software includes one or more of the following: in-vehicle network equipment, debugging equipment, programmable power supply, relay equipment, and intelligent driving domain controller.

[0153] Figure 8 A structural diagram of an automotive software testing system according to an embodiment of this application is shown.

[0154] A third aspect of this application provides an automotive software testing system, comprising: Interface layer 301, the interface layer includes an interface database, the interface database encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench; The test case layer 302 is communicatively connected to the interface layer. The test case layer includes a test case library, which stores multiple test cases corresponding to automotive software. An execution control layer 303, communicatively connected to the test case layer, is used to acquire test tasks for the vehicle software under test, and to acquire multiple target test cases corresponding to the test tasks from a test case library. For each target test case, a target test bench is matched from the candidate test benches in the test bench resource library, wherein the test bench resource library stores test bench resource information for multiple test benches, and at least two target test cases are matched with different target test benches. The target test cases are executed so that during execution, the target test cases call target interfaces adapted to the target test cases from the interface database, and interact with the corresponding target test benches through the target interfaces. The target test results corresponding to each target test case are then acquired.

[0155] The automotive software testing system is based on the PyTest automated testing framework. Its interface layer encapsulates interfaces such as SSH / SCP, CANoe / CANape, diagnostic Do / DoIP, serial / Android, other tools, and test function interfaces. The test case layer includes test cases for underlying software, middleware, basic services, perception / fusion / control algorithms, and other modules. The execution and control layer comprises a scheduler (Pytest-fixture), a resource manager (Benchpool), a parallel executor (pytest-xdist), and a report generator (pytest-html). The scheduler, based on the pytest-fixture mechanism, builds a scheduling decision center, dynamically allocating test tasks and bench resources according to test strategies and resource status, ensuring orderly and reliable execution of test tasks. The resource manager pools test benches, providing resource request and reclamation interfaces to the upper-layer scheduler, ensuring resources are not repeatedly allocated or conflicted, maximizing resource utilization. The parallel executor, based on the pytest-xdist plugin, implements multi-process distributed test scheduling, supporting the parallel execution of test tasks across multiple test benches, significantly improving test throughput and adapting to the high-frequency integration rhythm of CI / CD. The report generator collects and aggregates raw data returned by each test case in real time, performs unified preprocessing and formatting, and uses the pytest-html plugin to generate detailed, human-readable HTML reports, including a list of test cases, pass rate, failure logs, and output information, supporting multi-dimensional presentation and downstream parsing of test results. The data is standardized and uploaded to the test database, providing structured data input for upper-level reports and dashboards.

[0156] It is understood that the automotive software testing system in this application interacts with the underlying system under test layer (executing test cases, and the test cases interacting with the target test bench) on the one hand; on the other hand, the automotive software testing system also interacts with the top-level continuous integration and reporting layer. The above-mentioned interaction process can be referred to the preceding text, and will not be repeated here.

[0157] A fourth aspect of this application provides a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to perform the operation as described in any of the methods in the first aspect.

[0158] Computer-readable storage media may be portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the computer-readable storage medium of this application is not limited thereto. In this application, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0159] Readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, and portable compact disk read-only memory (CD). ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0160] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0161] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0162] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0163] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0164] Figure 9 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0165] According to a fifth aspect of the present application, an electronic device is provided, including one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, the at least one piece of program code being loaded and executed by the one or more processors to perform the operations performed as described in any of the methods in the first aspect.

[0166] like Figure 9As shown, the electronic device 400 is manifested in the form of a general-purpose computing device. The components of the electronic device 400 may include, but are not limited to: at least one processing unit 410, at least one storage unit 420, and a bus 430 connecting different system components (including storage unit 420 and processing unit 410).

[0167] The storage unit stores program code, which can be executed by the processing unit 410, causing the processing unit 410 to perform the steps described in the "Embodiment Method" section above according to various exemplary embodiments of this application.

[0168] Storage unit 420 may include readable media in the form of volatile storage units, such as random access memory (RAM) 421 and / or cache 422, and may further include read-only memory (ROM) 423.

[0169] Storage unit 420 may also include a program / utility 424 having a set (at least one) of program modules 425, such program modules 425 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0170] Bus 430 can represent one or more of several bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0171] Electronic device 400 can also communicate with one or more external devices 500 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 400, and / or with any device that enables electronic device 400 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed through I / O (input / output) interface 450, which can also be connected to display unit 440 to display the communication content. Furthermore, electronic device 400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public network, such as the Internet) through network adapter 460. As shown, network adapter 460 communicates with other modules of electronic device 400 via bus 430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0172] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions can be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this invention and the appended claims. For example, due to the nature of software, the functions described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

[0173] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for testing automotive software, characterized in that, include: Obtain the test task of the vehicle software to be tested, and obtain multiple target test cases corresponding to the test task from the test case library, wherein the test case library stores multiple test cases corresponding to the vehicle software. For each target test case, a target test bench is matched from the candidate test benches in the test bench resource library. The test bench resource library stores test bench resource information for multiple test benches, and at least two target test cases are matched with different target test benches. The target test case is executed so that during the execution of the target test case, the target test case calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface. The interface database encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench. Obtain the target test results corresponding to each target test case.

2. The method according to claim 1, characterized in that, The step of obtaining multiple target test cases corresponding to the test task from the test case library includes: Obtain the target file directory specified by the test task; Based on the target file directory, multiple target files conforming to preset naming rules are obtained from the test case library, wherein each target file includes at least one test case; The test cases contained in the multiple target files are used as multiple target test cases corresponding to the test task.

3. The method according to claim 2, characterized in that, The step of retrieving multiple target files conforming to preset naming rules from the test case library based on the target file directory includes: Based on the target file directory, obtain multiple candidate files under the target file directory from the test case library; The filenames of each candidate file are scanned. If a candidate file's filename includes a target field, then that candidate file is selected as the target file.

4. The method according to claim 1, characterized in that, The step of matching a target test bench for the target test case from the candidate test benches in the test bench resource library includes: If the target test case has a bench label, then the target test bench corresponding to the bench label is obtained from the candidate test benches in the bench resource library.

5. The method according to claim 1, characterized in that, The test bench resource information includes status information, including an idle status. Matching a target test bench for the target test case from the candidate test benches in the test bench resource library includes: If the target test case does not have a bench tag, then a test bench that is idle is queried from the bench resource library as the candidate test bench, and the target test bench is randomly matched for the target test case based on the candidate test bench.

6. The method according to any one of claims 1-5, characterized in that, The test bench resource information includes status information, which includes a non-idle status. After matching a target test bench for the target test case from the candidate test benches in the test bench resource library, the method further includes: Update the status information of the target test bench in the bench resource library to non-idle status.

7. The method according to claim 1, characterized in that, The execution of the target test case, during which the target test case calls a target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface, includes: Obtain the target test script for the target test case; The target test script is executed so that during its execution, the target test script calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface.

8. The method according to claim 1, characterized in that, Executing the target test case includes: The target test cases are executed in parallel using multiple processes.

9. The method according to claim 1, characterized in that, Each target test bench is matched with multiple target test cases, and executing the target test cases includes: If the plurality of target test cases include version upgrade test cases, execute the version upgrade test cases; After the version upgrade test case is executed, other test cases among the multiple target test cases are executed.

10. The method according to claim 1, characterized in that, Before executing the target test case, the method further includes: The test environment of the target test bench is initialized.

11. The method according to claim 1, characterized in that, The target interface includes at least one of the following types of interfaces: instruction execution and distribution interface, test tool interface, diagnostic interface, test environment preparation interface, test result detection interface, and test report generation interface.

12. The method according to claim 1, characterized in that, The test task for acquiring the software of the vehicle under test includes: The test task for the automotive software under test is obtained from the continuous integration and continuous deployment pipeline. The continuous integration and continuous deployment pipeline, after detecting a code change event of automotive software in the code repository, uses the automotive software with the code change event as the automotive software under test and generates a test task for the automotive software under test.

13. The method according to claim 12, characterized in that, The continuous integration and continuous deployment pipeline and / or the code repository are deployed on a cloud server.

14. The method according to claim 1, characterized in that, After obtaining the target test results corresponding to each target test case, the method further includes: Based on the test results of each target, a test report for the vehicle software under test is generated.

15. The method according to claim 14, characterized in that, After generating the test report for the vehicle software under test, the method further includes: The test report is uploaded to a cloud server, so that the cloud server performs at least one of the following steps: The test report is converted into a first display report, and the first display report is sent to the designated recipient for display. The test report is stored in the test database; A second display report is generated based on the test report, and the second display report is sent to the designated recipient for display.

16. The method according to claim 1, characterized in that, The automotive software includes one or more of the following: Ethernet communication software, controller area network software, diagnostic software, network management software, data distribution service software, process management software, status management software, mode management software, calibration software, time synchronization software, perception software, fusion software, prediction software, and planning and control software. and / or The hardware carrier of the automotive software includes one or more of the following: in-vehicle network equipment, debugging equipment, programmable power supply, relay equipment, and intelligent driving domain controller.

17. An automotive software testing device, characterized in that, include: The first acquisition unit is used to acquire the test task of the vehicle software to be tested, and to acquire multiple target test cases corresponding to the test task from the test case library, wherein the test case library stores multiple test cases corresponding to the vehicle software. A matching unit is configured to match a target test bench from the candidate test benches in the test bench resource library for each target test case, wherein the test bench resource library stores test bench resource information of multiple test benches, and at least two target test cases are matched with different target test benches. An execution unit is used to execute the target test case, so that during the execution of the target test case, the target test case calls the target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface. The interface database encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench. The second acquisition unit is used to acquire the target test result corresponding to each target test case.

18. An automotive software testing system, characterized in that, include: The interface layer includes an interface database, which encapsulates the interfaces required for multiple automotive software test cases to interact with the test bench. The test case layer communicates with the interface layer. The test case layer includes a test case library, which stores multiple test cases corresponding to automotive software. An execution control layer is communicatively connected to the test case layer. The execution control layer is used to obtain the test task of the vehicle software under test and to obtain multiple target test cases corresponding to the test task from the test case library. For each target test case, a target test bench is matched from the candidate test benches in the test bench resource library. The test bench resource library stores test bench resource information for multiple test benches, and at least two target test cases are matched with different target test benches. The target test case is then executed, so that during execution, the target test case calls a target interface adapted to the target test case from the interface database, and interacts with the corresponding target test bench through the target interface. Obtain the target test results corresponding to each target test case.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program instruction, which is loaded and executed by a processor to perform the operation as described in any one of claims 1-17.

20. An electronic device, characterized in that, It includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to perform the operation performed by the method as described in any one of claims 1-17.

Images