WO2019178957A1 - Distributed system test method and device, computer device and storage medium - Google Patents

Abstract

Disclosed in the present application are a distributed system test method and device, a computer device and a storage medium. The distributed system test method comprises: obtaining a distributed system test request, the distributed system test request comprising a target test module, a target test type and target test time; obtaining communication link data of the target test module, the communication link data comprising a target I/O interface quantity; if the target I/O interface quantity is greater than an idle I/O interface quantity within the target test time, obtaining and displaying an idle time period in which the idle I/O interface quantity is greater than or equal to the target I/O interface quantity; and obtaining an adjusted test time, and if the current system time reaches the adjusted test time, taking over a communication link of the target test module, and testing the target test module on the basis of the target test type. The described distributed system test method ensures that the distributed system test is convenient and improves the distributed system test efficiency.

Description

Test method, device, computer device and storage medium for distributed system

The present application is based on the Chinese Patent Application No. 201 810 239 756.X filed on Mar. 22, 2018, entitled "Testing Methods, Apparatus, Computer Equipment, and Storage Media for Distributed Systems," and claims priority.

Technical field

The present application relates to the field of system testing, and in particular, to a method, device, computer device and storage medium for testing a distributed system.

Background technique

A distributed system is a system that distributes hardware and software components on a network computer and communicates and coordinates through messaging. After the completion of the distributed system, the software testing of the system will be involved. However, the current mainstream software testing models (such as V model, W model, H model and X model) are mainly designed for non-distributed systems. Although it has certain applicability in the testing of distributed systems, with the development of distributed system technology and the improvement of testing requirements, these software testing models have not been able to meet the needs of distributed system testing. At the same time, because the distributed system has the characteristics of component networking and high deployment cost, the existing test methods for distributed systems are not convenient and the test efficiency is low.

Summary of the invention

The embodiments of the present application provide a testing method, a device, a computer device, and a storage medium of a distributed system, so as to solve the problem that the testing method of the existing distributed system is not convenient and efficient.

In a first aspect, an embodiment of the present application provides a testing method for a distributed system, including the following steps:

Obtaining a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time;

Obtaining communication link data of the target test module, where the communication link data includes a number of target I/O ports;

If the number of the target I/O ports is greater than or equal to the number of idle I/O ports in the target test time, obtain and display the idle time that the number of idle I/O ports is greater than or equal to the number of the target I/O ports. segment;

Obtaining an adjustment test time, if the current system time reaches the adjustment test time, taking over the communication link of the target test module, and testing the target test module based on the target test type.

In a second aspect, an embodiment of the present application provides a testing apparatus for a distributed system, including:

a distributed system test request obtaining module, configured to obtain a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time;

a communication link data acquiring module, configured to acquire communication link data of the target test module, where the communication link data includes a number of target I/O ports;

An idle time period obtaining module, configured to acquire and display the number of idle I/O ports greater than or equal to the target if the number of target I/O ports is greater than or equal to the number of idle I/O ports during the target test time The idle time period of the number of I/O ports;

The test module is configured to obtain an adjustment test time. If the current system time reaches the adjustment test time, the communication link of the target test module is taken over, and the target test module is tested based on the target test type.

In a third aspect, an embodiment of the present application provides a computer device, including a memory, a processor, and computer readable instructions stored in the memory and executable on the processor, where the processor executes the computer The following steps are implemented when reading the instruction:

Obtaining a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time;

Obtaining communication link data of the target test module, where the communication link data includes a number of target I/O ports;

If the number of the target I/O ports is greater than or equal to the number of idle I/O ports in the target test time, obtain and display the idle time that the number of idle I/O ports is greater than or equal to the number of the target I/O ports. segment;

Obtaining an adjustment test time, if the current system time reaches the adjustment test time, taking over the communication link of the target test module, and testing the target test module based on the target test type.

In a fourth aspect, the embodiment of the present application provides one or more non-volatile readable storage media storing computer readable instructions, when the computer readable instructions are executed by one or more processors, such that the one or Multiple processors perform the following steps:

Obtaining a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time;

Obtaining communication link data of the target test module, where the communication link data includes a number of target I/O ports;

If the number of the target I/O ports is greater than or equal to the number of idle I/O ports in the target test time, obtain and display the idle time that the number of idle I/O ports is greater than or equal to the number of the target I/O ports. segment;

Obtaining an adjustment test time, if the current system time reaches the adjustment test time, taking over the communication link of the target test module, and testing the target test module based on the target test type.

The details of one or more embodiments of the present invention are set forth in the accompanying drawings and the description of the claims.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments of the present application will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present application. Other drawings may also be obtained from those of ordinary skill in the art based on these drawings without the inventive labor.

