Automotive instrument software testing methods, devices, equipment and storage media

Abstract

This invention belongs to the field of automotive control system testing technology, and discloses a method, apparatus, equipment, and storage medium for testing automotive instrument software. The invention acquires a test task and determines the test parameter type based on the test task; according to the test parameter type, it generates a corresponding type of simulated MCU test signal using a QT simulation signal library; it transmits the simulated MCU test signal to the instrument panel under test, monitors the MCU of the instrument panel under test, and obtains the actual intermediate result data of the simulated MCU test signal; it acquires the real-time display result of the instrument panel under test, and based on the simulated MCU test signal, the actual intermediate result data, and the real-time display result, it determines the faulty section of the instrument main program. By generating simulated MCU test signals and monitoring the actual intermediate result data, this invention can quickly determine the fault location, allowing the corresponding test personnel to repair it, thus improving testing efficiency and accuracy.

Description

Technical Field

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

[0002] With the continuous development of modern automotive technology, the car dashboard plays a crucial role in vehicle information display and driver assistance. The reliability and safety of the dashboard software are paramount for automakers and development teams. Therefore, comprehensive testing and validation of the dashboard software is essential.

[0003] Currently, automotive instrument cluster software testing primarily relies on manual operation and simulator-based testing platforms. Instrument cluster debugging is commonly divided into two types: front-end debugging and back-end debugging. Front-end debugging focuses on the visual display, while back-end debugging works at the software's code logic level, with results limited to specific code sections. However, these methods suffer from low efficiency, insufficient accuracy, and high demands on human resources and time. Especially in front-end and back-end debugging of instrument clusters, the asynchronous operation and potential conflicts between the two methods lead to low debugging efficiency.

[0004] A vehicle instrument panel testing method is proposed in patent application publication number CN114964809B. First, a successfully programmed instrument panel is identified via serial port. Then, multiple modules of the instrument panel are tested, and the results are recorded. When all module test results are normal, the entire instrument panel system is considered to be in normal condition. This method effectively improves testing efficiency, but when a certain function test result is abnormal, it cannot determine whether the faulty module is in the front-end or back-end code. This limitation can be further improved to enhance the accurate location and diagnosis of anomalies.

[0005] To address the conflict between the front-end and back-end debugging of the dashboard, a new testing method for automotive dashboard software is needed. Summary of the Invention

[0006] The main objective of this invention is to provide a method for testing automotive instrument panel software, which aims to solve a series of problems such as low debugging efficiency caused by asynchronous operation and potential conflicts between the front and back ends of the instrument panel during debugging.

[0007] To achieve the above objectives, the present invention provides a method for testing automotive instrument cluster software, the method comprising:

[0008] Obtain the test task and determine the test parameter type based on the test task;

[0009] Based on the test parameter type, generate the corresponding type of simulated MCU test signal using the QT simulation signal library;

[0010] The simulated MCU test signal is transmitted to the instrument panel under test, and the MCU of the instrument panel under test is monitored to obtain the actual intermediate result data of the simulated MCU test signal.

[0011] The real-time display results of the instrument panel under test are obtained. Based on the simulated MCU test signal, actual intermediate result data and real-time display results, the faulty section of the instrument's main program is determined.

[0012] Optionally, before obtaining the test task and determining the test parameter type based on the test task, the method further includes:

[0013] The serial communication parameters and serial communication protocol of the instrument under test are obtained. The serial communication parameters include serial port number, baud rate, data bits, parity bits and stop bits.

[0014] Based on the serial communication protocol and serial communication parameters, the main program of the instrument under test is initialized with communication configuration to establish serial communication.

[0015] Optionally, obtaining the test task and determining the test parameter type based on the test task includes:

[0016] Obtain the test task, parse the test task, and obtain the raw vehicle signal data required in the test task;

[0017] Based on the original vehicle signal data, reverse data is used to determine the intermediate result data that leads to the test result.

[0018] The original vehicle signal data and the intermediate result data are summarized to determine all test parameter types in the test task.

[0019] Optionally, generating a corresponding type of simulated MCU test signal using the QT simulation signal library based on the test parameter type includes:

[0020] Based on the QT simulation signal library, the simulation signal generation function is determined according to the test parameter type;

[0021] Retrieve the content of the text box corresponding to the test parameter type in the test program interface;

