CN111752850B

CN111752850B - Method and related equipment for testing block chain system

Info

Publication number: CN111752850B
Application number: CN202010672078.3A
Authority: CN
Inventors: 陈金龙
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-07-13
Filing date: 2020-07-13
Publication date: 2021-08-20
Anticipated expiration: 2040-07-13
Also published as: CN111752850A

Abstract

An embodiment of the present application provides a method for testing a block chain system, including: acquiring scene information configured for a memory overflow scene, wherein the scene information comprises scene parameters and node identifiers; controlling the node indicated by the node identification to perform memory overflow simulation according to the scene parameters so as to simulate the memory overflow scene in the block chain system; acquiring an execution result of the block chain system executing a normal test case under the scene of memory overflow; and determining the test result of the block chain system under the memory overflow scene according to the execution result, so that the test of the block chain system under the memory overflow scene is realized.

Description

Method and related equipment for testing block chain system

Technical Field

The present disclosure relates to the field of blockchain technologies, and in particular, to a method and related device for testing a blockchain system.

Background

Based on the Byzantine consensus fault-tolerant mechanism in the blockchain system, even if a certain node in the blockchain system is down, and the memory is overflowed or is bad, the whole blockchain system can still normally operate.

In the case of node exception, memory overflow often makes node service unavailable, response timeout, and finally makes the node blocked. Although the Byzantine consensus fault-tolerant mechanism in the blockchain-based system can ensure that the blockchain system can still operate normally when a part of nodes with memory overflow exist in the blockchain system, the influence of the nodes with memory overflow on the performance of the blockchain system is still unclear. The related art does not propose a scheme for testing the performance impact of memory overflow on the blockchain system.

Disclosure of Invention

The embodiment of the application provides a testing method and related equipment for a block chain system, and further the block chain system can be tested in a memory overflow scene at least to a certain extent.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned by practice of the application.

According to an aspect of the embodiments of the present application, there is provided a method for testing a blockchain system, the blockchain system including a plurality of nodes, the method including: acquiring scene information configured for a memory overflow scene, wherein the scene information comprises scene parameters and node identifiers; controlling the node indicated by the node identification to perform memory overflow simulation according to the scene parameters so as to simulate the memory overflow scene in the block chain system; acquiring an execution result of the block chain system executing a normal test case under the scene of memory overflow; and determining a test result of the block chain system under the memory overflow scene according to the execution result.

According to an aspect of the embodiments of the present application, there is provided a testing apparatus for a blockchain system, the blockchain system including a plurality of nodes, the apparatus including: the system comprises a scene information acquisition module, a node identification acquisition module and a data processing module, wherein the scene information acquisition module is used for acquiring scene information configured for a memory overflow scene, and the scene information comprises scene parameters and node identifications; the memory overflow simulation module is used for controlling the node indicated by the node identifier to perform memory overflow simulation according to the scene parameters so as to simulate the memory overflow scene in the block chain system; the execution result acquisition module is used for acquiring the execution result of the block chain system executing the normal test case under the scene of memory overflow; and the test result determining module is used for determining the test result of the block chain system under the scene of memory overflow according to the execution result.

According to an aspect of an embodiment of the present application, there is provided an electronic device including: a processor; and a memory having computer readable instructions stored thereon which, when executed by the processor, implement the method as described above.

According to an aspect of embodiments of the present application, there is provided a computer-readable storage medium having stored thereon computer-readable instructions which, when executed by a processor, implement a method as described above.

In the scheme of the application, the scene information configured for the memory overflow scene is used for controlling the node indicated by the node identifier in the scene information to simulate the memory overflow according to the scene parameters in the scene information, so that the simulation of the memory overflow scene is realized. And then, on the basis of the simulated memory overflow scene in the block chain system, combining the execution of the test case to obtain the execution result of the test case in the memory overflow scene of the block chain system, and determining the test result of the block chain system in the memory overflow scene according to the execution result, so that the test of the block chain system in the memory overflow scene is realized.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

In the drawings:

FIG. 1 shows a schematic diagram of an exemplary system architecture to which aspects of embodiments of the present application may be applied;

FIG. 2 shows a schematic diagram of a blockchain;

FIG. 3 is a flow diagram illustrating a method for testing a blockchain system according to one embodiment;

FIG. 4 is a flow diagram of step 340 of the corresponding embodiment of FIG. 3 in one embodiment;

FIG. 5 is a flow diagram of step 340 of the corresponding embodiment of FIG. 3 in another embodiment;

FIG. 6 is a flow diagram of step 340 of the corresponding embodiment of FIG. 3 in another embodiment;

FIG. 7 is a block diagram illustrating a test framework in accordance with a particular embodiment;

FIG. 8 is a flow diagram illustrating a method of testing a blockchain system in accordance with one embodiment;

FIG. 9 is a timing diagram illustrating the functional modules in the test framework implementing blockchain system testing;

FIG. 10 is an on-line flow diagram of a blockchain system, according to one embodiment;

FIG. 11 illustrates a block diagram of a test apparatus of a blockchain system, according to one embodiment;

FIG. 12 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product services layer, and an application services layer.

The block chain system comprises the following data processing flows: (1) the client sends the transaction to the node, and the node broadcasts the transaction to other nodes through the P2P network; (2) a consensus mechanism randomly selects a billing node; (3) the accounting node packs and assembles a plurality of transaction lists into a block structure and broadcasts the block structure to other nodes; (4) after receiving the block, other nodes verify the transaction in the block and broadcast voting information; (5) after the consensus is achieved for the block, the block is committed to the blockchain storage layer and the next round of election and consensus begins.

In order to achieve the purpose of multi-center and non-falsification, a plurality of nodes in a typical blockchain system satisfy a certain fault tolerance mechanism, which is usually a byzantine consensus fault tolerance mechanism, that is, in a blockchain system composed of a plurality of nodes, if a certain node goes down, overflows or goes bad, the whole blockchain system can also normally operate, and of course, the influence on the operating state of the blockchain system caused by the abnormality must be reliably verified.

In the case of a typical node exception, memory overflow often renders the node service unavailable, response times out, and eventually the node blocks. Therefore, before the blockchain system comes online, the blockchain system needs to be tested for the condition that the memory overflow occurs in the node. In order to test the blockchain system under the condition that the memory overflow occurs in the node, the simulation of the memory overflow scene in the blockchain system needs to be simulated, so as to test the blockchain system under the memory overflow scene. However, in the related art, the scheme for simulating the memory overflow in the blockchain system has a problem of low efficiency, which further results in low test efficiency of the blockchain system. Accordingly, the present application is provided to solve the problems.

Fig. 1 shows a schematic diagram of an exemplary system architecture to which the technical solution of the embodiments of the present application can be applied.

As shown in fig. 1, the system architecture may include a communicatively connected test system 120 and a blockchain system 110, wherein the test system 120 may be composed of a terminal 121 and a server 122, wherein the terminal and the server establish a communication connection through a network or the like.

