Smart contract testing method and apparatus, electronic device, and computer-readable storage medium

Abstract

This application discloses a smart contract testing method, apparatus, electronic device, and computer-readable storage medium, relating to the field of blockchain technology. The method involves: determining a target smart contract to be tested and determining target test cases for testing the target smart contract; obtaining a modifier contract corresponding to the target smart contract; using the modifier contract to call and execute the target smart contract across contracts according to the target test cases to test the target smart contract; and recording the contract execution information of the target smart contract during the testing process using the modifier contract. This application achieves automated recording of smart contract execution information and eliminates manual intervention in the entire recording process, thereby improving the efficiency of contract execution information recording.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a smart contract testing method, a smart contract testing device, an electronic device, and a computer-readable storage medium. Background Technology

[0002] With the development of blockchain technology, it has gradually moved from theory to practice, and its application scope clearly covers many fields such as financial services, supply chain management, and real estate transactions.

[0003] Smart contracts are specific functional code executed on a blockchain, serving as a crucial means for users to interact with the blockchain and implement business logic. Therefore, to ensure the proper functioning and accuracy of smart contracts, they need to be tested, and relevant contract execution information needs to be recorded during the testing process. However, in related technologies, recording contract execution information requires significant manual intervention, impacting the efficiency of this process. Summary of the Invention

[0004] This application provides a smart contract testing method, a smart contract testing device, an electronic device, and a computer-readable storage medium, which can improve the efficiency of recording contract execution information.

[0005] Firstly, the smart contract testing methods provided in this application include:

[0006] Identify the target smart contract to be tested, and identify the target test cases for testing the target smart contract;

[0007] Obtain the modifier contract corresponding to the target smart contract;

[0008] The target smart contract is tested by calling cross-contract execution through the decorator contract according to the target test cases.

[0009] The modifier contract records the contract execution information of the target smart contract during the testing process.

[0010] Secondly, the smart contract testing device provided in this application includes:

[0011] The test determination module is used to determine the target smart contract to be tested, and to determine the target test cases for testing the target smart contract;

[0012] The contract acquisition module is used to acquire the modifier contract corresponding to the target smart contract;

[0013] The contract invocation module is used to invoke the execution of the target smart contract across contracts through the decorator contract, based on the target test cases, in order to test the target smart contract;

[0014] The information recording module is used to record the contract execution information of the target smart contract during the testing process through the modifier contract.

[0015] Optionally, in one embodiment, the modifier contract includes a cross-contract call function. The contract call module is used to determine the target function to be called in the target smart contract based on the target test case, and to determine the input parameters for the target function; and to call the target function in the target smart contract for execution through the cross-contract call function based on the input parameters.

[0016] Optionally, in one embodiment, the modifier contract further includes a recording function. The information recording module is used to obtain the output result of the target function and the call description information corresponding to the target function; and to record the call description information, output result and input parameters as contract execution information through the recording function.

[0017] Optionally, in one embodiment, the information recording module is used to format the call description information, output results, and input parameters as contract execution information into log entries through a recording function, and record the log entries to a log file.

[0018] Optionally, in one embodiment, the modifier contract further includes a replay function. The smart contract testing device provided in this application further includes a test replay module, which is used to control the cross-contract call function to call the target smart contract's target function in the test through the replay function according to the log entries recorded in the log file, so as to perform test replay on the target smart contract.

[0019] Optionally, in one embodiment, the test replay module is used to determine the start log entry and the end log entry in the log file; and based on all log entries from the start log entry to the end log entry recorded in the log file, to control the execution of the target function of the cross-contract call function in the test process through the replay function.

[0020] Optionally, in one embodiment, the smart contract testing device provided in this application further includes a quality assessment module, used to obtain contract execution difference information of the target smart contract during the testing process and test replay process; and to obtain the execution stability of the target smart contract based on the contract execution difference information.

[0021] Thirdly, the electronic device provided in this application includes a memory and a processor. The memory stores a computer program, and the processor is used to run the computer program in the memory to implement the steps in the smart contract testing method provided in this application.

[0022] Fourthly, the computer-readable storage medium provided in this application stores a computer program that is adapted to run on a processor to implement the steps in the smart contract testing method provided in this application.

[0023] The smart contract testing solution provided in this application first determines the target smart contract to be tested and the target test cases for testing the target smart contract. Then, it obtains the modifier contract corresponding to the target smart contract. Then, through the modifier contract, it calls the target smart contract across contracts to execute the target smart contract in order to test the target smart contract. The modifier contract records the contract execution information of the target smart contract during the testing process. This realizes the automated recording of the smart contract's contract execution information and eliminates manual intervention in the entire recording process, thereby improving the efficiency of contract execution information recording. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0025] Figure 1a This is a schematic diagram of a smart contract testing system provided in an embodiment of this application;

[0026] Figure 1b This is a flowchart illustrating the smart contract testing method provided in this application embodiment;

[0027] Figure 1c This is a schematic diagram illustrating the generation of replay test cases based on log files in an embodiment of this application;

[0028] Figure 1d This is a schematic diagram of test playback based on replay test cases in an embodiment of this application;

[0029] Figure 2a This is another flowchart illustrating the smart contract testing method provided in this application embodiment;

[0030] Figure 2b This is a schematic diagram illustrating the testing and replay of the target smart contract according to an embodiment of this application;

[0031] Figure 3 This is a schematic diagram of the structure of the smart contract testing device provided in the embodiments of this application;

[0032] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0033] It should be noted that the principles of this application are illustrated by example in a suitable computing environment. The following description is based on the specific embodiments of this application that are illustrated, and should not be regarded as limiting other specific embodiments not detailed herein.

[0034] In the following description of this application, "some embodiments" are referred to, which describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subset of all possible embodiments, and may be combined with each other without conflict.

[0035] In the following description of this application, the terms "first, second, third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0036] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0037] In related technologies, to obtain contract execution information during smart contract testing, testers currently need to manually write test logs to record the execution information of each operation performed by the smart contract during testing. This method requires test engineers to spend a significant amount of time and effort writing and maintaining test logs. However, manually writing test logs is not only inefficient but also prone to omissions or errors. Especially when the test cases used to test smart contracts become complex or are frequently modified, testers may overlook some key information due to negligence or fatigue, resulting in incomplete or inaccurate contract execution information recorded in the test logs.

