CN110347609B

CN110347609B - Method and device for testing blockchain software

Info

Publication number: CN110347609B
Application number: CN201910649902.0A
Authority: CN
Inventors: 周勇钧
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-07-18
Filing date: 2019-07-18
Publication date: 2023-05-23
Anticipated expiration: 2039-07-18
Also published as: CN110347609A

Abstract

The application provides a method and a device for testing blockchain software, and relates to the technical field of blockchains. The method comprises the following steps: running the version block chain software to be tested in the test environment; synchronizing the historical uplink data to each simulated blockchain node running the version blockchain software to be tested; the historical uplink data comprises uplink data generated by sequentially and iteratively updating a plurality of historical version block chain software, wherein the historical version block chain software refers to all versions of block chain software released before the version block chain software to be tested; writing the test data set of the version block chain software to be tested into the corresponding simulated block chain node running the version block chain software to be tested; if the written test data set of the version block chain software to be tested is verified successfully, determining that the version block chain software to be tested is tested successfully. The method increases the compatibility of the block chain software and the historical uplink data for testing, and improves the reliability of the test result.

Description

Method and device for testing blockchain software

Technical Field

The present disclosure relates to the field of blockchain technologies, and in particular, to a method and apparatus for testing blockchain software.

Background

The blockchain software is updated at random, and after a developer obtains the updated blockchain software, the updated blockchain software needs to be tested to ensure the usability of the updated blockchain software.

The existing block chain software is generally deployed in a simulated block chain node of a test environment, test data is written into the simulated block chain node, whether the block chain software can normally run in the test environment is verified, and if the block chain software can normally run, the test is successful. However, the testing method only tests whether the blockchain software can normally run in a testing environment, and the reliability of the testing result is low.

Disclosure of Invention

The embodiment of the application provides a method and a device for testing blockchain software, which are used for improving the reliability of a result of testing the blockchain software.

In a first aspect, a method of testing blockchain software is provided, comprising:

running the version block chain software to be tested in the test environment; wherein each simulated blockchain node is arranged in the test environment;

synchronizing historical uplink data into each simulated blockchain node running the version blockchain software to be tested; the historical uplink data comprises uplink data generated by sequentially and iteratively updating a plurality of historical version blockchain software, wherein the historical version blockchain software refers to blockchain software of all versions issued before the blockchain software of the version to be tested;

Writing a test data set of the version block chain software to be tested into a corresponding simulation block chain node running the version block chain software to be tested;

and if the written test data set of the block chain software to be tested is successfully verified, determining that the block chain software to be tested is successfully tested.

In one possible implementation, before running the version blockchain software to be tested in the test environment, for a plurality of historical version blockchain software, the following steps are performed for each historical version blockchain software in the release order:

running historical version blockchain software in a test environment;

synchronizing uplink data generated in a test environment running a previous historical version of blockchain software into each simulated blockchain node running the historical version of blockchain software; wherein the previous historical version of blockchain software refers to a previous version of blockchain software relative to the historical version of blockchain software;

writing a test data set of the historical version block chain software into a corresponding simulated block chain node running the historical version block chain software;

if the written test data set is successfully verified, determining that the historical version block chain software is successfully tested;

The uplink data generated by the test environment running the historical version blockchain software is determined to be historical uplink data.

In one possible implementation, before writing a test data set of a version of blockchain software to be tested into a corresponding analog blockchain node running the version of blockchain software to be tested, the method includes:

and generating a test data set of the version block chain software to be tested, which is matched with the service protocol type, according to the service protocol type associated with the version block chain software to be tested.

In one possible implementation, writing a set of test data for a version of blockchain software to be tested into a corresponding analog blockchain node running the version of blockchain software to be tested includes:

and aiming at each functional point to be tested in the version block chain software to be tested, according to the functional point, writing part of test data in a test data set of the version block chain software to be tested into the simulation block chain node associated with the functional point.

In one possible implementation, after writing a portion of test data in a test data set of version blockchain software to be tested into an analog blockchain node associated with the functional point according to the functional point, the method includes:

Inquiring the partial test data through an interface of the analog blockchain node associated with the functional point, and if the partial test data is inquired, determining that the functional point verification of the blockchain software to be tested is successful;

and if each function point to be tested in the function points of the version block chain software to be tested is determined to be successful in verification, determining that the test data set of the version block chain software to be tested is successful in verification.

In a second aspect, there is provided an apparatus for testing blockchain software, comprising:

the deployment module is used for running the version block chain software to be tested in the test environment; wherein each simulated blockchain node is arranged in the test environment;

the synchronization module is used for synchronizing the historical uplink data into each simulation block chain node running the block chain software of the version to be tested; the historical uplink data comprises uplink data generated by sequentially and iteratively updating a plurality of historical version blockchain software, wherein the historical version blockchain software refers to blockchain software of all versions issued before the blockchain software of the version to be tested;

the writing module is used for writing the test data set of the blockchain software to be tested into the corresponding simulated blockchain node running the blockchain software to be tested;

And the determining module is used for determining that the block chain software to be tested is successfully tested if the written test data set of the block chain software to be tested is successfully verified.

In a possible implementation manner, the deployment module is further configured to run, for a plurality of historical version blockchain software, for each of the historical version blockchain software according to a release order before running the version blockchain software to be tested in the test environment, the historical version blockchain software in the test environment;

the synchronization module is further used for synchronizing uplink data generated in a test environment running the previous historical version blockchain software into each simulated blockchain node running the historical version blockchain software; wherein the previous historical version of blockchain software refers to a previous version of blockchain software relative to the historical version of blockchain software;