[0022] When the text box content is not empty, the simulation MCU test signal corresponding to the text box content is generated according to the simulation signal generation function.

[0023] Optionally, after obtaining the text box content corresponding to the test parameter type within the test program interface, the method further includes:

[0024] When the text box is empty, obtain the parameter range of the test parameter type;

[0025] Based on the parameter range, a random value for the test parameter type is generated using a random generation function;

[0026] The simulated MCU test signal corresponding to the random value is generated using a simulated signal generation function.

[0027] Optionally, the step of obtaining the real-time display results of the instrument panel under test, and determining the faulty section of the instrument's main program based on the simulated MCU test signal, intermediate result data, and real-time display results, includes:

[0028] Obtain the real-time display results of the instrument panel under test;

[0029] Based on the simulated MCU test signal, the predicted intermediate result data is obtained;

[0030] When the real-time display result differs from the simulated MCU test signal, and the predicted intermediate result data corresponds correctly with the actual intermediate result data, it is determined that the faulty section of the instrument's main program is located in the front-end code section.

[0031] When there is a difference between the predicted intermediate result data and the actual intermediate result data, it is determined that the faulty section of the instrument's main program is located in the backend code section.

[0032] Optionally, the step of obtaining the real-time display results of the instrument panel under test, and determining the faulty section of the instrument's main program based on the simulated MCU test signal, intermediate result data, and real-time display results, further includes:

[0033] Obtain the real-time display results of the instrument panel under test;

[0034] Based on the simulated MCU test signal, the predicted intermediate result data is obtained;

[0035] When the real-time display result corresponds correctly with the simulated MCU test signal, and the predicted intermediate result data corresponds correctly with the actual intermediate result data, it is determined that the instrument main program is fault-free.

[0036] Furthermore, to achieve the above objectives, the present invention also proposes an automotive instrument software testing device, the automotive instrument software testing device comprising:

[0037] The parameter type acquisition module is used to acquire the test task and determine the test parameter type based on the test task.

[0038] The simulation signal generation module is used to generate corresponding type of simulated MCU test signals according to the test parameter type through the QT simulation signal library;

[0039] The signal monitoring module is used to transmit the simulated MCU test signal to the instrument panel under test, monitor the MCU of the instrument panel under test, and obtain the actual intermediate result data of the simulated MCU test signal.

[0040] The fault confirmation module is used to obtain the real-time display results of the instrument panel under test, and determine the fault section of the instrument's main program based on the simulated MCU test signal, actual intermediate result data and real-time display results.

[0041] Furthermore, to achieve the above objectives, the present invention also proposes an automotive instrument software testing device, which includes: a memory, a processor, and an automotive instrument software testing program stored in the memory and executable on the processor. The automotive instrument software testing program is configured to implement the steps of the automotive instrument software testing method described above.

[0042] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing an automotive instrument software test program, wherein the automotive instrument software test program, when executed by a processor, implements the steps of the automotive instrument software test method.

[0043] This invention acquires a test task and determines the test parameter type based on the test task. According to the test parameter type, it generates a corresponding simulated MCU test signal using a QT simulation signal library. The simulated MCU test signal is transmitted to the instrument panel under test (DUT), and the MCU of the DUT is monitored to obtain the actual intermediate result data of the simulated MCU test signal. The real-time display result of the DUT is obtained, and based on the simulated MCU test signal, the actual intermediate result data, and the real-time display result, the faulty section of the instrument's main program is determined. This invention, by generating simulated MCU test signals and transmitting them to the main program of the DUT, and monitoring the generated intermediate result data, can quickly determine the fault location, allowing the corresponding test personnel to repair it, thus improving testing efficiency and accuracy. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of the structure of an automotive instrument software testing device for the hardware operating environment involved in the embodiments of the present invention;

[0045] Figure 2 This is a flowchart illustrating the first embodiment of the automotive instrument software testing method of the present invention;

[0046] Figure 3This is a flowchart illustrating the second embodiment of the automotive instrument software testing method of the present invention;

[0047] Figure 4 This is a flowchart illustrating the third embodiment of the automotive instrument software testing method of the present invention;

[0048] Figure 5 This is a flowchart illustrating the fourth embodiment of the automotive instrument software testing method of the present invention;

