Testing method, system and equipment for interface-free application of vehicle-mounted infotainment system and medium

Abstract

The invention relates to the field of in-vehicle infotainment testing, in particular to a testing method, system and device for interface-free application of an in-vehicle infotainment system and a medium. Based on a runtime metadata analysis method, modifying the expected execution interface to enable the expected execution interface to output log information in a predetermined format when the expected execution interface is executed; executing the test case to be executed; acquiring real-time log information of executing the to-be-executed test case by the vehicle machine system; analyzing the real-time log information to obtain second interface information; and judging a test result of the test case to be executed according to the first interface information and the second interface information. According to the invention, the flexibility and portability of the test are improved; besides, according to the test method, the execution result of the test case can be automatically judged, the workload of manual observation and analysis is reduced, and the test efficiency is further improved.

Description

Technical Field

[0001] The present invention relates to the field of vehicle computer testing, and in particular to a method, system, equipment and medium for testing a non-interface application of a vehicle computer system. Background Art

[0002] With the development of automobile intelligence, the in-vehicle system has become a standard configuration of modern cars. The in-vehicle system not only provides functions such as navigation and entertainment, but also supports various interface-free applications, such as vehicle status monitoring and fault diagnosis. These interface-free applications do not have a graphical user interface and mainly run in the background and interact with various components of the vehicle. For example, the fault diagnosis application can collect the sensor data of the vehicle in real time to analyze whether there is a fault; the vehicle status monitoring application can record the operating parameters of the vehicle, such as speed, fuel consumption, etc. These interface-free applications are crucial to improving the safety, reliability and user experience of the vehicle, so comprehensive and efficient testing of them is an indispensable part of the development of the in-vehicle system.

[0003] Currently, the interfaceless applications of the vehicle system usually work in conjunction with other business applications, so their testing also needs to be coordinated with these applications. A common testing method is to run the interfaceless application to be tested and related business applications at the same time in a real vehicle environment, and observe their interaction process and results. However, this method requires the construction of a test environment that includes the vehicle system and various business applications. The preparation of the test environment is very complicated, the test efficiency is low, and because the interfaceless application lacks a user interface, its operating status and internal logic are difficult to observe, and the test coverage is limited. Summary of the invention

[0004] In order to solve the above problems, the present invention provides a method, system, device and medium for testing interface-free applications of a vehicle system.

[0005] A first aspect of the present invention discloses a method for testing a non-interface application of a vehicle system, comprising:

[0006] Receive test case data; wherein the test case data includes a test case to be executed and its corresponding first interface information; wherein the first interface information includes an interface identifier of an expected execution interface corresponding to the test case to be executed;

[0007] Based on the runtime metadata parsing method, modify the expected execution interface so that it outputs log information in a predetermined format when executed;

[0008] Execute the test case to be executed;

[0009] Obtaining real-time log information of the vehicle system executing the test case to be executed;

[0010] Parse the real-time log information to obtain the second interface information;

[0011] Judge the test result of the to-be-executed test case according to the first interface information and the second interface information.

[0012] Further, the step of parsing the real-time log information to obtain the second interface information includes:

[0013] Parse the real-time log information according to the predetermined format to obtain the interface identifier of the actually executed interface;

[0014] Generate the second interface information according to the interface identifier of the actually executed interface.

[0015] Further, the step of judging the test result of the to-be-executed test case according to the first interface information and the second interface information includes:

[0016] Judge whether the expected execution interface in the first interface information matches the actually executed interface in the second interface information:

[0017] When the result is yes, the to-be-executed test case passes the test;

[0018] When the result is no, the to-be-executed test case fails the test.

[0019] Further, the first interface information includes the interface identifiers of multiple expected execution interfaces and is sorted according to the expected execution order;

[0020] And, the step of judging the test result of the to-be-executed test case according to the first interface information and the second interface information includes:

[0021] Judge whether the interface identifier in the first interface information belongs to the interface identifier in the second interface information and the sorting orders corresponding to the interface identifiers are the same;

[0022] When the result is yes, the to-be-executed test case passes the test;

