A testing method and related apparatus for blockchain networks

Abstract

This application discloses a testing method and related apparatus for a blockchain network. The blockchain network includes multiple nodes, each node includes multiple modules, and each module is a collection of multiple functions. Data points are set in the target functions of the target modules to obtain test cases corresponding to the blockchain network. When executing test cases to test the blockchain network, business processing data is collected by triggering the data points. The business processing data includes the call performance data of the target functions corresponding to the data points in the blockchain network when processing target business requests. The call performance test results of the target functions are determined based on the call performance data, thereby determining whether an anomaly has occurred in the blockchain network. If an anomaly is determined, the anomaly location information is directly determined based on the target function corresponding to the call performance test results indicating the anomaly. This improves the efficiency of anomaly handling and obtains more granular anomaly location information, improving the accuracy of anomaly location.

Description

Technical Field

[0001] This application relates to the field of blockchain, and in particular to a testing method and related apparatus for a blockchain network. Background Technology

[0002] A blockchain network is a distributed system based on a peer-to-peer (P2P) network, where nodes can act as both clients and servers. That is, each computer in the network can act as a requester of network services and simultaneously respond to requests from other computers, providing resources, services, and content.

[0003] After developers complete product development or updates to a blockchain network, testers typically conduct tests to identify any issues as early as possible, thereby improving the stability and reliability of the product after launch. Traditional testing methods often involve monitoring the overall performance data of the blockchain network and then manually checking the entire network for anomalies.

[0004] This testing method has a low degree of automation and cannot locate the location of anomalies in real time, thus delaying the subsequent handling of anomalies and resulting in low processing efficiency. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a testing method and related apparatus for blockchain networks, improving the automation level of blockchain networks and increasing the efficiency of anomaly handling. Simultaneously, it obtains more granular anomaly location information, improving the accuracy of anomaly location.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] On one hand, embodiments of this application provide a testing method for a blockchain network, the blockchain network including multiple nodes, each of the multiple nodes including multiple modules, each of the multiple modules being a collection of multiple functions, and setting data embedding points in the target functions of the target modules included in the multiple modules, the method including:

[0008] The business processing data is obtained by triggering the data tracking points. The business processing data is obtained by triggering the test cases corresponding to the blockchain network and following the processing process of the target business request through the data tracking points. The business processing data includes the call performance data of the target function corresponding to the data tracking points in the blockchain network when processing the target business request.

[0009] The call performance test results of the target function are determined based on the call performance data.

[0010] The performance test results of the target function call are used to determine whether the blockchain network has experienced an anomaly.

[0011] If it is determined that the blockchain network has malfunctioned, the anomaly location information is determined based on the target function corresponding to the performance test result indicating the malfunction.

[0012] On one hand, embodiments of this application provide a testing device for a blockchain network, the blockchain network including multiple nodes, each of the multiple nodes including multiple modules, each of the multiple modules being a collection of multiple functions, and data embedding points being set in the target functions of the target modules included in the multiple modules; the device includes an acquisition unit, a determination unit, and a positioning unit.

[0013] The acquisition unit is used to acquire business processing data collected by triggering the data tracking point. The business processing data is obtained by triggering the test case corresponding to the blockchain network and following the processing process of the target business request through the data tracking point. The business processing data includes the call performance data of the target function corresponding to the data tracking point in the blockchain network when processing the target business request.

[0014] The determining unit is used to determine the call performance test result of the target function based on the call performance data;

[0015] The determining unit is further configured to determine whether the blockchain network has experienced an anomaly based on the performance test results of the target function call;

[0016] The positioning unit is used to determine the anomaly positioning information based on the target function corresponding to the performance test result indicating the anomaly if it is determined that the blockchain network has an anomaly.

[0017] In one possible implementation, the display unit is specifically used for:

[0018] Receive a call chain query request, wherein the call chain query request includes a follow identifier;

[0019] The call chain corresponding to the follow identifier is displayed through the pipeline platform.

[0020] In one possible implementation, the determining unit is specifically used for:

[0021] Based on the performance test results of the target function call, determine whether the module to which the target function belongs has encountered an anomaly;

[0022] If a module is found to be malfunctioning, determine the target node to which the malfunctioning module belongs.

[0023] If the number of target nodes exceeds the fault tolerance threshold, the blockchain network is determined to be abnormal.

[0024] In one possible implementation, the positioning unit is specifically used for:

[0025] Based on the target function corresponding to the performance test results of the call indicating the occurrence of the anomaly, determine the abnormal module, the abnormal node to which the abnormal module belongs, and the abnormal call chain to which the target function corresponding to the performance test results of the call indicating the occurrence of the anomaly belongs;

[0026] Anomaly location information is generated based on the target function, the abnormal module, the abnormal node, and the abnormal call chain corresponding to the performance test results of the abnormal call.

[0027] In one possible implementation, the target module is all modules among the plurality of modules or the main module among the plurality of modules, and the target function is all functions among the plurality of functions or the key function among the plurality of functions.

[0028] In one possible implementation, the device further includes an alarm unit:

[0029] The alarm unit is used to trigger an alarm notification, which is used to indicate that an anomaly has occurred in the blockchain network.

[0030] In one possible implementation, the apparatus further includes a generation unit and a display unit:

[0031] The generation unit is used to generate a test report, which includes the target test results obtained by executing the test cases, and the target test results indicate whether the blockchain network has experienced an anomaly.

[0032] The display unit is used to display the test report through the pipeline platform.

[0033] On one hand, embodiments of this application provide an electronic device for testing blockchain networks, the electronic device including a processor and a memory:

[0034] The memory is used to store program code and transmit the program code to the processor;

[0035] The processor is used to execute the testing method for the blockchain network described above, according to the instructions in the program code.

[0036] On one hand, embodiments of this application provide a computer-readable storage medium for storing program code for executing the testing method of the blockchain network described in the foregoing aspect.

