Vehicle bottom-layer software testing method, device, equipment and storage medium

Abstract

A vehicle bottom layer software testing method, device and equipment and storage medium belong to the field of automobile technology. The vehicle bottom layer software testing method comprises the following steps: generating a first configuration file based on the specification document in the test data of the vehicle bottom layer software to be tested; generating a second configuration file based on the serial number corresponding to the target test case of the vehicle bottom layer software to be tested; in a bus development environment, calling the first configuration file, the second configuration file and the data in the test data except the specification document by using a test script, so as to complete the test of the vehicle bottom layer software to be tested, output the test result, and effectively reduce the complex test task quantity caused by the difference in controller design. The test script does not need to be manually modified, and the test efficiency can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobiles, in particular to a vehicle bottom-layer software testing method, device, equipment and computer readable storage medium. BACKGROUND

[0002] With the rapid development of automobile technology, the intelligent degree of vehicles is continuously improved, and the testing demand for vehicle bottom-layer software is also increasing. In the related technology, testers can use fixed test scripts to test most vehicle bottom-layer software. However, different body controllers have certain differences in diagnostic trouble code (DTC) and someip interface design, and for this part of the test, testers need to manually modify the test script according to the test data of the vehicle bottom-layer software to be tested to complete the test, which is labor-intensive and low in efficiency. SUMMARY

[0003] The present application provides a vehicle bottom-layer software testing method, device, equipment and computer readable storage medium, which can solve the technical problems of the prior art that part of the vehicle bottom-layer software testing needs testers to manually modify the test script according to the test data of the vehicle bottom-layer software to be tested to complete the test, which is labor-intensive and low in efficiency.

[0004] In a first aspect, the embodiments of the present application provide a vehicle bottom-layer software testing method, which comprises:

[0005] generating a first configuration file based on the specification document in the test data of the vehicle bottom-layer software to be tested;

[0006] generating a second configuration file based on the serial number corresponding to the target test case of the vehicle bottom-layer software to be tested;

[0007] In a bus development environment, the first configuration file, the second configuration file and the data in the test data except the specification document are called by a test script to complete the test of the vehicle bottom-layer software to be tested, and a test result is output.

[0008] In combination with the first aspect, in an implementation mode, the first configuration file is generated based on the specification document in the test data of the vehicle bottom-layer software to be tested, which comprises:

[0009] identifying a target field in the specification document in the test data of the vehicle bottom-layer software to be tested;

[0010] writing the target field into a first initialization configuration file to obtain an updated first initialization configuration file, and taking the updated first initialization configuration file as the first configuration file.

[0011] In combination with the first aspect, in an implementation, the second configuration file is generated based on the serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software.

[0012] The serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software is written into the second initialization configuration file to obtain an updated second initialization configuration file, and the updated second initialization configuration file is used as the second configuration file.

[0013] In combination with the first aspect, in an implementation, the test script is created based on a communication access programming language.

[0014] In combination with the first aspect, in an implementation, before the step of generating the first configuration file based on the specification document in the test data of the to-be-tested vehicle bottom-layer software, the method further includes:

[0015] obtaining a file path of the test data of the to-be-tested vehicle bottom-layer software from a pre-created graphical user interface;

[0016] obtaining the test data of the to-be-tested vehicle bottom-layer software according to the file path;

[0017] determining the serial number corresponding to the target test case from the graphical user interface, the serial number corresponding to the target test case being a test case selected by a user from test case options;

[0018] starting a run button in the graphical user interface to execute the steps in the first aspect.

[0019] In a second aspect, an embodiment of the present application provides a vehicle bottom-layer software testing device, which includes:

[0020] a first generation module configured to generate a first configuration file based on a specification document in test data of to-be-tested vehicle bottom-layer software;

[0021] a second generation module configured to generate a second configuration file based on a serial number corresponding to a target test case of the to-be-tested vehicle bottom-layer software;

[0022] a test module configured to call the first configuration file, the second configuration file, and data in the test data except the specification document in a bus development environment by using a test script, so as to complete testing of the to-be-tested vehicle bottom-layer software and output a test result.

