Automatic vehicle testing method and device, electronic equipment and storage medium

Abstract

The invention provides a vehicle automatic testing method and device, electronic equipment and a storage medium. The method comprises the steps that a data identifier of at least one target diagnosis parameter of a to-be-tested vehicle is acquired; obtaining a test case corresponding to the target diagnosis parameter according to the data identifier, wherein the test case comprises a test script and an expected result; assembling a test message based on the test cases, and sending the test message to the to-be-tested vehicle for testing based on a vehicle diagnosis protocol to obtain a response result corresponding to each test case; the response result corresponding to each test case is compared with the expected result, the test result is obtained based on the comparison result, and through the method, the technical problem that in the related technology, manual testing needs to be carried out, and a large amount of manpower and time are consumed is solved.

Description

Technical Field

[0001] This application relates to the technical field of automated testing, and particularly relates to a vehicle automated testing method, device, electronic device, and storage medium. Background Art

[0002] Since its inception, the UDS (Unified Diagnostic Services) protocol has undergone multiple iterations and optimizations and has gradually become an important standard in the field of automotive diagnosis and repair. In modern automotive diagnosis, the application of the UDS protocol has far exceeded the traditional diagnostic field. It can not only handle traditional diagnostic functions such as reading fault codes, clearing fault codes, and reading data streams, but also extends to multiple aspects such as software update, parameter configuration, and performance monitoring. This makes the UDS protocol a bridge connecting vehicles to the external world and plays an important role especially in vehicle networking technology and intelligent transportation systems.

[0003] However, despite the powerful functions and wide application scenarios of the UDS protocol, there are still some challenges in actual diagnostic tests. In related technologies, UDS diagnostic tests mainly rely on manual operations by test engineers. Test engineers need to view diagnostic questionnaires and manually perform tests on the diagnostic instrument one by one according to the DID (Data Identifier). This manual operation method is not only inefficient but also error-prone. Test engineers need to spend a lot of time and effort editing and sending messages, and at the same time need to carefully analyze the captured messages to judge the test results. This not only increases the cost and time of the test but also may affect the accuracy and reliability of the test. Summary of the Invention

[0004] In view of the above-mentioned disadvantages of related technologies, this application provides a vehicle automated testing method, device, electronic device, and storage medium to solve the technical problem in related technologies that manual testing requires a large amount of manpower and time.

[0005] This application provides a vehicle automated testing method, and the vehicle automated testing method includes: obtaining data identifiers of at least one target diagnostic parameter of a vehicle to be tested; obtaining a test case corresponding to the target diagnostic parameter according to the data identifier, where the test case includes a test script and an expected result; assembling a test message based on the test case, and sending the test message to the vehicle to be tested for testing based on a vehicle diagnostic protocol to obtain a response result corresponding to each test case; comparing the response result corresponding to each test case with the expected result, and obtaining a test result based on the comparison result.

[0006] In one embodiment of the present application, obtaining the data identifiers of at least one target diagnostic parameter of the vehicle to be tested includes: obtaining a diagnostic questionnaire and extracting the data identifiers of each target diagnostic parameter in the diagnostic questionnaire; wherein, each of the target diagnostic parameters at least includes sensor parameters for diagnosing the vehicle running state, vehicle information parameters for obtaining the basic information of the vehicle, and fault code parameters for reading and clearing the vehicle fault codes.

[0007] In one embodiment of the present application, sending the test message to the vehicle to be tested for testing includes: establishing a DoIP connection with the vehicle to be tested and sending the test message to the vehicle to be tested through the DoIP connection; if the response result is not received after the test message is sent to the vehicle to be tested for more than the preset waiting time, the response times out.

[0008] In one embodiment of the present application, comparing the response result corresponding to each test case with the expected result includes: if the response result and the expected result match or are the same, the test result of the test case is successful, and the test cases with successful test results are recorded in the successful result log; if the response result and the expected result do not match or are different, the test result of the test case is failed, and the test cases with failed test results are recorded in the failed result log.