1 is a flowchart of a testing method of a distributed system in Embodiment 1 of the present application;

2 is a flow chart of a specific embodiment of step S40 in FIG. 1;

Figure 3 is a flow chart of another embodiment of step S40 of Figure 1;

4 is a flow chart of a specific embodiment of step S51 in FIG. 3;

Figure 5 is a flow chart of another embodiment of step S51 of Figure 3;

6 is a schematic diagram of a testing apparatus of a distributed system provided in Embodiment 2 of the present application;

FIG. 7 is a schematic diagram of a computer device provided in Embodiment 4 of the present application.

detailed description

The technical solutions in the embodiments of the present application are clearly and completely described in the following with reference to the drawings in the embodiments of the present application. It is obvious that the described embodiments are a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

Example 1

FIG. 1 is a flow chart showing a test method of a distributed system in the present embodiment. The test method of the distributed system is applied to various terminals or systems to solve the problem that the test method of the existing distributed system is convenient and inefficient. As shown in FIG. 1, the test method of the distributed system includes the following steps (exemplarily, the embodiment uses a test system to perform the following steps):

S10: Acquire a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time.

Among them, the distributed system test request refers to the initiation request for testing the distributed system. A distributed system includes multiple modules that can trigger a distributed system test request when one of the modules needs to be tested. The distributed system test request includes the target test module, the target test type, and the target test time. The target test module is used to point to or identify the modules in the distributed system that need to be tested. The target test type refers to the specific test type of the target test module that needs to be tested in the distributed system. The target test type may include: performance test, reliability test, stress test or functional test. The target test time refers to a preset time required to test the target test module in the distributed system. Optionally, the target test time includes a start time and an end time, or the target test time includes a start time and a test duration.

S20: Acquire communication link data of the target test module, where the communication link data includes the number of target I/O ports.

The physical channel between two nodes in the network is called a communication link. Communication link data is used to measure data communicated between a target test module and other modules. The number of target I/O ports refers to the number of I/O ports required to test the target test module. Specifically, the number of corresponding target I/O ports can be determined according to the number of communication links of the target test module. In one embodiment, the number of target I/O ports can be equal to the number of communication links of the target test module. Optionally, in order to improve test efficiency, the number of target I/O ports may also be greater than the number of communication links of the target test module.

S30: If the number of target I/O ports is greater than or equal to the number of idle I/O ports in the target test time, obtain and display an idle time period in which the number of idle I/O ports is greater than or equal to the number of target I/O ports.

According to the target test time and the number of target I/Os, it is judged whether the number of idle I/O ports of the test system within the target test time meets the requirements. If the number of target I/O ports in the target test time is greater than the number of idle I/O ports, it indicates that the test system does not have enough free I/O ports to support the distributed system test request during the target test time. At this time, an idle time period in which the number of idle I/O ports in the test system is greater than or equal to the number of target I/O ports is obtained and displayed, so that the time for testing the distributed system is adjusted according to the idle time period.

Preferably, the number of idle I/O ports in the test system in different time periods can be embodied by establishing an I/O port idle schedule. Specifically, the I/O port idle schedule includes a time interval and a corresponding number of idle I/O ports. The time interval can be divided according to the number of idle I/O ports. For example, taking 24 hours as an example, assume that the total number of I/O ports in the test system is 20. If there is a test request occupying 15 I/O ports between 8:00 and 10:00, the number of idle I/O ports of the test system is 20 at other times. Then the I/O port idle schedule can divide the time interval into: [00:00, 8:00], [8:00, 10:00], and [10:00, 24:00], thus, corresponding The I/O port idle schedule can be:

Table 1 I/O port idle timetable

The number of idle I/O ports in different time intervals can be visually understood through the I/O port idle schedule shown in Table 1. For example, if the distributed system test request, the target test module has a target I/O port number of 10 and the target test time is 9:00-11:00. At this point, the test system will get and display the idle time period of the number of idle I/O ports greater than or equal to 10, namely [00:00, 8:00] and [10:00, 24:00].

S40: Obtain an adjustment test time. If the current system time reaches the adjustment test time, take over the communication link of the target test module, and test the target test module based on the target test type.

After the idle time period in which the number of idle I/O ports is greater than or equal to the number of target I/O ports is displayed, the user can adjust the target test time according to the idle time period, and the number of idle I/O ports is greater than or equal to the target I/. A predetermined time interval is selected within the idle time period of the number of O ports as the adjustment test time, and then the test system acquires the adjustment test time.

The current system time refers to the current time displayed by the system, and the current system time reaches the adjustment test time, which may specifically refer to the start time of the current system time to reach the adjustment test time. If the current system time reaches the adjustment test time, the communication link of the target test module is taken over, and the target test module is tested based on the target test type.