The terminal device 121 may be one or more of a smart phone, a tablet computer, and a portable computer, and may also be a desktop computer, etc.

The blockchain system 110 includes a plurality of nodes 101, a Peer-To-Peer (P2P) network is formed among the nodes 101, and the P2P Protocol is an application layer Protocol operating on a Transmission Control Protocol (TCP). In a blockchain system, any machine, such as a server or a terminal, can join the system to become a node.

In the blockchain system 110, each node 101 has a corresponding node identifier, and each pole can store the node identifiers of other nodes in the blockchain system, so that the generated block can be broadcast to other nodes in the blockchain system according to the node identifiers of other nodes. Each node may maintain a node identifier list as shown in table 1 below, and store the node name and the node identifier in the node identifier list correspondingly. The node identifier may be an IP (Internet Protocol) address and any other information that can be used to identify the node, and table 1 only illustrates the IP address as an example.

Node name	Node identification
		Node 1	117.114.151.174
Node 2	117.116.189.145
		…	…
Node N	119.123.789.258

TABLE 1

Each node in the blockchain system 110 stores the same blockchain. The block chain is composed of a plurality of blocks, referring to fig. 2, the block chain is composed of a plurality of blocks, the starting block includes a block header and a block main body, the block header stores an input information characteristic value, a version number, a timestamp and a difficulty value, and the block main body stores input information; the next block of the starting block takes the starting block as a parent block, the next block also comprises a block head and a block main body, the block head stores the input information characteristic value of the current block, the block head characteristic value of the parent block, the version number, the timestamp and the difficulty value, and the like, so that the block data stored in each block in the block chain is associated with the block data stored in the parent block, and the safety of the input information in the block is ensured.

In an embodiment of the application, a user may configure scene information corresponding to a memory overflow scene in a test system, and then the test system controls a node in a blockchain system according to the scene to perform memory overflow simulation, so as to simulate the memory overflow scene in the blockchain system. Furthermore, the block chain system can be controlled to execute the normal test case based on the test system, and the execution result of the normal test case is correspondingly obtained.

The implementation details of the technical solution of the embodiment of the present application are set forth in detail below:

FIG. 3 is a flow chart illustrating a method for testing a blockchain system according to one embodiment, which may be performed by the test system shown in FIG. 1, including the following

steps

310 and 340, which are described in detail below.

In step 310, scene information configured for a memory overflow scene is obtained, where the scene information includes scene parameters and a node identifier.

The node identification is used to indicate the node in the blockchain system that needs to simulate memory overflow. It can be understood that the node identifier in the scene information may be one or multiple, that is, in the memory overflow scene to be simulated, one node may be controlled to simulate memory overflow, or multiple nodes may be controlled to simulate memory overflow.

And the scene parameters are used for controlling the nodes corresponding to the node identifiers to carry out memory overflow simulation. In a specific embodiment, the scenario parameter may be an execution condition for performing memory overflow simulation, such as a trigger condition, a stop condition, and the like. In the case where the memory overflow simulation is performed in the set order, the scene parameter may be a simulation interval time or the like, and is not particularly limited herein.

In some embodiments of the present application, a configuration interface is further provided for configuring the context information, so that a user can configure the information in the configuration interface. Therefore, according to the configuration operation performed on the memory overflow scene, the scene information corresponding to the memory overflow scene is generated.

It can be understood that an entry for configuration is provided in the configuration interface, and based on the entry, a user can perform information input, node selection, and the like, so as to implement node identifier configuration and scene parameter configuration, and further obtain scene information corresponding to a memory overflow scene. It can be understood that different memory overflow scenarios have different corresponding scenario information, such as different scenario parameters and/or different node identifiers.

In step 320, the node indicated by the node identifier is controlled to perform memory overflow simulation according to the scene parameters, so as to simulate a memory overflow scene in the block chain system.

And performing memory overflow simulation, namely controlling the node indicated by the node identifier to perform memory request, so that the memory available for providing block chain service in the node indicated by the node identifier is reduced, and further the node indicated by the node identifier is subjected to memory overflow.

In one embodiment of the present application, memory overflow simulation is performed by an overflow simulation script. Specifically, the overflow simulation script is issued to the node, then the overflow simulation script is controlled to run, and the memory request is continuously performed to the node by running the overflow simulation script. The requested memory is occupied, so that the requested memory cannot be used for providing services to the outside, and correspondingly, the memory which can be used for providing services to the outside in the node is gradually reduced until the node overflows from the memory.

In some embodiments of the present application, the scenario parameters include execution conditions, and step 320 includes: and when the execution condition is met, the node indicated by the control node identification executes an overflow simulation script, and the overflow simulation script is used for making a memory request to the node.

In some embodiments of the present application, the execution condition includes a trigger condition and a stop condition, and correspondingly, when the trigger condition is satisfied, the node indicated by the control node identifier starts executing the overflow simulation script; and when the stop condition is met, the node indicated by the control node identification stops executing the overflow simulation script.

In some embodiments of the present application, the trigger condition may be a trigger time, and correspondingly, if the trigger time is reached, the overflow simulation script is started to be executed; correspondingly, the stop condition may be a stop time, and when the stop time is reached during execution of the overflow simulation script, execution of the overflow simulation script is stopped.

For this case, in order to implement the control of the execution of the overflow simulation script in the node according to the trigger time and/or the stop time in the execution condition, a timing task may be created according to the trigger time and the stop time, and it is understood that the timing task is related to the node identifier. In the subsequent process, the timed task trigger node corresponding to the trigger time by the node identifier starts to execute the overflow simulation script, and the timed task trigger node corresponding to the stop time by the node identifier stops executing the overflow simulation script.

In other implementations of the present application, the triggering condition may also be a first threshold set for a target parameter in the node, and the corresponding stopping condition may be a second threshold set for the target parameter in the node. The target parameter may be a Central Processing Unit (CPU) occupancy of the node, the first threshold in the trigger condition may be a lower threshold of the CPU occupancy, and the second threshold in the stop condition may be an upper threshold of the CPU occupancy. If the CPU occupancy rate in the node reaches the lower limit threshold value, starting to execute the overflow simulation script; and in the process of executing the overflow simulation script, calculating the CPU occupancy rate in the node in real time, and if the CPU occupancy rate reaches an upper limit threshold value, stopping executing the overflow simulation script. Of course, the target parameter may also be another parameter that characterizes the memory usage in the node, and is not specifically limited herein.

It is to be understood that, in order to perform the memory overflow simulation by executing the overflow simulation script, before step 320, the method further includes issuing the overflow simulation script to the node corresponding to the node identifier.

In an embodiment of the present application, to implement issuing of the overflow simulation script, before step 320, the method further includes: acquiring node information corresponding to the node identification, wherein the node information comprises a network address of a node; and issuing an overflow simulation script to the node indicated by the node identification according to the network address. The network address of the node may be an IP address. By the process of issuing the overflow simulation script according to the network address, it can be ensured that in step 320, the overflow simulation script exists in all the nodes indicated by the node identifiers included in the scene information, and further, the overflow simulation script can be executed according to the corresponding scene parameters.