[0037] On one hand, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the testing method for the blockchain network described in the foregoing aspects.

[0038] As can be seen from the above technical solution, the blockchain network includes multiple nodes, each node includes multiple modules, and each module is a collection of functions. Data points are set in the target functions of the target modules included in the multiple modules to obtain test cases corresponding to the blockchain network. When the test cases are executed to test the blockchain network, the data points are triggered to follow the processing of the target business request, thereby collecting business processing data. This business processing data includes the call performance data of the target functions corresponding to the data points in the blockchain network when processing the target business request. Based on the call performance data, the call performance test results of the target functions can be determined, and then the blockchain network can be determined whether an anomaly has occurred based on the call performance test results of the target functions. If an anomaly is determined to have occurred in the blockchain network, since the call performance test results reflect the call status of the target functions, it shows whether the call of the target functions has occurred abnormally. Since the target functions are a subset of the modules included in the nodes, the anomaly location information can be directly determined based on the target functions corresponding to the call performance test results indicating the anomaly, without the need for manual anomaly investigation of the entire blockchain network, thereby improving the efficiency of anomaly handling. Furthermore, since the objective function is a subset of the modules included in a node, the anomaly location information obtained during anomaly localization can be refined to a specific function included in a module within the node, thus obtaining more granular anomaly location information and improving the accuracy of anomaly localization. Therefore, this scheme improves the automation level of the blockchain network and the efficiency of anomaly handling by setting data embedding points in the objective functions of modules within the node. Simultaneously, it obtains more granular anomaly location information, improving the accuracy of anomaly localization. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This application provides a schematic diagram of the system architecture of a blockchain system.

[0041] Figure 2 A flowchart illustrating a testing method for a blockchain network provided in this application embodiment;

[0042] Figure 3 A schematic diagram of a blockchain network consisting of multiple nodes is provided for an embodiment of this application;

[0043] Figure 4 This application provides a schematic diagram of the relevant modules and call chain of a node in a blockchain.

[0044] Figure 5 is a schematic diagram of the execution flow interface of a pipeline platform provided in an embodiment of this application;

[0045] Figure 6 This application provides a schematic diagram of the call chain of an objective function.

[0046] Figure 7 A schematic diagram of a display interface for the call chain and call performance data of an objective function provided in an embodiment of this application;

[0047] Figure 8 A schematic diagram of an alarm notification interface provided in an embodiment of this application;

[0048] Figure 9 A schematic diagram showing the test report provided in an embodiment of this application;

[0049] Figure 10 A structural diagram of a testing device for a blockchain network provided in an embodiment of this application;

[0050] Figure 11 A structural diagram of a terminal device provided in an embodiment of this application;

[0051] Figure 12 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0052] The embodiments of this application will now be described with reference to the accompanying drawings.

[0053] First, a brief introduction to the terms used in the embodiments of this application:

[0054] OpenTelemetry: OpenTelemetry is a unified new standard specification for the observability ecosystem. Supported by the Cloud Native Computing Foundation (CNCF), it serves as the infrastructure for observability, providing vendor-agnostic observability solutions. It represents a significant evolution in open observability following the merger of OpenCensus (a statistical data collection and distributed following framework) and OpenTracing (a distributed following system), while also supporting application programming interfaces (APIs) for following and metrics, and constructively adding the introduction of log-related standards.

[0055] Chaos engineering is a complex technique for improving the resilience of technical architectures. It's a discipline that experiments on distributed systems to build confidence in the system's ability to withstand turbulent conditions in a production environment. The design principles of chaos engineering are: 1. Establishing a stable state assumption; 2. Diversifying real-world events; 3. Conducting production environment experiments; 4. Conducting continuous automated operation experiments; 5. Minimizing the "explosion radius." The tests performed on the blockchain network in this application's embodiments can be chaos tests based on chaos engineering.

[0056] Ledger node: also called block-producing node or leader node. In the blockchain, during each packaging cycle, the ledger node needs to package a list of several transactions into a block structure and broadcast it to other nodes for consensus. The ledger node is the node that generates blocks and initiates proposals.

[0057] Consensus algorithm: It is the process of reaching a consensus on a certain proposal (goals, voting, and other collaborative work).

[0058] P2P network: A peer-to-peer network in which nodes can act as both clients and servers. That is, each computer in the network can both request network services and respond to requests from other computers, providing resources, services, and content.

[0059] Traditional blockchain network testing methods often monitor the overall performance data of the blockchain network and then manually troubleshoot anomalies. For example, data from the blockchain network's Remote Procedure Call (RPC) interface is collected to determine whether anomalies have occurred based on interface call time, error logs, etc., and if anomalies do occur, the specific location of the anomaly is manually investigated.

[0060] However, this testing method has a low degree of automation and cannot locate the location of anomalies in real time, thus delaying the subsequent handling of anomalies and resulting in low processing efficiency.

[0061] To address the aforementioned technical issues, this application provides a testing method for blockchain networks. This method sets data embedding points in the target functions of modules within nodes, eliminating the need for manual anomaly checks across the entire blockchain network, thus improving the automation level of the blockchain network and the efficiency of anomaly handling. Furthermore, the anomaly location information obtained during anomaly localization can be refined to a specific function included in the module within the node, resulting in more granular anomaly localization information and improving the accuracy of anomaly localization.