[0023] In combination with the second aspect, in an implementation, the first generation module is specifically configured to:

[0024] identify a target field in the specification document in the test data of the to-be-tested vehicle bottom-layer software;

[0025] write the target field into the first initialization configuration file to obtain an updated first initialization configuration file, and take the updated first initialization configuration file as the first configuration file.

[0026] With reference to the second aspect, in an implementation, the second generation module is specifically configured to:

[0027] write the serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software into the second initialization configuration file to obtain an updated second initialization configuration file, and take the updated second initialization configuration file as the second configuration file.

[0028] In a third aspect, an embodiment of the present application provides a vehicle bottom-layer software testing device, which comprises a processor, a memory, and a vehicle bottom-layer software testing program stored in the memory and executable by the processor, and when the vehicle bottom-layer software testing program is executed by the processor, the steps of the vehicle bottom-layer software testing method according to any one of the first aspect are implemented.

[0029] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a vehicle bottom-layer software testing program, and when the vehicle bottom-layer software testing program is executed by a processor, the steps of the vehicle bottom-layer software testing method according to any one of the first aspect are implemented.

[0030] The technical scheme provided by the embodiments of the present application has the following beneficial effects:

[0031] The first configuration file is generated based on the specification document in the test data of the to-be-tested vehicle bottom-layer software, the second configuration file is further generated based on the serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software, and then in the bus development environment, the first configuration file, the second configuration file and the data in the test data except the specification document are automatically called by the test script, so as to complete the test on the to-be-tested vehicle bottom-layer software and output the test result. The present application has strong adaptability, can effectively reduce the complex test task quantity caused by the difference in controller design, does not need to manually modify the test script, and can improve the test efficiency. The whole test process of the present application can be executed locally, without calling a third-party cloud platform, so as to ensure the data security of the whole test process. The present application can test the communication, network management, routing, diagnosis, flashing and someip interface of the vehicle bottom-layer software, has strong universality, and is convenient for later integration and secondary development. BRIEF DESCRIPTION OF DRAWINGS

[0032] Figure 1 FIG. 1 is a flowchart of a vehicle bottom-layer software testing method according to an embodiment of the present application;

[0033] Figure 2 Figure 1 is a functional module schematic diagram of an embodiment of a vehicle bottom-layer software testing device according to the present application;

[0034] Figure 3 Figure 2 is a hardware structure schematic diagram of a vehicle bottom-layer software testing device according to the present application. DETAILED DESCRIPTION

[0035] In order to enable persons skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative labor fall within the scope of protection of the present application.

[0036] In order to make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

[0037] In a first aspect, the embodiments of the present application provide a vehicle bottom-layer software testing method.

[0038] In an embodiment, with reference to Figure 1 , Figure 1 Figure 3 is a flow schematic diagram of a first embodiment of a vehicle bottom-layer software testing method according to the present application. As shown in Figure 3, the vehicle bottom-layer software testing method comprises: Figure 1

[0039] Step 110, generating a first configuration file based on an instruction document in test data of a vehicle bottom-layer software to be tested;

[0040] The test data of the vehicle bottom-layer software to be tested comprises an instruction document, a test project, a dll key file, a flashing package, etc. The instruction document comprises but is not limited to a diagnostic questionnaire, a routing table and a communication matrix table, wherein a matching relationship between input / output variables is stored in the instruction document in advance. The format of the first configuration file is.ini format, which can be called by a test script in a bus development environment. Preferably, the test script in the bus development environment is created based on a communication access programming language (CAPL). CAPL is a programming language developed based on C language, which is specially used for CANalyzer and CANoe bus environment.

[0041] In the test implementation, the instruction document is a table format file, which can be in.xlsx format, and the table format is consistent.

[0042] ​In implementation, based on the specification document in the test data of the to-be-tested vehicle bottom-layer software, the first configuration file is generated for automatic calling of the first configuration file by the test script in the bus development environment.

[0043] Further, in an embodiment, the step 110 comprises:

[0044] Step 1101: identifying a target field in a specification document in the test data of the to-be-tested vehicle bottom-layer software;

[0045] Step 1102: writing the target field into the first initialization configuration file to obtain an updated first initialization configuration file, and taking the updated first initialization configuration file as the first configuration file.

[0046] In implementation, the openpyxl library in the Python tool can be used to read and identify the target field in the specification document in the test data of the to-be-tested vehicle bottom-layer software.

[0047] When the specification document is a diagnostic questionnaire, the corresponding target field includes DTC maturity adjustment, negative code (NRC) and specific supported services; when the specification document is a routing table, the corresponding target field includes the routing relationship of the controller; and when the specification document is a communication matrix table, the corresponding target field includes the message sending and receiving information of the controller.

[0048] Further, after the target field in the specification document in the test data of the to-be-tested vehicle bottom-layer software is identified, the target field is transmitted into the first initialization configuration file to obtain an updated first initialization configuration file, and the updated first initialization configuration file is taken as the first configuration file.

[0049] In the embodiment, the target field in the specification document in the test data of the to-be-tested vehicle bottom-layer software is identified, and then the target field is written into the first initialization configuration file to obtain an updated first initialization configuration file, and the updated first initialization configuration file is taken as the first configuration file, so that the first configuration file is automatically called by the test script in the bus development environment, without manual modification of the test script, and the test efficiency is improved.

[0050] Step 120: generating a second configuration file based on a serial number corresponding to a target test case of the to-be-tested vehicle bottom-layer software;

[0051] In implementation, the second configuration file is generated based on the serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software for direct calling of the second configuration file by the test script in the bus development environment. The format of the second configuration file is.ini format, and the second configuration file can be called by the test script in the bus development environment.

[0052] Further, in an embodiment, step 120 comprises;

[0053] The serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software is written into the second initialization configuration file to obtain an updated second initialization configuration file, and the updated second initialization configuration file is taken as the second configuration file.

[0054] In a specific implementation, a correspondence between serial numbers and test cases is prepared in advance, and the target test case is determined from the correspondence between serial numbers and test cases according to the serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software. The serial number corresponding to the target test case can be transmitted to the second initialization configuration file by using a Python tool to obtain an updated second initialization configuration file, and the updated second initialization configuration file is taken as the second configuration file.

[0055] In this embodiment, the serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software is written into the second initialization configuration file to obtain an updated second initialization configuration file, and the updated second initialization configuration file is taken as the second configuration file, so that the serial number corresponding to the target test case is automatically obtained by using a test script to call the second configuration file in a bus development environment, and the test case is called according to the serial number, thereby realizing mapping and calling of the serial number and the test case, without manually changing the test script, and improving test efficiency.

[0056] Steps 110 and 120 can be developed and executed by using an open-source and free Python tool, which can reduce test cost.

[0057] Step 130, in the bus development environment, the test script is used to call the first configuration file, the second configuration file, and the data in the test data except the specification document, to complete the test on the to-be-tested vehicle bottom-layer software, and output a test result.

[0058] The bus development environment includes but is not limited to CANalyzer and CANoe, which are not limited in the present application. The data in the test data except the specification document include test engineering, dll key files, and flashing packages. The test result is in a.xml or.html format, so as to find test problem points and test statistics. In addition, by analyzing the test report, the overall result of different test cases can be counted.

[0059] The win32com library of the Python tool can be used to realize automatic control of the test engineering in a.cfg format, so as to call the test engineering.

[0060] When the specification document in the test material of the to-be-tested vehicle bottom-layer software is a diagnostic questionnaire, the diagnostic-related test is completed; when the specification document in the test material of the to-be-tested vehicle bottom-layer software is a routing table, the routing test is completed; and when the specification document in the test material of the to-be-tested vehicle bottom-layer software is a communication matrix table, the CAN and Eth communication and interface test are completed.

[0061] In the implementation, in the bus development environment, the test script is first used to call the second configuration file to read the serial number therein, and according to the serial number, the target test case is determined from the correspondence between the serial number and the test case.