In another embodiment of the present application, in order to ensure that the overflow simulation script is not required to be issued again when the required scene information changes, before step 320, node information of each node in the blockchain system may be obtained, and then the overflow simulation script is issued to each node in the blockchain system according to the network address indicated by the node information.

In the scheme of the application, the memory overflow scene corresponds to a period of time, and in the period of time of the memory overflow scene, the nodes indicated by the node identifiers in the scene information correspondingly perform memory overflow simulation according to the indication of the scene parameters. It should be noted that in the memory overflow scenario, a node indicated by a node identifier in the scenario information may perform memory overflow simulation according to a set time interval, and may perform memory overflow simulation continuously, depending on the scenario parameters in the scenario information.

Similarly, if the scene information includes multiple node identifiers, the multiple node identifiers may or may not perform memory overflow simulation simultaneously, for example, sequentially simulate memory overflow according to a set time sequence, and the time lengths of performing memory overflow simulation on the nodes indicated by the node identifiers may be the same or different, depending on the scene parameters in the scene information.

Step 330, obtaining the execution result of the block chain system executing the normal test case in the memory overflow scene.

The normal test case is a positive test case configured for testing the functionality of the blockchain system. As described above, the blockchain system functions such as broadcasting transactions (or other information requiring uplink), transaction verification, uplink transactions, etc. Therefore, the normal test case may be a normal test case configured for broadcast transaction, transaction verification, transaction uplink, and other functions.

The memory overflow scenario corresponds to a period of time, so that the execution of the normal test case by the blockchain system in the memory overflow scenario may be that the blockchain system executes the normal test case at any time point in the period of time corresponding to the memory overflow scenario. Of course, in a specific embodiment, multiple time points may be selected from a period of time corresponding to the memory overflow scenario to execute the normal test case, and multiple execution results are correspondingly obtained.

The execution result of the normal test case at least indicates that the normal test case is successfully or unsuccessfully executed in the blockchain system, and further, the execution result of the normal test case may also indicate an execution duration used for executing the normal test case in the blockchain system.

Step 340, determining a test result of the block chain system in the memory overflow scene according to the execution result.

According to the execution result of the normal test case executed by the blockchain system under the memory overflow scene, the operation condition of the blockchain system under the memory overflow scene can be correspondingly reflected, and the influence of the memory overflow scene on the operation state of the blockchain system can also be reflected.

In a specific embodiment, the influence of the memory overflow scenario on the operation state of the blockchain system may be reflected by the service performance degradation parameter, so that the service performance degradation parameter may be further calculated according to the execution result, and the service performance degradation parameter is used as one of the test results.

In other embodiments, the test result may also be a fault tolerance indicator in the blockchain system, so as to test the maximum number of nodes that are allowed to overflow the memory under the condition that the blockchain system provides the service normally. The test result may also be whether the Byzantine consensus mechanism in the blockchain system is in effect.

Of course, in the above exemplary embodiment, based on the difference of the parameters of the blockchain system to be tested in the memory overflow scenario, the test result may also be other parameters, and is not limited to the above listed service performance degradation parameter, fault tolerance index, bexaglit consensus mechanism, etc.

In some embodiments of the present application, after step 340, the method further comprises: and the control node marks the indicated node to execute a recovery script, and the recovery script is used for releasing the memory requested by the node.

The recovery script is executed by the control node to realize the memory requested by the node, so that the node can be recovered to the state before the overflow simulation script is executed.

In a specific embodiment, the recovery script may be issued to the node simultaneously with the overflow simulation script. Of course, in other embodiments, the recovery script may also be issued to the node as needed, and is not specifically limited herein.

In some embodiments of the present application, the executing condition includes a plurality of executing periods configured in time sequence for the same node identifier, and when the executing condition is satisfied, the node indicated by the control node identifier executes the overflow simulation script, including:

and respectively controlling the nodes indicated by the node identification to execute the overflow simulation script in the corresponding execution period according to the time sequence of the plurality of execution periods.

The overflow simulation script is executed by the node indicated by the node identifier according to the sequence of the execution periods, so that the same node is controlled to execute the overflow simulation script at intervals in sequence according to the set time sequence.

It is understood that during each of the plurality of execution periods, a portion of memory in the node is correspondingly requested by executing an overflow simulation script.

In the case of controlling a node to execute the overflow simulation script according to a set time sequence, when the node has memory overflow depends on the memory accumulated by executing the overflow simulation script during each execution period. In other words, after the overflow simulation script is executed in one execution period, the node does not necessarily have a memory overflow, but it is certain that after the overflow simulation script is executed in the previous execution period, the memory provided by the node is larger than the memory provided by the node after the simulation script is executed in the next execution period.

Based on the above execution conditions, the simulated memory overflow scenario is equivalent to memory overflow simulation for single-node multi-timing. Of course, in this process, an execution condition for executing the overflow simulation script in multiple timings may be configured for each of the plurality of nodes.

Then, based on the memory overflow simulation scenario constructed for the single-node multi-timing sequence, in the memory overflow scenario, after the overflow simulation script is executed in an execution period, the memory that can be provided in the node indicated by the node identifier is correspondingly reduced. Therefore, if the normal test cases are executed at the multiple time points in the memory overflow scenario, the influence of the size of the memory provided by the node on the performance of the blockchain system can be tested according to the execution results of the normal test cases executed at the multiple time points.

In an embodiment of the present application, the impact of the memory size in the node on the performance of the blockchain system can be tested by the following process.

Specifically, step 330 includes: acquiring a plurality of execution results obtained by executing a normal test case respectively at a plurality of time points of a block chain system in a memory overflow scene, wherein a plurality of execution periods are spaced by the plurality of time points; the execution results respectively indicate the execution time length for executing the normal test case at the corresponding time points.

For example, if the execution condition for the node a includes four sequentially arranged execution periods, which are T1, T2, T3, and T4, respectively, a time point K1 is selected after the overflow simulation script is executed by T1 in the execution period, a time point K2 is selected after the overflow simulation script is executed by T2 in the execution period, a time point K3 is selected after the overflow simulation script is executed by T3 in the execution period, a time point K4 is selected after the overflow simulation script is executed by T4 in the execution period, and normal test cases are executed at time points K1, K2, K3, and K4, respectively, so as to obtain four execution results for the memory overflow scenario.

In this case, the chronological order between the execution periods T1, T2, T3 and T4 and the four time points K1, K2, K3 and K4 is: t1, K1, T2, K2, T3, K3, T4, K4, i.e., four points in time, separate four execution periods.

Since the overflow simulation script is executed by all the nodes indicated by the node identifiers during the four executions, the situation that the memory is occupied in the nodes indicated by the node identifiers is different at the four time points K1, K2, K3 and K4. Specifically, the amount of memory available in the node indicated by the node identifier in the four time points is, from large to small: k1, K2, K3 and K4.

