Block chain test method and device, equipment, medium and product

Abstract

The invention relates to a block chain test method and device, equipment, a medium and a product. The method comprises the steps that under the condition that a code change request is received, block chain testing is started, and in the block chain testing, code change information is determined according to a difference code corresponding to the code change request; constructing a log graph based on a test log set generated in the block chain test process, and determining abnormal test logs from the test logs according to the log graph; performing fault diagnosis according to test environment information carried by the code change request, the code change information and the abnormal test log, and determining a fault reason; and determining a fault code from the difference codes based on the fault reason, and generating a fault solution based on the fault reason. By adopting the method, the fault in the block chain test can be accurately positioned.

Description

Technical Field

[0001] This application relates to the field of blockchain testing technology, and in particular to a blockchain testing method, apparatus, equipment, medium, and product. Background Technology

[0002] As blockchain technology is applied more extensively, the complexity of blockchain testing has increased significantly, thus creating a need to locate faults that occur during the blockchain testing process.

[0003] In traditional technologies, troubleshooting blockchain testing failures mainly relies on testers manually searching the entire log, identifying error messages through keyword matching, and comparing code change records with their personal experience to infer the root cause of the failure.

[0004] However, in traditional methods, manual analysis is inefficient and prone to missing deep-seated causes, resulting in the inability to accurately locate faults. Summary of the Invention

[0005] Therefore, it is necessary to provide a blockchain testing method, apparatus, equipment, medium, and product that can improve the accuracy of fault location in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a blockchain testing method, including:

[0007] Upon receiving a code change request, initiate a blockchain test. During the blockchain test, determine the code change information based on the difference code corresponding to the code change request.

[0008] A log graph is constructed based on the set of test logs generated during blockchain testing, and abnormal test logs are identified from the test logs based on the log graph.

[0009] Based on the test environment information, code change information, and abnormal test logs carried in the code change request, perform fault diagnosis to determine the cause of the fault;

[0010] The fault code is determined from the difference code based on the fault cause, and a fault solution is generated based on the fault cause.

[0011] Secondly, this application also provides a blockchain testing device, comprising:

[0012] The code parsing module is used to initiate blockchain testing upon receiving a code change request. During the blockchain test, it determines the code change information based on the difference code corresponding to the code change request.

[0013] The log processing module is used to construct a log graph based on the set of test logs generated during blockchain testing, and to identify abnormal test logs from the test logs according to the log graph.

[0014] The fault diagnosis module is used to diagnose faults and determine the cause of faults based on the test environment information, code change information and abnormal test logs carried in the code change request.

[0015] The fault diagnosis module is also used to determine the fault code from the difference code based on the fault cause, and to generate a fault solution based on the fault cause.

[0016] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0017] Upon receiving a code change request, initiate a blockchain test. During the blockchain test, determine the code change information based on the difference code corresponding to the code change request.

[0018] A log graph is constructed based on the set of test logs generated during blockchain testing, and abnormal test logs are identified from the test logs based on the log graph.

[0019] Based on the test environment information, code change information, and abnormal test logs carried in the code change request, perform fault diagnosis to determine the cause of the fault;

[0020] The fault code is determined from the difference code based on the fault cause, and a fault solution is generated based on the fault cause.

[0021] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0022] Upon receiving a code change request, initiate a blockchain test. During the blockchain test, determine the code change information based on the difference code corresponding to the code change request.

[0023] A log graph is constructed based on the set of test logs generated during blockchain testing, and abnormal test logs are identified from the test logs based on the log graph.

[0024] Based on the test environment information, code change information, and abnormal test logs carried in the code change request, perform fault diagnosis to determine the cause of the fault;

[0025] The fault code is determined from the difference code based on the fault cause, and a fault solution is generated based on the fault cause.

[0026] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0027] Upon receiving a code change request, initiate a blockchain test. During the blockchain test, determine the code change information based on the difference code corresponding to the code change request.

[0028] A log graph is constructed based on the set of test logs generated during blockchain testing, and abnormal test logs are identified from the test logs based on the log graph.

[0029] Based on the test environment information, code change information, and abnormal test logs carried in the code change request, perform fault diagnosis to determine the cause of the fault;

[0030] The fault code is determined from the difference code based on the fault cause, and a fault solution is generated based on the fault cause.

[0031] The aforementioned blockchain testing methods, devices, equipment, media, and products trigger blockchain testing through code change requests and lock code change information based on differing codes, accurately identifying potential causes of failures; they construct log graphs to identify abnormal test logs, linking scattered multi-source test logs according to business logic to form a traceable chain, thus achieving accurate identification of abnormal test logs; they integrate test environment information, code change information, and abnormal test logs for fault diagnosis, improving the accuracy of fault cause determination; and they locate faulty codes from differing codes and generate targeted solutions, achieving precise fault localization in blockchain testing. Attached Figure Description

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

[0033] Figure 1 This is a diagram illustrating the application environment of a blockchain testing method in one embodiment.