[0023] When the result is no, the to-be-executed test case fails the test.

[0024] Further, the step of judging the test result of the to-be-executed test case according to the first interface information and the second interface information includes:

[0025] According to the configuration file, read the to-be-executed test case matching the interface identifier of the actually executed interface to obtain the expected test case;

[0026] Determine whether the interface identifier in the first interface information belongs to the interface identifier in the second interface information, and whether the expected test case is the same as the test case to be executed;

[0027] When the results are both yes, the test case to be executed passes the test;

[0028] Otherwise, the test case to be executed fails the test.

[0029] Further, when in the configuration file, the interface identifier of an actually executed interface matches multiple test cases to be executed, the steps of reading the test cases to be executed matched by the interface identifier of the actually executed interface to obtain the expected test case include:

[0030] Read the log time of this actually executed interface from the real-time log information;

[0031] Read multiple test cases to be executed matched by the interface identifier of this actually executed interface according to the configuration file;

[0032] Obtain the test case execution time of multiple test cases to be executed matched by this actually executed interface;

[0033] Determine the expected test case corresponding to the interface identifier of this actually executed interface according to the log time and the test case execution time.

[0034] Further, when in the configuration file, the interface identifier of an actually executed interface matches multiple test cases to be executed, the steps of reading the test cases to be executed matched by the interface identifier of the actually executed interface to obtain the expected test case include:

[0035] Read multiple test cases to be executed matched by the interface identifier of this actually executed interface according to the configuration file;

[0036] Calculate the similarity between the first interface information corresponding to multiple test cases to be executed matched by this actually executed interface and the second interface information respectively, and determine the expected test case corresponding to the interface identifier of this actually executed interface according to the similarity.

[0037] The second aspect of the present invention discloses a test system for a car infotainment system's interface-free application, including:

[0038] A receiving module, configured to receive test case data; wherein, the test case data includes the test case to be executed and its corresponding first interface information; wherein, the first interface information includes the interface identifier of the expected execution interface corresponding to the test case to be executed;

[0039] A modification module, configured to modify the expected execution interface based on a runtime metadata parsing method, so that when it is executed, it outputs log information in a predetermined format;

[0040] An execution module, configured to execute the to-be-executed test case;

[0041] An acquisition module, configured to acquire real-time log information of the in-vehicle system executing the to-be-executed test case;

[0042] A parsing module, configured to parse the real-time log information to obtain second interface information;

[0043] A judgment module, configured to judge the test result of the to-be-executed test case according to the first interface information and the second interface information.

[0044] A third aspect of the present invention discloses an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The feature is that when the processor executes the computer program, it implements the steps of any one of the test methods for the interfaceless application of the in-vehicle system disclosed in the first aspect of the present invention.

[0045] A fourth aspect of the present invention discloses a storage medium, which stores a computer program. The feature is that when the computer program is executed by a processor, it implements the steps of any one of the test methods for the interfaceless application of the in-vehicle system disclosed in the first aspect of the present invention.

[0046] By introducing test cases and interface information, the present invention makes the test of the interfaceless application independent of the specific in-vehicle environment and business applications, improving the flexibility and portability of the test; at the same time, by modifying the interface to output logs in a predetermined format and collecting and analyzing these logs in real time, the running process of the interfaceless application can be clearly observed, expanding the test coverage. In addition, the test method of the present application can automatically judge the execution result of the test case, reducing the workload of manual observation and analysis and further improving the test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0048] Figure 1 It is a schematic flowchart of a test method for an interfaceless application of an in-vehicle system disclosed in an embodiment of the present invention;

[0049] Figure 2It is a schematic structural diagram of a test system for a head unit system's interface-less application disclosed in an embodiment of the present invention;

[0050] Figure 3 It is a schematic structural diagram of an electronic device disclosed in an embodiment of the present invention. Detailed implementation manners

[0051] To enable those skilled in the art to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0052] The terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, device, or product end that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, devices, or product ends.

[0053] Referring to "embodiment" herein means that a specific feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0054] Please refer to Figure 1 as shown in Figure 1 It is a schematic flowchart of a test method for a head unit system's interface-less application disclosed in an embodiment of the present invention, including the following operations:

[0055] S101. Receive test case data; wherein, the test case data includes the test case to be executed and its corresponding first interface information; wherein, the first interface information includes the interface identifier of the expected execution interface corresponding to the test case to be executed;

[0056] In this optional embodiment, the test case to be executed refers to a complete test scenario, which includes a series of test steps and expected results. It defines the operation sequence that the in-vehicle system should execute and the expected response under specific conditions. Each test case to be executed has a unique identifier for distinguishing different test scenarios.

[0057] The expected execution interface refers to the in-vehicle system interfaces that are expected to be called or triggered during the execution of the test case. These interfaces can be APIs, functions, methods, or other callable program units provided by the in-vehicle system. Each expected execution interface also has a unique interface identifier for precisely specifying a particular interface.

[0058] A complete test case usually includes multiple test steps, and each test step may involve the invocation of one or more expected execution interfaces. The test case defines a complete test process, and the expected execution interface is a key node or step in this process. By checking whether the actually called interfaces during the execution of the test case match the expected execution interfaces, it can be determined whether the execution result of the test case meets the expectations.

[0059] S102. Based on the runtime metadata parsing method, modify the expected execution interface so that it outputs log information in a predetermined format when it is executed;

[0060] In this optional embodiment, the runtime metadata parsing method is a method for dynamically analyzing or modifying the descriptive information of the code structure during program execution. For example, the reflection mechanisms in Java and C# dynamically call interfaces by reading metadata such as class names and method parameters, and the introspection mechanism in Python achieves dynamic inspection by parsing metadata such as function attributes. Metadata is data that describes program elements (such as classes, methods, functions, variables, etc.), including their names, types, attributes, parameters, etc.

[0061] This optional embodiment can dynamically implant the log output logic without modifying the source code, thereby capturing the actual call traces of the interfaces for subsequent verification of whether the execution path of the test case meets the expectations.

[0062] S103. Execute the test case to be executed;

[0063] In this optional embodiment, executing the test case to be executed means actually running the test case on the in-vehicle system according to the test steps and input data defined in the test case to be executed.

[0064] S104. Obtain the real-time log information of the in-vehicle system executing the test case to be executed;

[0065] In this optional embodiment, the runtime metadata parsing method modifies the expected execution interface so that it can output log information in a predetermined format when called. These log information usually include the call time of the interface, input parameters, return values, execution status, etc., and can reflect the actual behavior and status of the in-vehicle system during the execution of test cases.

[0066] After obtaining the real-time log information, it can be stored in the memory cache or persistent storage, and preprocessing operations such as filtering, conversion, and aggregation can also be performed on the original log information to extract the key data required for test analysis.

[0067] S105. Parse the real-time log information to obtain the second interface information;

[0068] In this optional embodiment, parsing the real-time log information means parsing according to the format and organization of the log using the corresponding parsing algorithm. For example: if the log information has a fixed format and pattern, regular expressions can be used to match and extract the key field values; if the log information is organized in a structured format (such as JSON, XML, etc.), the corresponding parsing libraries (such as json library, xml library, etc.) can be used to parse the log information into structured data objects and extract the specified field values.

[0069] In an optional embodiment, the steps of parsing the real-time log information to obtain the second interface information include:

[0070] Parse the real-time log information according to the predetermined format to obtain the interface identifier of the actual execution interface;

[0071] Generate the second interface information according to the interface identifier of the actual execution interface.

[0072] In this optional embodiment, the predetermined format refers to the fixed output format and pattern of the log information. This format usually contains key fields such as interface identifier, call time, input parameters, return values, etc., and is organized and separated in a specific way. Regular expressions, string splitting, etc. can be used to extract the interface identifier of the actual execution interface from the real-time log information according to the predetermined format.

[0073] It can be seen that this optional embodiment establishes a mapping relationship between the test case and the actual execution result through the parsing and transformation of the real-time log information, which can significantly improve the accuracy, reliability, and automation degree of the test.