In this embodiment, as shown in fig. 4, step 340 includes:

step 410, acquiring a memory occupation parameter of a node indicated by a node identifier at each time point in a plurality of time points; and step 420, obtaining the execution duration indicated by the execution results respectively.

In step 430, the memory occupation parameter of the node indicated by each time node identifier and the execution duration respectively indicated by the execution results are used as the test result of the block chain system in the memory overflow scenario.

In this embodiment, the condition that the memory in the node is occupied is represented by the memory occupation parameter. In a specific embodiment, the memory usage parameter may be CPU usage, occupied memory amount, remaining running memory amount, and the like, which is not specifically limited herein.

As described above, since the memory usage of the node indicated by the node identifier at each time point is different, the memory usage parameter of the node indicated by the node identifier at each time point is different.

In a computer device, the situation that the memory is occupied directly affects the processing efficiency of the computer device. Similarly, in a node, the memory usage of the node is directly related to the data processing efficiency of the node. In the process of executing the normal test case by the block chain system, the efficiency of data processing by the nodes directly influences the execution time for executing the normal test case. It is understood that the execution time starts to execute the normal test case until the block chain system outputs the execution result of the program test case.

In view of this, the execution duration respectively indicated by the multiple execution results and the memory occupation parameter of each time point node in the multiple time points are used as the test result of the blockchain system in the memory overflow scenario, so that the influence of the memory occupation condition of the nodes in the blockchain system on the performance of the blockchain system can be analyzed through the multiple execution durations and the corresponding relationship among the multiple memory occupation parameters, the execution duration and the memory occupation parameters, and the performance of the blockchain system can be embodied through the execution duration used by the blockchain system to execute the normal test case.

In another embodiment of the present application, the test result includes a fault tolerance indicator, the scenario information includes a plurality of node identifiers, and step 330 includes: and acquiring a plurality of execution results of the block chain system executing the program test case at a plurality of time points under the scene of memory overflow.

In this embodiment, step 340 includes: acquiring the number of memory overflow nodes of a block chain system at each time point in a plurality of time points; and determining the maximum quantity of the memory overflow nodes as the fault-tolerant index of the block chain system under the memory overflow scene in the execution result indicating the successful execution of the normal test case.

Based on the fault-tolerant consensus mechanism configured in the blockchain system, even if a small number of unavailable nodes exist in the blockchain system, for example, the unavailable nodes caused by memory overflow, the blockchain system can still operate normally and provide services for the outside. However, if the occurrence of the memory overflow causes a large number of unavailable nodes, which exceeds the maximum fault-tolerant node number defined by the fault-tolerant consensus mechanism, the blockchain system still cannot operate, i.e., cannot provide services to the outside normally. The maximum fault-tolerant node number is the fault-tolerant index of the block chain system.

Therefore, in order to fully understand the condition that the blockchain system provides external services, before the blockchain system comes online, it is necessary to test and determine the fault tolerance of the blockchain system in the memory overflow scenario.

Under the condition that the scene information corresponding to the memory overflow scene comprises a plurality of node identifiers, the nodes indicated by the plurality of node identifiers in the memory overflow scene can simulate the memory overflow at the same time or simulate the memory overflow at different times. In this embodiment, in order to measure the fault-tolerant index of the blockchain system in the memory overflow scenario, the fault-tolerant index is tested by constructing a memory overflow scenario in which a plurality of nodes stagger and simulate memory overflow.

Specifically, in the context information, an execution period may be configured for each node identifier, where in the context information, at least two node identifiers have different execution periods, which is equivalent to constructing a multi-time-sequence memory overflow context for a plurality of nodes. Under the scene of the memory overflow, a plurality of time points with different numbers of nodes with the memory overflow exist, and correspondingly, the normal test cases are respectively executed at the time points with different numbers of nodes with the memory overflow, so as to obtain corresponding execution results.

The number of memory overflow nodes refers to the number of nodes in the blockchain system where memory overflow occurs. By acquiring the number of memory overflow nodes of the block chain system at each time point in a plurality of time points, the memory overflow condition of the block chain system at each time point at the plurality of time points can be correspondingly known.

In one embodiment, the number of memory overflow nodes present in the blockchain system at each of a plurality of time points may be determined from a log of operations of each node in the blockchain system. The running log of the node records the memory overflow simulation condition in the node and the condition that the node executes the normal test case, when the memory required for executing the normal test case is larger than the available memory in the node, the node is abnormally blocked, so that the node is unavailable, and at the moment, the memory overflow of the node occurs. And corresponding operation logs are correspondingly generated when the nodes are abnormally blocked in the whole process, so that whether the nodes have memory overflow or not can be correspondingly determined through the operation logs of the nodes, and the number of the memory overflow nodes in the block chain system is further determined.

As described above, the fault tolerance indicator is the maximum number of fault tolerant nodes that the blockchain system can normally provide service. If an execution result indicates that the normal test case is successfully executed, it indicates that the blockchain system can normally provide services during the execution period of the test case, and further indicates that the number of memory overflow nodes in the blockchain system does not exceed the fault tolerance index during the period.

Therefore, in order to determine the fault-tolerant index of the blockchain system in the memory overflow scene, statistics are performed corresponding to the execution results indicating normal execution of the normal test cases in the plurality of execution results, and the fault-tolerant index of the blockchain system in the memory overflow scene is determined by the maximum number of the memory overflow nodes.

It is understood that, because of the limited number of nodes that are constructed to experience memory overflow in a memory overflow scenario, the fault tolerance measured in a memory overflow scenario is related to the memory overflow scenario. In order to further accurately determine the fault-tolerant indicator of the blockchain system, the fault-tolerant indicator of the blockchain system under multiple memory overflow scenarios may be determined comprehensively, for example, a maximum fault-tolerant indicator of the multiple fault-tolerant indicators of the blockchain system under multiple memory overflow scenarios is determined as the fault-tolerant indicator of the blockchain system.

In another embodiment of the present application, the test result includes a consensus test result, as shown in fig. 5, step 340 includes:

step 510, obtaining a running log of each node in the blockchain system.

Step 520, determining the number of memory overflow nodes and the number of normal nodes in the block chain system when the normal test case is executed in the memory overflow scene according to the running log.

Step 530, if the number of the memory overflow nodes and the number of the normal nodes satisfy the target number relationship and the execution result indicates that the normal test case is successfully executed, determining that the consensus test result is that the Byzantine fault-tolerant consensus mechanism is effective, wherein the target number relationship is defined by the Byzantine fault-tolerant consensus mechanism configured in the block chain system.

The normal node number refers to the number of nodes that operate normally in the blockchain system.

