System testing method, device, system, equipment and storage medium

Abstract

The invention relates to a system test method, device and system, equipment and a storage medium, relates to the technical field of block chains, and can solve the problem of large test result deviation. The system test method is applied to test equipment, and comprises the following steps: generating test data corresponding to a test case executed by simulation fault node equipment in a block chain system; sending a test request message to the simulated fault node equipment; the test request message is used for indicating the simulation fault node equipment to publish test data in the block chain system; obtaining state information after the block chain system executes the consensus operation on the test data; determining a stability result of the block chain system according to the state information; the stability result comprises at least one of a target state type and a target stability level corresponding to the block chain system.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a system testing method, device, system, equipment and storage medium. Background Art

[0002] Chaos engineering is often used to test distributed systems. It proactively creates failures to identify system weaknesses before they cause disruptions, thereby building users' confidence in the system's ability to withstand failures in production environments.

[0003] At present, the common system testing method is to conduct chaos engineering testing in a simulated test environment. Since the simulated test environment is simpler than the actual production environment, the network topology type and fault type are relatively simple, the test results have large deviations and are of low reference value. Summary of the invention

[0004] The present application provides a system testing method, apparatus, system, equipment and storage medium for solving the problem of large deviation in test results.

[0005] The technical solution of the embodiment of the present application is as follows:

[0006] According to a first aspect of an embodiment of the present application, a system testing method is provided, which is applied to a testing device; the system testing method includes: generating test data corresponding to a test case executed by a simulated faulty node device in a blockchain system; sending a test request message to the simulated faulty node device; the test request message is used to instruct the simulated faulty node device to publish the test data in the blockchain system; obtaining status information of the blockchain system after performing a consensus operation on the test data; determining a stability result of the blockchain system based on the status information; the stability result includes: at least one of a target status type and a target stability level corresponding to the blockchain system.

[0007] Optionally, the test device includes: a network module and a Byzantine message constructor; the network module and the Byzantine message constructor communicate through a message queue; the method for generating test data corresponding to the test case executed by the simulated faulty node device in the blockchain system includes: receiving the test case through the network module; and constructing the test data through the Byzantine message constructor according to the test case.

[0008] Optionally, the method of sending a test request message to a simulated fault node device includes: instructing a network module to send the test request message through a target communication connection; the target communication connection includes a unicast communication connection or a multicast communication connection.

[0009] Optionally, the test data includes at least one of invalid transactions, invalid proposals, and invalid votes.

[0010] Optionally, the system testing method also includes: when the stability result meets a preset alarm condition, sending an alarm message to the management terminal.

[0011] Optionally, the number of node devices simulating the faulty node devices and the number of node devices of the blockchain system satisfy a preset condition of the Byzantine fault tolerance algorithm.

[0012] According to a second aspect of an embodiment of the present application, a system testing method is provided, which is applied to a simulated faulty node device in a blockchain system; the system testing method includes: obtaining test data corresponding to a test case executed by the simulated faulty node device; publishing the test data in the blockchain system, and obtaining status information after the blockchain system performs a consensus operation on the test data; sending the status information to a testing device; and the testing device is used to determine a stability result of the blockchain system based on the status information.

[0013] Optionally, a connection is provided between the simulated fault node device and a network module in the test device; a method for obtaining test data corresponding to a test case executed by the simulated fault node device comprises: receiving a test request message sent by the network module through a target communication connection; the test request message is used to instruct the simulated fault node device to publish test data in the blockchain system; the target communication connection comprises a unicast communication connection or a multicast communication connection.

[0014] According to a third aspect of an embodiment of the present application, a system testing device is provided, which is applied to a testing device; the system testing device includes: a generating unit, a communication unit and a determining unit; the generating unit is used to generate test data corresponding to a test case executed by a simulated faulty node device in a blockchain system; the communication unit is used to send a test request message to the simulated faulty node device; the test request message is used to instruct the simulated faulty node device to publish the test data in the blockchain system; the communication unit is also used to obtain status information of the blockchain system after performing a consensus operation on the test data; the determining unit is used to determine a stability result of the blockchain system according to the status information; the stability result includes: at least one of a target status type and a target stability level corresponding to the blockchain system.

