WO2020062673A1 - 智能合约的测试方法、存储介质、测试终端及测试装置 - Google Patents

智能合约的测试方法、存储介质、测试终端及测试装置 Download PDF

Info

Publication number
WO2020062673A1
WO2020062673A1 PCT/CN2018/123985 CN2018123985W WO2020062673A1 WO 2020062673 A1 WO2020062673 A1 WO 2020062673A1 CN 2018123985 W CN2018123985 W CN 2018123985W WO 2020062673 A1 WO2020062673 A1 WO 2020062673A1
Authority
WO
WIPO (PCT)
Prior art keywords
smart contract
environment
test environment
data
run
Prior art date
Application number
PCT/CN2018/123985
Other languages
English (en)
French (fr)
Inventor
谢丹力
陈飞
宦鹏飞
Original Assignee
深圳壹账通智能科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳壹账通智能科技有限公司 filed Critical 深圳壹账通智能科技有限公司
Publication of WO2020062673A1 publication Critical patent/WO2020062673A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites

Definitions

  • the present application belongs to the technical field of blockchain, and particularly relates to a test method for a smart contract, a computer non-volatile readable storage medium, a test terminal, and a test device.
  • Smart Contract is a computer agreement designed to spread, verify or execute contracts in an informational manner. It allows trusted transactions to be conducted without a third party. These transactions are traceable and irreversible.
  • smart contracts need to run in an isolated sandbox, such as the Hyperledger (Hyper ledger) smart contracts need to run in Docker containers.
  • testing the published smart contracts is an essential link.
  • the process of testing smart contracts is generally as follows: first deploy the blockchain network and smart contracts, and run the smart contracts in the Docker environment; analyze the problems and modify the code by viewing the logs of the smart contracts.
  • the log of the smart contract may be lost, and because the intermediate data during the operation is generally presented in the form of random numbers using encryption, it is impossible to judge the correctness of the intermediate data by viewing the log;
  • the blockchain network and the smart contract need to be re-deployed to verify whether the problem is resolved. It can be seen that the testing process of smart contracts in the prior art is cumbersome and inefficient.
  • the present application provides a smart contract test method, a computer non-volatile readable storage medium, a test terminal, and a test device, in order to solve the problems of complicated and inefficient steps in the test process of the smart contract in the prior art. .
  • the first aspect of the embodiments of the present application provides a method for testing a smart contract, which may include:
  • the offline test environment is an operating environment obtained by simulating a blockchain environment in which the smart contract actually runs;
  • a second aspect of the embodiments of the present application provides a computer non-volatile readable storage medium, where the computer non-readable storage medium stores computer readable instructions, and the computer readable instructions are executed by a processor Steps of implementing the smart contract test method as described in the first aspect of the present application and any possible implementation manner of the first aspect.
  • a third aspect of the embodiments of the present application provides a test terminal, including a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, where the processor executes the computer When the instructions are readable, the steps of the method for testing a smart contract in the first aspect of the present application and any possible implementation manner of the first aspect are implemented.
  • a fourth aspect of the embodiments of the present application provides a test apparatus including a unit for implementing the steps of the smart contract test method in the first aspect of the present application and any possible implementation manner of the first aspect.
  • This application solves the tedious and inefficient testing process of the smart contract in the prior art by loading the smart contract to be tested into an offline test environment and compiling, executing, running, and debugging the smart contract in the offline test environment.
  • the problem That is, on the one hand, because the offline test environment is an operating environment obtained by simulating the blockchain environment in which the smart contract actually runs, the smart contract can run with the real blockchain environment when it runs in the offline test environment. Show consistent behavior logic at all times, so it can guarantee the validity of smart contract testing.
  • the smart contract can be run away from the real blockchain environment, avoiding the need to redeploy the smart contract every time the smart contract is tested in the existing technology.
  • the tedious steps of the blockchain network and the release of smart contracts simplify the testing process of smart contracts and help improve the development efficiency of smart contracts.
  • FIG. 1 is a flowchart of a smart contract test method according to an embodiment of the present application
  • FIG. 2 is a flowchart of another method for testing a smart contract according to an embodiment of the present application
  • step S201 in the embodiment shown in FIG. 2;
  • FIG. 4 is a structural diagram of an embodiment of a test device for a smart contract according to an embodiment of the present application.
  • FIG. 5 is a schematic block diagram of a test terminal according to an embodiment of the present application.
  • an embodiment of a smart contract test method in an embodiment of the present application may include:
  • step S101 the smart contract to be tested is loaded into an offline test environment.
  • the offline test environment is an operating environment obtained by simulating a blockchain environment in which a smart contract actually runs.
  • the actual blockchain environment in which a smart contract actually runs refers to the real blockchain environment that actually runs after the smart contract is issued, and is also referred to as a real blockchain environment in the following.
  • the blockchain in the embodiments of the present application is a Hyperledger (Hyper ledger) as an example.
  • the offline test environment can provide external dependent data consistent with the real blockchain environment, consistent underlying interfaces, and consistent trigger data, so that when the smart contract runs in this offline test environment, it can communicate with the real world.
  • the smart contract runs in this offline test environment, it can communicate with the real world.
  • it exhibits consistent behavioral logic.
  • step S102 the smart contract is compiled to obtain an executable file.
  • an executable file can be generated by compiling the source code of the smart contract in an offline test environment.
  • the source code of the smart contract is stored in a class library unit (package, also known as a package) in an offline test environment, and an executable is obtained by compiling the source code of the smart contract in the corresponding class library unit. file.
  • the executable file After the executable file is executed, it can generate a service (Server) for triggering the smart contract to run.
  • a service Server
  • multiple smart contracts can be loaded into an offline test environment and stored in different class library units, respectively, and then services can be generated by jointly compiling.
  • the application then provides different trigger data to trigger the service call and run the smart contract corresponding to the corresponding trigger data.
  • the source code of the smart contract and the offline test environment can be written and implemented in Golang language.
  • step S103 the executable file is executed to generate a service of the smart contract.
  • the executable file compiled in the above step S102 may be executed to obtain a service (Server) for triggering the smart contract to run.
  • the service runs in the background of the offline test environment, waiting to be triggered and called.
  • the triggering and calling of the smart contract may be completed by an application program, and the offline test environment provides an access interface consistent with the real blockchain environment.
  • the access interface may be a Restful interface.
  • the application can access the offline test environment like a real blockchain network, so that the service can be called and trigger data can be provided to trigger the smart contract to run in the offline test environment.
  • step S104 the service is called and trigger data is provided to trigger the smart contract to run in the offline test environment.
  • a corresponding smart contract can be triggered to run in the offline test environment.
  • the provided trigger data needs to be consistent with the trigger data when the smart contract runs in the real blockchain environment.
  • the corresponding service can be called through the application program and the trigger data is provided.
  • the application program may be a transaction program.
  • the transaction program provides trigger data to trigger the smart contract to run to execute the transaction indicated by the transaction program.
  • step S105 test the smart contract running in the offline test environment.
  • the smart contract is run in an offline test environment.
  • the running status of the smart contract can be checked at any time, and the smart contract code can also be conveniently debugged directly using the GDB debugging tool.
  • step S105 may include:
  • Interrupt the running of the smart contract at a specified breakpoint and output the current running state information of the smart contract.
  • a smart contract running in an offline test environment may specify a breakpoint at any time, and interrupt the smart contract operation at the breakpoint. For example, when a tester needs to view a smart contract at a certain point in time when it is running In the state, you can interrupt the running of the smart contract by setting a breakpoint. At the same time, the offline test environment can output the running state of the smart contract when it is interrupted for developers to use.
  • the offline testing environment provided is an operating environment that is decoupled from the real blockchain environment, and can support the operation of smart contracts and does not affect the real blockchain network. Therefore, it can support the interruption of smart contract operation It can also support the debugging of smart contract code at any time, which greatly facilitates the development and testing of smart contracts by developers.
  • this application solves the testing process of smart contracts in the prior art by loading the smart contracts to be tested into an offline test environment and compiling, executing, running, and debugging the smart contracts in the offline test environment.
  • the problem of tedious steps and low efficiency That is, on the one hand, because the offline test environment is an operating environment obtained by simulating the blockchain environment in which the smart contract actually runs, the smart contract can run with the real blockchain environment when it runs in the offline test environment. Show consistent behavior logic at all times, so it can guarantee the validity of smart contract testing.
  • the smart contract can be run away from the real blockchain environment, avoiding the need to redeploy the smart contract every time the smart contract is tested in the existing technology.
  • the tedious steps of the blockchain network and the release of smart contracts simplify the testing process of smart contracts and help improve the development efficiency of smart contracts.
  • another embodiment of a smart contract test method in the embodiment of the present application may include:
  • Step S201 Set up an offline test environment.
  • an offline test environment needs to be established first.
  • the basic framework for determining the real blockchain environment to support smart contract operations is determined, thereby simulating the functions of these basic frameworks, and building offline test environments that can support smart contract operations.
  • the basic framework that supports the operation of smart contracts can include:
  • the API includes basic interfaces such as Invoke (data writing), Query (data query), and Range Query (range query).
  • the blocks in the blockchain network are connected in the form of a linked list, which contains all the historical data and occurrences of the blockchain network. event.
  • the global ledger state in the blockchain network which is used to store the latest values of all key / value key-value pairs in the current blockchain network.
  • setting up an offline test environment may include the following steps (see FIG. 3):
  • Step S2011 Configure an application programming interface required for the smart contract to run, wherein the application programming interface includes a data writing interface, a data query interface, and a range query interface.
  • simulation can be performed and an offline test environment can be established.
  • Golang programs can be used to write code to implement the offline test environment.
  • Configure the application programming interface required for smart contract operation such as data write interface, data query interface and range query interface.
  • Step S2012 Configure a global ledger state required for the smart contract to run.
  • the global ledger state in the offline test environment can be configured according to the current global ledger state in the real blockchain network.
  • the Redis key-value pair database can be configured to implement storage of the obtained global ledger state data.
  • storage of the obtained global ledger state data may also be implemented by means of a Map data structure in a memory.
  • Step S2013 Configure block data required for the smart contract to run.
  • the block data in the offline test environment may be configured according to the block data in the real blockchain network.
  • the target block involved in the operation of the smart contract in the real blockchain network environment is determined; second, the simulated block corresponding to the determined target block is generated, where the data of the simulated block can be a key value Pairs are stored in an offline test environment.
  • each block is connected in series in the form of a chain and stored in the file system of the blockchain in the form of a log file.
  • This storage method is similar to the above-mentioned global ledger.
  • the state data is stored in a consistent manner, which can reduce the workload of developers.
  • only the block data associated with the smart contract to be tested is saved, without acquiring all the block data in the real blockchain network environment, which also greatly reduces the workload of developers.
  • the smart contract when the smart contract is run in an offline test environment, if the data of the simulation block in the offline test environment is called, the called data can be converted into a target format for the smart contract to call,
  • the target format is the data format of the block in the real blockchain network environment.
  • the data of the simulation block in the offline test environment is saved in the form of key-value pairs, when the data of the corresponding simulation block is called by the smart contract, it needs to be converted into a real block
  • the block data format in the chain environment to provide a unified return interface to the upper-level smart contracts.
  • the method of stubbing the API can be used to convert the data format when the corresponding block data is called. This also achieves the isolation of the smart contract from the underlying data structure in the offline test environment.
  • Step S202 Load the smart contract to be tested into an offline test environment.
  • Step S203 Compile the smart contract to obtain an executable file.
  • Step S204 Execute the executable file to generate a service of the smart contract.
  • Step S205 Call the service and provide trigger data to trigger the smart contract to run in the offline test environment.
  • Step S206 Test the smart contract running in the offline test environment.
  • steps S202 to S206 reference may be made to steps S101 to S105 in the embodiment shown in FIG. 1, and details are not described herein again.
  • the method may further include:
  • smart contracts may have a variety of different business logics, different business logics correspond to different test instances, and different test instances correspond to different global ledger states. Therefore, in the embodiment of the present application, the global ledger state in the offline test environment needs to be initialized according to the relevant logical branch of the smart contract and the specific test instance corresponding to the relevant logical branch.
  • business logic refers to the rules and processes of the smart contracts that need to be tested.
  • this application solves the testing process of smart contracts in the prior art by loading the smart contracts to be tested into an offline test environment and compiling, executing, running, and debugging the smart contracts in the offline test environment.
  • the problem of tedious steps and low efficiency That is, on the one hand, because the offline test environment is an operating environment obtained by simulating the blockchain environment in which the smart contract actually runs, the smart contract can run with the real blockchain environment when it runs in the offline test environment. Show consistent behavior logic at all times, so it can guarantee the validity of smart contract testing.
  • the smart contract can be run away from the real blockchain environment, avoiding the need to redeploy the smart contract every time the smart contract is tested in the existing technology.
  • the tedious steps of the blockchain network and the release of smart contracts simplify the testing process of smart contracts and help improve the development efficiency of smart contracts.
  • FIG. 4 shows a structural diagram of an embodiment of a smart contract test device provided by an embodiment of the present application.
  • the test device 4 for a smart contract may include a loading unit 41, a compiling unit 42, an execution unit 43, a triggering unit 44, and a testing unit 45.
  • a loading unit 41 is configured to load a smart contract to be tested into an offline test environment, where the offline test environment is an operating environment obtained by simulating a blockchain environment in which the smart contract actually runs;
  • the compiling unit 42 is configured to compile the smart contract loaded by the loading unit 41 to obtain an executable file.
  • the execution unit 43 is configured to execute an executable file obtained by the compiling unit 42 to generate a service of the smart contract.
  • the triggering unit 44 is configured to call a service generated by the execution unit 43 and provide triggering data to trigger the smart contract to run in the offline test environment.
  • the testing unit 45 is configured to test the smart contract after the triggering unit 44 triggers the smart contract to run in the offline test environment.
  • test device 4 for a smart contract may further include:
  • Environment building unit which is used to build an offline test environment
  • the environment building unit includes:
  • a first configuration subunit configured to configure an application programming interface required for the operation of the smart contract, wherein the application programming interface includes a data writing interface, a data query interface, and a range query interface;
  • a second configuration subunit configured to configure a global ledger state required for the smart contract to run
  • the third configuration subunit is configured to configure block data required for the smart contract to run.
  • test device 4 for a smart contract may further include:
  • a first obtaining unit configured to obtain global ledger status data in the blockchain environment
  • the second configuration subunit is further configured to create a local key-value pair database, and store the global ledger status data obtained by the first obtaining unit in the local key-value pair database.
  • the third configuration subunit includes:
  • a block determination unit configured to determine a target block involved in the smart contract when the blockchain environment is running
  • the simulation module generating unit is configured to generate a simulation block corresponding to the target block determined by the block determination unit, wherein the data of the simulation block is stored in the offline test environment in the form of key-value pairs.
  • test device 3 of the smart contract may further include:
  • a second obtaining unit configured to obtain the business logic of the smart contract before compiling the smart contract to obtain an executable file
  • the initialization unit is configured to initialize the global ledger state based on a test instance corresponding to the business logic obtained by the second obtaining unit.
  • test device 4 for a smart contract may further include:
  • a format conversion unit configured to, when the triggering unit 44 triggers the smart contract to run in the offline test environment, if the data in the simulation block configured in the offline test environment is called, the called data is converted into a target Format for the smart contract to call, wherein the target format is the data format of a block in the blockchain environment.
  • testing unit 45 is further configured to interrupt the running of the smart contract at a specified breakpoint, and output the current running state information of the smart contract.
  • this application solves the testing process of smart contracts in the prior art by loading the smart contracts to be tested into an offline test environment and compiling, executing, running, and debugging the smart contracts in the offline test environment.
  • the problem of tedious steps and low efficiency That is, on the one hand, because the offline test environment is an operating environment obtained by simulating the blockchain environment in which the smart contract actually runs, the smart contract can run with the real blockchain environment when it runs in the offline test environment Show consistent behavior logic at all times, so it can guarantee the validity of smart contract testing.
  • FIG. 5 shows a schematic block diagram of a test terminal provided in an embodiment of the present application. For ease of description, only a part related to the embodiment of the present application is shown.
  • the test terminal 5 may be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server.
  • the test terminal 5 may include a processor 50, a memory 51, and computer-readable instructions 52 stored in the memory 51 and executable on the processor 50.
  • a computer may execute the above-mentioned test method for a smart contract. Read instruction.
  • the processor 50 executes the computer-readable instructions 52, the steps in the test method embodiment of the foregoing smart contracts are implemented, for example, steps S101 to S105 shown in FIG.
  • the processor 50 executes the computer-readable instructions 52
  • the functions of the units in the foregoing device embodiments are implemented, for example, the functions of the units 41 to 45 shown in FIG. 4.
  • the computer-readable instructions 52 may be divided into one or more modules / units, the one or more modules / units are stored in the memory 51 and executed by the processor 50, To complete this application.
  • the one or more modules / units may be a series of computer-readable instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer-readable instructions 52 in the test terminal 5.
  • the processor 50 may be a central processing unit (Central Processing Unit (CPU), can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • CPU Central Processing Unit
  • DSP digital signal processors
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
  • the memory 51 may be an internal storage unit of the test terminal 5, such as a hard disk or a memory of the test terminal 5.
  • the memory 51 may also be an external storage device of the test terminal 5, such as a plug-in hard disk, a smart media card (SMC), and a secure digital (SD) provided on the test terminal 5. 1. flash card Card) and so on.
  • the memory 51 may include both an internal storage unit of the test terminal 5 and an external storage device.
  • the memory 51 is configured to store the computer-readable instructions and other instructions and data required by the test terminal 5.
  • the memory 51 may also be used to temporarily store data that has been output or is to be output.
  • Each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist separately physically, or two or more units may be integrated into one unit.
  • the above integrated unit may be implemented in the form of hardware or in the form of software functional unit.
  • the integrated unit When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a computer non-volatile readable storage medium.
  • the technical solution of the present application is essentially a part that contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium.
  • Including computer-readable instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present application.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), and a random access memory (RAM, Random Access) Memory), magnetic disks, or optical discs, which can store computer-readable instructions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请属于区块链技术领域，尤其涉及一种智能合约的测试方法、计算机非易失性可读存储介质、测试终端及测试装置。所述测试方法包括：将待测试的智能合约加载至离线测试环境，其中，所述离线测试环境为对所述智能合约实际运行的区块链环境进行模拟而得到的运行环境；对所述智能合约进行编译，获得可执行文件；执行所述可执行文件，生成所述智能合约的服务；调用所述服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行；对在所述离线测试环境中运行的所述智能合约进行测试。本申请能够简化智能合约的测试过程，有利于提高智能合约的开发效率。

