Automatic test system and method based on vehicle lamp self-closed loop

Abstract

The invention provides an automatic testing system and method based on a vehicle lamp self-closed loop, and relates to the technical field of vehicle lamp testing. Comprising a Web interaction layer, a business logic layer, an integrated service layer and a data storage layer. The Web interaction layer relates to interaction operations of a user and a Web interface, such as screening and execution of use cases and viewing of visual reports; the business logic layer relates to automatic control, multi-instance parallel testing, real-time state monitoring and exception handling; the integrated service layer relates to CANOE engineering storage and version management, execution of a VT HIL rack and CANOE software and hardware, control and coupling of signal collector equipment and execution commands of a flash tool; the data processing layer mainly relates to analysis and visualization of test report data. By integrating a hardware equipment cluster, automatic control and a Web platform, the system significantly improves the test efficiency, reduces manual intervention, and provides an efficient, flexible and extensible solution for the automatic test of the vehicle lamp ECU.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle lamp testing, and particularly relates to an automated test system and method based on a vehicle lamp self-closed loop. Background Art

[0002] With the development of vehicle intelligence, vehicle lamp technology has also diversified. Traditional vehicle lamp testing methods have many drawbacks in terms of efficiency, compatibility, accuracy, cost, flexibility, and engineering management, and it is difficult to meet the multi-path, high-efficiency, precise, flexible, and low-cost requirements of the modern automotive industry for vehicle lamps, especially for intelligent vehicle lamp testing. With the continuous progress of vehicle lamp technology and the increasing complexity of testing requirements, the limitations of traditional testing methods have become more and more obvious. There is an urgent need for a more efficient, intelligent, and flexible testing solution to replace traditional methods for comprehensive verification covering hardware, software, communication, and intelligent functions.

[0003] Currently, vehicle lamp projects can be divided into hard-wired functions, bus functions, and network diagnosis functions according to test function points. For hard-wired functions, a pure manual testing method is currently used. The test personnel give an instantaneous activation level signal through a high-precision power supply, and then collect corresponding test data through an oscilloscope. This method has problems such as low efficiency, poor scalability, and low resource utilization rate. For bus functions and network diagnosis functions, a semi-automated testing method is currently used. Engineers establish different automated projects according to different OEMs and different functions. This method relies on manual triggering of CAN-related tools for man-machine interactive operations, and has problems such as lack of platformization, fragmented communication protocols, poor engineering repetition rate, low environmental configuration, and lack of script management.

[0004] The existing technical solutions have the following limitations: (1) Low test efficiency and high idle rate of test resources. The degree of automation of the test process is insufficient, and the time-consuming for a single full-scale test is as high as several hours to several days, which severely restricts the test throughput in the mass production scenario. Specifically, test engineers need to execute more than a hundred test cases item by item, and complete test processes are required for different vehicle lamp models (such as LED matrix headlights and adaptive laser tail lights). There is a lack of an intelligent test case screening mechanism. And due to the lack of platformized automation capabilities, resources are idle during non-working hours.

[0005] (2) Poor compatibility and low reusability of test cases. There are serious obstacles to the reuse of the environment during multi-project parallel testing. For variables such as CAN protocol differences, vehicle configuration parameters, and vehicle lamp control logics of different OEMs, test personnel need to manually complete the repeated setting of 12 core parameters such as communication protocol configuration and light parameter calibration, and the cross-project reusability is less than 30%. The reason is that traditional testing lacks functions of intelligent parameter matching and configuration version management, resulting in nearly 40% of the test man-hours being consumed in the environment setup link.

[0006] (3) Hardware dependence and scalability limitations. The test system usually requires fixed bench equipment, and testers can only operate in the preset environment of a specific laboratory and cannot conduct remote tests, which severely limits the flexibility and application scenarios of testing. The traditional test method lacks modular design and is difficult to quickly integrate new test functions or adapt to new test standards, restricting the long-term applicability of the system.

[0007] (4) Incompatibility between hardwired and bus tests. The industry currently has to rely on the cooperation of hardware expansion modules and software to achieve hybrid testing of hardwired signals and Ethernet / CAN FD signals. There is still no test platform that can support the implementation of both hardwired functions and bus functions on the same platform.

[0008] (5) Weak automation analysis and data insight capabilities. In the test scenario based on CANOE software, although a basic test report can be generated, the original test report has the characteristics of multi-source heterogeneity and completely records process information such as system environment parameters, operation execution logs, and full-scale test steps, and cannot be directly used for automated measurement and systematic evaluation. The subsequent data processing link still highly relies on manual work to complete statistical analysis and result determination, resulting in low data processing efficiency. Testers need to spend a lot of time on data cleaning and index calculation; the presentation dimension of test results is single, mainly relying on static tables or basic report forms, lacking the support of interactive data visualization tools.

[0009] The above problems need to be solved urgently. Summary of the Invention

[0010] The purpose of the present invention is to overcome at least one technical problem existing in the prior art, and provide an automated test system and method based on the self-closed loop of vehicle lamps.

[0011] On the one hand, an embodiment of the present invention provides an automated test system based on a vehicle lamp self-closed loop. The system includes a Web interaction layer, a business logic layer, an integration service layer, and a data storage layer. The Web interaction layer is used to provide an interaction interface for users, and send a query request to the business logic layer according to the screening information submitted by the users. The business logic layer integrates a test case management module and a Python automated control module. The test case management module is used to retrieve in a built-in test case library based on the received query request, generate a test case table corresponding to the screening information, and display the test case table in the Web interaction layer. The Web interaction layer is used to generate a test case set based on the entries selected by the user in the test case table, and send an execution request to the business logic layer based on the test case set. The Python automated control module is used to parse the received execution request to obtain the screening information submitted by the user, and automatically send a start and configuration call instruction and a test case loading and execution call instruction to the integration service layer based on the screening information. The integration service layer integrates a CANOE project execution module and a vehicle lamp ECU. The CANOE project execution module is electrically connected to the vehicle lamp ECU, and is used to send a control signal to the vehicle lamp ECU and receive the message data returned by the vehicle lamp ECU. The CANOE project execution module is also used to interact with the Python automated control module through a COM interface to implement test logic and automated control, including dynamically loading a corresponding CANOE configuration file based on the received start and configuration call instruction to start a CANOE project instance; loading a test environment configuration file of a test management module and a test case set screened by the web interaction layer based on the received test case loading and execution call instruction, loading a corresponding xml file, and sequentially executing the corresponding test cases in the CAPL script pre-associated therewith. After all test cases are executed, a CANOE original test report is automatically generated. The data storage layer integrates an original report database and a report processing module. The original report database is used to store the CANOE original test report. The report processing module is used to parse the CANOE original test report to obtain the test results, and use a visualization tool to return the test results in a visualized form to the Web interaction layer for display.