[0015] Optionally, the test device includes: a network module and a Byzantine message constructor; the network module and the Byzantine message constructor communicate through a message queue; a generation unit, specifically used to: receive test cases through the network module; and construct test data through the Byzantine message constructor according to the test cases.

[0016] Optionally, the communication unit is specifically used to: instruct the network module to send a test request message through a target communication connection; the target communication connection includes a unicast communication connection or a multicast communication connection.

[0017] Optionally, the test data includes at least one of invalid transactions, invalid proposals, and invalid votes.

[0018] Optionally, the system testing device also includes: an alarm unit; the alarm unit is used to send an alarm message to the management terminal when the stability result meets the preset alarm condition.

[0019] Optionally, the number of node devices simulating the faulty node devices and the number of node devices of the blockchain system satisfy a preset condition of the Byzantine fault tolerance algorithm.

[0020] According to a fourth aspect of an embodiment of the present application, a system testing device is provided, which is applied to a simulated faulty node device in a blockchain system; the system testing device includes: a communication unit and a processing unit; the communication unit is used to obtain test data corresponding to the test case executed by the simulated faulty node device; the processing unit is used to publish the test data in the blockchain system, and obtain the status information after the blockchain system performs a consensus operation on the test data; the communication unit is also used to send status information to the testing device; the testing device is used to determine the stability result of the blockchain system according to the status information.

[0021] Optionally, the simulated fault node device is connected to a network module in the test device; the communication unit is specifically used to: receive a test request message sent by the network module through a target communication connection; the test request message is used to instruct the simulated fault node device to publish test data in the blockchain system; the target communication connection includes a unicast communication connection or a multicast communication connection.

[0022] According to a fifth aspect of an embodiment of the present disclosure, a system testing system is provided, comprising: a test device and a simulated fault node device in a blockchain system; the test device is used to execute any one of the optional system testing methods in the above-mentioned first aspect; and the simulated fault node device is used to execute any one of the optional system testing methods in the above-mentioned second aspect.

[0023] According to the sixth aspect of an embodiment of the present application, an electronic device is provided, which may include: a processor and a memory for storing processor executable instructions; wherein the processor is configured to execute instructions to implement any one of the above-mentioned first aspects, or any one of the optional system testing methods in the second aspect.

[0024] According to the seventh aspect of the embodiment of the present application, a computer-readable storage medium is provided, on which instructions are stored. When the instructions in the computer-readable storage medium are executed by a processor of a system testing device, the system testing device is enabled to execute any one of the above-mentioned first aspect, or any one of the optional system testing methods in the second aspect.

[0025] The technical solution provided by this application brings at least the following beneficial effects:

[0026] Based on any of the above aspects, the present application can execute the test cases required for the chaos engineering experiment in the blockchain system, and then determine the test results of the chaos engineering experiment in the blockchain system according to the consensus state of the blockchain system. Therefore, compared with the general method, the present application can simulate the corresponding failure behavior of at least one node device in the blockchain system, increase the richness of the simulation situation, get closer to the actual production environment, and effectively improve the referenceability of the test results; at the same time, the present application defines the stable state as the baseline of chaos engineering in advance, realizes the division of stability levels, can give more accurate system test conclusions, and help to predict the trend of system status. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application, and do not constitute an improper limitation on the present application.

[0028] Figure 1 A schematic diagram of a system testing system provided in an embodiment of the present application;

[0029] Figure 2 The following is a schematic diagram showing a process of a system testing method provided in an embodiment of the present application. Figure 1 ;

[0030] Figure 3 The following is a schematic diagram showing a process of a system testing method provided in an embodiment of the present application. Figure 2 ;

[0031] Figure 4 The following is a schematic diagram showing a process of a system testing method provided in an embodiment of the present application. Figure 3 ;

[0032] Figure 5 The structure of a system testing device provided in an embodiment of the present application is shown in FIG. Figure 1 ;

[0033] Figure 6 The structure of a system testing device provided in an embodiment of the present application is shown in FIG. Figure 2 ;

[0034] Figure 7 The structure of a system testing device provided in an embodiment of the present application is shown in FIG. Figure 3 . DETAILED DESCRIPTION

[0035] In order to enable ordinary persons in the art to better understand the technical solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0036] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0037] It should also be understood that the term “comprising” indicates the presence of described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements and / or components.

[0038] In order to facilitate the understanding of the present application, the relevant elements involved in the present application are now described.

[0039] Blockchain Technology

[0040] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" (i.e. recording transaction data) and jointly maintain a complete distributed database. Blockchain technology has been widely used in many fields because of its decentralization (i.e. no central node device), openness and transparency, each computing device can participate in database recording, and data can be quickly synchronized between computing devices.

[0041] A blockchain network may include multiple blockchain node devices. A blockchain node device is a device with communication functions and storage functions, such as a device storing a blockchain. For ease of description, this application uses a node device to represent a blockchain node device. In other words, all node devices involved in this application can be used to represent a blockchain node device.

[0042] Each node device can both receive and generate information. Different node devices maintain communication by maintaining a common blockchain. Specifically, in a blockchain network, any node device can generate a new block based on transaction-related data sent by the client, and notify other node devices in the form of broadcast, and other node devices can verify this block. When all node devices in the blockchain network reach a consensus, the new block can be added to the blockchain.

[0043] Node devices are divided into consensus node devices and ordinary node devices. Consensus node devices have block generation and voting rights. Transactions are sorted and packaged into blocks by consensus node devices. Once consensus is completed, they are confirmed as legal blocks. Ordinary node devices do not have block generation and voting rights, and are the same as consensus node devices in other aspects. They can synchronize all the original data on the blockchain, accept transaction data and broadcast it to other node devices. The management of ordinary node devices refers to the addition and deletion of ordinary node devices, which is achieved by modifying the list of connected node devices in the configuration file. For a new ordinary node device to access the network, it needs to connect to the node device that is already in the blockchain network.

[0044] The node device in this application can be understood as a processing unit. In one implementation, the node device can be a physical device, such as a server or a terminal device. In another implementation, the node device can be a virtual computer; a virtual computer is a general term for the operating environment virtualized by software in all types of virtualized devices, including virtual machines and containers.

[0045] As described in the background technology, the network topology type of the blockchain system can be any one of a star network topology, a ring network topology, a tree network topology, and a random pattern generated underlying network topology. The actual production environment is relatively complex.

[0046] However, the common system testing method is to conduct chaos engineering testing in a simulated test environment. Compared with the actual production environment, the simulated test environment is simpler in composition, and the network topology type and fault type are relatively simple. Therefore, the test results at the theoretical level cannot be regarded as the test results in the actual production environment.

[0047] Based on this, in the system testing method of the present application, the target node device can obtain the test data published in the blockchain system. Among them, the test data is the data generated by the blockchain system executing the test case, and the test case is used to instruct the simulated fault node device in the blockchain system to execute the fault to be tested. Then, the target node device can obtain the status information after the blockchain system performs the consensus operation on the test data, and further determine the test result of the test case in the blockchain system based on the status information.

[0048] In this application, the test cases required for the chaos engineering experiment can be executed in the blockchain system, and then the test results of the chaos engineering experiment in the blockchain system can be determined according to the consensus state of the blockchain system. Therefore, compared with the general method, this application can simulate the corresponding failure behavior of at least one node device in the blockchain system, increase the richness of the simulation situation, get closer to the actual production environment, and effectively improve the referenceability of the test results.

[0049] The following is an exemplary description of the system testing method provided in the embodiment of the present application in conjunction with the accompanying drawings:

[0050] Figure 1 A schematic diagram of a system test system provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the system test system may include: multiple node devices 101, test equipment 102 and management terminal 103.

[0051] In some embodiments, the multiple node devices 101 provided in the present application may be node devices in a blockchain system, and the blockchain system may be deployed in a consortium chain manner.

[0052] Among them, the consortium chain, also known as the consortium blockchain, refers to a blockchain whose consensus process is controlled by pre-selected node devices 101. In the consortium chain, all or part of the functions are only open to the node devices 101 storing the consortium chain, and each node device 101 in the consortium chain can customize the read and write permissions, query permissions, etc. based on needs.

[0053] In some embodiments, the node device 101 in the blockchain system is a device with communication and storage functions, which can be a single server, or a server cluster composed of multiple servers. In some implementations, the server cluster can also be a distributed cluster. This application does not limit the specific implementation of the node device 101.

[0054] Optionally, multiple node devices 101 can establish connections through any one of the star network topology, ring network topology, tree network topology and random pattern generated underlying network topology, which is not limited in this application.

[0055] In some embodiments, the test device 102 can be deployed on any electronic device and implemented through a software development kit (SDK) corresponding to the blockchain system. The electronic device communicates with the node device 101 in the blockchain network to implement the corresponding functions of the test device 102.

[0056] In some embodiments, the management terminal 103 may be a device held by a system maintenance personnel, a chip in the device, or a system on chip in the device. The device may be any electronic product that can interact with a user through one or more methods such as a keyboard, a touch pad, a touch screen, a remote control, voice interaction, or a handwriting device, such as a mobile phone, a tablet computer, a PDA, a personal computer (PC), a wearable device, a smart TV, etc.

[0057] In one embodiment, the test device 102 may be a functional module on the management terminal 103 or an independently configured physical device.

[0058] It is easy to understand that when the test device 102 is a functional module on the management terminal 103, the interaction between the test device 102 and the management terminal 103 is the interaction between the internal modules of the management terminal 103. In this case, the interaction process between the two is the same as "the interaction process between the two when the test device 102 is an independently set physical device".

[0059] For ease of understanding, Figure 1 Taking “the test device 102 being an independently-set physical device” as an example, the test device 102 can be connected to the node device 101 and the management terminal 103 respectively.

[0060] It should be noted that the node device 101 , the test device 102 and the management terminal 103 mentioned above can all be referred to as electronic devices.

[0061] The system testing method provided in the embodiment of the present application can be applied to the aforementioned Figure 1 The test device 102 in the application scenario is shown.

[0062] Figure 2 Take the blockchain system including node device 0, node device 1, node device 2 and simulated fault node device as an example for explanation. Figure 2 As shown, the system testing method may include:

[0063] S1. The test device generates test data corresponding to the test case executed by the simulated fault node device in the blockchain system. The test data is the data generated by the blockchain system executing the test case, and the test case is used to instruct the simulated fault node device in the blockchain system to execute the fault to be tested.

[0064] Optionally, the simulated fault node device includes at least one node device of the blockchain system, including a consensus node device or a common node device.

[0065] Optionally, the faults to be tested may include non-Byzantine faults such as network failures and resource failures, and may also include Byzantine faults such as invalid transactions, invalid proposals, and invalid votes.

[0066] Among them, network failure refers to failures that occur in the network, such as network delay and packet loss. Resource failure refers to failures that occur in resource use, such as processor preemption, memory preemption, disk write failure, and disk read failure.

[0067] Optionally, when the fault to be tested is a Byzantine fault, the number of node devices simulating the faulty node device and the number of node devices of the blockchain system meet the preset conditions of the Byzantine fault tolerance (BFT) algorithm.

[0068] It is easy to understand that when the fault to be tested is a Byzantine fault, simulating a faulty node device to test the fault is equivalent to switching a normal node device to a Byzantine node device.

[0069] In order to achieve the goal of multi-center and non-tampering, the multi-node devices in the blockchain network meet certain fault tolerance mechanisms, usually using the Byzantine fault tolerance algorithm, that is, in the consensus blockchain network composed of multi-node devices, if a node device crashes, overflows memory, or acts maliciously, the entire blockchain network can still operate normally. Among them, the number of node devices in the blockchain system is n, and the number of node devices simulating faulty node devices is m, satisfying n≥3m+1.

[0070] S2. The test device sends a test request message to the simulated fault node device.

[0071] The test request message is used to instruct the simulated fault node device to publish test data in the blockchain system. Accordingly, the simulated fault node device can obtain the test data corresponding to the test case executed by the simulated fault node device.

[0072] In one possible implementation, Figure 2 As shown, during the blockchain system executing the test case, the test device can generate test data corresponding to the test case, and instruct the simulated fault node device to publish the test data in the blockchain system using the error message as a carrier, and obtain the status information after the blockchain system performs the consensus operation on the test data. Then, the simulated fault node device sends the status information to the test device.

[0073] Optionally, the test request message may include a node device identifier of a simulated faulty node device.

[0074] Optionally, the node device identifier may include a hash value, a segment identifier (SID), an Internet protocol (IP) address, or a media access control (MAC) address.

[0075] In one possible implementation, Figure 3As shown, in response to the test instructions input by the tester, the management terminal can generate a test case, and then send the test case to the network module of the test device through any communication connection. The Byzantine message constructor of the test device can read the test case from the message queue, such as invalid transactions, invalid proposals or invalid votes, and construct the corresponding error message (i.e., Byzantine message) according to the communication protocol in the blockchain system. Among them, the error message includes the test data corresponding to the test case. Then, the test device can send a test request message to the simulated fault node device.

[0076] In one achievable manner, a simulated faulty node device transmits test data in a blockchain system by issuing an error message, so that the test data participates in the normal consensus process of the blockchain system.

[0077] Among them, any type of communication connection includes: broadcast, multicast or unicast in the blockchain system.

[0078] Optionally, the test instruction can be used to instruct the blockchain system to perform a single chaos engineering experiment, or to perform chaos engineering experiments periodically.

[0079] Optionally, the message queue may be a first in-first out (FIFO) queue.

[0080] In an optional embodiment, in order to avoid wasting communication resources and improve communication efficiency, S2 may specifically include:

[0081] S21. The test device instructs the network module to send a test request message through the target communication connection.

[0082] The target communication connection includes: a unicast communication connection or a multicast communication connection.

[0083] It is easy to understand that when sending a test request message via unicast or multicast, the destination address of the test request message includes the node device identifier of the simulated faulty node device. At this time, the network topology in the blockchain system can be used to determine the transmission path from the management terminal to the simulated faulty node device, which can avoid occupying resources such as interfaces and channels of other node devices when broadcasting messages, and can effectively improve communication efficiency.

[0084] S3. The test device obtains the status information after the blockchain system performs a consensus operation on the test data.

[0085] The consensus operation includes: the consensus node device verifies whether the test data is legal. If the verification is successful, the consensus node device can broadcast a message to the other node devices in the system. The message can indicate that the test data has been verified by the consensus node device, and specifically can include the signature of the consensus node device. As a result, each node device in the system can receive the verification results of the test data by the other node devices. After reaching a consensus, the consensus node device packages the test data into blocks, and then broadcasts the generated blocks to other node devices in the blockchain system.

[0086] Optionally, the status information can be used to describe the consensus process and the stage of the consensus process that the target node device is currently in. For example, the target node device is currently in the pre-voting stage of the consensus process at block height 10. The status information can also include information such as block time and block hash.

[0087] S4. The testing device determines the stability result of the blockchain system based on the status information.

[0088] Specifically, since the consensus process of the blockchain system is usually implemented based on a consensus algorithm, the consensus algorithm may include but is not limited to: BFT algorithm, practical byzantine fault tolerance (PBFT) algorithm, etc. Due to network failure, device failure or other reasons, the consensus status of each node device participating in the consensus in the blockchain system may not be consistent. Therefore, the impact of the test case on the stability, security and activity of the blockchain system, that is, the test result, can be determined based on the status information.