[0034] Figure 2 This is a flowchart illustrating a blockchain testing method in one embodiment;

[0035] Figure 3 This is a flowchart illustrating a blockchain testing method in another embodiment;

[0036] Figure 4 This is a schematic diagram of the overall process of a blockchain testing method in one embodiment;

[0037] Figure 5 This is a structural block diagram of a blockchain testing device in one embodiment;

[0038] Figure 6 This is an internal structural diagram of a computer device in one embodiment;

[0039] Figure 7 This is a diagram of the internal structure of a computer device in another embodiment. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0041] The blockchain testing method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Terminal 102 sends a code change request to server 104. Upon receiving the code change request, server 104 initiates blockchain testing. During blockchain testing, it determines the code change information based on the difference code corresponding to the code change request; constructs a log graph based on the set of test logs generated during blockchain testing, and identifies abnormal test logs from the test logs based on the log graph; performs fault diagnosis based on the test environment information, code change information, and abnormal test logs carried in the code change request, and determines the cause of the fault; identifies the fault code from the difference code based on the fault cause, and generates a fault solution based on the fault cause. Server 104 then feeds back the fault cause, fault code, and fault solution to terminal 102. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0042] In one exemplary embodiment, such as Figure 2 As shown, a blockchain testing method is provided, which is applied to... Figure 1 Taking the server in the example, the explanation includes the following steps 201 to 204. Wherein:

[0043] Step 201: Upon receiving a code change request, initiate a blockchain test. During the blockchain test, determine the code change information based on the difference code corresponding to the code change request.

[0044] The code change request can be a request submitted by a user to the blockchain project's code repository, which includes code addition, modification, or deletion operations; the diff code can be all the changed files and specific changes (such as file paths, added / deleted line identifiers, and changed text) obtained by comparing the changed code corresponding to the code change request with the base version of the code repository using the Git diff tool; the code change information can be structured information related to blockchain dependencies obtained by filtering and parsing from the diff code, including but not limited to the file path of the dependency configuration file, the change type, and the dependency change details.

[0045] Optionally, upon receiving a code change request submitted by a user, the system automatically triggers the blockchain testing process. During the test execution, the Git diff tool is used to compare the base version of the code repository with the modified code corresponding to the code change request, obtaining the difference code containing all changed files and specific changes. Based on preset blockchain dependency file feature rules, dependency configuration files are selected from the difference code. The selected dependency configuration files are then structured and parsed to extract key information such as file paths, change types, and dependency change details, ultimately forming code change information.

[0046] Step 202: Construct a log graph based on the set of test logs generated during the blockchain testing process, and identify abnormal test logs from the test logs according to the log graph.

[0047] Among them, the test log set can be a collection of full structured log records generated by multiple modules such as the test framework, blockchain nodes, smart contracts, and cross-chain components during the blockchain testing process; the log graph can be used to formally represent the complex relationships between test logs; and the abnormal test log can be a test log whose feature vector deviates from the normal range.

[0048] Optionally, after triggering the blockchain test, all test logs generated by each module during the blockchain test are collected to form a test log set; a complete log graph is constructed based on each log in the set; the feature vectors of each node in the log graph are aggregated in the neighborhood using a graph convolutional network (GCN), and the node's own features are fused with the features of related nodes to obtain enhanced node features; the enhanced features are input into an anomaly detection model and compared with the feature patterns of historical normal test logs to filter out log nodes that deviate from the normal pattern, which are the abnormal test logs.

[0049] In one embodiment, the method of constructing the log graph is further described, including: for each test log in the test log set, extracting the key log information of the test log; extracting the features of the key log information of the test log to obtain the log feature vector of the test log; constructing a log graph based on the log feature vector of each test log in the test log set, wherein each node in the log graph corresponds to a test log and the node contains the log feature vector associated with the test log, and the edges represent the association between the test logs corresponding to the nodes.

[0050] The key log information can be structured data components extracted from unstructured raw test logs through parsing rules, including but not limited to timestamps, log levels, source modules, message text, and blockchain-specific fields; the log feature vector can be a feature vector generated by fusing the numerical features, text features, and time series features of the test logs according to weights.

[0051] It is worth noting that this implementation method, targeting the multi-source log characteristics of blockchain testing, achieves structured log processing and anomaly extraction through a custom parser, deep learning, and graph neural networks (GNN). This includes: real-time collection of all logs in the blockchain test through a log collection agent, such as contract layer logs including but not limited to smart contract compilation logs (e.g., "DeclarationError" output by the Solc compiler), contract execution logs (e.g., transaction rollback information "Transactionreverted: Insufficient balance"), and contract event logs (e.g., the "Transfer" event parameter of ERC-20); node layer logs including but not limited to consensus node operation logs (e.g., "Validator elected" and "Block proposed" in PoS consensus), node P2P communication logs (e.g., "Peer connected" and "Sync failed"), and node SDK logs (e.g., "ProviderError: Timeout" from ethers.js calls); and test framework logs including but not limited to Hardhat / Truffle test execution logs (e.g., "Test case failed: should transfer ERC20 tokens") and test tool logs (e.g., "Block mined" from Ganache simulated nodes).

