Vehicle-mounted underlying software testing method, device and equipment and storage medium

Abstract

The invention discloses a vehicle-mounted underlying software testing method, device and equipment and a storage medium, and belongs to the technical field of automobiles. The vehicle-mounted underlying software test method comprises the following steps: generating a first configuration file based on a description document in test data of to-be-tested vehicle-mounted underlying software; generating a second configuration file based on a serial number corresponding to a target test case of the to-be-tested vehicle-mounted underlying software; and in a bus development environment, calling the first configuration file, the second configuration file and data except the description document in the test data by using a test script so as to complete the test of the to-be-tested vehicle-mounted underlying software and output a test result. The complicated test task load caused by the design difference of the controller can be effectively reduced, 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 field of automobile technology, and in particular to a vehicle-mounted underlying software testing method, device, equipment and computer-readable storage medium. Background Art

[0002] With the rapid development of automobile technology, the intelligence of vehicles is constantly improving, and the demand for testing vehicle-mounted underlying software is increasing. In related technologies, testers can use fixed test scripts to test most vehicle-mounted underlying software. However, different body controllers have certain differences in diagnostic trouble codes (DTC) and Someip interface design. For this part of the test, testers need to manually modify the test script according to the test data of the vehicle-mounted underlying software to complete the test, which results in a large test workload and low test efficiency. Summary of the invention

[0003] The present application provides a method, device, equipment and computer-readable storage medium for testing vehicle-mounted underlying software, which can solve the technical problems of some vehicle-mounted underlying software tests existing in the prior art, which require testers to manually modify the test script according to the test data of the vehicle-mounted underlying software to complete the test, resulting in large testing workload and low testing efficiency.

[0004] In a first aspect, an embodiment of the present application provides a vehicle-mounted underlying software testing method, the vehicle-mounted underlying software testing method comprising:

[0005] Generate a first configuration file based on a description document in the test data of the vehicle-mounted underlying software to be tested;

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

[0007] In a 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 description document to complete the test of the vehicle-mounted underlying software to be tested and output the test result.

[0008] In combination with the first aspect, in one implementation, generating a first configuration file based on a description document in a test document of the vehicle-mounted underlying software to be tested includes:

[0009] Identify the target fields in the description document in the test data of the vehicle-mounted underlying software to be tested;

[0010] 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 used as the first configuration file.

[0011] In combination with the first aspect, in one implementation, the generating of the second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested includes:

[0012] The serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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 one implementation, the test script is created based on a communication access programming language.

[0014] In combination with the first aspect, in one implementation, before the step of generating a first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested, the method further includes:

[0015] Obtain the file path of the test data of the vehicle-mounted underlying software to be tested from the pre-created graphical user interface;

[0016] According to the file path, obtain the test data of the vehicle-mounted underlying software to be tested;

[0017] Determining a serial number corresponding to a target test case from the graphical user interface, wherein the serial number corresponding to the visual test case is a test case selected by a user from the test case options;

[0018] Turn on the 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-mounted underlying software testing device, the vehicle-mounted underlying software testing device comprising:

[0020] A first generating module, which is used to generate a first configuration file based on a description document in a test data of the vehicle-mounted underlying software to be tested;

[0021] A second generating module, which is used to generate a second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested;

[0022] The test module is used to call the first configuration file, the second configuration file and the data in the test data except the description document by using the test script in the bus development environment to complete the test of the vehicle-mounted underlying software to be tested and output the test results.

[0023] In conjunction with the second aspect, in one implementation, the first generating module is specifically configured to:

[0024] Identify the target fields in the description document in the test data of the vehicle-mounted underlying software to be tested;

[0025] 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 used as the first configuration file.

[0026] In conjunction with the second aspect, in one implementation, the second generating module is specifically configured to:

[0027] The serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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.

[0028] In a third aspect, an embodiment of the present application provides a vehicle-mounted underlying software testing device, comprising a processor, a memory, and a vehicle-mounted underlying software testing program stored in the memory and executable by the processor, wherein when the vehicle-mounted underlying software testing program is executed by the processor, the steps of the vehicle-mounted underlying software testing method as described in any one of the first aspects are implemented.

[0029] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a vehicle-mounted underlying software testing program is stored. When the vehicle-mounted underlying software testing program is executed by a processor, the steps of the vehicle-mounted underlying software testing method as described in any one of the first aspects are implemented.