[0049] Figure 6 This is a structural block diagram of the first embodiment of the automotive instrument software testing device of the present invention.

[0050] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0051] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0052] Reference Figure 1 , Figure 1 This is a schematic diagram of the structure of an automotive instrument software testing device for the hardware operating environment involved in an embodiment of the present invention.

[0053] like Figure 1 As shown, the automotive instrument software testing equipment may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk storage device. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0054] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on automotive instrument software testing equipment and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0055] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and an automotive instrument software test program.

[0056] exist Figure 1 In the automotive instrument software testing device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the automotive instrument software testing device of the present invention can be set in the automotive instrument software testing device, and the automotive instrument software testing device calls the automotive instrument software testing program stored in the memory 1005 through the processor 1001 and executes the automotive instrument software testing method provided in the embodiment of the present invention.

[0057] This invention provides a method for testing automotive instrument cluster software, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the automotive instrument software testing method of the present invention.

[0058] Step S10: Obtain the test task and determine the test parameter type based on the test task.

[0059] It should be noted that test tasks generally include specifying the content to be tested. For example, for dashboard programs, test tasks may specifically refer to debugging related to speed display, fuel consumption display, or other types of display content. For instance, when the test task is related to speed display, the test parameter type that needs to be determined is the test parameter related to vehicle speed. These parameters, after being subdivided, may include a series of content related to the vehicle speed section, such as speed values, speed units, speed change response, and warning functions, each of which corresponds to a test parameter type.

[0060] Understandably, the test task only determines the general test direction. Based on this direction, the test program determines the test parameters that may be used or detected when performing this test. Generally, in addition to the content directly displayed on the dashboard, the test parameters also include some intermediate result data. For example, the conventional speed display is usually based on the real-time result obtained from the speed sensor as the reference value for the speed display. However, on the other hand, there is a certain correspondence between real-time vehicle speed and wheel rotation speed. Through a simple calculation, the real-time vehicle speed can be obtained from the real-time wheel rotation speed. In this process of obtaining the vehicle speed from the wheel rotation speed, the calculated vehicle speed value is the intermediate result data. The data type of this intermediate result data should be classified as a type of test parameter. Therefore, in actual practice, the test results include not only the types of results that can be directly obtained and displayed by some sensors, but also the types represented by the intermediate result data. These two parts together constitute the test parameter type.

[0061] It should be understood that, compared with the data results obtained directly from the sensor, the data results obtained through intermediate parameters can serve as an auxiliary verification of the real-time display results. Since the data obtained from the sensor is directly displayed on the display interface without processing, it lacks the verification of logical code and is easily inconsistent with the actual situation, leading to user misunderstanding or incorrect judgment. Therefore, a verification program is usually set up for the same display content, and new intermediate result data will be introduced into the verification program as an additional test parameter type.

[0062] Step S20: Based on the test parameter type, generate the corresponding type of simulated MCU test signal using the QT simulation signal library.

[0063] It's important to note that Qt is a cross-platform C++ application development framework. Qt provides a set of tools and libraries for building graphical user interface (GUI) and non-GUI applications. Qt's signals and slots are a mechanism for handling inter-object communication; they connect specific events (signals) to corresponding operations (slots) to enable interaction between objects. In the process of generating test signals for simulating MCUs, the signals and slots mechanism can be used to simulate signal transmission within the MCU, enabling the creation of custom simulation signal libraries. These libraries can be tailored to specific needs.

[0064] Understandably, the QT simulation signal library can simulate and generate real original vehicle signals and transmit them to the instrument panel program under test. The instrument panel program then processes the received signals and displays the results. On the other hand, the QT simulation signal library can also simulate and generate real intermediate data signals. As long as these signals are transmitted to the nodes in the main instrument panel program using a specific communication method, the main program can process the received intermediate data signals according to the current situation and display the processing results on the display interface.

[0065] Understandably, simulated MCU test signals are categorized into three types: data signals, fault code signals, and control signals. Data signals reflect vehicle status and performance, such as vehicle speed and engine speed; fault code signals indicate whether the vehicle has experienced a malfunction or abnormality, such as engine fault codes; control signals are instructions sent by the MCU to the vehicle system and controller, such as switching driving modes and activating safety functions. Simulating these signals can be used to test the normality and accuracy of communication between the dashboard and the MCU, as well as to verify the functionality and stability of the dashboard.