[0062] It should be noted that the embodiments of this application mainly involve blockchain. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is a ledger technology that is jointly maintained by multiple parties, uses cryptography to ensure the security of transmission and access, and can achieve consistent data storage, tamper-proofing, and non-repudiation—in other words, distributed ledger technology. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0063] like Figure 1 As shown, Figure 1 A schematic diagram of a blockchain system architecture is shown. The blockchain system 100 provided in this embodiment may include at least one client 110 and a blockchain network 120, with the blockchain network 120 including multiple nodes 121. The client 110 may be various electronic devices such as smartphones, tablets, laptops, and desktop computers. Multiple nodes 121 form a P2P network; the P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In a distributed system, any electronic device, such as a server or terminal device, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer. Terminal devices may be smartphones, tablets, laptops, desktop computers, etc. Servers may be independent physical servers, server clusters composed of multiple physical servers, or distributed systems. They may also be cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0064] Typically, client 110 can communicate with blockchain network 120 to query or update shared data maintained by nodes 121 in blockchain network 120. In blockchain system 100, client 110 sends a target business request to a node 121 in blockchain network 120. Node 121 broadcasts the transaction to other nodes 121 via a P2P network. The consensus mechanism randomly selects a ledger node from multiple nodes 121. The ledger node packages the target business request into a block and broadcasts it to other nodes 121. After receiving the block, other nodes 121 verify the target business request within the block and broadcast voting information. After reaching a consensus on the block, they submit the block to the blockchain storage layer to begin the next round of election and consensus.

[0065] It should be noted that each node 121 in the blockchain network 120 can store an identical blockchain. A blockchain is a chain-like data structure that combines data blocks sequentially in chronological order, and uses cryptography to ensure the immutability and unforgeability of the data. A blockchain consists of multiple sequentially linked blocks. Whenever new data needs to be written to the blockchain, this data is aggregated into a newly generated block, which is then linked to the end of the blockchain. A consensus algorithm ensures that the newly added blocks on each node 121 are identical. The block body of each block records the data of the current block, while its block header stores the hash value of the preceding block. If the transaction data in the preceding block changes, the hash value of the current block will also change accordingly. Therefore, data uploaded to the blockchain network is difficult to tamper with, improving the reliability of shared data.

[0066] Next, taking the method provided in the embodiments of this application as an example, and in conjunction with the accompanying drawings, we will provide a detailed description of the testing method for the blockchain network provided in the embodiments of this application.

[0067] See Figure 2 , Figure 2 A flowchart of a testing method for a blockchain network is shown, the method comprising:

[0068] S201. Obtain the business processing data collected by triggering the data embedding point.

[0069] In this embodiment of the application, the blockchain network includes multiple nodes, and the blockchain network composed of multiple nodes can be referred to as... Figure 3As shown, the multiple nodes are P1, P2, P3, P4, and P5, each with a corresponding RPC interface, which clients can use to access the nodes. These nodes can be categorized according to their functions, such as consensus nodes, synchronization nodes, and observation nodes.

[0070] Each of the multiple nodes includes multiple modules, which may be a transaction pool (IxPool), a consensus module (consent sns), a validator, a virtual machine (VM), an executor, a ledger module (Ledger), a storage module (Storage), a synchronization module (syncManager), a log collection module, a statistics module, and so on.

[0071] Each module in a multi-module system can be a collection of functions. By calling and executing these functions, a module can complete the processing of a target business request. Taking the executor as an example, the multiple functions that make up the executor can include executor_start (the function that starts the executor), executorInit (the function that initializes the executor), executorBaseInit (the basic initialization configuration function), and so on.

[0072] A node in a blockchain (e.g.) Figure 3 The relevant modules and call chain diagram of the P3 node can be found in [reference needed]. Figure 4 As shown. At this point, the blockchain network can call [a specific function / mechanism] to process a business request, such as the target business request. Figure 4 The module implementation is shown below. Specifically, when the client sends a target service request, it can receive and verify the target service request. Figure 4 Stages 1-2 indicate receiving the target business request from the RPC interface, while stages 3-4 indicate verifying the target business request and then placing it into the transaction pool. Finally, the target business request is broadcast. Figure 4 The five stages indicated by the symbol represent broadcasting the target service request to other nodes via a P2P network. Next, block proposal and consensus are reached. Figure 4 The stage marked with 6 indicates that the consensus module constructs a block; the stage marked with 7 indicates that the block is broadcast and consensus is reached with other nodes at the stage marked with 3. Finally, block submission and post-processing are performed. Figure 4 The stages marked 8-11 indicate the execution and submission of blocks to the ledger module and storage to the storage module for persistence. The stage marked 12 indicates the notification to the transaction pool to clean up transactions. The stages marked 13-14 indicate the notification to the synchronization module to broadcast blocks.

[0073] Based on the blockchain network's processing of target business requests described above, to automate testing and accurately pinpoint anomalies, data tracking points can be set in the target functions of multiple modules. The target module can be all or some of the modules in a node. A node's modules can include main and auxiliary modules. The main module is the one that plays a primary role in processing the target business request, such as the transaction pool, consensus module, validator, virtual machine, executor, ledger module, storage module, and synchronization module. Auxiliary modules are those that assist in processing the target business request, such as log collection and statistics modules. Auxiliary modules have a smaller impact on the processing of the target business request and a lower probability of anomalies. Therefore, in one possible implementation, the target module for setting data tracking points can be the main module among multiple modules. Based on a similar principle, the target function can be all or key functions among multiple functions. Taking the executor as an example, key functions could be executor_start, executor Init, executor BaseInit, executorstartTxExecutor, etc.

[0074] It should be noted that, in order to test the blockchain network, this application provides a pipeline platform, and the execution flow interface diagram of the pipeline platform can be seen in Figure 5.

[0075] Step 1: Submit the program code corresponding to a completed blockchain network product to the pipeline platform, for example, to the master branch (i.e., the main branch) of the git repository (a remote repository that can store program code), thereby triggering pipeline execution to achieve automated testing. See step 501 for the interface of the pipeline platform corresponding to this step.

[0076] Step 2: The pipeline platform launches the build environment and injects link instrumentation code (i.e., sets data entry points) into the program code under the master branch (the program code of the target module, which includes the target function). After injection, it compiles and distributes the code to the corresponding stability testing environment (multi-node). The interface of the pipeline platform for this step is shown in Figure 502. After the build is complete, "Build Success" will be displayed in the program code, indicating a successful build.