[0009] In one embodiment of the present application, after comparing the response result corresponding to each test case with the expected result, it further includes: calculating the number of test cases in the successful result log to obtain the first number of cases, and calculating the number of test cases in the failed result log to obtain the second number of cases; obtaining the total number of cases according to the first number of cases and the second number of cases; obtaining the successful result percentage based on the first number of cases and the total number of cases, and obtaining the failed result percentage based on the second number of cases and the total number of cases; generating a visual pie chart according to the successful result percentage and the failed result percentage.

[0010] In one embodiment of the present application, after comparing the response result corresponding to each test case with the expected result, it further includes: generating a visual test case table according to the successful result log and the failed result log, and the visual test case table includes the test cases with successful test results and the test cases with failed test results; generating a visual test result table based on the first number of cases, the second number of cases, the total number of cases, the successful result percentage, and the failed result percentage.

[0011] In an embodiment of the present application, when each test case starts to execute, the current time is obtained as the start execution time, and when each test case ends execution, the current time is obtained as the end execution time; the total execution time is obtained according to the start execution time and the end execution time; a test time visualization table is generated based on the start execution time, the end execution time, and the total execution time.

[0012] An embodiment of the present application further provides a vehicle automated test device, an information input module, configured to obtain a data identifier of at least one target diagnostic parameter of a vehicle to be tested; a use case generation module, configured to obtain a test case corresponding to the target diagnostic parameter according to the data identifier, the test case including a test script and an expected result; a use case test module, configured to assemble a test message based on the test case, and send the test message to the vehicle to be tested for testing based on a vehicle diagnostic protocol, so as to obtain a response result corresponding to each test case; a result comparison module, configured to compare the response result corresponding to each test case with the expected result, and obtain a test result based on the comparison result.

[0013] An embodiment of the present application further provides an electronic device, the electronic device includes: one or more processors; a storage device, configured to store one or more programs, when the one or more programs are executed by the one or more processors, enabling the electronic device to implement the vehicle automated test method as described in any one of the above embodiments.

[0014] An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, when the computer program is executed by a processor of a computer, enabling the computer to execute the vehicle automated test method as described in any one of the above embodiments.

[0015] Advantages of the present application: Embodiments of the present application provide a vehicle automated test method, device, electronic device, and storage medium. The method includes obtaining a data identifier of at least one target diagnostic parameter of a vehicle to be tested; obtaining a test case corresponding to the target diagnostic parameter according to the data identifier, the test case including a test script and an expected result; assembling a test message based on the test case, and sending the test message to the vehicle to be tested for testing, so as to obtain a response result corresponding to each test case; comparing the response result corresponding to each test case with the expected result, and obtaining a test result based on the comparison result. By using this method for automated testing, it is not necessary to connect to test tools and packet capture tools such as Wireshark for testing, which greatly reduces the test cost. By extracting data from the diagnostic questionnaire and directly performing automated testing to obtain the test result, the work efficiency is improved.

[0016] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this application. Description of the Drawings

[0017] Figure 1 is a schematic diagram of the implementation environment of a vehicle automation test method shown in an exemplary embodiment of this application;

[0018] Figure 2 is a flowchart of a vehicle automation test method shown in an exemplary embodiment of this application;

[0019] Figure 3 is a schematic diagram of the test process shown in an exemplary embodiment of this application;

[0020] Figure 4 is a schematic diagram of the test result visualization process shown in an exemplary embodiment of this application;

[0021] Figure 5 is a block diagram of a vehicle automation test device shown in an exemplary embodiment of this application;

[0022] Figure 6 is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of this application. Detailed Embodiments

[0023] The following uses specific specific examples to illustrate the implementation manners of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific implementation manners. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other.

[0024] It should be noted that the drawings provided in the following embodiments only illustrate the basic concept of this application in a schematic manner. Therefore, only the components related to this application are shown in the drawings, rather than being drawn according to the number, shape, and size of the components in actual implementation. The types, quantities, and proportions of the components in actual implementation can be arbitrarily changed, and the component layout type may also be more complex.

[0025] It should be noted that in this application, "first", "second", etc. are only used to distinguish similar objects, and are not used to limit the order or sequence of similar objects. The described "including", "having", etc. are modified to indicate that the scope covered by the subject of this word is not exclusive in addition to the examples shown by this word.

[0026] It is understood that the various numerical numbers, step numbers, etc. recorded in this application are for the convenience of description and do not limit the scope of this application. The size of the labels in this application does not imply the order of execution. The execution order of each process should be determined by its function and internal logic.