Description

智能合约的测试方法、存储介质、测试终端及测试装置
本申请要求于2018年9月26日提交中国专利局、申请号为201811122234.8、发明名称为“智能合约的测试方法、计算机可读存储介质及测试终端”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请属于区块链技术领域，尤其涉及一种智能合约的测试方法、计算机非易失性可读存储介质、测试终端及测试装置。
 背景技术
智能合约（Smart Contract）是一种旨在以信息化方式传播、验证或执行合同的计算机协议，其允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。目前，在区块链结构下，智能合约需要运行在隔离的沙箱中，例如，超级账本（Hyper ledger）的智能合约需要运行在Docker容器中。
由于业务场景的复杂多样性，智能合约需满足图灵完备性，因此其可能存在异常复杂的业务逻辑，为了确保智能合约的质量，对发布的智能合约进行测试是必不可少的环节。目前对智能合约进行测试的过程一般为：首先部署区块链网络和智能合约，并在Docker环境中运行智能合约，通过查看智能合约的日志来分析问题并进行代码修改。
然而，一方面，智能合约的日志可能存在丢失的情形，并且由于运行过程中的中间数据一般都采用了加密方式以随机数的形式呈现，因此无法通过查看日志的方式判断中间数据的正确性；另一方面，若检测到智能合约存在的问题，在进行相应的代码修改之后，还需要重新进行区块链网络和智能合约的部署以验证问题是否被解决。可见，现有技术中智能合约的测试过程步骤繁琐、效率低下。
 技术问题