[0066] It should be understood that the QT simulation signal library is designed with a complete set of simulation signal algorithms. It can calculate the original vehicle signal corresponding to a specified physical quantity as needed, and can also calculate the corresponding intermediate data based on the original vehicle signal. In other words, as long as the type of a test parameter is determined, other test parameters associated with that test parameter can be generated.

[0067] Step S30: Transmit the simulated MCU test signal to the instrument panel under test, monitor the MCU of the instrument panel under test, and obtain the actual intermediate result data of the simulated MCU test signal.

[0068] It should be noted that dashboard debugging is generally divided into front-end debugging, which is done on the instrument interface, icon positions, or other types of data, and back-end debugging, which is done at the data logic level based on received sensor signals. Unlike front-end debugging, which is based on visual display content, back-end debugging is done by back-end test engineers at the software code logic level in an editor. The debugging results are limited to a specific code section and are not synchronized with front-end debugging. Conflicts can easily occur between the two debugging operations. Both parties need to work together to debug the software logic and display logic to ensure the correct results.

[0069] Understandably, the key to distinguishing between front-end and back-end code faults lies in determining whether there are errors in the intermediate signals obtained after processing by the instrument panel under test. Since signal processing and flow are based on the process from the original signal to the intermediate signal and then to the display result, the process from the original vehicle signal to the intermediate data is handled by the back-end code according to its code logic, while the process from the intermediate signal to the display result is generally handled by the front-end code according to its display logic. By separately verifying the intermediate data, this can be used as a watershed to determine the location of the fault.

[0070] It should be understood that there can be more than one intermediate data point in practice. This is because there may be multiple processing stages, data flows, and verification processes before display. This creates multiple intermediate data points, like a data chain. Only when all the intermediate data is correct can we ensure that the final backend program is error-free. On the other hand, if the intermediate data is correct but the final display result has problems, then it can be determined that there is a problem with the frontend code.

[0071] Step S40: Obtain the real-time display results of the instrument panel under test, and determine the faulty section of the instrument main program based on the simulated MCU test signal, actual intermediate result data and real-time display results.

[0072] It should be noted that during the execution process, the simulated MCU test signal is generated by the simulated signal library. The simulated signal library can further obtain the intermediate data corresponding to the generated simulated MCU test signal and use the intermediate data calculated here as the reference value of the actual intermediate data. By comparing the two, it can be determined whether there is an error in the intermediate data obtained by the MCU during processing.

[0073] Understandably, if all intermediate data is correct after comparison, it can be assumed that there is no fault in the backend code and all data has been correctly processed in the backend. On this basis, if the display result can also correctly display the display result corresponding to the simulated MCU test signal, it proves that there is no problem in the frontend code. Otherwise, the fault lies in the frontend code.

[0074] In this embodiment, a test task is acquired, and the test parameter type is determined based on the test task. According to the test parameter type, a corresponding simulated MCU test signal is generated using a QT simulation signal library. This simulated MCU test signal is transmitted to the instrument panel under test (DUT), and the MCU of the DUT is monitored to obtain the actual intermediate result data of the simulated MCU test signal. The real-time display result of the DUT is then obtained. Based on the simulated MCU test signal, the actual intermediate result data, and the real-time display result, the faulty section of the instrument's main program is determined. These steps achieve the subdivision of test parameter types, utilize the QT simulation signal library to generate simulated signals, and simulate real-world scenarios. By comparing the results, faulty sections are identified and targeted repairs are performed, improving testing efficiency and accuracy, and ultimately enhancing product quality and user experience.

[0075] Reference Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the automotive instrument software testing method of the present invention.

[0076] Based on the first embodiment described above, step S10 in the automotive instrument software testing method of this embodiment includes:

[0077] Step S101: Obtain the test task, parse the test task, and obtain the original vehicle signal data required in the test task.

[0078] It should be noted that the test task generally only determines the display items that need to be tested on the instrument panel under test. However, to get from the original vehicle signal data to the actual display items, it is necessary to confirm the vehicle's electronic system manual or instrument panel model in advance. Then, based on the instrument panel model, technical specifications, or relevant documents, understand the logic and calculation method of each display item on the instrument panel in order to determine the original vehicle signals required by this type of instrument panel in actual process.