[0027] In the following description, a large number of details are explored to provide a more thorough explanation of the embodiments of this application. However, it is obvious to those skilled in the art that the embodiments of this application can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of this application difficult to understand.

[0028] Embodiments of this application respectively propose a vehicle automation test method, a vehicle automation test device, an electronic device, a computer-readable storage medium, and a computer program product. The following will describe these embodiments in detail.

[0029] In this application, a Diagnostic Survey Form is a tool for collecting information related to vehicle faults or performance. It is usually filled out by technicians during fault diagnosis to record vehicle faults and other important parameters. The Diagnostic Survey Form in this application at least includes a DID number (data identifier) and an expected result. The Diagnostic Survey Form helps to systematically record all relevant information to ensure that no important details are missed; the Diagnostic Survey Form is usually in a table structure, and each row of the table at least includes a data identifier and its corresponding diagnostic parameter, a description of the diagnostic parameter, and an expected result (the default value under normal circumstances). Through structured information collection, the process of fault troubleshooting can be accelerated; it provides an effective communication tool between customers and technicians to ensure that both parties have the same understanding of the problem; it can be used as a reference document for subsequent repairs to facilitate later tracking and analysis.

[0030] In this application, DID, whose full name is Data Identifier, is a key concept in automotive diagnosis. It is used to identify and access specific parameter data in an electronic control unit (ECU), such as sensor data, status information, etc. Each DID corresponds to a specific data item of the vehicle. By reading these data items, technicians can accurately understand the status and performance of the vehicle. Through specific DIDs, diagnostic tools can accurately obtain the required data. This data can be various sensor readings, operating status information, fault codes, etc. of the vehicle. This data provides real-time feedback on the performance and status of the vehicle for technicians. Technicians can analyze the performance and status of the vehicle using the data obtained by DIDs to determine whether there are faults. For example, by reading data such as engine speed, vehicle speed, and oil temperature, technicians can conduct fault troubleshooting to find potential problems.

[0031] In this application, DoIP (Diagnostics over IP) is a diagnostic communication method based on IP (Internet Protocol) and is mainly used in the automotive industry. It allows vehicle diagnosis to be carried out through an Ethernet connection, replacing traditional diagnostic methods based on low-speed communications such as CAN (Controller Area Network) or K-Line.

[0032] In this application, a test case includes a test script and an expected result. The test script includes code for automatically executing the test case, which is used to implement the automatic execution of the test case, including automatically configuring the test environment, automatically sending test messages, and automatically receiving response results according to the test case. The test message is used to send a test request to the vehicle under test, trigger the function corresponding to the test case, and return the response result of the vehicle under test.

[0033] Please refer to Figure 1 , Figure 1 is a schematic diagram of the implementation environment of a vehicle automation test method shown in an exemplary embodiment of this application.

[0034] As Figure 1 shown, the implementation environment includes a computer device 101 and a vehicle under test 102, where the computer device 101 can be at least one of a microcomputer, an embedded computer, a neural network computer, etc. In this embodiment, the computer device 101 is connected to the ECU component of the vehicle under test 102, conducts batch testing by automatically traversing the diagnostic questionnaire, automatically analyzes the test results, and outputs intuitive test results. During the test, the printing of the log can also be stored in a txt file, and the test results and problem points can be known through a quick method.

[0035] Please refer to Figure 2 , Figure 2 which is a flowchart of a vehicle automated test method shown in an exemplary embodiment of the present application. This method can be applied to the Figure 1 shown implementation environment, and this method can also be applicable to other exemplary implementation environments and be specifically executed by devices in other implementation environments. This embodiment does not limit the implementation environment applicable to this method.

[0036] As Figure 2 shown, in an exemplary embodiment, the vehicle automated test method at least includes steps S210 to S240, which are introduced in detail as follows:

[0037] Step S210, obtain the data identifier of at least one target diagnostic parameter of the vehicle to be tested.