In the embodiment, the Byzantine fault tolerant consensus mechanism is configured in the blockchain system. Under the condition of memory overflow, when the number of normal nodes in the block chain system and the number of memory overflow nodes meet the following relationship: when N is more than or equal to 3t +1 (wherein N is the number of normal nodes, and t is the number of nodes with memory overflow), the Byzantine consensus mechanism takes effect. As shown above, the relationship between the number of normal nodes and the number of memory overflow nodes is as follows: n is more than or equal to 3t +1, namely the target quantity relation limited by the configured Byzantine consensus mechanism in the block chain system.

On the contrary, in the block chain system, if the normal node number and the memory overflow node number do not satisfy the target number relationship, the byzantine consensus mechanism is not satisfied, and correspondingly, the block chain system is not available, and the normal test case fails to be executed.

When the Byzantine consensus mechanism is effective, the block chain system normally operates, so that a normal test case can be successfully executed.

Therefore, in this embodiment, when the execution result indicates that the normal test case is successfully executed, and the number of the memory overflow nodes and the number of the normal nodes satisfy the target number relationship during the time when the block chain system executes the normal test case corresponding to the execution result, it is determined that the consensus test result is that the byzantine consensus mechanism is effective.

In another embodiment of the present application, the test result includes a service performance degradation parameter, and the execution result includes an execution duration used for executing a normal test case, as shown in fig. 6, step 340 includes:

step 610, obtaining a reference execution result of the block chain system executing the normal test case when the memory overflow scene is not simulated, where the reference execution result includes a reference execution time length for executing the normal test case.

Step 620, calculating a service performance degradation parameter of the blockchain system in the memory overflow scene according to the execution duration and the reference execution duration.

The reference execution result refers to an execution result obtained when the block chain system executes a normal test case when any memory overflow scene is not simulated.

The reference execution time length refers to the execution time length for the block chain system to execute the normal test case when any memory overflow scene is not simulated.

It can be understood that, when any memory overflow scenario is not simulated, there is no node simulating memory overflow in the blockchain system, in other words, in this case, the memory of each node in the blockchain system is not additionally occupied, so that the reference execution time length for the blockchain system to execute the normal test case in this case represents the service performance of the blockchain system in the non-simulated memory overflow scenario.

Correspondingly, the execution duration for executing the normal test case by the blockchain system under the memory overflow scene represents the service performance of the blockchain system when executing the normal test case under the memory overflow scene.

The service performance degradation parameter is used for representing the difference of the service performance of the blockchain system in the memory overflow scene compared with the service performance of the blockchain system in the non-simulated memory overflow scene.

Specifically, the service performance of the blockchain system can be reflected by the execution time length (referred to as the execution time length) used by the blockchain system to execute the normal test case. Thus, in the present embodiment, the calculation of the service performance degradation parameter is performed based on the execution time length indicated by the execution result obtained in the memory overflow scenario and the reference execution time length.

In a specific embodiment, the service performance degradation parameter may be a difference between the execution time length and the reference execution time length, or may be a quotient obtained by dividing the difference between the execution time length and the reference execution time length by the reference execution time length.

As described above, the memory overflow scenario corresponds to a period of time, and in the period of time of the memory overflow scenario, the situation of performing the memory overflow simulation on the node of the blockchain system may change based on different scenario parameters, for example, the memory overflow scenario configured for the node to perform the memory overflow simulation according to the set time sequence. Therefore, under a memory overflow scene, a plurality of time points can be selected to execute the normal test case in the block chain system, and a plurality of execution results can be correspondingly obtained. Then, the service performance degradation parameter is calculated based on the execution time length indicated by each execution result and the reference execution time length, respectively.

In another embodiment, the execution duration in the execution result and the execution duration in the reference execution result may also be directly used as the test result, so that a user can analyze the influence of different memory overflow scenarios on the execution duration by combining multiple execution durations.

In some embodiments of the present application, after step 340, the method further comprises: acquiring an execution log of each node in a block chain system; and generating a test report of the block chain system under the memory overflow scene according to the execution result, the test result and the execution log.

And the problem positioning of an analyst is facilitated by generating a test report. For example, if the test result of the test blockchain system does not satisfy the set requirement, the problem may be located by analyzing the execution result and the test result in the test report and the execution log of each node.

The method of the present disclosure is specifically described below with reference to a specific example.

In this embodiment, a test frame is constructed for testing the blockchain system in the scene of memory overflow, so as to simulate the scene of memory overflow based on the test frame, and further control the blockchain system to execute a normal test case in the scene of memory overflow, so as to implement the test of the blockchain system. In this embodiment, the test framework is in communication connection with the blockchain system, and the test framework provides a configuration interface for a user, so that the user can configure information related to the memory overflow scenario in the configuration page.

Fig. 7 shows a block diagram of the test framework. As shown in fig. 7, the test framework includes a presentation layer 710, a communication layer 720, an application layer 730, a tool layer 740, and a storage layer 750.

Presentation layer 710, which is used to interact with the user, is the front-end entry of the test framework. In the presentation layer, the configuration of the memory overflow scenario related information may be performed, for example, selecting a node, configuring a scenario parameter, and the like. In addition, at the presentation level, the user may also trigger execution of the overflow simulation script in the node. Furthermore, the display layer also provides cluster management, node management, fault management and task management functions, through the cluster management functions, a user can set a block chain system to be tested, and through the node management, the user can set information of nodes in the block chain system. The task management is used for managing the test task to be performed by the user.

The test framework can simulate abnormal conditions such as disk abnormality besides the abnormality of memory overflow, so that a user can select the abnormal conditions to be simulated based on the fault management function.

The communication layer 720 provides an API Interface (also called Application Programming Interface) for calling a service, and is responsible for transmitting an instruction sent by the front end to the server and calling back a result of the reporting processing.

The application layer 730 comprises a fault Server and a fault Agent, wherein the fault Server is used for receiving a request from an upper layer, performing initialization configuration on a memory overflow Agent script to be issued, and then sending an execution instruction to the fault Agent; the fault Agent comprises various fault atomic operations and is responsible for directly running a fault script, recording a fault log and reporting a processing result.

The tool layer 740 contains various execution scripts and auxiliary tools (e.g., timing recovery tools, loop execution tools, etc.). The storage layer 750 is mainly used for data storage, and MySQL is provided therein for managing stored data. The data stored in the storage layer mainly comprises fault logs, task reports, flow information, heartbeat data and the like.

Based on the test framework of fig. 7, the testing of the blockchain system can be performed according to the flow chart shown in fig. 8. As shown in fig. 8, the testing method of the blockchain system includes the following steps:

step 810, submitting the node information. The node information corresponds to a node in the block chain system, and the node information corresponding to the node may be an IP address, a port, a user name, and a user password corresponding to the node, where the user password is encrypted and stored in order to ensure security. The submitted node information is used for the test framework to log in the blockchain system and is used for issuing overflow simulation scripts, recovery scripts and the like to nodes in the blockchain system;