[0079] Furthermore, before step S101, the method further includes: acquiring the serial communication parameters and serial communication protocol of the instrument under test, wherein the serial communication parameters include serial port number, baud rate, data bits, parity bits, and stop bits; and initializing the communication configuration of the main program of the instrument under test according to the serial communication protocol and serial communication parameters to establish serial communication.

[0080] Understandably, the serial communication parameters, including the port number, baud rate, data bits, parity bits, and stop bits, are obtained from the instrument panel's technical specifications or documentation provided by the manufacturer. It's also necessary to understand the serial communication protocol specifications, such as the communication command format and data interaction flow. Then, in the software development environment, using the appropriate serial communication library or API, the parameters such as the port number, baud rate, data bits, parity bits, and stop bits are set according to the obtained serial communication parameters. Following the communication protocol specifications, program code is written, including the communication command format, data interaction flow, and communication mode settings with the instrument under test (DUT). This may involve specific communication protocol parsing and encapsulation to ensure the program can accurately send and receive data. Finally, the initialized communication configuration is loaded into the main program of the DUT, thus completing the communication connection between the two.

[0081] Step S102: Perform data reverse engineering based on the original vehicle signal data to determine the intermediate result data generated to achieve the display result.

[0082] It should be noted that intermediate result data is data obtained by processing and calculating the original vehicle signal data. This data is used for the final display items on the dashboard. The acquired original vehicle signal data is parsed and converted into a readable and usable format, such as numerical values, status, and text. Then, based on the actual information obtained, the intermediate signals that may be needed can be further deduced. For example, when the test task includes vehicle speed, the type of intermediate signal may be wheel speed or fuel consumption. Then, based on the wheel speed, intermediate data such as engine speed can be deduced. This example shows that, under certain conditions, the final vehicle speed information can be determined based on engine speed, wheel speed, and fuel consumption. Once the intermediate information corresponding to the display item is confirmed, all the data types that need to be generated or compared can be determined. Then, the simulation signal generation library can indirectly calculate the specific values ​​of other signal types based on the specific value of one signal type.

[0083] Step S103: Summarize the original vehicle signal data and the intermediate result data to determine all test parameter types in the test task.

[0084] Understandably, once the type of the original vehicle signal data is confirmed, the intermediate data types related to the original vehicle signal can be deduced using the above method. By summarizing these data types, the overall test parameter types required for this test task can be determined.

[0085] In this embodiment, a test task is acquired and parsed to obtain the original vehicle signal data required for the test task. Based on the original vehicle signal data, data deduction is performed to determine the intermediate result data needed to achieve the display result. The original vehicle signal data and the intermediate result data are then summarized to determine all test parameter types in the test task. Through these steps, all required test parameter types for this test task can be determined. Once this data is confirmed, it can be supplied to the simulation signal generation library to generate all simulation signals globally at once, which helps reduce debugging conflicts caused by multiple signal generation.

[0086] Reference Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the automotive instrument software testing method of the present invention.

[0087] Based on the first embodiment described above, step S20 in the automotive instrument software testing method of this embodiment includes:

[0088] Step S201: Based on the QT simulation signal library, determine the simulation signal generation function according to the test parameter type.

[0089] It should be noted that, based on the test parameter types determined in the previous step, including all data types that need to be generated or compared, a summary of the data types for which simulation signals need to be generated is required. Then, according to the QT simulation signal library documentation and API, the corresponding interface functions are located to generate the simulation signals required for each type of test parameter. Internally, the signal generation interface provided by QT is called to generate standard-compliant simulation signal data based on the characteristics and requirements of each parameter type.

[0090] Understandably, by calling the simulation signal generation function and generating corresponding simulation signal data based on the specific values ​​provided by the parameter type, the generated signal can accurately simulate the signal data characteristics of actual vehicles. Then, the written simulation signal generation function is integrated into the test environment to ensure that it can be automatically called and generated as needed during testing to meet test requirements.

[0091] Step S202: Obtain the content of the text box corresponding to the test parameter type in the test program interface.

[0092] It should be noted that the type of test parameters is derived by the test program based on the test task, while the specific test parameter values ​​are set directly in the test program interface. For example, if the input test content is vehicle speed, the corresponding vehicle speed value can be set. Based on the specific vehicle speed value, the specific value of the intermediate data corresponding to that vehicle speed value can be obtained according to a certain calculation method. This value is then used as a comparison value of the intermediate data generated by the main program of the instrument panel under test in subsequent tests.