[0030] The beneficial effects brought by the technical solution provided in the embodiments of the present application include:

[0031] A first configuration file is generated based on the instruction document in the test data of the vehicle-mounted underlying software to be tested; a second configuration file is further generated based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested; then, in a bus development environment, the test script is used to automatically call the first configuration file, the second configuration file and the data in the test data except the instruction document to complete the test of the vehicle-mounted underlying software to be tested and output the test results. The present application has strong adaptability, which can effectively reduce the amount of complicated test tasks caused by differences in controller design, and there is no need to manually modify the test script, which can improve the test efficiency; the entire test process of the present application can be executed locally without calling a third-party cloud platform, thereby ensuring data security throughout the test process; the present application can test the communication, network management, routing, diagnosis, flashing and someip interface of the vehicle-mounted underlying software, has strong versatility, and is convenient for later integration and secondary development. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 This is a flow chart of the first embodiment of the vehicle-mounted underlying software testing method of the present application;

[0033] Figure 2 This is a functional module diagram of an embodiment of a vehicle-mounted underlying software testing device of the present application;

[0034] Figure 3 This is a schematic diagram of the hardware structure of the vehicle-mounted underlying software testing equipment involved in the embodiment of the present application. DETAILED DESCRIPTION

[0035] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

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

[0037] In a first aspect, an embodiment of the present application provides a method for testing vehicle-mounted underlying software.

[0038] In one embodiment, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the vehicle-mounted underlying software testing method of the present application. Figure 1 As shown in the figure, the vehicle-mounted underlying software testing method includes:

[0039] Step 110: Generate a first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested;

[0040] Among them, the test data of the vehicle-mounted underlying software to be tested includes description documents, test projects, dll key files, flash packages, etc. The description documents include but are not limited to diagnostic questionnaires, routing tables and communication matrix tables, wherein the matching relationship between input / output variables is stored in the description documents in advance. The format of the first configuration file is .ini format, which can be called by the test script in the bus development environment. Preferably, the test script in the bus development environment is created based on the Communication Access Programming Laguage (CAPL). CAPL is a programming language developed based on C language, specifically used in CANalyzer and CANoe bus environments.

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

[0042] In a specific implementation, a first configuration file is generated based on the description document in the test data of the vehicle-mounted bottom-layer software to be tested, so that the first configuration file can be automatically called by using a test script in a bus development environment.

[0043] Furthermore, in one embodiment, step 110 includes:

[0044] Step 1101, identifying a target field in a description document in a test document of the vehicle-mounted underlying software to be tested;

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

[0046] During specific implementation, the openpyxl library in the Python tool can be used to read and identify the target fields in the description document in the test data of the underlying vehicle software to be tested.

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

[0048] Furthermore, after identifying the target field in the description document in the test data of the vehicle-mounted underlying software to be tested, the target field is transferred to the first initialization configuration file to obtain an updated first initialization configuration file, and the updated first initialization configuration file is used as the first configuration file.

[0049] In this embodiment, the target field in the description document in the test data of the vehicle-mounted underlying software to be tested 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 used as the first configuration file, so that in the bus development environment, the first configuration file can be automatically called by using the test script, without manually changing the test script, thereby improving the test efficiency.

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

[0051] In specific implementation, based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested, a second configuration file is generated so that the second configuration file can be directly called by the test script in the bus development environment. The second configuration file is in .ini format and can be called by the test script in the bus development environment.

[0052] Further, in one embodiment, step 120 includes:

[0053] The serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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.

[0054] In specific implementation, a correspondence between serial numbers and test cases is pre-established, and the target test case is determined from the correspondence between the pre-established serial numbers and test cases according to the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested. The serial number corresponding to the target test case can be transferred to the second initialization configuration file through the Python tool to obtain an updated second initialization configuration file, and the updated second initialization configuration file is used as the second configuration file.

[0055] In this embodiment, the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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, so that in the bus development environment, the test script can be used to automatically call the second configuration file to obtain the serial number corresponding to the target test case, and the test case can be called according to the serial number, thereby realizing the mapping and calling of the serial number and the test case, without manually changing the test script, thereby improving the test efficiency.

[0056] Step 110 and step 120 can be developed and executed using open source and free Python tools, which can reduce testing costs.