the writing module is also used for writing the test data set of the historical version blockchain software into the corresponding simulated blockchain node running the historical version blockchain software;

the determining module is further configured to determine that the historical version blockchain software is successfully tested if the written test data set is successfully verified, and determine uplink data generated by a test environment running the historical version blockchain software as historical uplink data.

In one possible implementation, the apparatus includes a generation module, wherein:

the generating module is configured to generate, before writing a test data set of the version blockchain software to be tested into a corresponding analog blockchain node running the version blockchain software to be tested, a test data set of the version blockchain software to be tested, which is matched with a service protocol type associated with the version blockchain software to be tested, according to the service protocol type associated with the version blockchain software to be tested.

In one possible implementation manner, the writing module is specifically configured to:

In one possible implementation, the apparatus further comprises a verification module, wherein:

the verification module is used for inquiring part of test data through an interface of a simulation block chain node associated with the functional point after writing the part of test data in a test data set of the block chain software to be tested into the simulation block chain node associated with the functional point according to the functional point, and determining that the functional point verification of the block chain software to be tested is successful if the part of test data is inquired; the method comprises the steps of,

In a third aspect, a computer device is provided, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of any one of the first aspect and one of the possible implementations when executing the program.

In a fourth aspect, there is provided a computer readable storage medium storing computer instructions that, when run on a computer, cause the computer to perform the method according to any one of the first aspect and one of the possible implementations.

In the embodiment of the invention, after the version blockchain software to be tested is operated in the test environment, the historical uplink data generated by all the historical version blockchain software issued before the version blockchain software to be tested is synchronized into each simulated blockchain node in the test environment, and then the test data set corresponding to the version blockchain software to be tested is written into each simulated blockchain node. In addition, the method for testing the version blockchain software to be tested in the embodiment of the application does not need manual intervention of a tester, and can relatively improve efficiency of testing the blockchain software. And because the historical uplink data comprises uplink data generated by all previous historical version blockchain software, the compatibility of the blockchain software to be tested and the data generated by all historical versions can be tested, and the traceability verification of the blockchain software to be tested can be rapidly and efficiently completed.

Drawings

Fig. 1 is an application scenario schematic diagram of a method for testing blockchain software according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a main chain and a test chain according to an embodiment of the present disclosure;

FIG. 3 is a flow chart of a method of generating historical uplink data according to an embodiment of the present application;

FIG. 4 is a flowchart of a method for testing blockchain software according to an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a trend of a test data set in a process of testing blockchain software according to an embodiment of the present application;

FIG. 6 is a block diagram of an apparatus for testing blockchain software according to an embodiment of the present application;

fig. 7 is a block diagram of a computer device according to an embodiment of the present application.

Detailed Description

For a better understanding of the technical solutions provided by the embodiments of the present application, the following detailed description will be given with reference to the accompanying drawings and specific embodiments.

In order to facilitate a better understanding of the technical solutions of the present application by those skilled in the art, the following description refers to the proper nouns of the present application.

Blockchain software: a software module for providing blockchain services, which can be understood as a client, runs on each blockchain node on the blockchain. The blockchain software generally defines the architecture of the blockchain service, the service protocol type of the blockchain service, the way in which data is stored in the blockchain service, the way in which blocks are generated in the blockchain, the creation of intelligent contracts in the blockchain, the cancellation way of the intelligent contracts, and the like. With the increasing data of blockchain, developers may continuously upgrade blockchain software. Compared with the block chain software of the previous version, the updated block chain software can perform optimization adjustment of the function points, change the function points according to the requirements, or add new function points and the like.

Uplink data: meaning that the data has been identified by the individual blockchain link points of the blockchain, and is written to the blockchain. The corresponding service scenes of the block chain are different, and the specific content of the uplink data is also different. The type of service protocol employed by the blockchain software may vary, as may the specific format of the uplink data.

Historical uplink data: refers to the uplink data generated by all versions of blockchain software preceding the blockchain software to be tested.

A main chain: refers to a data chain formed by real transaction data generated by the blockchain software in the running process of each blockchain node.

The test chain, which can be called as a side chain, has the same data as the main chain, is isolated from the main chain and does not affect each other.

Test cases: test cases (Test cases) are a set of Test inputs, execution conditions, and expected results that are formulated for a particular goal to Test a program path or to verify whether a particular requirement is met.

Test data: referring to data specifically generated for testing functional points of blockchain software, test data may be understood substantially as transaction data. Test data may be generated by a test case. The format of the test data may be different for different versions of blockchain software.

Test data set: the system is formed by combining a plurality of groups of test data, wherein each group of test data in the plurality of groups of test data represents a transaction.

Unexpired transaction output (Unspent Transaction Outputs, UTXO): is a core concept for transaction generation and verification in blockchain. Transactions form a set of chain structures, and all legitimate transactions can be traced back to the output of one or more of the previous transactions.

The following describes the design concept of the present application.

At present, when the blockchain software is tested, the blockchain software of the version to be tested is operated in a test environment, a test data set is written in the test environment for operating the blockchain software of the version to be tested, and if the test data set can be successfully verified, the blockchain software of the version to be tested is determined to normally operate.