[0093] Understandably, the test program interface contains multiple raw vehicle signal types and their corresponding text boxes. By entering specific values ​​or text in these text boxes, the generated test signals can be manually adjusted.

[0094] Step S203: When the text box content is not empty, generate the simulated MCU test signal corresponding to the text box content through the simulated signal generation function based on the text box content.

[0095] It should be noted that since the test parameter types in the interface are generally not just one, but include multiple items, and some test parameters are related to each other, once one is determined, another test parameter is also determined accordingly. For example, when the wheel speed or engine speed is determined, the vehicle speed will be limited to a certain range. In this case, the vehicle speed value cannot be set arbitrarily. Instead, the corresponding test signal can be generated based on the parameter value that has already been set.

[0096] Furthermore, when the text box content is empty, the parameter range of the test parameter type is obtained; based on the parameter range, a random value of the test parameter type is generated through a random generation function; and a simulated MCU test signal corresponding to the random value is generated through a simulation signal generation function.

[0097] It should be noted that when the text box is empty, if the parameter type is not set due to the limitations of other related parameters, it will be randomly generated within the appropriate range of the parameter, and the randomly generated value will be filled into the text box for display. Similarly, test parameters that are not specifically set will also generate random values ​​for the parameter within the normal test range, and the corresponding test signal will be generated accordingly.

[0098] In this embodiment, based on the QT simulation signal library, a simulation signal generation function is determined according to the test parameter type; the content of the text box corresponding to the test parameter type in the test program interface is obtained; when the text box content is not empty, a simulation MCU test signal corresponding to the text box content is generated according to the simulation signal generation function; when the text box content is empty, the parameter range of the test parameter type is obtained; based on the parameter range, a random value of the test parameter type is generated according to the random generation function; and a simulation MCU test signal corresponding to the random value is generated according to the simulation signal generation function. This solves the conflict problem between test signals and facilitates the rapid deployment of testing work.

[0099] Reference Figure 5 , Figure 5 This is a flowchart illustrating the third embodiment of the automotive instrument software testing method of the present invention.

[0100] Based on the first embodiment described above, step S40 in the automotive instrument software testing method of this embodiment includes:

[0101] Step S401: Obtain the real-time display results of the instrument panel under test.

[0102] It should be noted that after the test signal is transmitted to the MCU via the predetermined serial communication, after a short period of processing, the instrument panel under test will generate a corresponding display screen based on the test signal, and the display result corresponding to the test signal in the display screen can be determined according to the test task.

[0103] Step S402: Obtain the predicted intermediate result data based on the simulated MCU test signal.

[0104] Understandably, once the simulated MCU test signal is determined, the associated intermediate result data can also be further determined. The intermediate result data here is derived from the data deduction based on the simulated signal generation function, which means that the predicted value of this type of intermediate result data is obtained. In the subsequent process, the actual intermediate result data can be obtained by monitoring the MCU through serial communication. By comparing the two, it can be determined whether there is a fault in the main program of the instrument panel and the location of the fault.

[0105] Step S403: When the real-time display result differs from the simulated MCU test signal, and the predicted intermediate result data corresponds correctly with the actual intermediate result data, it is determined that the fault section of the instrument main program is located in the front-end code section.

[0106] Furthermore, when there is a difference between the predicted intermediate result data and the actual intermediate result data, it is determined that the faulty section of the instrument's main program is located in the back-end code section.

[0107] Furthermore, when the real-time display result corresponds correctly with the simulated MCU test signal, and the predicted intermediate result data corresponds correctly with the actual intermediate result data, it is determined that the instrument main program is fault-free.

[0108] In this embodiment, by acquiring the real-time display results of the instrument panel under test, and obtaining predicted intermediate result data based on the simulated MCU test signal, the real-time display results are compared with the simulated MCU test signal to determine whether there is a fault in the instrument panel's main program. Then, by comparing the theoretically predicted intermediate result data with the actual intermediate result data monitored at the serial communication port, the final fault location is determined. This helps improve the accuracy and efficiency of testing, assists developers in quickly locating and fixing software faults, and optimizes the instrument panel's main program.