[0077] The pipeline platform provided in this application embodiment enables the testing of blockchain networks based on Opentelemetry. To achieve this, the Opentelemetry Go SDK (a software development kit) can be incorporated into the blockchain network's program code. SDK refers to the implementation of the Opentelemetry SDK interface. Since the blockchain network product is developed using the Go language, the Opentelemetry Go SDK needs to be included. This can be done by importing library files, such as the library file "go.opentelemetry.io / otel / sdk / resource" (a resource file) and the library file sdktrace "go.opentelemetry.io / otel / sdk / trace" (a follow file), etc., but is not limited to these two library files.

[0078] After importing the SDK development package, the next step is to complete the initialization work. Use the function `otlphttp.WithEndpoint` provided by the SDK to configure the reporting address (domain name / port) so that during testing, the business processing data collected by data tracking points can be reported to the electronic device corresponding to this reporting address, such as a server. Accessing this reporting address can obtain call performance data, anomaly location information, etc. Use the initialized driver to construct an exporter and start it. Simultaneously, you also need to register the service name of the blockchain network to be tested on the pipeline platform, such as the underlying blockchain network "TrustSQL2.1-service", and define and initialize resources in the code.

[0079] Inject link instrumentation code into the target function within the target module to obtain a Tracer command. This Tracer command is responsible for creating spans (spreads that specify a code block to be followed) and interacting with the context. The Tracer is obtained using the OpenTelemetry API, which specifies the name and version of the inspection library or application library to be tested in real-time. Once the location of the code block to be followed (e.g., the target function) is determined, a Span is created. Only the Span name needs to be specified, and custom attributes can be recorded using SetAttributes. For example, the following is a follower example:

[0080] ctx, span:=otel.Tracer("").start(context.Background(), "test-span-name"

[0081] defer span.End()

[0082] The above program code defines the collection of business processing data generated by the main module, and the registered span name is "test-span-name".

[0083] For example, follow the example below:

[0084] ctx, childspan:=otel.Tracer("").start(ctx.Background(), "BaseInit"

[0085] defer childspan.End()

[0086] The above program code defines the collection of business processing data generated by the executor module, and the registered span name is "BaseInit".

[0087] After completing the above steps, step 3 can be executed, which is to start the application of the blockchain network of multiple nodes on the pipeline platform and start the business processing data collection function for automatic collection and reporting. The interface of the pipeline platform corresponding to this step is shown in 503.

[0088] Step 4: Trigger the test cases corresponding to the blockchain network, simulating the process in the actual product where a client sends a target business request to the blockchain network, and the blockchain network processes the target business request. Start and execute the automated test of the blockchain network. See the 504 error message for the interface of the pipeline platform corresponding to this step. During the execution of the automated test, business processing data is obtained by tracking the processing of the target business request through data embedding points, and the collected business processing data is reported to the electronic device corresponding to the reporting address, such as a server. The business processing data includes the call performance data of the target function corresponding to the data embedding points in the blockchain network when processing the target business request. Call performance data includes, for example, call time and error data.

[0089] It should be noted that, in the embodiments of this application, the collection and use of business processing data are authorized and permitted by the object, and the object is aware of the data, and comply with legal requirements.

[0090] S202. Determine the call performance test results of the target function based on the call performance data.

[0091] The server can analyze call performance data, such as determining performance metrics based on the collected data, comparing these metrics with threshold values, and thus determining the call performance test results of the target function. The call performance test results of the target function are used to determine whether any exceptions occurred during the execution of the target function.

[0092] Taking call performance data, including call time, as an example, if the call time (i.e., performance metric) is 241.46ms and the metric threshold is 50ms, since 241.46ms is greater than the metric threshold of 50ms, it can be determined that the target function has malfunctioned.

[0093] In some cases, it's possible not only to obtain the call performance data of the current target function but also to identify the upstream function that called it, thus tracing the call chain that processed the target business request. In this scenario, the business processing data can also include upstream information of the target function corresponding to the data embedding point in the blockchain network when processing the target business request. This upstream information indicates which upstream function called the target function. Different upstream information will lead to different call patterns for the target function, and consequently, different performance evaluation rules. Therefore, one possible approach to determining the call performance test results of the target function based on call performance data is to determine the target performance evaluation rules based on upstream information, and then determine the call performance test results of the target function based on both the call performance data and the target performance evaluation rules.

[0094] For example, a first function can call a second function, and a third function can also call a second function. When the first function calls the second function, the threshold value in the corresponding performance evaluation rule is 50ms. When the third function calls the second function, the threshold value in the corresponding performance evaluation rule is 150ms. If the call time collected by the data tracking points for the second function (i.e., the target function to be evaluated) is 120.95ms, and the upstream information indicates that the first function called the second function when processing the target business request, then the determined target performance evaluation rule is the one corresponding to the first function calling the second function, with a threshold value of 50ms. Since 120.95ms is greater than the threshold value of 50ms, it can be determined that the second function is abnormal.

[0095] The above methods can accurately determine the target performance evaluation rules under different call chains, thereby accurately determining whether the target function has an anomaly, and further improving the accuracy of blockchain network testing and anomaly localization.

[0096] In one possible implementation, after obtaining the call performance data and upstream information of the target function, a call chain for the blockchain network to process the target business request can be generated based on the call performance data and upstream information of the target function. The call chain for the blockchain network to process the target business request can then be demonstrated to the tester through a pipeline platform, thereby meeting the follow-up requirements of multi-node and multi-module linkage in the blockchain network.

[0097] See Figure 6 As shown, Figure 6The target module is the executor. The target functions within this module include a first function, a second function, a third function, and a fourth function. Data collection points set on these four functions gather corresponding call performance data and upstream information, which are then used to generate... Figure 6 The call chain of the target function is shown. Among them, Figure 6 The time within the middle circle represents call performance data (such as call duration), making it convenient for testers to view.

[0098] It should be noted that, in this embodiment, after obtaining business processing data, the server can directly generate a call chain and display it to the tester through the pipeline platform. Alternatively, it can use the query function provided on the pipeline platform to display the call chain of the blockchain network processing the target business request based on the tester's call chain query request. Specifically, the server receives a call chain query request, which includes a follower identifier. This follower identifier is generated based on the identifier of the target business request. For example, it can be obtained through the API function `trace.SpanContextFromContext(ctx).TraceID().String()` provided by the SDK, and then the call chain can be viewed based on the TraceID. The server sends the call chain corresponding to the follower identifier to the pipeline platform and displays the call chain corresponding to the follower identifier through the pipeline platform. See also... Figure 6 As shown, the follower identifier can be as follows: Figure 6 As shown in Figure 601.

[0099] In addition, when displaying the call chain, besides showing call performance data (such as call time) within the call chain, the call performance data can also be displayed separately as a bar chart. See [link to relevant documentation]. Figure 7 As shown in Figure 701.

[0100] By visualizing the call chain, testers can intuitively understand the call patterns between nodes, modules, and functions when the blockchain network processes target business requests. This meets the requirement for multi-node and multi-module linkage in the blockchain network, assists in anomaly localization, and helps locate abnormal call chains.

[0101] S203. Determine whether the blockchain network has experienced an anomaly based on the performance test results of the target function call.

[0102] In this application embodiment, there are several ways to determine whether the blockchain network is abnormal based on the performance test results of the target function call. One way is to determine that the blockchain network is abnormal if the performance test results indicate that the corresponding target function call is abnormal.

[0103] In another possible implementation, since the embodiment of this application tests a blockchain network, and since the blockchain network has a multi-node consensus mechanism, the multi-nodes in a typical blockchain network satisfy a certain fault tolerance mechanism, usually the Byzantine Fault Tolerance (BFT) mechanism. That is, in a blockchain network composed of multiple nodes, if a node or a node within the fault tolerance range experiences an anomaly, such as crashing, memory overflow, or malicious behavior, the entire blockchain network can still operate normally.

[0104] In this scenario, determining whether the blockchain network has experienced an anomaly based on the performance test results of the target function call can be done by determining whether the module to which the target function belongs has experienced an anomaly. If an anomaly exists in the module, the target node to which that module belongs is identified. If the number of target nodes exceeds the fault tolerance threshold, the blockchain network is considered to have experienced an anomaly; if the number of target nodes does not exceed the fault tolerance threshold, the blockchain network is considered to be functioning normally.

[0105] The performance test results can reflect whether the corresponding target function has encountered an anomaly. If a target function encounters an anomaly, the module to which the anomaly target function belongs is determined, i.e., the module that encountered the anomaly is identified, and then the target node to which the module that encountered the anomaly belongs is determined. Assuming that the blockchain network includes 4 nodes and the fault tolerance threshold is 1, if the anomaly module belongs to one target node, that is, only 1 node in the blockchain network has encountered an anomaly. Since the number of target nodes 1 is not greater than the fault tolerance threshold 1, it is determined that the blockchain network can operate normally. If the anomaly module belongs to 2 target nodes, that is, 2 nodes in the blockchain network have encountered anomalies. Since the number of target nodes 2 is greater than the fault tolerance threshold 1, it is determined that the blockchain network has encountered an anomaly.

[0106] The above methods can cover the BFT fault-tolerant detection unique to blockchain networks, thus conforming to the consensus characteristics of blockchain networks and avoiding unnecessary anomaly location and alarms.

[0107] S204. If it is determined that the blockchain network has an anomaly, the anomaly location information is determined according to the target function corresponding to the performance test result indicating the anomaly.

[0108] Since calling the performance test results can indicate whether the corresponding target function has encountered an exception, it is possible to locate which target function the exception occurred in; that is, the exception location information includes the target function where the exception occurred.

[0109] Furthermore, since each node includes multiple modules, and each module is a collection of multiple functions, after determining the target function that caused the exception, it is possible to further determine the exception module to which the exception function belongs, the exception node to which the exception module belongs, and the exception call chain to which the exception function belongs. Thus, exception location information can be generated based on the target function, exception module, exception node, and exception call chain corresponding to the performance test results indicating the exception.

[0110] Since Opentelemetry-based pipeline platforms can display call chains, performance test data, etc., testers can use Opentelemetry-based pipeline platforms to assist in anomaly localization.

[0111] In one possible implementation, when an anomaly is detected in the blockchain network, the server can trigger an alarm notification. This alarm notification can be sent to the tester via the pipeline platform. The alarm notification is used to indicate that an anomaly has occurred in the blockchain network, thereby prompting the tester to fix the anomaly.

[0112] See Figure 8 As shown, Figure 8 This alert notification was issued after testing a blockchain network named "Majiang_CTRobot". The notification clearly stated the specific anomaly that occurred, such as "execution frequency too fast or cessation of block production", "real-time detection log error messages continuously exceeding the threshold", and provided instructions on how to view the specific problem, etc. Figure 8 This is merely one example of an alarm notification, and the specific content of the alarm notification is not limited in this application embodiment.

[0113] After the automated tests are completed on the pipeline platform, the server can generate a test report and display the test report through the pipeline platform. The test report includes the target test results obtained from executing the test cases, and the target test results indicate whether the blockchain network has experienced any anomalies.

[0114] The screenshot of the test report display interface can be found here. Figure 9 As shown, Figure 9 The image shows the target test results for automated tests used to perform different business operations (e.g., business request on-chaining, multiple business requests on-chaining in parallel, viewing blocks based on height). Figure 9 The CCP tested 20 test cases, and the target test result for each test case was passed. Additionally, each target test result includes an entry point to view its details; testers can click "View" to see the full details.

[0115] After the automated testing is completed on the pipeline platform, the failpoint environment can be restored. This allows for the automatic activation of these failpoints to simulate failures, and the final results can be observed to determine the correctness and stability of the blockchain network. The pipeline platform interface can be seen in step 5 of Figure 5 (505).

[0116] As can be seen from the above technical solution, the blockchain network includes multiple nodes, each node includes multiple modules, and each module is a collection of functions. Data points are set in the target functions of the target modules included in the multiple modules to obtain test cases corresponding to the blockchain network. When the test cases are executed to test the blockchain network, the data points are triggered to follow the processing of the target business request, thereby collecting business processing data. This business processing data includes the call performance data of the target functions corresponding to the data points in the blockchain network when processing the target business request. Based on the call performance data, the call performance test results of the target functions can be determined, and then the blockchain network can be determined whether an anomaly has occurred based on the call performance test results of the target functions. If an anomaly is determined to have occurred in the blockchain network, since the call performance test results reflect the call status of the target functions, it shows whether the call of the target functions has occurred abnormally. Since the target functions are a subset of the modules included in the nodes, the anomaly location information can be directly determined based on the target functions corresponding to the call performance test results indicating the anomaly, without the need for manual anomaly investigation of the entire blockchain network, thereby improving the efficiency of anomaly handling. Furthermore, since the objective function is a subset of the modules included in a node, the anomaly location information obtained during anomaly localization can be refined to a specific function included in a module within the node, thus obtaining more granular anomaly location information and improving the accuracy of anomaly localization. Therefore, this scheme improves the automation level of the blockchain network and the efficiency of anomaly handling by setting data embedding points in the objective functions of modules within the node. Simultaneously, it obtains more granular anomaly location information, improving the accuracy of anomaly localization.

[0117] Current testing methods for blockchain networks rely on manually entering information from multiple nodes, and real-time detection metrics are limited and cannot cover BFT scenarios. This application, however, sets data points at the granularity of the objective function, automatically reports business processing data based on the started nodes, automatically analyzes BFT fault tolerance, automatically collects call chains, and automatically triggers alarm notifications.

[0118] In addition, current blockchain network testing methods lack the capability to locate abnormal call chains and do not provide relevant test reports. Test events also lack clear conclusions. This application, based on a pipeline platform, can trigger test report generation and provide an abnormal call chain query function, which facilitates anomaly location.

[0119] In summary, this application presents a blockchain observability implementation scheme based on Opentelemetry distributed following. It collects call information from multiple nodes and modules within the blockchain, displays and analyzes it in real time, and issues real-time alarms when the steady-state of the blockchain network is not met. This method features functions such as module and node call chain following, call chain display, real-time Byzantine fault tolerance analysis, and call performance data collection. It accurately follows the business processing data of multi-node and multi-module blockchain networks, covering BFT scenarios, and triggers real-time alarms when the fault tolerance threshold that violates the blockchain network is reached.

[0120] Furthermore, the method provided in this application is convenient and easy to use, has high efficiency in exception handling, strong compatibility, and is easy to port. With the help of the DevOps pipeline mechanism, it has a high degree of automation.

[0121] It should be noted that, based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0122] based on Figure 2 Corresponding to the blockchain network testing method provided in the embodiments, this application also provides a blockchain network testing device 1000. The blockchain network includes multiple nodes, each of the multiple nodes includes multiple modules, and each of the multiple modules is a collection of multiple functions. Data points are set in the target functions of the target modules included in the multiple modules. See also Figure 10 The testing device 1000 for the blockchain network includes an acquisition unit 1001, a determination unit 1002, and a positioning unit 1003.

[0123] The acquisition unit 1001 is used to acquire business processing data collected by triggering the data embedding point. The business processing data is obtained by triggering the test case corresponding to the blockchain network and following the processing process of the target business request through the data embedding point. The business processing data includes the call performance data of the target function corresponding to the data embedding point in the blockchain network when processing the target business request.

[0124] The determining unit 1002 is used to determine the call performance test result of the target function based on the call performance data;

[0125] The determining unit 1002 is further configured to determine whether the blockchain network has experienced an anomaly based on the performance test results of the target function call;

[0126] The positioning unit 1003 is used to determine the abnormal positioning information according to the target function corresponding to the performance test result indicating the abnormality if it is determined that the blockchain network has an abnormality.

[0127] In one possible implementation, the business processing data further includes upstream information of the target function corresponding to the data embedding point in the blockchain network when processing the target business request, and the determining unit 1002 is used for:

[0128] The target performance evaluation rules are determined based on the upstream information;

[0129] The call performance test results of the target function are determined based on the call performance data and the target performance evaluation rules.

[0130] In one possible implementation, the business processing data further includes upstream information of the target function corresponding to the data embedding point in the blockchain network when processing the target business request, and the device further includes a generation unit and a display unit.

[0131] The generation unit is used to generate a call chain for the blockchain network to process the target business request based on the call performance data of the target function and the upstream information;

[0132] The demonstration unit is used to display the call chain of the blockchain network processing the target business request through the pipeline platform.

[0133] In one possible implementation, the display unit is specifically used for:

[0134] Receive a call chain query request, wherein the call chain query request includes a follow identifier;

[0135] The call chain corresponding to the follow identifier is displayed through the pipeline platform.

[0136] In one possible implementation, the determining unit 1002 is specifically used for:

[0137] Based on the performance test results of the target function call, determine whether the module to which the target function belongs has encountered an anomaly;

[0138] If a module is found to be malfunctioning, determine the target node to which the malfunctioning module belongs.

[0139] If the number of target nodes exceeds the fault tolerance threshold, the blockchain network is determined to be abnormal.

[0140] In one possible implementation, the positioning unit 1003 is specifically used for:

[0141] Based on the target function corresponding to the performance test results of the call indicating the occurrence of the anomaly, determine the abnormal module, the abnormal node to which the abnormal module belongs, and the abnormal call chain to which the target function corresponding to the performance test results of the call indicating the occurrence of the anomaly belongs;

[0142] Anomaly location information is generated based on the target function, the abnormal module, the abnormal node, and the abnormal call chain corresponding to the performance test results of the abnormal call.

[0143] In one possible implementation, the target module is all modules among the plurality of modules or the main module among the plurality of modules, and the target function is all functions among the plurality of functions or the key function among the plurality of functions.

[0144] In one possible implementation, the device further includes an alarm unit:

[0145] The alarm unit is used to trigger an alarm notification, which is used to indicate that an anomaly has occurred in the blockchain network.

[0146] In one possible implementation, the apparatus further includes a generation unit and a display unit:

[0147] The generation unit is used to generate a test report, which includes the target test results obtained by executing the test cases, and the target test results indicate whether the blockchain network has experienced an anomaly.

[0148] The display unit is used to display the test report through the pipeline platform.

[0149] As can be seen from the above technical solution, the blockchain network includes multiple nodes, each node includes multiple modules, and each module is a collection of functions. Data points are set in the target functions of the target modules included in the multiple modules to obtain test cases corresponding to the blockchain network. When the test cases are executed to test the blockchain network, the data points are triggered to follow the processing of the target business request, thereby collecting business processing data. This business processing data includes the call performance data of the target functions corresponding to the data points in the blockchain network when processing the target business request. Based on the call performance data, the call performance test results of the target functions can be determined, and then the blockchain network can be determined whether an anomaly has occurred based on the call performance test results of the target functions. If an anomaly is determined to have occurred in the blockchain network, since the call performance test results reflect the call status of the target functions, it shows whether the call of the target functions has occurred abnormally. Since the target functions are a subset of the modules included in the nodes, the anomaly location information can be directly determined based on the target functions corresponding to the call performance test results indicating the anomaly, without the need for manual anomaly investigation of the entire blockchain network, thereby improving the efficiency of anomaly handling. Furthermore, since the objective function is a subset of the modules included in a node, the anomaly location information obtained during anomaly localization can be refined to a specific function included in a module within the node, thus obtaining more granular anomaly location information and improving the accuracy of anomaly localization. Therefore, this scheme improves the automation level of the blockchain network and the efficiency of anomaly handling by setting data embedding points in the objective functions of modules within the node. Simultaneously, it obtains more granular anomaly location information, improving the accuracy of anomaly localization.

[0150] This application also provides an electronic device for testing blockchain networks. This electronic device can be a terminal device, for example, a smartphone.

[0151] Figure 11 The diagram shown is a block diagram of a portion of the structure of a smartphone provided in an embodiment of this application. (Reference) Figure 11 A smartphone includes components such as a radio frequency (RF) circuit 1110, a memory 1120, an input unit 1130, a display unit 1140, a sensor 1150, an audio circuit 1160, a Wi-Fi module 1170, a processor 1180, and a power supply 1190. The input unit 1130 may include a touch panel 1131 and other input devices 1132, the display unit 1140 may include a display panel 1141, and the audio circuit 1160 may include a speaker 1161 and a microphone 1162. It is understood that... Figure 11The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0152] The memory 1120 can be used to store software programs and modules. The processor 1180 executes various functions and data processing of the smartphone by running the software programs and modules stored in the memory 1120. The memory 1120 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 1120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0153] The processor 1180 is the control center of the smartphone, connecting various parts of the smartphone via various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1120 and calling data stored in the memory 1120. Optionally, the processor 1180 may include one or more processing units; preferably, the processor 1180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1180.

[0154] In this embodiment, the steps performed by the terminal device described above can be based on Figure 11 The terminal structure shown is implemented.

[0155] This application also provides a server; please refer to [link / reference]. Figure 12 As shown, Figure 12This is a structural diagram of a server 1200 provided in an embodiment of this application. The server 1200 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 1222 (e.g., one or more processors) and a memory 1232, and one or more storage media 1230 (e.g., one or more mass storage devices) for storing application programs 1242 or data 1244. The memory 1232 and storage media 1230 can be temporary or persistent storage. The program stored in the storage media 1230 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1222 may be configured to communicate with the storage media 1230 and execute the series of instruction operations in the storage media 1230 on the server 1200.

[0156] Server 1200 may also include one or more power supplies 1226, one or more wired or wireless network interfaces 1250, one or more input / output interfaces 1258, and / or one or more operating systems 1241, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0157] In this embodiment, the blockchain network includes multiple nodes, each node includes multiple modules, and each module is a collection of multiple functions. Data points are set in the target functions of the target modules included in the multiple modules. The central processing unit 1222 in the server 1200 can execute the following steps:

[0158] The business processing data is obtained by triggering the data tracking points. The business processing data is obtained by triggering the test cases corresponding to the blockchain network and following the processing process of the target business request through the data tracking points. The business processing data includes the call performance data of the target function corresponding to the data tracking points in the blockchain network when processing the target business request.