[0012] Further, the screening information includes one or a combination of an original equipment manufacturer, a project, a vehicle lamp type, and a test module. The test case management module is also used to store unstructured test metadata using MongoDB, and classify and store all test case information according to the original equipment manufacturer, the project, the vehicle lamp type, and the test module. The unstructured test metadata includes one or a combination of test steps, expected results, and environmental dependencies.

[0013] Further, a signal acquisition and transmission module is integrated in the integrated service layer, which is used to control the signal acquisition and transmission of the headlight ECU under test by writing a data acquisition script in the Python script layer of the Python automation control module before the test, and interact with the signal acquisition and transmission module through the PyVISA library and the USB interface to achieve signal acquisition and transmission.

[0014] Further, a VT HIL bench cluster is integrated in the integrated service layer. The VT HIL bench cluster is composed of VTSystem and boards, combined with CANOE software and hardware, and is used to support the simultaneous startup of multiple CANOE project instances through multi-threading technology to execute different test tasks; the VT HIL bench cluster is composed of multiple HIL benches, and each HIL bench is respectively connected to the corresponding headlight ECU under test to form a one-to-one test connection relationship. The HIL bench is used to send analog signals to the headlight ECU connected to it to simulate the input signals during actual vehicle operation.

[0015] Further, the VT HIL bench cluster is electrically connected to the CANOE project execution module. The CANOE project execution module is used to realize the control of multi-threaded simultaneous execution of different test tasks through multi-threading technology based on the multi-instance parallel control call instruction sent by the Python automation control module.

[0016] Further, the CANOE project execution module is used to realize the control of multi-threaded simultaneous execution of different test tasks through multi-threading technology based on the multi-instance parallel control call instruction sent by the Python automation control module, including: querying the corresponding VT HIL bench number from the database according to the project and headlight type selected by the user in the Web interaction layer; the Python script calls the COM API of the CANOE project execution module to start the corresponding CANOE project instance according to the queried VT HIL bench number, and load the specified configuration file and test management module; load the corresponding test case according to the test module selected by the user in the Web interaction layer; read the selected test case set by the user, and execute these test cases through the COM API of the CANOE project execution module.

[0017] Further, the business logic layer is also used to, when receiving an execution case request sent by the Web interaction layer, feedback the background monitoring VT HIL bench idle state information to the Web interaction layer. If the board of the currently selected VT HIL bench number is in operation, this execution task will enter the task list for queuing and waiting. If the board of the currently selected VT HIL bench number is in an idle state, the business logic layer will allocate test nodes to directly execute the test cases.

[0018] Furthermore, a parameter configuration module and a storage module are also integrated in the integrated service layer; the parameter configuration module is used to write parameter configuration and test environment automation configuration codes using Python and CAPL scripts to achieve rapid adaptation to different vehicle manufacturers; the storage module is used to establish a database to store CANoe project instance files, test environment configuration files, and / or CAPL scripts.

[0019] Furthermore, the step of sequentially executing the corresponding test cases in the CAPL script pre-associated therewith includes: before the test, associating the test cases with the CANOE project instance and the test module by writing a CAPL automation script in the Python script layer of the python automation control module.

[0020] Second aspect, an embodiment of the present invention provides an automated test method based on a vehicle lamp self-closed loop. The method is applied to the above-mentioned automated test system based on a vehicle lamp self-closed loop, and the method includes: Step S1, a user inputs filtering information in the Web interaction layer and sends a query request to the business logic layer; Step S2, the test case management module retrieves in the built-in test case library based on the received query request, generates a test case table corresponding to the filtering information, and displays the test case table in the Web interaction layer; Step S3, the user selects entries in the test case table according to actual needs to generate a test case set, and the Web interaction layer sends an execution request to the business logic layer based on the test case set; Step S4, when the business logic layer receives the execution use case request sent by the Web interaction layer, it feeds back the idle state information of the background monitoring VT HIL bench to the Web interaction layer; Step S5, if the board of the currently selected VT HIL bench number is in operation, this execution task will enter the task list for queuing and waiting, and a queuing and waiting prompt message will be returned to the Web interaction layer for display; Step S6, if the board of the currently selected VT HIL bench number is in an idle state, the business logic layer will allocate test nodes and directly execute the test cases, including: Step S600, the python automated control module parses the filtering information submitted by the user based on the received execution request, and automatically sends a start and configuration call instruction and a test case loading and execution call instruction to the integration service layer based on the filtering information; Step S610, the CANOE project execution module interacts with the python automated control module through the COM interface to implement test logic and automated control, including dynamically loading the corresponding CANOE configuration file based on the received start and configuration call instruction to start the CANOE project instance; loading the test environment configuration file of the test management module and the test case set filtered by the web interaction layer based on the received test case loading and execution call instruction, loading the corresponding xml file, and sequentially executing the corresponding test cases in the associated CAPL script. After all test cases are executed, a CANOE original test report is automatically generated; Step S7, storing the CANOE original test report in the original report database; Step S8, the report processing module parses the CANOE original test report to obtain the test result, and uses a visualization tool to return the test result to the Web interaction layer in a visualized form for display.

[0021] In yet another aspect, the present invention further provides a computer-readable storage medium, in which one or more instructions are stored, and the computer instructions are used to cause the computer to execute the above-mentioned automated test method based on a vehicle lamp self-closed loop.

[0022] On the other hand, the present invention provides an electronic device, comprising: a memory and a processor; at least one program instruction is stored in the memory; the processor loads and executes the at least one program instruction to implement the above-mentioned automated test method based on the headlight self-closed loop.

[0023] The beneficial effects of the present invention are as follows: (1) In the embodiment of the present invention, a platform-based automated test mechanism is introduced, which compresses the originally time-consuming manual test process to the hour level. The batch execution efficiency of test cases is increased by several times, and it supports the ability to perform tests at any time of 24 hours, providing a reliable guarantee for large-scale mass production projects with agile response.