有鉴于此，本申请提供了一种智能合约的测试方法、计算机非易失性可读存储介质、测试终端及测试装置，以解决现有技术中智能合约的测试过程步骤繁琐、效率低下的问题。
 技术解决方案
本申请实施例的第一方面提供了一种智能合约的测试方法，可以包括：
将待测试的智能合约加载至离线测试环境，其中，所述离线测试环境为对所述智能合约实际运行的区块链环境进行模拟而得到的运行环境；
对所述智能合约进行编译，获得可执行文件；
执行所述可执行文件，生成所述智能合约的服务；
调用所述服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行；
对在所述离线测试环境中运行的所述智能合约进行测试。
本申请实施例的第二方面提供了一种计算机非易失性可读存储介质，所述计算机非易失性可读存储介质存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如上述本申请的第一方面及第一方面任一种可能的实现方式中的智能合约的测试方法的步骤。
本申请实施例的第三方面提供了一种测试终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现如上述本申请的第一方面及第一方面任一种可能的实现方式中的智能合约的测试方法的步骤。
本申请实施例的第四方面提供了一种测试装置，包括用于实现上述本申请的第一方面及第一方面任一种可能的实现方式中的智能合约的测试方法的步骤的单元。
 有益效果
本申请通过将待测试的智能合约加载至离线测试环境，并在该离线测试环境中对智能合约进行编译、执行、运行以及调试，解决了现有技术中智能合约的测试过程步骤繁琐、效率低下的问题。也即，一方面，由于该离线测试环境为对智能合约实际运行的区块链环境进行模拟而得到的运行环境，智能合约在该离线测试环境中运行时可以与其在真实区块链环境中运行时表现出一致的行为逻辑，故能够保障智能合约测试的有效性。另一方面，通过在该离线测试环境中运行智能合约，可以使智能合约脱离真实区块链环境而运行，避免了现有技术中对智能合约进行测试时，每次运行智能合约均需要重新部署区块链网络和发布智能合约的繁琐步骤，从而简化了智能合约的测试过程，有利于提高智能合约的开发效率。
 附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
