CN117251354A

CN117251354A - Abnormality test method and device applied to blockchain system and computer equipment

Info

Publication number: CN117251354A
Application number: CN202210649099.2A
Authority: CN
Inventors: 陈金龙
Original assignee: Tenpay Payment Technology Co Ltd
Current assignee: Tenpay Payment Technology Co Ltd
Priority date: 2022-06-09
Filing date: 2022-06-09
Publication date: 2023-12-19

Abstract

The application discloses an anomaly testing method, an anomaly testing device and computer equipment applied to a blockchain system, and relates to the technical field of blockchains. The testing equipment injects abnormal logic codes into the original logic codes of the blockchain system to generate logic codes after abnormal injection; the abnormal logic code is used for simulating the wrongly behavior; transmitting the logic code after the abnormal injection to at least one node device in the blockchain system; a case execution request is sent to target node equipment in the block chain system, and the case execution request is used for requesting the target node equipment to execute a test case based on the logic code after the abnormal injection; and receiving an execution log sent by the target node equipment, wherein an execution result of the test case is recorded in the execution log. By combining the abnormal logic code and the use case, the abnormal test is automatically performed, the test cost is reduced, the degree of automation is higher, and the test period is shorter.

Description

Abnormality test method and device applied to blockchain system and computer equipment

Technical Field

The embodiment of the application relates to the technical field of blockchain, in particular to an anomaly testing method, an anomaly testing device and computer equipment applied to a blockchain system.

Background

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. The blockchain is a chained data structure which is formed by combining data blocks in a sequential connection mode according to time sequence, and the distributed account book which cannot be tampered and counterfeited is ensured in a cryptographic mode. Testing for bad behaviour is involved in the blockchain domain.

In the related art, in order to simulate the action, a network packet capturing form is generally adopted, a packet capturing tool is utilized to filter block chain protocol data, proposal information is tampered, and the action is simulated.

However, in the above manner, the blockchain protocol data needs to be known in advance, and there are technical risks of network unpacking, packetizing and data packet encryption, and the automation degree is low and the workload is high.

Disclosure of Invention

The embodiment of the application provides an anomaly testing method, an anomaly testing device and computer equipment applied to a blockchain system. The technical scheme is as follows:

according to one aspect of the embodiments of the present application, there is provided an anomaly testing method applied to a blockchain system, the method being performed by a testing device, the method comprising:

Injecting an abnormal logic code into the original logic code of the blockchain system, and generating an abnormal logic code after abnormal injection; wherein the abnormal logic code is a logic code for simulating a bad behavior;

transmitting the logic code after the abnormality injection to at least one node device in the blockchain system;

sending a case execution request to target node equipment in the blockchain system, wherein the case execution request is used for requesting the target node equipment to execute a test case based on the logic code after the abnormal injection;

and receiving an execution log sent by the target node equipment, wherein the execution log records the execution result of the test case.

According to an aspect of the embodiments of the present application, there is provided an anomaly testing method applied to a blockchain system including a plurality of node devices, the method being performed by a target node device of the plurality of node devices, the method including:

receiving an abnormal injected logic code sent by test equipment, wherein the abnormal injected logic code is generated after the abnormal logic code is injected into an original logic code of the blockchain system, and the abnormal logic code is a logic code for simulating a wrongly behavior;

Receiving a case execution request sent by the test equipment, wherein the case execution request is used for requesting the target node equipment to execute a test case based on the logic code after the abnormal injection;

executing the test case based on the logic code after the abnormal injection according to the case execution request;

and sending an execution log of the test case to the test equipment, wherein the execution log records an execution result of the test case.

According to one aspect of embodiments of the present application, there is provided an anomaly testing device applied to a blockchain system, the device including:

the code injection module is used for injecting abnormal logic codes into the original logic codes of the blockchain system and generating logic codes after abnormal injection; wherein the abnormal logic code is a logic code for simulating a bad behavior;

the code sending module is used for sending the logic code after the abnormality injection to at least one node device in the blockchain system;

the request sending module is used for sending a case execution request to target node equipment in the blockchain system, wherein the case execution request is used for requesting the target node equipment to execute a test case based on the logic code after the abnormal injection;

The log receiving module is used for receiving an execution log sent by the target node equipment, and the execution log records the execution result of the test case.

According to another aspect of an embodiment of the present application, there is provided an anomaly testing device applied to a blockchain system, the device including:

a code receiving module: the method comprises the steps of receiving an abnormal injected logic code sent by test equipment, wherein the abnormal injected logic code is generated after the abnormal logic code is injected into an original logic code of the blockchain system, and the abnormal logic code is used for simulating bad behaviors;

the request receiving module is used for receiving a case execution request sent by the test equipment, wherein the case execution request is used for requesting the target node equipment to execute the test case based on the logic code after the abnormal injection;

the case execution module is used for executing the test case based on the logic code after the abnormal injection according to the case execution request;

the log sending module is used for sending an execution log of the test case to the test equipment, and the execution log records an execution result of the test case.

According to an aspect of the embodiments of the present application, there is provided a computer device, including a processor and a memory, in which a computer program is stored, the computer program being loaded and executed by the processor to implement the method on the test device side described above, or the method on the target node device side described above.

According to an aspect of the embodiments of the present application, there is provided a computer readable storage medium having stored therein a computer program that is loaded and executed by a processor to implement the method on the test device side described above, or the method on the target node device side described above.

According to one aspect of embodiments of the present application, there is provided a computer program product 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, so that the terminal device performs the method on the side of the test device or the method on the side of the target node device.

The technical scheme provided by the embodiment of the application can comprise the following beneficial effects:

The abnormal logic codes corresponding to the wrought behaviors are injected into the source codes of the blockchain system, the logic codes after the abnormal injection are generated, the logic codes after the abnormal injection are sent to the node equipment, the node equipment executes the test cases based on the logic codes after the abnormal injection, so that the cases can be combined with the abnormal logic codes, various abnormal scenes can be simulated for different cases by driving the abnormal logic codes corresponding to the different wrought behaviors, the injection of the abnormal logic codes is not needed to be carried out once for each case, the test cost is reduced, and the degree of automation is higher.

Drawings

FIG. 1 is a schematic diagram of a distributed system as provided by one embodiment of the present application applied to a blockchain system;

FIG. 2 is a flow chart of an anomaly testing method for a blockchain system provided in an embodiment of the present application;

FIG. 3 is a flow chart of an anomaly testing method for use with a blockchain system provided in accordance with another embodiment of the present application;

FIG. 4 is a schematic diagram of exception logic code injection provided by one embodiment of the present application;

FIG. 5 is a flow chart of an anomaly testing method for use with a blockchain system provided in accordance with another embodiment of the present application;

FIG. 6 is a flow chart of an anomaly testing method for use with a blockchain system provided in accordance with another embodiment of the present application;

FIG. 7 is a flow chart of an anomaly testing method for use with a blockchain system provided in accordance with another embodiment of the present application;

FIG. 8 is a schematic illustration of an intermediate file provided in one embodiment of the present application;

FIG. 9 is a schematic diagram of a use case execution request provided by one embodiment of the present application;

FIG. 10 is a block diagram of an anomaly testing method applied to a blockchain system provided in an embodiment of the present application;

FIG. 11 is a schematic diagram of an implementation environment of an anomaly testing method applied to a blockchain system provided in an embodiment of the present application;

FIG. 12 is a schematic diagram of an implementation environment of an anomaly testing method for a blockchain system according to another embodiment of the present application;