[0038] To reduce manual intervention in recording contract execution information during smart contract testing and improve the efficiency of recording such information, this application provides a smart contract testing method, a smart contract testing device, an electronic device, and a computer-readable storage medium. The smart contract testing method can be executed by the smart contract testing device or by an electronic device integrated with the smart contract testing device.

[0039] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] Please refer to the reference. Figure 1a This application also provides a smart contract testing system, which includes an electronic device 100 for executing the smart contract testing method provided in this application. The electronic device 100 can be a device equipped with a processor and having data processing capabilities, such as a smartphone, tablet, PDA, laptop, or other mobile device with a processor, or a desktop computer, server, or other fixed device with a processor. When executing the smart contract testing method provided in this application, the system determines the target smart contract to be tested and the target test cases for testing the target smart contract; obtains the modifier contract corresponding to the target smart contract; uses the modifier contract to call the target smart contract across contracts according to the target test cases to test the target smart contract; and records the contract execution information of the target smart contract during the testing process using the modifier contract.

[0041] In addition, such as Figure 1a As shown, the smart contract testing system may also include a memory 200 for storing relevant data during the smart contract testing process, such as the contract address of the determined target smart contract, the description information of the determined target test cases, and the finally recorded contract execution information, etc.

[0042] It should be noted that the smart contract testing system described above is merely an example, intended to more clearly illustrate the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of smart contract testing systems and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0043] The following sections provide detailed descriptions of each example. It should be noted that the sequence numbers of the following embodiments are not intended to limit the preferred order of the embodiments.

[0044] Please refer to Figure 1b This embodiment provides a smart contract testing method, such as... Figure 1b As shown, the process of this smart contract testing method can be as follows:

[0045] In step 110, the target smart contract to be tested is identified, as well as the target test cases used to test the target smart contract.

[0046] A smart contract is a specific piece of code executed on a blockchain; it's a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. The implementation of smart contracts primarily relies on programming languages ​​and blockchain technology. Programming languages ​​are used to write the logic of smart contracts, while blockchain technology provides a decentralized and immutable execution environment. The execution of a smart contract is based on preset conditions; once these conditions are met, the code within the smart contract automatically executes the corresponding operations.

[0047] The target smart contract refers to the smart contract that uses the smart contract testing scheme provided in this application for smart contract testing. It can be a smart contract implemented on any blockchain technology and used to achieve any function, rather than referring to a specific smart contract.

[0048] In this embodiment of the application, in response to a contract testing requirement, the smart contract indicated by the contract testing requirement can be identified as the target smart contract that needs to be tested. The contract testing requirement can be input from outside the electronic device or triggered from inside the electronic device.

[0049] The target smart contract indicated by the contract testing requirement may or may not be unique. If the target smart contract indicated by the contract testing requirement is unique, meaning the contract testing requirement indicates only one target smart contract, then the smart contract testing scheme provided in this application is used to test that target smart contract. If the target smart contract indicated by the contract testing requirement is not unique, meaning the contract testing requirement indicates two or more target smart contracts, then the smart contract testing scheme provided in this application is used to test each target smart contract indicated by the contract testing requirement separately.

[0050] Typically, tests for smart contracts can take the following types:

[0051] Unit testing: Testing whether a single function in a smart contract works as expected.

[0052] Integration testing: Ensure that different parts of a smart contract or multiple contracts can work together.

[0053] Access control testing: Test the access control logic of smart contracts to ensure that only authorized users or contracts can execute specific functions.

[0054] Exception handling test: Test the smart contract's handling logic when encountering exceptional situations to ensure that the contract can respond correctly to errors and exceptions.

[0055] Security testing: This includes testing for common security vulnerabilities in smart contracts, such as reentrancy attacks, overflows, and underflows.

[0056] Performance testing: Evaluate the performance of smart contracts under high loads to ensure that smart contracts can meet performance requirements in actual operation.

[0057] Compatibility testing: Testing whether the smart contract can function properly in different blockchain environments.

[0058] Typically, test cases for smart contracts include at least a specific set of input parameters and expected output results. These are used to verify whether the smart contract behaves as expected under different conditions. Different test types have corresponding test cases. It should be noted that the same test case can be applied to smart contract testing across different test types. For example, a test case can be used for unit testing of a smart contract, performance testing of the smart contract, and compatibility testing of the smart contract.

[0059] After identifying the target smart contract that needs to be tested, the test cases that match the test type specified in the contract testing requirements are then selected as the target test cases for this test.

[0060] In this embodiment of the application, test cases can be collected and written in advance through a test framework, and test cases can be managed. Accordingly, when determining test cases for testing the target smart contract, the test framework can be used to filter out test cases that match the target smart contract, and then from these test cases that match the target smart contract, test cases that meet the test requirements of the contract can be determined as the target test cases for this test of the target smart contract.

[0061] A testing framework is a set of tools, libraries, and guidelines for supporting smart contract testing, such as Truffle, Hardhat, Embark, Foundry, etc. In practical applications, those skilled in the art can choose a suitable testing framework based on actual development needs and factors such as programming languages.

[0062] In step 120, obtain the modifier contract corresponding to the target smart contract.

[0063] A modifier contract refers to a smart contract constructed using modifier technology. In this embodiment, the modifier contract is configured to record the contract execution information of other smart contracts it calls during execution. The contract execution information includes relevant information when the other smart contract is executed, including but not limited to input parameters, output results, etc.

[0064] It should be noted that due to compatibility issues arising from differences in programming languages, the same smart contract cannot be applied to all blockchain environments; in other words, the same blockchain environment cannot be applied to all smart contracts. In this embodiment, after determining the target smart contract to be tested, a modifier contract corresponding to the target smart contract is further determined, that is, a modifier contract suitable for running in the blockchain environment applicable to the target smart contract. For example, if the determined target smart contract is suitable for running in blockchain environment A, a modifier contract also suitable for running in blockchain environment A is determined accordingly, serving as the modifier contract corresponding to the target smart contract, used for subsequent testing of the target smart contract and recording the contract execution information of the target smart contract during the testing process.

[0065] In 130, the target smart contract is executed by cross-contract calls based on the target test cases through the decorator contract to test the target smart contract.

[0066] In this embodiment of the application, the target smart contract and the modifier contract are also deployed to the corresponding blockchain environment so that the target smart contract can be tested using the target test cases in the blockchain environment.

