Vehicle-mounted gateway routing test method and device and storage medium

Abstract

The invention provides a test method and device for a vehicle-mounted gateway route and a storage medium. The method comprises the following steps: acquiring a test step corresponding to a vehicle-mounted gateway route test based on a test case of the vehicle-mounted gateway route; and packaging a test case of the vehicle-mounted gateway route into a function module according to the test steps, wherein the function module comprises a shunt control module, a route module, a test data sending module, a test data receiving module, a test data processing module and a connection module. And obtaining a route test strategy of the to-be-tested vehicle-mounted gateway route. And generating a test script corresponding to the to-be-tested vehicle-mounted gateway route by the plurality of function modules according to a test rule corresponding to the route test strategy. And testing the to-be-tested vehicle-mounted gateway route by using the test script to obtain a test report. According to the method provided by the invention, the test script is generated through the pre-packaged function module, and the test script is more simply generated in the test process of the vehicle-mounted gateway route, so that the test difficulty of the vehicle-mounted gateway route is reduced.

Description

Technical Field

[0001] The present application relates to the field of automotive electronics technology, and in particular, to a test method, device, and storage medium for in-vehicle gateway routing. Background Art

[0002] With the continuous development of technology, the automotive electronic and electrical architecture is developing towards the trend of high integration and centralization. The increasingly integrated and centralized trend of the automotive electronic and electrical architecture requires in-vehicle Ethernet to provide a greater bandwidth for data transmission. This makes the in-vehicle gateway need to complete routing work with a larger amount of data, richer types, and more flexible policies.

[0003] When testing the in-vehicle gateway routing in the prior art, it is necessary to first construct a test script. Different in-vehicle gateway routings may use different routing policies, and correspondingly, it is necessary to generate a test script corresponding to the in-vehicle gateway routing. During the test process of the in-vehicle gateway routing, in the face of different routing policies, the process of generating a test script is more difficult. This also makes the test of the in-vehicle gateway routing more difficult.

[0004] Therefore, how to more simply generate test scripts corresponding to different routing policies has become a technical problem that needs to be solved urgently by those skilled in the art. Summary of the Invention

[0005] Based on the above problems, the present application provides a test method, device, and storage medium for in-vehicle gateway routing to reduce the difficulty of testing the in-vehicle gateway routing.

[0006] The test method for in-vehicle gateway routing provided by the present application includes the following steps:

[0007] Obtain the test steps corresponding to the in-vehicle gateway routing test based on the test cases of the in-vehicle gateway routing;

[0008] Encapsulate the test cases of the in-vehicle gateway routing into function modules according to the test steps, and the function modules include a shunt control module, a routing module, a test data sending module, a test data receiving module, a test data processing module, and a connection module;

[0009] Obtain the routing test policy of the in-vehicle gateway routing to be tested;

[0010] Generate a test script corresponding to the in-vehicle gateway routing to be tested by generating corresponding test rules for multiple function modules according to the routing test policy;

[0011] Use the test script to test the in-vehicle gateway routing to be tested to obtain a test report.

[0012] In a possible implementation, if the routing test policy includes a loop requirement, the generating of a test script corresponding to the vehicle-mounted gateway route to be tested from multiple function modules according to the test rules corresponding to the routing test policy includes:

[0013] According to the loop requirement, when generating the test script for the vehicle-mounted gateway route to be tested, add a loop module to the test script, where the loop module is used to loop and execute the corresponding function module, and the loop module has a corresponding number of loops.

[0014] In a possible implementation, the test method for the vehicle-mounted gateway route further includes:

[0015] If the actual result corresponding to the test step included in the test report does not meet the test expectation corresponding to the test step, add an exception label to the test step that does not meet the test expectation in the test report, where the exception label is used to indicate the abnormal test step.

[0016] In a possible implementation, before obtaining the test steps corresponding to the vehicle-mounted gateway route test from the test cases based on the vehicle-mounted gateway route, the method further includes:

[0017] Obtain multiple test cases for the vehicle-mounted gateway route; the multiple test cases correspond to multiple different requirements; the multiple test cases include at least one of the following:

[0018] Test cases considering functional safety requirements, test cases considering timeout detection policies, or test cases considering routing behaviors before and after timeout.

[0019] In a possible implementation, the shunt control module is used to control the lookup, start, shutdown, and call interface functions of the shunt;