FIG. 13 is a block diagram of an anomaly testing device for use in a blockchain system provided in an embodiment of the present application;

FIG. 14 is a block diagram of an anomaly testing device for use in a blockchain system provided in accordance with another embodiment of the present application;

FIG. 15 is a block diagram of an anomaly testing device for use in a blockchain system provided in accordance with another embodiment of the present application;

FIG. 16 is a block diagram of an anomaly testing device for use in a blockchain system provided in accordance with another embodiment of the present application;

Fig. 17 is a block diagram of a computer device according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Before the technical scheme of the application is described, some background knowledge related to the application is described. The following related technologies may be optionally combined with the technical solutions of the embodiments of the present application, which all belong to the protection scope of the embodiments of the present application. Embodiments of the present application include at least some of the following.

Accounting node: and calling out a block node and a Leader node, wherein in the blockchain, in each packing period, the accounting node is required to pack a plurality of transaction lists into a block structure and broadcast the block structure to other nodes for consensus, and the accounting node is the node which generates the block and initiates the proposal.

Blockchain: a billing technique, also known as a distributed ledger technique, is commonly maintained by multiple parties, uses cryptography to secure transmission and access, and enables consistent storage of data, difficult tampering, and protection from repudiation.

BFT (Byzantine Fault Tolerance, bayer fault tolerance) consensus: the Bayesian fault-tolerant technology is a fault-tolerant technology in the field of distributed computing, and the whole system can normally run, namely n/3 nodes are allowed to be abnormal, if the distributed system is provided with n nodes and the Bayesian node of the whole system is not more than m (n is not less than 3m+1).

Proposal: at the beginning of the block chain life cycle, the accounting node scans the transaction pool of the current node, when the transaction pool list is not empty, the accounting node triggers to generate a block proposal, the proposal message comprises block height, block header, merkle root, transaction information and the like, and BFT consensus is completed after the proposal message is broadcast to other nodes.

Consensus algorithm: the method is a process for solving the problem of agreeing on a proposal (various collaborative works such as targets, votes and the like).

FailPoint (fault simulation tool): the fault simulation tool is realized by Golang (Go language) of FreeBSD (a You Nisi operating system) failpoints, and can inject errors or abnormal behaviors into codes for simulating error processing in various complex systems so as to improve the fault tolerance, the correctness and the stability of the system.

REQ (software development and promotion flow management platform): the method is used for managing software version development, test lifting, defect submission, regression testing and publishing the whole life cycle.

The system according to the embodiments of the present application may be a distributed system formed by connecting a test device (the test device may be any form of computer device in an access network, such as a server and a user terminal device), and a plurality of nodes (each node corresponds to one node device, and the node device may be any form of computer device in the access network, such as a server and a user terminal device) through a network communication.

Taking the distributed system as an example of a blockchain system, referring To fig. 1, fig. 1 is a schematic structural diagram of an alternative application of the distributed system 100 provided in the embodiment of the present application To the blockchain system, where the structure is formed by a plurality of nodes 200 and at least one testing device 300, a Peer-To-Peer (P2P) network is formed between the nodes 200, and the P2P protocol is an application layer protocol running on top of a transmission control protocol (TCP, transmission Control Protocol) protocol. In a distributed system, any machine, such as a server, terminal device, may join to become a node, including a hardware layer, an intermediate layer, an operating system layer, and an application layer.

For each node in the blockchain system, the node identification corresponding to the node identification is provided, and each node in the blockchain system can store the node identifications of other nodes in the blockchain system so as to broadcast the generated blocks to other nodes in the blockchain system according to the node identifications of other nodes. Each node can maintain a node identification list shown in the following table, and the node names and the node identifications are correspondingly stored in the node identification list. The node identifier may be an IP (Internet Protocol, protocol of interconnection between networks) address, and any other information that can be used to identify the node, and the IP address is only illustrated in table 1.

TABLE 1

Node name	Node identification
		Node 1	117.xxx.xxx.xxx
Node 2	117.xxx.xxx.xxx
		…	…
Node N	119.xxx.xxx.xxx

Referring to the functionality of each node in the blockchain system shown in fig. 1, the functions involved include:

1) The routing, the node has basic functions for supporting communication between nodes.

Besides the routing function, the node can also have the following functions:

2) The application is used for being deployed in a block chain to realize specific service according to actual service requirements, recording data related to the realization function to form recorded data, carrying a digital signature in the recorded data to represent the source of task data, sending the recorded data to other nodes in the block chain system, and adding the recorded data into a temporary block when the source and the integrity of the recorded data are verified by the other nodes.

3) The blockchain comprises a series of blocks (blocks) which are connected with each other according to the generated sequence time, the new blocks are not removed once being added into the blockchain, and record data submitted by nodes in the blockchain system are recorded in the blocks.

In some embodiments, the test device is a client, the client sends a transaction to a node, the node broadcasts the transaction to other nodes through a P2P network, the accounting node is randomly selected by a consensus mechanism, the accounting node packages and assembles a plurality of transaction lists into a block structure, generates a block proposal message, and broadcasts the block proposal message to other nodes, and if the transaction list is empty, packages into an empty block and broadcasts; after receiving the block, other nodes verify the transaction in the block and broadcast voting information for proposal; after BFT consensus is achieved for the block, the block is submitted to a block chain storage layer, and next round of election and consensus begins. In a typical blockchain network based on BFT consensus, a transaction list of a transaction pool is loaded by an accounting node, after a blockproposal is constructed, the proposal is broadcast to other nodes, the other nodes verify after receiving the blockproposal, and can vote or anti-vote, when the nodes vote the blockproposal, each node collects voting information of the proposal, verifies whether the number of votes for the blockproposal is greater than 2/3 nodes, submits the blockto the node if the number of votes for the blockproposal is greater than 2/3 nodes, and if the number of the votes for the blockchain is less than 2/3 nodes, the blockchain cannot complete BFT consensus, and the blockchain running state is abnormal and blocked. When the network is in an unsafe state of man-in-the-middle attack, the message can be tampered, and the consensus state is influenced. It is because the man-in-the-middle may attack the network because testing for blockchain disfigurement occurs.

In some embodiments, in order to simulate man-in-the-middle attack, a network packet capturing form is adopted, a packet capturing tool is utilized to obtain a data packet, protocol data is filtered, proposal information in the data packet is tampered (including illegal proposal construction, man-in-the-middle real signature and the like), and the purpose of tampering attack is achieved. However, the implementation method has large workload, needs to know the blockchain protocol data in advance, has technical risks of network unpacking, packetizing and packet encryption, and has low automation degree, large workload and poor accuracy, and no clear log can be queried. At the same time, there is also a risk of losing packets.

In some embodiments, to simulate man-in-the-middle attacks, anomaly testing is performed in the form of static injection. The abnormal logic codes are injected into the blockchain original logic codes and are directly compiled to simulate the bad behaviors, but the static abnormal test mode is required to be used for injecting the abnormal logic codes and compiling the codes once for each use case, so that the degree of automation is low, the combination with the use cases is poor, and the cost is relatively high. Also, since the exception logic code needs to be reinjected for each use case, the time required to trigger the execution of the use case is long.