[0067] The blockchain environment can be built using testing frameworks. For example, assuming the target smart contract is suitable for running in the Ethereum blockchain environment, the Ethereum blockchain environment can be built using testing frameworks such as Truffle, Hardhat, and Embark. Then, the target smart contract and the modifier contract can be deployed to the built Ethereum blockchain environment so that the target smart contract can be tested using the target test cases in the Ethereum blockchain environment.

[0068] It should be noted that, in order to enable the modifier contract to record the contract execution information during the testing process of the target smart contract, the target smart contract is not run directly. Instead, the target smart contract is tested by using the target test cases through the modifier contract and cross-contract calls.

[0069] Optionally, in one embodiment, the modifier contract includes a cross-contract call function. According to the target test case, the target smart contract is executed through cross-contract calls via the modifier contract, including:

[0070] Based on the target test cases, determine the target function to be called in the target smart contract, and determine the input parameters for the target function;

[0071] Based on the input parameters, the target function in the target smart contract is executed by calling the cross-contract function call function.

[0072] In this embodiment of the application, the modifier contract defines a cross-contract call function that calls a specified function in another smart contract based on specified input parameters.

[0073] For example, the modifier contract in this application embodiment is defined as follows:

[0074] contract TestLogger{

[0075] / / Define cross-contract call functions

[0076] function callotherContract(address targetContract, bytes memoryinputData, string memory description)internal returns(bytes memory){

[0077] / / Detailed implementation logic omitted here.

[0078] }

[0079] }

[0080] The modifier contract is named "TestLogger", and the function name for cross-contract call is "callotherContract".

[0081] `address targetContract` is an address-type parameter representing the other contract to be invoked. Each smart contract has its own contract address. Typically, a smart contract's contract address is obtained by hashing the smart contract's name using a hash algorithm. That is, a hash algorithm is used to hash the smart contract's name, and the result is used as the smart contract's contract address.

[0082] `bytes memory inputData` is a byte-type parameter used to store the call data to be sent to other contracts that need to be invoked, i.e., the input parameter.

[0083] The string memory description is a string parameter used to store additional information or descriptions about this cross-contract call, i.e., call description information.

[0084] `internal` is a visibility modifier that indicates that the cross-contract function call can only be called within the current contract (i.e., its modifier contract) or a contract that inherits from the current contract, and cannot be called by other external contracts.

[0085] `returns(bytes memory)` indicates that the cross-contract function call returns a byte value containing the data returned from the other contract being called. If the other contract does not return a value, or if the call fails, the returned data will be empty or invalid.

[0086] It should be noted that the determined target test case can consist of multiple single test cases corresponding to different test behaviors. When the target smart contract is executed across contracts through the decorator contract based on the target test case, for each single test case in the target test case, the function in the target smart contract corresponding to the test behavior is determined based on that single test case, denoted as the target function, and the input parameters used to call the target function are also determined.

[0087] For example, the following defines a target smart contract to be tested, which includes a sample function:

[0088] contract MyContract{

[0089] / / Example function

[0090] function myFunction(unit input)public pure return(unit){

[0091] / / Specific function logic

[0092] uint result = input * 2;

[0093] return result;

[0094] }

[0095] }

[0096] The target smart contract is named "MyContract", and the example function is named "myFunction".

[0097] `uint input` is an unsigned integer parameter used to store input parameters.

[0098] `public` is a visibility modifier that indicates that the example function can be called in the current contract (i.e., the target smart contract to which it belongs) or in contracts that inherit from the current contract, or it can be called by other external contracts.

[0099] "pure" is a modifier that indicates that the example function will not read or modify the state of the blockchain; it will only perform calculations and return the results.

[0100] The function returns(uint) indicates that this example function returns an unsigned integer value, which is the output result.

[0101] The function body is `uint result = input * 2`. This line of code multiplies the input parameter by 2 and stores the result in a variable named `result`.

[0102] The function of the line `return result` is to return the value of the variable `result`, and also to return the result of the multiplication operation above.

[0103] The following uses the CMC tool from Chang'an Chain as an example to illustrate the calling of example functions in the target smart contract above:

[0104] . / cmc client contract user invoke\

[0105] --contract-name=TestLogger\

[0106] --method=callotherContract\

[0107] --params="{\"contract_name\":\"MyContract\",\"contract_method\":\"myFuncti on\"

[0108] ,\"params_inner\":\"8\"}"\

[0109] --sdk-conf-path=. / testdata / sdk_config_pk.yml\

[0110] --sync-result=true

[0111] The command ". / cmc client contract user invoke\" is the basic part, indicating that the operation to be performed is "invoke", which means calling a function in the smart contract.

[0112] The "-contract-name=TestLogger" option specifies the name of the smart contract to be invoked, which is "TestLogger" in this case, the decorator contract.

[0113] The `--method=callotherContract:` option specifies the name of the function in the contract to be called. Here it is `callotherContract`, which means calling a function across contracts within the decorator contract.

[0114] The `--params="{"contract_name":"MyContract","contract_method":"myFunction","params_inner":"8"}"` parameter specifies the arguments to be passed to the cross-contract call function "callotherContract". Here, it is a JSON string containing three fields:

[0115] "contract_name":"MyContract": Specifies the name of the other contract to be invoked across contracts, here it is MyContract, which is the target smart contract in the example above.

[0116] "contract_method":"myFunction": Specifies the name of the target function to be called in the target smart contract above, which is myFunction, the example function above.

[0117] "params_inner":"8": The input parameter to be passed to the myFunction function, which is 8 in this case.

[0118] The `--sdk-conf-path=. / testdata / sdk_config_pk.yml:` option specifies the relative path to the SDK configuration file, which typically contains the configuration information required to connect to the blockchain, such as API keys, node addresses, etc.

[0119] The "--sync-result=true" option specifies that the call should be waited for a result to return synchronously.

[0120] As shown above, by calling the cross-contract call function "callotherContract" in the modifier contract, the cross-contract call to the target function "myFunction" in the target smart contract "MyContract" is realized. According to the above description, if the target function "myFunction" executes normally, it will return the output result "16" corresponding to the input parameter "8".

[0121] In 140, the modifier contract records the contract execution information of the target smart contract during the testing process.

[0122] As shown above, the modifier contract is configured to record the contract execution information of other smart contracts that are called. Accordingly, the modifier contract can be used to record the contract execution information of the target smart contract during the testing process. The specific type of contract execution information recorded depends on the actual testing requirements.

