Concurrent testing method, device, storage medium and product based on task merging

Abstract

The embodiment of the application provides a concurrent test method and device based on task merging, a storage medium and a product. Task data of each test task is analyzed to generate corresponding task identifiers. According to each test task and the task identifiers of each test task, the task merging is performed on each test task to generate merged test task data, so as to reduce the number of process startings. Then, according to the merged test task data, the number of test processes of the concurrent test process is determined. The concurrent test process of the number of test processes is called to execute the concurrent test corresponding to the merged test task data respectively to generate the test results corresponding to each test task, so as to ensure the reasonable allocation of test resources, reduce the waiting time of the test task, reduce the resource occupation of the dial test probe, dynamically adjust and optimize the resource utilization, and realize the concurrent test, that is, solve the problem of long test delay in the prior art.

Description

Technical Field

[0001] This application relates to the field of probe technology, and in particular to a concurrent testing method, device, storage medium and product based on task merging. Background Technology

[0002] As network scale expands and business complexity increases, network operations and maintenance (O&M) require greater real-time performance, accuracy, and efficiency. As a core tool for network quality monitoring, probes proactively detect network performance metrics (such as latency, packet loss rate, and bandwidth utilization) by simulating user behavior (e.g., web browsing, video viewing, file downloading) or performing network layer tests (e.g., Ping, TCP / UDP connection, Traceroute).

[0003] In existing technologies, network operators need to centrally deploy testing tasks through a management platform and use testing probes to perform testing tasks at different levels of network nodes (such as backbone network, access network, and edge nodes) to achieve a comprehensive understanding of the network status.

[0004] However, existing solutions suffer from significant testing delays. Summary of the Invention

[0005] The concurrent testing method, device, storage medium, and product based on task merging provided in this application are intended to solve the problem of large testing latency caused by existing solutions.

[0006] In a first aspect, embodiments of this application provide a concurrent testing method based on task merging, comprising: parsing the task data of each test task to generate a corresponding task identifier; merging the test tasks according to each test task and its task identifier to generate merged test task data; determining the number of test processes for concurrent testing based on the merged test task data; and calling the number of concurrent test processes to execute the concurrent tests corresponding to the merged test task data to generate test results for each test task.

[0007] In one possible implementation, parsing the task data of each test task to generate a corresponding task identifier includes: for each test task: generating a hash key based on the task data of the test task; and calling a preset hash algorithm to calculate the hash key to generate a task identifier corresponding to the test task.

[0008] In one possible implementation, the step of merging test tasks based on each test task and its task identifier to generate merged test task data includes: classifying test tasks according to their corresponding test types to obtain one or more test task sets; and sequentially performing the following steps for each test task set: matching the task identifier with the generated merged test task data; wherein the test type corresponding to the generated merged test task data is consistent with the test type of the test task set; if the generated merged test task data includes the task identifier, then the task included in the generated merged test task data is considered as a test task. The test address of the test task is added under the identifier, and the generated merged test task data is obtained again. If the generated merged test task data does not include the task identifier, the task identifier is added to the generated merged test task data, and the test address of the test task is added under the added task identifier, and the generated merged test task data is obtained again. For the last test task in the test task set, after completing the above steps, the obtained generated merged test task data is determined as the category merged test task data corresponding to the test task set. The merged test task data is obtained by summarizing the data of each category merged test task.

[0009] In one possible implementation, determining the number of test processes for concurrent test processes based on the merged test task data includes: determining the number of test addresses based on the merged test task data; and determining the number of test processes based on the number of test addresses and the maximum number of test addresses for a single test process.

[0010] In one possible implementation, the process of determining the maximum number of test addresses for a single test process includes: determining the test type based on the merged test task data; and determining the maximum number of test addresses for a single test process based on the test type.

[0011] In one possible implementation, the method of calling the number of concurrent test processes to execute concurrent tests corresponding to the merged test task data to generate test results for each test task includes: dividing the merged test task data according to the number of test processes to determine the target merged test task data corresponding to each concurrent test process; for each concurrent test process: verifying the target merged test task data corresponding to the concurrent test process; if the target merged test task data passes the verification, then performing address parsing on the target merged test task data to obtain a set of test addresses; wherein the set of test addresses includes multiple test addresses; creating a packet sending test thread and a packet receiving test thread in the concurrent test process; based on the packet sending test thread and a preset time interval, sequentially sending test packets to each test address to test the test address; based on the packet receiving test thread, receiving the test data sent by the test address; and generating test results corresponding to the test task based on the test data.