Based on this, the embodiment of the application provides an exception testing method applied to a blockchain system, by injecting an exception logic code into a source code of a blockchain, compiling the source code to generate an executable file, and sending the executable file to each node device, the node device can call an API (Application Program Interface, application programming interface) of the exception logic code to drive the exception logic code, when the node device executes a use case, the use case is executed based on the executable file after the exception driving, and after the use case is executed, the node device stops calling the API of the exception logic code. That is, for each use case, the node apparatus may automatically drive the target abnormal logic code by calling the API of the abnormal logic code, and may also stop calling the API of the abnormal logic code after the use case is executed. Therefore, the technical scheme provided by the embodiment of the application has better combination with the use case, higher automation degree and higher accuracy.

Referring to fig. 2, a flowchart of an anomaly testing method applied to a blockchain system according to an embodiment of the present application is shown. The method can be applied to the distributed system shown in fig. 1, and the execution subject of each step of the method can be a test device. The method may comprise at least one of the following steps (310-340).

Step 310, injecting an abnormal logic code into the original logic code of the blockchain system to generate an abnormal logic code; wherein the abnormal logic code is a logic code for simulating a bad behavior.

The malignant behavior: there are man-in-the-middle (third party) attacks in blockchain systems, which may be collectively referred to as offensive behavior. The aversion behavior includes, but is not limited to, at least one of: tamper with proposal information, simulate man-in-the-middle signatures, construct illegal proposals, etc. In some embodiments, each offensive behavior corresponds to a different exception logic code.

In some embodiments, the test equipment obtains the original logic code of the blockchain system, and injects the logic code (abnormal logic code) for simulating the offending behavior into the original logic code, generating the logic code after the abnormal injection.

In some embodiments, the logic code after exception injection is in the form of original logic code + exception logic code; in some embodiments, the exception injected logic code is not in the form of simple original logic code+exception logic code, but is compiled again for the original logic code+exception logic code.

And step 320, transmitting the logic code after the exception injection to at least one node device in the blockchain system.

In some embodiments, the blockchain system includes a plurality of node devices, and the logic code after the exception injection is sent to the plurality of node devices in the blockchain system. Optionally, the exception injected logical code is sent to all node devices in the blockchain system. Optionally, the exception injected logical code is sent to a node device of a particular portion of the blockchain system.

In some embodiments, the blockchain system includes an a node device, a b node device, and a c node device, and optionally, the logic code after the anomaly injection is sent to the a node device, the b node device, and the c node device in the blockchain system. Optionally, the logic code after the exception injection is sent to any one of an a node device, a b node device and a c node device in the blockchain system. Optionally, the logic code after the exception injection is sent to any two of an a node device, a b node device and a c node device in the blockchain system.

In some embodiments, to simulate the act of "tamper proposal information", an abnormal logic code corresponding to the act of "tamper proposal information" is injected into an original logic code of the blockchain system, an abnormally injected logic code is generated, and the abnormally injected logic code is sent to half of the node devices in the blockchain system.

In some embodiments, to simulate the act of "constructing an illegal proposal," an abnormal logic code corresponding to the act of "constructing an illegal proposal" is injected into an original logic code of the blockchain system, an abnormally injected logic code is generated, and the abnormally injected logic code is sent to all node devices in the blockchain system.

And 330, sending a case execution request to the target node equipment in the block chain system, wherein the case execution request is used for requesting the target node equipment to execute the test case based on the logic code after the exception injection.

Test cases: a particular software product is described for testing tasks embodying test schemes, methods, techniques and strategies. In some embodiments, a test case is a description of a blockchain system performing a test task. In some embodiments, the use case is a read-write operation, optionally the test case is a query task, optionally the test case is a contract deployment task.

The target node device is at least one node device in a blockchain system. In some embodiments, the blockchain system includes an a node device, a b node device, and a c node device, optionally, the target node device is the a node device, the test case is to query the number of nodes in the blockchain system, and the test device sends a case execution request to the a node device in the blockchain system, so as to request the a node device to execute the test case of "query the number of nodes in the blockchain system" based on the logic code after the exception is injected. Optionally, the target node device is a b node device, the test case is to deploy a contract h in the blockchain system, and the test device sends a case execution request to the b node device in the blockchain system, so as to request the b node device to execute the test case of deploying the contract h in the blockchain system based on the logic code after the abnormal injection. In some embodiments, test cases are generated according to tasks to be tested of the blockchain system. Optionally, when the blockchain system needs to execute the query task, the query task is a task to be tested, and the test case is generated according to the query task. Optionally, when the blockchain system is about to perform contract deployment, the contract deployment is to be tested, and the test case is generated according to the contract deployment task.

Step 340, receiving an execution log sent by the target node device, where an execution result of the test case is recorded in the execution log.

The execution log reflects the specific running condition of the node when executing the test case. The test equipment receives the execution log sent by the target node equipment, and in some embodiments, the test equipment may analyze whether a running error occurs in each node according to a specific record of the execution log.

In some embodiments, the test device receives an execution log sent by the node a device, where the execution log records an execution result of the test case, i.e. the "number of nodes in the query blockchain system". In some embodiments, the test device receives an execution log sent by the b node device, where an execution result of the test case of "deploying a contract h in the blockchain system" is recorded in the execution log.

According to the technical scheme provided by the embodiment of the application, the abnormal logic codes are injected into the original codes of the blockchain system, the logic codes after the abnormal injection are sent to the node equipment, and the case execution request is sent to the target node equipment, so that the target node equipment is requested to execute the test case based on the logic codes after the abnormal injection, different node equipment in the blockchain system can execute different test cases based on different injected abnormal logic codes, and the flexibility and accuracy of the abnormal injection are improved. Furthermore, the target node device can also send the execution result of the test case to the test device, so that the test device can analyze the specific blockchain node situation according to the execution log and remove the fault.

Referring to fig. 3, a flowchart of an anomaly testing method applied to a blockchain system according to another embodiment of the present application is shown. The method can be applied to the distributed system shown in fig. 1, and the execution subject of each step of the method can be a test device. The method may comprise at least one of the following steps (410-480).

Step 410, determining instrumentation points in the original logic code according to the wrongly behavior corresponding to the abnormal logic code.

The instrumentation point is the location where the abnormal logic code needs to be injected. The original logic code is the running code of the blockchain system, each wrongly action corresponds to a different position, and when the abnormal logic code is injected, the position of the code also needs to be noted, and the abnormal logic code is injected at a proper position, so that the confusion of the running of the blockchain system is not caused. In some embodiments, the offending action is "tampering with the proposal," finding the position of the proposal in the original logical code, and determining the position of the proposal as the instrumentation point.

Step 420, injecting an abnormal logic code at the instrumentation point, and generating an abnormal logic code after the abnormal injection.

In some embodiments, multiple offending actions need to be simulated in the original logic code of the blockchain system, and thus multiple exception logic codes need to be injected. In some embodiments, three wrongly-acting behaviors need to be simulated, so that there are three instrumentation points in the blockchain original logic code, and each instrumentation point is used for injecting abnormal logic code corresponding to different wrongly-acting behaviors, so that logic code after abnormal injection is generated.

In some embodiments, the act of mismatching is "tamper proposal information", the position of the proposal is found in the original logic code, the position of the proposal is determined as the instrumentation point, and the abnormal logic code corresponding to "tamper proposal" is injected at the instrumentation point. Referring to FIG. 4, a schematic diagram of one possible abnormal logic code injection is shown. 400 is a section of the intercepted original code (the code in fig. 4 is merely an example and is not an actual code), wherein 401 represents an abnormal logic code corresponding to the injected "tamper proposal information", and the position of 401 is the insertion point of the abnormal logic code corresponding to the "tamper proposal information" in the original logic code 400.

And 430, compiling the logic code after the exception injection to generate an executable file.

In some embodiments, the executable file is a file that can be run by the node device after compilation. In some embodiments, the node device may drive exception logic code corresponding to different wrongly-acting actions in the executable file.

Step 440, the executable file is sent to at least one node device in the blockchain system.

In some embodiments, the blockchain system includes an a node device, a b node device, and a c node device, and optionally, the executable file is sent to all node devices in the blockchain system, that is, to the a node device, the b node device, and the c node device. Optionally, the executable file is sent to a portion of the node devices in the blockchain system, and optionally, the executable file is sent to an a-node device and a b-node device in the blockchain system.

And 450, determining target node equipment simulating the wrongly-acting behavior from at least one node equipment according to the abnormal simulation scene.

Under the condition that the abnormal simulation scene is a single-node abnormal scene, determining one node device simulating the wrongly behavior from at least one node device as a target node device, namely, the number of the target node devices is one at the moment; or, in the case where the abnormality simulation scene is a multi-node abnormality scene, a plurality of node devices simulating the wrongly behavior are determined from among the at least one node device as target node devices, that is, the number of target node devices is a plurality at this time.

In some embodiments, the anomaly simulation scene is a single-node anomaly scene. The block chain system comprises an a node device, a b node device and a c node device. And sending the executable file to all node devices in the blockchain system, namely an a node device, a b node device and a c node device, and determining one node device from the a node device, the b node device and the c node device as a target node device.

In some embodiments, the anomaly simulation scene is a multi-node anomaly scene. The block chain system comprises an a node device, a b node device and a c node device. And sending the executable file to all node devices in the blockchain system, namely an a node device, a b node device and a c node device, and determining a plurality of node devices from the a node device, the b node device and the c node device as target node devices. Alternatively, the multi-node anomaly scenario is a two-node anomaly scenario, i.e., two node devices are determined from an a-node device, a b-node device, and a c-node device as target node devices.

In some embodiments, the anomaly simulation scene is a multi-node anomaly scene. And determining the number N of node devices simulating the wrongly acting actions according to the total number of node devices participating in the test case execution in the blockchain system, wherein N is an integer greater than 1. N node devices are determined from at least one node device as target node devices. In a possible embodiment, the number of node devices simulating the wrongly acting is determined to be 2, executable files are sent to 6 node devices, and 2 node devices needing to simulate the wrongly acting are determined from the 6 node devices to serve as target node devices.

In some embodiments, the number of node devices simulating bad behavior is determined based on the total number of node devices participating in the execution of the test case and consensus achievement conditions in the blockchain system. The consensus meeting condition refers to the requirement of a voting consensus mechanism adopted by the block chain system for the number of node devices. In some embodiments, the consensus achievement condition is that the number of wrongly-generated nodes is less than one third of the total number of node devices based on a scenario in which the number of wrongly-generated nodes is less than one third of the total number of node devices in the bayer consensus scenario, and the number of node devices simulating wrongly-generated actions is determined to be less than one third of the total number of node devices participating in the test case execution. In some embodiments, the consensus achievement condition is that the number of wrongly-generated nodes is greater than two-thirds of the total number of node devices based on a scenario in which the number of wrongly generated nodes is greater than two-thirds of the total number of node devices in the bayer consensus scenario, and the number of node devices simulating wrongly generated behavior is determined to be greater than two-thirds of the total number of node devices participating in the test case execution. In some embodiments, the consensus achievement condition is that the number of wrongly-generated nodes is greater than one third of the total number of node devices and less than two thirds of the total number of node devices, and the number of node devices simulating wrongly-generated behavior is determined to be less than two thirds of the total number of node devices participating in the test case execution and greater than one third of the total number, based on a scenario in which the number of wrongly-generated nodes is less than two thirds of the total number of node devices and greater than one third of the total number of node devices in the bayer consensus scenario.

In some embodiments, to simulate a scenario in which the number of offending nodes in the bayer consensus scenario is less than one third of the total number of node devices, an executable file is sent to 3n+1 node devices, and N target node devices are determined from 3n+1 node devices for simulating offending behavior. In some embodiments, to simulate a scenario in which the number of wrongly generated nodes in the Bayesian consensus scenario is greater than two-thirds of the total number of node devices, 2N+1 target node devices are determined from 3N+1 node devices for simulating wrongly generated behavior. In some embodiments, to simulate a scenario in which the offending node is less than two-thirds and more than one-third of the total number of node devices in the bayer consensus scenario, less than 2n+1 and more than N target node devices are determined from 3n+1 node devices for simulating offending behavior. Optionally, the total number of node devices participating in the test case execution is 100, 30 node devices are determined as target node devices in order to simulate a scene in which the number of wrongly generated nodes in the bayer consensus scene is less than one third of the total number of node devices, and 70 node devices are determined as target node devices in order to simulate a scene in which the number of wrongly generated nodes in the bayer consensus scene is greater than two thirds of the total number of node devices. To simulate a scene in which the number of bad nodes in the bayer consensus scene is less than two-thirds and more than one-third of the total number of node devices, 50 node devices are determined as target node devices.

In some embodiments, the device information is configured for all node devices. In some embodiments, the device information is a node device identification. Each node device is configured with device information, and an executable file is issued to at least one node device based on the configured device information. Based on the determined target node equipment simulating the wrongly, the abnormal logic code corresponding to the wrongly behavior can be further triggered in a directional manner according to the equipment information.

According to the technical scheme provided by the embodiment of the application, part of node equipment in the block chain system can be used as target node equipment, the target node equipment can be used for simulating the disfiguring behavior, namely, the simulation of the disfiguring behavior on any equipment can be controlled, and the automation of the abnormality test with a higher degree is realized.

Step 460, determining a target aversion behavior to be simulated by the target node device from a plurality of different aversion behaviors.

The target offensive behavior is at least one of a number of different offensive behaviors, and in some embodiments, at least one of tampering with proposal information, simulating man-in-the-middle signatures, constructing illegal proposals, and the like. In some embodiments, the target aversion behavior is "tamper proposal information". In some embodiments, in order to enable the target node device to drive the abnormal logic code corresponding to the disfiguring action of "tamper proposal information", the test device further sends an indication information to the target node device, where the indication information is used to indicate what kind of disfiguring action the target node device drives. In some embodiments, the indication information is sent to the target node device along with the use case execution request in step 470, in some embodiments, the indication information is sent to the target node device by the test device first, and then the test device sends the use case execution request that does not include the indication information. The embodiment of the application does not limit the type of the indication information and the time sequence of the transmission.

According to the technical scheme provided by the embodiment of the application, the abnormal logic codes corresponding to the plurality of wrongly-acting actions are firstly injected into the source codes of the blockchain system, the executable file which can be executed by the node equipment is generated, meanwhile, the testing equipment can also specify the target wrongly-acting actions which are required to be simulated by the blockchain system in a mode of sending the indication information, namely, the plurality of wrongly-acting actions are injected at the same time, but the blockchain equipment can simulate the corresponding wrongly-acting actions in a specified mode, the form of the indication information is not limited, the text form can be marked, the mark can be marked for each section of abnormal logic codes, and the corresponding wrongly-acting actions are indicated by the testing equipment in a mode of sending the mark. After the simulation of one kind of bad behavior is finished, the simulation of the bad behavior can be stopped, and the simulation of other bad behaviors can be continued when the test equipment sends the indication information next time.

Unlike the related art, the simulation of each kind of wrongly behavior in the related art is immediate, that is, after one kind of wrongly behavior is simulated, if the second kind of wrongly behavior is further to be simulated, the abnormal logic code of the second kind of wrongly behavior needs to be reinjected into the source code of the blockchain system for compiling again to generate a file which can be executed by the blockchain system, so that the technical scheme provided by the application needs less time for performing the abnormal test and has shorter test period.

Furthermore, in the related art, the unpacking, the reassembling and the sending of the tampered data packet are performed by the unpacking tool, and the unpacking and the reassembling are performed by the unpacking tool, so that the unpacking tool needs more times of encryption and decryption operations, and partial data is likely to be lost in the encoding and decoding processes, so that the final test result is inaccurate.

In step 470, a use case execution request is sent to the target node device in the blockchain system, where the use case execution request further includes indication information of target disfigurement.

In some embodiments, the indication of target disfigurement is included in a use case execution request sent by the test equipment to the target node device.

Step 480, receiving an execution log sent by the target node device, where an execution result of the test case is recorded in the execution log.

In a possible embodiment, according to the execution logs respectively reported by each node device participating in the execution of the test case in the blockchain system, statistical analysis is performed on the execution results of each node device for the test case. And generating a test report according to the result of the statistical analysis.

In some embodiments, the executable file is sent to 3N+1 node devices, and N target node devices are determined from the 3N+1 node devices for simulating the wrought behavior. In some embodiments, the execution logs sent by the N target node devices are received, and the execution logs sent by other nodes are also received at the same time, and the result of the BFT consensus scenario of the entire blockchain is also obtained. In some embodiments, the result of the BFT consensus scenario of the entire blockchain is to determine whether the entire blockchain is in a clear state or a blocking state after setting up N target node devices to simulate wrongly, where the clear state is that the entire blockchain system can operate normally, and the blocking state is that the blockchain system cannot operate normally. After the result of the BFT consensus scenario of the entire blockchain is obtained, if the blockchain is in a blocking state, an execution log of each target node device is obtained. Because the target node device only occupies less than one third of the running node devices, the BFT consensus scene of the whole blockchain is expected to be smooth, but if blocking occurs, other problems appear in the node, and based on the execution log of each node device, the node device with the specific problem and the corresponding program can be positioned, and the program can be modified to obtain the original logic code of the modified blockchain.

In some embodiments, 2N+1 target node devices are determined from the 3N+1 node devices for simulating the wrought behavior. As expected, when more than 2/3 of the target node devices simulating disfigurement are present in the blockchain system, the entire blockchain system is in a blocking state. If the final BFT consensus scene of the whole blockchain results in a blocking state, the method accords with expectations, and meanwhile, the execution log of each target node device can be further queried to judge whether the execution log is matched with expected wrongly actions.

In some embodiments, less than 2N+1 and greater than N target node devices are determined from the 3N+1 node devices for simulating disfigurement. Similarly, according to the result of the BFT consensus scene of the whole blockchain and the execution log of each node device, statistical analysis can be performed to determine the node device with the problem finally, judge whether other nodes with bad behaviors appear or not, and generate a test report.

In some embodiments, the manner in which the target node device is determined is randomly determined. In some embodiments, the test device randomly determines N target node devices from the 3n+1 node devices, and sends indication information to the corresponding target node devices according to the node identifiers of the determined N target node devices, where the indication information is used to instruct the target node devices to call an abnormal logic code corresponding to the specified disfiguring behavior.

According to the technical scheme provided by the embodiment of the application, through covering all the Bayesian consensus scenes (the number of the target node devices is greater than 2/3 of the number of the total node devices, the number of the target node devices is less than 1/3 of the number of the total node devices, and the gap between the target node devices), specific wrought behaviors can be designated, the use cases and the anomalies are combined, the anomalies can be automatically injected into the block chain, the cost of the anomaly test is saved, and the degree of automation of the anomaly test is improved.

Referring to fig. 5, a flowchart of an anomaly testing method applied to a blockchain system according to another embodiment of the present application is shown. The method can be applied to the distributed system shown in fig. 1, and the execution subject of each step of the method can be node equipment corresponding to the node. The method may comprise at least one of the following steps (510-540).

Step 510, receiving an abnormal logic code sent by the test equipment, wherein the abnormal logic code is generated after the abnormal logic code is injected into the original logic code of the blockchain system, and the abnormal logic code is used for simulating the wrongly behavior.

The specific logic code after the exception injection is described in more detail in the above embodiments, and will not be described herein.

Step 520, a use case execution request sent by the test equipment is received.

Specific use case execution requests are described in more detail in the above embodiments, and are not described in detail herein.

Step 530, executing the test case based on the logic code after the exception injection according to the case execution request.

In some embodiments, the test case is generated from case information in the case execution request. In some embodiments, when the case execution request is a request to execute a case of "number of nodes in query blockchain system", a test case is generated according to the case information of "number of nodes in query blockchain system", and the test case is sent to the target node device. In some embodiments, when the case execution request is a request to execute the case of "deploy contract h in blockchain system", a test case is generated according to the case information of "deploy contract h in blockchain system", and the test case is sent to the target node device.

In some embodiments, the target node device receives the indication information first, drives the abnormal logic code corresponding to the corresponding action according to the indication information, and executes the test case based on the logic code after the abnormal injection and after the driving of the abnormality. That is, at the time of executing the use case, the logical code that the target node apparatus runs is the code after the abnormality has been driven.

In some embodiments, the use case execution request includes indication information, and after receiving the use case execution request, the target node device determines, according to the indication information in the use case execution request, an abnormal logic code corresponding to a target aversion behavior that needs to be driven. In some embodiments, the instruction information is information indicating the wrongly acting behavior of "tamper proposal information" of the operation, and after the target node device receives the use case execution request, the target node device determines, according to the instruction information in the use case execution request, an abnormal logic code corresponding to the target wrongly acting behavior "tamper proposal information" that needs to be driven.

Step 540, an execution log of the test case is sent to the test equipment, and an execution result of the test case is recorded in the execution log.

The specific execution log is described in more detail in the above embodiments, and is not described herein.

According to the technical scheme provided by the embodiment of the application, the target node equipment receives the logic code after the injection of the abnormality sent by the test equipment, and operates the logic code after the injection of the abnormality according to the use case execution request, so that the use case and the abnormal logic code can be automatically combined, the degree of automation is higher, the precision is higher, the cost is lower, and the test period is shorter.

Referring to fig. 6, a flowchart of an anomaly testing method applied to a blockchain system according to another embodiment of the present application is shown. The method can be applied to the distributed system shown in fig. 1, and the execution subject of each step of the method can be target node equipment corresponding to the target node. The method may include at least one of the following steps (610-660).

And step 610, receiving logic codes after exception injection sent by the test equipment.

Step 620, receiving a use case execution request sent by the test equipment.

Step 630, according to the use case execution request, calling the API corresponding to the abnormal logic code.

In some embodiments, each exception action corresponds to a section of exception logic code, and each section of exception logic code also corresponds to an API, that is, each exception logic code corresponding to an exception action provides a program interface, so that the target node device may access the exception logic code corresponding to a specific exception action through the API. APIs represent the ability of exception logic code to provide services externally. In some embodiments, based on the API to which the exception logic code corresponds, the corresponding exception logic code may be accessed via HTTP (HyperText Transfer Protocol ) and code segment names.

In step 640, in the process of executing the test case, the test case is executed by driving the abnormal logic code through the API.

In some embodiments, the target offence is "tamper proposal information", and after the target node device receives such indication information, the exception logic code corresponding to the "tamper proposal information" is driven through the API, so that the code running on the target node device is injected with the "tamper proposal information" offence before the use case is executed. That is, when the use case is executed, the anomaly of "tamper proposal information" has been simulated in the target node apparatus.

Step 650, sending an execution log of the test case to the test equipment, wherein an execution result of the test case is recorded in the execution log.

Step 660, stopping calling the API corresponding to the abnormal logic code after the test case is executed.

In some embodiments, after the test case is executed, the API corresponding to the abnormal logic code is stopped being called, that is, the code running in the target node device at this time is the code that has not started the abnormality, which means that the API can be called again to drive other abnormal logic codes when other abnormalities are tested. In colloquial terms, after each exception test is completed, the exception code in the code is zeroed, and when the next test is abnormal, the corresponding code segment is called again.

According to the technical scheme provided by the embodiment of the application, various abnormal logic codes are injected into the original codes of the blockchain, and according to different wrongly-acting behaviors required to be tested, the API interfaces corresponding to the different abnormal logic codes are called to drive the different abnormal logic codes, so that the abnormal injection is not required to be executed once each time of use case execution, the abnormal logic codes are not required to be reinjected into the original logic codes when different wrongly-acting behaviors are simulated, the simulation of the wrongly-acting behaviors is more convenient and quick, the combination of the use case and the abnormal test is more automatic, and the corresponding cost of the abnormal test is lower.

Referring to fig. 7, a flowchart of an anomaly testing method applied to a blockchain system according to another embodiment of the present application is shown. The method can be applied to the distributed system shown in fig. 1. The method may comprise at least one of the following steps (S1-S13).

And S1, determining the instrumentation point in the original logic code by the test equipment according to the action corresponding to the abnormal logic code.

Blockchain project engineering is pulled from the GIT (warehouse of managed code), and FailPoint-object instrumentation points are injected for code that needs to simulate bad behavior.

And S2, the testing equipment injects abnormal logic codes into the instrumentation point to generate logic codes after abnormal injection.

And S3, compiling the logic code after the abnormal injection by the test equipment to generate an executable file.

Activating the FailPoint code through an enable command, generating an intermediate file and activating an instruction: "xxxxxxxxxxxxxxxx" (by way of example only, not in actual code) generates an intermediate file. For the exception logic code injected as in fig. 4, the resulting intermediate file is shown as 800 in fig. 8 (the code in fig. 8 is merely an example and is not an actual code). 801 and 802 in fig. 8 correspond to intermediate files corresponding to the two pieces of code of 401 in fig. 4. The method can be implemented by instructions: "yyyyyyyyyyyy" (by way of example only, not actual code) clears the intermediate file.

And (3) automatically compiling project engineering based on codes carrying the intermediate file of the tamper proposal, and generating a binary file, namely, an executable file.

And S4, the test equipment sends the executable file to the target node equipment.

In some embodiments, the executable file is issued to all node devices in the blockchain system.

And S5, determining target node equipment simulating the wrongly-acting behavior from at least one node equipment according to the abnormal simulation scene.

In some embodiments, the executable file is sent to the target node device according to a different BFT consensus scenario.

And S6, determining target disfiguring behaviors to be simulated by the target node equipment from a plurality of different disfiguring behaviors.

In some embodiments, "tamper proposal information" is selected as the target offending action.

Step S7, the test equipment sends a case execution request to the target node equipment, wherein the case execution request is used for requesting the target node equipment to execute the test case based on the logic code after the exception injection, and the case execution request also comprises indication information of target wrongly acting.

In step S8, the target node device determines the target abnormal logic code related to the target wrongly behavior from the abnormal logic codes according to the indication information of the target wrongly behavior.

Step S9, the target node equipment calls an API corresponding to the target abnormal logic code.

Step S10, the target node equipment drives the abnormal logic code to execute the test case through the API in the process of executing the test case.

The API driving mode is adopted to automatically trigger the activation of the 'tamper proposal' scene to open and activate the API: http:// xx. Xxx/xxxx/yourproject/package/pro-sac_nil_error (by way of example only, not an actual code). Where package is the packet name of the file in which the exception logical code is injected, proposal_nil_error is the failure name of "tamper proposal information", and yourproject is the executable file.

Referring to fig. 9, 900 in fig. 9 is a schematic diagram of a use case execution request sent by a test device. In which fig. 9 shows only a part (the code in fig. 9 is merely an example, and is not an actual code). And 901, when an abnormal scene is started, the test equipment sends indication information to the target node equipment, wherein the indication information is used for indicating the target node equipment to start the disfiguring action of 'tamper proposal information'. 902 is a specific use case execution request.

Step S11, the target node device sends an execution log to the test device.

Before the automatic use case is executed, the API drives the abnormal scene, and the execution state log is recorded under the directory appointed by the node, so that the subsequent query is convenient.

Step S12, the target node equipment stops calling the API corresponding to the abnormal logic code.

In fig. 9, 903 is a request for closing an exception, and after receiving the request, the target node device stops calling the API corresponding to the exception logic code.

Steps S12 and S11 are not sequential.

Step S13, the test device generates a test report.

The test equipment analyzes the BFT consensus state, when the fault-tolerant nodes which do not meet the BFT are simulated, such as 4 total nodes, two normal nodes and two attack nodes of tamper proposal information, the BFT does not meet the condition that the number of the normal nodes is more than 2/3 nodes, the consensus is not achieved, and error information is returned, as follows: { "id": "yyyyyyyyyyy", "yyyyyy", "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy: "yy", "yyy": { "yyyyyy } (by way of example only, not an actual code).

In some embodiments, a total of 4 node devices form a blockchain network, if a single-node man-in-the-middle tamper proposal information attack is simulated, node a is caused to be disqualified, but the BFT consensus mechanism allows one fault-tolerant node in the blockchain network formed by 4 nodes, so that the whole blockchain service still operates normally, an automation use case executes normally, but if the simulation nodes A and B execute the tamper proposal attack simultaneously, the BFT consensus is not satisfied, finally the whole blockchain network is caused to be unavailable, the automation use case fails to execute, and the blockchain enters a blocking state.

In some embodiments, the test device sums up the analysis result of the previous step, and generates a corresponding test report, thereby facilitating the test personnel to locate the problem.

Referring to FIG. 10, a block diagram of an anomaly testing method for a blockchain system is shown, according to one embodiment of the present application.

As shown in a method flow 1000 in fig. 10, the test device dynamically injects an abnormal logic code into a source code of the blockchain system, and compiles automatically, meanwhile submits device information of the node device, and issues a compiled executable file to the node device, the node device drives an abnormal scene, namely a target behavior by using an API, and simultaneously sends a test case to the node device, the target node device records the abnormal running log in an execution log, generates a test report after the execution of the case is completed, and stops calling the API to drive the abnormal scene.

Referring to fig. 11, a schematic diagram of an implementation environment of an anomaly testing method applied to a blockchain system according to an embodiment of the present application is shown.

In the blockchain product testing, as shown in the method flow 1100 in fig. 11, the blockchain product is developed first, each module is tested in the REQ, the REQ platform issues the source code, and after the verification is passed, the testing flow is entered.

After the test, the exception test is carried out, the "wrongly behavior" code, namely the exception logic code, is dynamically injected, and after automatic compiling and issuing are carried out, the target node equipment is utilized to call the API to drive the exception scene, namely the target wrongly behavior. And the target node equipment receives the use case execution request and the test use case sent by the test equipment, executes the automatic use case, and stops calling the API driving exception scene after the use case is executed.

After the use case is executed, BFT consensus results and use case execution logs are analyzed simultaneously, a test report is generated, the blockchain source codes are adjusted based on the test report, and finally the adjusted blockchain source codes are issued.

Referring to fig. 12, a schematic diagram of an implementation environment of an anomaly testing method applied to a blockchain system according to another embodiment of the present application is shown.

In the implementation environment 1200, a total of two major segments are split.

Part is exception injection and compilation. And pulling a source code of the blockchain system from the GIT, determining a stub point after multi-layer compiling, injecting an abnormal logic code corresponding to the wrongness behavior into the source code, generating an intermediate file according to an Enable command, obtaining an executable file after binary coding, and transmitting the executable file to node equipment.

The other part is exception execution and recovery. Before executing the use case, determining target node equipment needing to trigger the exception, sending an API request to HTTP through the target node equipment, implementing target wrongly behavior, and driving the exception scene. After the abnormal scene is started, executing the use case, and after the use case is executed, stopping calling the API to drive the abnormal scene.

The following are device embodiments of the present application, which may be used to perform method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

Referring to FIG. 13, a block diagram of an anomaly testing device for a blockchain system according to an embodiment of the present application is shown. The device has the function of realizing the method example executed by the test equipment side, and the function can be realized by hardware or can be realized by executing corresponding software by hardware. The apparatus may be implemented as a test device or as part of a test device. As shown in fig. 13, the apparatus 1300 may include: a code injection module 1310, a code transmission module 1320, a request transmission module 1330, and a log reception module 1340.

The code injection module 1310 is configured to inject an abnormal logic code into an original logic code of the blockchain system, and generate an logic code after the abnormal injection; wherein the abnormal logic code is a logic code for simulating a bad behavior.

The code sending module 1320 is configured to send the logic code after the exception is injected to at least one node device in the blockchain system.

The request sending module 1330 is configured to send a case execution request to a target node device in the blockchain system, where the case execution request is used to request the target node device to execute a test case based on the logic code after the exception is injected.

The log receiving module 1340 is configured to receive an execution log sent by the target node device, where an execution result of the test case is recorded in the execution log.

In some embodiments, the code sending module 1320 is configured to compile the logic code after the exception is injected to generate an executable file.

The code sending module 1320 is configured to send the executable file to the at least one node device in the blockchain system.

In some embodiments, the code injection module 1310 is configured to determine an instrumentation point in the original logic code according to the aversion behavior corresponding to the abnormal logic code.

The code injection module 1310 is configured to inject the abnormal logic code at the instrumentation point, and generate the logic code after the abnormal injection.

In some embodiments, as shown in fig. 14, the apparatus further comprises a node device determination module 1350.

The node device determining module 1350 is configured to determine, from the at least one node device, the target node device that simulates the bad behavior according to an abnormal simulation scenario.

In some embodiments, as shown in fig. 14, the node device determination module 1350 includes a single node device determination unit 1352 and a multi-node device determination unit 1354.

The single-node device determining unit 1352 is configured to determine, from the at least one node device, one node device that simulates the bad behavior as the target node device, in a case where the anomaly simulation scene is a single-node anomaly scene. Or, the multi-node device determining unit 1354 is configured to determine, from the at least one node device, a plurality of node devices simulating the wrongly performed behavior as the target node device, in a case where the abnormality simulation scene is a multi-node abnormality scene.

In some embodiments, the multi-node device determining unit 1354 is configured to determine, when the anomaly simulation scenario is a multi-node anomaly scenario, the number N of node devices simulating the bad behavior according to the total number of node devices participating in the test case execution in the blockchain system and a consensus achievement condition, where N is an integer greater than 1; the consensus condition refers to the requirement of the voting consensus mechanism adopted by the blockchain system for the number of node devices.

The multi-node device determining unit 1354 is configured to determine N node devices from the at least one node device, as the target node device.

In some embodiments, the exception logic code is used to simulate a variety of different offensive behaviors.

In some embodiments, as shown in FIG. 14, the apparatus further comprises a bad behavior determination module 1360.

The wrongly behavior determining module 1360 is configured to determine, from the plurality of different wrongly behaviors, a target wrongly behavior that the target node device needs to simulate; the use case execution request further comprises indication information of the target wrongly behavior.

In some embodiments, as shown in fig. 14, the apparatus further comprises a test case generation module 1370.

The test case generation module 1370 is configured to generate the test case according to a task to be tested of the blockchain system.

The test case generation module 1370 is further configured to send the test case to a node device in the blockchain system that participates in the execution of the test case.

In some embodiments, as shown in fig. 14, the apparatus further comprises a test report generation module 1380.

The test report generating module 1380 is configured to perform statistical analysis on an execution result of each node device for the test case according to an execution log reported by each node device participating in the execution of the test case in the blockchain system.

The test report generating module 1380 is further configured to generate a test report according to the result of the statistical analysis.

Referring to fig. 15, a block diagram of an anomaly testing device applied to a blockchain system according to another embodiment of the present application is shown. The device has the function of realizing the method example executed by the target node equipment side, and the function can be realized by hardware or can be realized by executing corresponding software by hardware. The apparatus may be implemented as a target node device or as part of a target node device. As shown in fig. 15, the apparatus 1500 may include: a code receiving module 1510, a request receiving module 1520, a use case executing module 1530, and a log transmitting module 1540.

The code receiving module 1510 is configured to receive an abnormal injected logic code sent by a test device, where the abnormal injected logic code is generated after an abnormal logic code is injected into an original logic code of the blockchain system, and the abnormal logic code is a logic code for simulating a bad behavior.

The request receiving module 1520 is configured to receive a use case execution request sent by the test device, where the use case execution request is used to request the target node device to execute a test use case based on the logic code after the exception is injected.

The case execution module 1530 is configured to execute the test case based on the logic code after the exception injection according to the case execution request.

The log sending module 1540 is configured to send an execution log of the test case to the test device, where the execution log records an execution result of the test case.

In some embodiments, as shown in fig. 16, the use case execution module 1530 includes an interface call unit 1532 and a code driving unit 1534.

The interface calling unit 1532 is configured to call an API corresponding to the abnormal logic code according to the use case execution request.

The code calling unit 1534 is configured to drive, through the API, the exception logic code to execute the test case in the process of executing the test case.

In some embodiments, the exception logic code is configured to simulate a plurality of different wrongly performed actions, and the use case execution request further includes information indicative of a target wrongly performed action of the plurality of different wrongly performed actions.

In some embodiments, the interface calling unit is configured to determine, according to the indication information of the target aversion behavior, a target exception logic code related to the target aversion behavior from the exception logic codes;

and the interface calling unit is used for calling the API corresponding to the target abnormal logic code.

In some embodiments, the interface calling unit is further configured to stop calling the API corresponding to the abnormal logic code after the test case is executed.

In some embodiments, as shown in fig. 16, the apparatus further comprises a use case receiving module 1550.

The use case receiving module 1550 is configured to receive the test use case sent by the test device, where the test use case is a task to be tested according to the blockchain system.