[0123] For example, assuming the target test case describes four test behaviors, the target smart contract is called across contracts to execute these four test behaviors for testing, and the input parameters and output results of the target smart contract during the execution of these four test behaviors are recorded as contract execution information.

[0124] Optionally, in one embodiment, the modifier contract further includes a recording function to record the execution information of the target smart contract during the testing process, including:

[0125] Obtain the output of the target function, and obtain the call description information corresponding to the target function;

[0126] By recording functions, the call description, output results, and input parameters are recorded as contract execution information.

[0127] In this embodiment of the application, the modifier contract also includes a recording function, which can be configured to record the execution information of the target smart contract during the testing process.

[0128] For example, in this application embodiment, the modifier contract can also be defined as follows:

[0129] contract TestLogger{

[0130] / / Define the recording function

[0131] function logstep(string memory description, string memory input, stringmemory output)internal{

[0132] / / Detailed implementation logic omitted here.

[0133] }

[0134] / / Define cross-contract call functions

[0135] function callotherContract(address targetContract, bytes memoryinputData, string memory description)internal returns(bytes memory){

[0136] / / Detailed implementation logic omitted here.

[0137] }

[0138] }

[0139] The logging function is named "logstep" and accepts the following three parameters:

[0140] The string memory description represents the call description information of the target function during a single call process; it is presented as a string here.

[0141] The string memory input represents the input parameters of the target function during a single call; it is presented as a string here.

[0142] The string memory output represents the output of the target function during a single call; it is presented as a string.

[0143] In this embodiment of the application, after a call to the target function in the target smart contract is completed according to the target test case through the cross-contract call parameters in the modifier contract, the output result of the target function in this call and the call description information of the target function in this call are obtained. Then, the call description information, input parameters and output result of the target function in this call process are recorded as contract execution information through the recording function. Here, there is no restriction on the recording format of the contract execution information.

[0144] Optionally, in one embodiment, a recording function is used to record the description information, output results, and input parameters as contract execution information, including...

[0145] By recording functions, the call description information, output results, and input parameters are formatted as contract execution information into log entries, and these log entries are recorded to a log file.

[0146] In this embodiment of the application, the recording function is configured to format the call description information, input parameters and output results into log entries, and record the log entries to a log file.

[0147] For example, in this application embodiment, the modifier contract can also be defined as follows:

[0148] contract TestLogger{

[0149] / / Define the relative path to the log file

[0150] string constant LOG_FILE="log.txt"

[0151] / / Define the recording function

[0152] function logstep(string memory description, string memory input, stringmemory output)internal{

[0153] / / Detailed implementation logic omitted here.

[0154] writeLogToFile(logEntry);

[0155] }

[0156] / / Define cross-contract call functions

[0157] function callotherContract(address targetContract, bytes memoryinputData, string memory description)internal returns(bytes memory){

[0158] / / Detailed implementation logic omitted here.

[0159] / / Call the logging function to record contract execution information

[0160] logStep("Call completed","","");

[0161] }

[0162] }

[0163] Based on the logging function "logstep" in the modifier contract in the example above, the contract execution information (call description, input parameters, and output results) of the cross-contract call function "callotherContract" calling the target function in the target smart contract "MyContract" can be formatted into log entries and recorded in the log file "log.txt". For example, two log entries recorded in the log file "log.txt" by the logging function are shown below:

[0164] 2024-01-01 12:20 131,contract name:MyContract,func:myFunction params:8result:16,Description:...;

[0165] 2024-01-01 12:20 437,contract name:MyContract,func:myFunction params:3result:6,Description:……;

[0166] The first log entry describes a call to the target function "myFunction" in the target smart contract "MyContract", which is a test behavior. The call time is "2024-01-01 12:20131", the input parameter is "8", the output result is "16", and the call description information is "...", which is omitted here.

[0167] The second log entry describes a call to the target function "myFunction" in the target smart contract "MyContract", which is also a test behavior. The call time is "2024-01-01 12:20437", the input parameter is "3", the output result is "6", and the call description information is "...", which is omitted here.

[0168] Optionally, in one embodiment, the modifier contract further includes a replay function. After formatting the call description information, output results, and input parameters as contract execution information into log entries using a recording function, and recording the log entries to a log file, the contract further includes:

[0169] Based on the log entries recorded in the log file, the replay function controls the cross-contract call function to execute the target function of the target smart contract in the test, so as to perform test replay of the target smart contract.

[0170] It should be noted that, in this embodiment of the application, a replay function is also defined in the modifier contract. The replay function is configured to control the cross-contract call function to call the target function corresponding to the log entry according to a log entry recorded in the log file, thereby realizing the replay of the test behavior of the target function during the test. In this way, the test replay of the entire or part of the test process of the target smart contract can be realized.

[0171] Please refer to Figure 1cFor a log entry in the log file, a single test case corresponding to the log entry is generated based on the contract execution information (such as input parameters) recorded in the log entry and the test case template. In this way, single test cases corresponding to all log entries can be generated, and these single test cases can be combined to form replay test cases for the target smart contract.

[0172] For example, the following log entries exist:

[0173] 2024-01-01 12:20 437,contract name:MyContract,func:myFunction params:3result:6,Description:……;

[0174] Based on this log entry, a corresponding single test case can be generated: "contract name:MyContract,func:myFunction params:3". This single test case targets the target function "myFunction" in the target smart contract "MyContract", and the input parameter is "3".

[0175] Accordingly, when there is a need for test replay, the replay function can be used to control the cross-contract call function to execute the target function of the target smart contract during the test process, thereby performing test replay on the target smart contract.

[0176] For example, continuing with the single test case shown above, the replay function will control the cross-contract call function "callotherContract" to call the target smart contract "MyContract" during the test process, and execute the target function "myFunction". The input parameter is "3". The specific implementation of the cross-contract call will not be elaborated here. Please refer to the relevant description in the above embodiments for details.

[0177] There are no restrictions on how the test replay requirement is triggered. For example, it could be triggered when the target smart contract encounters an exception during the test. The replay function can then be used to replay the test process of the target smart contract in order to reproduce the exception and eliminate it.

[0178] Optionally, in one embodiment, based on log entries recorded in the log file, the execution of the target function in the test of the cross-contract call function is controlled by a replay function, including:

[0179] Determine the start and end log entries in the log file;

[0180] Based on the start and end log entries, the replay function controls the execution of the target function in the target smart contract during the test process by invoking the cross-contract call function.