[0074] S106. Judge the test result of the to-be-executed test case according to the first interface information and the second interface information.

[0075] In an alternative embodiment, the step of determining the test result of the to-be-executed test case according to the first interface information and the second interface information includes:

[0076] Determine whether the expected execution interface in the first interface information matches the actual execution interface in the second interface information:

[0077] When the result is yes, the to-be-executed test case passes the test;

[0078] When the result is no, the to-be-executed test case fails the test.

[0079] In this alternative embodiment, the fact that the expected execution interface in the first interface information matches the actual execution interface in the second interface means that the interface identifier of each expected execution interface in the first interface information is the same as the interface identifier of an actual execution interface in the second interface information. For example: The first interface information includes the interface identifiers of three expected execution interfaces, namely startNavigation, getRoute, and playVoice, and the second interface information includes the interface identifiers of four actual execution interfaces, namely playVoice, startNavigation, getRoute, and printLog. Then, the expected execution interface in the first interface information matches the actual execution interface in the second interface information.

[0080] It can be seen that by introducing an automated test mechanism based on interface matching, this alternative embodiment can not only effectively evaluate the execution result of the test case, ensure the quality and stability of the in-vehicle system's non-graphical application, but also optimize the test process, reduce the test cost, improve the work efficiency and quality of the test team, and has a positive promoting effect on the overall improvement of software development and testing work.

[0081] In another alternative embodiment, the first interface information includes the interface identifiers of multiple expected execution interfaces and is sorted according to the expected execution order;

[0082] And, the step of determining the test result of the to-be-executed test case according to the first interface information and the second interface information includes:

[0083] Determine whether the interface identifier in the first interface information belongs to the interface identifiers in the second interface information and the sorting order corresponding to the interface identifier is the same;

[0084] When the result is yes, the to-be-executed test case passes the test;

[0085] When the result is no, the to-be-executed test case fails the test.

[0086] In this alternative embodiment, the first interface information not only includes the interface identifiers of multiple expected execution interfaces, but also defines the expected execution order of these interface identifiers. Correspondingly, when judging the test result, not only the matching situation between the expected execution interface and the actual execution interface needs to be compared, but also whether the actual execution order is consistent with the expected execution order needs to be verified. For example: The interface identifiers of three expected execution interfaces in the first interface information are startNavigation, getRoute, and playVoice respectively, and the interface identifiers of four actual execution interfaces in the second interface information are playVoice, startNavigation, getRoute, and printLog respectively. Although the interface identifier of each expected execution interface in the first interface information is the same as the interface identifier of an actual execution interface in the second interface information, since the execution order does not meet the expectation, the test case to be executed fails the test.

[0087] It can be seen that by introducing the check of the interface execution order, this embodiment further enhances the rigor and accuracy of the test, and can discover more defects and anomalies related to the interface call timing; at the same time, it also improves the design quality and maintainability of the test cases, ultimately significantly improving the test efficiency, shortening the test cycle, and verifying the functions and performance of the system from a higher level, ensuring the quality and reliability of the in-vehicle system's interface-less applications.

[0088] In another alternative embodiment, the steps of judging the test result of the test case to be executed according to the first interface information and the second interface information include:

[0089] Read the test case to be executed that matches the interface identifier of the actual execution interface according to the configuration file to obtain the expected test case;

[0090] Judge whether the interface identifier in the first interface information belongs to the interface identifier in the second interface information, and whether the expected test case is the same as the test case to be executed;

[0091] When the results are all yes, the test case to be executed passes the test;

[0092] Otherwise, the test case to be executed fails the test.

[0093] It can be seen that by introducing the comparison between the configuration file and the expected test cases, this embodiment allows the tester to dynamically associate the interface identifier with the test case to be executed through the configuration file. By comparing the expected test case with the actually executed test case, the correctness and consistency of the test execution can be further verified, which not only improves the maintainability and scalability of the test, but also enhances the flexibility and adaptability of the test, so that the test framework can better cope with the systems under test of different versions and configurations, thereby improving the test efficiency and ensuring the quality and reliability of the interface-free application of the vehicle system.