[0024] (2) In the embodiment of the present invention, through the parameter reuse mechanism and the intelligent environment configuration system, one-key migration of test parameters for cross-OEM and multi-vehicle models projects is realized, eliminating the workload of repeated configuration; using standardized interfaces and protocols to ensure that the system can quickly adapt to new test standards and technical requirements.

[0025] (3) In the embodiment of the present invention, a WEB architecture and modular design are adopted, supporting flexible expansion and rapid iteration of test functions; remote testing and data analysis are realized through the web platform, breaking through the limitations of the fixed environment and equipment in the laboratory, realizing test requirements in multiple scenarios, and being more convenient for large-scale promotion and use. Updates and maintenance are all on the server side, which is more convenient and unified.

[0026] (4) In the embodiment of the present invention, different test tools, such as CANOE, oscilloscope, programmable power supply, flashing tool, etc. can be driven by the system architecture to form an automated flow, supporting full coverage of the test link.

[0027] (5) In the embodiment of the present invention, through the multi-bench concurrent test management and execution function, the test efficiency can be greatly improved and the resource utilization can be optimized.

[0028] (6) In the embodiment of the present invention, the test report is subjected to data cleaning and index calculation through an algorithm and visually output on the web side, realizing a rich interactive interface and visualization effect. It is convenient to integrate with other Web services and systems, realizing the automation of the test process and data sharing, and providing intuitive and efficient decision-making support for testers. Description of the Drawings

[0029] The present invention will be further described below with reference to the drawings and embodiments.

[0030] Figure 1 It is a structural diagram of an automated test system based on the headlight self-closed loop provided by Embodiment 1 of the present invention.

[0031] Figure 2It is a schematic diagram of the overall process for Python to call the CANOE interface provided in Embodiment 1 of the present invention.

[0032] Figure 3 It is a schematic diagram of the structure of the VT HIL cluster distributed system provided in Embodiment 1 of the present invention.

[0033] Figure 4 It is a schematic diagram of the working process of an automated test system based on a headlight self-closed loop provided in Embodiment 1 of the present invention.

[0034] Figure 5 It is a flowchart of an automated test method based on a headlight self-closed loop provided in Embodiment 2 of the present invention.

[0035] Figure 6 It is a partial block diagram of an electronic device provided in Embodiment 4 of the present invention. Detailed implementation manners

[0036] Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations as sequential processes, many of the operations can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the operations can be rearranged. The process can be terminated when its operations are completed, but it can also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0037] It should be understood that although terms such as "first" and "second" may be used here to describe various units, these units should not be limited by these terms. These terms are only used to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, the first unit can be called the second unit, and similarly the second unit can be called the first unit. The term "and / or" used here includes any and all combinations of one or more of the listed associated items.

[0038] Now, the present invention will be described in detail with reference to the accompanying drawings. This figure is a simplified schematic diagram, which only illustrates the basic structure of the present invention in a schematic manner, so it only shows the components related to the present invention.

[0039] Embodiment 1 For ease of understanding, the working principle of this system is described as a whole before the detailed description of the embodiments of the present invention: The overall process of the automated test platform mainly includes: a Web interaction layer, a business logic layer, an integration service layer, and a data storage layer. The Web interaction layer mainly involves the interaction operations between users and the Web interface, such as the screening and execution of test cases, the viewing of visualization reports, etc.; the business logic layer mainly involves automated control, multi-instance parallel testing, real-time status monitoring, and exception handling, etc.; the integration service layer mainly involves CANOE project storage and version management, the execution of VT HIL benches and CANOE software and hardware, the control and coupling of signal collector devices, the execution commands of flashing tools, etc.; the data processing layer mainly involves the analysis and visualization of test report data. Using the low-coupling architecture of the web side, Python, and different test tools, through parameterization, modular design, and intelligent technology, it can support both hardwire and bus testing at the same time, comprehensively cover test requirements, improve the parallel testing ability, and ensure the consistency, accuracy, and stability of test results, realize the strengthening of data management and analysis, realize the integration of hardware resources and the reuse of software resources, and improve the test efficiency and greatly reduce the test cost.

[0040] The specific implementation manners are as follows: As Figures 1-4 shown, it is a structural diagram and a working process schematic diagram of an automated test system based on the self-closed loop of vehicle lamps provided by the present invention.

[0041] As an example, the system includes a Web interaction layer 1, a business logic layer 2, an integration service layer 3, and a data storage layer 4; the Web interaction layer 1 is used to provide an interaction interface for users and send a query request to the business logic layer according to the filtering information submitted by the users; the business logic layer 2 integrates a test case management module 200 and a python automation control module 210; the test case management module 200 is used to retrieve in a built-in test case library based on the received query request, generate a test case table corresponding to the filtering information, and display the test case table in the Web interaction layer; the Web interaction layer 1 is used to generate a test case set based on the entries selected by the users in the test case table and send an execution request to the business logic layer based on the test case set; the python automation control module 210 is used to parse the filtering information submitted by the users based on the received execution request and automatically send a start and configuration call instruction and a test case loading and execution call instruction to the integration service layer 3; the integration service layer 3 integrates a CANOE project execution module 300 and a headlight ECU 310, the CANOE project execution module 300 is electrically connected to the headlight ECU 310 and is used to send a control signal to the headlight ECU 310 and receive the message data returned by the headlight ECU 310; the CANOE project execution module 300 is further used to interact with the python automation control module 210 through a COM interface to implement test logic and automation control, including dynamically loading a corresponding CANOE configuration file based on the received start and configuration call instruction to start a CANOE project instance; loading a test environment configuration file of a test management module and a test case set filtered by the web interaction layer based on the received test case loading and execution call instruction, loading a corresponding xml file, and sequentially executing the corresponding test cases in the CAPL script pre-associated with it, and automatically generating a CANOE original test report after all test cases are executed; the data storage layer 4 integrates an original report database 400 and a report processing module 410; the original report database 400 is used to store the CANOE original test report; the report processing module 410 is used to parse the CANOE original test report to obtain the test results and return the test results to the Web interaction layer 1 in a visual form for display using a visualization tool. The CANOE project execution module 300 is equipped with CANOE software.