[0038] Exemplarily, obtain the data identifier of the target diagnostic parameter through a diagnostic questionnaire. The diagnostic questionnaire at least includes multiple diagnostic parameters and corresponding data identifiers, data types, ranges, units, etc., and extract the data identifier of the target diagnostic parameter in the diagnostic questionnaire. For example, if it is necessary to diagnose the operating state of the vehicle, the sensor parameters are used as the target diagnostic parameter and the corresponding data identifier is extracted. The sensor parameters include diagnostic parameters such as the engine speed, vehicle speed, and oil temperature. If it is necessary to diagnose the basic information of the vehicle, the vehicle information parameters are used as the target diagnostic parameter and the corresponding data identifier is extracted. The vehicle information parameters include the vehicle part number, ECU name (in-vehicle computer name), and version software number, etc. If it is necessary to diagnose the information related to the fault code of the vehicle, the fault code parameters are used as the target diagnostic parameter and the corresponding data identifier is extracted.

[0039] Exemplarily, extracting the data identifiers of multiple different diagnostic parameters based on the diagnostic questionnaire includes traversing the diagnostic questionnaire row by row and extracting the column where the data identifier is located in each row. In some embodiments, the diagnostic questionnaire is in a table structure, and each row of the table at least includes a data identifier and its corresponding diagnostic parameter, description of the diagnostic parameter, and expected result.

[0040] Exemplarily, during the process of extracting the data identifier, it is necessary to ensure the accuracy of the extracted data, including performing data compliance verification and removing duplicate values. For example, if the compliant data identifier is represented in hexadecimal, then the data identifier that does not conform to the compliant representation method after extraction needs to be converted or removed.

[0041] Step S220, obtain the test case corresponding to the target diagnostic parameter according to the data identifier. The test case includes a test script and an expected result.

[0042] Exemplarily, obtaining test cases corresponding to target diagnostic parameters according to data identifiers includes determining diagnostic parameters, parameter types, ranges, units, etc. corresponding to each data identifier, then writing one or more test scripts for each data identifier. The test scripts include setting up necessary test environments, sending test messages, and receiving response results, etc. According to the specifications and documents of the diagnostic system, defining corresponding expected results for each test case. The expected results include data accuracy and response timeliness of the response results (setting a preset response time) to facilitate one-by-one testing of the vehicle under test.

[0043] Step S230, assembling a test message based on the test case and sending the test message to the vehicle under test for testing based on the vehicle diagnostic protocol to obtain response results corresponding to each test case.

[0044] The vehicle diagnostic protocol refers to the communication protocol used to connect the diagnostic device and the electronic control unit (ECU) of the vehicle under test during the process of vehicle repair and diagnosis. These protocols ensure that the diagnostic device can perform data exchange and fault diagnosis with the vehicle.

[0045] Exemplarily, establishing a communication connection between the diagnostic device and the vehicle under test, sending the test message to the vehicle under test through the communication interface, and receiving response results corresponding to each test case after the vehicle under test receives the test message and conducts testing.

[0046] Exemplarily, if the test message is successfully processed, the ECU will return a positive response and relevant data as the response result. If the ECU cannot process the test message or encounters an error, it will return a negative response as the response result. For example, when testing vehicle information parameters, when the test message is successfully processed, the ECU will return a positive response and relevant data corresponding to the vehicle information parameters as the response result.

[0047] Step S240, comparing the response result corresponding to each test case with the expected result and obtaining a test result based on the comparison result.

[0048] Exemplarily, comparing the response result corresponding to each test case with the expected result to obtain the test result of each test case. The test result includes success or failure. If the response result and the expected result match, the test result of this test case is successful. If the response result and the expected result do not match, the test result of this test case is failure.

[0049] Exemplarily, if the response result is a negative response or the data returned by the response result does not match the expected result, the test result of the test case is failure. If the response result is a positive response and the data returned by the response result matches the expected result, the test result of the test case is successful.

[0050] The automated testing of the vehicle is achieved in the above - mentioned manner. By directly obtaining the diagnostic questionnaire and automatically testing each diagnostic parameter based on the data identifiers in the diagnostic questionnaire, it is not necessary to connect the test tool and the packet - capturing tool, which greatly reduces the testing cost. The test result is obtained by directly comparing the response result with the expected result, improving the work efficiency.