[0052] The blockchain-specific log parser is designed as follows: It collects tens of thousands of blockchain test logs (covering mainstream blockchain networks such as ETH, Hyperchain, and Fabric) as a training set, labeling them with timestamps, log levels, blockchain-specific fields (block height, transaction hash, node ID), message content, and source modules (contract / node / framework / consensus). It then trains a BERT-based log format recognition model, enabling the parser to automatically adapt to log formats of different blockchain networks without requiring manual maintenance of regular expressions. For each collected log entry, it extracts key information according to the rules of the blockchain log components. For example, the log entry for a node, "2025-10-27 14:30:25 ERROR NodeID: node1| BlockHeight: 1056|Syncfailed: Peer 0x456 not responding", yields the following results: Timestamp: 2025-10-27 14:30:25; Log Level: ERROR; Blockchain-specific fields: NodeID=node1, BlockHeight=1056; Message Content: Sync failed: Peer node1 not responding; Source Module: Node Layer (P2P communication).

[0053] The extracted log component information (timestamp, log level, blockchain-specific fields, message content, and source module) is then converted into machine-recognizable feature vectors to adapt for subsequent AI analysis and anomaly detection. Specific conversion methods include: numerical conversion: For fields such as log level (DEBUG=0, INFO=1, WARN=2, ERROR=3, FATAL=4), block height (directly taking the numerical value), and node ID (mapped to an integer via hashing), direct conversion to numerical features; textual feature conversion: For message content (e.g., "Transaction reverted due to insufficient gas"), word embedding is performed using a pre-trained blockchain-domain BERT model (fine-tuned on blockchain technical documents, contract code, and fault reports) to generate a 384-dimensional textual feature vector, preserving blockchain-specific semantics such as "insufficient gas" and "contract rollback"; and time-series feature conversion: For logs containing timestamps, the "interval between adjacent logs" and the "logs of the same type on the same node (e.g., Sync)" are calculated. The log features are analyzed by analyzing time features such as the frequency of "failed" occurrences and the number of logs highly correlated with the same block, forming a time series vector. Finally, the numerical features, text features, and time series features are fused according to their weights (e.g., text features 0.5, numerical features 0.3, and time features 0.2) to generate the final log feature vector.

[0054] Based on log feature vectors and using log entries as nodes, node types are defined according to blockchain business logic (contract log nodes, node log nodes, and test framework log nodes), and three types of edge relationships are constructed. For example, causal edges: such as "Contract compilation failure log" → "Test case execution failure log" (test interrupted due to compilation failure); attribution edges: such as "Transaction execution log" → "Block log" (a transaction belongs to a specific block); node association edges: such as "Node A synchronization failure log" → "Node B connection timeout log" (Node A synchronization failed because Node B could not connect). Then, graph convolution is applied. The Generative Network (GCN) trains on the log graph. Each node updates its own features by aggregating features from its neighbors (e.g., for a node with "test case execution failure log", the features of "contract compilation failure log" associated with its causal edge are aggregated with the features of "block log" associated with its home edge, forming more correlated node features). Finally, the node features output by the GNN are input into an anomaly detection model based on an isolated forest (the training set is the features of historical normal blockchain test logs). When the feature vector deviates from the normal range, it is marked as an abnormal test log, and an anomaly confidence score is output (e.g., 0.92 indicates a 92% probability of being abnormal).

[0055] Step 203: Based on the test environment information, code change information, and abnormal test logs carried in the code change request, perform fault diagnosis to determine the cause of the fault.

[0056] The test environment information can be the full set of environment configuration data supporting the blockchain test operation carried in the code change request, such as the blockchain network type, node configuration parameters, test framework version, smart contract compiler version, hardware resource configuration, and environment variables required for the operation of dependencies. The cause of failure can be the root cause of the abnormality in the blockchain test that has been diagnosed, including but not limited to incompatibility between dependency version and test environment, mismatch between configuration parameters and network type, incorrect import path, conflict between contract logic and new dependency adaptation, and abnormal dependency operation caused by insufficient test environment resources.

[0057] Optionally, in this embodiment, the test environment information, code change information, and abnormal test logs carried in the code change request can be used as input data. Fault diagnosis can be performed by an AI (Artificial Intelligence) big model that integrates knowledge of the blockchain field. Alternatively, fault diagnosis can be performed by a pre-trained neural network model. Therefore, this embodiment does not limit the scope of the fault diagnosis.