[0181] In the embodiments of this application, the replay function provides the ability to specify the start and end log entries for test replay, thereby providing more flexible test replay capabilities.

[0182] For example, in this application embodiment, the modifier contract can also be defined as follows:

[0183] contract TestLogger{

[0184] / / Define the relative path to the log file

[0185] string constant LOG_FILE="log.txt"

[0186] / / Define the recording function

[0187] function logstep(string memory description, string memory input, stringmemory output)internal{

[0188] / / Detailed implementation logic omitted here.

[0189] writeLogToFile(logEntry);

[0190] }

[0191] / / Define cross-contract call functions

[0192] function callotherContract(address targetContract, bytes memoryinputData, string memory description)internal returns(bytes memory){

[0193] / / Detailed implementation logic omitted here.

[0194] / / Call the logging function to record contract execution information

[0195] logStep("Call completed","","");

[0196] }

[0197] function return(unit start, unit end)public{

[0198] / / Specific implementation logic omitted here}

[0199] }

[0200] The function name for the playback function is "return".

[0201] `uint start` is an unsigned integer parameter used to specify the starting log entry for test replay.

[0202] `uint end` is an unsigned integer parameter used to specify the end log entry for the test replay.

[0203] Accordingly, in this embodiment, the starting log entry can be specified using the parameter "start", and the ending log entry can be specified using the parameter "end". This allows the single test case corresponding to the starting log entry to be determined as the starting single test case, and the single test case corresponding to the ending log entry to be determined as the ending single test case. Then, based on each single test case in the replay test cases from the starting single test case to the ending single test case, the replay function controls the execution of the target function of the target smart contract during the test process by calling the cross-contract call function, thereby re-executing the test behavior of the target function during the test process. This achieves the re-execution of the test behavior corresponding to the period from the starting log entry to the ending log entry, thus achieving the purpose of test replay. Figure 1d As shown.

[0204] Optionally, in one embodiment, the test replay capability passed in the above embodiments can be used to evaluate the execution stability of smart contracts. Based on the log entries recorded in the log file, after controlling the cross-contract call function to call the target smart contract in the test through the replay function, it further includes:

[0205] Obtain information on the differences in contract execution between the target smart contract during the testing process and the test replay process;

[0206] Based on the contract execution difference information, obtain the execution stability of the target smart contract.

[0207] It should be noted that in the embodiments of this application, the contract execution information of the target smart contract is recorded through the decorator contract, both during the testing process and the replay process. Based on the relevant descriptions in the above embodiments, it can be understood that the target smart contract performs exactly the same test behavior during the testing process and the replay process. Therefore, this application utilizes the execution differences of the target smart contract during the testing process and the replay process to evaluate the execution stability of the target smart contract.

[0208] Specifically, log entries corresponding to the testing process of the target smart contract and the test replay process can be obtained from the log files. Based on these log entries, the execution differences between the two processes can be identified. For example, this execution difference information can describe the differences in the same test behavior of the target smart contract between the testing and replay processes, such as differences in output results. It is understood that if the target smart contract outputs different results for the same input parameters, it indicates an instability in the execution of the target smart contract.

[0209] Furthermore, after obtaining the contract execution difference information of the target smart contract during the testing process and test replay, the execution stability of the target smart contract is further evaluated based on the contract execution difference information according to the configured stability evaluation strategy. There are no restrictions on the specific configuration of the stability evaluation strategy here.

[0210] For example, the stability assessment strategy can be configured as follows: if the target smart contract has no difference in output results in 1000 test behaviors, the execution stability of the target smart contract is determined to be high; if the target smart contract has 1-3 differences in output results in 1000 test behaviors, the execution stability of the target smart contract is determined to be medium; if the target smart contract has more than 3 differences in output results in 1000 test behaviors, the execution stability of the target smart contract is determined to be low.

[0211] As can be seen from the above, the smart contract testing method provided in this application first determines the target smart contract to be tested and the target test cases for testing the target smart contract. Then, it obtains the modifier contract corresponding to the target smart contract, and then uses the modifier contract to call the target smart contract across contracts to execute the target smart contract in order to test the target smart contract. In addition, the modifier contract records the contract execution information of the target smart contract during the testing process. This achieves the automated recording of the contract execution information of the smart contract and eliminates the need for manual intervention in the entire recording process, thereby improving the efficiency of recording contract execution information.

[0212] Please refer to the following: Figure 2a and Figure 2b Taking the execution subject of the smart contract testing method provided in this application as an electronic device as an example, the process of the smart contract testing method can also be as follows:

[0213] In 201, the electronic device identifies the target smart contract to be tested, and identifies the target test cases for testing the target smart contract.

[0214] In this embodiment of the application, in response to a contract testing requirement, the smart contract indicated by the contract testing requirement can be identified as the target smart contract that needs to be tested. The contract testing requirement can be input from outside the electronic device or triggered from inside the electronic device.

[0215] The target smart contract indicated by the contract testing requirement may or may not be unique. If the target smart contract indicated by the contract testing requirement is unique, meaning the contract testing requirement indicates only one target smart contract, then the smart contract testing scheme provided in this application is used to test that target smart contract. If the target smart contract indicated by the contract testing requirement is not unique, meaning the contract testing requirement indicates two or more target smart contracts, then the smart contract testing scheme provided in this application is used to test each target smart contract indicated by the contract testing requirement separately.

[0216] After identifying the target smart contract that needs to be tested, the electronic device further determines the test cases that match the test type specified in the contract testing requirements for the target smart contract as the target test cases for this test.

[0217] For example, electronic devices can pre-collect and write test cases through a testing framework and manage the test cases. Accordingly, when determining the test cases for testing the target smart contract, the testing framework can filter out the test cases that match the target smart contract, and then determine the test cases that meet the test requirements of the contract and are of the test type for the target smart contract, from these test cases that match the target smart contract, as the target test cases for this test of the target smart contract.

[0218] In 202, the electronic device obtains the modifier contract corresponding to the target smart contract. The modifier contract includes cross-contract call functions, recording functions, and replay functions.

[0219] A modifier contract refers to a smart contract constructed using modifier technology. In this embodiment, the modifier contract is configured to record the contract execution information of other smart contracts it calls during execution. The contract execution information includes relevant information when the other smart contract is executed, including but not limited to input parameters, output results, etc.