[0062] Then the test script is used to call the first configuration file and the material in the test material except the specification document, and the test on each target test case of the to-be-tested vehicle bottom-layer software is started, and the test result is output.

[0063] In the embodiment, the first configuration file is generated based on the specification document in the test material of the to-be-tested vehicle bottom-layer software, the second configuration file is further generated based on the serial number corresponding to the target test case of the to-be-tested vehicle bottom-layer software, and then in the bus development environment, the test script is used to automatically call the first configuration file, the second configuration file and the material in the test material except the specification document, so as to complete the test on the to-be-tested vehicle bottom-layer software and output the test result. The application has strong adaptability, can effectively reduce the complex test task amount caused by the difference in controller design, does not need to manually modify the test script, can improve the test efficiency, the whole test process of the application can be executed locally, does not need to call a third-party cloud platform, and the data safety of the whole test process is ensured, the application can test the communication, network management, routing, diagnosis, flashing and someip interface of the vehicle bottom-layer software, has strong universality, and is convenient for later integration and secondary development.

[0064] Further, in an embodiment, before the step of generating the first configuration file based on the specification document in the test material of the to-be-tested vehicle bottom-layer software, the method further includes:

[0065] Step S01: obtaining a file path of the test material of the to-be-tested vehicle bottom-layer software from a pre-created graphical user interface;

[0066] Step S02: obtaining the test material of the to-be-tested vehicle bottom-layer software according to the file path;

[0067] For example, a graphical user interface GUI containing a specific file path identifier can be created by using the Tkinter library of the Python tool, so as to enable the user to select the file path of the test material of the to-be-tested vehicle bottom-layer software.

[0068] In implementation, the user can select a file path of test data of the to-be-tested vehicle bottom-layer software in the graphical user interface, and the Python tool obtains the file path of the test data of the to-be-tested vehicle bottom-layer software from the graphical user interface, and then obtains the test data of the to-be-tested vehicle bottom-layer software according to the file path.

[0069] In step S03, a serial number corresponding to a target test case is determined from the graphical user interface, where the serial number is selected by the user from test case options.

[0070] The graphical user interface further includes test case options for the user to select a serial number corresponding to a target test case. After the user selects the serial number corresponding to the target test case from the graphical user interface, the Python tool determines the serial number corresponding to the target test case from the graphical user interface.

[0071] In step S04, a run button in the graphical user interface is started to execute the steps in the first aspect.

[0072] The graphical user interface further includes a run button. After the test data of the to-be-tested vehicle bottom-layer software and the serial number corresponding to the target test case are obtained, the run button in the graphical user interface is started to execute the steps in the first aspect, i.e., steps 110 to 130.

[0073] In this embodiment, the file path of the test data of the to-be-tested vehicle bottom-layer software is first obtained from a pre-created graphical user interface, the test data of the to-be-tested vehicle bottom-layer software is obtained according to the file path, the serial number corresponding to the target test case is determined from the graphical user interface, where the serial number is selected by the user from test case options, and the run button in the graphical user interface is started to execute the steps in the first aspect. The steps in this embodiment can be developed and executed by using the open-source and free Python tool, which can reduce the test cost. The user can operate the graphical user interface simply and conveniently, and the test process can be simplified.

[0074] In the second aspect, the embodiments of the present application further provide a vehicle bottom-layer software testing device.

[0075] In one embodiment, the vehicle bottom-layer software testing device 200 is configured to perform the steps in the first aspect. Figure 2 , Figure 2 FIG. 1 is a schematic diagram of functional modules of an embodiment of the vehicle bottom-layer software testing device according to the present application. As shown in FIG. 1, the vehicle bottom-layer software testing device 200 includes: Figure 2

[0076] The first generation module 201 is configured to generate a first configuration file based on a specification document in test data of a to-be-tested vehicle bottom-layer software.

[0077] ​a second generation module 202, configured to generate a second configuration file based on a serial number corresponding to a target test case of the to-be-tested vehicle underlying software;