[0109] like Figure 6 As shown, the automotive instrument software testing device proposed in this embodiment of the invention includes:

[0110] The parameter type acquisition module 10 is used to acquire the test task and determine the test parameter type based on the test task.

[0111] The simulation signal generation module 20 is used to generate a corresponding type of simulated MCU test signal through the QT simulation signal library according to the test parameter type.

[0112] The signal monitoring module 30 is used to transmit the simulated MCU test signal to the instrument panel under test, monitor the MCU of the instrument panel under test, and obtain the actual intermediate result data of the simulated MCU test signal.

[0113] The fault confirmation module 40 is used to obtain the real-time display results of the instrument panel under test, and determine the fault section of the instrument main program based on the simulated MCU test signal, actual intermediate result data and real-time display results.

[0114] In one embodiment, the signal monitoring module 30 is further configured to acquire the serial communication parameters and serial communication protocol of the instrument under test, wherein the serial communication parameters include serial port number, baud rate, data bits, parity bits and stop bits; and to initialize the communication configuration of the main program of the instrument under test and establish serial communication according to the serial communication protocol and serial communication parameters.

[0115] In one embodiment, the parameter type acquisition module 10 is further configured to acquire a test task, parse the test task to obtain the original vehicle signal data required in the test task; perform data reverse deduction based on the original vehicle signal data to determine the intermediate result data generated to achieve the display result; and summarize the original vehicle signal data and the intermediate result data to determine all test parameter types in the test task.

[0116] In one embodiment, the simulation signal generation module 20 is further configured to determine a simulation signal generation function based on the QT simulation signal library and the test parameter type; obtain the text box content corresponding to the test parameter type in the test program interface; and when the text box content is not empty, generate a simulation MCU test signal corresponding to the text box content through the simulation signal generation function based on the text box content.

[0117] In one embodiment, the simulation signal generation module 20 is further configured to: obtain the parameter range of the test parameter type when the text box content is empty; generate a random value of the test parameter type based on the parameter range using a random generation function; and generate a simulation MCU test signal corresponding to the random value using a simulation signal generation function.

[0118] In one embodiment, the fault confirmation module 40 is further configured to acquire the real-time display result of the instrument panel under test; obtain predicted intermediate result data based on the simulated MCU test signal; when the real-time display result differs from the simulated MCU test signal, and the predicted intermediate result data corresponds correctly with the actual intermediate result data, determine that the fault section of the instrument main program is located in the front-end code section; when the predicted intermediate result data differs from the actual intermediate result data, determine that the fault section of the instrument main program is located in the back-end code section.

[0119] In one embodiment, the fault confirmation module 40 is further configured to determine that the instrument main program is fault-free when the real-time display result corresponds correctly with the simulated MCU test signal and the predicted intermediate result data corresponds correctly with the actual intermediate result data.

[0120] Furthermore, to achieve the above objectives, the present invention provides an automotive instrument software testing device, which includes: a memory, a processor, and an automotive instrument software testing program stored in the memory and executable on the processor. The automotive instrument software testing program is configured to implement the steps of the automotive instrument software testing method described above.

[0121] Furthermore, to achieve the above objectives, the present invention provides a storage medium storing an automotive instrument software test program, which, when executed by a processor, implements the steps of the automotive instrument software test method.

[0122] It should be understood that although the steps in the flowcharts of this application's embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0123] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0124] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0125] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

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

[0127] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for testing automotive instrument panel software, characterized in that, The automotive instrument software testing method includes: Obtain the test task and determine the test parameter type based on the test task; The process of acquiring a test task and determining the test parameter type based on the test task includes: Obtain the test task, parse the test task, and obtain the raw vehicle signal data required in the test task; Based on the original vehicle signal data, data backwards are performed to determine the intermediate result data that will lead to the displayed result; The original vehicle signal data and the intermediate result data are summarized to determine all test parameter types in the test task; Based on the test parameter type, generate the corresponding type of simulated MCU test signal using the QT simulation signal library; The simulated MCU test signal is transmitted to the instrument panel under test, and the MCU of the instrument panel under test is monitored to obtain the actual intermediate result data of the simulated MCU test signal. Obtain the real-time display results of the instrument panel under test, and determine the faulty section of the instrument's main program based on the simulated MCU test signal, actual intermediate result data, and real-time display results; The process of obtaining the real-time display results of the instrument panel under test, and determining the faulty modules of the instrument's main program based on the simulated MCU test signals, actual intermediate result data, and real-time display results, includes: Obtain the real-time display results of the instrument panel under test; Based on the simulated MCU test signal, the predicted intermediate result data is obtained; When the real-time display result differs from the simulated MCU test signal, and the predicted intermediate result data corresponds correctly with the actual intermediate result data, it is determined that the faulty section of the instrument's main program is located in the front-end code section. When there is a difference between the predicted intermediate result data and the actual intermediate result data, it is determined that the faulty section of the instrument's main program is located in the backend code section.