[0042] In some feasible embodiments, the workflow of the CANOE project execution module 300 includes: dynamically loading the corresponding CANOE configuration file (.cfg) according to the call instruction sent by the Python automation control module 210, starting the CANOE project; loading the test environment configuration file (.tse) of the test management module; loading the corresponding xml file according to the test case set screened on the web side, and sequentially executing the corresponding test cases in the associated CAPL script. After the execution is completed, the CANOE original test report will be automatically generated.

[0043] Specifically, the project startup and configuration loading include: dynamically loading the corresponding CANOE configuration file (.cfg) according to the call instruction sent by the Python automation control module 210, so as to start the CANOE project. This process ensures that CANOE runs with the correct configuration and prepares for subsequent tests. The test environment configuration loading includes: loading the test environment configuration file (.tse) of the test management module, which further sets the environmental parameters required for the test, such as the test scenario, device connection method, etc., so that the test can be carried out under specific environmental conditions. The test case execution and report generation include: loading the corresponding xml file according to the test case set screened by the web side user. This file contains detailed information related to the test cases. The system will sequentially execute the corresponding test cases in the associated CAPL script (the programming language script of CANoe). After all test cases are executed, CANOE will automatically generate the original test report, recording various data and results during the test process, providing a basis for subsequent analysis.

[0044] In some feasible embodiments, for the convenience of subsequent understanding of the automation control function of the python automation control module 210 on the overall system, in combination with Figure 2As shown below, this elaborates in detail how a Python script interacts with CANoe software through the COM interface to achieve the function of automated test control. Python script layer: This layer is the core of the logical control of the entire automated test. Testers define the test process and rules by writing Python scripts. For example, setting which function tests to perform first and then which performance tests, covering a series of automated control instructions from test initialization to result analysis. Python-CANoe interface layer: Start / stop CANoe instance: Similar to operating a normal application, a Python script can start or stop the running instance of CANoe software, facilitating the management of the start and end of the test. Load configuration file: CANoe software requires specific configurations to run tests. This function allows the Python script to load pre-set configuration files (.cfg), which define the working environment of CANoe, such as the type of connected bus, communication parameters, etc. Start / stop control measurement: During the test, this interface can be used to flexibly control CANoe to start data collection and analysis (measurement), or stop the measurement when the test ends or an exception occurs. Obtain test cases in the test management module: Various test cases are stored in the test management module (Test Modules) of CANoe. The Python script can obtain these test cases through this interface. Read / write signal / message data: During the test, the Python script can read the signals and message data transmitted on the bus through this interface, and can also send specific signals and messages to the bus to simulate different test scenarios. Event listening and callback handling: It is possible to listen for various events during the operation of CANoe software, such as the arrival of new data, the occurrence of errors, etc., and set corresponding callback functions for these events to make timely processing, such as recording error logs, adjusting the test process, etc. CANoe software layer: Engineering configuration (.cfg): The.cfg file is the core configuration file of the CANoe project. It contains all the setting information of the entire test project, such as the connected hardware devices, network topology, communication protocol, etc., ensuring that the CANoe software can run tests in the correct environment. Database loading (.dbc): The.dbc file is the database file of the CAN bus, storing the definitions of each signal on the CAN bus, such as signal name, data type, value range, etc. After CANoe loads this file, it can correctly parse and process the data transmitted on the bus. Test management (Test Modules): Used to organize and manage test cases. Users can create, edit, and store different test case sets here for easy invocation during testing.Bus Communication (CAN / LIN / …): The CANoe software supports multiple automotive bus communication protocols such as CAN (Controller Area Network) and LIN (Local Interconnect Network), etc., and can achieve data communication with each ECU (Electronic Control Unit) connected to the bus, simulating a real vehicle communication environment. Log Recording (.asc / .blf): During the test, CANoe records the data transmitted on the bus and the relevant information during the test, and stores them as files in.asc (ASCII format) and.blf (Binary Log File) formats respectively, facilitating subsequent analysis and traceability of the test data. Hardware Interface Layer: Physical Bus / ECU Hardware: This is the actual communication bus and the ECU hardware under test, such as the headlight ECU, and the test data is transmitted between various devices through the physical bus. CAN / LIN Transceiver: Used to implement the conversion and transmission of CAN or LIN bus signals to ensure normal communication between the ECU and other devices. VTHIL Bench Cluster: The VT (Vector Test) Hardware In the Loop (HIL) bench cluster can simulate a real vehicle environment, provide various input signals to the ECU under test, and receive its output signals, enabling the test to be carried out under conditions close to actual operation. Signal Acquisition Device: Used to acquire the signals on the bus and the output signals of the ECU for subsequent analysis and judgment to ensure that the functions and performance of the ECU meet the requirements. That is, this architecture controls the CANoe software through Python scripts, and then the CANoe software interacts with the hardware devices to achieve automated testing of hardware such as the headlight ECU. More specifically, the main functions of the Python automation control module 210 include: writing test logic and automation control code in Python, calling the COM API of CANoe through the COM interface to achieve operations such as starting, shutting down, loading configurations, and executing tests on the CANoe instance; using the PyVISA library to communicate with devices such as oscilloscopes to acquire and send signal data; adopting multi-threading technology to implement parallel testing of multiple instances, and ensuring the efficient execution of test tasks through thread scheduling and resource management.

[0045] In some feasible embodiments, the screening information includes one or a combination of the vehicle manufacturer, project, headlight type, and test module; the test case management module 200 is further configured to store unstructured test metadata using MongoDB, and store all test case information classified by vehicle manufacturer, project, headlight type, and test module. The unstructured test metadata includes one or a combination of test steps, expected results, and environmental dependencies. Preferably, the test case management module 200 also supports operations of adding, deleting, modifying, and querying test cases, and provides a version management function; and associates test cases with CANOE engineering instances and test module files by writing CAPL automation scripts to facilitate quick positioning and loading.

[0046] Specifically, storing unstructured test metadata using MongoDB includes: MongoDB is a NoSQL database, which is particularly suitable for storing unstructured or semi-structured data. In test case management, information such as test steps, expected results, and environmental dependencies may have a flexible structure, and different test cases may contain different fields or attributes. The document model (BSON format) of MongoDB can well adapt to this situation. It allows each test case to be stored as a document, and the document can contain various types of data, such as strings, arrays, objects, etc., facilitating the management of complex test metadata.

[0047] Specifically, storing all test case information classified by vehicle manufacturer, project, headlight type, and test module includes: To facilitate the management and retrieval of a large number of test cases, the system classifies test cases according to four dimensions: vehicle manufacturer (such as Chery, Geely, Seres, etc.), project (specific project names, such as Project A, Project B), headlight type (such as front headlights, taillights, turn signals, etc.), and test module (such as functional test, aging test, diagnostic test, logic switching test, etc.). When storing, each test case document will contain fields of these classification information. When querying, relevant test case sets can be quickly located according to these fields, improving the organization and retrieval efficiency of data.

[0048] Specifically, supporting operations of adding, deleting, modifying, and querying test cases and the version management function includes: CRUD (Create, Read, Update, Delete) operations are basic data management functions. Users can add new test cases and store their relevant test metadata in the database; delete test cases that are no longer needed; modify the content of existing test cases, such as updating test steps or expected results; and query test cases that meet specific conditions. The version management function is to record the historical changes of test cases. As the project progresses and testing is continuously improved, test cases may be modified multiple times. Version management can record information such as the content of each version of the test case, modification time, and modifier, facilitating the tracing and management of the evolution process of test cases.

[0049] Specifically, associating test cases with CANoe project files and test module files by writing CAPL automation scripts includes: CAPL (Communication Access Programming Language) is a programming language used for CANoe (an automotive network development and testing tool). By writing CAPL scripts, automated association between test cases, CANoe project instance files, and test module files can be achieved. For example, in a test case, a specific test scenario may be specified to run in a specific CANoe project environment and call a specific test module file. The CAPL script can automatically load the corresponding CANoe project instance file and test module file according to the relevant information in the test case, execute test operations, and realize the automated execution and management of test cases.

[0050] That is to say, this test case management module 200 realizes the efficient management and application of test cases through reasonable data storage, comprehensive function support, and automated association mechanisms, which helps improve the quality and efficiency of test work.

[0051] In some feasible implementation manners, a signal acquisition and sending module 320 is integrated in the integration service layer 3, which is used to control the signal acquisition and sending of the to-be-tested headlight ECU by writing a data acquisition script in the Python script layer of the Python automation control module 210 before the test, and interact with the signal acquisition and sending module 320 through the PyVISA library and the USB interface to realize signal acquisition and sending. Specifically, the signal acquisition and sending module 320 can select an oscilloscope. To obtain relevant data during the test, a data acquisition script needs to be written, which is written in Python. PyVISA is a Python library for communicating with various instrument devices and is used here to interact with the oscilloscope. Through the USB interface, the Python data acquisition script can establish a connection with a specific oscilloscope. After the connection is established, the script can control the oscilloscope to acquire signals (obtain electrical signals, etc. from the relevant circuits of the to-be-tested object - the headlight ECU), and send the acquired signals back to Python for subsequent analysis and processing (such as using relevant plotting libraries Matplotlib or PyQtGraph in Python or specialized data analysis software to display the processed data in visual forms such as waveform diagrams and charts), and can also send instructions to the oscilloscope to make it perform specific operations, such as adjusting acquisition parameters, etc., to meet the test requirements.

[0052] In some feasible embodiments, a VT HIL bench cluster 330 is integrated in the integrated service layer 3. The VT HIL bench cluster 330 is composed of VT System, boards, and combined CANOE software and hardware, and is used to support the simultaneous startup of multiple CANOE project instances through multi-threading technology to execute different test tasks. The VT HIL bench cluster 330 is composed of multiple HIL benches, and each HIL bench is respectively connected to the corresponding headlight ECU under test to form a one-to-one test connection relationship. The HIL bench is used to send analog signals to the headlight ECU connected thereto to simulate the input signals during actual vehicle operation. Specifically, in combination with Figure 3 As shown in the figure, the VT HIL (Hardware-in-the-Loop) cluster adopts a distributed system structure. The core lies in the collaborative work of multiple HIL benches to achieve efficient testing. The VT HIL bench cluster is collaborated by multiple benches: it is composed of multiple HIL benches, such as HIL bench 1, HIL bench 2, etc. to form a cluster. Each bench has the ability to independently simulate the real environment. In automotive electronics testing, it can simulate electrical signals, physical parameters, etc. during vehicle operation. For example, it can simulate CAN bus signals with different frequencies and amplitudes generated during engine operation, as well as environmental factors such as vibration and temperature changes during vehicle driving. Multiple benches work in parallel, greatly improving the testing efficiency, and can simultaneously test multiple objects under test or multiple test scenarios. By adopting a distributed control architecture, each bench has an independent control unit and can independently execute local test tasks. Each bench is connected to the headlight ECU under test in a one-to-one manner to form a one-to-one test connection relationship. This connection enables each headlight ECU to be tested in an independent simulated environment, avoiding interference during the testing process. For example, when HIL bench 1 conducts a functional test on the front headlight ECU, it can accurately simulate various working conditions of the front headlight, such as high and low beam switching, turn signal flashing, etc., without being affected by the testing of other headlight ECUs. Moreover, there is continuous data interaction between the HIL bench and the headlight ECU under test. The bench sends analog signals to the ECU to simulate the input signals during actual vehicle operation, such as control signals from the body controller, sensor feedback signals, etc. That is to say, by simultaneously working multiple HIL benches, multiple headlight ECUs under test can be tested in parallel, greatly shortening the testing cycle. In automotive manufacturing enterprises, different batches or different models of headlight ECUs can be tested simultaneously, improving production efficiency and accelerating the product launch speed. The cluster system is easy to expand. As the testing requirements increase, HIL benches can be added. When automotive manufacturers develop new vehicle models or new function headlights, the testing system can be easily expanded to meet new testing requirements without large-scale modification of the system architecture. The distributed architecture and redundant design enhance the system reliability. In case of a failure of an individual bench, other benches can continue to work to ensure the completion of the testing tasks.

[0053] In some feasible embodiments, the VTHIL bench cluster 330 is electrically connected to the CANOE engineering execution module 300. The CANOE engineering execution module 300 is used to implement the control of multiple threads simultaneously executing different test tasks through multi-threading technology based on the multi-instance parallel control call instructions sent by the python automation control module 210, including: querying the corresponding VTHIL bench number from the database according to the project and headlight type selected by the user in the Web interaction layer 1; the Python script calls the COM API of the CANOE engineering execution module to start the corresponding CANOE engineering instance according to the queried VTHIL bench number, and loads the specified configuration file and test management module; loading the corresponding test cases according to the test module selected by the user in the Web interaction layer; reading the selected test case set, and executing these test cases through the COM API of the CANOE engineering execution module. Specifically, identifying the VTHIL bench number is an important link in the automated test process, which ensures that the test tasks can be correctly assigned to the specified hardware-in-the-loop (HIL) test bench. The following are the detailed steps and methods to implement this function: Data preparation and storage: Establish a mapping table. Create a mapping table in the database to store the correspondence between projects, headlight types, and VTHIL bench numbers. This table can include the following fields: Project ID: Uniquely identifies a project; Headlight type ID: Uniquely identifies a type of headlight; VTHIL bench number: The HIL bench number corresponding to the project and headlight type. Data maintenance: Regularly update and maintain this mapping table through scripts to ensure the accuracy and timeliness of its data. Bench number identification logic: Use the selected project and headlight type by the user as query conditions to retrieve the corresponding VTHIL bench number from the mapping table. If the corresponding bench number cannot be queried, a default value can be set or an error message can be returned to prompt the user to check whether the selected project and headlight type are correct. System integration and automation: Write an automated script to integrate the above logic into the entire test process.

[0054] In some feasible embodiments, the business logic layer 2 is also used to, when receiving an execution case request sent by the Web interaction layer 1, feedback the background monitoring VT HIL bench idle state information to the Web interaction layer. If the board of the currently selected VTHIL bench number is in operation, this execution task will enter the task list for queuing and waiting. If the board of the currently selected VTHIL bench number is in an idle state, the business logic layer will allocate test nodes and directly execute the test cases. Moreover, the business logic layer 2 monitors the running state of the CANOE instance in real time, discovers and processes exceptions in a timely manner (such as process crashes, resource exhaustion, etc.). And it provides a logging function for easy problem troubleshooting and analysis.

[0055] In some feasible embodiments, the integrated service layer 3 is further integrated with a parameter configuration module 340 and a storage module 350; the parameter configuration module 340 is used to write parameter configuration and test environment automation configuration codes using Python and CAPL scripts to achieve rapid adaptation for different vehicle manufacturers; the storage module 350 is used to establish a database to store CANoe project instance files, test environment configuration files, and / or CAPL scripts. Specifically, the parameter configuration module 340 includes: Parameter standardization: Define a unified parameter naming rule, data type, and value range to ensure the consistency and reusability of parameters for different vehicle manufacturers; provide a parameter template function to quickly generate and reuse standard parameter sets. Environment configuration unification: Create standard environment configuration templates (CANoe project templates, ECU configuration templates) to support rapid adaptation for different vehicle manufacturers, including communication protocol configuration, signal definition, variable naming, etc.; use Python and CAPL scripts to achieve batch generation and update of configuration files. Universal signal acquisition table: Establish a unified signal acquisition table to ensure the correct acquisition and rapid response of signals of different headlight types that need to be returned. The storage module 350 includes: Establish a cross-vehicle manufacturer database, and classify and store CANoe project files (such as.cfg files), test environment configuration files (.tse files), and CAPL scripts (.can files) according to vehicle manufacturers, projects, headlight types, etc. The integrated service layer 3 also includes a version control function: Provide an engineering version management function to support historical version backtracking and comparison. Specifically, version management can be implemented through a version control system such as Git.

[0056] In some feasible embodiments, the original report database 400 includes: Store the original test reports generated by CANOE, and classify them according to dimensions such as time, vehicle manufacturer, and project. Provide a report query function to support filtering and exporting reports according to conditions. The report processing module 410 includes: Parse the original test reports (.xml format) generated by CANOE, and extract key data (such as test results, execution time, error information, etc.); perform data analysis and measurement on the test results, and calculate metrics such as pass rate, failure rate, and average execution time; classify and summarize the error information to identify common problems and potential risks; use visualization tools to generate charts, intuitively display the test results and analysis data, return a visualization report, and display it on the Web interface. Store multiple report templates to support users to customize the template content and format.

[0057] In some feasible embodiments, the system supports version software flashing operations and can quickly switch different software versions for multi-scenario testing.

[0058] In the above embodiments, through the collaborative work of the platform and the hardware device cluster, the full-process automation of headlight testing is achieved. The system is based on the VT HIL bench cluster, simulates the real vehicle environment, provides input signals for the ECU (headlight) under test, and collects output signals to ensure the accuracy and reliability of the test. The Python automation control module, as the core driver, is responsible for managing the test process, controlling hardware devices, analyzing test data, and seamlessly interacting with the Web automation testing platform. Users can set test cases, monitor the test progress, and view the results through the Web platform. All test data is stored in the database for easy traceability and analysis. In addition, the system supports the operation of flashing software versions, and can quickly switch different software versions for multi-scenario testing. By integrating the hardware device cluster, automation control, and Web platform, the system significantly improves the test efficiency, reduces manual intervention, and provides an efficient, flexible, and scalable solution for the automated testing of headlight ECUs.

[0059] It is worth mentioning that each module involved in this embodiment is a logical unit. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, to highlight the innovative part of the present invention, units that are not closely related to solving the technical problems proposed by the present invention are not introduced in this embodiment, but this does not mean that there are no other units in this embodiment.

[0060] Embodiment 2 Please refer to Figure 5 , this embodiment provides a flowchart of an automated testing method based on headlight self-closed loop.

[0061] As an example, the method is applied to the automated testing system based on headlight self-closed loop described in Embodiment 1, and the method includes: Step S1, the user inputs filtering information in the Web interaction layer and sends a query request to the business logic layer.

[0062] Step S2, the test case management module retrieves in the built-in test case library based on the received query request, generates a test case table corresponding to the filtering information, and displays the test case table in the Web interaction layer.

[0063] Step S3, the user selects entries in the test case table according to actual needs to generate a test case set, and the Web interaction layer sends an execution request to the business logic layer based on the test case set.

[0064] Step S4, when the business logic layer receives the execution case request sent by the Web interaction layer, it feeds back the idle state information of the background monitoring VT HIL bench to the Web interaction layer.