[0078] a test module 203, configured to call the first configuration file, the second configuration file and test data except the specification document in the test data in a test script in a bus development environment, so as to complete the test on the to-be-tested vehicle underlying software, and output a test result.

[0079] Further, in an embodiment, the first generation module is specifically configured to:

[0080] identify a target field in the specification document in the test data of the to-be-tested vehicle underlying software;

[0081] write the target field into the first initialization configuration file to obtain an updated first initialization configuration file, and take the updated first initialization configuration file as the first configuration file.

[0082] Further, in an embodiment, the second generation module is specifically configured to:

[0083] write the serial number corresponding to the target test case of the to-be-tested vehicle underlying software into the second initialization configuration file to obtain an updated second initialization configuration file, and take the updated second initialization configuration file as the second configuration file.

[0084] Further, in an embodiment, the test script is created based on a communication access programming language.

[0085] Further, in an embodiment, the vehicle underlying software testing apparatus further comprises an opening module, which is specifically configured to:

[0086] before the step of generating the first configuration file based on the specification document in the test data of the to-be-tested vehicle underlying software, acquire a file path of the test data of the to-be-tested vehicle underlying software from a pre-created graphical user interface; acquire the test data of the to-be-tested vehicle underlying software according to the file path; determine a serial number corresponding to a target test case from the graphical user interface, the serial number corresponding to the target test case being selected by a user from test case options; and open a run button in the graphical user interface to execute the steps in the first aspect.

[0087] Correspondingly, the functions of each module in the vehicle underlying software testing apparatus and the steps in the vehicle underlying software testing method embodiment are not repeated here.

[0088] In a third aspect, the embodiments of the present application provide a vehicle bottom-layer software testing device. The vehicle bottom-layer software testing device can be a personal computer (PC), a notebook computer, a server, or the like device having a data processing function.

[0089] Referring to Figure 3 , Figure 3 FIG. 1 is a schematic diagram of a hardware structure of a vehicle bottom-layer software testing device according to an embodiment of the present application. In the embodiment of the present application, the vehicle bottom-layer software testing device can include a processor, a memory, a communication interface, and a communication bus.

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

[0091] The communication interface includes an input / output (I / O) interface, a physical interface, and a logical interface, and the like interface used to interconnect devices inside the vehicle bottom-layer software testing device, and an interface used to interconnect the vehicle bottom-layer software testing device with other devices (for example, other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber interface, an ATM interface, or the like. The user device can be a display (Display), a keyboard (Keyboard), or the like.

[0092] The memory can be various types of storage media, such as a random access memory (RAM), a read-only memory (ROM), a non-volatile RAM (NVRAM), a flash memory, an optical storage, a hard disk, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), or the like.

[0093] The processor can be a general-purpose processor, which can invoke an in-vehicle underlying software test program stored in a memory and execute an in-vehicle underlying software test method provided by the embodiments of the application. The in-vehicle underlying software test method comprises: generating a first configuration file based on a specification document in test data of the in-vehicle underlying software to be tested; generating a second configuration file based on a serial number corresponding to a target test case of the in-vehicle underlying software to be tested; and invoking the first configuration file, the second configuration file and data in the test data except the specification document in a bus development environment by using a test script, so as to complete the test of the in-vehicle underlying software to be tested and output a test result. For example, the general-purpose processor can be a central processing unit (CPU). The method executed by the in-vehicle underlying software test program can refer to various embodiments of the in-vehicle underlying software test method of the application.

[0094] Further, in an embodiment, the first configuration file is generated based on the specification document in the test data of the in-vehicle underlying software to be tested, and the generating the first configuration file comprises:

[0095] identifying a target field in the specification document in the test data of the in-vehicle underlying software to be tested;

[0096] writing the target field into a first initialization configuration file to obtain an updated first initialization configuration file, and taking the updated first initialization configuration file as the first configuration file.

[0097] Further, in an embodiment, the second configuration file is generated based on the serial number corresponding to the target test case of the in-vehicle underlying software to be tested, and the generating the second configuration file comprises:

[0098] writing the serial number corresponding to the target test case of the in-vehicle underlying software to be tested into a second initialization configuration file to obtain an updated second initialization configuration file, and taking the updated second initialization configuration file as the second configuration file.

[0099] Further, in an embodiment, the test script is created based on a communication access programming language.

[0100] Further, in an embodiment, before the step of generating the first configuration file based on the specification document in the test data of the in-vehicle underlying software to be tested, the method further comprises:

[0101] obtaining a file path of the test data of the in-vehicle underlying software to be tested from a pre-created graphical user interface;

[0102] obtaining the test data of the in-vehicle underlying software to be tested according to the file path;

[0103] determining a serial number corresponding to the target test case from the graphical user interface, the serial number corresponding to the target test case being filtered out by the user from the test case options;

[0104] starting a running button in the graphical user interface to execute the steps in the first aspect.

[0105] Those skilled in the art can understand that, Figure 3 The hardware structure shown in the foregoing embodiments is not a limitation to the present application, and can include more or less components than those shown, or combine certain components, or arrange different components.

[0106] In a fourth aspect, the embodiments of the present application further provide a computer readable storage medium.

[0107] The computer readable storage medium of the present application stores a vehicle bottom-layer software test program therein, wherein the vehicle bottom-layer software test program, when executed by a processor, implements the steps of the vehicle bottom-layer software test method as described above. The vehicle bottom-layer software test method comprises: generating a first configuration file based on a specification document in test data of a vehicle bottom-layer software to be tested; generating a second configuration file based on a serial number corresponding to a target test case of the vehicle bottom-layer software to be tested; and in a bus development environment, calling the first configuration file, the second configuration file and data in the test data except the specification document by using a test script, so as to complete the test of the vehicle bottom-layer software to be tested, and output a test result.

[0108] The method implemented when the vehicle bottom-layer software test program is executed can refer to each embodiment of the vehicle bottom-layer software test method of the present application.

[0109] Further, in an embodiment, the generating of the first configuration file based on the specification document in the test data of the vehicle bottom-layer software to be tested comprises:

[0110] identifying a target field in the specification document in the test data of the vehicle bottom-layer software to be tested;

[0111] writing the target field into a first initialization configuration file to obtain an updated first initialization configuration file, and taking the updated first initialization configuration file as the first configuration file.

[0112] Further, in an embodiment, the generating of the second configuration file based on the serial number corresponding to the target test case of the vehicle bottom-layer software to be tested comprises:

[0113] writing the serial number corresponding to the target test case of the vehicle bottom-layer software to be tested into a second initialization configuration file to obtain an updated second initialization configuration file, and taking the updated second initialization configuration file as the second configuration file.

[0114] Further, in an embodiment, the test script is created based on a communication access programming language.

[0115] Further, in an embodiment, before the step of generating the first configuration file based on the description document in the test data of the to-be-tested vehicle bottom-layer software, the method further comprises:

[0116] obtaining a file path of the test data of the to-be-tested vehicle bottom-layer software from a pre-created graphical user interface;

[0117] obtaining the test data of the to-be-tested vehicle bottom-layer software according to the file path;

[0118] determining a serial number corresponding to a target test case from the graphical user interface, the serial number corresponding to the target test case being selected by a user from test case options;

[0119] starting a running button in the graphical user interface to execute the steps in the first aspect.

[0120] It should be noted that the serial numbers of the embodiments of the present application described above are merely for description, and do not represent the advantages or disadvantages of the embodiments.

[0121] The terms “include”, “has” and “has” and any variations thereof in the specification and claims of the present application and the above-described drawings are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but can optionally include steps or units not listed, or can optionally include other steps or units inherent to the process, method, product or device. The terms “first”, “second” and “third” and the like are used to distinguish different objects, and do not represent the order or limit the types of “first”, “second” and “third”.

[0122] In the description of the embodiments of the present application, “exemplary”, “for example” or “for instance” is used to represent an example, illustration or description. Any embodiment or design scheme described as “exemplary”, “for example” or “for instance” in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words “exemplary”, “for example” or “for instance” are intended to present the relevant concept in a specific manner.