[0051] Please refer to Figure 3 , Figure 3 FIG. is a schematic diagram of the test process shown in an exemplary embodiment of the present application. In this embodiment, the test process includes: sequentially extracting DID information (data identifier) in the diagnostic questionnaire to establish a DoIP connection, sending a DoIP message (test message), receiving and parsing the DoIP message (response result), obtaining the test result of the test case, and outputting the test result.

[0052] Obtaining the data identifiers of at least one target diagnostic parameter of the vehicle to be tested includes: obtaining the diagnostic questionnaire and extracting the data identifiers of each diagnostic parameter in the diagnostic questionnaire; wherein, each diagnostic parameter at least includes sensor parameters for diagnosing the vehicle running state, vehicle information parameters for obtaining the basic information of the vehicle, and fault code parameters for reading and clearing the vehicle fault code.

[0053] In some embodiments of the present application, before traversing the diagnostic questionnaire, first detect the structure and content of the diagnostic questionnaire. Usually, the diagnostic questionnaire will contain multiple columns, such as diagnostic parameter name, data identifier, data type, range, and unit, etc. Select the corresponding traversal tool according to the storage format of the table (such as Excel). In this embodiment, the diagnostic questionnaire is stored in the form of an Excel table, so the openpyxl library of Python is used to traverse the diagnostic questionnaire. The openpyxl library of Python is a third - party library for processing Excel files, which is specifically used to read, write, and modify Excel files.

[0054] When traversing the diagnostic questionnaire, first filter the columns of the diagnostic questionnaire by column name or column index, locate the column where the data identifier is located, then traverse the data of each row, extract the data identifier of each row, and store the extracted data identifiers in an appropriate data structure (such as a list, dictionary, or database). In this embodiment, the extracted data identifiers are stored in a dictionary.

[0055] In some embodiments of the present application, some DID information in the diagnostic questionnaire is shown in Table 1:

[0056] Table 1

[0057]

[0058]

[0059] In Table 1, some information of the DID includes the serial number, the DID number (data identifier), and the description of the diagnostic parameter corresponding to each data identifier. For example, the diagnostic parameter corresponding to F187 is the part number, the diagnostic parameter corresponding to F18A is the supplier code, the diagnostic parameter corresponding to F197 is the ECU name (in-vehicle computer name), and the diagnostic parameter corresponding to 0216 is the software version number.

[0060] In some embodiments of the present application, extracting DID information includes defining a local empty dictionary type to store the information of the target diagnostic parameter in the diagnostic questionnaire. The information of the target diagnostic parameter includes at least the DID corresponding to the target diagnostic parameter. Format the DID in the dictionary into Hex strings of 22 frames and 2E frames, and store the dictionary containing the DID into a global list. Here, the global list refers to a list defined in the global scope and can be accessed by all functions or classes in the entire program.

[0061] Through the above method, extract the DID information in the diagnostic questionnaire and automatically generate test cases based on the data identifier, so that the test result can be directly obtained by importing the diagnostic questionnaire during the actual test process, improving the work efficiency of the test.

[0062] In some embodiments of the present application, obtaining the test case corresponding to the target diagnostic parameter according to the data identifier includes: if the target diagnostic parameter corresponding to the data identifier is the in-vehicle computer name parameter, the test case is to read the in-vehicle computer name of the vehicle to be tested, and the expected result is the preset expected name.

[0063] In some embodiments of the present application, sending the test message to the vehicle to be tested for testing includes: establishing a DoIP connection with the vehicle to be tested, and sending the test message to the vehicle to be tested through the DoIP connection; if the response result is not received after the test message is sent to the vehicle to be tested for more than the preset waiting time, the response times out.

[0064] In some embodiments of the present application, a DoIP connection can be established with the vehicle to be tested through the DoIPClient function. The DoIPClient function is a class used to implement communication between the diagnostic and the automotive electronic control unit (ECU) through the IP (DoIP) protocol and is a core component in the python library.

[0065] In some embodiments of the present application, the structure and content of the test message to be sent are determined according to each test case, and the test message corresponding to the test case is constructed according to the requirements of the DoIP diagnostic protocol, including filling in necessary fields such as service ID, data length, etc. Before sending the test message, the test message is verified to ensure that the format of the test message is correct and the data is error-free. Methods such as CRC (Cyclic Redundancy Check) can be used for verification.