The communication link that takes over the target test module refers to the various communication links that take over communication between the target test module and other modules. Specifically, the takeover of the communication link can be implemented in the following manner (taking the communication link between the client and the server as an example): insert a module between the client and the server. First, the module simulates the server to start the same port for monitoring; then, intercepts the connection request from the client and establishes a connection. At this time, the module is the server side relative to the client, so that the client can be sent. At the same time, the server-side address is configured on the module. When receiving the data packet sent by the client, the connection request is sent to the server, and the connection is established. At this time, the module is the client with respect to the server. Finally, the module forwards the packets received from the client to the server. After the server has processed the request, the return packet is sent to the client through the previously established connection. Through the above steps, the takeover of a communication link is completed, and the control of the communication data in the link can also be realized.

After taking over the communication link of the target test module, the target test module can be tested based on the target test type. By taking over the communication link of the target test module, the test system can simulate the distributed system environment, saving time spent on environmental preparation during the test process, and also saving a lot of machine resources. The specific process of testing the target test module can be set according to the type of target test.

Preferably, after obtaining the adjustment test time, the method further includes: generating a corresponding adjustment test task. Among them, the adjustment test task refers to the test task whose target test time is adjusted, and a distributed system test request corresponds to a test task. Tuning test tasks includes adjusting test time and number of target I/O ports. After the adjustment test task is generated, the I/O port idle schedule is updated according to the adjustment test task. In this way, the I/O port idle schedule is updated in real time, ensuring the accuracy of the I/O port idle schedule.

In the test method of the distributed system provided in this embodiment, after obtaining the distributed system test request, it is determined whether the target test module has sufficient time in the target test time by the target I/O port number of the target test module and the target test time. More idle I/O ports for the corresponding test tasks. When there is not enough free I/O ports in the target test time to perform the corresponding test tasks, the reminder is displayed by displaying the corresponding idle time period, so that the user can intuitively select the appropriate test time, thereby smoothly Testing of distributed systems improves the convenience of testing. By taking over the communication link of the target test module, the test system can simulate a distributed system environment, saving time spent on environmental preparation during the test process, and also saving a lot of machine resources. The target test module is tested based on the target test type, which improves the test efficiency of the distributed system.

In a specific implementation, after the step of acquiring communication link data of the target test module and the communication link data includes the number of target I/O ports, the test method of the distributed system further includes:

If the number of target I/O ports is less than the number of idle I/O ports during the target test time, when the current system time reaches the target test time, the communication link of the target test module is taken over, and the target test module is tested based on the target test type. .

If the number of target I/O ports in the target test time is less than the number of idle I/O ports, it means that the test system has enough free I/O ports to support the distributed system test request during the target test time. The communication link of the target test module is taken over when the current system time reaches the target test time, and the target test module is tested based on the target test type. The specific process of testing the target test module can be set according to the type of target test.

Preferably, if the number of target I/O ports is less than the number of idle I/O ports during the target test time, a target test task is generated. The target test task refers to a test task generated based on a distributed system test request. The target test task includes the target test time and the number of target I/O ports. And update the I/O port idle schedule according to the target test task. In this way, the I/O port idle schedule is updated in real time, ensuring the accuracy of the I/O port idle schedule.

In this implementation manner, after obtaining the result that the number of target I/O ports in the target test time is not greater than the current number of idle I/O ports, the distributed system is tested according to the corresponding target test time, and the I/O port is tested. The idle schedule is updated in real time to ensure the convenience and accuracy of distributed system testing.

In a specific implementation manner, the communication link that takes over the target test module, as shown in FIG. 2, specifically includes the following steps:

S41: Start port monitoring for the target test module.

Port listening is a type of information record that is manipulated by a terminal/module. In a distributed system, the target test module needs to establish a communication connection with each of the corresponding upstream module and downstream module. Therefore, for each of these modules, it is necessary to start the corresponding port for monitoring and establish a mapping relationship between the port and the destination module. The destination module refers to a corresponding module of the target test module to establish a communication connection. The upstream module and the downstream module are based on the target test module, and the manner in which the associated modules are distinguished according to the flow direction of the communication data. The module upstream of the target test module communication data flow is an upstream module, and the module downstream of the target test module communication data flow is a downstream module. The specific process of step S41 is as follows:

(1) Determine the number of ports N to be monitored.

The number of ports N to be monitored is determined by the communication link data of the target test module. Optionally, the number of ports to be monitored is the same as the number of target I/O ports. Preferably, the number N of ports determined to be listening can be implemented by LISTEN_NUM. For example, if the number of ports to be monitored is 5, the configuration information can be: #define LISTEN_NUM 5.

(2) Establish a mapping relationship between the port and the destination module's ip and port.

