Internet of vehicles performance test method and system

Abstract

The embodiment of the invention is suitable for the technical field of vehicles, and provides an Internet of Vehicles performance test method and system, and the system comprises a test client and a test server. The test client sends a test demand to the test server; the test server creates a working node cluster for operating the test scene based on the test requirement and the container technology; the working node cluster comprises first working nodes respectively corresponding to a plurality of first communication protocol types; the first working node performs data interaction with the Internet of Vehicles system when operating the test scene, and generates test data corresponding to each first communication protocol type; and the test server generates a performance test result of the Internet of Vehicles system based on the test data. By adopting the system, the simulation degree during the performance test of the Internet of Vehicles can be improved, and the hardware cost required by the test can be effectively reduced.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a method and system for testing the performance of an Internet of Vehicles (IoV). Background Art

[0002] With the development of Internet of Vehicles (IoV) technology, the number of IoV devices has gradually increased. A large number of these devices are connected to IoV systems through various communication protocols to achieve IoV communication. Therefore, to ensure the robustness of IoV system communication, performance testing of IoV systems is necessary to reduce communication risks.

[0003] Currently, IoV systems support multiple communication protocols. Therefore, IoV system performance testing also needs to consider the test data generated by IoV devices communicating under these multiple protocols. Furthermore, to improve the accuracy of performance testing, the test data volume is usually large.

[0004] However, testing IoV systems on actual vehicles is costly and cumbersome. Furthermore, using traditional testing systems to simulate communication between IoV devices is not suitable for IoV systems due to the significant differences in system architecture, network model, and communication protocols between IoV and traditional Internet systems.

[0005] Based on this, there is no good method and system for testing the performance of the Internet of Vehicles in the existing technology. Summary of the Invention

[0006] The embodiments of the present application provide a vehicle network performance testing system and method, which can improve the simulation level during vehicle network performance testing and effectively reduce the hardware cost required for testing.

[0007] In a first aspect, an embodiment of the present application provides a vehicle networking performance testing system, which includes a test client and a test server;

[0008] The test client sends the test request to the test server;

[0009] The test server creates a working node cluster for running the test scenario based on the test requirements and container technology; the working node cluster includes first working nodes corresponding to multiple first communication protocol types respectively;

[0010] When the first working node runs the test scenario, it interacts with the Internet of Vehicles system to generate test data corresponding to each first communication protocol type;

[0011] The test server generates performance test results of the Internet of Vehicles system based on the test data.

[0012] In a second aspect, an embodiment of the present application provides a method for testing the performance of an Internet of Vehicles (IoV). The method is applied to an IoV performance testing system and includes:

[0013] Creating a worker node cluster for running the test scenario based on test requirements and container technology; the worker node cluster includes first worker nodes corresponding to multiple first communication protocol types;

[0014] Acquire test data generated by data interaction with the Internet of Vehicles system when the first working node runs the test scenario;

[0015] Generate performance test results of the Internet of Vehicles system based on test data.

[0016] In a third aspect, an embodiment of the present application provides a vehicle network performance testing device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method of the second aspect described above is implemented.

[0017] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the method of the second aspect described above.

[0018] In a fifth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on a vehicle networking performance test device, the vehicle networking performance test device executes the method of the second aspect above.

[0019] Compared to the prior art, the present embodiment offers the following advantages: the IoV performance testing system includes a test client and a test server. The test client can send test requirements to the test server, which then simulates a first working node representing an IoV device based on the test requirements and container technology. Furthermore, to ensure that the simulated first working nodes are more consistent with the IoV system's system architecture, network model, and communication protocol, not only are a large number of simulated first working nodes formed into a working node cluster, but the simulated first working nodes are also divided into multiple first communication protocol types. These simulated first working nodes interact with the IoV system during test scenarios, generating test data corresponding to each first communication protocol type. Finally, the test server generates IoV system performance test results based on the test data. Compared to traditional testing systems, this system not only includes a test client for testers to control test scenarios, but also enables the IoV performance testing system to realistically simulate the operational behavior of IoV devices. Furthermore, container technology can be used to simulate first working nodes, supporting interactions with multiple first communication protocol types. This improves the simulation of the interaction between IoV devices and the IoV system during performance testing, eliminates the need to test the IoV system on a real vehicle, reduces hardware costs, and simplifies testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0021] Figure 1 This is a structural diagram of a vehicle networking performance testing system provided by an embodiment of the present application;

[0022] Figure 2 This is a flowchart of an implementation method of a vehicle networking performance testing method provided in one embodiment of the present application;

[0023] Figure 3 This is a structural diagram of a vehicle networking performance testing device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0024] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0025] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0026] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0027] With the development of Internet of Vehicles (IoV) technology, the number of IoV devices has gradually increased. A large number of these devices are connected to IoV systems through various communication protocols to achieve IoV communication. Therefore, to ensure the robustness of IoV system communication, performance testing of IoV systems is necessary to reduce communication risks.

[0028] Currently, IoV systems support multiple communication protocols. Therefore, IoV system performance testing also needs to consider the test data generated by IoV devices communicating under these multiple protocols. Furthermore, to improve the accuracy of performance testing, the test data volume is usually large.

[0029] However, testing the IoV system on a real vehicle is costly and cumbersome. Furthermore, simulating communication between IoV devices using traditional test systems is challenging due to the significant differences between IoV and traditional Internet systems in terms of system architecture, network model, and communication protocols.

[0030] For example, the Internet typically uses a single HTTP (Hypertext Transfer Protocol) protocol for communication. However, the communication protocol types between the Internet of Vehicles system and Internet of Vehicles devices include, but are not limited to, HTTP, MQTT (Message Queuing Telemetry Transport), WebSocket (a network protocol based on TCP), and CoAP (The Constrained Application Protocol), which are not limited to these protocols. Therefore, the performance testing methods for the Internet cannot be applied to the Internet of Vehicles system.

[0031] Based on this, in order to better test the performance of the Internet of Vehicles, the embodiment of the present application provides a system for testing the performance of the Internet of Vehicles. Figure 1 , Figure 1 FIG1 is a structural diagram of a vehicle networking test system provided in an embodiment of the present application. The vehicle networking performance test system includes a test client 1 and a test server 2.

[0032] Test client 1 sends a test request to test server 2.

[0033] The test client 1 can be set in an independent test device or in the test server 2. In this embodiment, in order to facilitate the tester to control the test server 2, the test client 1 can be set in an independent test device.

[0034] Exemplarily, the test device includes but is not limited to a mobile phone, a tablet computer, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, and the like. The embodiments of the present application do not impose any limitation on the specific type of the test device.

[0035] It should be noted that the above test requirements include but are not limited to the scenario name of the test scenario, scenario configuration parameters, test scripts corresponding to the test cases, the running order of the test scripts, and the first working node configured with the test cases, and there is no limitation on this.

[0036] Exemplarily, the above test scenario may be a test scenario with one MQTT message publisher and multiple subscribers.

[0037] As an example, the test client 1 may include an interaction module 11, which may be a command line control program. The interaction module 11 may communicate with the test server 2 using a dedicated application programming interface (API) to control operations such as loading, starting, stopping, and re-running the test server 2 during test execution.

[0038] The tester can enter the test requirements on the test client 1 and send them to the test server 2 through the test interaction module 11. Based on this, it can be considered that the test scenarios and working node clusters 23 created according to the test requirements can meet the tester's diverse needs for the test environment, making the test of the Internet of Vehicles system 3 closer to the real scene, and improving the authenticity and accuracy of the performance test results.

[0039] After receiving the test requirements, the test server 2 may create a working node cluster 23 for running the test scenario based on the test requirements and container technology.

[0040] The test server 2 can be run on the cloud platform 4 where the Internet of Vehicles system 3 is located, and container resources built based on container technology can be deployed on the cloud platform 4. The container resources are preset with second working nodes of multiple second communication protocol types. Exemplarily, the type of the above-mentioned cloud platform 4 can be a k8s (Kubernetes, an open source container cluster management system) cloud platform, and a container is the smallest basic unit that can be created or deployed on the k8s cloud platform.

[0041] Based on this, the test server 2 can call the container resources in the cloud platform 4 based on the container technology to simulate the first working node required by the test scenario.

[0042] In one embodiment, the above-mentioned container resource may be a container management agent resource installed in the cloud platform 4, for example, a container cluster management software agent such as a rancher agent or a swarm agent, which is not limited to this.

[0043] A container is a resource that virtualizes or lightweights an operating system's applications, including the application and its libraries. For example, it can be considered a lightweight application runtime environment, containing the files and components that make up the application.

[0044] Container technology can specifically be container orchestration technology, which is used to complete management operations such as definition, configuration, creation, modification, and deletion of container resources based on the test requirements configured by testers.

[0045] Specifically, test server 2 can build a test scenario that meets testing requirements based on container resources and container technology. For example, container resources can be used to provide stable environmental resource support. Test server 2 can deploy first worker nodes of the corresponding first communication protocol type and the number of first worker nodes based on testing requirements. Container technology can manage deployed container resources in an orderly manner.

[0046] As an example, the test server 2 may include a test management module 21 and a test control module 22. The test management module 21 may create a test scenario based on test requirements and configure scenario configuration parameters in the test scenario; the test control module may create a working node cluster 23 based on the scenario configuration parameters.

[0047] In one embodiment, scenario configuration parameters may include, but are not limited to, the first communication protocol type that the first working node must meet to run the test scenario, and the number of first working nodes used for each first communication protocol type, which is not limited. The scenario configuration parameters may be set by the tester when writing the test requirements on the test client 1.

[0048] Based on the first communication protocol type required in the above scenario configuration parameters and the number of nodes using the first communication protocol type, the test control module 22 can call the first working node corresponding to the first communication protocol type in the container resources, and create a corresponding number of first working nodes based on the number of working nodes.

[0049] For example, multiple first communication protocol types can refer to Figure 1 An example of multiple first working nodes included in the working node cluster 23 is shown. Specifically, when the first communication protocol type is the MQTT communication protocol type, the test control module 22 can call the MQTT middleware plug-in in the container resource to generate a first working node simulating the MQTT communication protocol type. The MQTT middleware plug-in can be pre-implemented in a programming language such as Erlang or Python.

[0050] It should be noted that, when creating a large number of first working nodes, the test control module 22 may also group the large number of first working nodes into a working node cluster 23 to facilitate management or running of the corresponding test scenario.

[0051] After creating the corresponding number of first working nodes, the test control module 22 can also manage the deployed container resources in an orderly manner based on container technology. For example, each first working node can be assigned a number of connections to connected vehicle devices in the connected vehicle system 3. For example, the number of connected vehicle devices required for data interaction can be evenly distributed to each first working node.

[0052] In another embodiment, the test control module 22 can also control each first working node to run the test scenario in turn according to the test cases in the test requirements and the execution order of the test scripts corresponding to the test cases to simulate the test of the Internet of Vehicles system 3.

[0053] It should be noted that, upon determining that the first communication protocol type is not included in the plurality of second communication protocol types, the test control module 22 may also invoke a plug-in deployed on the cloud platform 4 to generate a first working node corresponding to the first communication protocol type that is not included. In other words, due to the limited container resources and the rapid development of the Internet of Vehicles system 3, the container resources may not contain resources corresponding to a certain first communication protocol type. In this case, the test control module 22 will be unable to invoke the container resources to create a first working node corresponding to the first communication protocol type.

[0054] Based on this, in order to complete the performance test of the Internet of Vehicles system, the test control module 22 can call the plug-in deployed on the cloud platform 4 to generate a first working node corresponding to the first communication protocol type that is not included.

[0055] Exemplarily, the test control module 22 may generate a corresponding plug-in based on the unincluded first communication protocol type and then call the newly generated plug-in to create the corresponding first working node. For example, the cloud platform 4 may be pre-installed with a basic plug-in. The test control module 22 may then receive a programming language written by a tester that implements the unincluded first communication protocol type and write the programming language into the pre-set basic plug-in to obtain a plug-in corresponding to the first communication protocol type. Finally, the test control module 22 may call the plug-in to simulate the aforementioned first working node.

[0056] When the first working node runs the test scenario, it interacts with the Internet of Vehicles system 3 to generate test data corresponding to each first communication protocol type.

[0057] The test requirements described above include the test scripts corresponding to the test cases, the order in which the test scripts are run, and the first working nodes configured with the test cases. Therefore, running the above test scenario can be considered as each first working node running the test scripts corresponding to the configured test cases based on the order in which the test scripts are run, thereby interacting with each IoV device in IoV system 3.

[0058] For example, when running a test script, the first working node can generate a fault message simulating a vehicle failure and send it to the corresponding IoV device via a first communication protocol. Subsequently, upon receiving the fault message, the IoV device can send a response message back to the first working node. In this case, the fault message sent by the first working node and the response message from the IoV device can both be considered the test data. The content of the response message can be pre-configured and is not limited thereto.

[0059] It should be noted that, in order to enable rapid interaction between the first working node and each connected vehicle device in the connected vehicle system 3, the test server 2 and the connected vehicle system 3 can be run on the same cloud platform 4. For example, the cloud platform 4 can be a connected vehicle cloud platform. Consequently, there is no need to use a separate platform or device to run the connected vehicle system 3.

[0060] The above-mentioned Internet of Vehicles device can also be a virtual host simulated in the Internet of Vehicles system 3, used for data interaction with the first working node. Therefore, there is no need to set up a large number of physical Internet of Vehicles devices to participate in the above-mentioned test.

[0061] The test server 2 generates a performance test result of the Internet of Vehicles system based on the test data.

[0062] In one embodiment, the above performance test results include but are not limited to the results of indicators such as response time, throughput, success rate, deviation, CPU usage and RAM load of the Internet of Vehicles system 3, and are not limited to this.

[0063] The test analysis service module may include an indicator performance analysis tool to quantitatively analyze performance indicators related to the Internet of Vehicles system 3. In this embodiment, the method for analyzing the test data based on each indicator is not limited.

[0064] As an example, the test server 2 may include a test data service module 24 and a test analysis service module 25. The test data service module 24 monitors the test data generated by the interaction between the first working node and the Internet of Vehicles system 3 and stores the test data in a pre-set database. The test analysis service module 25 then analyzes the test data in the database, generates performance test results, and sends them to the test client 1.

[0065] The test data service module 24 may only monitor each first working node, and then generate the test data based on the messages sent and received by each first working node.

[0066] As an example, in order to test various aspects of the performance of the Internet of Vehicles system 3, the test data service module 24 can monitor the data values ​​generated when the first working node interacts with the Internet of Vehicles system 3, and store the data values, the timestamp when the data values ​​are obtained, and the test indicators corresponding to the data values ​​as a set of test data in the database.

[0067] In one embodiment, the database includes, but is not limited to, Oracle, Access, SQL, and other types of databases, and is not limited thereto. In this embodiment, to facilitate the acquisition of test data from the database, the database may be time series data, capable of rapidly storing the test data containing different test indicators based on time and timestamps. This can save test data reading and writing time and reduce test data storage space.

[0068] In one embodiment, the aforementioned data values ​​can be considered data obtained after parsing the message. Furthermore, when a message carries each data value, it can also encapsulate the indicator corresponding to that data value. Based on this, when monitoring any message sent or received by the first working node, the test data service module 24 can determine the aforementioned data value, the test indicator corresponding to the data value, and the timestamp of the message generation or acquisition time. This generates the aforementioned test data.

[0069] For example, the test data service module 24 can use the open-source Prometheus software to monitor each first working node and each connected vehicle device in the connected vehicle system 3 to collect data values ​​for test indicators such as LA (Load Average), CPU, RAM, and interface traffic of each first working node. Then, based on the data model function of the Prometheus software, the collected data values ​​can be converted into a set of test data in the form of test indicators and stored in the aforementioned time series database.

[0070] In another embodiment, when analyzing test data in the database, the test analysis service module may also filter, deduplicate, and summarize the test data to ensure data integrity and usability. The processed test data is then used to analyze each performance test to obtain the aforementioned performance test results.

[0071] In another embodiment, the test client 1 further includes an information display module 12 for displaying test data and performance test results in the form of data charts, wherein the data charts include graphs, tables, and metric dashboards, etc., which are not limited to these.

[0072] In one embodiment, the information display module 12 may be a visualization panel developed based on an open source program (grafana) for visualizing large data sets, thereby displaying not only the data values ​​of various test indicators but also the performance test results.

[0073] In this embodiment, the IoV performance testing system includes a test client and a test server. The test client can send test requirements to the test server, which then simulates a first working node representing the IoV device based on the test requirements and container technology. Furthermore, to ensure that the simulated first working nodes are more consistent with the IoV system's system architecture, network model, and communication protocol, not only are a large number of simulated first working nodes formed into a working node cluster, but the simulated first working nodes are also divided into multiple first communication protocol types. These simulated first working nodes interact with the IoV system during test scenarios, generating test data corresponding to each first communication protocol type. Finally, the test server generates IoV system performance test results based on the test data. Compared to traditional testing systems, this system not only includes a test client for testers to control test scenarios, but also enables the IoV performance testing system to realistically simulate the operational behavior of IoV devices. Furthermore, container technology can be used to simulate first working nodes, supporting interactions with multiple first communication protocol types. This improves the simulation of the interaction between IoV devices and the IoV system during performance testing, eliminates the need to test the IoV system on a real vehicle, reduces costs, and simplifies testing.

[0074] As an example, upon receiving a test requirement configured by a tester, the interaction module 11 within the test client 1 can send the test requirement to the test management module 21 within the test server 2. The test management module 21 can then create a test scenario based on the test requirement and configure the scenario configuration parameters within the test scenario. The test control module 22 can then invoke container resources to generate a worker node cluster 23 based on the scenario configuration parameter field and set the test cases to be executed for each first worker node within the worker node cluster 23. When executing the test cases, the first worker nodes can interact with the Internet of Vehicles system 3 to generate test data corresponding to each first communication protocol type. Finally, the test data service module 24 within the test server 2 can monitor the test data and store it in a time series database. The test analysis service module 25 within the test server 2 can then analyze the test data in the time series database to generate performance test results for the Internet of Vehicles system. The test analysis service module 25 can then send the performance test results and test data to the information display module 12 within the test client 1 for display.

[0075] For example, suppose the test requirement is: Test server 2 needs to establish 40,000 HTTP communication protocol connections with Internet of Vehicles system 3. Furthermore, 20 first worker nodes need to be deployed on cloud platform 4. Furthermore, when each first worker node executes a test case, test management module 21 must control each HTTP communication protocol connection to send a message every 100 seconds. This rate should be gradually increased to every 10 seconds over a 12-hour period.

[0076] According to the requirements of the above test scenario, the program for the first working node can be written as follows:

[0077] worker_type=http_worker

[0078] pods=20

[0079] connected=4000*10000

[0080] working=12

[0081] loop(from=100, to=10secs, rate=1rps):

[0082] sendMessage(" / login")

[0083] Among them, when testing based on the above test requirements, during the peak release period, the CPU utilization rate of the Internet of Vehicles devices that process transactions in the Internet of Vehicles system was as high as 75%, the memory utilization rate was 80%, and the load of the Internet of Vehicles system was 30%.

[0084] In another embodiment, see Figure 2 , Figure 2 The following is a flowchart illustrating an implementation of a vehicle networking performance testing method provided in an embodiment of the present application. The method can be applied to the vehicle networking performance testing system described above. The method includes the following steps:

[0085] S201. Create a working node cluster for running a test scenario based on test requirements and container technology; the working node cluster includes first working nodes corresponding to multiple first communication protocol types.

[0086] S202: Acquire test data generated by data interaction between the first working node and the Internet of Vehicles system when the first working node runs the test scenario.

[0087] S203: Generate performance test results of the Internet of Vehicles system based on the test data.

[0088] In one embodiment, the above steps and the modules corresponding to the execution of the steps have been explained in the above examples and will not be further described.

[0089] In this embodiment, the IoV performance testing system can simulate first working nodes used to represent IoV devices based on test requirements and container technology. Furthermore, to ensure that the simulated first working nodes are more consistent with the system architecture, network model, and communication protocol of the IoV system, not only are a large number of simulated first working nodes formed into a working node cluster, but the simulated first working nodes are also divided into multiple first communication protocol types. These simulated first working nodes interact with the IoV system during test scenarios, generating test data corresponding to each first communication protocol type. Finally, the test server can generate performance test results for the IoV system based on the test data. Consequently, compared to traditional testing systems, the IoV performance testing system can realistically simulate the operational behavior of IoV devices. Furthermore, by simulating first working nodes through container technology, it supports interactions with multiple first communication protocol types. This improves the simulation level of the interaction between IoV devices and the IoV system during performance testing, eliminates the need to test the IoV system on a real vehicle, reduces costs, and simplifies testing.

[0090] Figure 3 This is a structural block diagram of a vehicle networking performance test device provided by an embodiment of the present application. Figure 3As shown, the vehicle networking performance testing device 300 of this embodiment includes: a processor 310, a memory 320, and a computer program 330 stored in the memory 320 and executable by the processor 310, such as a program for the vehicle networking performance testing method. When the processor 310 executes the computer program 330, the steps in each embodiment of the vehicle networking performance testing method described above are implemented, such as Figure 2 Alternatively, the processor 310 executes the computer program 330 to implement the above Figure 1 The functions of each module in the corresponding embodiment are, for example, Figure 1 For details on the functions of each module, please refer to Figure 1 Related description in the corresponding embodiment.

[0091] Exemplarily, computer program 330 can be divided into one or more modules, one or more of which are stored in memory 320 and executed by processor 310 to implement the connected vehicle performance testing method provided in the embodiments of the present application. One or more modules can be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution process of computer program 330 in connected vehicle performance testing device 300. For example, computer program 330 can implement the connected vehicle performance testing method provided in the embodiments of the present application.

[0092] The vehicle networking performance test device 300 may include, but is not limited to, a processor 310 and a memory 320. Those skilled in the art will understand that Figure 3 It is only an example of the Internet of Vehicles performance test device 300 and does not constitute a limitation of the Internet of Vehicles performance test device 300. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the Internet of Vehicles performance test device may also include input and output devices, network access devices, buses, etc.

[0093] The processor 310 may be a central processing unit, or other general-purpose processor, a digital signal processor, an application-specific integrated circuit, an off-the-shelf programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0094] The memory 320 can be an internal storage unit of the connected vehicle performance test device 300, such as a hard drive or memory of the connected vehicle performance test device 300. The memory 320 can also be an external storage device of the connected vehicle performance test device 300, such as a plug-in hard drive, smart memory card, flash memory card, etc. equipped on the connected vehicle performance test device 300. Furthermore, the memory 320 can include both an internal storage unit of the connected vehicle performance test device 300 and an external storage device.

[0095] An embodiment of the present application provides a computer-readable storage medium, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the vehicle network performance testing method described in the above-mentioned embodiments is implemented.

[0096] An embodiment of the present application provides a computer program product. When the computer program product runs on a vehicle networking performance testing device, the vehicle networking performance testing device executes the vehicle networking performance testing method in each of the above embodiments.

[0097] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A vehicle networking performance testing system, characterized in that: The vehicle networking performance testing system includes a test client and a test server; The test client sends a test request to the test server; The test server creates a working node cluster for running the test scenario based on the test requirements and container technology; the working node cluster includes first working nodes corresponding to multiple first communication protocol types respectively; When the first working node runs the test scenario, it interacts with the Internet of Vehicles system to generate test data corresponding to each of the first communication protocol types; The test server generates a performance test result of the Internet of Vehicles system based on the test data.

2. The system according to claim 1, wherein: The test server and the Internet of Vehicles system run on the same cloud platform.

3. The system according to claim 2, characterized in that The test server tests the management module and the control module; The test management module creates the test scenario based on the test requirements and configures scenario configuration parameters in the test scenario; The test control module creates the working node cluster based on the scenario configuration parameters.

4. The system according to claim 3, characterized in that Container resources based on the container technology are deployed in the cloud platform, and second working nodes of multiple second communication protocol types are preset in the container resources; The test control module calls the first working nodes corresponding to the first communication protocol type in the container resources based on the first communication protocol type required in the scenario configuration parameters and the number of nodes using the first communication protocol type, and creates a corresponding number of the first working nodes based on the number of working nodes.

5. The system according to claim 4, characterized in that When the test control module determines that the first communication protocol type is not included in the plurality of second communication protocol types, it calls a plug-in deployed on the cloud platform to generate a first working node corresponding to the first communication protocol type that is not included.

6. The system according to claim 1, wherein: The test server includes a test data service module and a test analysis service module; The test data service module monitors the test data generated by the interaction between the first working node and the Internet of Vehicles system, and stores the test data in a preset database; The test analysis service module analyzes the test data in the database to generate the performance test result, and sends it to the test client.

7. The system according to claim 6, characterized in that The test data service module monitors the data values ​​generated when the first working node interacts with the Internet of Vehicles system, and stores the data values, the timestamp when the data values ​​are obtained, and the test indicators corresponding to the data values ​​as a set of test data in the database.

8. The system according to claim 6, wherein: The database is a time series database.

9. The system according to any one of claims 1 to 8, characterized in that: The test client includes an information display module, and the information display module displays the test data and the performance test results in the form of data charts.

10. A vehicle networking performance testing method, characterized in that: The method is applied to a vehicle networking performance test system, and the method includes: Creating a worker node cluster for running the test scenario based on test requirements and container technology; the worker node cluster includes first worker nodes corresponding to multiple first communication protocol types; Acquire test data generated by data interaction between the first working node and the Internet of Vehicles system when the first working node runs the test scenario; A performance test result of the Internet of Vehicles system is generated based on the test data.

Images