It should be noted that, in the apparatus provided in the foregoing embodiment, when implementing the functions thereof, only the division of the foregoing functional modules is used as an example, in practical application, the foregoing functional allocation may be implemented by different functional modules, that is, the internal structure of the device is divided into different functional modules, so as to implement all or part of the functions described above. In addition, the apparatus and the method embodiments provided in the foregoing embodiments belong to the same concept, and specific implementation processes of the apparatus and the method embodiments are detailed in the method embodiments and are not repeated herein.

Fig. 17 shows a block diagram of a computer device according to an exemplary embodiment of the present application.

In general, the computer device 1700 includes: a processor 1701 and a memory 1702.

The processor 1701 may include one or more processing cores, such as a 4-core processor, a 17-core processor, or the like. The processor 1701 may be implemented in at least one hardware form of DSP (Digital Signal Processing ), FPGA (Field Programmable Gate Array, field programmable gate array), PLA (Programmable Logic Array ). The processor 1701 may also include a main processor and a coprocessor, the main processor being a processor for processing data in an awake state, also referred to as a CPU (Central Processing Unit ); a coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 1701 may be integrated with a GPU for use in connection with rendering and rendering of content to be displayed by the display screen. In some embodiments, the processor 1701 may also include an AI (Artificial Intelligence ) processor for processing computing operations related to machine learning.

Memory 1702 may include one or more computer-readable storage media, which may be tangible and non-transitory. Memory 1702 may also include high-speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In some embodiments, a non-transitory computer readable storage medium in the memory 1702 stores a computer program that is loaded and executed by the processor 1701 to implement the anomaly testing method on the test device side or the anomaly testing method on the target node device side described above.

Those skilled in the art will appreciate that the architecture shown in fig. 17 is not limiting as to the computer device 1700, and may include more or fewer components than shown, or may combine certain components, or employ a different arrangement of components.

In an exemplary embodiment, there is also provided a computer-readable storage medium in which a computer program is stored, which when executed by a processor, implements the above-described abnormality test method on the test device side, or the abnormality test method on the target node device side.

Alternatively, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random Access Memory ), SSD (Solid State Drives, solid state disk), or optical disk, etc. The random access memory may include, among other things, reRAM (Resistance Random Access Memory, resistive random access memory) and DRAM (Dynamic Random Access Memory ).

In an exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program stored in a computer readable storage medium. The processor of the terminal device reads the computer program from the computer-readable storage medium, and the processor executes the computer program so that the terminal device executes the above-described abnormality test method on the side of the test device or the abnormality test method on the side of the target node device.

It should be understood that references herein to "a plurality" are to two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship. In addition, the step numbers described herein are merely exemplary of one possible execution sequence among steps, and in some other embodiments, the steps may be executed out of the order of numbers, such as two differently numbered steps being executed simultaneously, or two differently numbered steps being executed in an order opposite to that shown, which is not limited by the embodiments of the present application.

The foregoing description of the exemplary embodiments of the present application is not intended to limit the invention to the particular embodiments disclosed, but on the contrary, the intention is to cover all modifications, equivalents, alternatives, and alternatives falling within the spirit and scope of the invention.

Claims

1. An anomaly testing method for a blockchain system, the method performed by a testing device, the method comprising:

2. The method of claim 1, wherein the sending the exception-injected logical code to at least one node device in the blockchain system comprises:

Compiling the logic code after the exception injection to generate an executable file;

and transmitting the executable file to the at least one node device in the blockchain system.

3. The method of claim 1, wherein the injecting the exception logic code into the original logic code of the blockchain system generates the exception-injected logic code, comprising:

determining instrumentation points in the original logic codes according to the wrought behaviors corresponding to the abnormal logic codes;

and injecting the abnormal logic code at the instrumentation point, and generating the logic code after the abnormal injection.

4. The method according to claim 1, wherein the method further comprises:

and determining the target node equipment simulating the wrongly-acting behavior from the at least one node equipment according to an abnormal simulation scene.

5. The method of claim 4, wherein said determining said target node device from said at least one node device that simulates said offensive behavior based on an anomaly simulation scenario comprises:

determining one node device simulating the wrongly behavior from the at least one node device as the target node device under the condition that the anomaly simulation scene is a single-node anomaly scene;

Or,

and determining a plurality of node devices simulating the wrongly-acting behavior from the at least one node device as the target node device under the condition that the abnormality simulation scene is a multi-node abnormality scene.

6. The method according to claim 5, wherein the determining, from the at least one node device, a plurality of node devices simulating the wrongly behavior as the target node device in the case where the abnormality simulation scene is a multi-node abnormality scene, includes:

under the condition that the abnormal simulation scene is a multi-node abnormal scene, determining the number N of node equipment simulating the wrongly acting behavior according to the total number of node equipment participating in the execution of the test case and consensus achievement conditions in the blockchain system, wherein N is an integer larger than 1; wherein the consensus achieving condition refers to the number requirement of a voting consensus mechanism adopted by the blockchain system for node equipment;

and determining N node devices from the at least one node device as the target node device.

7. The method of claim 1, wherein the exception logic code is configured to simulate a plurality of different offensive behaviors;

The method further comprises the steps of:

determining target aversion behaviors to be simulated by the target node equipment from the plurality of different aversion behaviors;

the use case execution request further comprises indication information of the target wrongly behavior.

8. The method according to claim 1, wherein the method further comprises:

generating the test case according to a task to be tested of the blockchain system;

and sending the test case to node equipment participating in the execution of the test case in the blockchain system.

9. The method of claim 1, further comprising, after receiving the execution log sent by the target node device:

according to the execution logs reported by each node device participating in the execution of the test case in the blockchain system, carrying out statistical analysis on the execution results of each node device aiming at the test case;

and generating a test report according to the result of the statistical analysis.

10. An anomaly testing method applied to a blockchain system, the blockchain system including a plurality of node devices, the method performed by a target node device of the plurality of node devices, the method comprising:

11. The method of claim 10, wherein the executing the test case based on the exception injected logic code according to the case execution request comprises:

calling an Application Programming Interface (API) corresponding to the abnormal logic code according to the use case execution request;

and in the process of executing the test case, driving the abnormal logic code to execute the test case through the API.

12. The method of claim 11, wherein the exception logic code is configured to simulate a plurality of different wrongly performed actions, and wherein the use case execution request further includes information indicative of a target wrongly performed action of the plurality of different wrongly performed actions;

the calling the application programming interface API corresponding to the abnormal logic code according to the use case execution request comprises the following steps:

determining a target abnormal logic code related to the target offensive behavior from the abnormal logic codes according to the indication information of the target offensive behavior;

and calling an API corresponding to the target abnormal logic code.

13. The method of claim 11, wherein the method further comprises:

and stopping calling the API corresponding to the abnormal logic code after the test case is executed.

14. The method according to claim 10, wherein the method further comprises:

and receiving the test case sent by the test equipment, wherein the test case is generated according to a task to be tested of the blockchain system.

15. An anomaly testing device for a blockchain system, the device comprising:

16. An anomaly testing device for a blockchain system, the device comprising:

17. A computer device comprising a processor and a memory in which a computer program is stored, the computer program being loaded and executed by the processor to implement the method of any one of claims 1 to 9 or to implement the method of any one of claims 10 to 14.

18. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program, which is loaded and executed by a processor to implement the method of any one of claims 1 to 9 or to implement the method of any one of claims 10 to 14.

19. A computer program product comprising computer instructions stored in a computer readable storage medium, the computer instructions being read from the computer readable storage medium and executed by a processor to implement the method of any one of claims 1 to 9 or to implement the method of any one of claims 10 to 14.