[0012] Secondly, embodiments of this application provide a concurrent testing device based on task merging, comprising: a parsing module, used to parse the task data of each test task and generate corresponding task identifiers; a processing module, used to merge the test tasks according to each test task and the task identifiers of each test task, and generate merged test task data; and a generation module, used to call the number of concurrent test processes of the number of test processes, and execute the concurrent tests corresponding to the merged test task data respectively, so as to generate test results corresponding to each test task.

[0013] In one possible implementation, when the parsing module parses the task data of each test task and generates the corresponding task identifier, it is specifically used to: for each test task: generate a hash key based on the task data of the test task; call a preset hash algorithm to calculate the hash key and generate the task identifier corresponding to the test task.

[0014] In one possible implementation, when the processing module merges test tasks based on each test task and its task identifier to generate merged test task data, it specifically performs the following steps: classifying test tasks according to their corresponding test types to obtain one or more test task sets; and sequentially executing the following steps for each test task set: matching the task identifier with the generated merged test task data; wherein the test type corresponding to the generated merged test task data is consistent with the test type of the test task set; if the generated merged test task data includes the task identifier, then the merged test task data includes... The test address of the test task is added under the task identifier, and the generated merged test task data is obtained again. If the generated merged test task data does not include the task identifier, the task identifier is added to the generated merged test task data, and the test address of the test task is added under the added task identifier, and the generated merged test task data is obtained again. For the last test task in the test task set, after completing the above steps, the re-obtained generated merged test task data is determined as the category merged test task data corresponding to the test task set. The merged test task data is obtained by summarizing the category merged test task data.

[0015] In one possible implementation, when the processing module determines the number of test processes for concurrent test processes based on the merged test task data, it is specifically used to: determine the number of test addresses based on the merged test task data; and determine the number of test processes based on the number of test addresses and the maximum number of test addresses for a single test process.

[0016] In one possible implementation, the processing module is specifically used to: determine the test type based on the merged test task data; and determine the maximum number of test addresses for the single test process based on the test type.

[0017] In one possible implementation, when the generation module calls the number of concurrent test processes to execute concurrent tests corresponding to the merged test task data to generate test results for each test task, it specifically performs the following steps: Dividing the merged test task data according to the number of test processes to determine the target merged test task data for each concurrent test process; for each concurrent test process: verifying the target merged test task data corresponding to the concurrent test process; if the target merged test task data passes verification, performing address parsing on the target merged test task data to obtain a set of test addresses; wherein the set of test addresses includes multiple test addresses; creating a packet sending test thread and a packet receiving test thread in the concurrent test process; based on the packet sending test thread and a preset time interval, sequentially sending test packets to each test address to test the test address; receiving test data sent by the test address based on the packet receiving test thread; and generating test results corresponding to the test task based on the test data.

[0018] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0019] The memory stores computer-executed instructions;

[0020] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0022] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0023] The concurrent testing method, device, storage medium, and product based on task merging provided in this application solve the problem of high test latency in the prior art by generating task identifiers and merging test tasks. Specifically, the task data of each test task is parsed to generate corresponding task identifiers; based on each test task and its task identifier, the test tasks are merged to generate merged test task data, thereby reducing the number of process startups; then, based on the merged test task data, the number of concurrent test processes is determined; the number of concurrent test processes is called to execute the concurrent tests corresponding to the merged test task data, thereby generating test results for each test task. This ensures reasonable allocation of test resources, reduces the waiting time of test tasks, reduces the resource consumption of probes, and dynamically adjusts and optimizes resource utilization to achieve concurrent testing, thus solving the problem of high test latency in the prior art. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0025] Figure 1 A schematic diagram illustrating the scenario of the concurrent testing method based on task merging provided in this application;

[0026] Figure 2 A flowchart illustrating a concurrent testing method based on task merging provided in one embodiment of this application;

[0027] Figure 3 A flowchart of a concurrent testing method based on task merging provided for another embodiment of this application;

[0028] Figure 4 A schematic diagram of the structure of a concurrent testing device based on task merging provided in one embodiment of this application;

[0029] Figure 5 A schematic diagram of the structure of the electronic device provided in this application.