[0020] The routing module is used to read and process the routing table;

[0021] The test data sending module is used to send the data for testing the vehicle-mounted gateway to the vehicle-mounted gateway to be tested;

[0022] The test data receiving module is used to receive the data returned by the vehicle-mounted gateway to be tested;

[0023] The test data processing module is used to process the data returned by the vehicle-mounted gateway to be tested;

[0024] The connection module is used to connect the function models according to the corresponding test policy.

[0025] This application also provides a test system for a vehicle-mounted gateway route, and the system includes:

[0026] Electronic device, shunt, and in-vehicle gateway route to be tested;

[0027] The electronic device is connected to the shunt, and the shunt is connected to the in-vehicle gateway route to be tested;

[0028] The electronic device is used to send the test script of the in-vehicle gateway route to be tested to the shunt;

[0029] The shunt is used to test the in-vehicle gateway route to be tested based on the test script of the vehicle gateway route;

[0030] The tested in-vehicle gateway route returns test result data to the shunt;

[0031] The shunt returns the test result data to the electronic device;

[0032] The electronic device obtains a test report based on the test result data.

[0033] In a possible implementation, the shunt is connected to the in-vehicle gateway route to be tested through a connection harness, and the type of the connection harness is determined based on the in-vehicle gateway route to be tested.

[0034] In a possible implementation, the electronic device is connected to multiple shunts, and each shunt is respectively connected to an in-vehicle gateway route to be tested.

[0035] This application also provides a test device for an in-vehicle gateway route, and the test device for the in-vehicle gateway route includes:

[0036] A first acquisition module, configured to acquire test steps corresponding to the in-vehicle gateway route test based on the test cases of the in-vehicle gateway route;

[0037] An encapsulation module, configured to encapsulate the test cases of the in-vehicle gateway route into function modules according to the test steps, and the function modules include a shunt control module, a routing module, a test data sending module, a test data receiving module, a test data processing module, and an interface module;

[0038] A second acquisition module, configured to acquire the routing test strategy of the in-vehicle gateway route to be tested;

[0039] A test script generation module, configured to generate a test script corresponding to the in-vehicle gateway route to be tested according to the test rules corresponding to the routing test strategy for multiple function modules;

[0040] A test module, configured to test the in-vehicle gateway route to be tested by using the test script to obtain a test report.

[0041] In a possible implementation, if the routing test policy includes a loop requirement, the test script generation module is specifically configured to:

[0042] According to the loop requirement, when generating a test script for the vehicle-mounted gateway route to be tested, add a loop module to the test script, where the loop module is used to loop and execute the corresponding function module, and the loop module has a corresponding number of loops.

[0043] In a possible implementation, the device further includes:

[0044] An analysis module, configured to add an exception label to the test step that does not meet the test expectation in the test report if the actual result corresponding to the test step included in the test report does not meet the test expectation, where the exception label is used to indicate the abnormal test step.

[0045] The present application also provides a computer-readable storage medium, which is characterized in that the computer-readable storage medium is used to store a computer program, and when the computer program is executed by an electronic device, the steps of the above-mentioned test method for the vehicle-mounted gateway route are implemented.

[0046] Compared with the prior art, the present application has the following beneficial effects:

[0047] The method provided by the present application first obtains the test steps corresponding to the vehicle-mounted gateway route test based on the test cases of the vehicle-mounted gateway route. The test of the vehicle-mounted gateway route is not achieved overnight and requires many test steps to complete. The test steps in the test cases of the vehicle-mounted gateway route can accurately represent each stage of the vehicle-mounted gateway route test. Then, the test cases of the vehicle-mounted gateway route are encapsulated into function modules according to the test steps. The function modules include a shunt control module, a routing module, a test data sending module, a test data receiving module, and a test data processing module. Obtain the routing test policy of the vehicle-mounted gateway route to be tested, and generate a test script corresponding to the vehicle-mounted gateway route to be tested according to the test rules corresponding to the routing test policy for multiple function modules. Then, use the test script to test the vehicle-mounted gateway route to be tested to obtain a test report. During the test process of the vehicle-mounted gateway route, no matter what kind of routing test policy the vehicle-mounted gateway route corresponds to, a test script can be generated by the pre-encapsulated function modules corresponding to the routing test policy. It is simpler to generate a test script during the test process of the vehicle-mounted gateway route, thereby reducing the difficulty of testing the vehicle-mounted gateway route. Description of the Drawings