[0094] In a further optional embodiment, when an interface identifier of an actual execution interface matches multiple test cases to be executed in the configuration file, the step of reading the test cases to be executed that match the interface identifier of the actual execution interface to obtain the expected test cases includes:

[0095] Reading the log time of the actual execution interface from the real-time log information;

[0096] According to the configuration file, multiple test cases to be executed that match the interface identifier of the actual execution interface are read;

[0097] Obtain the test case execution time of multiple test cases to be executed that match the actual execution interface;

[0098] According to the log time and the test case execution time, the expected test case corresponding to the interface identifier of the actual execution interface is determined.

[0099] In this optional embodiment, the same interface may be covered and verified by multiple test cases. For example, a login interface may be tested by multiple test cases such as user login, administrator login, and login failure. In this case, it is impossible to determine the specific test case corresponding to the actual execution interface by matching only based on the interface identifier. This optional embodiment can find the test case closest to the execution time of the actual execution interface by comparing the log time of the actual execution interface and the test case execution time of multiple matching test cases to be executed, thereby determining the only expected test case.

[0100] It can be seen that this optional implementation scheme improves the accuracy and reliability of the test by introducing an execution time matching mechanism; at the same time, this dynamic matching method also enables the test framework to adapt to more complex and flexible test scenarios, reduces the constraints and restrictions on test case design, and allows testers to design and organize test cases more freely, thereby improving the flexibility and maintainability of the test.

[0101] In a further optional embodiment, when in a configuration file, the interface identifier of an actual execution interface matches multiple test cases to be executed, the steps of reading the test cases to be executed that match the interface identifier of the actual execution interface to obtain the expected test cases include:

[0102] According to the configuration file, read multiple test cases to be executed that match the interface identifier of the actual execution interface;

[0103] Calculate the similarity between the first interface information corresponding to the multiple test cases to be executed matched by the actual execution interface and the second interface information respectively, and determine the expected test case corresponding to the interface identifier of the actual execution interface according to the similarity.

[0104] In this optional embodiment, when the interface identifier of an actual execution interface matches multiple test cases to be executed, by calculating the similarity between the first interface information corresponding to all test cases to be executed and the second interface information, select the test case with the highest similarity as the expected test case corresponding to the actual execution interface. In this optional embodiment, the Jaccard similarity coefficient between the first interface information corresponding to the multiple test cases to be executed matched by the actual execution interface and the second interface information can be calculated as the similarity.

[0105] It can be seen that this optional embodiment not only considers the matching situation of the interface identifier, but also comprehensively evaluates the overall similarity between the test case and the actual execution situation. This comprehensive consideration can improve the accuracy and reliability of the matching, thereby improving the pertinence and effectiveness of the test. In addition, by analyzing the results of the similarity calculation, testers can also evaluate the rationality and completeness of the test case design, identify potential improvement points and optimization spaces, and promote the continuous improvement and optimization of the test plan.

[0106] Please refer to Figure 2 as shown Figure 2 is a schematic structural diagram of a test system for a head unit system's interface-free application disclosed in an embodiment of the present invention, including:

[0107] A receiving module 201, configured to receive test case data; wherein, the test case data includes test cases to be executed and their corresponding first interface information; wherein, the first interface information includes the interface identifier of the expected execution interface corresponding to the test case to be executed;

[0108] A modification module 202, configured to modify the expected execution interface based on a runtime metadata parsing method so that it outputs log information in a predetermined format when executed;

[0109] An execution module 203, configured to execute the test cases to be executed;

[0110] An acquisition module 204, configured to acquire real-time log information of the in-vehicle system executing the to-be-executed test case;

[0111] An analysis module 205, configured to analyze the real-time log information to obtain second interface information;

[0112] A judgment module 206, configured to judge the test result of the to-be-executed test case according to the first interface information and the second interface information.