[0058] It is worth noting that this embodiment uses a large AI model integrating blockchain knowledge for fault diagnosis as an example. This includes injecting blockchain-specific testing knowledge into the large AI model (such as a model fine-tuned based on GPT-4), covering dependency knowledge, fault mode knowledge, and blockchain characteristic knowledge. Dependency knowledge can include changes in the parameter order of the safeTransferFrom function in OpenZeppelin contract library version 4.9.0, differences in the return fields of the provider.getBlock method between ethers.js versions 6.x and 5.x, and the version compatibility matrix between the Hardhat plugin and the node SDK. Fault mode knowledge can include contract compilation errors such as DeclarationError: Undeclared identifier possibly due to incompatibility of the imported contract library version, node synchronization timeout possibly due to inconsistent SDK versions leading to P2P protocol mismatch, and transaction rollback Insufficient gas possibly due to changes in the default gas calculation logic after the dependency library is updated. Blockchain characteristic knowledge can include the impact of ERC-20 / ERC-721 standard interface changes, PoS consensus node Validator configuration dependencies, and plugin version coordination requirements in cross-chain testing.

[0059] The abnormal test logs, code change information, and test environment information are integrated into the input data of the AI ​​diagnostic model. The example format is as follows: Abnormal test log: Type = Contract execution exception, Content = Transaction reverted:ERC20: transfer amount exceeds balance, Related fields = Transaction hash 0x789, Block height 1056, Abnormal confidence 0.95; Code change: The version of @openzeppelin / contracts in the package.json file was changed from 4.8.0 to 4.9.0, and the change time was 2025-10-09 18:00; Test environment: ETH testnet (Sepolia), Hardhat 2.17.0, Node SDK version 1.11.4.

[0060] The AI-powered large-scale model, based on input information and injected domain knowledge, performs three steps of reasoning: Step 1: Correlate code changes with anomaly test logs. For example, identify the temporal correlation between OpenZeppelin contract library version changes and ERC20 transfer rollbacks (the first anomaly after the change). Step 2: Retrieve domain knowledge. For example, confirm that the transfer function of the ERC20 contract in OpenZeppelin version 4.9.0 has added balance verification accuracy optimization. If the balance calculation logic in the test cases is not updated synchronously, it will lead to sufficient balance but verification failure. Step 3: Output the root cause. For example, the root cause is that the change in the ERC20 transfer balance verification logic due to the OpenZeppelin contract library version 4.9.0 change, and the balance calculation code in the test cases is not adapted. The root cause confidence level (e.g., 0.94) is given.

[0061] The AI ​​big model outputs specific, actionable solutions based on the root cause, including: short-term fixes, such as rolling back the @openzeppelin / contracts version to 4.8.0 and recompiling and testing the contract; long-term adaptation solutions, such as modifying the balance calculation code in the test cases to adjust it according to the verification logic of OpenZeppelin 4.9.0 (e.g., adding decimals() precision conversion); and verification methods, such as re-executing the ERC20 transfer test cases to check whether the transaction was successfully recorded on the chain and whether the Transfer event parameters in the contract event log are correct.

[0062] Step 204: Determine the fault code from the difference codes based on the fault cause, and generate a fault solution based on the fault cause.

[0063] Among them, the fault code can be the specific changes in the difference code that directly cause the fault; the fault solution can be a repair plan that can be directly implemented based on the fault cause and fault code, including but not limited to measures such as rollback or upgrade of dependent versions, adjustment of configuration parameters, correction of import path, optimization of contract logic compatibility and adjustment of test environment parameters.

[0064] Optionally, based on the cause of the fault determined by AI diagnosis, a scan and match is performed in the complete set of differing codes to accurately locate the code change fragments directly related to it, i.e. the fault code; then, based on the cause of the fault, the AI ​​big model is called to generate specific short-term or long-term repair solutions, including rolling back dependent versions and modifying code logic, and the verification solution is output simultaneously.

[0065] In one embodiment, the method for obtaining fault codes is further described, including: determining the fault type corresponding to the fault cause; and determining the fault code from the difference codes according to the code matching rules associated with the fault type.

[0066] Among them, the code matching rules can be filtering and identification criteria predefined for each fault type, used to accurately locate fault code fragments in the differential codes.

[0067] Optionally, the causes of the faults identified through diagnosis are analyzed and classified, and mapped to predefined fault types. Then, the code matching rules associated with the fault type are called, and the complete difference code is automatically scanned and matched based on the matching rules. Finally, the specific code fragments that cause the fault of this type are accurately filtered and located, i.e., the fault codes.

[0068] It is worth noting that this embodiment takes the root cause of the fault (i.e., the cause of the fault) output by the AI ​​large model as an example to illustrate how to match related code fragments in the cached code change content to achieve a precise mapping between the fault and the code. Specifically, matching rules are defined according to the blockchain fault type. For example, the matching rule for ERC20 transfer anomalies caused by the OpenZeppelin contract library version change is: file type is smart contract code (.sol) or test script (.js / .ts), etc.; keywords: import@openzeppelin / contracts / token / ERC20 / ERC20.sol, transfer and balanceOf, etc.; change type is dependency version modification or contract function call code modification, etc.