2. The automotive instrument software testing method according to claim 1, characterized in that, Before obtaining the test task and determining the test parameter type based on the test task, the process further includes: The serial communication parameters and serial communication protocol of the instrument panel under test are obtained. The serial communication parameters include serial port number, baud rate, data bits, parity bits and stop bits. Based on the serial communication protocol and parameters, the main program of the instrument panel under test is initialized with communication configuration to establish serial communication.

3. The automotive instrument software testing method according to claim 1, characterized in that, The step of generating corresponding type of simulated MCU test signals using the QT simulation signal library based on the test parameter type includes: Based on the QT simulation signal library, the simulation signal generation function is determined according to the test parameter type; Retrieve the content of the text box corresponding to the test parameter type in the test program interface; When the text box content is not empty, the simulation MCU test signal corresponding to the text box content is generated according to the simulation signal generation function.

4. The automotive instrument software testing method according to claim 3, characterized in that, After obtaining the text box content corresponding to the test parameter type within the test program interface, the method further includes: When the text box is empty, obtain the parameter range of the test parameter type; Based on the parameter range, a random value for the test parameter type is generated using a random generation function; The simulated MCU test signal corresponding to the random value is generated using a simulated signal generation function.

5. The automotive instrument software testing method according to claim 1, characterized in that, The step of obtaining the real-time display results of the instrument panel under test, and determining the faulty module of the instrument's main program based on the simulated MCU test signal, actual intermediate result data, and real-time display results, further includes: Obtain the real-time display results of the instrument panel under test; Based on the simulated MCU test signal, the predicted intermediate result data is obtained; When the real-time display result corresponds correctly with the simulated MCU test signal, and the predicted intermediate result data corresponds correctly with the actual intermediate result data, it is determined that the instrument main program is fault-free.

6. A testing device for automotive instrument software, characterized in that, The automotive instrument software testing device includes: The parameter type acquisition module is used to acquire the test task and determine the test parameter type based on the test task. The parameter type acquisition module is also used to acquire a test task, parse the test task to obtain the original vehicle signal data required in the test task; perform data reverse deduction based on the original vehicle signal data to determine the intermediate result data generated to achieve the display result; and summarize the original vehicle signal data and the intermediate result data to determine all test parameter types in the test task. The simulation signal generation module is used to generate corresponding type of simulated MCU test signals according to the test parameter type through the QT simulation signal library; The signal monitoring module is used to transmit the simulated MCU test signal to the instrument panel under test, monitor the MCU of the instrument panel under test, and obtain the actual intermediate result data of the simulated MCU test signal. The fault confirmation module is used to obtain the real-time display results of the instrument panel under test, and determine the fault section of the instrument's main program based on the simulated MCU test signal, actual intermediate result data and real-time display results. The fault confirmation module is further configured to acquire the real-time display results of the instrument panel under test; obtain predicted intermediate result data based on the simulated MCU test signal; when the real-time display results differ from the simulated MCU test signal, and the predicted intermediate result data corresponds correctly with the actual intermediate result data, determine that the fault section of the instrument main program is located in the front-end code section; when the predicted intermediate result data differs from the actual intermediate result data, determine that the fault section of the instrument main program is located in the back-end code section.

7. A testing device for automotive instrument software, characterized in that, The automotive instrument software testing device includes: a memory, a processor, and an automotive instrument software testing program stored in the memory and executable on the processor, wherein the automotive instrument software testing program is configured to implement the steps of the automotive instrument software testing method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium stores an automotive instrument software test program, which, when executed by a processor, implements the steps of the automotive instrument software test method as described in any one of claims 1 to 5.

Images