[0030] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0032] The technical solution of this application involves the collection, storage, use, processing, transmission, provision and disclosure of user personal information and data, which comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0033] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0034] With the expansion of network scale and the increase in service complexity, network operation and maintenance demands higher levels of real-time performance, accuracy, and efficiency. As a core tool for network quality monitoring, dial-up probes proactively detect network performance indicators (such as latency, packet loss rate, and bandwidth utilization) by simulating user behavior (e.g., web browsing, video viewing, file downloading) or performing network layer tests (e.g., Ping, TCP / UDP connection, Traceroute). In existing technologies, network operators need to centrally deploy dial-up testing tasks through a management platform and execute these tasks on different network nodes (e.g., backbone, access, and edge nodes) using dial-up probes to achieve comprehensive network status awareness. However, existing solutions suffer from significant testing latency because the dial-up probes need to start a separate process for each task.

[0035] The application scenarios of the embodiments of this application are explained below:

[0036] Figure 1 A schematic diagram illustrating the scenario of the task merging-based concurrent testing method provided in this application is shown below. Figure 1As shown, the execution subject of the method provided in this application embodiment can be any form of electronic device. Taking a computer device as the execution subject, the computer device 101 parses the task data of each test task and generates a corresponding task identifier; according to each test task and its task identifier, it merges the test tasks to generate merged test task data; according to the merged test task data, it determines the number of concurrent test processes; it calls the number of concurrent test processes to execute the concurrent tests corresponding to the merged test task data, sends test packets to test address 102 to test test address 102, and then receives the test data sent by test address 102; according to the test data, it generates the test results corresponding to each test task; wherein, test address 102 can be a real physical server or a virtual network address.

[0037] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0038] Figure 2 A flowchart of a concurrent testing method based on task merging provided in one embodiment of this application is shown below. Figure 2 As shown, the execution subject of the task merging-based concurrent testing method provided in this embodiment can be any form of electronic device. For example, this embodiment uses a computer device as the execution subject for illustration. The task merging-based concurrent testing method provided in this embodiment includes the following steps:

[0039] Step S201: Parse the task data of each test task and generate the corresponding task identifier.

[0040] For example, for each test task, task data for the test task is obtained separately, and a task identifier is generated to indicate the test task based on the task data. Specifically, for example, for three different test addresses add_1, add_2, and add_3, there are corresponding test tasks task_1, task_2, and task_3. Then, the task data of test tasks task_1, task_2, and task_3 are parsed respectively, and the task identifiers generated are all label_1. The task identifier label_1 is used to indicate that test tasks task_1, task_2, and task_3 are consistent in task data, but different in test objects (e.g., test addresses). Therefore, the task identifier label_1 can be used as the identifier of test tasks task_1, task_2, and task_3.

[0041] Specifically, the specific implementation steps of step S201 include:

[0042] For each test task: Generate a hash key based on the task data of the test task; call the preset hash algorithm to calculate the hash key and generate the task identifier corresponding to the test task.

[0043] Specifically, the test task data includes a task source identifier, a task type field, a task identifier field, and the MD5 hash of the task parameters and schedule. The task source identifier, task type field, task identifier field, and the MD5 hash of the task parameters and schedule are concatenated sequentially to generate a string, i.e., a hash key. For example, the lower 16 bits of the task source identifier, the lower 16 bits of the task type field, the lower 16 bits of the task identifier field, and the lower 32 bits of the MD5 hash of the task parameters and schedule are concatenated sequentially to generate a string, i.e., a hash key. Then, based on a preset hash algorithm (e.g., the BKDRHash algorithm), the hash key is calculated to generate the corresponding task identifier.

[0044] In this embodiment, a preset hash algorithm ensures that different hash keys generate different task identifiers, thus providing a data foundation for merging subsequent test tasks. Specifically, it ensures that identical task data generates the same task identifier, preventing test task merging failures. For example, if multiple test tasks share the same task source identifier, task type field, task identifier field, and task parameters with the same MD5 value as the scheduler, then the same task identifier is generated.

[0045] Step S202: Based on each test task and its task identifier, merge the test tasks to generate merged test task data.

[0046] Specifically, the specific implementation steps of step S202 include:

[0047] For each test task, perform the following steps in sequence:

[0048] Step S2021: Match the task identifier with the generated merged test task data.

[0049] Step S2022: If the generated merged test task data includes a task identifier, then add the test address of the test task under the task identifier included in the generated merged test task data, and re-obtain the generated merged test task data.