The data communication between the target test module and the upstream module or the target test module and the downstream module is established by establishing a mapping relationship between the port and the ip and port of the destination module. The ip and port of the destination module and the corresponding upstream module or downstream module must be the same when the mapping between the ip and the port of the destination module is established. Otherwise, the target test module and the upstream module or the target test module and downstream cannot be established. The link between modules. Specifically, the ip and port information of the corresponding destination module is configured for each port, and the ip and port information of the destination module of each port is the same as the ip and port information of the upstream module or the downstream module corresponding to the port.

(3) Start port monitoring and wait for the connection service of the upstream module.

After the mapping between the port and the destination module's ip and port is established, the port monitoring is started, and the real-time port monitoring task is performed, waiting for the connection service of the upstream module to trigger the corresponding process.

S42: Establish a communication link between the target test module and the upstream module and between the target test module and the downstream module based on the idle I/O port.

The establishment of the communication link connection includes two aspects of connection: (1) accepting the connection request of the upstream module and establishing a connection with the upstream module; (2) issuing a connection request to the corresponding downstream module, and corresponding to the downstream module establish connection.

When establishing a connection with an upstream module, the target test module is equivalent to the server side, and the upstream module is equivalent to the client. After the target test module establishes a connection with the upstream module, a handle fd1 is generated. When establishing a connection with the downstream module, the target test module module is equivalent to being a client. By performing a mapping relationship established during the system monitoring process, the port finds the ip and port of the destination module according to the port, and initiates a connection to the corresponding downstream module. The handle fd2 is generated after the connection. By establishing these two connections, it is possible to establish a connection between the upstream module and the downstream module, thereby realizing the effect of simulating the upstream and downstream communication links.

Specifically, a communication link between the target test module and the upstream module and between the target test module and the downstream module is established through the idle I/O port. Optionally, an idle I/O port is used to establish a corresponding communication link. For example, if the target test module communicates with an upstream module and a target test module and five downstream modules, the six idle I/O ports can be used to establish a target test module, an upstream module, and a target test module, respectively. Communication link between 5 downstream modules.

In this embodiment, after the port monitoring is started, the number of destination modules that need to be taken over and the corresponding ip and port of each destination module are determined, and the target test module and the upstream module are established based on the idle I/O port and the target test is performed. The communication link between the module and the downstream module facilitates the forwarding and recording of subsequent communication data, ensuring the accuracy and efficiency of the communication link takeover.

In a specific implementation, the target test module is tested based on the target test type, as shown in FIG. 3, and specifically includes the following steps:

S51: Record communication data of the target test module based on the target test type.

The communication data that needs to be recorded is different for different target test types. On the premise that the communication link of the target test module has been taken over, the corresponding communication data is selected for recording based on the target test type. Specifically, according to different target test types, different test data are selected for input to trigger data interaction between different modules, and the corresponding communication data is recorded by the I/O port that takes over the corresponding communication link.

In the communication data that needs to be recorded, the data in two directions, that is, the request data sent from the upstream module to the test system and the response data returned from the downstream module to the test system, can be performed on data in different directions during data recording. Mark and record separately.

Specifically, the process of recording the communication data of the target test module may be: after the test system obtains the request data sent by the upstream module, the test system identifies and saves the request data, and forwards the request data to the corresponding downstream module. After receiving the corresponding request data, the downstream module responds to the request data and performs related processing. After the processing is completed, the downstream module returns corresponding response data. The test system identifies and saves the response data and forwards the response data to the corresponding upstream module. Through the above steps, the request data sent to the downstream module by the upstream module and the response data of the response data returned by the downstream module to the upstream module are realized.

In a specific embodiment, the communication data of the recording target test module further includes forwarding of the communication data. When the connection is established on the corresponding communication link, two handles fd1 and fd2 are generated. For example, the idle I/O port A is connected to the upstream module to generate the handle fd1. The handle fd2 is generated by the idle I/O port B being connected to the upstream module. Both handles have corresponding read/write events, so these two handles can be used to forward the communication data. The specific communication data forwarding steps are as follows:

(1) Reading the handle fd1: After the idle I/O port A establishes a connection with the upstream module, a read operation is performed on the handle fd1 to read the request data from the upstream module.

(2) Writing to the handle fd2: The request data read from the upstream module is written to the downstream module through the handle fd2 of the idle I/O port B.

(3) Reading the handle fd2: after receiving the corresponding request data and processing the request, the downstream module returns the corresponding response data to the handle fd2, and at this time, the read operation of the handle fd2 is read from the downstream module. Take response data.

(4) Writing to the handle fd1: The response data returned by the downstream module is forwarded to the upstream module by writing to the handle fd1.