[0057] Step 130: In a bus development environment, use a test script to call the first configuration file, the second configuration file, and the data in the test data except the description document to complete the test of the vehicle-mounted underlying software to be tested and output the test results.

[0058] Wherein, bus development environment includes but is not limited to CANalyzer and CANoe, and this application does not make specific limitation to this. The data in the test data other than the description document include test project, dll key file, flashing package, etc. The format of the test result is .xml or html format, so as to find the test problem point and test statistics. In addition, by parsing the test report, the overall results of different test cases can be counted.

[0059] The win32com library of the Python tool can be used to realize the automated control of the test project in the .cfg format to call the test project.

[0060] When the description document in the test data of the vehicle-mounted underlying software to be tested is a diagnostic questionnaire, the diagnosis-related tests are completed; when the description document in the test data of the vehicle-mounted underlying software to be tested is a routing table, the routing test is completed; when the description document in the test data of the vehicle-mounted underlying software to be tested is a communication matrix table, the CAN, Eth communication and interface tests are completed.

[0061] In specific implementation, in a bus development environment, the second configuration file is first called by a test script to read the serial number therein, and the target test case is determined according to the serial number from the correspondence between the pre-defined serial number and the test case.

[0062] Then, the test script is used to call the first configuration file and the data in the test data except the description document, and the target test cases of the vehicle-mounted underlying software to be tested are tested to output the test results.

[0063] In this embodiment, a first configuration file is generated based on the instruction document in the test data of the vehicle-mounted underlying software to be tested; a second configuration file is further generated based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested; then, in the bus development environment, the test script is used to automatically call the first configuration file, the second configuration file and the information in the test data except the instruction document to complete the test of the vehicle-mounted underlying software to be tested and output the test results. The present application has strong adaptability, which can effectively reduce the amount of complicated test tasks caused by differences in controller design, and there is no need to manually modify the test script, which can improve the test efficiency; the entire test process of the present application can be executed locally without calling a third-party cloud platform, thereby ensuring data security throughout the test process; the present application can test the communication, network management, routing, diagnosis, flashing and someip interface of the vehicle-mounted underlying software, has strong versatility, and is convenient for later integration and secondary development.

[0064] Furthermore, in one embodiment, before the step of generating the first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested, the method further includes:

[0065] Step S01, obtaining the file path of the test data of the vehicle-mounted underlying software to be tested from the pre-created graphical user interface;

[0066] Step S02: Acquire test data of the vehicle-mounted underlying software to be tested according to the file path;

[0067] Exemplarily, a Tkinter library of a Python tool may be used to create a graphical user interface GUI that includes identifying a specific file path, so that a user can select the file path of the test data of the vehicle-mounted underlying software to be tested.

[0068] During specific implementation, the user can select the file path of the test data of the vehicle-mounted underlying software to be tested in the graphical user interface, the Python tool obtains the file path of the test data of the vehicle-mounted underlying software to be tested from the graphical user interface, and then obtains the test data of the vehicle-mounted underlying software to be tested according to the file path.

[0069] Step S03: determining the serial number corresponding to the target test case from the graphical user interface, wherein the serial number corresponding to the visual test case is selected by the user from the test case options;

[0070] The graphical user interface also includes a test case option for the user to select the serial number corresponding to the 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] Step S04: Turn on the run button in the graphical user interface to execute the steps in the first aspect.

[0072] The graphical user interface also includes a run button. After obtaining the test data of the vehicle-mounted underlying software to be tested and the serial number corresponding to the target test case, the run button in the graphical user interface is turned on to execute the steps in the first aspect, namely steps 110 to 130.

[0073] In this embodiment, first, the file path of the test data of the vehicle-mounted underlying software to be tested is obtained from a pre-created graphical user interface; according to the file path, the test data of the vehicle-mounted underlying software to be tested is obtained; the serial number corresponding to the target test case is determined from the graphical user interface, and the serial number corresponding to the visual test case is selected by the user from the test case options; the run button in the graphical user interface is turned on to execute the steps in the first aspect. In this embodiment, each step can be developed and executed using the open source and free Python tool, which can reduce the testing cost; and the user can operate the graphical user interface simply and conveniently, which can simplify the testing process.

[0074] In a second aspect, an embodiment of the present application also provides a vehicle-mounted underlying software testing device.