[0066] In some embodiments of the present application, a communication connection is established with the vehicle under test based on DoIP, and the test message is sent to the vehicle under test through the communication interface. After the vehicle under test receives and executes the test message, the corresponding response result is received.

[0067] In some embodiments of the present application, after establishing the DoIP connection, route activation is performed through the request_activation function (routing activation function). A DoIP message is sent, and the timeout parameter is defined to specify the timeout time (in seconds) for waiting for the response. If a response DoIP message is received within the specified timeout time for waiting for the response, the response result of the DoIP message is read through the read_doip function (message reading function). Among them, the read_doip function (message reading function) is used to read diagnostic data from the vehicle through the DoIP protocol, and the request_activation function (routing activation function) is used to perform route activation in the DoIP connection.

[0068] By the above method, establishing a DoIP connection to perform automated testing does not require connecting to a test tool or other packet capture tools, which greatly reduces the testing cost.

[0069] In some embodiments of the present application, comparing the response result corresponding to each test case with the expected result includes: if the response result matches or is the same as the expected result, the test result of the test case is successful, and the test cases with successful test results are recorded in the successful result log;

[0070] If the response result does not match or is different from the expected result, the test result of the test is failed, and the test cases with failed test results are recorded in the failed result log.

[0071] Figure 4 It is a schematic diagram of the test result visualization process shown in an exemplary embodiment of the present application. As Figure 4 shown, by calculating the percentage of the number of successful and failed test cases, counting the execution time of each test case, gathering the test results of each test case together, and setting a pie chart to achieve the visualization of the test results.

[0072] After comparing the response results corresponding to each test case with the expected results, it further includes: obtaining a first case quantity based on the number of test cases recorded in the success result log, and obtaining a second case quantity based on the number of test cases recorded in the failure result log; obtaining the total case quantity according to the first case quantity and the second case quantity; obtaining a success result percentage based on the first case quantity and the total case quantity, and obtaining a failure result percentage based on the second case quantity and the total case quantity; generating a visual pie chart according to the success result percentage and the failure result percentage.

[0073] In some embodiments of the present application, through spreadsheet software (such as Excel), data visualization software (such as Tableau), or a graphics library in a programming language (such as Matplotlib in Python), set the pie chart data based on the success result percentage and the failure result percentage: configure the style of the pie chart as needed, including colors, labels, titles, etc. Ensure that each part of the pie chart clearly represents the success and failure results. Generate and save the visual pie chart, so as to analyze the success and failure ratios according to the visual pie chart. According to the analysis results, it may be necessary to further investigate the reasons for failure or optimize the test process.

[0074] In some embodiments of the present application, after comparing the response results corresponding to each test case with the expected results, it further includes: generating a test case visualization table according to the success result log and the failure result log, and the test case visualization table includes test cases with successful test results and test cases with failed test results; generating a test result visualization table based on the first case quantity, the second case quantity, the total case quantity, the success result percentage, and the failure result percentage.

[0075] In some embodiments of the present application, in the test case visualization table, the numbers of all test cases in the success result log and the failure result log are listed respectively, as shown in Table 2, and Table 2 is an exemplary test case visualization table:

[0076] Table 2

[0077]

[0078] In Table 2, an exemplary test case visualization table is shown, with the test cases with successful test results on the left and the test cases with failed test results on the right.

[0079] In some embodiments of the present application, in the test result visualization table, the first case quantity, the second case quantity, the total case quantity, the success result percentage, and the failure result percentage are listed, as shown in Table 3, and Table 3 is an exemplary test result visualization table:

[0080] Table 3

[0081] Number of successful test cases Percentage of successful test cases Number of failed test cases Percentage of failed test cases Total number of test cases 20 71％ 8 28％ 28

[0082] Table 3 shows an example of the visualization results of an automated test, in which the number of successful use cases is 20, accounting for 71% of the total, the number of failed use cases is 8, accounting for 28% of the total, and the total number of use cases is 28.

[0083] In some embodiments of the present application, the vehicle automation testing method also includes: when each test case starts to execute, the current time is obtained as the execution start time, and when each test case ends to execute, the current time is obtained as the execution end time; the total execution time is obtained according to the execution start time and the execution end time; and a test time visualization table is generated based on the execution start time, the execution end time and the total execution time.