S52: Test the target test module based on the communication data, and obtain the test result.

Test the target test module according to the target test type and select the corresponding communication data to obtain the test result. For example, if the test type is performance test, the communication data sent to the target test module by the pressure test tool and the recorded upstream module can be used to apply pressure to the tested module, and monitor the running state of the target test module and various performance indicators. And analyze it and finally get the test results. Among them, the pressure measuring tool refers to a tool for performing a pressure test.

In this embodiment, the communication data corresponding to the target test module is recorded according to the target test type, and the target test module is tested according to the recorded communication data to obtain the test result. While ensuring the convenience of distributed system testing, there is no need to simulate a distributed system environment, which saves time spent on environmental preparation during the test process, and also saves a lot of machine resources and improves the test efficiency of the distributed system. .

In a specific implementation manner, based on the target test type, the communication data of the target test module is recorded, as shown in FIG. 4, specifically including the following steps:

S511: If the target test type is a performance test, send the test data to the upstream module.

Among them, performance testing is to test various performance indicators of the system through automated test tools to simulate a variety of normal, peak and abnormal load conditions. Both load testing and stress testing are performance tests, and the two can be combined. Through the load test, the performance of the system under various workloads is determined, that is, the changes of various performance indicators of the system when the load is gradually increased. Stress testing is done by determining a system bottleneck or an unacceptable performance point to get the maximum service level test that the system can provide.

Sending test data to the upstream module can use a pressure test tool to apply pressure to the upstream module. Among them, the pressure measuring tool refers to a tool for performing a pressure test. The stress test simulates the software and hardware environment of the actual application and the system load of the user's use process, and runs the test software for a long time or a large load to test the performance, reliability and stability of the system under test. Specifically, a pressure tool such as Webbench, Siege, or Http_load can be used to apply pressure to the upstream module.

S512: Record the upstream communication data sent by the upstream module to the target test module and the downstream communication data returned by the downstream module to the target test module.

After transmitting the test data to the upstream module, the upstream module sends the corresponding upstream communication data to the target test module based on the test data, and records the upstream communication data. Specifically, the upstream communication data can be saved to a corresponding upstream communication data file. After receiving the upstream communication data, the target test module will respond to the upstream communication data and perform related processing. After the processing is completed, the data will be sent to the corresponding downstream module, and the downstream module will return the downstream communication data accordingly. In the target test module, the downstream communication data is recorded. Specifically, the downstream communication data can be saved to a corresponding downstream communication data file.

In a specific embodiment, the communication data of the recording target test module further includes forwarding of the communication data. The specific forwarding step is similar to the forwarding of the communication data in step S51, and details are not described herein again.

In this embodiment, the test data is sent to the upstream module, thereby triggering data communication between different modules, and data recording is completed at the same time as data forwarding, which facilitates data acquisition in subsequent testing, and saves a large amount. Machine resources improve the convenience and efficiency of distributed system testing.

In a specific implementation manner, based on the target test type, the communication data of the target test module is recorded, as shown in FIG. 5, specifically including the following steps:

S511': If the target test type is a reliability test, the network abnormality test logic is injected into the communication link, and the predetermined link in the communication link is controlled by the control command to perform interaction.

Among them, the reliability test is the ability of the software system to complete the specified functions within the specified time and under the specified environmental conditions. In general, the reliability of a software system is measured by testing it. Generally, the reliability is measured in two ways: (1) under the specified conditions, the probability that the software does not cause the system to fail within the specified time; (2) the required execution under the predetermined conditions within the specified time period The ability to function.

In the reliability test, the network abnormality test logic is injected into the communication link taken over by the test system, and each communication link in the abnormal network condition is tested by controlling the command to control the predetermined link in the communication link to interact. The interaction data, so as to achieve the purpose of reliability testing. The network abnormality test logic refers to test logic that modifies specific network parameters and monitors key nodes. For example, the ability of distributed system load balancing largely determines the reliability of the system. For the system load balancing test, it includes two dimensions of the equalization of node access frequency and the balance of node communication data volume. In the test of access frequency equalization, some identification information can be inserted into the source code, and the frequency of accessing each node of the system can be analyzed by sending pressure and counting these identifiers. In the test of node communication data balance, the performance data of each server is recorded when the pressure is sent, and the performance data of the network card is analyzed to test whether the hot data is dispersed evenly.

Specifically, the injection of network abnormality test logic can be implemented by using a hook technique. That is, replace the function called in the program under test, and populate the function containing the test logic. There are two main types of functions that are replaced:

(1) For the functions such as strcmp and fopen in the GNU C standard library, write the corresponding API and compile it into a so dynamic library. Specify the loading priority of the so dynamic library by setting the LD_PRELOAD environment variable to reach the original standard. The purpose of the library API.