[0220] It should be noted that due to compatibility issues arising from differences in programming languages, the same smart contract cannot be applied to all blockchain environments; in other words, the same blockchain environment cannot be applied to all smart contracts. In this embodiment, after determining the target smart contract to be tested, the electronic device further determines a modifier contract corresponding to the target smart contract, that is, a modifier contract suitable for running in the blockchain environment applicable to the target smart contract. For example, if the determined target smart contract is suitable for running in blockchain environment A, a modifier contract also suitable for running in blockchain environment A is determined accordingly. This modifier contract serves as the modifier contract corresponding to the target smart contract and is used for subsequent testing of the target smart contract and for recording the contract execution information of the target smart contract during the testing process.

[0221] For example, a decorator contract can be defined as follows:

[0222] contract TestLogger{

[0223] / / Define the relative path to the log file

[0224] string constant LOG_FILE="log.txt"

[0225] / / Define the recording function

[0226] function logstep(string memory description, string memory input, stringmemory output)internal{

[0227] / / Detailed implementation logic omitted here.

[0228] writeLogToFile(logEntry);

[0229] }

[0230] / / Define cross-contract call functions

[0231] function callotherContract(address targetContract, bytes memoryinputData, string memory description)internal returns(bytes memory){

[0232] / / Detailed implementation logic omitted here.

[0233] / / Call the logging function to record contract execution information

[0234] logStep("Call completed","","");

[0235] }

[0236] function return(unit start, unit end)public{

[0237] / / Specific implementation logic omitted here}

[0238] }

[0239] The modifier contract is named "TestLogger", the logging function is named "logstep", the cross-contract call function is named "callotherContract", and the replay function is named "return".

[0240] `address targetContract` is an address-type parameter representing the other contract to be invoked. Each smart contract has its own contract address. Typically, a smart contract's contract address is obtained by hashing the smart contract's name using a hash algorithm. That is, a hash algorithm is used to hash the smart contract's name, and the result is used as the smart contract's contract address.

[0241] `bytes memory inputData` is a byte-type parameter used to store the call data to be sent to other contracts that need to be invoked, i.e., the input parameter.

[0242] The string memory description is a string parameter used to store additional information or descriptions about this cross-contract call, i.e., call description information.

[0243] `internal` is a visibility modifier that indicates that the cross-contract function call can only be called within the current contract (i.e., its modifier contract) or a contract that inherits from the current contract, and cannot be called by other external contracts.

[0244] `returns(bytes memory)` indicates that the cross-contract function call returns a byte value containing the data returned from the other contract being called. If the other contract does not return a value, or if the call fails, the returned data will be empty or invalid.

[0245] The logging function "logstep" accepts the following three parameters:

[0246] The string memory description represents the call description information of the target function during a single call process; it is presented as a string here.

[0247] The string memory input represents the input parameters of the target function during a single call; it is presented as a string here.

[0248] The string memory output represents the output of the target function during a single call; it is presented as a string.

[0249] `uint start` is an unsigned integer parameter used to specify the starting log entry for test replay.

[0250] `uint end` is an unsigned integer parameter used to specify the end log entry for the test replay.

[0251] In Section 203, electronic devices deploy modifier contracts and target smart contracts to a blockchain environment.

[0252] In this embodiment of the application, the electronic device also deploys the target smart contract and the modifier contract to the corresponding blockchain environment so that the target smart contract can be tested using the target test cases in the blockchain environment.

[0253] The blockchain environment can be built using testing frameworks. For example, assuming the target smart contract is suitable for running in the Ethereum blockchain environment, the Ethereum blockchain environment can be built using testing frameworks such as Truffle, Hardhat, and Embark. Then, the target smart contract and the modifier contract can be deployed to the built Ethereum blockchain environment so that the target smart contract can be tested using the target test cases in the Ethereum blockchain environment.

[0254] It should be noted that, in order to enable the modifier contract to record the contract execution information during the testing process of the target smart contract, the target smart contract is not run directly. Instead, the target smart contract is tested by using the target test cases through the modifier contract and cross-contract calls.

[0255] In 204, the electronic device determines the target function to be called in the target smart contract and the input parameters for the target function based on the target test cases.

[0256] It should be noted that the determined target test case can consist of multiple single test cases corresponding to different test behaviors. When the target smart contract is executed by cross-contract invocation based on the target test case through the decorator contract, for each single test case in the target test case, the electronic device determines the function in the target smart contract corresponding to the test behavior, denoted as the target function, and determines the input parameters used to invoke the target function; then, based on the determined input parameters, the target function is invoked and executed through cross-contract function invocation. In this way, the test behaviors corresponding to all single test cases in the target test case can be completed, thereby realizing the testing of the target smart contract.

[0257] In 205, the electronic device executes the target function in the target smart contract by calling the target function through cross-contract function calls, based on the input parameters.

[0258] For example, the following defines a target smart contract to be tested, which includes a sample function:

[0259] contract MyContract{

[0260] / / Example function

[0261] function myFunction(unit input)public pure return(unit){

[0262] / / Specific function logic

[0263] uint result = input * 2;

[0264] return result;

[0265] }

[0266] }

[0267] The target smart contract is named "MyContract", and the example function is named "myFunction".

[0268] `uint input` is an unsigned integer parameter used to store input parameters.

[0269] `public` is a visibility modifier that indicates that the example function can be called in the current contract (i.e., the target smart contract to which it belongs) or in contracts that inherit from the current contract, or it can be called by other external contracts.

[0270] "pure" is a modifier that indicates that the example function will not read or modify the state of the blockchain; it will only perform calculations and return the results.

[0271] The function returns(uint) indicates that this example function returns an unsigned integer value, which is the output result.

[0272] The function body is `uint result = input * 2`. This line of code multiplies the input parameter by 2 and stores the result in a variable named `result`.

[0273] The function of the line `return result` is to return the value of the variable `result`, and also to return the result of the multiplication operation above.

[0274] The following uses the CMC tool from Chang'an Chain as an example to illustrate the calling of example functions in the target smart contract above:

[0275] . / cmc client contract user invoke\

[0276] --contract-name=TestLogger\

[0277] --method=callotherContract\

[0278] --params="{\"contract_name\":\"MyContract\",\"contract_method\":\"myFuncti on\"

[0279] ,\"params_inner\":\"8\"}"\

[0280] --sdk-conf-path=. / testdata / sdk_config_pk.yml\