[0050] Step S2023: If the generated merged test task data does not include a task identifier, then add a task identifier to the generated merged test task data, add the test address of the test task under the added task identifier, and re-obtain the generated merged test task data.

[0051] In step S2024, for the last test task, after completing steps S2021-S2023, the newly generated merged test task data is determined as the merged test task data.

[0052] In this embodiment, for the same task identifier, the test addresses of the corresponding test tasks are merged in the generated merged test task data to finally obtain merged test task data. This reduces the number and / or number of test process starts, optimizes the allocation of test resources, and improves the testing efficiency of test tasks.

[0053] Step S203: Determine the number of test processes for concurrent test processes based on the merged test task data.

[0054] Specifically, the specific implementation steps of step S203 include:

[0055] Step S2031: Determine the number of test addresses based on the merged test task data.

[0056] Step S2032: Determine the number of test processes based on the number of test addresses and the maximum number of test addresses for a single test process.

[0057] For example, the merged test task data includes one or more task identifiers, and the test addresses of one or more test tasks under each task identifier; then, based on the merged test task data, the number of test addresses corresponding to each task identifier is determined. Further, for the number of test addresses corresponding to each task identifier, the number of test processes corresponding to each task identifier is calculated respectively; taking the number of test addresses corresponding to one task identifier as an example, the calculation formula for determining the number of test processes based on the number of test addresses and the maximum number of test addresses for a single test process is shown in Equation (1).

[0058] (1)

[0059] in, The number of test processes is [number], of which the number of newly created processes is [number]. indivual; Number of test addresses; The maximum number of test addresses for a single test process; calculate the symbol. The rounding up operator; for example, Then, based on equation (1). ; Then, based on equation (1). ; Then, based on equation (1). .

[0060] Furthermore, in one possible implementation, the process of determining the maximum number of test addresses for a single test process includes: determining the test type based on the merged test task data; and determining the maximum number of test addresses for a single test process based on the test type. Specifically, the test traffic requirement is determined based on the test type; and the maximum number of test addresses for a single test process is determined based on the test traffic requirement. For example, if the test type is a Ping test, the test traffic requirement for a Ping test is small (e.g., demand_1), so the maximum number of test addresses for a single test process is large (e.g., num_1); if the test type is a video download test, the test traffic requirement for a video download test is large (e.g., demand_2), so the maximum number of test addresses for a single test process is small (e.g., num_2); where demand_1 is less than demand_2, and num_1 is greater than num_2.

[0061] In this embodiment, by establishing a mapping relationship between "test type and resource configuration", the test resources (test processes) are accurately and dynamically allocated and efficiently utilized, ensuring the stability, accuracy and scalability of the test.

[0062] Step S204: Call the concurrent test processes of the number of test processes to execute the concurrent tests corresponding to the merged test task data, so as to generate the test results corresponding to each test task.

[0063] Specifically, the specific implementation steps of step S204 include:

[0064] Step S2041: Divide the merged test task data according to the number of test processes, and determine the target merged test task data corresponding to each concurrent test process.

[0065] For example, based on step S2032, for instance, the number of test addresses corresponding to the merged test task data is 500, the number of test processes is 3, and the maximum number of test addresses for a single test process is 200. Among these, two concurrent test processes are newly created processes, and one concurrent test process is the original process. Then, the number of test addresses corresponding to the target merged test task data of the first newly created concurrent test process is 200, the number of test addresses corresponding to the target merged test task data of the second newly created concurrent test process is 200, and the number of test addresses corresponding to the target merged test task data of the concurrent test process corresponding to the original process is 100.

[0066] In this embodiment, the overhead of creating concurrent test processes is reduced: when the number of test addresses in the last batch is less than 200, the overhead (memory, CPU) of creating a new concurrent test process is greater than that of directly reusing the concurrent test process corresponding to the original process, and reusing the concurrent test process corresponding to the original process is more efficient; the redundancy of the number of concurrent test processes is avoided: if a new process is created for each batch, the last batch of a small number of addresses will also occupy an independent process, resulting in a waste of process resources.

[0067] Step S2042: For each concurrent test process: verify the target merged test task data corresponding to the concurrent test process.

[0068] Specifically, the target merged test task data is subjected to reverse hash calculation to obtain the corresponding task source identifier, task type field, task identifier field, and MD5 value of task parameters and scheduling; then, the task source identifier, task type field, task identifier field, and MD5 value of task parameters and scheduling are verified to determine whether the identifier field is not empty and whether the format is valid.