(2) For the user-defined function, by modifying the symbol table to jump to the API containing the test logic, different test logic is encapsulated in a so file, using tools to control the loading.

In this embodiment, the abnormal test logic is added through the mechanism of the so, the code is highly universal, avoids frequent updates and adjustments, and the communication data can be conveniently recorded while forwarding the communication data packet, which can directly satisfy the reliability. Application requirements for data recording and testing during testing.

After injecting the network anomaly test logic in the takeover communication link, the predetermined link in the communication link is controlled by the control command to interact. For example, the control command may be embodied by the control target test module continuously transmitting communication data to each downstream module or sending pressure to the upstream module through the pressure measurement tool, and modifying the network parameters and real-time monitoring of the key nodes through the injected network abnormality test logic.

S512': recording an interaction data packet exchanged between predetermined links in the communication link and an abnormality test data packet passing through the network abnormality test logic.

In this step, the recording process of the interactive data packet for the interaction between the predetermined links in the communication link is similar to the step S512, and details are not described herein again. In the reliability test, when the data is recorded, the abnormal test data packet passing through the network abnormal test logic needs to be recorded and saved separately for analyzing the reliability of the distributed system.

For example, if some identification information is implanted in the source code, these identifiers are counted when interacting between predetermined links in the communication link to analyze the frequency of access by each node of the system. In the data volume balancing test, the performance of the network card performance data of each server is recorded when the pressure is transmitted, and the performance data of the network card is analyzed to test whether the hotspot data is dispersed uniformly. Further, by recording the interaction data packet between the predetermined links in the communication link, it can be analyzed whether network packet loss, data disorder or data tampering occurs when the network is abnormal.

In this embodiment, the network abnormality test logic is injected into the communication link, and the predetermined link in the communication link is controlled by the control command to interact and record the corresponding data packet, so as to better perform reliability later. Testing improves the convenience of distributed system testing.

It should be understood that the size of the sequence of the steps in the above embodiments does not mean that the order of execution is performed. The order of execution of each process should be determined by its function and internal logic, and should not be construed as limiting the implementation process of the embodiments of the present application.

Example 2

Fig. 6 is a block diagram showing the principle of a test apparatus of a distributed system corresponding to the test method of the distributed system in the first embodiment. As shown in FIG. 6, the test apparatus of the distributed system includes a distributed system test request acquisition module 10, a communication link data acquisition module 20, an idle time period acquisition module 30, and an adjustment test module 40. The implementation functions of the distributed system test request acquisition module 10, the communication link data acquisition module 20, the idle time period acquisition module 30, and the adjustment test module 40 correspond to the steps corresponding to the test method of the distributed system in Embodiment 1. In order to avoid redundancy, the present embodiment will not be described in detail.

The distributed system test request obtaining module 10 is configured to obtain a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time.

The communication link data acquiring module 20 is configured to acquire communication link data of the target test module, where the communication link data includes the number of target I/O ports.

The idle time period obtaining module 30 is configured to acquire and display the number of idle I/O ports that are greater than or equal to the number of target I/O ports if the number of target I/O ports is greater than or equal to the number of idle I/O ports in the target test time. Free time period.

The adjustment test module 40 is configured to obtain an adjustment test time. If the current system time reaches the adjustment test time, the communication link of the target test module is taken over, and the target test module is tested based on the target test type.

Preferably, the test device of the distributed system further includes a target test module 50.

The target test module 50 is configured to take over the communication link of the target test module when the current system time reaches the target test time, if the number of target I/O ports is less than the number of idle I/O ports in the target test time, based on the target test. The type tests the target test module.

Preferably, the adjustment test module 40 includes a port listening unit 41 and a communication link establishing unit 42.

The port monitoring unit 41 is configured to start port monitoring on the target test module.

The communication link establishing unit 42 is configured to establish a communication link between the target test module and the upstream module and between the target test module and the downstream module based on the idle I/O port.

Preferably, the adjustment test module 40 further includes a communication data recording unit 51 and a test result acquisition unit 52.

The communication data recording unit 51 is configured to record communication data of the target test module based on the target test type.

The test result obtaining unit 52 is configured to test the target test module based on the communication data, and obtain the test result.

Preferably, the communication data recording unit 51 includes a test data transmitting subunit 511 and a performance test data recording subunit 512.

The test data sending subunit 511 is configured to send the test data to the upstream module if the target test type is a performance test.

The performance test data recording sub-unit 512 is configured to record upstream communication data sent by the upstream module to the target test module and downstream communication data returned by the downstream module to the target test module.

Preferably, the communication data recording unit 51 further includes an interactive data transmitting subunit 511' and a reliability test data recording subunit 512'.