[0113] For the specific limitations of the test system for the interface-less application of the in-vehicle system, reference may be made to the limitations of the test method for the interface-less application of the in-vehicle system in the foregoing text, which will not be elaborated herein. Each module in the above test system for the interface-less application of the in-vehicle system may be implemented in whole or in part by software, hardware, and their combination. The above modules may be embedded in the processor in the electronic device in a hardware format or independent of the processor, or may be stored in the memory in the electronic device in a software format, so as to facilitate the processor to call the corresponding operations of the above modules.

[0114] It should be noted that, in order to highlight the innovative part of the present invention, modules that are not closely related to solving the technical problems proposed by the present invention are not introduced in this embodiment, but this does not mean that there are no other modules in this embodiment.

[0115] As Figure 3 shown, the electronic device 1 provided by the present invention may include a memory 11, a processor 12, and a bus, and may further include a computer program stored in the memory 11 and executable on the processor 12, such as a test program for the interface-less application of the in-vehicle system.

[0116] Among them, the memory 11 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, mobile hard disk, multimedia card, card-type memory (such as: SD or DX memory, etc.), magnetic memory, magnetic disk, optical disk, etc. The memory 11 may be an internal storage unit of the electronic device 1 in some embodiments, such as the mobile hard disk of the electronic device 1. The memory 11 may also be an external storage device of the electronic device 1 in other embodiments, such as a plug-in mobile hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the electronic device 1. Further, the memory 11 may include both the internal storage unit and the external storage device of the electronic device 1. The memory 11 can not only be used to store application software installed in the electronic device 1 and various types of data, such as the code for testing the interface-less application of the in-vehicle system, but also be used to temporarily store data that has been output or will be output.

[0117] In some embodiments, the processor 12 may be composed of an integrated circuit. For example, it may be composed of a single packaged integrated circuit, or may be composed of multiple packaged integrated circuits with the same or different functions, including a combination of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor 12 is the control core of the electronic device 1, connecting various components of the entire electronic device 1 through various interfaces and circuits. By running or executing programs or modules stored in the memory 11 (such as the test program of the head unit system's interfaceless application, etc.), and by calling the data stored in the memory 11, it performs various functions of the electronic device 1 and processes data.

[0118] The processor 12 executes the operating system of the electronic device 1 and various installed application programs. The processor 12 executes the application programs to implement the steps in the above-mentioned test method for the head unit system's interfaceless application.

[0119] Exemplarily, the computer program may be divided into one or more modules, and the one or more modules are stored in the memory 11 and executed by the processor 12 to complete this application. The one or more modules may be a series of computer program instruction segments capable of completing specific functions, and these instruction segments are used to describe the execution process of the computer program in the electronic device 1. For example, the computer program may be divided into a receiving module 201, a modifying module 202, an executing module 203, an obtaining module 204, a parsing module 205, and a judging module 206.

[0120] The above-mentioned integrated unit implemented in the form of software function modules may be stored in a computer-readable storage medium, and the storage medium may be non-volatile or volatile. The above-mentioned software function modules are stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a computer device, or a network device, etc.) or a processor to execute part of the functions of the test method for the head unit system's interfaceless application in various embodiments of this application.

[0121] In summary, a test method, system, device, and medium for a head unit system's interface-less application disclosed by the present invention introduce test cases and interface information, making the testing of the interface-less application independent of the specific head unit environment and business applications, thus improving the flexibility and portability of testing. At the same time, by modifying the interface to output logs in a predetermined format and collecting and analyzing these logs in real time, the running process of the interface-less application can be clearly observed, expanding the test coverage. In addition, the test method of the present application can automatically judge the execution results of test cases, reducing the workload of manual observation and analysis and further improving the test efficiency. Therefore, the present invention effectively overcomes various drawbacks in the prior art and has high industrial utilization value.

[0122] The above embodiments are only used to exemplarily illustrate the principles and effects of the present invention, rather than to limit the present invention. Any person familiar with this technology can modify or change the above embodiments without departing from the spirit and scope of the present invention. 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 by the present invention should still be covered by the claims of the present invention.

Claims