By analyzing the prior art, the inventor finds that the prior art method for testing the blockchain software is similar to the method for testing other types of software, namely, only the running process of the blockchain software is tested, and the inventor finds that the prior art method for testing ignores the specificity of the blockchain software. The uplink data in the blockchain is non-tamperable, and when the blockchain software is upgraded, the historical uplink data can be influenced by the modification of the blockchain software, so the inventor finds that the compatibility of the blockchain software and the historical uplink data needs to be considered when the blockchain software is tested.

In view of this, the inventor designs a method for testing the blockchain software, and the method not only tests the running process of the blockchain software to be tested in the testing environment, but also tests the compatibility of the blockchain software to be tested and historical uplink data when testing the blockchain software to be tested, thereby improving the reliability of the test result.

The inventor further considers that to test the compatibility of the version blockchain software to be tested and the historical uplink data, if the version blockchain software to be tested is directly tested on the main chain, once the version blockchain software to be tested is abnormal, the abnormality of the whole main chain is caused, and irrecoverable loss is brought to users corresponding to all blockchain nodes, so the inventor further improves the method for constructing the historical uplink data, constructs the historical uplink data in a test environment according to the historical version blockchain software, tests the compatibility of the blockchain software by utilizing the constructed historical uplink data, and can reduce the test cost of the blockchain software as much as possible while guaranteeing the reliability of test results.

The inventors further consider that if historical uplink data were to be constructed, a significant amount of test data would necessarily be required. If test data and the like are manually input into the test environment by a tester, the efficiency is low, and the tester may miss or input some test data, so that the data accuracy in the historical uplink data is low, therefore, the inventor considers that a corresponding test data set can be automatically generated, the test efficiency can be improved, and the situation of manual input errors can be avoided.

The inventor further considers that in the test process, if corresponding test data is input on each analog blockchain node, each analog blockchain node is tested, the test period is relatively long, the inventor discovers that partial test data can be written in the analog blockchain node corresponding to the newly added functional point according to the newly added functional point of the blockchain software to be tested, the analog blockchain node corresponding to the newly added functional point is tested in a targeted manner, and the test efficiency can be further improved.

After the design concept of the embodiment of the present application is introduced, some simple descriptions are made below for application scenarios applicable to the technical solution of the embodiment of the present application, and it should be noted that the application scenarios described below are only used to illustrate the embodiment of the present application and are not limiting. In the specific implementation process, the technical scheme provided by the embodiment of the application can be flexibly applied according to actual needs.

Referring to fig. 1, fig. 1 is a schematic diagram of an application scenario of a testing blockchain software in an embodiment of the present application. The application scenario includes a test environment 110, a version management server 140, and a means 150 for testing blockchain software.

The test environment 110 may have a plurality of analog blockchain nodes, and the number of analog blockchain nodes may be arbitrary, and fig. 1 illustrates that the test environment 110 includes a first analog blockchain node 120 and a second analog blockchain node 130. Each simulated blockchain node corresponds to a client running blockchain software. Each analog blockchain node may be implemented by a terminal device, such as a personal computer or the like, running blockchain software on each of a plurality of terminal devices. The simulated blockchain node may also be implemented by a service in the cloud server, e.g., running blockchain software on a service in the cloud server that is equivalent to one blockchain node.

The first analog blockchain node 120 includes a memory 121, a processor 122, and an interface 123. The memory 121 may be configured to store program instructions that, when executed by the processor 122, perform the functions of the first analog blockchain node 120 in the embodiments of the present application, and the interface 123 may be configured to communicate with the device 150 for testing blockchain software. The second analog blockchain node 130 includes a memory 131, a processor 132, and an interface 133. The memory 131 may be configured to store program instructions that, when executed by the processor 132, perform the functions of the second analog blockchain node 130 in embodiments of the present application, and the interface 133 may be configured to communicate with the device 150 for testing blockchain software.

The means 150 for testing blockchain software may be implemented by a server or by a software module, and the means 150 for testing blockchain software is specifically limited herein. The means 150 for testing blockchain software includes a memory 151, a processor 152, and an interface 153. The memory 151 stores program instructions that, when executed by the processor 152, enable the apparatus 150 for testing blockchain software in the embodiments of the present application to perform the functions, and the apparatus 150 for testing blockchain software may communicate with each analog blockchain node in the testing environment 110 through the interface 153, and may also communicate with the version management server 140 through the interface 153.

The version management server 140 includes a memory 141, a processor 142, and an interface 143, and version management server 140 stores therein version blockchain software to be tested and a plurality of historical version blockchain software released before the version blockchain software to be tested. The processor 142 in the version management server 140 obtains the blockchain software of each version from the compiling platform of the developer through the interface 143, and sets version numbers for each blockchain software according to the release time sequence of each blockchain software. Alternatively, versions of blockchain software may be written directly into the version management server 140 by the developer. It should be noted that the plurality of historical version blockchain software and the version blockchain software to be tested are software generated by sequentially and iteratively updating for the same blockchain service.

In fig. 1, the version management server 140, the device 150 for testing the blockchain software and the testing environment 110 may be implemented by different servers, and the version management server 140, the device 150 for testing the blockchain software and the testing environment 110 may also be deployed in the same cloud server. It should be noted that to avoid affecting the operation of the backbone, the version management server 140, the means 150 for testing blockchain software, and the test environment 110 may all be deployed in a network environment that relatively isolates the backbone phases, such as a local area network.

The test environment 110, the version management server 140 and the device 150 for testing blockchain software, which need to be communicated, may be connected through one or more networks, and of course, the devices that need to be communicated are not limited to the devices connected in fig. 1, and may be communicated through the networks when any device has a communication requirement. The network may be a wired network, or may be a Wireless network, for example, a mobile cellular network, or may be a Wireless-Fidelity (WIFI) network, or may be other possible networks, which is not limited in this embodiment of the present application.