in step 820, the exception type, memory overflow exception, is selected. The test framework can be used for simulating various exceptions, such as disk exceptions and the like, so that in order to simulate a memory overflow scene, a memory overflow exception is selected, and a corresponding overflow simulation script and a corresponding recovery script are further acquired for the memory overflow exception.

And step 830, configuring information. And the user configures the information related to the memory overflow scene on the configuration interface of the test frame, so that the test frame generates scene information according to the information configuration performed by the user for the memory overflow scene. The information configuration may be node information corresponding to a single-node multi-timing memory overflow scenario configuration, multiple execution periods in the timing sequence, and interval time between adjacent execution periods, or node information corresponding to multiple nodes configured for a multi-node multi-timing memory scenario, a trigger timing sequence corresponding to each node in the timing sequence, and the like.

Step 840, an exception execution is triggered. At this time, the test framework issues an indication signal to a node corresponding to the selected memory overflow scenario, so as to control the node indicated by the node identifier in the scenario information to execute the overflow simulation script according to the scenario parameters in the scenario information configured for the memory overflow scenario, so as to simulate the memory overflow scenario, and record the running log generated in the execution process into a directory specified by the node, thereby facilitating subsequent query.

As shown in fig. 8, the memory overflow scenario involves performing memory overflow simulation on four nodes, namely node a, node B, node C, and node D.

Step 850, executing the normal test case. In the process of simulating the memory overflow scene, triggering the block chain system to execute the normal test case, so as to obtain the execution result of the block chain system executing the normal test case under the memory overflow scene.

The test framework further analyzes according to the execution result of the normal test case in the block chain system to determine a consensus test result. The determination process of the consensus test result is described in detail above and will not be described in detail herein.

Step 860, a test report is generated. The test framework generates a corresponding test report based on the consensus test result and the running log of the node, so that the problem positioning of a tester is facilitated.

FIG. 9 shows a timing diagram of the functional modules in the test framework implementing the blockchain system test. As shown in fig. 9, when a memory overflow scenario needs to be simulated, the fault agent deployment is implemented through steps 901-904, and then, in order to control a node in the block chain system to perform memory overflow simulation, the memory overflow simulation is implemented through the process 905-908. Specifically, after agent is started in step 905, step 906 is executed, that is, initialization is performed according to the configured scene information, a timing task is created according to the execution conditions in the scene parameters, then a start timer is executed, when the trigger time of the timer is reached, step 908 is executed, and correspondingly, the node performs memory overflow simulation and records a log. After the timer task is executed, the timer triggers recovery, step 909, and after the timer triggers recovery, the fault Server executes step 910 to update the pipeline, record the execution time, and return to the UI interface through steps 911-912.

If the operation flow query needs to be performed in the test framework, the operation flow can be obtained by the UI layer (presentation layer) through the API and the fault Server through the process of the step 913-915, and then the MySQL query to the storage layer and returned.

If the log query analysis needs to be summarized in the test framework, the process of step 916-.

Fig. 10 shows an online flow chart of the blockchain system, as shown in fig. 10, which includes three stages of blockchain product promotion 1010, exception testing 1020, and release 1030. In a block chain product test 1010 stage, after development of a block chain product is completed, simulation related in the block chain product is submitted to a REQ, the REQ performs distribution verification, and after the verification is passed, an exception test is performed on the block chain product. The REQ is a software development and instrumentation process management platform for managing software version development, instrumentation, defect submission, regression testing, and release of the entire lifecycle.

In the stage of the exception test 1020, the test is performed in a memory overflow scenario according to the method of the present application, including the processes of submitting relevant scenario parameters of the memory overflow test, registering node information of a block chain to be tested, simulating the memory overflow scenario, and executing a normal test case.

After the abnormal test is completed, the stage of issuing 1030 is entered, specifically including analyzing the consensus test result and the execution log, generating a test report, and then issuing the blockchain product on line.

Embodiments of the apparatus of the present application are described below, which may be used to perform the methods of the above-described embodiments of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method described above in the present application.

The present application provides a testing apparatus 1100 of a blockchain system, the testing apparatus 1100 of the blockchain system can be configured in the testing system shown in fig. 1, the blockchain system includes a plurality of nodes, as shown in fig. 11, the testing apparatus 1100 of the blockchain system includes:

the context information obtaining module 1110 is configured to obtain context information configured for a memory overflow context, where the context information includes a context parameter and a node identifier.

The memory overflow simulation module 1120 is configured to control the node indicated by the node identifier to perform memory overflow simulation according to the scene parameter, so as to simulate a memory overflow scene in the blockchain system.

The execution result obtaining module 1130 is configured to obtain an execution result of the block chain system executing the normal test case in the memory overflow scenario.

The test result determining module 1140 is configured to determine a test result of the blockchain system in a memory overflow scenario according to the execution result.

In an embodiment of the present application, the scene parameters include execution conditions, and the memory overflow simulation module 1120 is configured to: and when the execution condition is met, the node indicated by the control node identification executes an overflow simulation script, and the overflow simulation script is used for making a memory request to the node.

In an embodiment of the present application, the execution condition includes a trigger condition and a stop condition, and the memory overflow simulation module 1120 is further configured to: when the triggering condition is met, the node indicated by the control node identification starts to execute the overflow simulation script; and when the stop condition is met, the node indicated by the control node identification stops executing the overflow simulation script.

In an embodiment of the present application, the apparatus further includes: the node information acquisition module is used for acquiring node information corresponding to the node identifier, and the node information comprises a network address of the node; and the script issuing module is used for issuing the overflow simulation script to the node indicated by the node identification according to the network address.

In another embodiment of the present application, the execution condition includes a plurality of execution periods configured for the same node identifier and arranged according to a time sequence, and the memory overflow simulation module 1120 is configured to: and respectively controlling the nodes indicated by the node identification to execute the overflow simulation script in the corresponding execution period according to the time sequence of the plurality of execution periods.

In an embodiment of the present application, the execution result obtaining module 1130 is configured to: acquiring a plurality of execution results obtained by executing a normal test case respectively at a plurality of time points of a block chain system in a memory overflow scene, wherein a plurality of execution periods are spaced by the plurality of time points; the execution results respectively indicate the execution duration for executing the normal test case at the corresponding time points; in this embodiment, the test result determining module 1140 includes: the first obtaining unit is configured to obtain a memory usage parameter of a node indicated by a node identifier at each of a plurality of time points. And a second acquisition unit configured to acquire execution durations indicated by the plurality of execution results, respectively. And the test result determining unit is used for taking the memory occupation parameter of the node indicated by each time point node identifier and the execution duration respectively indicated by the execution results as the test result of the block chain system in the memory overflow scene.

In another embodiment of the present application, the test result includes a fault tolerance indicator, the scenario information includes a plurality of node identifiers, and the execution result obtaining module 1130 is configured to: and acquiring a plurality of execution results of the block chain system executing the program test case at a plurality of time points under the scene of memory overflow. In this embodiment, the test result determination module 1140 is configured to: acquiring the number of memory overflow nodes of a block chain system at each time point in a plurality of time points; and determining the maximum quantity of the memory overflow nodes as the fault-tolerant index of the block chain system under the memory overflow scene in the execution result indicating the successful execution of the normal test case.