[0075] In one embodiment, referring to Figure 2 , Figure 2 This is a functional module diagram of an embodiment of the vehicle-mounted bottom-layer software testing device of the present application. Figure 2 As shown, the vehicle-mounted bottom-layer software testing device 200 includes:

[0076] A first generating module 201, which is used to generate a first configuration file based on a description document in a test data of the vehicle-mounted underlying software to be tested;

[0077] A second generating module 202, which is used to generate a second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested;

[0078] The test module 203 is used to use the test script to call the first configuration file, the second configuration file and the data in the test data except the description document in the bus development environment to complete the test of the vehicle-mounted underlying software to be tested and output the test results.

[0079] Furthermore, in one embodiment, the first generating module is specifically used for:

[0080] Identify the target fields in the description document in the test data of the vehicle-mounted underlying software to be tested;

[0081] 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 used as the first configuration file.

[0082] Furthermore, in one embodiment, the second generating module is specifically used for:

[0083] The serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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.

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

[0085] Furthermore, in one embodiment, the vehicle-mounted bottom-layer software testing device further includes an opening module, and the opening module is specifically used to:

[0086] Before the step of generating the first configuration file based on the instruction document in the test data of the vehicle-mounted underlying software to be tested, the file path of the test data of the vehicle-mounted underlying software to be tested is obtained from a pre-created graphical user interface; the test data of the vehicle-mounted underlying software to be tested is obtained according to the file path; the serial number corresponding to the target test case is determined from the graphical user interface, and the serial number corresponding to the visual test case is selected by the user from the test case options; and the run button in the graphical user interface is turned on to execute the steps in the first aspect.

[0087] Among them, the functional implementation of each module in the above-mentioned vehicle-mounted underlying software testing device corresponds to the various steps in the above-mentioned vehicle-mounted underlying software testing method embodiment, and its functions and implementation processes will not be repeated here one by one.

[0088] In a third aspect, an embodiment of the present application provides a vehicle-mounted underlying software testing device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0089] Reference Figure 3 , Figure 3 The hardware structure diagram of the vehicle-mounted bottom-level software testing device involved in the embodiment of the present application is shown in FIG. In the embodiment of the present application, the vehicle-mounted bottom-level software testing device may include a processor, a memory, a communication interface, and a communication bus.

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

[0091] The communication interface includes input / output (I / O) interface, physical interface and logical interface, etc., which are used to realize the interconnection of devices inside the vehicle-mounted low-level software test equipment, and the interface used to realize the interconnection between the vehicle-mounted low-level software test equipment and other devices (such as other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.; the user device can be a display, a keyboard, etc.

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

[0093] The processor may be a general-purpose processor, which may call the vehicle-mounted underlying software test program stored in the memory and execute the vehicle-mounted underlying software test method provided in the embodiment of the present application. The vehicle-mounted underlying software test method includes: generating a first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested; generating a second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested; in a bus development environment, using a test script to call the first configuration file, the second configuration file and the data in the test data except the description document to complete the test of the vehicle-mounted underlying software to be tested and output the test results. For example, the general-purpose processor may be a central processing unit (CPU). Among them, the method executed when the vehicle-mounted underlying software test program is called can refer to the various embodiments of the vehicle-mounted underlying software test method of the present application.

[0094] Furthermore, in one embodiment, the generating of the first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested includes:

[0095] Identify the target fields in the description document in the test data of the vehicle-mounted underlying software to be tested;

[0096] 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 used as the first configuration file.

[0097] Further, in one embodiment, the generating of the second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested includes:

[0098] The serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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.

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

[0100] Furthermore, in one embodiment, before the step of generating the first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested, the method further includes:

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

[0102] According to the file path, obtain the test data of the vehicle-mounted underlying software to be tested;

[0103] Determining a serial number corresponding to a target test case from the graphical user interface, wherein the serial number corresponding to the visual test case is selected by a user from test case options;

[0104] Turn on the run button in the graphical user interface to execute the steps in the first aspect.

[0105] Those skilled in the art will understand that Figure 3 The hardware structure shown in the figure does not constitute a limitation on the present application, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0106] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium.