[0281] --sync-result=true

[0282] The command ". / cmc client contract user invoke\" is the basic part, indicating that the operation to be performed is "invoke", which means calling a function in the smart contract.

[0283] The "-contract-name=TestLogger" option specifies the name of the smart contract to be invoked, which is "TestLogger" in this case, the decorator contract.

[0284] The `--method=callotherContract:` option specifies the name of the function in the contract to be called. Here it is `callotherContract`, which means calling a function across contracts within the decorator contract.

[0285] The `--params="{"contract_name":"MyContract","contract_method":"myFunction","params_inner":"8"}"` parameter specifies the arguments to be passed to the cross-contract call function "callotherContract". Here, it is a JSON string containing three fields:

[0286] "contract_name":"MyContract": Specifies the name of the other contract to be invoked across contracts, here it is MyContract, which is the target smart contract in the example above.

[0287] "contract_method":"myFunction": Specifies the name of the target function to be called in the target smart contract above, which is myFunction, the example function above.

[0288] "params_inner":"8": The input parameter to be passed to the myFunction function, which is 8 in this case.

[0289] The `--sdk-conf-path=. / testdata / sdk_config_pk.yml:` option specifies the relative path to the SDK configuration file, which typically contains the configuration information required to connect to the blockchain, such as API keys, node addresses, etc.

[0290] The "--sync-result=true" option specifies that the call should be waited for a result to return synchronously.

[0291] As shown above, by calling the cross-contract call function "callotherContract" in the modifier contract, the cross-contract call to the target function "myFunction" in the target smart contract "MyContract" is realized. According to the above description, if the target function "myFunction" executes normally, it will return the output result "16" corresponding to the input parameter "8".

[0292] In section 206, the electronic device obtains the output of the target function and the corresponding call description information of the target function.

[0293] In 207, the electronic device uses a recording function to format the call description information, output results, and input parameters as contract execution information into log entries, and records the log entries to a log file.

[0294] After the electronic device completes a call to the target function in the target smart contract according to the target test case through the cross-contract call parameters in the modifier contract, it obtains the output result of the target function in this call and the call description information of the target function in this call. Then, through the recording function, it formats the call description information, output result and input parameters of this call into log entries and records them to the log file.

[0295] For example, the following two log entries are logged to the log file "log.txt" using the logging function:

[0296] 2024-01-01 12:20 131,contract name:MyContract,func:myFunction params:8result:16,Description:……;

[0297] 2024-01-01 12:20 437,contract name:MyContract,func:myFunction params:3result:6,Description:……;

[0298] The first log entry describes a call to the target function "myFunction" in the target smart contract "MyContract", which is a test behavior. The call time is "2024-01-01 12:20131", the input parameter is "8", the output result is "16", and the call description information is "...", which is omitted here.

[0299] The second log entry describes a call to the target function "myFunction" in the target smart contract "MyContract", which is also a test behavior. The call time is "2024-01-01 12:20437", the input parameter is "3", the output result is "6", and the call description information is "...", which is omitted here.

[0300] In 208, the electronic device generates replay test cases based on the log file.

[0301] For a log entry in the log file, the electronic device generates a single test case corresponding to the log entry based on the contract execution information (such as input parameters) and test case template recorded in the log entry. In this way, single test cases corresponding to all log entries can be generated, and these single test cases can be combined to form replay test cases for the target smart contract.

[0302] In 209, the electronic device, based on the replay test cases, controls the cross-contract call function to execute the target function of the target smart contract in the test through the replay function, so as to perform test replay on the target smart contract.

[0303] When there is a need for test replay, the replay function can be used to control the cross-contract call function to call the target smart contract's target function during the test process, thereby performing test replay on the target smart contract.

[0304] For example, there is a single test case in the replay test cases as follows:

[0305] The test case is named “contract name:MyContract,func:myFunction params:3”, where the target function “myFunction” in the target smart contract “MyContract” is selected, and the input parameter is “3”.

[0306] According to the single test case above, the replay function will control the cross-contract call function "callotherContract" to call the target smart contract "MyContract" and execute the target function "myFunction" during the test process. The input parameter is "3". The specific implementation of the cross-contract call is not described in detail here. Please refer to the relevant description in the above embodiments for details.

[0307] There are no restrictions on how the test replay requirement is triggered. For example, it could be triggered when the target smart contract encounters an exception during the test. The replay function can then be used to replay the test process of the target smart contract in order to reproduce the exception and eliminate it.

[0308] To facilitate better implementation of the above smart contract testing methods, this application also provides a corresponding smart contract testing device. The meanings of the terms used are the same as in the above smart contract testing methods; for specific implementation details, please refer to the descriptions in the above method embodiments.

[0309] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of a smart contract testing device provided in an embodiment of this application. The smart contract testing device may include a test determination module 310, a contract acquisition module 320, a contract invocation module 330, and an information recording module 340.

[0310] The test determination module 310 is used to determine the target smart contract to be tested, and to determine the target test cases for testing the target smart contract;

[0311] Contract acquisition module 320 is used to acquire the modifier contract corresponding to the target smart contract;

[0312] Contract invocation module 330 is used to invoke the execution of the target smart contract across contracts through the decorator contract, based on the target test cases, in order to test the target smart contract;

[0313] The information recording module 340 is used to record the contract execution information of the target smart contract during the testing process through the modifier contract.

[0314] Optionally, in one embodiment, the modifier contract includes a cross-contract call function. The contract call module 330 is used to determine the target function to be called in the target smart contract based on the target test case, and to determine the input parameters for the target function; and to call the target function in the target smart contract for execution through the cross-contract call function based on the input parameters.

[0315] Optionally, in one embodiment, the modifier contract further includes a recording function. The information recording module 340 is used to obtain the output result of the target function and the call description information corresponding to the target function; and to record the call description information, output result and input parameters as contract execution information through the recording function.

[0316] Optionally, in one embodiment, the information recording module 340 is used to format the call description information, output results, and input parameters as contract execution information into log entries through a recording function, and record the log entries to a log file.

[0317] Optionally, in one embodiment, the modifier contract further includes a replay function. The smart contract testing device provided in this application further includes a test replay module, which is used to control the cross-contract call function to call the target smart contract's target function in the test through the replay function according to the log entries recorded in the log file, so as to perform test replay on the target smart contract.