[0048] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0049] Figure 1 It is a flowchart of a test method for in-vehicle gateway routing provided by an embodiment of the present application;

[0050] Figure 2 It is a schematic diagram of a preliminary test sequence provided by an embodiment of the present application;

[0051] Figure 3 It is a schematic diagram of a test script provided by an embodiment of the present application;

[0052] Figure 4 It is a schematic diagram of a test report provided by an embodiment of the present application;

[0053] Figure 5 It is a schematic diagram of the structure of a test system for in-vehicle gateway routing provided by an embodiment of the present application;

[0054] Figure 6 It is a schematic diagram of the structure of a test device for in-vehicle gateway routing provided by an embodiment of the present application. Specific implementation manners

[0055] As described above, the automotive electronic and electrical architecture is developing towards the trend of high integration and centralization. The increasingly integrated and centralized trend of the automotive electronic and electrical architecture requires in-vehicle Ethernet to provide greater bandwidth data transmission capabilities. During the process of in-vehicle gateway routing testing, facing different routing strategies, it is difficult to generate test scripts. This also makes the testing of in-vehicle gateway routing difficult.

[0056] Through research, it is found that in the related art, C-like languages and JAVA programming languages are generally used to generate test scripts. However, due to the lack of a relatively standard process among different routing strategies, the difficulty of generating test scripts increases. Routing strategies can include routing strategies considering functional safety requirements, different timeout detection strategies, different routing behaviors before and after timeout, different diagnostic strategies, and different network management strategies, etc. Using C-like languages and JAVA programming languages to generate test scripts, due to the low encapsulation degree of existing functional modules, the testing of in-vehicle gateway routing is difficult and the convenience is poor.

[0057] To enable those skilled in the art to better understand the solution of this application, the following will clearly and completely describe the technical solution in the embodiments of this application with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of this application.

[0058] It can be understood that the method provided in this application can be applied to a processing device, which is a processing device that can obtain the test steps corresponding to the in-vehicle gateway routing test based on the test cases of the in-vehicle gateway routing. For example, it can be a terminal device or a server that can obtain the test steps corresponding to the in-vehicle gateway routing test based on the test cases of the in-vehicle gateway routing. The method provided in this application can be independently executed by the terminal device or the server, or can be applied to the network scenario where the terminal device and the server communicate, and is executed in cooperation by the terminal device and the server. Among them, the terminal device can be a device such as a computer or a mobile phone. The server can be understood as an application server or a Web server. In actual deployment, the server can be an independent server or a cluster server.

[0059] Figure 1 The flowchart of a test method for in-vehicle gateway routing provided by this application, the method includes the following steps:

[0060] S101: Obtain the test steps corresponding to the in-vehicle gateway routing test based on the test cases of the in-vehicle gateway routing.

[0061] The processing device obtains the test steps corresponding to the in-vehicle gateway routing test based on the test cases of the in-vehicle gateway routing. The test cases of the in-vehicle gateway routing can be a set of test inputs, execution conditions, and expected results compiled for a specific target to test a certain program path or verify whether a specific requirement is met.

[0062] In a possible implementation, the processing device can first obtain multiple test cases of the in-vehicle gateway routing, and the multiple test cases of the in-vehicle gateway routing can correspond to various different specific requirements. For example, the test cases of the in-vehicle gateway routing can be test cases considering functional safety requirements, test cases considering timeout detection strategies, or test cases considering routing behaviors before and after timeout.

[0063] S102: Package the test cases of the in-vehicle gateway routing into functional modules according to the test steps.

[0064] The processing device encapsulates the test cases routed by the in-vehicle gateway into functional modules according to the test steps. The functional modules may include a shunt control module, a routing module, a test data sending module, a test data receiving module, a test data processing module, and a connection module. The shunt control module can be used to control the shunt, such as controlling functions like shunt lookup, startup, shutdown, and interface invocation. The routing module can be used to read and process the routing table. The test data sending module is used to send the data for testing the in-vehicle gateway to the in-vehicle gateway to be tested. The test data receiving module can be used to receive the data returned by the in-vehicle gateway to be tested. The test data processing module can be used to process the data returned by the in-vehicle gateway to be tested. The connection module can be used to connect the functional model according to the corresponding test strategy.