[0065] Step S5: If the board of the currently selected VTHIL bench number is in operation, the current execution task will enter the task list for queuing and waiting, and a queuing and waiting prompt message will be returned to the Web interaction layer for display.

[0066] Step S6: If the board of the currently selected VTHIL bench number is in an idle state, the business logic layer will allocate test nodes and directly execute the test cases. It includes: Step S600: The python automation control module parses the filtering information submitted by the user based on the received execution request, and automatically sends a start and configuration call instruction and a test case loading and execution call instruction to the integration service layer based on the filtering information.

[0067] Step S610: The CANOE project execution module interacts with the python automation control module through the COM interface to implement test logic and automation control, including dynamically loading the corresponding CANOE configuration file based on the received start and configuration call instruction to start the CANOE project instance; loading the test environment configuration file of the test management module and the test case set filtered by the web interaction layer based on the received test case loading and execution call instruction, loading the corresponding xml file, and sequentially executing the corresponding test cases in the associated CAPL script. After all test cases are executed, a CANOE raw test report will be automatically generated.

[0068] Step S7: Store the CANOE raw test report in the raw report database.

[0069] Step S8: The report processing module parses the CANOE raw test report to obtain the test results, and uses a visualization tool to return the test results in a visualized form to the Web interaction layer for display.

[0070] In some feasible implementation manners, in the Web interaction layer, it mainly includes the following steps: ① Vehicle manufacturer: The user filters by vehicle manufacturer (such as Chery, Geely, Seres, etc.). After selecting the vehicle manufacturer, the interface will dynamically load the corresponding project list.

[0071] ② Project: According to the selected vehicle manufacturer, the interface loads relevant projects. When the user selects a certain project, the interface dynamically updates the headlight type list.

[0072] ③ Headlight type: According to the project selection, the interface loads the headlight type (such as headlight, taillight, turn signal, etc.). When the user selects a certain headlight type, the interface dynamically updates the test module list.

[0073] ④ Test module: According to the type of vehicle lamp, the interface loads test modules (such as functional test, aging test, diagnostic test, logic switching test, etc.). The user selects a test module according to the requirements, and the interface dynamically displays the test case table.

[0074] ⑤ The user can select the entries in the test case table according to actual needs. It also supports independently importing the names of test cases in.xml format. By parsing the file content and automatically matching the test cases in the database, it can handle the situation where there are many and miscellaneous test cases and it is difficult for the user to select certain test cases one by one.

[0075] ⑥ Use case preview: When the user selects or imports test cases, a preview function is provided to display the detailed information of the test cases (such as case number, description, expected result, etc.).

[0076] ⑦ Button trigger: After clicking the "Execute Case" button, a execution request is submitted, an xml file of the selected test case set will be generated, and the selected test case information will be passed to the business logic layer.

[0077] ⑧ Status feedback: During the execution process, the execution status (such as "Executing", "Completed") is displayed in real time, and a progress bar and log information are provided.

[0078] ⑨ Exception handling: When an exception occurs during the execution process, a friendly error prompt is provided, and retry or termination operations are supported.

[0079] It is not difficult to find that this embodiment is a method embodiment corresponding to the first embodiment, and this embodiment can be implemented in cooperation with the first embodiment. The relevant technical details mentioned in the first embodiment are still valid in this embodiment. To avoid repetition, they are not elaborated here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied in the first embodiment.

[0080] Embodiment 3 The embodiment of the present invention also proposes a storage medium, on which an automated test method based on the vehicle lamp self-closed loop is stored. When the program of the automated test based on the vehicle lamp self-closed loop is executed by a processor, the steps of the automated test method based on the vehicle lamp self-closed loop as described above are implemented. Since this storage medium adopts all the technical solutions of the above-mentioned all embodiments, it has at least all the beneficial effects brought by the technical solutions of the above-mentioned embodiments, and will not be elaborated here one by one.

[0081] Embodiment 4 Please refer to Figure 6, an embodiment of the present invention further provides an electronic device, including: a memory and a processor; at least one program instruction is stored in the memory; the processor loads and executes the at least one program instruction to implement the automated test method based on the headlight self-closed loop provided in Embodiment 2.

[0082] The memory 702 and the processor 701 are connected in a bus manner. The bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors 701 and the memory 702 together. The bus may also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art, so they will not be further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver may be an element or multiple elements, such as multiple receivers and transmitters, and provides a unit for communicating with various other devices on the transmission medium. The data processed by the processor 701 is transmitted on the wireless medium through the antenna. Further, the antenna also receives data and transmits the data to the processor 701.

[0083] The processor 701 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions. The memory 702 can be used to store the data used by the processor 701 when executing operations.

[0084] The above are only embodiments of the present invention. Specific structures and common knowledge such as characteristics that are well known in the art are not described in detail herein. Those of ordinary skill in the art know all the common technical knowledge in the technical field to which the invention belongs before the application date or the priority date, can know all the prior arts in this field, and have the ability to apply the conventional experimental means before this date. Those of ordinary skill in the art can, under the inspiration given in this application, combine their own abilities to complete and implement this solution. Some typical well-known structures or well-known methods should not become obstacles for those of ordinary skill in the art to implement this application. It should be noted that for those skilled in the art, without departing from the structure of the present invention, several deformations and improvements can be made, which should also be regarded as the protection scope of the present invention, and these will not affect the implementation effect of the present invention and the practicability of the patent. The protection scope required by this application should be subject to the content of its claims, and the specific implementation manners and the like recorded in the specification can be used to interpret the content of the claims.

Claims