[0089] Optionally, the stability result includes: at least one of a target state type and a target stability level corresponding to the blockchain system.

[0090] Among them, the target state type may include any state type such as a preset stable state, unstable state, alarm state, etc., which is used to characterize the stability state of the blockchain system. The target state type can be divided according to the actual application situation, and this application does not limit this.

[0091] In one feasible way, the test equipment can define the stable state in advance as the baseline of chaos engineering, and determine the target state type of the current blockchain system by obtaining the state information of the consensus algorithm. The target stability level of the consensus algorithm can be divided to evaluate the consensus algorithm.

[0092] Exemplarily, in a preset stable state, the trigger time of the consensus algorithm is set to 10 seconds (s), with the trigger time as the ordinate and the continuous detection time as the abscissa, the test device can obtain a detection curve. Then, according to the difference between the detection value and the value set in the stable state in the detection curve, multiple stability levels can be divided, and corresponding feedback operations can be set based on different target stability levels. For example, when the target stability level is greater than the preset level, an alarm message is generated.

[0093] It should be noted that the above example only uses the trigger time of the consensus algorithm as an example. The consistency of each block information in the consensus process, whether the block height continues to increase, and the stress test of the number of transactions within a certain period of time to obtain the transaction per second (TPS) performance can also be used as a detection indicator of the stable state. The embodiments of the present application are not limited to this.

[0094] The technical solution provided by the above embodiment brings at least the following beneficial effects: From S1-S4, it can be known that in this application, the test cases required for the chaos engineering experiment can be executed in the blockchain system, and then the test results of the chaos engineering experiment in the blockchain system can be determined according to the consensus state of the blockchain system. Therefore, compared with the general method, this application can simulate the corresponding failure behavior of at least one node device in the blockchain system, increase the richness of the simulation situation, get closer to the actual production environment, and effectively improve the referenceability of the test results; at the same time, this application defines the stable state as the baseline of chaos engineering in advance, realizes the division of stability levels, can give more accurate system test conclusions, and help predict the trend of system status.

[0095] In an optional embodiment, Figure 2 The method embodiment shown is based on the combination of Figure 2 ,like Figure 4 As shown, the method also includes:

[0096] S5. When the stability result meets the preset alarm condition, the test device sends an alarm message to the management terminal.

[0097] Optionally, the preset alarm conditions may include: the block generation time is greater than the preset delay threshold, the block heights of various node devices are inconsistent, and any other condition that may affect the normal operation of the blockchain system.

[0098] The technical solution provided by the above embodiment brings at least the following beneficial effects: As can be seen from S5, when the stability result meets the preset alarm condition, it can be said that the test case has a greater impact on the blockchain system. In addition to the corresponding test results, an alarm message can also be sent to the management terminal so that the test personnel can discover and take measures in time, which can effectively improve the security of the test process.

[0099] It is understandable that, in actual implementation, the system testing device described in the embodiment of the present application may include one or more hardware structures and / or software modules for implementing the aforementioned corresponding system testing method, and these execution hardware structures and / or software modules may constitute an electronic device. It should be easily appreciated by those skilled in the art that, in combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0100] Based on this understanding, an embodiment of the present application also provides a system testing device. Figure 5 The structure of the system test device provided in the embodiment of the present application is shown as follows Figure 1 .like Figure 5 As shown, the system testing device is applied to a testing device, and includes: a generating unit 501 , a communicating unit 502 and a determining unit 503 .

[0101] The generating unit 501 is used to generate test data corresponding to the test case executed by the simulated faulty node device in the blockchain system.

[0102] The communication unit 502 is used to send a test request message to the simulated fault node device; the test request message is used to instruct the simulated fault node device to publish test data in the blockchain system.

[0103] The communication unit 502 is also used to obtain status information after the blockchain system performs a consensus operation on the test data.

[0104] The determination unit 503 is used to determine the stability result of the blockchain system according to the state information; the stability result includes: at least one of the target state type and the target stability level corresponding to the blockchain system.