图1为本申请实施例中一种智能合约的测试方法的一个实施例流程图；
图2为本申请实施例中一种智能合约的测试方法的另一个实施例流程图；
图3为图2所示实施例中步骤S201的一个实施例流程图；
图4为本申请实施例中一种智能合约的测试装置的一个实施例结构图；
图5为本申请实施例中一种测试终端的示意框图。
 本发明的实施方式
为使得本申请的目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本申请一部分实施例，而非全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
请参阅图1，本申请实施例中一种智能合约的测试方法的一个实施例可以包括：
在步骤S101中、将待测试的智能合约加载至离线测试环境。
在本申请实施例中，离线测试环境为对智能合约实际运行的区块链环境进行模拟而得到的运行环境。
在本申请实施例中，智能合约实际运行的区块链环境是指智能合约发布之后实际运行的真实区块链环境，在下文中也称为真实区块链环境。另外，本申请实施例中的区块链是以超级账本（Hyper ledger）为例进行说明的。
在本申请实施例中，离线测试环境可以提供与真实区块链环境一致的外部依赖数据、一致的底层接口、以及一致的触发数据，使得智能合约在该离线测试环境中运行时能够与其在真实区块链环境中运行时表现出一致的行为逻辑。
在步骤S102中、对所述智能合约进行编译，获得可执行文件。
在本申请实施例中，通过在离线测试环境中对智能合约的源代码进行编译，可以生成可执行文件。具体的，智能合约的源代码在离线测试环境中存放于类库单元（package，也可称为包）中，通过对相应的类库单元中的智能合约的源代码执行编译，得到一个可执行文件。该可执行文件在执行之后可生成用于触发智能合约运行的服务（Server）。
在一种实现方式中，可以将多个智能合约加载至离线测试环境中，并分别存放于不同的类库单元中，然后通过共同执行编译，生成服务。再通过应用程序提供不同的触发数据，来触发该服务调用和运行与相应的触发数据对应的智能合约。
在本申请实施例中，智能合约的源代码以及离线测试环境均可以通过Golang语言来进行编写实现。
在步骤S103中、执行所述可执行文件，生成所述智能合约的服务。
在本申请实施例中，执行上述步骤S102中编译得到的可执行文件，可以得到用于触发智能合约运行的服务（Server）。该服务运行于离线测试环境的后台，等待被触发和调用。
在本申请实施例中，智能合约的触发和调用可以由应用程序来完成，离线测试环境提供了与真实区块链环境一致的访问接口，例如，该访问接口可以为Restful接口。由此，使得应用程序可以如访问真实区块链网络一样访问该离线测试环境，从而可以调用该服务并提供触发数据以触发智能合约在该离线测试环境中运行。
在步骤S104中、调用所述服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行。
在本申请实施例中，通过调用离线测试环境中与智能合约关联的服务，并提供触发数据，可以触发对应的智能合约在该离线测试环境中运行。所提供的触发数据需要与智能合约在真实区块链环境中运行时的触发数据保持一致，在实际应用时，可以通过应用程序来调用相应的服务并提供触发数据。例如，该应用程序可以是一个交易程序，通过交易程序提供触发数据触发智能合约运行以执行交易程序所指示的交易。
智能合约被触发并运行之后，可以读取离线测试环境中的区块数据，以及向离线测试环境中的区块中写入新的数据（区块更新），智能合约被触发运行之后进行的行为与其在真实区块链环境中表现的行为一致。
在步骤S105中、对在所述离线测试环境中运行的所述智能合约进行测试。
在本申请实施例中，智能合约运行于离线测试环境，在该离线测试环境中，可以随时查看智能合约的运行状态，并且，还可以使用GDB调试工具方便的直接进行智能合约的代码的调试。
可选的，上述步骤S105可以包括：
在指定的断点中断所述智能合约的运行，并输出所述智能合约的当前运行状态信息。
本申请实施例中，在离线测试环境中运行的智能合约，可以随时指定断点，并在该断点中断智能合约的运行，例如，当测试人员需要查看某智能合约运行时某个时间点的状态时，可以通过设置断点中断智能合约的运行，同时，离线测试环境可以输出智能合约中断时的运行状态，以供开发人员使用。
需要说明的是，在真实区块链环境中，智能合约是依托于区块链网络的一个节点（peer）运行在复杂的Docker环境中，若在真实区块环境中直接进行测试的实现难度很大，需要专门的人员进行区块链网络的部署和智能合约的发布，该过程是非常复杂的。并且，由于区块链网络是一个分布式的网络，意味着同一份智能合约，会运行在多个peer上，如果在其中某个peer进行在线调试，有可能会打乱整个区块链网络的数据流。
本申请实施例中，所提供的离线测试环境是脱离了真实区块链环境的运行环境，既能够支持智能合约的运行，也不影响真实区块链网络，故可以支持随时中断智能合约的运行，也可以支持随时进行智能合约的代码的调试，从而大大方便了开发人员进行智能合约的开发和测试。
综上所述，本申请通过将待测试的智能合约加载至离线测试环境，并在该离线测试环境中对智能合约进行编译、执行、运行以及调试，解决了现有技术中智能合约的测试过程步骤繁琐、效率低下的问题。也即，一方面，由于该离线测试环境为对智能合约实际运行的区块链环境进行模拟而得到的运行环境，智能合约在该离线测试环境中运行时可以与其在真实区块链环境中运行时表现出一致的行为逻辑，故能够保障智能合约测试的有效性。另一方面，通过在该离线测试环境中运行智能合约，可以使智能合约脱离真实区块链环境而运行，避免了现有技术中对智能合约进行测试时，每次运行智能合约均需要重新部署区块链网络和发布智能合约的繁琐步骤，从而简化了智能合约的测试过程，有利于提高智能合约的开发效率。
请参阅图2，本申请实施例中一种智能合约的测试方法的另一个实施例可以包括：
步骤S201、搭建离线测试环境。
本申请实施例中，在进行智能合约的测试之前，首先需要搭建离线测试环境。通过分析和分解智能合约实际运行的区块链环境，确定真实区块链环境支持智能合约运行的基本框架，从而模拟这些基本框架的功能，搭建可以支持智能合约运行的离线测试环境。
具体的，支持智能合约运行的基本框架可以包括：
第一，底层区块链的应用程序编程接口API，所述API包括Invoke（数据写入）、Query（数据查询）、Range Query（范围查询）等基本接口。
第二，区块链网络中的区块（Block），在真实区块链网络中，Block块之间以链表的形式连接，包含了该区块链网络上发生的所有的历史数据和发生的事件。
第三，区块链网络中的全局账本状态（World State），所述全局账本状态用于存储当前区块链网络中的所有key/value键值对的最新值。
第四，智能合约被调用触发的时候，对应的触发数据。
可选的，上述步骤S201中，搭建离线测试环境可以包括以下步骤（请参阅图3）：
步骤S2011、配置所述智能合约运行所需的应用程序编程接口，其中，所述应用程序编程接口包括数据写入接口、数据查询接口和范围查询接口。
本申请实施例中，基于上文所述的真实区块链网络中支持智能合约运行的基本框架，可以进行模拟并搭建离线测试环境，具体的，可以采用Golang程序编写代码实现离线测试环境的搭建，配置智能合约运行所需的应用程序编程接口，例如数据写入接口、数据查询接口和范围查询接口。
步骤S2012、配置所述智能合约运行所需的全局账本状态。
本申请实施例中，可以根据真实区块链网络中当前的全局账本状态来配置离线测试环境中的全局账本状态。
进一步地，首先获取所述区块链环境中的全局账本状态数据；然后创建本地键值对数据库，并在所述本地键值对数据库中存储获取的所述全局账本状态数据。
在一个实现方式中，可以通过配置Redis键值对数据库，实现对获取的所述全局账本状态数据的存储。
在另一个实现方式中，还可通过内存中的Map数据结构的方式实现对获取的所述全局账本状态数据的存储。
步骤S2013、配置所述智能合约运行所需的区块数据。
本申请实施例中，可以根据真实区块链网络中的区块数据配置离线测试环境中的区块数据。
进一步地，首先确定智能合约在真实区块链网络环境运行时所涉及的目标区块；其次，生成与上述确定的目标区块对应的模拟区块，其中，模拟区块的数据可以以键值对的形式存储于离线测试环境中。
在真实区块链网络环境中，各区块是以链的形式串联连接在一起的，同时以log file的格式存储在区块链的文件系统中。在本申请实施例中，只需获取与待测试的智能合约关联的区块的数据，并在离线测试环境中将其简化为键值对的形式进行存储，这种存储方式与上述的全局账本状态数据的存储方式保持一致，从而能够减少开发人员的工作量。另外，在离线测试环境中仅保存当前要测试的智能合约关联的区块数据，而无需获取真实区块链网络环境中的全部区块数据，同样大大减少了开发人员的工作量。
作为一个可选的实施例，当智能合约在离线测试环境中运行时，若离线测试环境中的模拟区块的数据被调用，则可以将被调用的数据转换为目标格式以供智能合约调用，其中，目标格式为真实区块链网络环境中的区块的数据格式。
在本实施例中，由于离线测试环境中的模拟区块的数据是以键值对的形式进行保存的，在相应的模拟区块的数据被智能合约调用时，需要将其转化为真实区块链环境中的区块数据格式，以对上层的智能合约提供统一的返回接口。具体的，可以通过模拟API打桩的方式，在相应的区块数据被调用时进行数据格式的转换，这样也实现了在离线测试环境中智能合约与底层数据结构的隔离。
步骤S202、将待测试的智能合约加载至离线测试环境。
步骤S203、对所述智能合约进行编译，获得可执行文件。
步骤S204、执行所述可执行文件，生成所述智能合约的服务。
步骤S205、调用所述服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行。
步骤S206、对在所述离线测试环境中运行的所述智能合约进行测试。
本申请实施例中，上述步骤S202至S206具体可参考图1所示实施例中的步骤S101至S105，在此不再赘述。
作为一个可选的实施例，在上述步骤S203之前，还可以包括：
获取所述智能合约的业务逻辑；
基于与所述业务逻辑对应的测试实例，对所述全局账本状态进行初始化
由于智能合约可能具备多种不同的业务逻辑，而不同的业务逻辑又对应了不同的测试实例，不同的测试实例又对应了不同的全局账本状态。因此，在本申请实施例中，需要根据智能合约的相关逻辑分支以及和相关逻辑分支对应的具体测试实例，对离线测试环境中的全局账本状态进行初始化。在这里，业务逻辑是指当前需要测试的智能合约具备的规则和流程。
综上所述，本申请通过将待测试的智能合约加载至离线测试环境，并在该离线测试环境中对智能合约进行编译、执行、运行以及调试，解决了现有技术中智能合约的测试过程步骤繁琐、效率低下的问题。也即，一方面，由于该离线测试环境为对智能合约实际运行的区块链环境进行模拟而得到的运行环境，智能合约在该离线测试环境中运行时可以与其在真实区块链环境中运行时表现出一致的行为逻辑，故能够保障智能合约测试的有效性。另一方面，通过在该离线测试环境中运行智能合约，可以使智能合约脱离真实区块链环境而运行，避免了现有技术中对智能合约进行测试时，每次运行智能合约均需要重新部署区块链网络和发布智能合约的繁琐步骤，从而简化了智能合约的测试过程，有利于提高智能合约的开发效率。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
对应于上文实施例所述的智能合约的测试方法，图4示出了本申请实施例提供的一种智能合约的测试装置的一个实施例结构图。
本实施例中，智能合约的测试装置4可以包括：加载单元41、编译单元42，执行单元43，触发单元44和测试单元45。
加载单元41，用于将待测试的智能合约加载至离线测试环境，其中，所述离线测试环境为对所述智能合约实际运行的区块链环境进行模拟而得到的运行环境；
编译单元42，用于对加载单元41加载的智能合约进行编译，获得可执行文件。
执行单元43，用于执行编译单元42获得的可执行文件，生成所述智能合约的服务。
触发单元44，用于调用执行单元43生成的服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行。
测试单元45，用于在触发单元44触发所述智能合约在所述离线测试环境中运行之后，对所述智能合约进行测试。
进一步地，智能合约的测试装置4还可以包括：
环境搭建单元，用于搭建离线测试环境；
进一步地，所述环境搭建单元包括：
第一配置子单元，用于配置所述智能合约运行所需的应用程序编程接口，其中，所述应用程序编程接口包括数据写入接口、数据查询接口和范围查询接口；
第二配置子单元，用于配置所述智能合约运行所需的全局账本状态；
第三配置子单元，用于配置所述智能合约运行所需的区块数据。
进一步地，智能合约的测试装置4还可以包括：
第一获取单元，用于获取所述区块链环境中的全局账本状态数据；
所述第二配置子单元还用于，创建本地键值对数据库，并在所述本地键值对数据库中存储所述第一获取单元获取的所述全局账本状态数据。
进一步地，所述第三配置子单元包括：
区块确定单元，用于确定所述智能合约在所述区块链环境运行时所涉及的目标区块；
模拟模块生成单元，用于生成与所述区块确定单元确定的目标区块对应的模拟区块，其中，所述模拟区块的数据以键值对的形式存储于所述离线测试环境。
进一步地，智能合约的测试装置3还可以包括：
第二获取单元，用于在对所述智能合约进行编译，获得可执行文件之前，获取所述智能合约的业务逻辑；
初始化单元，用于基于与所述第二获取单元获取的业务逻辑对应的测试实例，对所述全局账本状态进行初始化。
进一步地，智能合约的测试装置4还可以包括：
格式转换单元，用于当触发单元44触发所述智能合约在所述离线测试环境中运行时，若离线测试环境中配置的模拟区块中的数据被调用，则将被调用的数据转换为目标格式以供所述智能合约调用，其中，所述目标格式为所述区块链环境中的区块的数据格式。
进一步的，测试单元45还用于，在指定的断点中断所述智能合约的运行，并输出所述智能合约的当前运行状态信息。
综上所述，本申请通过将待测试的智能合约加载至离线测试环境，并在该离线测试环境中对智能合约进行编译、执行、运行以及调试，解决了现有技术中智能合约的测试过程步骤繁琐、效率低下的问题。也即，一方面，由于该离线测试环境为对智能合约实际运行的区块链环境进行模拟而得到的运行环境，智能合约在该离线测试环境中运行时可以与其在真实区块链环境中运行时表现出一致的行为逻辑，故能够保障智能合约测试的有效性。另一方面，通过在该离线测试环境中运行智能合约，可以使智能合约脱离真实区块链环境而运行，避免了现有技术中对智能合约进行测试时，每次运行智能合约均需要重新部署区块链网络和发布智能合约的繁琐步骤，从而简化了智能合约的测试过程，有利于提高智能合约的开发效率。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置，模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
图5示出了本申请实施例提供的一种测试终端的示意框图，为了便于说明，仅示出了与本申请实施例相关的部分。
在本实施例中，所述测试终端5可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该测试终端5可包括：处理器50、存储器51以及存储在所述存储器51中并可在所述处理器50上运行的计算机可读指令52，例如执行上述的智能合约的测试方法的计算机可读指令。所述处理器50执行所述计算机可读指令52时实现上述各个智能合约的测试方法实施例中的步骤，例如图1所示的步骤S101至步骤S105。或者，所述处理器50执行所述计算机可读指令52时实现上述各装置实施例中各单元的功能，例如图4所示单元41至45的功能。
示例性的，所述计算机可读指令52可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器51中，并由所述处理器50执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该指令段用于描述所述计算机可读指令52在所述测试终端5中的执行过程。
所述处理器50可以是中央处理单元（Central Processing Unit，CPU），还可以是其它通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器51可以是所述测试终端5的内部存储单元，例如测试终端5的硬盘或内存。所述存储器51也可以是所述测试终端5的外部存储设备，例如所述测试终端5上配备的插接式硬盘，智能存储卡（Smart Media Card, SMC），安全数字（Secure Digital, SD）卡，闪存卡（Flash Card）等。进一步地，所述存储器51还可以既包括所述测试终端5的内部存储单元也包括外部存储设备。所述存储器51用于存储所述计算机可读指令以及所述测试终端5所需的其它指令和数据。所述存储器51还可以用于暂时地存储已经输出或者将要输出的数据。
在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机非易失性可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干计算机可读指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储计算机可读指令的介质。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (20)

  1. 一种智能合约的测试方法，其特征在于，所述测试方法包括：
    将待测试的智能合约加载至离线测试环境，其中，所述离线测试环境为对所述智能合约实际运行的区块链环境进行模拟而得到的运行环境；
    对所述智能合约进行编译，获得可执行文件；
    执行所述可执行文件，生成所述智能合约的服务；
    调用所述服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行；
    对在所述离线测试环境中运行的所述智能合约进行测试。
  2. 根据权利要求1所述的智能合约的测试方法，其特征在于，在将待测试的智能合约加载至离线测试环境之前包括：
    搭建所述离线测试环境。
  3. 根据权利要求2所述的智能合约的测试方法，其特征在于，所述搭建所述离线测试环境包括：
    配置所述智能合约运行所需的应用程序编程接口，其中，所述应用程序编程接口包括数据写入接口、数据查询接口和范围查询接口；
    配置所述智能合约运行所需的全局账本状态；
    配置所述智能合约运行所需的区块数据。
  4. 根据权利要求3所述的智能合约的测试方法，其特征在于，所述配置所述智能合约运行所需的全局账本状态，包括：
    获取所述区块链环境中的全局账本状态数据；
    创建本地键值对数据库，并在所述本地键值对数据库中存储获取的所述全局账本状态数据。
  5. 根据权利要求3所述的智能合约的测试方法，其特征在于，所述配置所述智能合约运行所需的区块数据，包括：
    确定所述智能合约在所述区块链环境运行时所涉及的目标区块；
    生成与所述目标区块对应的模拟区块，其中，所述模拟区块的数据以键值对的形式存储于所述离线测试环境。
  6. 根据权利要求3至5任一项所述的智能合约的测试方法，其特征在于，在对所述智能合约进行编译，获得可执行文件之前还包括：
    获取所述智能合约的业务逻辑；
    基于与所述业务逻辑对应的测试实例，对所述全局账本状态进行初始化。
  7. 根据权利要求5所述的智能合约的测试方法，其特征在于，所述测试方法还包括：
    当所述智能合约在所述离线测试环境中运行时，若所述模拟区块中的数据被调用，则将被调用的数据转换为目标格式以供所述智能合约调用，其中，所述目标格式为所述区块链环境中的区块的数据格式。
  8. 根据权利要求1至5任一项所述的智能合约的测试方法，其特征在于，所述对在所述离线测试环境中运行的所述智能合约进行测试，包括：
    在指定的断点中断所述智能合约的运行，并输出所述智能合约的当前运行状态信息。
  9. 一种计算机非易失性可读存储介质，所述计算机非易失性可读存储介质存储有计算机可读指令，其特征在于，所述计算机可读指令被处理器执行时实现如下步骤：
    将待测试的智能合约加载至离线测试环境，其中，所述离线测试环境为对所述智能合约实际运行的区块链环境进行模拟而得到的运行环境；
    对所述智能合约进行编译，获得可执行文件；
    执行所述可执行文件，生成所述智能合约的服务；
    调用所述服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行；
    对在所述离线测试环境中运行的所述智能合约进行测试。
  10. 根据权利要求9所述的计算机非易失性可读存储介质，其特征在于，所述计算机可读指令在实现所述将待测试的智能合约加载至离线测试环境的步骤之前，还实现如下步骤：
    搭建所述离线测试环境。
  11. 根据权利要求10所述的计算机非易失性可读存储介质，其特征在于，所述搭建所述离线测试环境包括：
    配置所述智能合约运行所需的应用程序编程接口，其中，所述应用程序编程接口包括数据写入接口、数据查询接口和范围查询接口；
    配置所述智能合约运行所需的全局账本状态；
    配置所述智能合约运行所需的区块数据。
  12. 根据权利要求11所述的计算机非易失性可读存储介质，其特征在于，所述配置所述智能合约运行所需的全局账本状态，包括：
    获取所述区块链环境中的全局账本状态数据；
    创建本地键值对数据库，并在所述本地键值对数据库中存储获取的所述全局账本状态数据。
  13. 根据权利要求11所述的计算机非易失性可读存储介质，其特征在于，所述配置所述智能合约运行所需的区块数据，包括：
    确定所述智能合约在所述区块链环境运行时所涉及的目标区块；
    生成与所述目标区块对应的模拟区块，其中，所述模拟区块的数据以键值对的形式存储于所述离线测试环境。
  14. 一种测试终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，其特征在于，所述处理器执行所述计算机可读指令时实现如下步骤：
    将待测试的智能合约加载至离线测试环境，其中，所述离线测试环境为对所述智能合约实际运行的区块链环境进行模拟而得到的运行环境；
    对所述智能合约进行编译，获得可执行文件；
    执行所述可执行文件，生成所述智能合约的服务；
    调用所述服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行；
    对在所述离线测试环境中运行的所述智能合约进行测试。
  15. 根据权利要求14所述的测试终端，其特征在于，所述处理器执行所述计算机可读指令时，在实现所述将待测试的智能合约加载至离线测试环境的步骤之前，还实现如下步骤：
    搭建所述离线测试环境。
  16. 根据权利要求15所述的测试终端，其特征在于，所述搭建所述离线测试环境包括：
    配置所述智能合约运行所需的应用程序编程接口，其中，所述应用程序编程接口包括数据写入接口、数据查询接口和范围查询接口；
    配置所述智能合约运行所需的全局账本状态；
    配置所述智能合约运行所需的区块数据。
  17. 根据权利要求16所述的测试终端，其特征在于，所述配置所述智能合约运行所需的全局账本状态，包括：
    获取所述区块链环境中的全局账本状态数据；
    创建本地键值对数据库，并在所述本地键值对数据库中存储获取的所述全局账本状态数据。
  18. 一种智能合约的测试装置，其特征在于，所述测试装置包括：
    加载单元，用于将待测试的智能合约加载至离线测试环境，其中，所述离线测试环境为对所述智能合约实际运行的区块链环境进行模拟而得到的运行环境；
    编译单元，用于对所述加载单元加载的智能合约进行编译，获得可执行文件；
    执行单元，用于执行所述编译单元获得的可执行文件，生成所述智能合约的服务；
    触发单元，用于调用所述执行单元生成的服务，并提供触发数据以触发所述智能合约在所述离线测试环境中运行；
    测试单元，用于在所述触发单元触发所述智能合约在所述离线测试环境中运行之后，对所述智能合约进行测试。
  19. 根据权利要求18所述的智能合约的测试装置，其特征在于，所述测试装置还包括：
    环境搭建单元，用于搭建离线测试环境。
  20. 根据权利要求19所述的智能合约的测试装置，其特征在于，所述环境搭建单元包括：
    第一配置子单元，用于配置所述智能合约运行所需的应用程序编程接口，其中，所述应用程序编程接口包括数据写入接口、数据查询接口和范围查询接口；
    第二配置子单元，用于配置所述智能合约运行所需的全局账本状态；
    第三配置子单元，用于配置所述智能合约运行所需的区块数据。