[0069] In the cached code changes, filter related fragments according to matching rules. For example, extract the call code of await token.transfer(recipient, amount) in test-erc20.js and the version change code of import@openzeppelin / contracts / token / ERC20 / ERC20.sol in ERC20Token.sol.

[0070] Store the root cause of the failure, the solution, the related code snippets, and the details of the abnormal test logs in a structured file (such as JSON format). The file is named according to "failure time-blockchain network type" (such as "20251011-1430-ETH-Sepolia-Fault.json"), which makes it easy for testers to trace back and review.

[0071] For example, this embodiment can also implement tiered and timed early warnings based on the scope and urgency of the fault, ensuring that testers obtain key fault information in a timely manner. This includes: classifying the blockchain test faults into three priority levels according to their impact on the test process, business functions, and system stability. For example, high priority: affecting core test processes (such as contract compilation failure causing all test cases to be interrupted), involving key modules such as consensus mechanisms / cross-chain (such as node synchronization failure causing consensus testing to be impossible); medium priority: affecting a single type of test case (such as ERC20 transfer test failure, other tests are normal), not interrupting the overall test process (such as some transaction logs being abnormal but testing can continue); low priority: only logs have minor anomalies (such as node SDK alarms but not affecting test results), and the scope of the fault impact is extremely small (such as a non-core assertion failure in a single test case).

[0072] Scheduled tasks can also be configured. For example, high-priority faults: real-time triggering of alerts (i.e., push within 1 minute after fault identification), and repeated push every 10 minutes until the fault is marked as "processed"; medium-priority faults: scheduled push every 30 minutes (e.g., 14:00, 14:30, 15:00), pushing all unprocessed medium-priority faults at once; low-priority faults: scheduled push at a fixed time every day (e.g., 18:00), reducing interference to testers.

[0073] Finally, the push notification includes the fault priority, root cause (AI analysis results), link to related code snippets, solution (short-term or long-term), list of affected test cases, and path to view abnormal test logs; the notification is then pushed to a designated test group, high-priority faults trigger notifications for all members, while medium / low-priority faults only send group messages; clicking the "View Details" link in the notification message allows direct access to the stored fault information file.

[0074] In the aforementioned blockchain testing method, blockchain testing is triggered by code change requests, and code change information is locked based on the differencing code, accurately identifying potential causes of failures; abnormal test logs are identified by constructing log graphs, and scattered multi-source test logs are linked according to business logic to form a traceable link, achieving accurate identification of abnormal test logs; failure diagnosis is performed by integrating test environment information, code change information, and abnormal test logs, improving the accuracy of failure cause determination; and fault codes are located from the differencing code and targeted solutions are generated, achieving precise location of blockchain test failures.

[0075] In one exemplary embodiment, the steps for determining code change information are further described, including:

[0076] Step 301: Determine the difference code corresponding to the code change request and the multiple configuration files for the difference code change.

[0077] In this context, the configuration file can be a structured file used in a blockchain project to declare dependencies, configure runtime parameters, and define environment properties.

[0078] Optionally, upon receiving a code change request submitted by a user, a blockchain test is triggered. Then, a code comparison operation is performed using a version control tool (such as Git). The base version code in the code repository is used as a reference, and a full comparison is performed with the changed code corresponding to the code change request to generate differential code containing all changed files and specific changes. Based on preset blockchain configuration file feature rules, all changed configuration files are selected from the generated differential code, and finally, the differential code corresponding to the code change request and its multiple changed configuration files are determined.

[0079] Step 302: Select at least one dependency configuration file from multiple configuration files. The dependency configuration files include direct dependency configuration files, indirect dependency association files, and off-chain dependency configuration files.

[0080] Among them, the dependency configuration file can be a dedicated configuration file selected from multiple configuration files, used in the blockchain project to declare, manage, and call direct dependencies, indirect dependencies, and off-chain dependencies.

[0081] Optionally, based on preset blockchain dependency configuration file feature rules, multiple determined change configuration files are screened one by one to identify dependency configuration files that meet the feature rules. The dependency configuration files are at least one of the following: direct dependency configuration files, indirect dependency related files, and off-chain dependency configuration files. Finally, at least one dependency configuration file is selected.

[0082] In one embodiment, the selection steps for dependency configuration files are further explained, including: determining multiple reference file paths, where different reference file paths represent different configuration file types, including direct dependency configuration files, indirect dependency associated files, and / or off-chain dependency configuration files; for each configuration file among the multiple configuration files, matching the file path of the configuration file with the multiple reference file paths, and determining the configuration file as a candidate configuration file if a match is successful; and determining the candidate configuration file as a dependency configuration file if the candidate configuration file meets the keyword matching rules.