[0069] Step S2043: If the target merging test task data verification passes, then the target merging test task data is parsed to obtain a test address set; wherein, the test address set includes multiple test addresses.

[0070] Specifically, if the target merging test task data verification passes, that is, if the task source identifier, task type field, task identifier field, and the identifier field of the task parameters and scheduling MD5 value are not empty and the format is valid, then DNS latency address resolution is performed on the target merging test task data to convert the "destination address (which may be a domain name)" corresponding to the target merging test task data into a network-recognizable IP address (a necessary condition for packet sending), thus obtaining the test address, which is also the test address set; at the same time, the DNS resolution time (one of the testing indicators) is recorded to provide basic data for subsequent packet sending and data calculation.

[0071] Step S2044: Create a packet sending test thread and a packet receiving test thread in the concurrent test process.

[0072] Specifically, the number of packet sending test threads can be one or more; this application embodiment is described using one packet sending test thread; the implementation of one packet sending test thread can avoid the problems of inaccurate packet intervals and resource contention caused by multiple packet sending test threads sending packets.

[0073] Step S2045: Based on the packet sending test thread and the preset time interval, test packets are sent to each test address in sequence to test the test address.

[0074] Specifically, the test packet is, for example, an ICMP Echo request packet. The ICMP ID ensures that each test packet sent to a different test address is unique; that is, different test addresses use different test packets. Specifically, the ICMP ID of each packet is encoded according to business rules to guarantee global uniqueness. The ICMP ID is a 16-bit value. The high 8 bits of the ICMP ID equal the low 8 bits of the current process's PID, and the low 8 bits equal the "concurrency ID" (0-199) corresponding to that address. For example, if process PID = 1234 (lower 8 bits = 2^10) and concurrency ID = 5, then ICMP ID = 2^10 << 8 + 5 = 53765. This encoding rule ensures that packet IDs from different processes and addresses are not duplicated, allowing the packet receiving test thread to accurately determine the mapping relationship between test packets, test data, and test addresses during subsequent packet receiving steps.

[0075] Furthermore, after all test packets for all test addresses within this process have been sent, the packet sending test thread immediately exits to release thread resources.

[0076] Step S2046: Based on the packet receiving test thread, receive test data sent by the test address.

[0077] For example, before or after the packet sending test thread starts, the packet receiving test thread starts listening to receive test data sent by the test address until the exit condition is met (e.g., after all test packets corresponding to the test addresses under this process have been sent, a timeout preset duration is reached).

[0078] Step S2047: Generate the test results corresponding to the test task based on the test data.

[0079] For example, the test data is parsed according to the ICMP ID corresponding to the test data to obtain the "lower 8 bits of the process PID" and the "concurrency ID". The test address and the corresponding test task are determined according to the "lower 8 bits of the process PID" and the "concurrency ID". Then, the test result is determined according to the test parameters in the test data (such as packet reception time, round-trip delay = packet reception time - packet sending time, packet ownership). Thus, the test result corresponding to each test task is obtained.

[0080] In this embodiment, the problem of high test latency in the prior art is solved by generating task identifiers and merging test tasks. Specifically, the task data of each test task is parsed to generate corresponding task identifiers; based on each test task and its task identifier, the test tasks are merged to generate merged test task data, thereby reducing the number of process startups; then, based on the merged test task data, the number of concurrent test processes is determined; the number of concurrent test processes is called to execute the concurrent tests corresponding to the merged test task data, thereby generating test results for each test task. This ensures reasonable allocation of test resources, reduces the waiting time of test tasks, lowers the resource consumption of probes, and dynamically adjusts and optimizes resource utilization to achieve concurrent testing, thus solving the problem of high test latency in the prior art.

[0081] Figure 3 A flowchart of a concurrent testing method based on task merging, provided for another embodiment of this application, is shown below. Figure 3 As shown, the concurrent testing method based on task merging provided in this embodiment... Figure 2 Based on the task merging-based concurrent testing method provided in the illustrated embodiment, further refinement of step S202 results in the following steps:

[0082] Step S301: Parse the task data of each test task and generate the corresponding task identifier.

[0083] Step S302: Classify the test tasks according to the test types corresponding to each test task to obtain one or more test task sets.

[0084] Specifically, if the test types include add (ADD), modify (MODIFY), and delete (DELETE), then the corresponding sets of test tasks are add test task set, modify test task set, and delete test task set.