[0065] In a possible implementation, the processing device can encapsulate the functional modules based on the Python programming language. Since the routing module can be used to read and process the routing table, the routing module encapsulated based on the Python programming language can perform full-automatic parsing and reading of the routing table, while achieving high coupling within the routing module and low cohesion between the routing module and other functional modules, which is conducive to building a complete test script.

[0066] Table 1 shows a test case for the in-vehicle gateway routing provided by an embodiment of this application.

[0067]

[0068] Table 1

[0069] In Table 1, the gateway to be tested can be the in-vehicle gateway to be tested. The processing device can identify Step 2 in Table 1, "The gateway to be tested sends a SYN packet for requesting to establish a TCP connection to the shunt". While identifying the test case for the in-vehicle gateway routing corresponding to Table 1, the processing device can also identify multiple other test cases for the in-vehicle gateway routing. The processing device can confirm based on Step 2 in Table 1 that it has identified and the steps in other test cases for the in-vehicle gateway routing. In the test cases for the in-vehicle gateway routing, it is necessary for the gateway to be tested and the shunt to establish a TCP connection. Therefore, the processing device can determine that "The gateway to be tested sends a SYN packet for requesting to establish a TCP connection to the shunt" is a key step. The processing device can encapsulate this step into a functional module. The function of this module is shunt control, so this module can be used as the shunt control module. The input of this shunt control module is the communication information such as the IP address, MAC address, or port number of the shunt and the gateway to be tested in the routing table corresponding to the gateway to be tested, and the output is whether a TCP connection is successfully established between the shunt and the gateway to be tested.

[0070] It should be noted that the above process is only an exemplary description of the encapsulation of a functional module. In actual application, the processing device can obtain more functional modules based on a certain number of test cases of in-vehicle gateway routing, so as to complete the test of in-vehicle gateway routing.

[0071] S103: Obtain the routing test policy of the in-vehicle gateway routing to be tested.

[0072] The processing device obtains the routing test policy of the in-vehicle gateway routing to be tested. The routing test policy can be a policy for testing certain functions of the in-vehicle gateway routing. The routing test policy can be a routing test policy considering functional safety requirements, timeout detection under different timeouts, routing behaviors before and after different timeouts, different diagnostic policies, and different network management policies, etc.

[0073] S104: Generate a test script corresponding to the in-vehicle gateway routing to be tested according to the test rules corresponding to the routing test policy for multiple functional modules.

[0074] The processing device can generate a test script corresponding to the in-vehicle gateway routing to be tested according to the test rules corresponding to the routing test policy for multiple functional modules.

[0075] In a possible implementation, the processing device can first build a preliminary test sequence. Figure 2 FIG. is a schematic diagram of a preliminary test sequence provided by an embodiment of the present application. The preliminary test sequence includes a test device startup module belonging to the shunt control module, a routing table reading and routing parameter importing module belonging to the routing module, a TCP connection establishment module between the shunt and the in-vehicle gateway routing to be tested belonging to the shunt control module, a module for verifying whether the test result meets the test standard belonging to the test data processing module, and a test device shutdown and resource recovery module belonging to the shunt control module. Figure 2 In, initialization is initialization, Test Step represents the test step, Expected Result represents the expected result, and Clean up represents cleaning up.

[0076] After obtaining the preliminary test sequence, the processing device can generate a test script according to the routing test policy. For example, if the routing test policy is a routing test policy considering functional safety requirements, the processing device can add a corresponding connection module to the preliminary test sequence to adapt to the requirements considering functional safety.

[0077] In a possible implementation, if the routing test policy includes a loop requirement, the processing device can, according to the loop requirement, add a loop module to the test script when generating the test script for the in-vehicle gateway routing to be tested. The loop module is used to loop-execute the corresponding functional module, and the loop module has a corresponding number of loops.

[0078] For Figure 2 a corresponding preliminary test sequence can be generated Figure 3 and a corresponding test script Figure 3 is a schematic diagram of a test script provided by an embodiment of the present application. In Figure 3 it, the test rules in the routing test policy include the requirement of looping N times and the requirement of considering functional safety. At this time, the processing device can add a loop module "For(stare = 0, end = n; step = 1)" to the preliminary test sequence, and implement N - time loop through this loop module. Since the test rules in the test policy include the requirement of considering functional safety, the processing device can add a connection module according to the actual requirements Figure 3 and the connection module added in it is a "TLS security authentication module". In this way, a test script corresponding to the in - vehicle route to be tested can be obtained quickly and simply.

[0079] S105: Use the test script to test the in - vehicle gateway route to be tested to obtain a test report.

[0080] The processing device uses the test script to test the in - vehicle gateway route to be tested to obtain a test report. After the test is completed, the tester can view the test report, which includes an overview of the test results, the overall test process, and the expected and actual results of each detailed test step.

[0081] Figure 4 is a schematic diagram of a test report provided by an embodiment of the present application, Figure 4 and the name of the corresponding test report is "TG4_TC6 Logical Address - IP Address Conversion Function Test (Physical Addressing)". Below is the overall test process and each detailed test step. The number in front of each test step is the time spent on this step in the test process. "result: 1" in the test step is the test result.

[0082] In a possible implementation manner, if the actual result corresponding to the test step included in the test report does not meet the test expectation corresponding to the test step, an exception label is added to the test step that does not meet the test expectation in the test report, and the exception label is used to indicate the abnormal test step.

[0083] The method provided by this application first obtains the test steps corresponding to the in-vehicle gateway routing test based on the test cases of the in-vehicle gateway routing. The test of the in-vehicle gateway routing is not achieved overnight and requires many test steps to complete. The test steps in the test cases of the in-vehicle gateway routing can accurately represent each stage of the in-vehicle gateway routing test. Then, according to the test steps, the test cases of the in-vehicle gateway routing are encapsulated into functional modules, which include a shunt control module, a routing module, a test data sending module, a test data receiving module, and a test data processing module. Obtain the routing test strategy of the in-vehicle gateway routing to be tested, and generate a test script corresponding to the in-vehicle gateway routing to be tested according to the test rules corresponding to the routing test strategy for multiple functional modules. Then use the test script to test the in-vehicle gateway routing to be tested to obtain a test report. During the test of the in-vehicle gateway routing, no matter what routing test strategy the in-vehicle gateway routing corresponds to, a test script can be generated by the pre-encapsulated functional modules corresponding to the routing test strategy. In the process of testing the in-vehicle gateway routing, the test script can be generated more simply, thereby reducing the difficulty of testing the in-vehicle gateway routing.

[0084] Figure 5 FIG. 4 is a schematic structural diagram of a test system for an in-vehicle gateway routing provided by this application. In Figure 5 the shown in-vehicle gateway routing test system 500, it includes an electronic device 10, a shunt 20, and an in-vehicle gateway routing 30 to be tested. The electronic device 10 is connected to the shunt 20, and the shunt 20 is connected to the in-vehicle gateway routing 30 to be tested. The electronic device 10 and the shunt 20 can be connected in various ways, such as through a 100 / 1000Base-TX wire harness. The shunt 20 and the in-vehicle gateway routing 30 to be tested can also be connected in various ways, such as through a connection wire harness, and the type of the connection wire harness is determined based on the in-vehicle gateway routing 30 to be tested. The connection wire harness can be, for example, a 100 / 1000Base-T1 wire harness, a 100 / 1000Base-TX wire harness, a CAN (FD) wire harness, or a LIN wire harness.

[0085] In a possible implementation manner, the electronic device 10 can be connected to multiple shunts 20, and each shunt 20 is respectively connected to an in-vehicle gateway routing 30 to be tested. The electronic device 10 is used to send the test script of the in-vehicle gateway routing 30 to be tested to the shunt 20. The shunt 20 is used to test the in-vehicle gateway routing 30 to be tested based on the test script of the in-vehicle gateway routing 30 to be tested. The in-vehicle gateway routing 30 to be tested is used to return test result data to the shunt 20. The shunt 20 is used to return the test result data to the electronic device 10. The electronic device 10 obtains a test report based on the test result data.

[0086] During the testing process, the electronic device 10 is also used to construct the packets required for the routing test, that is, to determine the header parameters of Ethernet, CAN, and LIN packets according to the test requirements. The electronic device 10 calls the data communication channel of the splitter 20 to send the constructed routing packets, communicates with the in-vehicle gateway routing 30 to be tested, and analyzes and processes the packets received by the splitter 20 on the electronic device 10. During the analysis, the test software can be used to extract each field in the packet and the timing of the relevant test packets one by one, determine whether each field is consistent with the in-vehicle gateway routing table, and determine that the timing of the packet is consistent with the routing policy design. The functions of constructing and analyzing data on the electronic device 10 are all implemented using pre-identified and encapsulated functional modules.