[0083] The reference file path can be a pre-defined standard path corresponding to various dependency-related configuration file types in a blockchain project; the candidate configuration file can be a configuration file whose file path is initially determined to be likely to belong to a dependency-related type after successfully matching the file path of the configuration file with the pre-defined reference file path, and is a candidate set of dependency configuration files; the keyword matching rule can be a pre-defined set of keyword rules used to verify whether the candidate configuration file has dependency management functions.

[0084] Optionally, multiple reference file paths corresponding to direct dependency configuration files, indirect dependency associated files, and off-chain dependency configuration files are pre-defined. For each of the obtained configuration files, the file path of each configuration file is extracted and matched with the pre-defined multiple reference file paths. If the file path of a configuration file matches any of the reference file paths, the configuration file is determined as a candidate configuration file. The content of the candidate configuration file is further verified to meet the keyword matching rules (i.e., it contains dependency-related exclusive keywords). If the keyword matching rules are met, the candidate configuration file is finally determined as the dependency configuration file. If the change type is deletion or modification, a configuration file comparison operation is performed using a version control tool (such as Git) to determine the path of the stored configuration file. If the change type is addition, the storage location in the repository specified by the user when submitting the change (e.g., if the user creates a configuration file in the crosschain directory of the local project, Git diff will directly record this directory path after submission) is the native output information of Git diff for the addition file.

[0085] It is worth noting that this implementation method filters dependency-related files in the Gitdiff output by pre-setting the relationship between the blockchain and the dependency file feature library. These include: direct dependency configuration files, such as hardhat.config.js (plugin version of the Hardhat framework, contract library reference), truffle-config.js (Truffle node dependencies, compiler version), and package.json (test framework managed by npm, contract library version); indirect dependency related files, such as import statements in smart contract code (e.g., import "@openzeppelin / contracts / token / ERC20 / ERC20.sol"), and node SDK call code in test scripts (e.g., the ethers.js version corresponding to ethers.provider.getBlock()); and off-chain dependency configuration files, such as Oracle service configuration files (off-chain data interface version in oracle.config.js) and cross-chain plugin configurations (cross-chain SDK in crosschain-plugin.json). Version); the log filtering method combines file path matching with keyword regular expressions (e.g., matching files whose paths contain "config" and whose content contains "version" and "import") to exclude code changes unrelated to dependencies (e.g., changes to test case assertion text). Therefore, the above method improves the targeting and efficiency of subsequent fault diagnosis and code location by accurately filtering dependency configuration files.

[0086] Step 303: Parse the dependency configuration file and extract key information to obtain the key change information.

[0087] Among them, the key information for changes can be the key information parsed and extracted from the dependency configuration file that has been changed.

[0088] Optionally, based on at least one selected dependency configuration file, and combined with the structured parsing rules corresponding to the file type, key information related to the dependency is extracted from the file one by one, including core content such as dependency name, version number, import path, and configuration parameters. At the same time, the change type (addition / modification / deletion) and the position identifier in the file of the key information are recorded. After the extracted information is deredundant and structured, standardized key change information is formed.

[0089] In one embodiment, the steps for determining key change information are further explained, including: determining the change type of the dependency configuration file; if the change type of the dependency configuration file is an addition type, then extracting the dependency version information in the dependency configuration file; if the change type of the dependency configuration file is a deletion type, then extracting the dependency library name and version information in the dependency configuration file; if the change type of the dependency configuration file is a modification type, then obtaining the change details by comparing the dependency configuration file before the change with the dependency configuration file after the change.

[0090] The change types include adding, deleting, and modifying; the dependency version information can be the dependency version field in the newly added dependency configuration file; the dependency library name can be the dependency library name associated with the deleted dependency reference file; the version information can be the version of the deleted dependency reference file; and the change details include the changed field name, old value, and new value.

[0091] It is worth noting that this implementation method categorizes and parses the filtered files according to the type of change and extracts key information. Specifically, if it is a newly added dependency configuration file (such as adding oracle.config.js), the dependency version field is extracted (such as "oracle-sdk-version": "1.5.0"); if it is a deleted dependency reference file (such as deleting a contract file containing import "@openzeppelin / contracts"), the name of the deleted dependency library and its original version are recorded; the content before and after the file modification is compared, and the details of the dependency-related changes are extracted (such as the version of "@openzeppelin / contracts" in package.json being changed from "4.8.0" to "4.9.0", and the version of the hardhat-ethers plugin in hardhat.config.js being changed from "2.2.0" to "2.3.0"), and the changed field names, old values, and new values ​​are recorded simultaneously.

[0092] Step 304: Generate code change information based on the file path, change type, and key change information corresponding to the dependency configuration file.

[0093] Optionally, by associating and integrating the path identifier of the dependency configuration file, the type classification of the change operation, and the key details describing the specific changes in the dependency relationship, a structured code change record containing complete information such as the change location, operation behavior, and change content can be generated.

[0094] It is worth noting that in this implementation, the parsed file path, change type, and dependency change details are stored in a distributed cache (such as Redis). The cache structure is classified according to the blockchain network type (such as ETH testnet, hyperchain testnet, and Fabric consortium chain). Each cache entry contains a timestamp (code submission time), submitter, and change summary, which facilitates subsequent correlation analysis with abnormal test logs.