1. An automated test system based on a self-closed loop of vehicle lights, characterized in that The system includes a Web interaction layer, a business logic layer, an integration service layer, and a data storage layer; The Web interaction layer is used to provide an interaction interface for users and send a query request to the business logic layer according to the filtering information submitted by the users; The test case management module and the Python automation control module are integrated in the business logic layer; The test case management module is used to retrieve in the built-in test case library based on the received query request, generate a test case table corresponding to the filtering information, and display the test case table in the Web interaction layer; The Web interaction layer is used to generate a test case set based on the entries selected by the user in the test case table, and send an execution request to the business logic layer based on the test case set; The Python automation control module is used to parse the filtering information submitted by the user based on the received execution request, and automatically send a start and configuration call instruction and a test case loading and execution call instruction to the integration service layer based on the filtering information; The CANOE project execution module and the headlight ECU are integrated in the integration service layer. The CANOE project execution module is electrically connected to the headlight ECU and is used to send a control signal to the headlight ECU and receive the message data returned by the headlight ECU; The CANOE project execution module is also used to interact with the Python automation control module through the COM interface to implement test logic and automation control, including dynamically loading the corresponding CANOE configuration file based on the received start and configuration call instruction to start the CANOE project instance; loading the test environment configuration file of the test management module and the test case set filtered by the web interaction layer based on the received test case loading and execution call instruction, loading the corresponding xml file, and sequentially executing the corresponding test cases in the CAPL script pre-associated with it. After all test cases are executed, a CANOE raw test report is automatically generated; The raw report database and the report processing module are integrated in the data storage layer; The raw report database is used to store the CANOE raw test report; The report processing module is used to parse the CANOE raw test report to obtain the test results, and use a visualization tool to return the test results in a visualized form to the Web interaction layer for display.

2. The automated test system based on the headlight self-closed loop according to claim 1, wherein The filtering information includes one or a combination of the vehicle manufacturer, project, headlight type, and test module; The test case management module is also used to store unstructured test metadata using MongoDB, and classify and store all test case information according to the vehicle manufacturer, project, headlight type, and test module. The unstructured test metadata includes one or a combination of test steps, expected results, and environmental dependencies.

3. The automated test system based on the headlight self-closed loop according to claim 1, wherein, The integrated service layer integrates a signal acquisition and transmission module, which is used to control the signal acquisition and transmission of the headlight ECU under test by writing data acquisition scripts in the Python script layer of the Python automation control module before testing, and interacts with the signal acquisition and transmission module through the PyVISA library and the USB interface to achieve signal acquisition and transmission.

4. The automated test system based on the headlight self-closed loop according to claim 1, wherein The integrated service layer integrates a VT HIL bench cluster, which is composed of VT System and boards, and CANOE software and hardware, and is used to support the simultaneous startup of multiple CANOE project instances and execute different test tasks through multi-threading technology; The VT HIL bench cluster is composed of multiple HIL benches, and each HIL bench is respectively connected to the corresponding headlight ECU under test to form a one-to-one test connection relationship. The HIL bench is used to send analog signals to the connected headlight ECU to simulate the input signals during actual vehicle operation.

5. The automated test system based on the headlight self-closed loop according to claim 4, characterized in that The VT HIL bench cluster is electrically connected to the CANOE project execution module, and the CANOE project execution module is used to realize the control of multi-threaded simultaneous execution of different test tasks through multi-threading technology based on the multi-instance parallel control call instruction sent by the Python automation control module.

6. The automated test system based on the headlight self-closed loop according to claim 5, wherein, The CANOE project execution module is used to realize the control of multi-threaded simultaneous execution of different test tasks through multi-threading technology based on the multi-instance parallel control call instruction sent by the Python automation control module, including: Query the corresponding VT HIL bench number from the database according to the project and headlight type selected by the user in the Web interaction layer; The Python script calls the COM API of the CANOE project execution module to start the corresponding CANOE project instance, load the specified configuration file and test management module according to the queried VT HIL bench number; load the corresponding test case according to the test module selected by the user in the Web interaction layer; read the selected test case set and execute these test cases through the COM API of the CANOE project execution module.

7. The automated test system based on the headlight self-closed loop according to claim 6, wherein, The business logic layer is also used to, when receiving the execution case request sent by the Web interaction layer, feedback the background monitoring VT HIL bench idle state information to the Web interaction layer. If the board of the currently selected VT HIL bench number is in operation, this execution task will enter the task list for queuing and waiting. If the board of the currently selected VT HIL bench number is in an idle state, the business logic layer will allocate test nodes to directly execute the test cases.

8. The automated test system based on the headlight self-closed loop according to claim 1, wherein, The integrated service layer also integrates a parameter configuration module and a storage module; The parameter configuration module is used to write parameter configuration and test environment automation configuration codes using Python and CAPL scripts to achieve rapid adaptation for different OEMs; The storage module is used to establish a database to store CANoe project instance files, test environment configuration files, and / or CAPL scripts.

9. The automated test system based on the headlight self-closed loop according to claim 1, characterized in that The sequential execution of the corresponding test cases in the pre-associated CAPL script includes: Before testing, the test cases are associated with the CANOE project instance and the test module by writing a CAPL automation script in the python script layer of the python automation control module.

10. An automated test method based on a vehicle headlight self-closed loop, the method being applied to the automated test system based on a vehicle headlight self-closed loop according to any one of claims 1-9, characterized in that, The method includes: Step S1, the user inputs filtering information in the Web interaction layer and sends a query request to the business logic layer; Step S2, the test case management module retrieves in the built-in test case library based on the received query request, generates a test case table corresponding to the filtering information, and displays the test case table in the Web interaction layer; Step S3, the user selects entries in the test case table according to actual needs to generate a test case set, and the Web interaction layer sends an execution request to the business logic layer based on the test case set; Step S4, when the business logic layer receives the execution case request sent by the Web interaction layer, it feeds back the idle state information of the background monitoring VT HIL bench to the Web interaction layer; Step S5, if the board of the currently selected VT HIL bench number is in operation, this execution task will enter the task list for queuing and waiting, and return a queuing and waiting prompt message to the Web interaction layer for display; Step S6, if the board of the currently selected VT HIL bench number is in an idle state, the business logic layer will allocate test nodes and directly execute the test cases, including: Step S600, the python automation control module parses the filtering information submitted by the user based on the received execution request, and automatically sends a start and configuration call instruction and a test case loading and execution call instruction to the integration service layer; Step S610, the CANOE project execution module interacts with the python automation control module through the COM interface to implement test logic and automation control, including dynamically loading the corresponding CANOE configuration file based on the received start and configuration call instruction to start the CANOE project instance; loading the test environment configuration file of the test management module and the test case set filtered by the web interaction layer based on the received test case loading and execution call instruction, loading the corresponding xml file, sequentially executing the corresponding test cases in the associated CAPL script, and automatically generating a CANOE original test report after all test cases are executed; Step S7, storing the CANOE original test report in the original report database; Step S8, the report processing module parses the CANOE original test report to obtain the test results, and uses a visualization tool to return the test results in a visual form to the Web interaction layer for display.

Images