[0085] Step S303: For each test task in the test task set, perform the following steps sequentially: Match the task identifier with the generated merged test task data; wherein the test type corresponding to the generated merged test task data is consistent with the test type of the test task set; if the generated merged test task data includes a task identifier, add the test address of the test task under the task identifier included in the generated merged test task data, and re-obtain the generated merged test task data; if the generated merged test task data does not include a task identifier, add the task identifier to the generated merged test task data, and add the test address of the test task under the added task identifier, and re-obtain the generated merged test task data; for the last test task in the test task set, after completing the above steps, determine the re-obtained generated merged test task data as the category merged test task data corresponding to the test task set.

[0086] The merging process in step S303, which merges the test tasks, is consistent with the present application. Figure 2 The steps of S202 in the illustrated embodiment are the same and will not be described in detail here.

[0087] In this embodiment, the test tasks are further classified and grouped according to the test type corresponding to each test task, which ensures the accuracy of the merging process of each test task in subsequent steps.

[0088] Step S304: Summarize the test task data for each category to obtain the merged test task data.

[0089] Step S305: Determine the number of test processes for concurrent test processes based on the merged test task data.

[0090] Specifically, based on steps S302-S304, if the merged test task data includes multiple categories of merged test task data, then the number of test processes for the corresponding concurrent test processes is determined according to each category of merged test task data.

[0091] Step S306: Call the concurrent test processes of the number of test processes to execute the concurrent tests corresponding to the merged test task data, so as to generate the test results corresponding to each test task.

[0092] Specifically, for each category of merged test task data, the corresponding number of concurrent test processes are called to execute the concurrent tests corresponding to the category of merged test task data, so as to generate the test results corresponding to each test task under each category of merged test task data; then, the test results corresponding to each test task under each category of merged test task data are summarized to obtain the test results corresponding to each test task.

[0093] In this embodiment, the implementation of steps S305-S306 is the same as that in this application. Figure 2 The implementation methods of steps S203-S204 in the illustrated embodiment are the same, and will not be described in detail here.

[0094] Figure 4 This is a schematic diagram of the structure of a concurrent testing device based on task merging provided in one embodiment of this application, as shown below. Figure 4 As shown, the concurrent testing device 40 based on task merging provided in this embodiment includes: a parsing module 401, used to parse the task data of each test task and generate corresponding task identifiers; a processing module 402, used to merge each test task according to each test task and its task identifier, and generate merged test task data; and to determine the number of test processes in the concurrent testing process according to the merged test task data; and a generation module 403, used to call the number of concurrent test processes to execute the concurrent tests corresponding to the merged test task data, so as to generate the test results corresponding to each test task.

[0095] In one possible implementation, when parsing the task data of each test task and generating the corresponding task identifier, the parsing module 401 is specifically used to: for each test task: generate a hash key based on the task data of the test task; call a preset hash algorithm to calculate the hash key and generate the task identifier corresponding to the test task.

[0096] In one possible implementation, when processing module 402 merges test tasks according to each test task and its task identifier to generate merged test task data, it specifically performs the following steps: classifying test tasks according to the test type corresponding to each test task to obtain one or more test task sets; for each test task in each test task set, it sequentially performs the following steps: matching the task identifier with the generated merged test task data; wherein the test type corresponding to the generated merged test task data is consistent with the test type of the test task set; if the generated merged test task data includes a task identifier, then in the generated merged test task data... The test addresses of the test tasks are added under the task identifiers included in the test task set, and the generated merged test task data is obtained again. If the generated merged test task data does not include task identifiers, task identifiers are added to the generated merged test task data, and test addresses of the test tasks are added under the added task identifiers, and the generated merged test task data is obtained again. For the last test task in the test task set, after completing the above steps, the newly obtained generated merged test task data is determined as the category merged test task data corresponding to the test task set. The merged test task data of each category is summarized to obtain the merged test task data.

[0097] In one possible implementation, when the processing module 402 determines the number of test processes for concurrent test processes based on the merged test task data, it specifically performs the following steps: determining the number of test addresses based on the merged test task data; and determining the number of test processes based on the number of test addresses and the maximum number of test addresses for a single test process.

[0098] In one possible implementation, the processing module 402, in the process of determining the maximum number of test addresses for a single test process, is specifically used to: determine the test type based on the merged test task data; and determine the maximum number of test addresses for a single test process based on the test type.