The interactive data transmitting subunit 511' is configured to inject network abnormality testing logic into the communication link if the target test type is a reliability test, and control the predetermined link in the communication link to perform interaction through the control command.

The reliability test data recording sub-unit 512' is configured to record an interaction data packet exchanged between predetermined links in the communication link and an abnormality test data packet passing through the network abnormality test logic.

Preferably, in the target test module 50, the communication link of the target test module is taken over, and the specific implementation unit/subunit that is tested on the target test module based on the target test type is consistent with the adjustment test module 40, and details are not described herein again.

Example 3

The present embodiment provides one or more non-volatile readable storage media having computer readable instructions that are executed by one or more processors such that the one or more processors perform as implemented The test method of the distributed system in Example 1 is not repeated here to avoid repetition. Alternatively, when the computer readable instructions are executed by one or more processors, the one or more processors implement the functions of the modules/units in the test device of the distributed system of Embodiment 2, to avoid repetition, here is not Let me repeat.

It is to be understood that the non-volatile readable storage medium may include any entity or device capable of carrying the computer readable instruction code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, only Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier signals, and telecommunications signals.

Example 4

FIG. 7 is a schematic diagram of a computer device according to an embodiment of the present application. As shown in FIG. 7, computer device 60 of this embodiment includes a processor 61, a memory 62, and computer readable instructions 63 stored in memory 62 and executable on processor 61. The processor 61 executes the steps of the test method of the distributed system in the first embodiment, such as steps S10 to S40 shown in FIG. 1, when the computer readable instructions 63 are executed. Alternatively, when the processor 61 executes the computer readable instructions 63, the functions of the modules/units in the testing device of the distributed system in the second embodiment are implemented, for example, the distributed system test request obtaining module 10 and the communication link data shown in FIG. The functions of the acquisition module 20, the idle time period acquisition module 30, and the adjustment test module 40 are obtained.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the division of each functional unit and module described above is exemplified. In practical applications, the above functions may be assigned to different functional units as needed. The module is completed by dividing the internal structure of the device into different functional units or modules to perform all or part of the functions described above.

The above-mentioned embodiments are only used to explain the technical solutions of the present application, and are not limited thereto; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still implement the foregoing embodiments. The technical solutions described in the examples are modified or equivalently replaced with some of the technical features; and the modifications or substitutions do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in Within the scope of protection of this application.

Claims (20)