In another embodiment of the present application, the test results include consensus test results, and the test result determination module 1140 includes: and the running log acquiring unit is used for acquiring the running logs of all the nodes in the block chain system. And the quantity determining unit is used for determining the quantity of memory overflow nodes and the quantity of normal nodes in the block chain system when the normal test case is executed under the memory overflow scene according to the running log. And the consensus test result determining unit is used for determining that the consensus test result is effective as a Byzantine fault-tolerant consensus mechanism if the memory overflow node number and the normal node number meet the target number relation and the execution result indicates that the normal test case is successfully executed, wherein the target number relation is limited by the Byzantine fault-tolerant consensus mechanism configured in the block chain system.

In an embodiment of the application, the test result includes a service performance degradation parameter, the execution result includes an execution duration for executing the normal test case, and the test result determining module 1140 includes: and the reference execution result acquisition unit is used for acquiring a reference execution result of the block chain system for executing the normal test case when the memory overflow scene is not simulated, wherein the reference execution result comprises a reference execution time length for executing the normal test case. And the service performance degradation parameter calculation unit is used for calculating the service performance degradation parameter of the block chain system under the scene of memory overflow according to the execution duration and the reference execution duration.

In an embodiment of the present application, the apparatus further includes: and the recovery script execution module is used for controlling the node indicated by the node identifier to execute the recovery script, and the recovery script is used for releasing the memory requested by the node.

In an embodiment of the present application, the apparatus further includes: and the scene information generating module is used for generating scene information corresponding to the memory overflow scene according to the configuration operation performed on the memory overflow scene.

In an embodiment of the present application, the apparatus further includes: the execution log acquisition module is used for acquiring the execution logs of all nodes in the block chain system; and the test report generation module is used for generating a test report of the block chain system under the scene of memory overflow according to the execution result, the test result and the execution log.

It should be noted that the computer system 1200 of the electronic device shown in fig. 12 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 12, the computer system 1200 includes a Central Processing Unit (CPU)1201, which can perform various appropriate actions and processes, such as executing the methods in the above-described embodiments, according to a program stored in a Read-Only Memory (ROM) 1202 or a program loaded from a storage section 1208 into a Random Access Memory (RAM) 1203. In the RAM 1203, various programs and data necessary for system operation are also stored. The CPU 1201, ROM 1202, and RAM 1203 are connected to each other by a bus 1204. An Input/Output (I/O) interface 1205 is also connected to bus 1204.

The following components are connected to the I/O interface 1205: an input section 1206 including a keyboard, a mouse, and the like; an output section 1207 including a Display device such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 1208 including a hard disk and the like; and a communication section 1209 including a Network interface card such as a LAN (Local Area Network) card, a modem, or the like. The communication section 1209 performs communication processing via a network such as the internet. A driver 1210 is also connected to the I/O interface 1205 as needed. A removable medium 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like, is mounted on the drive 1210 as necessary, so that a computer program read out therefrom is mounted into the storage section 1208 as necessary.

In particular, according to embodiments of the application, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 1209, and/or installed from the removable medium 1211. The computer program executes various functions defined in the system of the present application when executed by a Central Processing Unit (CPU) 1201.

It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a flash Memory, an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by an electronic device, cause the electronic device to implement the method in the above embodiments.

According to an aspect of the application, there is also provided a computer program product or a computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method provided in the various alternative implementations described above.

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method for testing a blockchain system, the blockchain system including a plurality of nodes, the method comprising:

acquiring scene information configured for a memory overflow scene, wherein the scene information comprises scene parameters and node identifiers;

controlling the node indicated by the node identification to perform memory overflow simulation according to the scene parameters so as to simulate the memory overflow scene in the block chain system;

acquiring an execution result of the block chain system executing a normal test case under the scene of memory overflow;

determining a test result of the block chain system under the scene of memory overflow according to the execution result;

the obtaining of the execution result of the block chain system executing the normal test case in the memory overflow scene includes:

obtaining a plurality of execution results obtained by executing the normal test case respectively at a plurality of time points of the block chain system under the scene of memory overflow, wherein the execution periods are separated by the time points; the execution results respectively indicate the execution duration for executing the normal test case at the corresponding time points;

the determining, according to the execution result, a test result of the block chain system in the memory overflow scenario includes:

acquiring a memory occupation parameter of a node indicated by the node identifier at each time point in the plurality of time points; and

acquiring execution duration indicated by the execution results respectively;

and taking the memory occupation parameter of the node indicated by the node identifier at each time point and the execution duration respectively indicated by the execution results as the test result of the block chain system in the memory overflow scene.

2. The method of claim 1, wherein the context parameters include execution conditions, and wherein controlling the node indicated by the node identifier to perform memory overflow simulation according to the context parameters comprises:

and when the execution condition is met, controlling the node indicated by the node identification to execute an overflow simulation script, wherein the overflow simulation script is used for making a memory request to the node.

3. The method according to claim 2, wherein the execution condition includes a trigger condition and a stop condition, and when the execution condition is satisfied, the control unit controls the node indicated by the node identifier to execute the overflow simulation script, including:

when the triggering condition is met, controlling the node indicated by the node identification to start executing the overflow simulation script;

and when the stop condition is met, controlling the node indicated by the node identification to stop executing the overflow simulation script.

4. The method of claim 2, wherein before controlling the node indicated by the node identifier to perform memory overflow simulation according to the scenario parameter, the method further comprises:

acquiring node information corresponding to the node identifier, wherein the node information comprises a network address of a node:

and issuing the overflow simulation script to the node indicated by the node identification according to the network address.

5. The method according to claim 2, wherein the execution condition includes a plurality of execution periods configured for a same node identifier and arranged in chronological order, and when the execution condition is satisfied, controlling the node indicated by the node identifier to execute the overflow simulation script includes:

and respectively controlling the nodes indicated by the node identifications to execute the overflow simulation script in the corresponding execution periods according to the time sequence of the execution periods.

6. The method of claim 1, wherein the test result comprises a fault tolerance indicator, the scenario information comprises a plurality of node identifiers, and the obtaining the execution result of the normal test case executed by the blockchain system in the memory overflow scenario comprises:

acquiring the number of memory overflow nodes of the block chain system at each time point in the plurality of time points;

and determining the maximum quantity of the memory overflow nodes as the fault tolerance index of the block chain system under the memory overflow scene in the execution result indicating the successful execution of the normal test case.

7. The method of claim 1, wherein the test results comprise consensus test results, and wherein the determining the test results of the blockchain system under the memory overflow scenario according to the execution results comprises:

acquiring an operation log of each node in the block chain system;

determining the number of memory overflow nodes and the number of normal nodes in the block chain system when the normal test case is executed under the memory overflow scene according to the running log;