[0084] In some embodiments of the present application, statistics on the execution time of each test case include obtaining the current time of the system at the start execution node of each test case as the execution start time, and obtaining the current time of the system at the end execution node as the execution end time, thereby obtaining the execution start time, execution end time and total execution time, and visualizing the test case time through HTML, including filling in a table header and data, the table header including the execution start time, execution end time and total execution time.

[0085] In some embodiments of the present application, a test time visualization table of a test case is shown in Table 4:

[0086] Table 4

[0087] Start time of execution End time of execution Total execution time 2024-10-2016:29:14.106702 2024-10-2016:29:14.107203 0:00:00.000501

[0088] Table 4 shows an example of the visualization result of an automated test, where the execution start time, execution end time and total execution time are all shown in Table 4, so that the tester can intuitively view the test time.

[0089] By converting the test results into a visual pie chart or a visual table in the above manner, the test results can be viewed directly and clearly. At the same time, the test results are recorded in the success result log and the failure result log, which is convenient for locating the problematic test cases in subsequent analysis.

[0090] See also Figure 5 , Figure 5 is a block diagram of a vehicle automated testing device shown in an exemplary embodiment of the present application. The device can be applied to Figure 1 The implementation environment shown is as follows. The device may also be applicable to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0091] As Figure 5 shown, the exemplary vehicle automated test device includes: an information input module 501, a test case generation module 502, a test case testing module 503, and a result comparison module 504.

[0092] The information input module 501 is configured to obtain a diagnostic questionnaire, and the diagnostic questionnaire carries data identifiers corresponding to respective diagnostic parameters of the vehicle;

[0093] The test case generation module 502 is configured to generate test cases corresponding to each diagnostic parameter according to the data identifiers, and the test cases include test scripts and expected results;

[0094] The test case testing module 503 is configured to assemble the test cases into test messages, and send the test messages to the vehicle to be tested for testing based on the vehicle diagnostic protocol, so as to obtain response results corresponding to each test case;

[0095] The result comparison module 504 is configured to compare the response results corresponding to each test case with the expected results, and obtain test results based on the comparison results.

[0096] For specific limitations on the vehicle automated test device, reference may be made to the limitations on the vehicle automated test method in the foregoing text, which will not be elaborated herein. Each module in the foregoing vehicle automated test device can be implemented in whole or in part by software, hardware, and their combination. The foregoing modules can be embedded in or independent of a processor in an electronic device in the form of hardware, or stored in a memory in the electronic device in the form of software, so as to facilitate the processor to call and execute operations corresponding to the foregoing modules.

[0097] In this embodiment, the vehicle automated test device essentially sets multiple modules to execute the vehicle automated test method in any of the foregoing embodiments. For specific functions and technical effects, reference may be made to the foregoing embodiments, which will not be elaborated herein.

[0098] Figure 6 shows a schematic structural diagram of a computer system of an electronic device suitable for implementing an embodiment of the present application. It should be noted that, Figure 6 the shown computer system 600 of the electronic device is only an example, and should not bring any limitation to the functions and usage scopes of the embodiments of the present application.

[0099] As Figure 6As shown, computer system 600 includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes according to programs stored in a Read-Only Memory (ROM) 602 or programs loaded from a storage section 608 into a Random Access Memory (RAM) 603, such as executing the methods described in the above embodiments. In the RAM 603, various programs and data required for system operations are also stored. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An Input / Output (I / O) interface 605 is also connected to the bus 604.

[0100] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including, for example, a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc. and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed so that a computer program read from it can be installed into the storage section 608 as needed.

[0101] Specifically, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by a Central Processing Unit (CPU) 601, various functions defined in the system of the present application are executed.

[0102] It should be noted that the computer-readable medium shown in the embodiments of the present application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable computer program. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted by any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. Among them, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the above module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order from that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0104] The units involved in the embodiments described in this application can be implemented in software or in hardware, and the described units can also be provided in a processor. Among them, the names of these units do not, in some cases, constitute a limitation on the units themselves.

[0105] Another aspect of this application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor of a computer, the computer is caused to execute the vehicle automation test method as described above. The computer-readable storage medium can be included in the electronic device described in the above embodiments, or can exist alone without being assembled into the electronic device.

