CN111625474A - Automatic testing method of alliance chain - Google Patents
Automatic testing method of alliance chain Download PDFInfo
- Publication number
- CN111625474A CN111625474A CN202010740536.2A CN202010740536A CN111625474A CN 111625474 A CN111625474 A CN 111625474A CN 202010740536 A CN202010740536 A CN 202010740536A CN 111625474 A CN111625474 A CN 111625474A
- Authority
- CN
- China
- Prior art keywords
- test
- node
- scenario
- real node
- real
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
Images
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/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application discloses an automatic testing method of a alliance chain, which comprises the following steps: constructing a test framework program, wherein an agent node is established in the test framework program, a plurality of test cases are stored in the agent node, and each test case corresponds to one test scene; updating the adaptive IP and the adaptive port of the proxy node into a database of a real node; starting the test framework program, and automatically establishing connection between the agent node and the real node according to the adaptive IP and the adaptive port; calling and executing the test case to obtain a corresponding test result; and collecting the test result, and forming a test report according to a set report format. The method solves the problems that manual testing is generally adopted in the existing testing method of the alliance chain, a large amount of manpower and time are consumed, and automatic and efficient testing cannot be achieved.
Description
Technical Field
The application relates to the technical field of block chains, in particular to an automatic testing method of a alliance chain.
Background
Federation chains allow authorized nodes to join a network, view information based on permissions, and are typically used for blockchains between enterprises. At present, no good way is provided for proving whether the functional completeness and performance index of an organization is qualified, and a business party cannot effectively combine with a business scene of the business party to accurately evaluate a alliance chain system, so that the alliance chain becomes unreliable. The credible alliance chain propulsion plan is established under the background, the union member units jointly develop the test standard, repeatedly demonstrate the test index and develop independent tests with the neutral third party identity.
However, since the alliance-link platform is a dynamically evolved test object, the test tool needs to participate in the test object to detect the correctness of the data transmitted by each link, and meanwhile, the test tool also needs to be capable of tampering the data to test the fault tolerance of the alliance-link platform, but cannot damage the stable operation and the continuous block output of the alliance-link platform.
At present, a testing method of a alliance chain usually adopts manual testing, consumes a great deal of manpower and time, and cannot realize automatic and efficient testing.
Disclosure of Invention
The application provides an automatic test method of a alliance chain, which aims to solve the problems that manual test is usually adopted in the existing test method of the alliance chain, a large amount of manpower and time are consumed, and automatic and efficient test cannot be realized.
An automatic testing method of a federation chain, comprising:
constructing a test framework program, wherein an agent node is established in the test framework program, a plurality of test cases are stored in the agent node, and each test case corresponds to one test scene;
updating the adaptive IP and the adaptive port of the proxy node into a database of a real node;
starting the test framework program, and automatically establishing connection between the agent node and the real node according to the adaptive IP and the adaptive port;
calling and executing the test case to obtain a corresponding test result;
the technical scheme can be known from the technical scheme that the test results are collected and the test report is formed according to the set report format.
According to the technical scheme, the automatic testing method for the alliance chain comprises the following steps: constructing a test framework program, wherein an agent node is established in the test framework program, a plurality of test cases are stored in the agent node, and each test case corresponds to one test scene; updating the adaptive IP and the adaptive port of the proxy node into a database of a real node; starting the test framework program, and automatically establishing connection between the agent node and the real node according to the adaptive IP and the adaptive port; calling and executing the test case to obtain a corresponding test result; and collecting the test result, and forming a test report according to a set report format. According to the automatic alliance chain testing method, by arranging the proxy node, the RPC (remote Procedure call) service is conducted with drainage and forwarding, communication, transaction, SDK interface calling, consensus algorithm and the like in the alliance chain are automatically tested on the premise that stable operation and continuous block output of an alliance chain platform are not damaged, test cases can be continuously supplemented according to newly added requirement expansion, testing efficiency is greatly improved, problems and defects which possibly occur in the alliance chain can be accurately tested, product iteration quality and efficiency can be guaranteed, and the method can be widely popularized and applied to markets.
Drawings
In order to more clearly explain the technical solution of the present application, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious to those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.
FIG. 1 is a schematic diagram illustrating an automatic testing method for a federation chain according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a communication connection between a real node and a proxy node;
FIG. 3 is a diagram of a test framework networking of a test framework program;
FIG. 4 is a test flow chart of a consensus test case in a test scenario of a consensus algorithm;
FIG. 5 is a flow chart of a message tamper test case under a message tamper test scenario;
FIG. 6 is a test flow diagram for generating a world state test case in a world state test scenario;
FIG. 7 is a test flowchart of a system version upgrade test case in a system version upgrade check scenario.
Detailed Description
The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
A plurality of nodes capable of realizing point-to-point communication are usually arranged in a alliance chain, the nodes are in peer-to-peer mode and can serve as a server side and a client side, message interaction is carried out through RPC to achieve consensus and provide external interface calling. The federation chain bottom layer publishes services and consumes services through a communication protocol (IP + Port).
Fig. 1 is a test schematic diagram of an automatic testing method of a federation chain according to an embodiment of the present application, fig. 2 is a schematic diagram of a communication connection between a real node and a proxy node, and fig. 3 is a schematic diagram of a test framework networking of a test framework program. With reference to fig. 1 to fig. 3, the present embodiment provides an automatic testing method for federation chains, which first performs step S1: and constructing a test framework program, establishing an agent node in the test framework program, and storing a plurality of test cases in the agent node, wherein each test case corresponds to one test scene. The nodes of the federation chain can be regarded as real nodes, and as shown in fig. 1, it is assumed that there are 5 real nodes in the federation chain, which are a first real node, a second real node, a third real node, a fourth real node and a fifth real node, respectively. The agent node in the test framework program is used for guiding the RPC service of the real node, namely the agent node serves as a called party of the RPC service of the real node for the real node to call, and meanwhile the RPC service of the real node can be called. In addition, the test scenarios may include a consensus algorithm test scenario, an sdk (software Development kit) interface call test scenario, and a system test scenario; the consensus algorithm test scenario can comprise a node state change and evolution logic judgment test scenario, a block persistence data inspection test scenario, a historical block synchronization mechanism scenario implementation and result inspection test scenario and a message tampering test scenario; the SDK interface calling test scene can comprise an inquiry interface seamless calling test scene, a transaction realization test scene, an intelligent contract installation upgrading and life cycle management test scene, a node certificate life cycle management test scene and an SDK authority control test scene; the transaction implementation test scenario may include a generation world state test scenario, a transfer test scenario, a double flower attack test scenario, and a transaction tampering test scenario. The system test scene can comprise system configuration check, system version upgrade check, real node expansion check and test case management check; the system may include a federation chain platform and a test framework program. According to different test scenarios, the test cases can be further divided into dynamic cases and static cases, for example, the consensus algorithm test case corresponding to the consensus algorithm test scenario is a dynamic case, and the SDK interface call test case corresponding to the SDK interface call test scenario is a static case. The test cases can be programmed according to the test requirements, can be added and supplemented to the test case management file at any time, and can meet most of the conceivable test requirements.
Execution continues with step S2: updating the adaptive IP and the adaptive port of the proxy node into a database of the real node; and performing step S3: and starting a test framework program, and automatically establishing connection between the proxy node and the real node according to the adaptive IP and the adaptive port. As shown in fig. 2 and fig. 3, when the federation chain includes 5 real nodes, 5 proxy RPC service ports corresponding to the real nodes are provided in the proxy node, where the proxy RPC service ports are respectively a first proxy RPC service port, a second proxy RPC service port, a third proxy RPC service port, a fourth proxy RPC service port, and a fifth proxy RPC service port, each proxy RPC service port includes an adaptation IP and an adaptation port of the proxy node, and the adaptation IP and the adaptation port of the proxy node are respectively updated into databases of the 5 real nodes, and when the test framework program is started, the proxy node can automatically establish communication connection with the real nodes, that is, the proxy node automatically accesses the federation chain. Therefore, the proxy node can also serve as a node in the alliance chain to conduct the flow guidance and the forwarding of the RPC service between the real nodes in the alliance chain, and conduct automatic testing on communication, transaction, SDK interface calling, consensus algorithm and the like which occur in an alliance chain platform in the flow guidance and forwarding processes.
Execution continues with step S4: and calling and executing the test case to obtain a corresponding test result. As shown in fig. 3, a proxy node service implementation class is provided in a proxy node, 5 proxy RPC service ports correspond to 5 proxy node service implementation classes, which are respectively a proxy node first service implementation class, a proxy node second service implementation class, a proxy node third service implementation class, a proxy node fourth service implementation class, and a proxy node fifth service implementation class, and according to a test case management file configured in a test framework program, each proxy node service implementation class is configured with a test case, and according to the setting of the test framework program, all the test cases can be called to perform comprehensive testing on a federation link platform, and also part of the test cases can be called to perform testing, so as to obtain a plurality of corresponding test results.
While step S4 is being performed, step S4' may also be performed: and when the test scene is a consensus algorithm test scene, forwarding the message body received from the real node to the called real node according to the RPC service port of the proxy node and the IP mapping list of the real node. The method comprises the steps that a proxy node RPC service port and a real node IP mapping list are configured in a test framework program, when a test scene is a consensus algorithm test scene, a real node serving as a calling party can send a message body to a real node serving as a called party, the proxy node can receive the message body through RPC service flow guiding, a corresponding test case is called and executed to obtain a test result, and meanwhile, the message body can be forwarded to the real node serving as the called party as an original sample to ensure normal operation of a consensus algorithm process in a alliance chain, namely stable operation of an alliance chain platform and continuous block output are not damaged. The RPC service port of the proxy node and the IP mapping list of the real node provide a correct target path for the forwarding of the message body. As shown in fig. 3, when there are 5 real nodes in the federation chain, the proxy RPC service first port corresponds to the first real RPC service port, the proxy RPC service second port corresponds to the second real RPC service port, the proxy RPC service third port corresponds to the third real RPC service port, the proxy RPC service fourth port corresponds to the fourth real RPC service port, and the proxy RPC service fifth port corresponds to the fifth real RPC service port.
Finally, step S5 is executed: and collecting all test results, and generating a test report according to a report format set by a test framework program.
According to the automatic alliance chain testing method, the RPC service of the real node is guided and forwarded by the proxy node, communication, transaction, SDK interface calling, consensus algorithm and the like in the alliance chain platform are automatically tested on the premise that stable operation and continuous block output of the alliance chain platform are not damaged, a test case can be continuously supplemented according to new requirement expansion, testing efficiency is greatly improved, problems and defects possibly occurring in the alliance chain can be accurately tested, iteration quality and efficiency of products can be guaranteed, and the method can be widely popularized and applied in the market.
For example, the testing steps of the corresponding test cases in different testing scenarios are illustrated, and fig. 4 is a testing flow chart of the consensus test case in the testing scenario of the consensus algorithm. As shown in fig. 4, when the test scenario is a consensus algorithm test scenario, a consensus test case needs to be called and executed, and when a process of a consensus algorithm is performed in a federation chain, a first real node is set as a caller, and a second real node and a third real node are set as callees, at this time, the first real node sends a message body to the second real node and the third real node, where the message body is a message body of the consensus algorithm process, and the proxy node first executes step S41: calling and executing a consensus test case corresponding to the consensus algorithm test scene; execution continues with step S42: under a test framework of the consensus test case, the agent node intercepts a message body sent by the first real node; thereafter, step S4' is performed: according to the RPC service port of the proxy node and the IP mapping list of the real nodes, the message body received from the first real node is forwarded to the second real node and the third real node; what may be performed simultaneously with step S4' is step S43: carrying out parameter detection on the message body to obtain a corresponding parameter value; for example, the parameter value may be a block height, and the like, and the present application is not particularly limited. After the step S43 is executed, the step S44 is continuously executed: and searching a parameter value in the database of the first real node, wherein when the parameter value is searched, the output test result is passed, and when the parameter value is not searched, the output test result is failed. It is easy to understand that when the parameter value is searched, the message body is not falsified or forged and is authentic, so the test result is passed.
FIG. 5 is a test flow diagram of a message tamper test case in a message tamper test scenario. As shown in fig. 5, when the test scenario is a message tampering test scenario, a corresponding message tampering test case needs to be called and executed. And the first real node is also taken as a caller, and the second real node and the third real node are taken as callees. The proxy node first performs step S41': calling and executing a message tampering test case; continuing to execute step S42': under a test framework of a message tampering test case, an agent node intercepts a message body sent by a first real node; thereafter, step S4' is performed: according to the RPC service port of the proxy node and the IP mapping list of the real nodes, the message body received from the first real node is forwarded to the second real node and the third real node; what may be performed simultaneously with step S4 'is step S43': message tampering is carried out on the message body, wherein the message tampering can be attribute modification, parameter modification, information deletion and called party information modification; after the step S43 ', the process proceeds to step S44': and searching the tampered message in the database of the first real node, wherein when the tampered message cannot be searched, the output test result is passed, and when the tampered message cannot be searched, the output test result is failed. It is easy to understand that when the tampered message is not searched in the database, it indicates that the message tampering test case detects that the message has been tampered, and the message in the database is authentic and authentic, so the test result is passed; when the tampered message is searched in the database, the message tampering test case can not detect the condition that the message is tampered, and the message in the database is also tampered and becomes untrustworthy, so that the test result is failed.
FIG. 6 is a test flow diagram for generating a world state test case in a world state test scenario. As shown in fig. 6, when the test scenario is a test scenario for generating a world state, a test case for generating the world state needs to be called and executed; still, the first real node is used as a transaction initiator, and the second real node and the third real node are used as transaction objects. The proxy node first performs step S41 ": calling and executing to generate a world state test case; continuing to execute step S42': acquiring a world state in a first real node; step S43 "may be performed simultaneously with step S42": acquiring transaction information from a message body received from a first real node; the transaction information may be transfer information, payment information, etc., and is not specifically described herein. Continuing to execute step S44': and searching the world state and the transaction information in the database of the real node, and outputting a passed test result when the world state and the transaction information can be searched, or else, outputting a failed test result. Alternatively, after the proxy node receives the message body, step S4' may be performed. It is easy to understand that when the world state and the transaction information can be searched in the database of the real node, it means that the transaction information has been updated to the latest state in the database of the real node, so the test result is passed; when the world state and the transaction information are not searched in the database of the real node, the fact that the transaction information cannot be updated in time by the database of the real node is shown, and therefore the test result is failed.
When the test scenario is a transfer test scenario, calling and executing the test case to obtain a corresponding test result, which may include the following specific steps: transferring and executing a transfer test case corresponding to the transfer test scene; acquiring world state balance data of a real node; acquiring transfer information from a message body received from a real node; and searching world state balance data and transfer information in a database of the real node, and outputting a test result of passing when the world state balance data and the transfer information are searched and the world state balance data is correct, or else, outputting a test result of failing.
FIG. 7 is a test flowchart of a system version upgrade test case in a system version upgrade check scenario. As shown in fig. 7, when the test scenario is a system version upgrade check, the system version upgrade test case needs to be called and executed. The proxy node first performs step S410: calling and executing a system version upgrading test case; step S420 is continued: acquiring the current version number of the system from a database of the real node; continuing to execute step S430: calling an inquiry version number interface of any real node, and searching the latest version number of system upgrade; any real node is here schematically illustrated by taking the first real node as an example. Continuing to execute step S440: and comparing whether the current version number is the same as the latest version number, if so, outputting a test result of passing, otherwise, outputting a test result of failing.
In the automatic testing method for the alliance chain provided by this embodiment, the behavior and the process of the proxy node are controlled by writing the corresponding test case in the test framework program, so that an expected test scenario is constructed, most service scenarios can be met, and the test bottleneck of the alliance chain platform is solved.
Those skilled in the art will readily appreciate that the techniques of the embodiments of the present invention may be implemented as software plus a required general purpose hardware platform. Based on such understanding, the technical solutions in the embodiments of the present invention may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments.
The same and similar parts in the various embodiments in this specification may be referred to each other.
Claims (10)
1. An automatic testing method for a federation chain, comprising:
constructing a test framework program, wherein an agent node is established in the test framework program, a plurality of test cases are stored in the agent node, and each test case corresponds to one test scene;
updating the adaptive IP and the adaptive port of the proxy node into a database of a real node;
starting the test framework program, and automatically establishing connection between the agent node and the real node according to the adaptive IP and the adaptive port;
calling and executing the test case to obtain a corresponding test result;
and collecting the test result, and forming a test report according to a set report format.
2. The automatic testing method of federation chains of claim 1, further comprising:
the test scene comprises a consensus algorithm test scene, an SDK interface calling test scene and a system test scene;
and when the test scene is a consensus algorithm test scene, forwarding the message body received from the real node to the called real node according to a proxy node RPC service port and a real node IP mapping list.
3. The automatic testing method of alliance chain as claimed in claim 2, wherein when the test scenario is a consensus algorithm test scenario, the invoking and executing test case to obtain a corresponding test result comprises:
calling and executing a consensus test case corresponding to the consensus algorithm test scene;
performing parameter detection on the message body received from the real node to obtain a corresponding parameter value;
and searching the parameter value in the database of the real node, and outputting a test result of passing when the parameter value is searched.
4. The automatic testing method of an alliance chain as claimed in claim 2 wherein the consensus algorithm test scenario comprises a node state change and evolution logic judgment test scenario, a block persistence data check test scenario, a historical block synchronization mechanism scenario implementation and result check test scenario and a message tampering test scenario;
when the test scenario is a message tampering test scenario, the calling and executing the test case to obtain a corresponding test result, including:
calling and executing a message tampering test case corresponding to the message tampering test scene;
performing message tampering on a message body received from the real node; the message tampering comprises attribute modification, parameter modification, information deletion and called party information modification;
and searching the tampered message in the database of the real node, and outputting a test result as pass if the tampered message cannot be searched.
5. The automatic testing method of a federation chain of claim 2, wherein the SDK interface invocation test scenario includes a query interface seamless invocation test scenario, a transaction implementation test scenario, an intelligent contract installation upgrade and lifecycle management test scenario, a node certificate lifecycle management test scenario, and an SDK permission control test scenario.
6. The automatic testing method of an alliance chain as claimed in claim 5 wherein the transaction implementation testing scenario includes generating a world state testing scenario, a transfer testing scenario, a double flower attack testing scenario and a transaction tampering testing scenario.
7. The automatic testing method of a federation chain according to claim 6, wherein when the test scenario is the generated world state test scenario, the invoking and executing a test case to obtain a corresponding test result comprises:
calling and executing a generated world state test case corresponding to the generated world state test scene;
acquiring the world state of the real node;
acquiring transaction information from a message body received from the real node;
and searching the world state and the transaction information in the database of the real node, and outputting a test result of passing when the world state and the transaction information can be searched.
8. The automatic federation chain testing method of claim 6, wherein when the test scenario is a transfer test scenario, the invoking and executing a test case to obtain a corresponding test result comprises:
transferring and executing a transfer test case corresponding to the transfer test scene;
acquiring world state balance data of the real node;
acquiring transfer information from a message body received from the real node;
and searching the world state balance data and the transfer information in a database of the real node, and outputting a test result of passing when the world state balance data and the transfer information are searched and the world state balance data is correct.
9. The automatic testing method of alliance chain as claimed in claim 2 wherein the system test scenario includes system configuration check, system version upgrade check, real node telescoping check and test case management check; the system comprises a federation chain platform and the test framework program.
10. The automatic testing method of a federation chain according to claim 9, wherein when the test scenario is the system version upgrade check, the invoking and executing a test case to obtain a corresponding test result comprises:
calling and executing a system version upgrading test case corresponding to the system version upgrading check;
acquiring the current version number of the system;
calling a version number query interface of the real node, and searching the latest version number of the system upgrade;
and comparing whether the current version number is the same as the latest version number, and if the current version number is the same as the latest version number, outputting a test result of passing.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010740536.2A CN111625474B (en) | 2020-07-29 | 2020-07-29 | Automatic testing method of alliance chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010740536.2A CN111625474B (en) | 2020-07-29 | 2020-07-29 | Automatic testing method of alliance chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111625474A true CN111625474A (en) | 2020-09-04 |
| CN111625474B CN111625474B (en) | 2020-11-10 |
Family
ID=72272971
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010740536.2A Active CN111625474B (en) | 2020-07-29 | 2020-07-29 | Automatic testing method of alliance chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111625474B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112527468A (en) * | 2020-12-23 | 2021-03-19 | 上海万向区块链股份公司 | Alliance chain one-stop type automatic deployment and test method and system |
| CN112948271A (en) * | 2021-04-09 | 2021-06-11 | 腾讯科技（深圳）有限公司 | Code testing method, device, equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109753433A (en) * | 2018-12-26 | 2019-05-14 | 中链科技有限公司 | Automated testing method, device and electronic equipment based on block chain |
| CN109872156A (en) * | 2019-03-11 | 2019-06-11 | 赛迪(青岛)区块链研究院有限公司 | A kind of alliance's chain common recognition system and method |
| CN110061889A (en) * | 2019-04-01 | 2019-07-26 | 北京众享比特科技有限公司 | Block chain performance test methods, device, equipment and storage medium |
| US20190306176A1 (en) * | 2016-10-17 | 2019-10-03 | Arm Limited | Blockchain mining using trusted nodes |
-
2020
- 2020-07-29 CN CN202010740536.2A patent/CN111625474B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190306176A1 (en) * | 2016-10-17 | 2019-10-03 | Arm Limited | Blockchain mining using trusted nodes |
| CN109753433A (en) * | 2018-12-26 | 2019-05-14 | 中链科技有限公司 | Automated testing method, device and electronic equipment based on block chain |
| CN109872156A (en) * | 2019-03-11 | 2019-06-11 | 赛迪(青岛)区块链研究院有限公司 | A kind of alliance's chain common recognition system and method |
| CN110061889A (en) * | 2019-04-01 | 2019-07-26 | 北京众享比特科技有限公司 | Block chain performance test methods, device, equipment and storage medium |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112527468A (en) * | 2020-12-23 | 2021-03-19 | 上海万向区块链股份公司 | Alliance chain one-stop type automatic deployment and test method and system |
| CN112948271A (en) * | 2021-04-09 | 2021-06-11 | 腾讯科技（深圳）有限公司 | Code testing method, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111625474B (en) | 2020-11-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111741114A (en) | System, method and equipment capable of monitoring cross-chain interaction based on block chain | |
| CN110442652A (en) | A kind of across chain data processing method and device based on block chain | |
| CN113347164B (en) | Block chain-based distributed consensus system, method, device and storage medium | |
| CN111625474B (en) | Automatic testing method of alliance chain | |
| CN112417049B (en) | Cross-chain interaction method and system based on block chain all-in-one machine | |
| CN108022090B (en) | Virtual account management method, device, system and readable storage medium | |
| CN107800565A (en) | Method for inspecting, device, system, computer equipment and storage medium | |
| CN110287119A (en) | A kind of automatic interface testing method and device based on python | |
| CN113194126B (en) | Transverse federal learning model construction method based on blockchain | |
| CN112075062A (en) | Automated commit transaction management in blockchain networks | |
| CN106375458A (en) | Service call system, method and device | |
| CN110535654A (en) | Parallel system dispositions method, device and computer equipment based on block chain | |
| CN113111126A (en) | Block chain cross-chain forwarding system and forwarding method thereof | |
| WO2023040453A1 (en) | Transaction information processing method and apparatus | |
| CN111861481A (en) | Block chain account checking method and system | |
| CN111949720B (en) | Data analysis method based on big data and artificial intelligence and cloud data server | |
| CN115202911A (en) | Node exception handling method and device of federated learning system and communication equipment | |
| CN106990974A (en) | A kind of APP applications update method, device and electronic equipment | |
| CN103326892B (en) | The operating method and device of web interface | |
| US20050166186A1 (en) | Automated generation of message exchange pattern simulation code | |
| CN107579871B (en) | Method and system for generating distributed test script based on model detection | |
| CN108400901A (en) | Test method, terminal device and the computer readable storage medium of application | |
| CN112015826B (en) | Intelligent contract security detection method based on block chain and related equipment | |
| CN107872493A (en) | A kind of information processing method, terminal and server | |
| CN110166295B (en) | Method for judging whether network topology supports Byzantine fault tolerance or not |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |