Test network construction method and device, electronic equipment and readable storage medium

Abstract

The invention relates to a test network construction method and device, electronic equipment and a readable storage medium, and relates to the technical field of testing. The test network construction method is applied to a test service cluster, the test service cluster comprises a plurality of execution nodes, and the test network construction method comprises the steps that under the condition that a target test case is received, topology description information of test sub-services in the target test case is acquired; according to the topology description information, determining target execution nodes for executing the test sub-services of each category in the target test network, and topological relation information between the target execution nodes; and constructing a target test network according to the target execution nodes of the test sub-services of each category and the topological relation information between the target execution nodes. According to the invention, on-demand generation of the test network architecture and dynamic scheduling of resources are realized, and complex and changeable test cases in an intelligent driving simulation test can be flexibly adapted.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of testing, and particularly relates to a test network construction method and device, electronic equipment and readable storage medium. BACKGROUND

[0002] With the rapid development of intelligent driving technology, simulation testing has become a key link for verifying the functions and performance of automatic driving systems. In the simulation testing process, a test network containing multiple test sub-services needs to be constructed to execute complex test cases, which puts higher requirements on the flexibility and adaptability of the test network.

[0003] At present, intelligent driving simulation testing usually adopts a pre-constructed fixed test network architecture. Test personnel deploy and configure various test sub-services and their network connection relationships in advance according to the expected test requirements, forming a static test environment. When the test case is executed, it can only rely on the pre-constructed fixed network topology structure to run. However, this pre-constructed test network method has obvious shortcomings. Since the test network structure is fixed, it cannot be dynamically adjusted according to the needs of specific test cases, resulting in low utilization of test resources and difficulty in flexible adaptation to the specific needs of different types of test cases. SUMMARY

[0004] To solve the above technical problems, the present disclosure provides a test network construction method, device, electronic equipment and readable storage medium, which solves the problem of low utilization of test resources and difficulty in flexible adaptation to the specific needs of different types of test cases in related technologies.

[0005] In a first aspect, an embodiment of the present disclosure provides a test network construction method applied to a test service cluster, the test service cluster including a plurality of execution nodes, and the test network construction method comprising: In the case of receiving a target test case, acquiring topology description information of test sub-services in the target test case; determining target execution nodes for executing each category of test sub-services in a target test network and topology relationship information between the target execution nodes according to the topology description information, wherein the target test network is used to execute the target test case; and constructing the target test network according to the target execution nodes for executing each category of test sub-services and the topology relationship information between the target execution nodes.

[0006] In a second aspect, an embodiment of the present disclosure provides a test network construction device applied to a test service cluster, the test service cluster including a plurality of execution nodes, and the test network construction device comprising: The acquisition module is configured to acquire topology description information of the test sub-service in the target test case when the target test case is received; the determination module is configured to determine target execution nodes for executing each type of test sub-service in a target test network and topology relationship information between the target execution nodes according to the topology description information, wherein the target test network is used to execute the target test case; and the construction module is configured to construct the target test network according to the target execution nodes for executing each type of test sub-service and the topology relationship information between the target execution nodes.

[0007] In a third aspect, an electronic device is provided, comprising: a memory, a processor, and a computer program; the computer program is stored in the memory and is configured to be executed by the processor to implement the test network construction method in the first aspect.

[0008] In a fourth aspect, a computer readable storage medium is provided, and the computer readable storage medium stores computer instructions for causing a computer to execute the test network construction method in the first aspect.

[0009] Compared with the prior art, the technical solutions provided by the embodiments of the present disclosure have the following advantages: The test network construction method, device, electronic device, and readable storage medium provided by the embodiments of the present disclosure have the following advantages: when a target test case is acquired, the topology description information of the test sub-service in the target test case is analyzed, the target execution nodes required to be called in a plurality of execution nodes when the target test network is constructed are determined, and the topology relationship information between the target execution nodes is determined, so that the test service cluster can obtain the target execution nodes customized for the target test case and the topology relationship information between the target execution nodes in the test service cluster when different target test cases are received, even if the requirements of different target test cases are different. Then, the target test network is constructed based on the target execution nodes and the topology relationship information between the target execution nodes. By dynamically determining and constructing the target test network according to the topology description information of each target test case, the on-demand generation of the test network architecture and the dynamic scheduling of resources are realized, thereby solving the technical problem in the related art that the test network structure is fixed and cannot be dynamically adjusted according to the requirements of specific test cases, resulting in low utilization of test resources and difficulty in flexibly adapting to the specific requirements of different types of test cases. The test network in the test service cluster is no longer pre-constructed statically, but is a dynamically and automatically generated target test network with different target test cases being issued, so that the test network can flexibly adapt to the complex and changeable test cases in intelligent driving simulation testing. BRIEF DESCRIPTION OF DRAWINGS

[0010] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the accompanying drawings required by the embodiments or the prior art description will be briefly introduced as follows. Obviously, those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0012] Figure 1 A schematic diagram of an application scenario of a test network construction method provided by some embodiments of the present disclosure is shown; Figure 2 A flowchart of the test network construction method in some embodiments of the present disclosure is shown; Figure 3 A topology diagram of a target test case provided by some embodiments of the present disclosure is shown; Figure 4 A topology diagram of a target test case provided by some embodiments of the present disclosure is shown; Figure 5 A flowchart of the test network construction method in some embodiments of the present disclosure is shown; Figure 6 A flowchart of the test network construction method in some embodiments of the present disclosure is shown; Figure 7 A topology diagram of a target test case provided by some embodiments of the present disclosure is shown; Figure 8 A topology diagram of a target test network provided by some embodiments of the present disclosure is shown; Figure 9 A topology diagram of a test service cluster provided by some embodiments of the present disclosure is shown; Figure 10 A structural block diagram of a surveying network construction apparatus provided by some embodiments of the present disclosure is shown; Figure 11 A structural schematic diagram of an electronic device provided by some embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the accompanying drawings required by the embodiments or the prior art description will be briefly introduced as follows. Obviously, those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0014] Many particular details are set forth in the following description in order to provide a thorough understanding of the present disclosure. However, the present disclosure can be practiced according to the claims without some or all of these details. Indeed, some embodiments of the present disclosure can be specifically adapted to satisfy specific, application- or business-related constraints, including constraints introduced by the particular intended use of the embodiments. In other instances, well-known structures have not been described in detail in order to avoid unnecessarily obscuring the present disclosure.

[0015] It should be noted that, in the present document, relational terms such as "first" and "second", and the like, can be used solely to distinguish one entity or action from another entity or action, without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a", "comprises...", or "comprising...", does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0016] Embodiments of the present disclosure provide a test network construction method, which will be described below in conjunction with specific embodiments.

[0017] Figure 1 A schematic diagram of an application scenario of a test network construction method provided by some embodiments of the present disclosure is shown in FIG. 1. Figure 1 As shown in FIG. 1, the application scenario includes a test service cluster 100, and the test service cluster 100 includes a plurality of servers 110, and each server 110 includes a plurality of processors 112.

[0018] A plurality of execution nodes and management nodes are deployed in the test service cluster, each execution node is capable of invoking a corresponding number of processors, and the management node is capable of invoking a plurality of execution nodes, thereby building a corresponding test network.

[0019] Exemplarily, the plurality of execution nodes include a vehicle-side algorithm node, a cloud-side algorithm node, a simulation service node, and a test service node.

[0020] In the related art, the network topology of each test sub-service capable of being started by a test case can only be determined in advance in the preparation stage of the execution node, thereby building a corresponding test network for the test case. In order to improve the adaptation performance to different test cases, it is necessary to redundantly set the execution nodes in the test network, which leads to that the test resources in each test node cannot be fully utilized in the actual execution process, resulting in a low utilization rate of test resources.

[0021] According to an embodiment of the present disclosure, a test network construction method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown.

[0022] The following describes an example of the test network construction method in the present application executed by a management node in a test service cluster: In this embodiment, a test network construction method is provided, which can be used in the test service cluster in the above application scenarios, and the test service cluster includes a plurality of execution nodes, Figure 2 A flowchart of the test network construction method in some embodiments of the present disclosure is shown, as shown in Figure 2 The flowchart includes the following steps: Step S201, upon receiving a target test case, obtaining topology description information of a test sub-service in the target test case.

[0023] In this embodiment, the target test case is a test case executed by the constructed target test network, and the target test case is a specific complete test case to be executed.

[0024] By way of example, the target test case can be a simulation test of automatic emergency braking, and the target test defines the test scenario, test evaluation criteria, and required test sub-services.

[0025] In this embodiment, the test sub-service is an independent software service or functional module that constitutes a complete target test case. Typically, different types of test sub-services require different execution nodes to execute.

[0026] By way of example, the target test case is a simulation test of intelligent driving, and the test sub-services include: sensor simulation sub-service, vehicle dynamics model sub-service, scene generation sub-service, result evaluation sub-service, etc. Among them, the sensor simulation service and the vehicle dynamics model service belong to the vehicle-side algorithm sub-service, the scene generation service belongs to the simulation sub-service, and the result evaluation service belongs to the test sub-service.

[0027] In this embodiment, when the management node receives the target test case, it can parse the target test case according to the topology description rules of the test case, thereby determining the topology description information of the test sub-service in the target test case.

[0028] The topology description information is used to describe the category of each test sub-service required by the target test case, the number of test sub-services of each category, and the data flow direction and dependency relationship between each test sub-service. The topology description information represents the logical structure of the target test case.

[0029] It should be noted that the topology description information is information added in the target test case. The topology description information can be added in the target test case in the stage of creating the target test case, or the topology description information can be added in the completed target test case. The topology description information includes the type of test sub-service, the number of test sub-services of each type, and the description of the data flow direction and dependency relationship between each test sub-service.

[0030] Exemplarily, the target test case is taken as an intelligent driving simulation test. The simulation sub-service in the intelligent driving simulation test does not access other sub-services. The service provided by the simulation sub-service is only accessed by the vehicle-side algorithm sub-service. The vehicle-side algorithm sub-service does not have a mutual request access relationship with each other. In the cloud-side algorithm sub-service, a corresponding function needs to be started in one of the cloud-side algorithm sub-services, so as to be accessed by the vehicle-side algorithm sub-service and other cloud-side algorithm sub-services. The test sub-service accesses all other types of sub-services. Based on the above description, in the intelligent driving simulation test case, only the specific type of sub-service required to run in the case and the number of sub-services of each type need to be described. Combined with the above access relationship, the topology description information of the intelligent driving simulation test case is obtained.

[0031] Figure 3 A topology diagram of a target test case provided in some embodiments of the present disclosure is shown as follows. Figure 3 As shown in the figure, the target test case includes one vehicle-side algorithm sub-service and one simulation sub-service. The test process needs to run the vehicle-side algorithm sub-service and the simulation sub-service, and the vehicle-side algorithm sub-service needs to access the simulation sub-service when running.

[0032] Figure 4 A topology diagram of a target test case provided in some embodiments of the present disclosure is shown as follows. Figure 4 As shown in the figure, the target test case includes one simulation sub-service, two vehicle-side algorithm sub-services, and two cloud-side algorithm sub-services. The test process needs to run all the above sub-services. The two vehicle-side algorithm sub-services need to access the simulation sub-service and one cloud-side algorithm sub-service when running, and the other cloud-side algorithm sub-service also needs to access the cloud-side algorithm sub-service when running.

[0033] In step S202, according to the topology description information, the target execution node for executing each category of test sub-service in the target test network is determined, and the topology relationship information between the target execution nodes is determined.

[0034] The target test network is used to execute the target test case.

[0035] In this embodiment, the management node can determine the categories of the test sub-services in the test case according to the topology description information, and screen the target execution nodes from the plurality of execution nodes based on the categories of the test sub-services; and determine the topology relationship information between the screened target execution nodes according to the data flow direction and the dependency relationship between the test sub-services, the topology relationship information being used to represent the data flow direction and the dependency relationship between the target execution nodes.

[0036] Specifically, the number of the test sub-services in the target test case is at least two, and the target execution nodes correspond to the test sub-services one by one, that is, each target execution node is used to execute a corresponding test sub-service, so that the topology relationship information between the target execution nodes can be determined according to the data flow direction and the dependency relationship between the test sub-services. The topology relationship information is used to represent the interface connection relationship and the data calling relationship between the at least two target execution nodes.

[0037] In this embodiment, according to the topology description information between the test sub-services obtained by the analysis, the logical relationship between the test sub-services can be mapped to the physical resources of the test service cluster, that is, the target execution nodes are selected from the plurality of execution nodes according to the types of the test sub-services, and the topology relationship information between the plurality of target execution nodes is determined according to the data flow direction and the dependency relationship between the plurality of test sub-services.

[0038] In step S203, the target test network is constructed according to the target execution nodes of each category of test sub-service and the topology relationship information between the target execution nodes.

[0039] In this embodiment, after the target execution nodes are determined from the plurality of execution nodes and the topology relationship information between the target execution nodes is determined, the management node can configure the interface information between the target execution nodes based on the topology relationship information, so as to construct the target test network based on the target execution nodes.

[0040] In this embodiment, upon obtaining a target test case, the management node parses the topology description information of the test sub-services within the target test case to determine the target execution nodes to be invoked among multiple execution nodes when constructing the target test network, as well as the topology relationship information between the target execution nodes. This allows the test service cluster to obtain the target execution nodes tailored to the target test case and the topology relationship information between each target execution node when receiving different target test cases, even if the requirements of different target test cases are different. Then, the target test network is constructed based on the target execution nodes and the topology relationship information between each target execution node. By dynamically determining and constructing the target test network according to the topology description information of each target test case, on-demand generation of the test network architecture and dynamic scheduling of resources are achieved. This solves the technical problem in related technologies where the fixed test network structure cannot be dynamically adjusted according to the needs of specific test cases, resulting in low test resource utilization and difficulty in flexibly adapting to the specific needs of different types of test cases. In this embodiment of the disclosure, the test network in the test service cluster is no longer pre-built statically, but is dynamically and automatically generated as different target test cases are issued, so as to flexibly adapt to the complex and ever-changing test cases in intelligent driving simulation testing.

[0041] In some embodiments of this disclosure, the target execution node for each category of test sub-services in the target test network is determined based on topology description information, including: Obtain the running status information of multiple execution nodes; based on the running status information, determine the idle execution nodes among the multiple execution nodes; based on the topology description information, determine the target execution node from the idle execution nodes.

[0042] In this embodiment, the running status information characterizes the current workload and available resource status of the execution node, and is used to indicate whether the execution node is occupied. An idle execution node is an unoccupied execution node, meaning that the idle execution node can execute the test sub-services in the target test case.

[0043] In this embodiment, the management node can continuously monitor and record the running status information of all execution nodes in the test service cluster, thereby determining the occupied and idle execution nodes in the test service cluster. Once the management node has determined the topology description information, it can continuously monitor whether there are any idle execution nodes that match the topology description information of the target test case. If a matching idle execution node is detected, the target execution node matching the topology description information is selected from the idle execution nodes.

[0044] Specifically, the management node continuously monitors the running status information of multiple execution nodes to establish and maintain an available "idle execution node pool". After the management node receives the target test case and parses its topology description information, it can match the target execution node in the "idle execution node pool" to ensure that the target execution node is an idle execution node that can be called.

[0045] For example, if a target test case includes one simulation sub-service, two vehicle-side algorithm sub-services, and two cloud-based algorithm sub-services, and the "idle execution node pool" maintained by the management node contains only one simulation service node and one cloud-based algorithm node, then the target test network corresponding to this target test case will not be constructed for the time being. If, upon detecting that the "idle execution node pool" contains one simulation service node, two vehicle-side algorithm nodes, and two cloud-based algorithm nodes, these idle execution nodes will be selected as target execution nodes, and the target test network will be constructed based on these target execution nodes. The target test case will then be run through the constructed target test network.

[0046] In this embodiment of the disclosure, by introducing an idle execution node filtering mechanism based on running status information, the selection range of target execution nodes is limited to idle execution nodes among multiple execution nodes. This ensures that the newly constructed target test network will not reuse execution nodes that are already in an occupied state, avoids congestion in the execution nodes' task processing, and achieves load balancing of the test service cluster's computing resources. This allows target test cases to be automatically scheduled to execute on relatively idle resources, thereby improving the overall resource utilization and system stability of the test service cluster.

[0047] In some embodiments of this disclosure, determining the target execution node from idle execution nodes based on topology description information includes: When the target test case is determined as the test case to be executed according to the preset execution order, and the number and type of idle execution nodes meet the test requirements of the test case to be executed, the target execution node is determined from the idle execution nodes according to the topology description information; wherein, the test requirements are the requirements determined according to the type and quantity information of the test sub-services in the topology description information.

[0048] In this embodiment, the preset execution order is used to indicate the order in which multiple target test cases are executed when there are multiple target test cases.

[0049] For example, the preset execution order can be the order in which the management node receives the target test cases. Specifically, the management node constructs a test case queue. After receiving a target test case, it places the target test case into the test case queue and determines the preset execution order of the target test cases according to the first-in-first-out order, thereby determining the test cases to be executed.

[0050] In this embodiment, the test requirements are the requirements for execution nodes determined based on the topology description information of the test case to be executed. The test requirements include type requirements and quantity requirements for the execution nodes. Specifically, the type requirements are determined based on the type information of the test sub-services in the topology description information, and the quantity requirements are determined based on the quantity information of each type of test sub-service.

[0051] In this embodiment, when an idle node in the test service cluster meets the test requirements of the test case to be executed, a target execution node is selected from the idle nodes, and the subsequent process of building a target test network based on the target execution node is executed; when an idle node in the test service cluster does not meet the test requirements of the test case to be executed, the system continues to wait for the execution node in the occupied state to be released as an idle node until the idle node meets the test requirements of the test case to be executed.

[0052] It should be noted that the management node can record the occupancy status of each execution node. When the management node assigns a test sub-service to an idle execution node, the running status information of the idle execution node indicates that it is in an occupied state, and the management node marks the execution node as occupied. After the execution node in the occupied state completes the corresponding test sub-service, the management node marks the execution node in the occupied state as an idle execution node in an unoccupied state.

[0053] For example, the test requirements for the test case to be executed are two vehicle-side algorithm nodes and one simulation service node. If the management node detects that there is only one vehicle-side algorithm node among the idle execution nodes, it will continuously monitor the execution nodes in the test service cluster. After the number of idle execution nodes increases to include two vehicle-side algorithm nodes and one simulation service node, these idle execution nodes will be identified as target execution nodes, and a target test network will be constructed based on the target execution nodes.

[0054] In this embodiment, when the management node receives multiple target test cases, it determines a preset execution order for the multiple target test cases and identifies the test cases to be executed among the multiple target test cases based on the preset execution order. Then, based on the test requirements of the test cases to be executed, it monitors the available idle execution nodes in the test service cluster. When an idle execution node meets the test requirements of the test cases to be executed, it identifies the target execution node and constructs a target test network to execute the test cases to be executed. When an idle execution node does not meet the test requirements of the test cases to be executed, it waits for an idle execution node to meet the test requirements of the test cases to be executed before continuing to construct the target test network to execute the test cases to be executed. This allows the management node to construct the corresponding target test networks for multiple target test cases in a preset execution order, ensuring that multiple target test cases are executed in a preset order. This further improves the orderliness of the execution of multiple target test cases and enhances the reliability of the testing process when facing multiple target test cases with strict test order requirements.

[0055] Figure 5 Flowcharts of test network construction methods in other embodiments of this disclosure are shown, such as... Figure 5 As shown, in some possible implementations, the test network construction method includes: Step S501: Upon receiving the target test case, add the target test case to the test case queue.

[0056] Each target test case in the test case queue corresponds to a parsed topology description.

[0057] Step S502: Extract the test cases to be executed from the test case queue according to the preset execution order of the test case queue.

[0058] In this embodiment, the preset execution order can be the receiving order of target test cases in the case queue, or it can be the execution order set by the tester for all target test cases in the case queue according to actual needs.

[0059] Step S503: Determine whether the idle execution nodes in the test service cluster meet the test requirements of the test case to be executed. If the result is yes, proceed to step S505; if the result is no, proceed to step S504.

[0060] Step S504: Continuously monitor the idle execution nodes among the multiple execution nodes, and return to step S503.

[0061] In this embodiment, each test node actively reports its own running status information to the management node, enabling the management node to update idle execution nodes in a timely manner.

[0062] Step S505: Determine the target execution node among the idle execution nodes, construct the target test network for the test cases to be executed based on the target execution node, execute the test cases to be executed based on the target test network, and return to step S501.

[0063] In this embodiment, after determining the target execution node, the management node marks the target execution node as an execution node in an occupied state.

[0064] In this embodiment of the disclosure, test cases to be executed in the test case queue are determined according to a preset execution order, and the idle execution nodes in the test service cluster are continuously monitored to see if they meet the test requirements of the test cases to be executed. When the test requirements are met, the corresponding target test network is directly constructed to execute the test cases to be executed, which ensures that multiple target test cases in the test case queue can be executed in sequence according to the preset execution order, and further improves the reliability when multiple target test cases are executed.

[0065] In some embodiments of this disclosure, determining the target execution node from idle execution nodes based on topology description information includes: When the number and type of idle execution nodes meet the testing requirements of the target test case, the target execution node is determined from the idle execution nodes based on the topology description information; wherein, the testing requirements are determined based on the type and quantity information of the test sub-services in the topology description information.

[0066] In this embodiment, the management node obtains the test requirements of the target test case, and when the number and type of idle nodes meet the test requirements of the target test case, it selects the target test node corresponding to the target test case from the idle execution nodes and constructs the target test network for the target test case.

[0067] Specifically, when there are multiple target test cases, the management node can obtain the test requirements for each target test case and the currently idle execution nodes in the test service cluster. If any of the multiple target test cases is satisfied by an idle execution node, the target test node corresponding to that target test case is directly selected from the idle execution nodes, and the target test network for that target test case is constructed.

[0068] For example, the management node receives three target test cases. Target test case one requires two vehicle-side algorithm nodes, two cloud-side algorithm nodes, and one test service node; target test case two requires three vehicle-side algorithm nodes, one cloud-side algorithm node, and one simulation service node; and target test case three requires one vehicle-side algorithm node and one simulation service node. The management node determines that the idle execution nodes in the test service cluster include: twenty vehicle-side algorithm nodes, twenty cloud-side algorithm nodes, and ten simulation service nodes. At this point, the idle execution nodes can simultaneously satisfy the test requirements of target test cases two and three, but cannot satisfy the test requirements of target test case one. Therefore, the management node constructs a target test network for target test case two based on the target test nodes required for target test case two, and constructs a target test network for target test case three based on the target test nodes required for target test case three, thereby enabling the test service cluster to process target test cases two and three simultaneously. The management node continuously monitors the idle execution nodes, and when an idle execution node can satisfy the test requirements of target test case one, it constructs the corresponding target test network for target test case one.

[0069] In this embodiment of the disclosure, when the management node receives multiple target test cases, it can prioritize calling idle execution nodes. If the test requirements of any target test case are met, the management node immediately constructs a target test network based on the target execution nodes that match the target test cases among the idle execution nodes. This ensures that the execution nodes in the test service cluster are fully utilized, reducing the waste of computing resources.

[0070] Figure 6 Flowcharts of test network construction methods in some other embodiments of this disclosure are shown, such as Figure 6 As shown, in some possible implementations, the test network construction method includes: Step S601: Upon receiving the target test case, add the target test case to the test case queue.

[0071] Each target test case in the test case queue corresponds to a parsed topology description.

[0072] Step S602: Determine whether the idle execution nodes in the test service cluster meet the test requirements of any target test case. If the result is yes, proceed to step S604; if the result is no, return to step S603.

[0073] Step S603: Continuously monitor the idle execution nodes among the multiple execution nodes, and return to step S602.

[0074] In this embodiment, each test node actively reports its own running status information to the management node, enabling the management node to update idle execution nodes in a timely manner.

[0075] Step S604: Determine the target execution node among the idle execution nodes, construct a target test network based on the target execution node to meet the test requirements, execute the target test cases to meet the test requirements based on the target test network, and return to step S601.

[0076] In this embodiment, after determining the target execution node, the management node marks the target execution node as an execution node in an occupied state.

[0077] In this embodiment, the management node obtains the test requirements for each target test case in the test case queue. When it is determined that an idle execution node meets the test requirements of a target test case, the corresponding target test network is directly constructed to execute the target test case, ensuring that the test service cluster can execute multiple target test cases simultaneously and making full use of the computing resources of the test service cluster.

[0078] In some embodiments of this disclosure, the target execution nodes for each category of test sub-services in the target test network are determined based on topology description information, as well as the topology relationship information between the target execution nodes, including: Based on the type and quantity information of the test sub-services in the topology description information, the target execution nodes are determined; and based on the access dependency information between the test sub-services in the topology description information, the topology relationship information between the target execution nodes is determined.

[0079] In this embodiment, the topology description information includes type information, quantity information, and access dependency information between test sub-services. Specifically, the type information characterizes the type of each test sub-service; the quantity information characterizes the number of test sub-services corresponding to each type; and the access dependency information includes information on the data flow and dependencies between at least two test sub-services.

[0080] In this embodiment, when constructing the target test network, the management node sets up an execution node for each test sub-service in the target test case. The type of the corresponding execution node must match the type of the test sub-service. Therefore, the management node can find the target execution node matching the target test case in the test service cluster based on the type and quantity information. Access dependency information indicates the data flow and dependencies between test sub-services. Therefore, the management node can determine the topological relationship information between target execution nodes based on this access dependency information. This topological relationship information characterizes the interface access relationship between target execution nodes, facilitating the subsequent construction of access relationships between at least two target test nodes based on the topological relationship information. Specifically, it defines the API (Application Programming Interface) access relationship between one target execution node and another.

[0081] Specifically, the mapping relationship between the test sub-service and the target execution node is determined based on the node type of the target execution node and the type information of the test sub-service, with one test sub-service corresponding to one target execution node.

[0082] Specifically, after parsing the type and quantity information of multiple test sub-services in the target test case, the management node finds the target execution node among multiple execution nodes based on the type and quantity information, and then constructs a mapping relationship between the test sub-services and the target execution node according to the matching relationship of the type information.

[0083] In some possible implementations, after the management node parses the topology description information of the target test case, it assigns a number to each of the multiple test sub-services within the target test case. After selecting the target execution node based on the type and quantity information of the test sub-services, the target execution node is then numbered based on the test sub-service's number, and a mapping relationship exists between test sub-services with the same number and the target execution node.

[0084] Figure 7 A topology diagram of the target test cases provided in some embodiments of this disclosure is shown. Figure 8 The topology of the target test network provided in some embodiments of this disclosure is shown, such as... Figure 7 and Figure 8As shown, the target test cases include four types of test sub-services: A, B, C, and D. There is one sub-service of type A, three sub-services of type B, two sub-services of type C, and three sub-services of type D, totaling nine sub-services. Therefore, nine target execution nodes are required. The management node selects nine target execution nodes of the corresponding types and assigns numbers to the nine test sub-services and target execution nodes: A1, B1, B2, C1, C2, D1, D2, and D3. The management node then configures these nine numbers to the nine test sub-services and nine target execution nodes. Specifically, one test sub-service of type A corresponds to the target execution node numbered A1; three test sub-services of type B correspond to the target execution nodes numbered B1, B2, and B3; two test sub-services of type C correspond to the target execution nodes numbered C1 and C2; and three test sub-services of type D correspond to the target execution nodes numbered D1, D2, and D3.

[0085] In this embodiment, after determining the mapping relationship between the test sub-service and the target execution node, the interface call relationship of multiple target execution nodes can be determined based on the mapping relationship and topology relationship information. Thus, the target interface information is written into the corresponding target execution node, forming a topology connection between the target execution nodes, and completing the construction of the target test network.

[0086] Specifically, to construct the network topology between multiple test sub-services in the target test case, the management node parses the topology description information in the target test case, determines the access dependencies between the test sub-services based on the access dependency information in the topology description information, and constructs a dependency list for the test sub-services. Since there is a mapping relationship between the test sub-services and the target execution nodes, this dependency list is the dependency list of the target execution nodes corresponding to each test sub-service; that is, the topology relationship information between the target execution nodes is determined based on this dependency list.

[0087] In this embodiment of the disclosure, by selecting target execution nodes that match the test sub-services from multiple execution nodes based on the type and quantity information of the test sub-services, and configuring the topological relationship information between the target execution nodes based on the access dependency information between the test sub-services, a precise and complete mapping from the logical topology of the target test case to the topological network structure of the target execution nodes in the test service cluster is achieved. This enables the constructed target test network to accurately adapt to the execution requirements of the test case, improving the matching accuracy between the target test network and the target test case.

[0088] In some embodiments of this disclosure, a target test network is constructed based on the target execution nodes of each category of test sub-services and the topological relationship information between the target execution nodes, including: Based on the topology information, the target interface information is written into the target execution node to form the topology relationship between the target execution nodes, so as to build the target test network.

[0089] In this embodiment, the topological relationship information between target execution nodes can determine the access relationship between them. Therefore, based on this topological relationship information, interface information is written to the target execution nodes with access relationships, enabling data transmission between the target execution nodes with access relationships.

[0090] Specifically, based on the topology information, the dependent and dependent parties among two target execution nodes with access relationships are identified. The port information of the dependent party's target execution node is written into the configuration information of the dependent party's target execution node, enabling the dependent party to access the port information of the dependent party. By writing port information to all target execution nodes with access relationships, a request relationship topology matching the topology description information of the target test case is formed, thereby completing the construction of the target test network corresponding to the target test case.

[0091] like Figure 8 As shown, for example, parsing the topology description information of the test sub-service can yield the following topology relationship information of the target execution nodes: The target execution node numbered B1 depends on the target execution node numbered A1; the target execution node numbered B2 depends on the target execution node numbered A1; the target execution node numbered B3 depends on the target execution node numbered A1; the target execution node numbered C1 depends on the target execution node numbered B1; the target execution node numbered C2 depends on the target execution node numbered B3; the target execution node numbered C1 depends on the target execution node numbered D1; the target execution node numbered C2 depends on the target execution node numbered D1; the target execution node numbered D2 depends on the target execution node numbered D1; the target execution node numbered D3 depends on the target execution node numbered D1.

[0092] Based on the above topological relationship information, the management node... Figure 8 Each target execution node in the process performs the following operations: Write the API information of target execution node A1 to target execution nodes B1, B2, and B3; write the API information of target execution node B1 to target execution node C1; write the API information of target execution node B3 to target execution node C2; ​​write the API information of target execution node D1 to target execution nodes C1 and C2; write the API information of target execution node D1 to target execution nodes D2 and D3.

[0093] It should be noted that when the target test case is executed, the target execution node numbered B1 accesses the API of the target execution node numbered A1; the target execution node numbered B2 accesses the API of the target execution node numbered A1; the target execution node numbered B3 accesses the API of the target execution node numbered A1; the target execution node numbered C1 accesses the API of the target execution node numbered B1; the target execution node numbered C2 accesses the API of the target execution node numbered B3; the target execution node numbered C1 accesses the API of the target execution node numbered D1; the target execution node numbered C2 accesses the API of the target execution node numbered D1; the target execution node numbered D2 accesses the API of the target execution node numbered D1; and the target execution node numbered D3 accesses the API of the target execution node numbered D1.

[0094] In this embodiment of the disclosure, after determining the target execution node in the test service cluster, the corresponding target interface information can be written into the target execution node with access relationship according to the topology relationship information, thereby forming a topology relationship between the target execution nodes to complete the construction of the target test network, improving the matching between the target test case and the target test network, thereby improving the accuracy of executing the target test case through the target test network.

[0095] In some embodiments of this disclosure, the test service cluster includes multiple processors; The multiple execution nodes include vehicle-side algorithm nodes, cloud-based algorithm nodes, simulation service nodes, and test service nodes; The target test cases include at least one of the following: vehicle-side algorithm sub-service, cloud-side algorithm sub-service, simulation sub-service, and test sub-service; Based on the topology description information, determine the target execution nodes in the target test network that execute each category of sub-services, including: When the target test case includes a vehicle-side algorithm sub-service, the vehicle-side algorithm node among the multiple execution nodes is determined as the target execution node for executing the vehicle-side algorithm sub-service, wherein each vehicle-side algorithm node is pre-allocated with at least one processor; when the target test case includes a cloud-side algorithm sub-service, the cloud-side algorithm node among the multiple execution nodes is determined as the target execution node for executing the cloud-side algorithm sub-service, wherein at least two cloud-side algorithm nodes are pre-allocated to share one processor; when the target test case includes a simulation sub-service, the simulation service node among the multiple execution nodes is determined as the target execution node for executing the simulation sub-service, wherein at least two simulation service nodes are pre-allocated to share one processor; when the target test case includes a test sub-service, the test service node among the multiple execution nodes is determined as the target execution node for executing the test sub-service, wherein at least two test service nodes are pre-allocated to share one processor.

[0096] In this embodiment, the test service cluster is configured with multiple processors, which are used to build multiple execution nodes. The number of processors allocated to each execution node can be the same or different, and each execution node is allocated at least one processor.

[0097] For example, processors include, but are not limited to, CPUs (Central Processing Units) and GPUs (Graphics Processing Units).

[0098] In this embodiment, the test service cluster is used to conduct intelligent driving simulation tests. Therefore, a total of four types of execution nodes are set in the test service cluster, and the target test case includes a total of four types of test sub-services. The four types of execution nodes include: vehicle-side algorithm nodes, cloud-side algorithm nodes, simulation service nodes, and test service nodes. The four types of test sub-services include: vehicle-side algorithm sub-service, cloud-side algorithm sub-service, simulation sub-service, and test sub-service.

[0099] Specifically, the vehicle-side algorithm node is used to run vehicle-side algorithm sub-services, which can simulate the environment of the computing unit inside the vehicle; the cloud-side algorithm node is used to run cloud-side algorithm sub-services, which can simulate the environment of the cloud computing center; the simulation service node is used to run simulation sub-services, which can perform simulation models; and the test service node is used to run test sub-services, which can be responsible for services such as test case scheduling, result recording, and test judgment.

[0100] In this embodiment, a corresponding number of processors are pre-allocated to the execution nodes in the test service cluster. Before the system runs, the multiple execution nodes in the test service cluster are functionally divided and resources are pre-allocated.

[0101] Specifically, a portion of the nodes are configured as vehicle-side algorithm nodes, and each vehicle-side algorithm node is pre-allocated at least one dedicated processor to ensure the real-time performance and computational isolation of the vehicle-side algorithms. The remaining nodes are configured as cloud-based algorithm nodes, simulation service nodes, and test service nodes, respectively. For these nodes, a resource-sharing strategy is adopted, meaning that at least two nodes of the same type are pre-allocated to share a single processor. Through this pre-allocation method, a heterogeneous resource pool with clearly defined functional partitions and different resource protection strategies is constructed within the test service cluster.

[0102] Figure 9 The topology of the test service cluster provided in some embodiments of this disclosure is shown, such as... Figure 9 As shown, exemplarily, the test service cluster contains 200 processors. The management node connects to vehicle-side algorithm nodes, cloud-side algorithm nodes, simulation service nodes, and test service nodes. Specifically, there are 100 vehicle-side algorithm nodes, each with its own dedicated processor; 100 cloud-side algorithm nodes, sharing 50 processors; 100 simulation service nodes, sharing 25 processors; and 100 test service nodes, also sharing 25 processors. It should be noted that different types of execution nodes do not share processors.

[0103] In this embodiment, when selecting a target execution node from multiple execution nodes based on type and quantity information, the target execution node can be selected according to the relationships between vehicle-side algorithm nodes and vehicle-side algorithm sub-services, cloud-side algorithm nodes and cloud-side algorithm sub-services, simulation service nodes and simulation sub-services, and test service nodes and test sub-services.

[0104] In this embodiment, the node pre-configuration step establishes clear functional partitions within the test service cluster, specifically including vehicle-side algorithm nodes, cloud-side algorithm nodes, simulation service nodes, and test service nodes. Differentiated resource protection strategies are implemented for different execution nodes: vehicle-side algorithm nodes have exclusive access to the processor to ensure performance, while other execution nodes share the processor to improve resource utilization. This provides a stable and predictable underlying resource environment for building the test network. When building the target test network, the appropriate target execution node is selected through type information matching. This eliminates the need for the management node to perform complex general resource assessments each time the target test network is built. Instead, it directly schedules the test sub-services to the corresponding target execution nodes based on the needs of the test cases, improving the convenience of building the target test network.

[0105] In some possible implementations, resources other than the processor are pre-allocated to each execution node. Specifically, corresponding memory resources and port resources are allocated to each execution node. It is understood that the allocation of port resources and memory resources can be based on the number of processors in the execution node, or it can be allocated individually to each execution node according to actual needs.

[0106] This embodiment also provides a test network construction apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0107] This embodiment provides a test network construction device applied to a test service cluster, which includes multiple execution nodes. Figure 10 The following are structural block diagrams of the mapping network construction apparatus provided in some embodiments of this application, such as... Figure 10 As shown, the test network construction device 1000 includes: an acquisition module 1001, a determination module 1002, and a construction module 1003.

[0108] The acquisition module 1001 is used to acquire the topology description information of the test sub-services in the target test case when the target test case is received; The determination module 1002 is used to determine the target execution nodes for executing each category of test sub-services in the target test network, as well as the topology relationship information between the target execution nodes, based on the topology description information. The target test network is used to execute target test cases. Module 1003 is used to build the target test network based on the target execution nodes of each category of test sub-services and the topological relationship information between the target execution nodes.

[0109] In this embodiment, upon obtaining a target test case, the topology description information of the test sub-services within the target test case is parsed to determine the target execution nodes to be invoked among multiple execution nodes when constructing the target test network, as well as the topology relationship information between the target execution nodes. This allows the test service cluster to obtain, even when receiving different target test cases with varying requirements, the target execution nodes tailored to that specific target test case, along with the topology relationship information between each target execution node. Then, the target test network is constructed based on the target execution nodes and their respective topology relationship information. By dynamically determining and constructing the target test network according to the topology description information of each target test case, on-demand generation of the test network architecture and dynamic resource scheduling are achieved. This solves the technical problem in related technologies where the fixed test network structure cannot be dynamically adjusted according to the specific needs of test cases, resulting in low test resource utilization and difficulty in flexibly adapting to the specific needs of different types of test cases. In this embodiment of the disclosure, the test network in the test service cluster is no longer pre-built statically, but is dynamically and automatically generated as different target test cases are issued, so as to flexibly adapt to the complex and ever-changing test cases in intelligent driving simulation testing.

[0110] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0111] The test network construction device in this embodiment is presented in the form of functional units. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0112] Figure 11 Schematic diagrams of the structure of electronic devices provided in some embodiments of this disclosure are shown. The electronic devices provided in the embodiments of this disclosure can execute the processing flow provided in the request processing method embodiments, such as... Figure 11 As shown, the electronic device 1100 includes: a memory 1101, a processor 1102, a computer program, and a communication interface 1103; wherein the computer program is stored in the memory 1101 and is configured to be executed by the processor 1102 using the test network construction method described above.

[0113] In addition, this disclosure also provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the test network construction method of the above embodiments.

[0114] Furthermore, this disclosure also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the test network construction method described above.

[0115] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0116] The above are merely specific embodiments of this disclosure, enabling those skilled in the art to understand or implement this disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of testing network construction, characterized by, The application is applied to a test service cluster including a plurality of execution nodes, and the test network construction method includes: In the case of receiving a target test case, obtaining topology description information of a test sub-service in the target test case; According to the topology description information, determining target execution nodes for executing each category of test sub-service in a target test network, and topology relationship information between the target execution nodes, wherein the target test network is used to execute the target test case; According to the target execution nodes for executing each category of test sub-service and the topology relationship information between the target execution nodes, the target test network is constructed.

2. The test network building method of claim 1, wherein, The target execution nodes for executing each category of test sub-service in the target test network are determined according to the topology description information, including: Obtaining running state information of the plurality of execution nodes; According to the running state information, determining idle execution nodes in the plurality of execution nodes; According to the topology description information, determining the target execution nodes from the idle execution nodes.

3. The test network building method of claim 2, wherein, According to the topology description information, the target execution nodes are determined from the idle execution nodes, including: When the target test case is determined to be a to-be-executed test case according to a preset execution order, and the number and type of the idle execution nodes meet the test requirements of the to-be-executed test case, the target execution nodes are determined from the idle execution nodes according to the topology description information; The test requirements are determined according to type information and quantity information of test sub-services in the topology description information.

4. The method of claim 2, wherein, According to the topology description information, the target execution nodes are determined from the idle execution nodes, including: When the number and type of the idle execution nodes meet the test requirements of the target test case, the target execution nodes are determined from the idle execution nodes according to the topology description information; The test requirements are determined according to type information and quantity information of test sub-services in the topology description information.

5. The method of claim 1, wherein, According to the topology description information, the target execution nodes for executing each category of test sub-service in the target test network and the topology relationship information between the target execution nodes are determined, including: According to type information and quantity information of the test sub-services in the topology description information, the target execution nodes are determined; and According to access dependency relationship information between the test sub-services in the topology description information and mapping relationship information between the test sub-services and the target execution nodes, the topology relationship information between the target execution nodes is determined.

6. The test network building method according to any one of claims 1 to 5, wherein, According to the target execution nodes for executing each category of test sub-service and the topology relationship information between the target execution nodes, the target test network is constructed, including: According to the topology relationship information, target interface information is written into the target execution nodes to form a topology relationship between the target execution nodes, so as to construct the target test network.

7. The test network building method according to any one of claims 1 to 5, wherein, The test service cluster includes a plurality of processors; The plurality of execution nodes include a vehicle-end algorithm node, a cloud-end algorithm node, a simulation service node, and a test service node; The target test case includes at least one of a vehicle-end algorithm sub-service, a cloud-end algorithm sub-service, a simulation sub-service, and a test sub-service; The method further includes: In a case where the target test case includes the vehicle-end algorithm sub-service, determining the vehicle-end algorithm node in the plurality of execution nodes as the target execution node for executing the vehicle-end algorithm sub-service, wherein each vehicle-end algorithm node is pre-assigned at least one processor; In a case where the target test case includes the cloud-end algorithm sub-service, determining the cloud-end algorithm node in the plurality of execution nodes as the target execution node for executing the cloud-end algorithm sub-service, wherein at least two cloud-end algorithm nodes are pre-assigned to share one processor; In a case where the target test case includes the simulation sub-service, determining the simulation service node in the plurality of execution nodes as the target execution node for executing the simulation sub-service, wherein at least two simulation service nodes are pre-assigned to share one processor; In a case where the target test case includes the test sub-service, determining the test service node in the plurality of execution nodes as the target execution node for executing the test sub-service, wherein at least two test service nodes are pre-assigned to share one processor.

8. A test network building apparatus, characterized by comprising: The test service cluster includes a plurality of execution nodes, and the test network construction apparatus includes: An obtaining module configured to, in a case where a target test case is received, obtain topology description information of a test sub-service in the target test case; A determining module configured to, according to the topology description information, determine a target execution node for executing each type of test sub-service in a target test network, and topology relationship information between the target execution nodes, wherein the target test network is used to execute the target test case; A construction module configured to, according to the target execution node for each type of test sub-service and the topology relationship information between the target execution nodes, construct the target test network.

9. An electronic device, comprising: include: a memory; a processor; and a computer program; The computer program is stored in the memory and is configured to be executed by the processor to implement the method in any one of claims 1 to 7. The computer readable storage medium stores computer instructions for causing a computer to execute the test network construction method in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, ​

Images