[0159] The call performance test results of the target function are determined based on the call performance data.

[0160] The performance test results of the target function call are used to determine whether the blockchain network has experienced an anomaly.

[0161] If it is determined that the blockchain network has malfunctioned, the anomaly location information is determined based on the target function corresponding to the performance test result indicating the malfunction.

[0162] According to one aspect of this application, a computer-readable storage medium is provided for storing program code for executing the testing methods for the blockchain network described in the foregoing embodiments.

[0163] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various optional implementations of the above embodiments.

[0164] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0165] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0166] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

[0168] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0170] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A testing method for a blockchain network, characterized in that, The method for testing a blockchain network based on Opentelemetry, wherein the blockchain network comprises multiple nodes, each node comprises multiple modules, and each module is a collection of multiple functions, wherein data points are set in the target functions of the target modules included in the multiple modules, the method comprising: The business processing data is obtained by triggering the data tracking points. The business processing data is obtained by triggering the test cases corresponding to the blockchain network and following the processing process of the target business request through the data tracking points. The business processing data includes the call performance data of the target function corresponding to the data tracking points in the blockchain network when processing the target business request, and the upstream information of the target function corresponding to the data tracking points in the blockchain network when processing the target business request. The upstream information is used to indicate that the target function is called by the specific upstream function. The call performance data includes call time and error data. The target performance evaluation rules are determined based on the upstream information; The call performance test results of the target function are determined based on the call performance data and the target performance evaluation rules. Determining whether the blockchain network has experienced an anomaly based on the performance test results of the target function call includes: determining whether the module to which the target function belongs has experienced an anomaly based on the performance test results of the target function call; if there is an anomaly in the module, determining the target node to which the anomaly module belongs; if the number of the target nodes is greater than the fault tolerance threshold, determining that the blockchain network has experienced an anomaly. If it is determined that the blockchain network has malfunctioned, the anomaly location information is determined based on the target function corresponding to the performance test result indicating the malfunction.