[0095] For example, such as Figure 4 As shown, this embodiment initiates the blockchain test execution process, triggering the blockchain code change parsing module to analyze Git code differences (Git diff); it determines whether there are changes to dependency configuration files: if so, it categorizes and parses the change type (addition / deletion / modification), and caches the changed content in distributed storage; if not, it directly enters the multi-source log intelligent processing module; the multi-source log intelligent processing module completes log collection and parsing, sequentially performing log component extraction (including blockchain-specific fields), feature vector conversion, and GNN correlation analysis; it identifies abnormal test logs (such as contract compilation failure, node synchronization timeout), and transmits the abnormal information to the AI ​​large model fault diagnosis module; the AI ​​large model fault diagnosis module inputs abnormal test logs, code change cache information, and blockchain domain knowledge to generate fault root causes (such as indirect dependency version conflicts) and solutions (such as rolling back SDK versions); the fault-code matching module extracts code fragments associated with the fault from the cached code; it stores the fault information, solutions, and associated code as structured files; the hierarchical timed early warning module creates timed tasks according to fault priority and pushes early warnings to testers to end the overall process.

[0096] In this embodiment, by determining the differential code corresponding to the code change request and multiple configuration files for the differential code change; selecting at least one dependency configuration file from the multiple configuration files, the dependency configuration files include direct dependency configuration files, indirect dependency associated files, and off-chain dependency configuration files; parsing the dependency configuration files and extracting key information to obtain key change information; and generating code change information based on the file path, change type, and key change information corresponding to the dependency configuration files, it is possible to accurately locate faults caused by indirect dependency changes and improve dependency analysis coverage.

[0097] To more comprehensively demonstrate this solution, this embodiment provides an optional approach to blockchain testing, specifically including:

[0098] 1. Upon receiving a code change request, initiate blockchain testing to determine the differential code corresponding to the code change request and the multiple configuration files involved in the differential code change;

[0099] 2. Select at least one dependency configuration file from multiple configuration files. Dependency configuration files include direct dependency configuration files, indirect dependency association files, and off-chain dependency configuration files.

[0100] 3. Parse the dependency configuration file and extract key information to obtain key change information;

[0101] 4. Generate code change information based on the file path, change type, and key change information corresponding to the dependency configuration file;

[0102] 5. For each test log in the test log collection, extract the key log information from the test log;

[0103] 6. Extract the key information features from the test logs to obtain the log feature vector of the test logs;

[0104] 7. Construct a log graph based on the log feature vector of each test log in the test log set. Each node in the log graph corresponds to a test log and contains the log feature vector associated with the test log. The edges represent the association between the test logs corresponding to the nodes.

[0105] 8. Identify abnormal test logs from the test logs based on the log graphs;

[0106] 9. Based on the test environment information, code change information, and abnormal test logs carried in the code change request, perform fault diagnosis to determine the cause of the fault;

[0107] 10. Determine the fault code from the difference code based on the fault cause, and generate a fault solution based on the fault cause.

[0108] The specific process of the above steps can be found in the description of the above method embodiments. The implementation principle and technical effect are similar, and will not be repeated here.

[0109] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0110] Based on the same inventive concept, this application also provides a blockchain testing apparatus for implementing the blockchain testing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more blockchain testing apparatus embodiments provided below can be found in the limitations of the blockchain testing method described above, and will not be repeated here.

[0111] In one exemplary embodiment, such as Figure 5 As shown, a blockchain testing device is provided, including: a code parsing module 51, a log processing module 52, and a fault diagnosis module 53, wherein:

[0112] The code parsing module 51 is used to start blockchain testing when a code change request is received. In the blockchain test, the code change information is determined based on the difference code corresponding to the code change request.

[0113] Log processing module 52 is used to construct a log graph based on the set of test logs generated during blockchain testing, and to identify abnormal test logs from the test logs according to the log graph;

[0114] The fault diagnosis module 53 is used to diagnose faults and determine the cause of faults based on the test environment information, code change information and abnormal test logs carried in the code change request.

[0115] The fault diagnosis module 53 is also used to determine the fault code from the difference code based on the fault cause, and to generate a fault solution based on the fault cause.

[0116] In one embodiment, the code parsing module 51 is further configured to:

[0117] Identify the differential code corresponding to the code change request and the multiple configuration files for the differential code change; select at least one dependency configuration file from the multiple configuration files, including direct dependency configuration files, indirect dependency associated files, and off-chain dependency configuration files; parse the dependency configuration files and extract key information to obtain key change information; generate code change information based on the file path, change type, and key change information corresponding to the dependency configuration files.

[0118] In one embodiment, the code parsing module 51 is further configured to:

[0119] Multiple reference file paths are identified, each representing a different configuration file type, including direct dependency configuration files, indirect dependency files, and / or off-chain dependency configuration files. For each configuration file, its file path is matched against the multiple reference file paths. If a match is found, the configuration file is identified as a candidate configuration file. If the candidate configuration file satisfies the keyword matching rules, it is identified as a dependency configuration file.

[0120] In one embodiment, the code parsing module 51 is further configured to:

[0121] Determine the change type of the dependency configuration file; if the change type is "addition", extract the dependency version information from the dependency configuration file; if the change type is "deletion", extract the dependency library name and version information from the dependency configuration file; if the change type is "modification", obtain the change details by comparing the dependency configuration file before and after the change.

[0122] In one embodiment, the code log processing module 52 is further configured to:

[0123] For each test log in the test log set, extract the key information of the test log; extract the features of the key information of the test log to obtain the log feature vector of the test log; construct a log graph based on the log feature vector of each test log in the test log set. Each node in the log graph corresponds to a test log and contains the log feature vector associated with the test log. The edges represent the association between the test logs corresponding to the nodes.

[0124] In one embodiment, the fault diagnosis and processing module 53 is further configured to:

[0125] Determine the fault type corresponding to the cause of the fault; determine the fault code from the difference codes according to the code matching rules associated with the fault type.

[0126] Each module in the aforementioned blockchain testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0127] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores blockchain test data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a blockchain testing method.

[0128] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a blockchain testing method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0129] Those skilled in the art will understand that Figure 6 and Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0130] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0131] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0132] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0133] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0134] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0135] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0136] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A blockchain testing method, characterized in that, The method includes: Upon receiving a code change request, a blockchain test is initiated, in which code change information is determined based on the difference code corresponding to the code change request. A log graph is constructed based on the set of test logs generated during the blockchain testing process, and abnormal test logs are identified from the test logs according to the log graph. Based on the test environment information carried in the code change request, the code change information, and the abnormal test log, fault diagnosis is performed to determine the cause of the fault; Based on the cause of the fault, the fault code is determined from the difference code, and a fault solution is generated based on the cause of the fault.

2. The method according to claim 1, characterized in that, The step of determining the code change information based on the difference code corresponding to the code change request includes: Identify the difference code corresponding to the code change request and the multiple configuration files for the difference code change; Select at least one dependency configuration file from the plurality of configuration files, wherein the dependency configuration files include direct dependency configuration files, indirect dependency association files, and off-chain dependency configuration files; The dependency configuration file is parsed and key information is extracted to obtain the key change information; Based on the file path, change type, and key change information corresponding to the dependency configuration file, code change information is generated.

3. The method according to claim 2, characterized in that, The step of selecting at least one dependency configuration file from the plurality of configuration files includes: Multiple reference file paths are determined, and different reference file paths represent different configuration file types, including direct dependency configuration files, indirect dependency associated files, and / or off-chain dependency configuration files. For each of the plurality of configuration files, the file path of the configuration file is matched with the plurality of reference file paths. If a match is successful, the configuration file is determined as a candidate configuration file. If the candidate configuration file satisfies the keyword matching rules, the candidate configuration file is determined as the dependency configuration file.

4. The method according to claim 2, characterized in that, The process of parsing the dependency configuration file and extracting key information to obtain key change information includes: Determine the type of change to the dependency configuration file; If the change type of the dependency configuration file is a new addition, then extract the dependency version information from the dependency configuration file; If the change type of the dependency configuration file is deletion, then extract the dependency library name and version information from the dependency configuration file; If the change type of the dependency configuration file is modification, the change details are obtained by comparing the dependency configuration file before the change with the dependency configuration file after the change.

5. The method according to any one of claims 1 to 4, characterized in that, The construction of the log graph based on the set of test logs generated during the blockchain testing process includes: For each test log in the test log set, extract the key log information from the test log; Extract the features of the key information in the test logs to obtain the log feature vector of the test logs; A log graph is constructed based on the log feature vector of each test log in the test log set. Each node in the log graph corresponds to a test log and contains the log feature vector associated with the test log. The edges represent the association between the test logs corresponding to the nodes.

6. The method according to any one of claims 1 to 4, characterized in that, Determining the fault code from the difference codes based on the fault cause includes: Determine the fault type corresponding to the cause of the fault; The fault code is determined from the difference codes according to the code matching rules associated with the fault type.

7. A blockchain testing device, characterized in that, The device includes: The code parsing module is used to initiate a blockchain test upon receiving a code change request, and in the blockchain test, determine the code change information based on the difference code corresponding to the code change request; The log processing module is used to construct a log graph based on the set of test logs generated during the blockchain test, and to determine abnormal test logs from the test logs according to the log graph. The fault diagnosis module is used to perform fault diagnosis based on the test environment information carried in the code change request, the code change information, and the abnormal test log, and to determine the cause of the fault. The fault diagnosis module is further configured to determine the fault code from the difference code based on the fault cause, and generate a fault solution based on the fault cause.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images