1. A method for testing a non-interface application of a vehicle system, characterized in that: The method comprises: Receive test case data; wherein the test case data includes a test case to be executed and its corresponding first interface information; wherein the first interface information includes an interface identifier of an expected execution interface corresponding to the test case to be executed; Based on the runtime metadata parsing method, modify the expected execution interface so that it outputs log information in a predetermined format when executed; Execute the test case to be executed; Obtaining real-time log information of the vehicle system executing the test case to be executed; Parsing the real-time log information to obtain second interface information; The test result of the test case to be executed is determined according to the first interface information and the second interface information.

2. The method for testing a non-interface application of a vehicle system according to claim 1, characterized in that: The step of parsing the real-time log information to obtain the second interface information includes: Parsing the real-time log information according to the predetermined format to obtain an interface identifier of an actual execution interface; The second interface information is generated according to the interface identifier of the actual execution interface.

3. The method for testing a non-interface application of a vehicle system according to claim 2, characterized in that: The step of determining the test result of the test case to be executed according to the first interface information and the second interface information includes: Determine whether the expected execution interface in the first interface information matches the actual execution interface in the second interface information: When the result is yes, the test case to be executed passes; When the result is no, the test case to be executed fails.

4. The method for testing a non-interface application of a vehicle system according to claim 3, characterized in that: The first interface information includes interface identifiers of multiple expected execution interfaces, and is sorted in the expected execution order; And, the step of determining the test result of the test case to be executed according to the first interface information and the second interface information includes: Determine whether the interface identifier in the first interface information belongs to the interface identifier in the second interface information, and the sorting order corresponding to the interface identifiers is the same; When the result is yes, the test case to be executed passes; When the result is no, the test case to be executed fails.

5. The method for testing a non-interface application of a vehicle system according to claim 3, characterized in that: The step of determining the test result of the test case to be executed according to the first interface information and the second interface information includes: According to the configuration file, read the test case to be executed that matches the interface identifier of the actual execution interface to obtain the expected test case; Determine whether the interface identifier in the first interface information belongs to the interface identifier in the second interface information, and whether the expected test case is the same as the test case to be executed; When the results are all yes, the test case to be executed passes the test; Otherwise, the test case to be executed fails.

6. The method for testing a non-interface application of a vehicle system according to claim 5, characterized in that: When an interface identifier of an actual execution interface matches multiple test cases to be executed in the configuration file, the step of reading the test cases to be executed that match the interface identifier of the actual execution interface to obtain the expected test cases includes: Reading the log time of the actual execution interface from the real-time log information; According to the configuration file, multiple test cases to be executed that match the interface identifier of the actual execution interface are read; Obtain the test case execution time of multiple test cases to be executed that match the actual execution interface; According to the log time and the test case execution time, the expected test case corresponding to the interface identifier of the actual execution interface is determined.

7. The method for testing a non-interface application of a vehicle system according to claim 5, characterized in that: When an interface identifier of an actual execution interface matches multiple test cases to be executed in the configuration file, the step of reading the test cases to be executed that match the interface identifier of the actual execution interface to obtain the expected test cases includes: According to the configuration file, multiple test cases to be executed that match the interface identifier of the actual execution interface are read; The similarities between the first interface information and the second interface information corresponding to the multiple test cases to be executed matched by the actual execution interface are respectively calculated, and the expected test case corresponding to the interface identifier of the actual execution interface is determined according to the similarities.

8. A test system for non-interface applications of a vehicle system, characterized in that: include: A receiving module, configured to receive test case data; wherein the test case data includes a test case to be executed and its corresponding first interface information; wherein the first interface information includes an interface identifier of an expected execution interface corresponding to the test case to be executed; A modification module, used to modify the expected execution interface based on the runtime metadata parsing method so that it outputs log information in a predetermined format when executed; An execution module, used for executing the test case to be executed; An acquisition module, used to acquire real-time log information of the vehicle system executing the test case to be executed; A parsing module, used for parsing the real-time log information to obtain second interface information; A judgment module is used to judge the test result of the test case to be executed according to the first interface information and the second interface information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method for testing the interface-free application of the vehicle system as claimed in any one of claims 1 to 7 are implemented.

10. A storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method for testing the interface-free application of the vehicle system as claimed in any one of claims 1 to 7 are implemented.

Images