The following is an exemplary description of the interaction between the test environment 110, the version management server 140, and the means 150 for testing blockchain software.

The apparatus 150 for testing blockchain software obtains historical uplink data, obtains the blockchain to be tested from the version management server 140, deploys the blockchain software to be tested in the testing environment 110 after obtaining the blockchain software to be tested, and runs the blockchain software to be tested on each simulated blockchain node in the testing environment 110. The historical uplink data is then synchronized into the test environment 110. The test data set of the blockchain software to be tested is written in the test environment 110, if the test data set is verified to be successful, the device 150 for testing the blockchain software determines that the blockchain software to be tested is successfully tested, wherein the blockchain software to be tested can run normally and is compatible with historical uplink data.

After the version block chain software to be tested is determined to be successfully tested, the main chain on the version block chain software to be tested can be updated, so that a developer can continuously optimize the block chain service.

According to the testing method, not only can the running condition of the version block chain software to be tested, but also the compatibility of the version block chain software to be tested and the historical uplink data can be tested, and the reliability of the testing result is improved.

Of course, the method provided in the embodiment of the present application is not limited to the application scenario shown in fig. 1, but may be used in other possible application scenarios, and the embodiment of the present application is not limited. The functions that can be implemented by each device in the application scenario shown in fig. 1 will be described together in the following method embodiments, which are not described in detail herein.

Based on the application scenario discussed in fig. 1, in order to further explain the technical solution provided in the embodiments of the present application, the following detailed description is given with reference to the accompanying drawings and the specific embodiments. Although the embodiments of the present application provide the method operational steps as shown in the following embodiments or figures, more or fewer operational steps may be included in the method, either on a routine or non-inventive basis. In steps where there is logically no necessary causal relationship, the execution order of the steps is not limited to the execution order provided by the embodiments of the present application. The methods may be performed sequentially or in parallel as shown in the embodiments or the drawings when the actual processing or the apparatus is performed.

As discussed above, the means 150 for testing blockchain software is required to obtain historical uplink data before testing the blockchain software of the version to be tested, and the manner in which the means 150 for testing blockchain software obtains the historical uplink data is described below.

Mode one:

the means 150 for testing blockchain software obtains historical uplink data from the test chain.

Specifically, the test chain is the same as the data of the main chain, the main chain runs in each blockchain node, the test chain runs in the test network, the device 150 for testing the blockchain software can be authorized in advance, the test chain can be obtained from the test network, the test chain comprises uplink data generated by a plurality of historical version blockchain software, and the device 150 for testing the blockchain software can take the test chain as the historical uplink data.

For example, referring to fig. 2, fig. 2 is a schematic diagram of a main chain and a test chain, and the main chain and the test chain are identical in structure, and the blockchain software to be tested is the fourth version, that is, 3 blockchain software versions exist before the blockchain software to be tested. Each blockchain node generates blockchain 1 and block2 of fig. 2 when running a first historical version of blockchain software, which is then updated to a second historical version of blockchain software, and generates blockchain 3 and block4 of fig. 2 when running a second historical version of blockchain software. After the second historical version of blockchain software is updated to the third historical version of blockchain software, block 5 is generated. The means 150 for testing blockchain software obtains the test chain directly from the test network and determines the test chain as historical uplink data.

In the embodiment of the present application, the test chain is directly used as the historical uplink data, so that the processing amount of the device 150 for testing the blockchain software in the process of acquiring the historical uplink data can be relatively reduced.

Mode two:

the means for testing blockchain software 150 constructs historical uplink data from a plurality of historical version blockchain software.

Specifically, the apparatus for testing blockchain software 150 performs the steps shown in fig. 3 for each of the historical version blockchain software in the order of release for the plurality of historical version blockchain software. The process of constructing historical uplink data is described below in connection with fig. 3.

S301, the device 150 for testing the blockchain software acquires the historical version blockchain software.

Specifically, the version management server 140 stores various versions of blockchain software. When the device 150 for testing blockchain software needs to construct the historical uplink data, the device 150 for testing blockchain software can request the historical version blockchain software from the version management server 140, and the version management server 140 sends the historical version blockchain software to the device 150 for testing blockchain software, which is equivalent to the device 150 for testing blockchain software obtaining the historical version blockchain software. Alternatively, the apparatus 150 for testing blockchain software directly accesses the version management server 140 according to the version number of the historical version blockchain software after determining that the historical version blockchain software needs to be processed, and obtains the historical version blockchain software corresponding to the version number.

S302-S303, deploying historical version blockchain software.

The apparatus for testing blockchain software 150 executes S302 and S303 after acquiring the historical version blockchain software to deploy the historical version blockchain software in the first and second simulated blockchain nodes 120 and 130.

Specifically, fig. 3 illustrates an example of a test environment 110 that includes a first analog blockchain node 120 and a second analog blockchain node 130. Regardless of how many simulated blockchain nodes there are, the means 150 for testing blockchain software deploys the historical version of blockchain software into each simulated blockchain node. The apparatus 150 for testing the blockchain software may be configured to synchronously deploy the historical version blockchain software to the plurality of analog blockchain nodes 130, or may be configured to sequentially deploy the historical version blockchain software to each analog blockchain node according to a preset sequence. That is, the order of execution of S302 and S303 in fig. 3 may be arbitrary, and is not particularly limited herein.