[0123] In the description of the embodiments of the present application, unless otherwise specified, " / " means the meaning of or, for example, A / B can mean A or B; the text "and / or" only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist together, and B exists alone, and in addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0124] In some of the processes described in the embodiments of the present application, a plurality of operations or steps are included in a specific order, but it should be understood that these operations or steps can be executed or in parallel without the order in which they appear in the embodiments of the present application, and the serial number of the operation is only used to distinguish different operations, and the serial number itself does not represent any execution order. In addition, these processes can include more or fewer operations, and these operations or steps can be executed in sequence or in parallel, and these operations or steps can be combined.

[0125] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by means of software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, an optical disk) as described above, and includes a plurality of instructions for making a terminal device execute the method described in each embodiment of the present application.

[0126] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation using the content of the present application specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. An in-vehicle middleware testing method characterized by comprising: The vehicle bottom software testing method comprises the following steps: generating a first configuration file based on a description document in test data of the vehicle bottom software to be tested; generating a second configuration file based on a serial number corresponding to a target test case of the vehicle bottom software to be tested; in a bus development environment, calling the first configuration file, the second configuration file and data in the test data except the description document by using a test script, so as to complete the test of the vehicle bottom software to be tested and output a test result; the first configuration file is generated based on the description document in the test data of the vehicle bottom software to be tested, and the first configuration file comprises the following steps: identifying a target field in the description document in the test data of the vehicle bottom software to be tested; writing the target field into a first initialization configuration file to obtain an updated first initialization configuration file, and taking the updated first initialization configuration file as the first configuration file; the second configuration file is generated based on the serial number corresponding to the target test case of the vehicle bottom software to be tested, and the second configuration file comprises the following steps: writing the serial number corresponding to the target test case of the vehicle bottom software to be tested into a second initialization configuration file to obtain an updated second initialization configuration file, and taking the updated second initialization configuration file as the second configuration file.

2. The in-vehicle middleware testing method of claim 1, wherein, The test script is created based on a communication access programming language.

3. The in-vehicle middleware testing method of claim 1, wherein, Before the step of generating the first configuration file based on the description document in the test data of the vehicle bottom software to be tested, the method further comprises the following steps: obtaining a file path of the test data of the vehicle bottom software to be tested from a pre-created graphical user interface; obtaining the test data of the vehicle bottom software to be tested according to the file path; determining a serial number corresponding to a target test case from the graphical user interface, wherein the serial number corresponding to the target test case is selected by a user from a test case option; starting a running button in the graphical user interface to execute the steps in claim 1.

4. An in-vehicle middleware testing apparatus characterized by comprising: The vehicle bottom software testing device comprises: a first generation module configured to generate a first configuration file based on a description document in test data of a vehicle bottom software to be tested; a second generation module configured to generate a second configuration file based on a serial number corresponding to a target test case of the vehicle bottom software to be tested; a test module configured to call the first configuration file, the second configuration file and data in the test data except the description document by using a test script in a bus development environment, so as to complete the test of the vehicle bottom software to be tested and output a test result; the first generation module is specifically configured to: identify a target field in the description document in the test data of the vehicle bottom software to be tested; write the target field into a first initialization configuration file to obtain an updated first initialization configuration file, and take the updated first initialization configuration file as the first configuration file; the second generation module is specifically configured to: write the serial number corresponding to the target test case of the vehicle bottom software to be tested into a second initialization configuration file to obtain an updated second initialization configuration file, and take the updated second initialization configuration file as the second configuration file.

5. An in-vehicle middleware testing apparatus characterized by comprising: The vehicle bottom-layer software testing device comprises a processor, a memory, and a vehicle bottom-layer software testing program stored on the memory and executable by the processor, wherein the vehicle bottom-layer software testing program, when executed by the processor, implements the steps of the vehicle bottom-layer software testing method according to any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a vehicle bottom-layer software testing program, wherein the vehicle bottom-layer software testing program, when executed by a processor, implements the steps of the vehicle bottom-layer software testing method according to any one of claims 1 to 3.

Images