[0105] Optionally, the test device includes: a network module and a Byzantine message constructor; the network module and the Byzantine message constructor communicate through a message queue; a generation unit 501, specifically used to: receive test cases through the network module; and construct test data through the Byzantine message constructor according to the test cases.

[0106] Optionally, the communication unit 502 is specifically used to: instruct the network module to send a test request message through a target communication connection; the target communication connection includes a unicast communication connection or a multicast communication connection.

[0107] Optionally, the system testing device further includes: an alarm unit 504.

[0108] The alarm unit 504 is used to send an alarm message to the management terminal when the stability result meets the preset alarm condition.

[0109] The embodiment of the present application also provides a system testing device. Figure 6 The structure of the system test device provided in the embodiment of the present application is shown as follows Figure 2 .like Figure 6 As shown, the system testing device is applied to simulated fault node equipment in the blockchain system, including: a communication unit 601 and a processing unit 602.

[0110] The communication unit 601 is used to obtain test data corresponding to the test case executed by the simulated fault node device.

[0111] The processing unit 602 is used to publish the test data in the blockchain system and obtain the status information after the blockchain system performs a consensus operation on the test data.

[0112] The communication unit 601 is also used to send status information to the test device; the test device is used to determine the stability result of the blockchain system based on the status information.

[0113] Optionally, the simulated fault node device is connected to a network module in the test device; the communication unit 601 is specifically used to: receive a test request message sent by the network module through a target communication connection; the test request message is used to instruct the simulated fault node device to publish test data in the blockchain system; the target communication connection includes a unicast communication connection or a multicast communication connection.

[0114] As described above, the embodiment of the present application can divide the functional modules of the test equipment and the simulated fault node equipment according to the above method example. Among them, the above integrated modules can be implemented in the form of hardware or in the form of software functional modules. In addition, it should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. For example, each functional module can be divided according to each function, or two or more functions can be integrated in one processing module.

[0115] Regarding the system testing device in the above embodiment, the specific manner in which each module performs operations and the beneficial effects possessed have been described in detail in the above method embodiment and will not be repeated here.

[0116] The embodiment of the present application also provides a system testing device. Figure 7 The structure of the system test device provided in the embodiment of the present application is shown as follows Figure 3 The system testing device may include at least one processor 221 , a communication bus 222 , a memory 223 and at least one communication interface 224 .

[0117] The processor 221 may be a central processing unit (CPU), a microprocessing unit, an ASIC, or one or more integrated circuits for controlling the execution of the program of the present application.

[0118] The communication bus 222 may include a pathway for transmitting information between the above-mentioned components.

[0119] The communication interface 224 uses any transceiver-like device for communicating with other devices or communication networks, such as electronic devices, Ethernet, radio access networks (RAN), wireless local area networks (WLAN), etc.

[0120] The memory 223 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processing unit through a bus. The memory may also be integrated with the processing unit.

[0121] The memory 223 is used to store the application code for executing the solution of the present application, and the execution is controlled by the processor 221. The processor 221 is used to execute the application code stored in the memory 223, so as to realize the functions in the method of the present application.

[0122] In a specific implementation, as an embodiment, the processor 221 may include one or more CPUs, such as Figure 7 Processor 0 and processor 1 in.

[0123] In a specific implementation, as an embodiment, the system testing device may include multiple processors, such as Figure 7 221 and processor 225 in the embodiment of the present invention. Each of these processors may be a single-CPU processor or a multi-CPU processor. The processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0124] In a specific implementation, as an embodiment, the system test device may further include an input device 226 and an output device 227. The input device 226 communicates with the output device 227 and may receive user input in a variety of ways. For example, the input device 226 may be a mouse, a keyboard, a touch screen device, or a sensor device. The output device 227 communicates with the processor 221 and may display information in a variety of ways. For example, the output device 227 may be a liquid crystal display (LCD), a light emitting diode (LED) display device, or the like.

[0125] Those skilled in the art will understand that Figure 7 The structure shown in the figure does not constitute a limitation on the system test device, and may include more or less components than those shown in the figure, or combine certain components, or adopt a different component arrangement.