2. The method according to claim 1, characterized in that, The method further includes: Based on the call performance data of the target function and the upstream information, a call chain is generated for the blockchain network to process the target business request; The pipeline platform demonstrates the call chain of the blockchain network processing the target business request.

3. The method according to claim 2, characterized in that, The process of demonstrating the call chain of the blockchain network processing the target business request through the pipeline platform includes: Receive a call chain query request, wherein the call chain query request includes a follow identifier; The pipeline platform displays the call chain corresponding to the follow identifier.

4. The method according to claim 2, characterized in that, The step of determining the anomaly location information based on the target function corresponding to the indicated anomaly call performance test results includes: Based on the target function corresponding to the performance test results of the call indicating the occurrence of the anomaly, determine the abnormal module, the abnormal node to which the abnormal module belongs, and the abnormal call chain to which the target function corresponding to the performance test results of the call indicating the occurrence of the anomaly belongs; Anomaly location information is generated based on the target function, the abnormal module, the abnormal node, and the abnormal call chain corresponding to the performance test results of the abnormal call.

5. The method according to any one of claims 1-4, characterized in that, The target module is all modules among the plurality of modules or the main module among the plurality of modules, and the target function is all functions among the plurality of functions or the key function among the plurality of functions.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: An alarm notification is triggered, which is used to indicate that an anomaly has occurred in the blockchain network.

7. The method according to any one of claims 1-4, characterized in that, The method further includes: A test report is generated and displayed through the pipeline platform. The test report includes the target test results obtained by executing the test cases, and the target test results indicate whether the blockchain network has experienced an anomaly.

8. A testing device for a blockchain network, characterized in that, This device is used for testing an Opentelemetry-based blockchain network, which includes multiple nodes. Each node includes multiple modules, and each module is a collection of functions. Data points are set in the target functions of the target modules included in the multiple modules. The device includes an acquisition unit, a determination unit, and a positioning unit. The acquisition unit is used to acquire business processing data collected by triggering the data embedding point. The business processing data is obtained by triggering the test case corresponding to the blockchain network and following the processing process of the target business request through the data embedding point. The business processing data includes the call performance data of the target function corresponding to the data embedding point in the blockchain network when processing the target business request, and the upstream information of the target function corresponding to the data embedding point in the blockchain network when processing the target business request. The upstream information is used to indicate that the target function is called by a specific upstream function. The call performance data includes call time and error data. The determining unit is configured to determine the target performance evaluation rules based on the upstream information; and to determine the call performance test results of the target function based on the call performance data and the target performance evaluation rules. The determining unit is further configured to determine whether the blockchain network has experienced an anomaly based on the performance test results of the target function's call, including: determining whether the module to which the target function belongs has experienced an anomaly based on the performance test results of the target function's call; if there is an anomaly in the module, determining the target node to which the anomaly belongs; if the number of the target nodes is greater than the fault tolerance threshold, determining that the blockchain network has experienced an anomaly. The positioning unit is used to determine the anomaly positioning information based on the target function corresponding to the performance test result indicating the anomaly if it is determined that the blockchain network has an anomaly.

9. The apparatus according to claim 8, characterized in that, The device also includes a generation unit and a display unit: The generation unit is used to generate a call chain for the blockchain network to process the target business request based on the call performance data of the target function and the upstream information; The demonstration unit is used to display the call chain of the blockchain network processing the target business request through the pipeline platform.

10. The apparatus according to claim 9, characterized in that, The display unit is specifically used for: Receive a call chain query request, wherein the call chain query request includes a follow identifier; The pipeline platform displays the call chain corresponding to the follow identifier.

11. The apparatus according to claim 9, characterized in that, The positioning unit is specifically used for: Based on the target function corresponding to the performance test results of the call indicating the occurrence of the anomaly, determine the abnormal module, the abnormal node to which the abnormal module belongs, and the abnormal call chain to which the target function corresponding to the performance test results of the call indicating the occurrence of the anomaly belongs; Anomaly location information is generated based on the target function, the abnormal module, the abnormal node, and the abnormal call chain corresponding to the performance test results of the abnormal call.

12. The apparatus according to any one of claims 8-11, characterized in that, The target module is all modules among the plurality of modules or the main module among the plurality of modules, and the target function is all functions among the plurality of functions or the key function among the plurality of functions.

13. The apparatus according to any one of claims 8-11, characterized in that, The device also includes an alarm unit; The alarm unit is used to trigger an alarm notification, which is used to indicate that an anomaly has occurred in the blockchain network.

14. The apparatus according to any one of claims 8-11, characterized in that, The device also includes a generation unit and a display unit; The generation unit is used to generate a test report, which includes the target test results obtained by executing the test cases, and the target test results indicate whether the blockchain network has experienced an anomaly. The display unit is used to display the test report through the pipeline platform.

15. An electronic device for testing blockchain networks, characterized in that, The electronic device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the method according to any one of claims 1-7 according to the instructions in the program code.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for performing the method according to any one of claims 1-7.

17. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the method described in any one of claims 1-7.

Images