[0318] Optionally, in one embodiment, the test replay module is used to determine the start log entry and the end log entry in the log file; and based on all log entries from the start log entry to the end log entry recorded in the log file, to control the execution of the target function of the cross-contract call function in the test process through the replay function.

[0319] Optionally, in one embodiment, the smart contract testing device provided in this application further includes a quality assessment module, used to obtain contract execution difference information of the target smart contract during the testing process and test replay process; and to obtain the execution stability of the target smart contract based on the contract execution difference information.

[0320] As described above, the smart contract testing device provided in this application first determines the target smart contract to be tested and the target test cases for testing the target smart contract through the test determination module 310. Then, the contract acquisition module 320 acquires the modifier contract corresponding to the target smart contract. Next, the contract invocation module 330 uses the modifier contract to perform cross-contract invocation of the target smart contract to test it. Finally, the information recording module 340 records the contract execution information of the target smart contract during the testing process through the modifier contract. This achieves automated recording of smart contract execution information and eliminates manual intervention in the entire recording process, thereby improving the efficiency of contract execution information recording.

[0321] For details on the implementation of each of the above modules, please refer to the previous examples, which will not be repeated here.

[0322] This application also provides an electronic device, including a memory and a processor, wherein the processor executes the steps in the smart contract testing method provided in the above embodiments by calling a computer program stored in the memory.

[0323] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0324] The electronic device may include components such as a processor 101 with one or more processing cores, a memory 102 with one or more computer-readable storage media, a power supply 103, and an input unit 104. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0325] The processor 101 is the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes software programs and / or modules stored in the memory 102, and calls data stored in the memory 102, to perform various functions and process data. Optionally, the processor 101 may include one or more processing cores; alternatively, the processor 101 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 101.

[0326] The memory 102 can be used to store software programs and modules. The processor 101 executes various functional applications and data processing by running the software programs and modules stored in the memory 102. The memory 102 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs 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 electronic device, etc. In addition, the memory 102 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. Accordingly, the memory 102 may also include a memory controller to provide the processor 101 with access to the memory 102.

[0327] The electronic device also includes a power supply 103 that supplies power to the various components. Optionally, the power supply 103 can be logically connected to the processor 101 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 103 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0328] The electronic device may also include an input unit 104, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0329] Although not shown, the electronic device may also include a display unit, an image acquisition component, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 101 loads one or more executable codes corresponding to computer programs into the memory 102, and the processor 101 executes the steps in the smart contract testing method provided in this application, such as:

[0330] Identify the target smart contract to be tested, and identify the target test cases for testing the target smart contract;

[0331] Obtain the modifier contract corresponding to the target smart contract;

[0332] The target smart contract is tested by calling cross-contract execution through the decorator contract according to the target test cases.

[0333] The modifier contract records the contract execution information of the target smart contract during the testing process.

[0334] It should be noted that the electronic device provided in this application embodiment and the smart contract testing method in the above embodiment belong to the same concept. The specific implementation process can be found in the above related embodiments, and will not be repeated here.

[0335] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program stored thereon is executed on the processor of the electronic device provided in the embodiments of this application, the processor of the electronic device implements the steps in the smart contract testing method provided in this application. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0336] This application also provides a computer program product, which includes a computer program that, when executed on a processor, causes the processor to implement the steps in the smart contract testing method provided in this application.

[0337] The above provides a detailed description of the smart contract testing method, smart contract testing device, electronic device, computer-readable storage medium, and computer program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0338] It should be noted that when the above embodiments of this application are applied to specific products or technologies, and user-related data is involved, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A smart contract testing method, characterized in that, include: Identify the target smart contract to be tested, and determine the target test cases for testing the target smart contract; Obtain the modifier contract corresponding to the target smart contract; The target smart contract is executed by cross-contract calls through the modifier contract according to the target test case, in order to test the target smart contract; The modifier contract records the contract execution information of the target smart contract during the testing process.

2. The smart contract testing method according to claim 1, characterized in that, The modifier contract includes cross-contract call functions. The step of using the modifier contract to call the target smart contract across contracts according to the target test case includes: Based on the target test cases, determine the target function to be called in the target smart contract, and determine the input parameters for the target function; Based on the input parameters, the target function in the target smart contract is executed by calling the cross-contract call function.

3. The smart contract testing method according to claim 2, characterized in that, The modifier contract also includes a recording function, which records the contract execution information of the target smart contract during the testing process through the modifier contract, including: Obtain the output of the target function and the call description information corresponding to the target function; The recording function records the call description information, the output result, and the input parameters as the contract execution information.

4. The smart contract testing method according to claim 3, characterized in that, The process of recording the description information, the output result, and the input parameters as contract execution information through the recording function includes... The recording function formats the call description information, the output result, and the input parameters as contract execution information into log entries, and records the log entries to a log file.

5. The smart contract testing method according to claim 4, characterized in that, The modifier contract also includes a replay function. After formatting the call description information, the output result, and the input parameters as contract execution information into log entries using the recording function, and recording the log entries to a log file, the contract further includes: Based on the log entries recorded in the log file, the replay function controls the cross-contract call function to call the target function of the target smart contract in the test, so as to perform test replay of the target smart contract.

6. The smart contract testing method according to claim 5, characterized in that, The step of controlling the cross-contract call function to invoke the target function of the target smart contract in the test through the replay function based on the log entries recorded in the log file includes: Determine the start and end log entries in the log file; Based on all log entries from the start log entry to the end log entry recorded in the log file, the replay function controls the cross-contract call function to call the target function of the target smart contract during the test process.

7. The smart contract testing method according to claim 5, characterized in that, After controlling the cross-contract call function to execute the target function of the target smart contract in the test through the replay function based on the log entries recorded in the log file, the method further includes: Obtain information on the differences in contract execution between the target smart contract during the testing process and the test replay process; The execution stability of the target smart contract is obtained based on the contract execution difference information.

8. A smart contract testing device, characterized in that, include: The test determination module is used to determine the target smart contract to be tested, and to determine the target test cases for testing the target smart contract; The contract acquisition module is used to acquire the modifier contract corresponding to the target smart contract; The contract invocation module is used to invoke the target smart contract across contracts through the decorator contract according to the target test case to test the target smart contract; The information recording module is used to record the contract execution information of the target smart contract during the testing process through the modifier contract.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, implements the steps of the smart contract testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for execution by a processor to implement the steps of the smart contract testing method according to any one of claims 1 to 7.

Images