[0126] The present application also provides a computer-readable storage medium including instructions, wherein the computer-readable storage medium stores instructions, and when the instructions in the computer-readable storage medium are executed by a processor of a system test device, the system test device can execute the system test method provided in the above-mentioned embodiment. For example, the computer-readable storage medium may be a memory 223 including instructions, and the above instructions may be executed by a processor 221 of the system test device to complete the above method.

[0127] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, for example, the non-transitory computer-readable storage medium may be a ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0128] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0129] It should be understood that the present application is not limited to the precise structures that have been 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 present application is limited only by the appended claims.

Claims

1. A system testing method, characterized in that: Applied to testing equipment; the method comprises: Generate test data corresponding to the test cases executed by the simulated faulty node devices in the blockchain system; Sending a test request message to the simulated fault node device; the test request message is used to instruct the simulated fault node device to publish the test data in the blockchain system; Obtaining status information after the blockchain system performs a consensus operation on the test data; Determine a stability result of the blockchain system according to the state information; the stability result includes: at least one of a target state type and a target stability level corresponding to the blockchain system.

2. The method according to claim 1, characterized in that The test device includes: a network module and a Byzantine message builder; the network module communicates with the Byzantine message builder through a message queue; the test data corresponding to the test case executed by the simulated fault node device in the blockchain system is generated, including: Receiving the test case through the network module; According to the test case, the test data is constructed by a Byzantine message constructor.

3. The method according to claim 2, characterized in that The sending a test request message to the simulated fault node device includes: Instruct the network module to send the test request message through a target communication connection; the target communication connection includes a unicast communication connection or a multicast communication connection.

4. The method according to claim 2, characterized in that: The test data includes at least one of invalid transactions, invalid proposals, and invalid votes.

5. The method according to claim 1, characterized in that Also includes: When the stability result meets the preset alarm condition, an alarm message is sent to the management terminal.

6. The method according to any one of claims 1 to 4, characterized in that: The number of node devices of the simulated faulty node devices and the number of node devices of the blockchain system meet the preset conditions of the Byzantine fault tolerance algorithm.

7. A system testing method, characterized in that: A simulated fault node device is applied to a blockchain system; the method comprises: Acquire test data corresponding to the test case executed by the simulated fault node device; Publishing the test data in the blockchain system, and obtaining status information after the blockchain system performs a consensus operation on the test data; The state information is sent to a test device; the test device is used to determine the stability result of the blockchain system according to the state information.

8. The method according to claim 7, characterized in that The simulated fault node device is connected to a network module in the test device; and obtaining test data corresponding to the test case executed by the simulated fault node device includes: A test request message is received, which is sent by the network module through a target communication connection; the test request message is used to instruct the simulated fault node device to publish the test data in the blockchain system; the target communication connection includes a unicast communication connection or a multicast communication connection.

9. A system testing device, characterized in that: Applicable to testing equipment; the device comprises: a generating unit, a communication unit and a determining unit; The generating unit is used to generate test data corresponding to the test case executed by the simulated fault node device in the blockchain system; The communication unit is used to send a test request message to the simulated fault node device; the test request message is used to instruct the simulated fault node device to publish the test data in the blockchain system; The communication unit is further used to obtain status information after the blockchain system performs a consensus operation on the test data; The determining unit is used to determine a stability result of the blockchain system according to the state information; the stability result includes: at least one of a target state type and a target stability level corresponding to the blockchain system.

10. A system testing system, characterized in that: include: Test equipment and simulate faulty node devices in blockchain systems; The test device is used to perform the system testing method according to any one of claims 1 to 6; The simulated fault node device is used to execute the system testing method as described in any one of claims 7-8.

11. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the system testing method according to any one of claims 1 to 6 or any one of claims 7 to 8.

12. A computer-readable storage medium having instructions stored thereon, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the system testing method according to any one of claims 1 to 6 or any one of claims 7 to 8.

Images