S304-S305, synchronizing the uplink data generated in the test environment 110 running the previous historical version of blockchain software.

After the means 150 for testing blockchain software deploys the historical version blockchain software to each of the simulated blockchain nodes in the testing environment 110, each of the simulated blockchain nodes runs the historical version blockchain software. The apparatus 150 for testing blockchain software performs S304 and S305 to synchronize the uplink data generated in the testing environment 110 of the previous historical version of blockchain software into the first and second simulated blockchain nodes 120 and 130.

Specifically, the previous historical version of blockchain software refers to the blockchain software version that is adjacent to the order in which the historical version of blockchain software was published and that was published before the historical version of blockchain software. When the testing environment 110 runs the previous history version blockchain software, the device 150 for testing blockchain software synchronizes the uplink data generated by the previous history version blockchain software running in the testing environment 110 to each analog blockchain node running the previous history version blockchain software, and writes the test data set corresponding to the previous history version blockchain software in the corresponding analog blockchain node, thereby generating the uplink data generated in the testing environment 110 of the previous history version blockchain software. The means 150 for testing blockchain software obtains the uplink data generated in the testing environment 110 running the previous historical version of blockchain software and synchronizes it into the first and second simulated blockchain nodes 120 and 130.

Wherein if the historical version blockchain software is the first historical version blockchain software, i.e., the first blockchain software that was first released by the developer, the first historical version blockchain software does not exist for the previous historical version blockchain software, and therefore the means 150 for testing the blockchain software need not perform the steps of S304 and S305 while processing the first historical version blockchain software.

S306, writing the test data set of the historical version blockchain software to the corresponding simulated blockchain link point in the test environment 110.

Specifically, to facilitate the early preparation of the simulated blockchain nodes to receive test data and to ensure that the corresponding simulated blockchain nodes are in a normal state, the means 150 for testing blockchain software may send a request to the corresponding simulated blockchain nodes for writing a set of test data with the historical version blockchain software. Wherein the apparatus 150 involved in testing blockchain software needs to determine to which analog blockchain links to send requests to, as exemplified below.

The first determination method comprises the following steps:

determining a functional point of the historical version blockchain software to be verified relative to the previous historical version blockchain software, determining a simulated blockchain node associated with the functional point, and sending a request to a simulated blockchain link point associated with the functional point.

If the functional point to be verified is associated with a plurality of analog blockchain nodes or if there are a plurality of functional points to be tested, the plurality of functional points are associated with a plurality of analog blockchain nodes, the means 150 for testing blockchain software requests writing of part of the test data in the test data set to the plurality of analog blockchain nodes, respectively.

For example, the functionality of the historic version blockchain software that was added relative to the previous historic version blockchain software is changed by the verification mechanism of the verification node, and the first simulated blockchain node 120 is the verification node in the test environment 110, so the means 150 for testing blockchain software requests the first simulated blockchain node 120 to write the set of test data.

S307, receiving first writing feedback.

Specifically, after the corresponding analog block link point receives the test data set requested to write to the historical version blockchain software, if it is determined that the analog block link node can normally receive the test data set, a first write feedback may be sent to the device 150 for testing the blockchain software, where the first write feedback is used to indicate that the analog block link point confirms that the analog block link point can process the test data set.

S308, writing the test data set into the first analog blockchain node.

Specifically, the apparatus 150 for testing blockchain software parses the historical version blockchain software, generates a test case matching the service protocol type of the historical version blockchain software, and generates a test data set with the historical version blockchain software through the test case. Test cases define the data format of a test data set. Because the service protocol types of different historical version blockchain software may be different, the formats of the test data sets corresponding to the different historical version blockchain software may also be different.

After the test data set of the historical version block chain software is generated, the test data set of the historical version block chain software is written into the corresponding simulated block chain node.

It should be noted that, since there may be multiple historical version blockchain software, the functional points to be tested by different historical version blockchain software may involve different analog blockchain nodes, so that the analog blockchain nodes to which the device 150 testing the blockchain software writes the test data set may also be different when executing S306 on different historical version blockchain software.

Specifically, the means for testing blockchain software 150 writes the set of test data into the first simulated blockchain node after the means for testing blockchain software 150 requests the first simulated blockchain node 120 to write the set of test data.

S309, verifying the written test data of the to-be-tested version block chain software.

Specifically, the apparatus 150 for testing blockchain software may query the first analog blockchain node 120 for a set of test data after writing the set of test data into the first analog blockchain node 120, and if the set of test data is queried through the interface 123 of the first analog blockchain node 120, it indicates that the verification of the set of test data is successful.

If the device 150 for testing the blockchain software writes the test data in the test data set into the plurality of analog blockchain nodes, the device 150 for testing the blockchain software needs to query the corresponding test data through each analog blockchain node when verifying the test data set, and if the corresponding test data can be normally queried, the device indicates that the test data verification is successful.

If the device 150 for testing blockchain software verifies that the test data set is successful, step 310 is executed, and if the verification is successful, it is determined that the blockchain software version to be tested is successfully tested. If the means for testing blockchain software 150 verifies that the set of test data is unsuccessful, the means for testing blockchain software 150 resumes the process of S301 through S310 from the first historical version of blockchain software.

In one possible embodiment, the means for testing blockchain software 150 generates a test report for each historical version of blockchain software.