A testing method for a distributed system, comprising the steps of: Obtaining a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time; Obtaining communication link data of the target test module, where the communication link data includes a number of target I/O ports; If the number of the target I/O ports is greater than or equal to the number of idle I/O ports in the target test time, obtain and display the idle time that the number of idle I/O ports is greater than or equal to the number of the target I/O ports. segment; Obtaining an adjustment test time, if the current system time reaches the adjustment test time, taking over the communication link of the target test module, and testing the target test module based on the target test type. The method for testing a distributed system according to claim 1, wherein after said step of acquiring communication link data of said target test module, said communication link data includes a number of target I/O ports, The testing method of the distributed system further includes: If the number of target I/O ports is less than the number of idle I/O ports during the target test time, when the current system time reaches the target test time, the communication link of the target test module is taken over, based on The target test type is tested on the target test module. The method for testing a distributed system according to claim 1 or 2, wherein the taking over the communication link of the target test module comprises the following steps: Start port monitoring for the target test module; Establishing a communication link between the target test module and the upstream module and between the target test module and the downstream module based on the idle I/O port. The testing method of the distributed system according to claim 3, wherein the testing the target test module based on the target test type comprises the following steps: Recording communication data of the target test module based on the target test type; The target test module is tested based on the communication data to obtain test results. The method for testing a distributed system according to claim 4, wherein the recording the communication data of the target test module based on the target test type comprises the following steps: Sending test data to the upstream module if the target test type is a performance test; The upstream communication data sent by the upstream module to the target test module and the downstream communication data returned by the downstream module to the target test module are recorded. The method for testing a distributed system according to claim 4, wherein the recording the communication data of the target test module based on the target test type comprises the following steps: If the target test type is a reliability test, injecting network abnormality test logic into the communication link, and controlling a predetermined link in the communication link to perform interaction by using a control command; An interaction data packet that interacts between predetermined links in the communication link and an abnormality test data packet that passes through the network abnormality test logic are recorded. A testing device for a distributed system, comprising: a distributed system test request obtaining module, configured to obtain a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time; a communication link data acquiring module, configured to acquire communication link data of the target test module, where the communication link data includes a number of target I/O ports; An idle time period obtaining module, configured to acquire and display the number of idle I/O ports greater than or equal to the target if the number of target I/O ports is greater than or equal to the number of idle I/O ports during the target test time The idle time period of the number of I/O ports; The test module is configured to obtain an adjustment test time. If the current system time reaches the adjustment test time, the communication link of the target test module is taken over, and the target test module is tested based on the target test type. The testing device of the distributed system according to claim 7, wherein the adjustment test module comprises: a port monitoring unit, configured to start port monitoring on the target test module; And a communication link establishing unit, configured to establish a communication link between the target test module and the upstream module and between the target test module and the downstream module based on the idle I/O port. A computer device comprising a memory, a processor, and computer readable instructions stored in the memory and operative on the processor, wherein the processor executes the computer readable instructions as follows step: Obtaining a distributed system test request, where the distributed system test request includes a target test module, a target test type, and a target test time; Obtaining communication link data of the target test module, where the communication link data includes a number of target I/O ports; If the number of the target I/O ports is greater than or equal to the number of idle I/O ports in the target test time, obtain and display the idle time that the number of idle I/O ports is greater than or equal to the number of the target I/O ports. segment; Obtaining an adjustment test time, if the current system time reaches the adjustment test time, taking over the communication link of the target test module, and testing the target test module based on the target test type. The computer apparatus according to claim 9, wherein said processor after said step of acquiring communication link data of said target test module, said communication link data comprising a number of target I/O ports The following steps are also implemented when the computer readable instructions are executed: If the number of target I/O ports is less than the number of idle I/O ports during the target test time, when the current system time reaches the target test time, the communication link of the target test module is taken over, based on The target test type is tested on the target test module. The computer device according to claim 9 or 10, wherein the taking over the communication link of the target test module comprises the following steps: Start port monitoring for the target test module; Establishing a communication link between the target test module and the upstream module and between the target test module and the downstream module based on the idle I/O port. The computer device according to claim 11, wherein said testing said target test module based on said target test type comprises the following steps: Recording communication data of the target test module based on the target test type; The target test module is tested based on the communication data to obtain test results. The computer device according to claim 12, wherein the recording the communication data of the target test module based on the target test type comprises the following steps: Sending test data to the upstream module if the target test type is a performance test; The upstream communication data sent by the upstream module to the target test module and the downstream communication data returned by the downstream module to the target test module are recorded. The computer device according to claim 12, wherein the recording the communication data of the target test module based on the target test type comprises the following steps: If the target test type is a reliability test, injecting network abnormality test logic into the communication link, and controlling a predetermined link in the communication link to perform interaction by using a control command; An interaction data packet that interacts between predetermined links in the communication link and an abnormality test data packet that passes through the network abnormality test logic are recorded. One or more non-transitory readable storage mediums storing computer readable instructions, when executed by one or more processors, cause the one or more processors to perform the following steps: Obtaining a distributed system test request including a target test module, a target test type, and a target test time; Obtaining communication link data of the target test module, where the communication link data includes a number of target I/O ports; If the number of the target I/O ports is greater than or equal to the number of idle I/O ports in the target test time, obtain and display the idle time that the number of idle I/O ports is greater than or equal to the number of the target I/O ports. segment; Obtaining an adjustment test time, if the current system time reaches the adjustment test time, taking over the communication link of the target test module, and testing the target test module based on the target test type. The non-volatile readable storage medium according to claim 15, wherein in said obtaining communication link data of said target test module, said communication link data includes a number of target I/O ports Thereafter, the computer readable instructions are executed by one or more processors such that the one or more processors further perform the following steps: If the number of target I/O ports is less than the number of idle I/O ports during the target test time, when the current system time reaches the target test time, the communication link of the target test module is taken over, based on The target test type is tested on the target test module. The non-volatile readable storage medium according to claim 15 or 16, wherein the taking over the communication link of the target test module comprises the following steps: Start port monitoring for the target test module; Establishing a communication link between the target test module and the upstream module and between the target test module and the downstream module based on the idle I/O port. The non-volatile readable storage medium according to claim 17, wherein said testing said target test module based on said target test type comprises the following steps: Recording communication data of the target test module based on the target test type; The target test module is tested based on the communication data to obtain test results. The non-volatile readable storage medium according to claim 18, wherein said recording the communication data of the target test module based on the target test type comprises the following steps: Sending test data to the upstream module if the target test type is a performance test; The upstream communication data sent by the upstream module to the target test module and the downstream communication data returned by the downstream module to the target test module are recorded. The non-volatile readable storage medium according to claim 18, wherein said recording the communication data of the target test module based on the target test type comprises the following steps: If the target test type is a reliability test, injecting network abnormality test logic into the communication link, and controlling a predetermined link in the communication link to perform interaction by using a control command; An interaction data packet that interacts between predetermined links in the communication link and an abnormality test data packet that passes through the network abnormality test logic are recorded.

Images