[0087] The system provided by this application supports a one-key operation of the test method for the in-vehicle gateway routing, sends and receives test scripts to the gateway to be tested, and automatically analyzes the test results. The present invention constructs test scripts through the encapsulated functional modules, without the need for a compilation process, effectively reducing the difficulty of script development. The present invention can fully automatically parse and read complex routing tables based on the test system of the in-vehicle gateway routing, improving the test efficiency and reducing the labor cost of test data import. By fully automatically parsing and reading complex routing tables, the test efficiency is improved, and the labor cost of test data import during the test process is reduced.

[0088] This application also provides a Figure 6 structural schematic diagram of a test device for in-vehicle gateway routing as shown in

[0089] The first acquisition module 601 is used to acquire the test steps corresponding to the in-vehicle gateway routing test based on the test cases of the in-vehicle gateway routing.

[0090] The encapsulation module 602 is used to encapsulate the test cases of the in-vehicle gateway routing into functional modules according to the test steps. The functional modules include a splitter control module, a routing module, a test data sending module, a test data receiving module, a test data processing module, and a connection module.

[0091] The second acquisition module 603 is used to acquire the routing test policy of the in-vehicle gateway routing to be tested.

[0092] The test script generation module 604 is used to generate test scripts corresponding to the in-vehicle gateway routing to be tested by generating multiple functional modules according to the test rules corresponding to the routing test policy.

[0093] The test module 605 is used to test the in-vehicle gateway routing to be tested using the test script to obtain a test report.

[0094] In a possible implementation, if the routing test policy includes a loop requirement, the test script generation module is specifically configured to:

[0095] Add loop units to one or more of the multiple function modules according to the loop requirement, where the loop units are used to execute the corresponding function modules in a loop, and the loop units have corresponding loop times;

[0096] Generate a test script corresponding to the on-vehicle gateway route to be tested according to the test rules corresponding to the routing test policy for one or more function modules with loop units installed and one or more function modules without loop units installed.

[0097] In a possible implementation, the device further includes:

[0098] An analysis module, configured to add an exception label to the test steps in the test report that do not meet the test expectations corresponding to the actual results of the test steps included in the test report, where the exception label is used to indicate the abnormal test steps.

[0099] The above device first obtains the test steps corresponding to the on-vehicle gateway route test based on the test cases of the on-vehicle gateway route. The test of the on-vehicle gateway route is not achieved overnight and requires many test steps to complete. The test steps in the test cases of the on-vehicle gateway route can accurately represent each stage of the on-vehicle gateway route test. Then, the test cases of the on-vehicle gateway route are encapsulated into function modules according to the test steps. The function modules include a shunt control module, a routing module, a test data sending module, a test data receiving module, and a test data processing module. Obtain the routing test policy of the on-vehicle gateway route to be tested, and generate a test script corresponding to the on-vehicle gateway route to be tested according to the test rules corresponding to the routing test policy for multiple function modules. Then, use the test script to test the on-vehicle gateway route to be tested to obtain a test report. During the test of the on-vehicle gateway route, no matter what routing test policy the on-vehicle gateway route corresponds to, a test script can be generated by the pre-encapsulated function modules corresponding to the routing test policy. Generate a test script more simply during the test of the on-vehicle gateway route, thereby reducing the difficulty of the on-vehicle gateway route test.

[0100] In practical applications, the computer-readable storage medium may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium.

[0101] A computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (a non-exhaustive list) of the computer-readable storage medium include: an electrical connection with one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or 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 this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0102] A computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which computer-readable program code is carried. Such a propagated data signal may take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium may 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 conjunction with an instruction execution system, apparatus, or device.

[0103] The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire, optical fiber cable, RF, etc., or any suitable combination of the above.

[0104] The computer program code for performing the operations of the present invention may be written in one or more programming languages or combinations thereof. The programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0105] It should be noted that the various embodiments in this specification are described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the apparatus embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for the relevant parts, reference can be made to the description of the method embodiments. The apparatus embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components referred to as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without creative efforts.