[0099] In one possible implementation, when the generation module 403 calls a number of concurrent test processes to execute concurrent tests corresponding to the merged test task data to generate test results for each test task, it specifically performs the following: Dividing the merged test task data according to the number of test processes to determine the target merged test task data for each concurrent test process; for each concurrent test process: verifying the target merged test task data corresponding to the concurrent test process; if the target merged test task data passes verification, resolving the target merged test task data to obtain a set of test addresses; wherein the set of test addresses includes multiple test addresses; creating a packet sending test thread and a packet receiving test thread in the concurrent test process; based on the packet sending test thread and a preset time interval, sequentially sending test packets to each test address to test the test address; receiving test data sent by the test address based on the packet receiving test thread; and generating test results corresponding to the test tasks based on the test data.

[0100] The concurrent testing device 40 based on task merging provided in this embodiment can perform tasks such as... Figures 2-3 The technical solutions of any of the method embodiments shown are similar in implementation principle and technical effect, and will not be described again here.

[0101] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.

[0102] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0103] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0104] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0105] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0106] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0107] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0108] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0109] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0110] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0111] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0112] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0113] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0114] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0115] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0116] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A concurrent testing method based on task merging, characterized in that, include: The task data for each test task is parsed to generate the corresponding task identifier; Based on each test task and its task identifier, the test tasks are merged to generate merged test task data. Based on the merged test task data, determine the number of test processes for concurrent test processes; The number of concurrent test processes is called to execute the concurrent tests corresponding to the merged test task data, so as to generate the test results corresponding to each test task.

2. The method according to claim 1, characterized in that, The process of parsing the task data for each test task and generating corresponding task identifiers includes: For each test task: Generate a hash key based on the task data of the test task; A preset hash algorithm is invoked to calculate the hash key, generating a task identifier corresponding to the test task.

3. The method according to claim 1, characterized in that, The step of merging test tasks based on each test task and its task identifier to generate merged test task data includes: Test tasks are categorized according to the test type corresponding to each test task to obtain one or more test task sets; For each test task in each test task set, perform the following steps in sequence: The task identifier is matched with the generated merged test task data; wherein the test type corresponding to the generated merged test task data is consistent with the test type of the test task set. If the generated merged test task data includes the task identifier, then the test address of the test task is added under the task identifier included in the generated merged test task data, and the generated merged test task data is obtained again. If the generated merged test task data does not include the task identifier, then the task identifier is added to the generated merged test task data, and the test address of the test task is added under the added task identifier, and the generated merged test task data is obtained again. For the last test task in the test task set, after completing the above steps, the newly generated merged test task data will be determined as the category merged test task data corresponding to the test task set. The merged test task data is obtained by summarizing the data from each category of merged test tasks.

4. The method according to claim 1, characterized in that, The step of determining the number of test processes for concurrent test processes based on the merged test task data includes: Based on the merged test task data, determine the number of test addresses; The number of test processes is determined based on the number of test addresses and the maximum number of test addresses for a single test process.

5. The method according to claim 4, characterized in that, The process of determining the maximum number of test addresses for a single test process includes: Based on the merged test task data, determine the test type; Based on the test type, determine the maximum number of test addresses for the single test process.

6. The method according to any one of claims 1-5, characterized in that, The method of calling the specified number of concurrent test processes to execute the concurrent tests corresponding to the merged test task data, thereby generating test results for each test task, includes: Based on the number of test processes, the merged test task data is divided to determine the target merged test task data corresponding to each concurrent test process; For each concurrent test process: Verify the target merged test task data corresponding to the concurrent test process; If the target merging test task data passes the verification, then the target merging test task data is parsed to obtain a test address set; wherein, the test address set includes multiple test addresses; Create packet sending test threads and packet receiving test threads in the concurrent test process; Based on the packet sending test thread and the preset time interval, test packets are sent to each test address in sequence to test the test address; Based on the packet receiving test thread, test data sent by the test address is received; Based on the test data, generate the test results corresponding to the test task.

7. A concurrent testing device based on task merging, characterized in that, include: The parsing module is used to parse the task data of each test task and generate the corresponding task identifier; The processing module is used to merge the test tasks according to each test task and its task identifier, and generate merged test task data. Based on the merged test task data, determine the number of test processes for concurrent test processes; The generation module is used to call the number of concurrent test processes of the specified number of test processes, and execute the concurrent tests corresponding to the merged test task data respectively, so as to generate the test results corresponding to each test task.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images