Specifically, after executing the processes from S301 to S310 on each historical version blockchain software, the device 150 for testing blockchain software may obtain the test result of the historical version blockchain software, and generate a test report with the historical version blockchain software, so as to facilitate the later investigation of the cause of unsuccessful testing. To facilitate identifying test reports for multiple historical version blockchain software, the means 150 for testing blockchain software may carry the version number of the historical version blockchain software in the corresponding test report.

After performing the methods of S301 to 310 described above for each of the plurality of historical version blockchain software until the methods of S301 to S310 are performed for the previous historical version blockchain software with respect to the version blockchain software to be tested, the device 150 that tested the blockchain software obtains the historical uplink data.

As an example, S306 and S307 are optional steps, that is, the device 150 testing the blockchain software may not request writing to the analog blockchain link point in advance.

In the second mode, the corresponding uplink data is constructed through a plurality of historical version block chain software, so that the data amount of the historical uplink data is controllable, the flexibility of testing is improved, a test chain is not required to be relied on, and the safety of main chain data is ensured.

After obtaining the historical uplink data, the means for testing blockchain software 150 tests the version blockchain software to be tested. The following describes a specific test procedure related to the embodiment of the present application with reference to fig. 4.

S401, obtaining the block chain software of the version to be tested.

Specifically, as discussed above, versions of blockchain software are stored in the version management server 140. The means 150 for testing the blockchain software obtains the blockchain software to be tested from the version management server 140.

S402-S403, deploying the blockchain software to be tested.

After acquiring the blockchain software to be tested, the specific device 150 for testing blockchain software executes S402 and S403 to deploy the blockchain software to be tested in the first and second analog blockchain nodes 120 and 130.

S404-S405, synchronizing historical uplink data.

After each of the simulated blockchain nodes runs the version of blockchain software under test, the device 150 testing the blockchain software performs S404 to synchronize the historical uplink data into the first simulated blockchain node 120 and into the second simulated blockchain node 130.

In one possible embodiment, to ensure that each analog blockchain node is ready to receive historical uplink data in advance, the apparatus 150 for testing blockchain software may request synchronization of the historical uplink data from each analog blockchain node in the testing environment 110 to inform each analog blockchain node in advance that there will be historical uplink data to be synchronized to each analog blockchain node prior to performing S404 and S405.

S406-S407, requesting to write the test data set of the block chain software of the version to be tested into the corresponding analog block chain link point.

Specifically, the apparatus for testing blockchain software 150 requests to the first analog blockchain node 120 to write partial test data of the blockchain software to be tested, and requests to the second analog blockchain node 130 to write partial test data of the blockchain software to be tested.

Before the device 150 for testing blockchain software requests to write the test data of the blockchain software to be tested in each analog blockchain node in the test environment 110, the device 150 for testing blockchain software needs to determine which analog blockchain nodes to write the test data set into before the device 150 for testing blockchain software requests to write the test data into the corresponding analog blockchain node. The determination of writing test data into the first and second blockchain simulation nodes 120 and 130 by the device 150 for testing blockchain software is illustrated in fig. 4. The means 150 for testing the blockchain software is illustrated below in a number of ways in which it is determined which simulated blockchain nodes to write the set of test data.

A1：

The apparatus 150 for testing blockchain software can write the test data set into each of the simulated blockchain nodes on average in advance according to the version blockchain software to be tested, that is, the apparatus 150 for testing blockchain software will write the test data in the test data set into each of the simulated blockchain nodes in the test environment 110 later.

In the embodiment of the present application, part of the test data is written in each of the analog blockchain nodes, so that the device 150 for testing blockchain software allocates the test data conveniently, and can complete the test on each of the analog blockchain nodes in the multi-test environment 110.

A2：

And according to each functional point to be tested in the version block chain to be tested, determining that part of test data in the test data set in the version block chain software to be tested is written into the simulation block chain node associated with the functional point according to the functional point.

Specifically, the apparatus 150 for testing blockchain software may determine, in advance, newly added functional points of the blockchain software of the version to be tested relative to the blockchain software of the previous version of the blockchain software of the version to be tested, analyze the analog blockchain nodes associated with each newly added functional point, and then write the test data sets into the corresponding analog blockchain nodes respectively.

For example, the apparatus 150 for testing blockchain software may determine in advance that the newly added function point data storage manner of the blockchain software to be tested is changed, which involves taking a leader (leader) node (first analog blockchain node 120 for example) and a follow (follower) node (second blockchain analog node 130 for example). The means for testing blockchain software 150 determines that the data storage mode change involves the first and second simulated blockchain nodes 120 and 130 in the blockchain, and thus the means for testing blockchain software 150 determines that test data needs to be written to both the first and second simulated blockchain nodes 120 and 130.

In this embodiment of the present application, when writing test data, the device 150 for testing blockchain software determines, according to the newly added function point, to write the test data set into the analog blockchain nodes associated with the newly added function point, so as to test each blockchain node in a targeted manner, thereby being capable of improving the efficiency of the verification process of each test data in the later period.

S408-S409, receiving write feedback.

Specifically, after requesting the corresponding blockchain simulation node, the first simulation blockchain node 120 determines that the corresponding test data can be received, sends a second write feedback to the device 150 that tests the blockchain software, and the device 150 that tests the blockchain software receives the second write feedback. Similarly, the second analog blockchain node 130 determines that it is capable of receiving the corresponding test data, sends a third write feedback to the device 150 that tests the blockchain software, and receives the third write feedback. The second write feedback and the third write feedback are each used to indicate that the corresponding analog blockchain node is ready to receive the respective test data.