[0106] As described above, this is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present application should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A test method for in-vehicle gateway routing, characterized in that Including: Obtaining test steps corresponding to in-vehicle gateway routing tests based on test cases of in-vehicle gateway routing; Encapsulating the test cases of the in-vehicle gateway routing into functional modules according to the test steps, where the functional modules include a shunt control module, a routing module, a test data sending module, a test data receiving module, a test data processing module, and a connection module; Obtaining a routing test strategy for the in-vehicle gateway routing to be tested; Generating a test script corresponding to the in-vehicle gateway routing to be tested by generating corresponding test rules for multiple of the functional modules according to the routing test strategy; Testing the in-vehicle gateway routing to be tested using the test script to obtain a test report.

2. The method according to claim 1, characterized in that, If the routing test strategy includes a loop requirement, the generating a test script corresponding to the in-vehicle gateway routing to be tested by generating corresponding test rules for multiple of the functional modules includes: According to the loop requirement, when generating the test script for the in-vehicle gateway routing to be tested, adding a loop module to the test script, where the loop module is used to loop and execute the corresponding functional module, and the loop module has a corresponding number of loop times.

3. The method according to claim 1, wherein The method further includes: If the actual result corresponding to the test step included in the test report does not conform to the test expectation corresponding to the test step, adding an exception label to the test step in the test report that does not conform to the test expectation, where the exception label is used to indicate the abnormal test step.

4. The method according to claim 1, wherein Before obtaining the test steps corresponding to the in-vehicle gateway routing tests based on the test cases of in-vehicle gateway routing, the method further includes: Obtaining multiple test cases of the in-vehicle gateway routing; the multiple test cases correspond to multiple different requirements; the multiple test cases include at least one of the following: Test cases considering functional safety requirements, test cases considering timeout detection strategies, or test cases considering routing behaviors before and after timeout.

5. The method according to claim 1, wherein The shunt control module is used to control the search, start, stop, and call interface functions of the shunt; The routing module is used to read and process the routing table; The test data sending module is used to send data for testing the in-vehicle gateway to the in-vehicle gateway routing to be tested; The test data receiving module is used to receive data returned by the in-vehicle gateway routing to be tested; The test data processing module is used to process the data returned by the in-vehicle gateway routing to be tested; The connection module is used to connect the functional models according to the corresponding test strategy.

6. A test system for in-vehicle gateway routing, characterized in that, Including: An electronic device, a shunt, and an in-vehicle gateway routing to be tested; The electronic device is connected to the shunt, and the shunt is connected to the in-vehicle gateway routing to be tested; The electronic device is used to send the test script of the in-vehicle gateway routing to be tested to the shunt; The shunt is used to test the in-vehicle gateway routing to be tested based on the test script of the in-vehicle gateway routing; The test in-vehicle gateway routing returns test result data to the shunt; The shunt returns the test result data to the electronic device; The electronic device obtains a test report based on the test result data.

7. The system according to claim 6, characterized in that, The shunt is connected to the in-vehicle gateway route to be tested through a connection harness, and the type of the connection harness is determined based on the in-vehicle gateway route to be tested.

8. A test device for in-vehicle gateway routing, characterized in that It includes: A first acquisition module, configured to acquire test steps corresponding to the in-vehicle gateway route test based on a test case of the in-vehicle gateway route; An encapsulation module, configured to encapsulate the test case of the in-vehicle gateway route into a functional module according to the test steps, and the functional module includes a shunt control module, a routing module, a test data sending module, a test data receiving module, a test data processing module, and a connection module; A second acquisition module, configured to acquire a routing test policy of the in-vehicle gateway route to be tested; A test script generation module, configured to generate a test script corresponding to the in-vehicle gateway route to be tested according to test rules corresponding to the routing test policy for multiple said functional modules; A test module, configured to test the in-vehicle gateway route to be tested using the test script to obtain a test report.

9. The device according to claim 8, characterized in that If the routing test policy includes a loop requirement, the test script generation module is specifically configured to: According to the loop requirement, when generating the test script of the in-vehicle gateway route to be tested, add a loop module to the test script, and the loop module is used to loop and execute the corresponding functional module, and the loop module has a corresponding number of loops.

10. A computer-readable storage medium, characterized in that, For saving a computer program, wherein the computer program, when executed by a processor, implements the test method of the in-vehicle gateway route according to any one of claims 1-5.

Images