and if the memory overflow node number and the normal node number meet a target number relation and the execution result indicates that the normal test case is successfully executed, determining that the consensus test result is a Byzantine fault-tolerant consensus mechanism in effect, wherein the target number relation is defined by the Byzantine fault-tolerant consensus mechanism configured in the blockchain system.

8. The method of claim 1, wherein the test results comprise service performance degradation parameters, the execution results comprise an execution duration for executing the normal test case, and the determining the test results of the blockchain system in the memory overflow scenario according to the execution results comprises:

acquiring a reference execution result of the block chain system for executing the normal test case when the memory overflow scene is not simulated, wherein the reference execution result comprises a reference execution time length for executing the normal test case;

and calculating the service performance degradation parameter of the block chain system under the memory overflow scene according to the execution duration and the reference execution duration.

9. The method of claim 1, wherein after controlling the node indicated by the node identifier to perform memory overflow simulation according to the scenario parameter, the method further comprises:

and controlling the node indicated by the node identification to execute a recovery script, wherein the recovery script is used for releasing the memory requested to the node.

10. The method of claim 1, wherein before the obtaining the scene information configured for the memory overflow scene, the method further comprises:

and generating scene information corresponding to the memory overflow scene according to the configuration operation performed on the memory overflow scene.

11. The method of claim 1, wherein after determining the test result of the blockchain system under the memory overflow scenario according to the execution result, the method further comprises:

acquiring an execution log of each node in the block chain system;

and generating a test report of the block chain system under the memory overflow scene according to the execution result, the test result and the execution log.

12. An apparatus for testing a blockchain system, the blockchain system including a plurality of nodes, the apparatus comprising:

the system comprises a scene information acquisition module, a node identification acquisition module and a data processing module, wherein the scene information acquisition module is used for acquiring scene information configured for a memory overflow scene, and the scene information comprises scene parameters and node identifications;

the memory overflow simulation module is used for controlling the node indicated by the node identifier to perform memory overflow simulation according to the scene parameters so as to simulate the memory overflow scene in the block chain system;

an execution result obtaining module, configured to obtain an execution result of the block chain system executing a normal test case in the memory overflow scenario, where the execution result obtaining module is configured to: acquiring a plurality of execution results obtained by executing a normal test case respectively at a plurality of time points of a block chain system in a memory overflow scene, wherein a plurality of execution periods are spaced by the plurality of time points; the execution results respectively indicate the execution duration for executing the normal test case at the corresponding time points;

a test result determining module, configured to determine a test result of the block chain system in the memory overflow scenario according to the execution result, where the test result determining module includes: the device comprises a first acquisition unit and a second acquisition unit, wherein the first acquisition unit is used for acquiring the memory occupation parameter of a node indicated by a node identifier of each time point in a plurality of time points, and the second acquisition unit is used for acquiring the execution duration respectively indicated by a plurality of execution results; and the test result determining unit is used for taking the memory occupation parameter of the node indicated by each time point node identifier and the execution duration respectively indicated by the execution results as the test result of the block chain system in the memory overflow scene.

13. The apparatus for testing a blockchain system of claim 12, wherein the scene parameters include execution conditions, the memory overflow simulation module configured to: and when the execution condition is met, controlling the node indicated by the node identification to execute an overflow simulation script, wherein the overflow simulation script is used for making a memory request to the node.

14. The apparatus for testing a blockchain system of claim 13, wherein the execution conditions include a trigger condition and a stop condition, the memory overflow simulation module further configured to: when the triggering condition is met, controlling the node indicated by the node identification to start executing the overflow simulation script; and when the stop condition is met, controlling the node indicated by the node identification to stop executing the overflow simulation script.

15. The apparatus for testing a blockchain system of claim 13, wherein the apparatus further comprises: a node information obtaining module, configured to obtain node information corresponding to the node identifier, where the node information includes a network address of a node; and the script issuing module is used for issuing the overflow simulation script to the node indicated by the node identification according to the network address.

16. The apparatus of claim 13, wherein the execution conditions include a plurality of execution periods arranged in chronological order configured for a same node identifier, and the memory overflow simulation module is configured to: and respectively controlling the nodes indicated by the node identifications to execute the overflow simulation script in the corresponding execution periods according to the time sequence of the execution periods.

17. The apparatus for testing a blockchain system of claim 12, wherein the test result includes a fault tolerance indicator, the scenario information includes a plurality of node identifiers, and the test result determination module is configured to: acquiring the number of memory overflow nodes of the block chain system at each time point in a plurality of time points; and determining the maximum quantity of the memory overflow nodes as the fault-tolerant index of the block chain system under the memory overflow scene in the execution result indicating the successful execution of the normal test case.

18. The apparatus for testing a blockchain system of claim 12, wherein the test results include consensus test results, and the test result determination module comprises: the operation log obtaining unit is used for obtaining operation logs of all nodes in the block chain system; the quantity determining unit is used for determining the quantity of memory overflow nodes and the quantity of normal nodes in the block chain system when the normal test case is executed under the memory overflow scene according to the running log; and the consensus test result determining unit is used for determining that the consensus test result is the Byzantine fault-tolerant consensus mechanism to be effective if the number of the memory overflow nodes and the number of the normal nodes meet the target number relation and the execution result indicates that the normal test case is successfully executed, wherein the target number relation is limited by the Byzantine fault-tolerant consensus mechanism configured in the block chain system.

19. The apparatus for testing a blockchain system according to claim 12, wherein the test result includes a service performance degradation parameter, the execution result includes an execution duration for executing a normal test case, and the test result determination module includes: the reference execution result acquisition unit is used for acquiring a reference execution result of the block chain system for executing the normal test case when the memory overflow scene is not simulated, wherein the reference execution result comprises a reference execution time length for executing the normal test case; and the service performance degradation parameter calculation unit is used for calculating the service performance degradation parameter of the block chain system under the scene of memory overflow according to the execution duration and the reference execution duration.

20. The apparatus for testing a blockchain system of claim 12, wherein the apparatus further comprises: and the recovery script execution module is used for controlling the node indicated by the node identification to execute a recovery script, and the recovery script is used for releasing the memory requested by the node.

21. The apparatus for testing a blockchain system of claim 12, wherein the apparatus further comprises: and the scene information generating module is used for generating scene information corresponding to the memory overflow scene according to the configuration operation performed on the memory overflow scene.

22. The apparatus for testing a blockchain system of claim 12, wherein the apparatus further comprises: the execution log acquisition module is used for acquiring the execution logs of all nodes in the block chain system; and the test report generation module is used for generating a test report of the block chain system under the scene of memory overflow according to the execution result, the test result and the execution log.

23. An electronic device, comprising:

a processor; and

a memory having stored thereon computer readable instructions which, when executed by the processor, implement the method of any of claims 1 to 11.

24. A computer-readable storage medium having computer-readable instructions stored thereon which, when executed by a processor, implement the method of any one of claims 1 to 11.