PCT/CN2018/123985 2018-09-26 2018-12-26 智能合约的测试方法、存储介质、测试终端及测试装置 WO2020062673A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811122234.8A CN109408373B (zh) 2018-09-26 2018-09-26 智能合约的测试方法、计算机可读存储介质及测试终端
CN201811122234.8 2018-09-26

Publications (1)

Publication Number Publication Date
WO2020062673A1 true WO2020062673A1 (zh) 2020-04-02

Family

ID=65466354

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/123985 WO2020062673A1 (zh) 2018-09-26 2018-12-26 智能合约的测试方法、存储介质、测试终端及测试装置

Country Status (2)

Country Link
CN (1) CN109408373B (zh)
WO (1) WO2020062673A1 (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111459825A (zh) * 2020-04-03 2020-07-28 银清科技有限公司 支付业务的区块链应用系统、方法及装置
CN112785439A (zh) * 2021-03-19 2021-05-11 中国工商银行股份有限公司 测试被部署在区块链节点上的智能合约的方法及装置
CN112817811A (zh) * 2020-12-31 2021-05-18 深圳市联影高端医疗装备创新研究院 扫描失败率的预测方法、装置、设备及存储介质
CN113010409A (zh) * 2020-09-16 2021-06-22 腾讯科技（深圳）有限公司 智能合约测试方法及装置、电子设备、存储介质
US11113271B2 (en) 2019-03-04 2021-09-07 Advanced New Technologies Co., Ltd. Methods and devices for performing off-chain testing on smart contract
CN113408259A (zh) * 2021-06-09 2021-09-17 微易签(杭州)科技有限公司 一种基于区块链填写文件的方法、系统、装置和存储介质
CN113419821A (zh) * 2021-07-09 2021-09-21 杭州复杂美科技有限公司 evm合约调试方法、计算机设备和存储介质
CN116743729A (zh) * 2023-08-14 2023-09-12 四川万流数据服务有限责任公司 智能合约调用装置、系统及方法

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110347609B (zh) * 2019-07-18 2023-05-23 腾讯科技（深圳）有限公司 一种测试区块链软件的方法及装置
CN110543419B (zh) * 2019-08-28 2021-09-03 杭州趣链科技有限公司 一种基于深度学习技术的智能合约代码漏洞检测方法
CN111090581B (zh) * 2019-11-22 2024-02-09 腾讯科技（深圳）有限公司 智能合约测试方法、装置、计算机设备和存储介质
CN111222160B (zh) * 2019-12-30 2022-07-29 联动优势科技有限公司 一种智能合约执行方法及系统
CN111352835B (zh) * 2020-02-25 2024-04-26 腾讯科技（深圳）有限公司 一种智能合约的测试方法、装置、设备及存储介质
CN111459504B (zh) * 2020-03-30 2023-07-04 百度国际科技（深圳）有限公司 智能合约的处理方法、装置、设备和存储介质
CN111627489B (zh) * 2020-04-20 2023-09-29 珠海妙存科技有限公司 闪存特性分析方法及系统
CN111723102A (zh) * 2020-08-21 2020-09-29 支付宝(杭州)信息技术有限公司 一种智能合约的更新方法和装置
CN112134764B (zh) * 2020-09-27 2022-08-09 中国银行股份有限公司 测试环境连通性的确定方法及装置
CN112783771A (zh) * 2021-01-22 2021-05-11 平安普惠企业管理有限公司 计算机软件的自动化测试方法、装置、设备以及存储介质
CN113204765B (zh) * 2021-04-27 2022-09-30 交叉信息核心技术研究院(西安)有限公司 一种Hyperledger Fabric链码的测试方法及系统
CN113961202B (zh) * 2021-12-21 2022-02-22 北京中科金财科技股份有限公司 一种自动调试智能合约的方法及系统
CN114327776A (zh) * 2021-12-30 2022-04-12 支付宝(杭州)信息技术有限公司 用于智能合约的调试方法、调试设备和调试系统
CN116975850B (zh) * 2023-09-25 2024-01-05 腾讯科技（深圳）有限公司 合约运行方法、装置、电子设备及存储介质
CN117971679A (zh) * 2024-02-02 2024-05-03 牛津(海南)区块链研究院有限公司 一种智能合约测试数据生成方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107943691A (zh) * 2017-11-17 2018-04-20 深圳圣马歌科技有限公司 一种自动产生智能合约的功能测试页面的方法及装置
CN108073513A (zh) * 2017-04-21 2018-05-25 富士通株式会社 对基于区块链的智能合约进行测试的装置和方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106598824B (zh) * 2016-11-25 2018-11-20 深圳前海微众银行股份有限公司 区块链的性能分析方法及装置
CN107329888B (zh) * 2017-05-31 2019-10-18 深圳前海微众银行股份有限公司 智能合约操作码覆盖率计算方法和系统
CN108074177B (zh) * 2017-12-05 2022-01-11 深圳前海微众银行股份有限公司 数据对账方法、系统和计算机可读存储介质

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108073513A (zh) * 2017-04-21 2018-05-25 富士通株式会社 对基于区块链的智能合约进行测试的装置和方法
CN107943691A (zh) * 2017-11-17 2018-04-20 深圳圣马歌科技有限公司 一种自动产生智能合约的功能测试页面的方法及装置

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11113271B2 (en) 2019-03-04 2021-09-07 Advanced New Technologies Co., Ltd. Methods and devices for performing off-chain testing on smart contract
CN111459825A (zh) * 2020-04-03 2020-07-28 银清科技有限公司 支付业务的区块链应用系统、方法及装置
CN111459825B (zh) * 2020-04-03 2023-10-31 银清科技有限公司 支付业务的区块链应用系统、方法及装置
CN113010409A (zh) * 2020-09-16 2021-06-22 腾讯科技（深圳）有限公司 智能合约测试方法及装置、电子设备、存储介质
CN112817811A (zh) * 2020-12-31 2021-05-18 深圳市联影高端医疗装备创新研究院 扫描失败率的预测方法、装置、设备及存储介质
CN112785439A (zh) * 2021-03-19 2021-05-11 中国工商银行股份有限公司 测试被部署在区块链节点上的智能合约的方法及装置
CN113408259A (zh) * 2021-06-09 2021-09-17 微易签(杭州)科技有限公司 一种基于区块链填写文件的方法、系统、装置和存储介质
CN113408259B (zh) * 2021-06-09 2024-05-07 微易签(杭州)科技有限公司 一种基于区块链填写文件的方法、系统、装置和存储介质
CN113419821A (zh) * 2021-07-09 2021-09-21 杭州复杂美科技有限公司 evm合约调试方法、计算机设备和存储介质
CN116743729A (zh) * 2023-08-14 2023-09-12 四川万流数据服务有限责任公司 智能合约调用装置、系统及方法

Also Published As

Publication number Publication date
CN109408373A (zh) 2019-03-01
CN109408373B (zh) 2022-03-04

Similar Documents

Publication Publication Date Title
WO2020062673A1 (zh) 智能合约的测试方法、存储介质、测试终端及测试装置
KR102225973B1 (ko) 블록체인 네트워크들을 위한 테스트 플랫폼
US11010283B2 (en) Mock-based unit test(s) for an end-to-end test of a code snippet
US11086619B2 (en) Code analytics and publication platform
US10360141B2 (en) Automated application test system
US11093372B2 (en) Systems and methods for automatically parallelizing sequential code
US8904353B1 (en) Highly reusable test frameworks and tests for web services
US20140372985A1 (en) API Rules Verification Platform
US20210191845A1 (en) Unit testing of components of dataflow graphs
CN110633200A (zh) 用于测试智能合约的方法和设备
US20200327044A1 (en) Method for constructing test scenario and information processing device
Salihoglu et al. Graft: A debugging tool for apache giraph
CN111782207B (zh) 任务流代码生成方法、装置、设备及存储介质
JP7119096B2 (ja) ライセンス検証装置
US7805711B2 (en) Redirection interface system and method for CIM object manager provider
US11755458B2 (en) Automatic software behavior identification using execution record
CN114116509A (zh) 程序分析方法、装置、电子设备和存储介质
US9122805B2 (en) Resilient mock object creation for unit testing
US20170091076A1 (en) Debugging remote vertex code on test machine
AU2014253672A1 (en) Checking undoability of an API-controlled computing system
CN111274144B (zh) 一种基于网络文件系统操作字接口的单元测试方法与系统
CN113986766A (zh) 一种自动化测试方法及装置
US11573787B1 (en) Hot reloading a running application with an unsaved source code change
US11275569B1 (en) Techniques and architectures for providing continuous integration (CI) and/or continuous delivery (CD) in a data lake environment
KR20200048016A (ko) 바이너리 분석을 위한 중간 언어 테스트 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18934623

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 09.07.2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18934623

Country of ref document: EP

Kind code of ref document: A1