In one possible embodiment, the apparatus for testing blockchain software 150 generates test data of the blockchain software to be tested matching the service protocol type according to the service protocol type of the blockchain software to be tested.

In particular, the service protocol type of the blockchain software may change accordingly during the continuous upgrade of the blockchain software service, and thus, the test data set constructed may not be identical for different versions of the blockchain software. Thus, the apparatus 150 for testing blockchain software generates a test data set matching the service protocol type according to the service protocol type of the blockchain software to be tested.

In one possible embodiment, the apparatus 150 for testing blockchain software may generate a test case corresponding to a service protocol type of the blockchain software to be tested according to the service protocol type of the blockchain software to be tested, and then generate a corresponding test data set through the test case.

In order to facilitate the device 150 for testing blockchain software to identify a set of test data corresponding to the blockchain software to be tested, the version number of the blockchain software to be tested corresponding to the set of test data may be carried while the set of test data is generated.

For example, a set of test data includes a target address, a hash value of a transaction, an index value, a current address, unlock footsteps, lock footsteps, and the like.

Specifically, when the first analog blockchain node 120 transfers money to the second analog blockchain node 130, the output of the transaction includes a locking script, and when the second analog blockchain node 130 uses the first analog blockchain node 120 to turn to the asset of the second analog blockchain node 130, a corresponding unlocking step needs to be input in the transaction to form a transaction, that is, a set of test data.

S410-S411, writing the test data set of the to-be-tested version block chain software.

Specifically, after receiving the write feedback, the apparatus for testing blockchain software 150 determines that the corresponding analog blockchain node is ready to receive the corresponding test data, and therefore, the apparatus for testing blockchain software 150 writes a portion of the test data in the set of test data into the first analog blockchain node 120, and the apparatus for testing blockchain software 150 may write a portion of the test data of the version blockchain to be tested into the second analog blockchain node 130.

S412, verifying the written test data set of the to-be-tested version block chain software.

Specifically, the apparatus 150 for testing blockchain software writes test data into both the first analog blockchain node 120 and the second analog blockchain node, and therefore, it is necessary to verify the test data written into the first analog blockchain node 120 and verify the test data written into the second analog blockchain node 130.

Further, the device 150 for testing the blockchain software queries corresponding test data through the interfaces of the analog blockchain nodes associated with each functional point, and if the correct test data can be queried in the analog blockchain nodes, it is determined that the functional point verification of the blockchain software to be tested is successful. Until all newly added function points of the block chain software to be tested are confirmed to be successful.

For example, a transaction data (corresponding to test data) is written into the first analog blockchain node 120, and the transaction can be queried through the interface 123 of the first analog blockchain node 120 at a later stage, which indicates that the transaction data writing is successful.

S413, determining that the block chain software of the version to be tested is successfully tested.

Specifically, the apparatus for testing blockchain software 150 verifies that the test data set is successful, and determines that the blockchain software version to be tested is successful.

S414, determining that the block chain software test of the version to be tested fails.

Specifically, if the test data of a certain functional point of the version blockchain software to be tested fails, the device 150 for testing the blockchain software determines that the version blockchain software to be tested fails to be tested.

It should be noted that S413 and S414 are two different cases, and the apparatus 150 for testing blockchain software executes one of them.

As an example, S406 through S409 are optional parts, that is, the apparatus 150 for testing blockchain software does not need to request the corresponding analog blockchain node in advance.

The test procedure of fig. 3 and 4 is specifically illustrated in conjunction with fig. 5. In fig. 5, the blockchain software to be tested is taken as an example of the fourth blockchain software version, that is, the blockchain software to be tested includes the first historical version blockchain software, the second historical version blockchain software and the third historical version blockchain software before.

S501, writing the first test data set (1) into a test environment running the first historical version blockchain software.

Specifically, the apparatus 150 for testing blockchain software deploys the blockchain software of the first historical version in the testing environment 110, and the first test data set (1) is test data that is generated by the apparatus 150 for testing blockchain software and matches the service protocol type of the blockchain software of the first historical version. The first set of test data (1) is written into a test environment 110 running a first historical version of blockchain software. The written first test data set (1) is then verified.

After verifying that the first test data set (1) is successful, the means 150 for testing blockchain software pulls the second historical version of blockchain software from the version management server 140, deploying the second historical version of blockchain software in the test environment 110.

S502, synchronizing the first test data set (1) into the test environment 110 running the second historical version blockchain software.

S503, writing the second test data set (2) into the test environment 110 running the second historical version blockchain software.

After writing the second set of test data (2) to the test environment 110, the second set of test data (2) is verified.

After verifying that the second test data set (2) is successful, the means 150 for testing blockchain software pulls the third historical version of blockchain software from the version management server 140, deploying the third historical version of blockchain software in the testing environment 110.

S504, synchronizing the first test data set (1) +the second test data set (2) into a test environment running the second historical version blockchain software.

S505, writing the third test data set (3) into a test environment running the third historical version blockchain software.

After writing the third set of test data (3) to the test environment 110, the third set of test data (3) is verified.

After verifying that the third test data set (3) is successful, the means 150 for testing blockchain software pulls the blockchain software to be tested from the version management server 140 and deploys the blockchain software to be tested in the test environment 110.

S506, synchronizing the first test data set (1) +the second test data set (2) +the third test data set (3) into the test environment 110 running the version of blockchain software to be tested.

S507, writing the fourth test data set (4) into the test environment 110 running the historical version blockchain software to be tested.