[0106] Another aspect of this application also provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the vehicle automation test method provided in the above various embodiments.

[0107] The above embodiments are only used to exemplarily illustrate the principles and effects of this application, rather than to limit this application. Any person familiar with this technology can modify or change the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or changes completed by those with ordinary knowledge in the technical field without departing from the spirit and technical ideas disclosed in this application should still be covered by the claims of this application.

Claims

1. A vehicle automated testing method, characterized in that: The vehicle automation testing method comprises: Obtaining a data identifier of at least one target diagnostic parameter of the vehicle to be tested; Obtaining a test case corresponding to the target diagnostic parameter according to the data identifier, wherein the test case includes a test script and an expected result; Assembling a test message based on the test case, and sending the test message to the vehicle to be tested for testing based on the vehicle diagnostic protocol to obtain a response result corresponding to each test case; The response result corresponding to each test case is compared with the expected result, and the test result is obtained based on the comparison result.

2. The vehicle automated testing method according to claim 1, characterized in that: Acquiring a data identifier of at least one target diagnostic parameter of the vehicle to be tested includes: Obtain a diagnostic questionnaire and extract a data identifier for each target diagnostic parameter in the diagnostic questionnaire; wherein each diagnostic parameter includes at least a sensor parameter for diagnosing a vehicle operating state, a vehicle information parameter for obtaining basic vehicle information, and a fault code parameter for reading and clearing a vehicle fault code.

3. The vehicle automated testing method according to claim 1, characterized in that: Sending the test message to the vehicle to be tested for testing includes: Establishing a DoIP connection with the vehicle to be tested, and sending the test message to the vehicle to be tested through the DoIP connection; If the test message is sent to the vehicle to be tested for more than a preset waiting time and the response result is not received, the response times out.

4. The vehicle automated testing method according to any one of claims 1 to 3, characterized in that: Comparing the response results and expected results corresponding to each test case includes: If the response result is consistent with or the same as the expected result, the test result of the test case is successful, and the test case with a successful test result is recorded in the success result log; If the response result does not match or is different from the expected result, the test result of the test is failure, and the test case with the failed test result is recorded in the failure result log.

5. The vehicle automated testing method according to claim 4, characterized in that: After comparing the response results of each test case with the expected results, it also includes: Calculate the number of test cases in the success result log to obtain the first number of test cases, and calculate the number of test cases in the failure result log to obtain the second number of test cases; Obtaining a total number of use cases according to the number of the first use cases and the number of the second use cases; Obtain a percentage of successful results based on the first number of use cases and the total number of use cases, and obtain a percentage of failed results based on the second number of use cases and the total number of use cases; A visual pie chart is generated according to the success result percentage and the failure result percentage.

6. The vehicle automated testing method according to claim 5, characterized in that: After comparing the response results of each test case with the expected results, it also includes: Generate a test case visualization table according to the success result log and the failure result log, wherein the test case visualization table includes test cases with successful test results and test cases with failed test results; A test result visualization table is generated based on the first number of use cases, the second number of use cases, the total number of use cases, the percentage of successful results, and the percentage of failed results.

7. The vehicle automated testing method according to any one of claims 1 to 3, characterized in that: The vehicle automation testing method further comprises: When each test case starts executing, the current time is obtained as the execution start time, and when each test case ends executing, the current time is obtained as the execution end time; Obtaining the total execution time according to the execution start time and the execution end time; A test time visualization table is generated based on the execution start time, the execution end time and the total execution time.

8. A vehicle automated testing device, characterized in that: The vehicle automation test device comprises: An information input module, used to obtain a data identifier of at least one target diagnostic parameter of the vehicle to be tested; A test case generation module, used to obtain a test case corresponding to the target diagnostic parameter according to the data identifier, wherein the test case includes a test script and an expected result; A case test module, used to assemble a test message based on the test case, and send the test message to the vehicle to be tested for testing based on the vehicle diagnostic protocol to obtain a response result corresponding to each test case; The result comparison module is used to compare the response result corresponding to each test case with the expected result, and obtain the test result based on the comparison result.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; A storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, enables the electronic device to implement the vehicle automation testing method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor of a computer, the computer is enabled to execute the vehicle automation testing method as described in any one of claims 1 to 7.

Images