[0107] The computer-readable storage medium of the present application stores a vehicle-mounted underlying software test program, wherein when the vehicle-mounted underlying software test program is executed by a processor, the steps of the vehicle-mounted underlying software test method described above are implemented. The vehicle-mounted underlying software test method includes: generating a first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested; generating a second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested; in a bus development environment, using a test script to call the first configuration file, the second configuration file, and the data in the test data except the description document to complete the test of the vehicle-mounted underlying software to be tested and output the test results.

[0108] Among them, the method implemented when the vehicle-mounted underlying software testing program is executed can refer to the various embodiments of the vehicle-mounted underlying software testing method of the present application.

[0109] Furthermore, in one embodiment, the generating of the first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested includes:

[0110] Identify the target fields in the description document in the test data of the vehicle-mounted underlying software to be tested;

[0111] 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 used as the first configuration file.

[0112] Further, in one embodiment, the generating of the second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested includes:

[0113] The serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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.

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

[0115] Furthermore, in one embodiment, before the step of generating the first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested, the method further includes:

[0116] Obtain the file path of the test data of the vehicle-mounted underlying software to be tested from the pre-created graphical user interface;

[0117] According to the file path, obtain the test data of the vehicle-mounted underlying software to be tested;

[0118] Determining a serial number corresponding to a target test case from the graphical user interface, wherein the serial number corresponding to the visual test case is selected by a user from test case options;

[0119] Turn on the run 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 above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0121] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.

[0122] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0123] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

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

[0125] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.

[0126] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A vehicle-mounted bottom-level software testing method, characterized in that: The vehicle-mounted bottom-layer software testing method comprises: Generate a first configuration file based on a description document in the test data of the vehicle-mounted underlying software to be tested; Generate a second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested; In a 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 description document to complete the test of the vehicle-mounted underlying software to be tested and output the test result.

2. The vehicle-mounted underlying software testing method according to claim 1, characterized in that: The generating of the first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested includes: Identify the target fields in the description document in the test data of the vehicle-mounted underlying software to be tested; 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 used as the first configuration file.

3. The vehicle-mounted bottom-level software testing method according to claim 1, characterized in that: The generating of the second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested comprises: The serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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.

4. The vehicle-mounted bottom-level software testing method according to claim 1, characterized in that: The test script is created based on a communication access programming language.

5. The vehicle-mounted bottom-level software testing method according to claim 1, characterized in that: Before the step of generating the first configuration file based on the description document in the test data of the vehicle-mounted underlying software to be tested, the method further includes: Obtain the file path of the test data of the vehicle-mounted underlying software to be tested from the pre-created graphical user interface; According to the file path, obtain the test data of the vehicle-mounted underlying software to be tested; Determining a serial number corresponding to a target test case from the graphical user interface, wherein the serial number corresponding to the visual test case is selected by a user from test case options; Turn on the run button in the graphical user interface to execute the steps in claim 1.

6. A vehicle-mounted bottom-level software testing device, characterized in that: The vehicle-mounted bottom-layer software testing device comprises: A first generating module, which is used to generate a first configuration file based on a description document in a test data of the vehicle-mounted underlying software to be tested; A second generating module, which is used to generate a second configuration file based on the serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested; The test module is used to use the test script to call the first configuration file, the second configuration file and the data in the test data except the description document in the bus development environment to complete the test of the vehicle-mounted underlying software to be tested and output the test results.

7. The vehicle-mounted bottom-level software testing device according to claim 6, characterized in that: The first generating module is specifically used for: Identify the target fields in the description document in the test data of the vehicle-mounted underlying software to be tested; 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 used as the first configuration file.

8. The vehicle-mounted bottom-level software testing device according to claim 6, characterized in that: The second generating module is specifically used for: The serial number corresponding to the target test case of the vehicle-mounted underlying software to be tested 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.

9. A vehicle-mounted bottom-level software testing device, characterized in that: The on-board low-level software testing device includes a processor, a memory, and a on-board low-level software testing program stored in the memory and executable by the processor, wherein when the on-board low-level software testing program is executed by the processor, the steps of the on-board low-level software testing method as described in any one of claims 1 to 5 are implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a vehicle-mounted underlying software testing program, wherein when the vehicle-mounted underlying software testing program is executed by a processor, the steps of the vehicle-mounted underlying software testing method as described in any one of claims 1 to 5 are implemented.

Images