Specifically, after writing the fourth test data set (4) into the test environment 110 running the blockchain software of the historical version to be tested, verifying the fourth test data set (4), and after verifying that the fourth test data set is successful, determining that the blockchain software of the version to be tested is successful in testing.

Based on the same technical concept, the embodiment of the present application further provides an apparatus for testing blockchain software, which is the apparatus 150 for testing blockchain software discussed above, please refer to fig. 6, the apparatus includes:

a deployment module 601, configured to run version blockchain software to be tested in a testing environment; wherein, each simulated blockchain node is arranged in the test environment;

a synchronization module 602 for synchronizing historical uplink data into each of the simulated blockchain nodes running the version blockchain software to be tested; the historical uplink data comprises uplink data generated by sequentially and iteratively updating a plurality of historical version block chain software, wherein the historical version block chain software refers to all versions of block chain software released before the version block chain software to be tested;

a writing module 603, configured to write the test data set of the version blockchain software to be tested into a corresponding analog blockchain node running the version blockchain software to be tested;

The determining module 604 is configured to determine that the version blockchain software to be tested is successfully tested if the written test data set of the version blockchain software to be tested is successfully verified.

In a possible embodiment, the deployment module 601 is further configured to run, for a plurality of historical version blockchain software, for each of the historical version blockchain software according to the release order, before running the version blockchain software to be tested in the test environment, running the historical version blockchain software in the test environment;

a synchronization module 602 further configured to synchronize uplink data generated in a test environment running a previous historical version of blockchain software into each of the simulated blockchain nodes running the historical version of blockchain software; wherein the previous historical version of blockchain software refers to the previous version of blockchain software relative to the historical version of blockchain software;

the writing module 603 is further configured to write the test data set of the historical version blockchain software into a corresponding simulated blockchain node running the historical version blockchain software;

the determining module 604 is further configured to determine that the historical version blockchain software is successfully tested if the written test data set is successfully verified, and determine the uplink data generated by the test environment running the historical version blockchain software as historical uplink data.

In one possible embodiment, the apparatus includes a generation module 605, wherein:

the generating module 605 is configured to generate, according to a service protocol type associated with the version blockchain software to be tested, a test data set of the version blockchain software to be tested that matches the service protocol type before writing the test data set of the version blockchain software to be tested into a corresponding analog blockchain node running the version blockchain software to be tested.

In one possible embodiment, the writing module 603 is specifically configured to:

In one possible embodiment, the apparatus further comprises a verification module 606, wherein:

the verification module 606 is configured to query, after writing, according to the function point, part of test data in the set of test data of the version blockchain software to be tested into the analog blockchain node associated with the function point, part of test data through an interface of the analog blockchain node associated with the function point, and if part of test data is queried, determine that the function point of the version blockchain software to be tested is tested successfully; the method comprises the steps of,

As one embodiment, the generation module 605 and the verification module 606 are optional modules in the apparatus 150 for testing blockchain software.

Based on the same technical concept, the embodiments of the present application also provide a computer device, which may be implemented by a device having processing capabilities, such as a server or the like. Referring to fig. 7, the computer device includes a processor 701 and a memory 702, wherein:

the memory 702 has stored therein a computer program;

the processor 701, when executing the computer program, implements the method of testing blockchain software discussed previously.

One processor 701 is illustrated in fig. 7, but the number of processors 701 is not limited in practice.

The memory 702 may be, but is not limited to, a volatile memory (RAM), such as a random-access memory (RAM), a non-volatile memory (non-volatile memory), such as a read-only memory (rom), a flash memory (HDD), or a solid-state drive (SSD), or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 702 may be a combination of the above.

As one example, the functions of the various modules of the apparatus 150 of fig. 6 for testing blockchain software may be implemented by the processor 701 of fig. 7.

As one embodiment, the means 150 for testing blockchain software discussed above is provided in the computer device, that is, the means 150 for testing blockchain software is part of the computer device.

Based on the same technical concept, embodiments of the present application also provide a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform a method of testing blockchain software as previously discussed.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present application without departing from the spirit or scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims and the equivalents thereof, the present application is intended to cover such modifications and variations.

Claims

1. A method of testing blockchain software, comprising:

2. The method of claim 1, wherein the following steps are performed for each historical version of blockchain software in release order for a plurality of historical version of blockchain software before running the version of blockchain software to be tested in the test environment:

running historical version blockchain software in a test environment;

3. The method of claim 1 or 2, comprising, prior to writing a set of test data for a version of blockchain software to be tested into a corresponding analog blockchain node running the version of blockchain software to be tested:

4. The method of claim 1, wherein writing the set of test data for the version of blockchain software to be tested into the corresponding simulated blockchain node running the version of blockchain software to be tested comprises:

5. The method of claim 4, after writing a portion of the test data in the test data set of the version of blockchain software to be tested to the analog blockchain node associated with the functional point, according to the functional point, comprising:

6. An apparatus for testing blockchain software, comprising:

7. The apparatus of claim 6, wherein,

the deployment module is further used for running the historical version block chain software in the test environment for each historical version block chain software according to the release sequence aiming at a plurality of historical version block chain software before running the to-be-tested version block chain software in the test environment;

8. The apparatus of claim 6 or 7, wherein the apparatus comprises a generation module, wherein:

9. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the steps of the method of any of claims 1-5 when the program is executed.

10. A computer readable storage medium storing computer instructions which, when run on a computer, cause the computer to perform the method of any one of claims 1-5.