Blockchain interface testing system, method, device and readable storage medium

Abstract

The application provides a block link interface test system, method, device and readable storage medium. The block link interface test system provided by the application can independently run a program without relying on a working environment and can be applied to different system environments. The performance test of the block link interface can be automatically completed in one key mode without secondary request and confirmation actions. The block link interface test process is simplified, the performance test of the block link interface can be completed faster, the needs of the block chain asynchronous interface test process can be better met, in addition, the performance of the block link interface test can be improved, different files can be configured according to application scene needs, the universality is relatively strong, and process data generated in the performance test process of the block link interface and a test result report finally generated are recorded.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of interface testing, in particular to a block chain interface testing system and method, equipment and readable storage medium. BACKGROUND

[0002] System performance is a key indicator of software system application. Since the software system uses different scenarios, its performance indicator requirements are also different. According to the "request-response" model, the system performance is the number of requests that the system interface can correctly process per unit time. The industry generally uses two parameters to represent the performance indicators of the system: TPS indicators for "write" operation interfaces and QPS indicators for "read" operation interfaces. In addition, since the block chain network processes data asynchronously, the industry has added a CTPS indicator to identify the performance of the block chain network system in processing data.

[0003] Software performance testing is a direct method to obtain system performance indicators and an important part of software system quality assurance. Software performance testing simulates various normal, peak and abnormal load conditions through automated testing tools to test various performance indicators of the system, simulates business pressure or user usage scenarios in production operation to determine whether the performance indicators of the system meet the performance requirements, and verifies whether the performance of the software system meets the performance indicators. In actual application, the blockchain technology is usually combined with the actual scene, but different scenes have different performance requirements. For example, the bank settlement scene requires a higher TPS indicator, while the luxury goods traceability scene requires a higher QPS indicator. Therefore, performance testing of the block chain network platform is necessary, which will directly determine whether the block chain network platform can meet the needs of the actual scene. However, the current interface testing scheme cannot meet the requirements of block chain asynchronous interface performance testing. SUMMARY

[0004] The present application aims to at least solve one of the above technical defects, and in view of this, the present application provides a block chain interface testing system, method, equipment and readable storage medium to solve the technical defect that the existing technology cannot test the performance of the block chain interface.

[0005] A block chain interface testing system, the system comprising: a launcher, a configuration reader, a request generator, a threshold detector and a response processor;

[0006] Among them,

[0007] The launcher sends a start signal after starting to initialize the block chain interface testing system, and simultaneously sends a request to the target node of the block chain network, wherein the request is to obtain the block height in the current network and cache the block in the memory, and at the same time, mark the block as an initial block;

[0008] The configuration reader reads a target configuration file from a preset storage path, wherein the target configuration file is used to provide configuration parameters for the initiator, the request generator, the threshold detector, and the response processor;

[0009] After receiving the start signal of the block chain interface test system, the request generator is initialized, and connection pooling is performed during the initialization process, and each coroutine is processed in parallel;

[0010] The threshold detector is responsible for configuring the completion threshold of the coroutine group and configuring the completion threshold of the block chain network;

[0011] The response processor parses the block data of the target block chain network node and generates a test report of the target block chain network node.

[0012] Preferably, the target configuration file includes:

[0013] Node connection information, block chain interface test system working limit information, block chain network threshold information, block chain basic interface configuration information, and test case configuration information.

[0014] Preferably, the process of connection pooling performed by the request generator during the initialization process includes:

[0015] Building a target object pool;

[0016] Initializing the capacity of the target object pool to a preset threshold;

[0017] Determine whether there is a request to use an object;

[0018] If an object is needed, create a target object and bind the request to use the target object to the corresponding URL of the request;

[0019] Determine whether the number of objects in the target object pool exceeds the preset threshold;

[0020] If the number of objects in the target object pool exceeds the preset threshold, recycle the remaining objects in the target object pool that exceed the preset threshold.

[0021] Preferably, the process of processing each coroutine in parallel by the request generator includes:

[0022] When a target test case enters the execution queue, the request generator initializes the parameter of the number of concurrent coroutines in the target test case configuration to a corresponding number of target coroutines;

[0023] Concurrently execute all target coroutines, wherein the execution flow of each target coroutine is consistent;

[0024] Record the response results of all requests of the coroutines as the test report data evidence of the target test case, wherein each response result of a request includes a request time, a response time, and a response result.

[0025] Preferably, the threshold detector performs a process of configuring a completion threshold for a group of coroutines, including:

[0026] Collect the feedback results of each request in each group of coroutines, wherein the feedback results of each request in each group of coroutines include original responses representing three types of results of a request, i.e., a request success, a request failure, and a request timeout;

[0027] Compare the total number of all feedback results with the product of the number of concurrent coroutines set in the test case configuration and the number of requests each coroutine needs to complete;

[0028] Determine whether to enter the next test case process according to the comparison result of the feedback results of each request in each group of coroutines and the product of the number of concurrent coroutines set in the test case configuration and the number of requests each coroutine needs to complete;

[0029] If the total number of feedback results is less than the product of the number of concurrent coroutines set in the test case configuration and the number of requests each coroutine needs to complete, it is determined that the current test case process is not completed, and the remaining response results are continued to be waited for;

[0030] If the total number of feedback results is equal to the product of the number of concurrent coroutines set in the test case configuration and the number of requests each coroutine needs to complete, it is determined that the current test case process is completed, and the completion threshold of the group of coroutines is configured as the product of the number of concurrent coroutines set in the test case configuration and the number of requests each coroutine needs to complete.

[0031] Preferably, the threshold detector performs a process of configuring a completion threshold for a blockchain network, including:

[0032] After the process of all groups of coroutines is completed, a delay waiting time is determined according to a time parameter of waiting for a block generation in the configuration item system working limit;

[0033] After the delay waiting ends, subsequent blocks are obtained one by one from an initial block height;

[0034] The number of transactions in a block is counted;

[0035] According to the number of transactions in the block, the state of the transaction data in the block is recorded as successfully processed data;

[0036] Determine whether there is a zero transaction block according to the state of the transaction data in the block being successfully processed data;

[0037] If it is determined that there is a zero transaction block, it is determined that all data of the blockchain has been completed, and the completion threshold of the blockchain network is configured to meet the zero transaction block.

[0038] A blockchain interface test method, applied to the blockchain interface test system introduced above, the system includes: a launcher, a configuration reader, a request generator, a threshold detector, and a response processor;

[0039] Among them,

[0040] The launcher is started to send a start signal to initialize the blockchain interface test system, and at the same time, a request is sent to the target node of the blockchain network, wherein the request is to request to obtain the block height in the current network and cache the block in the memory, and at the same time, the block is marked as an initial block;

[0041] The configuration reader is called to read a target configuration file from a preset storage path, wherein the target configuration file is used to provide configuration parameters for the launcher, the request generator, the threshold detector, and the response processor;

[0042] After receiving the start signal of the blockchain interface test system, the request generator is called to generate an initialization, and in the initialization process, connection pooling is performed, and each coroutine is processed in parallel;

[0043] The threshold detector is called to configure the completion threshold for the coroutine group and the blockchain network;

[0044] The response processor is called to parse the block data of the target blockchain network node and generate a test report of the target blockchain network node.

[0045] Preferably, the target configuration file includes:

[0046] Node connection information, the blockchain interface test system working limit information, the blockchain network threshold information, the blockchain basic interface configuration information, and the configuration information of the test case.

[0047] A blockchain interface test device, comprising one or more processors and a memory;

[0048] The memory stores computer readable instructions, which are executed by the one or more processors to implement the steps of the blockchain interface test method as described in any of the foregoing.

[0049] A readable storage medium, the readable storage medium stores computer readable instructions, the computer readable instructions are executed by one or more processors, so that the one or more processors implement the steps of the block chain interface test method as any one of the preceding descriptions.

[0050] From the above technical solutions, when the interface performance of the block chain needs to be tested, the application embodiment can provide a block chain interface test system, which can include a starter, a configuration reader, a request generator, a threshold detector and a response processor. The starter can send a start signal after starting to initialize the block chain interface test system, and can send a request to the target node of the block chain network at the same time, wherein the request can be a request to obtain the block height in the current network and cache the block in the memory, and the block is marked as an initial block. The configuration reader can read a target configuration file from a preset storage path, wherein the target configuration file can be used to provide configuration parameters for the starter, the request generator, the threshold detector and the response processor. The request generator can be initialized after receiving the start signal of the block chain interface test system, and can be connected to the pool during the initialization process, and each coroutine can be processed in parallel. The threshold detector can be responsible for configuring the completion threshold of the coroutine group and the completion threshold of the block chain network. The response processor can analyze the block data of the target block chain network and generate a test report of the target block chain network.

[0051] The test system provided by the application embodiment can run independently without relying on the working environment, and can be applied to different system environments. The performance test of the block chain interface can be completed automatically in one key, without the need for secondary request and confirmation action, which simplifies the block chain interface test process, can faster complete the performance test of the block chain interface, better meets the needs of the block chain asynchronous interface test process, and can improve the performance of the block chain interface test. Different files can be configured according to the application scene, which has strong universality, and the process data generated during the block chain interface performance test and the finally generated test result report can be recorded. BRIEF DESCRIPTION OF DRAWINGS

[0052] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the drawings needed in the embodiment or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0053] Figure 1 A system architecture diagram for implementing block chain interface testing is provided for an embodiment of the present application.

[0054] Figure 2 An HTTP object connection pooling process diagram is provided for an embodiment example of the present application.

[0055] Figure 3 A test case coroutine group completion threshold configuration and a block chain network completion threshold configuration diagram is provided for an embodiment example of the present application.

[0056] Figure 4 A hardware structure block diagram of a block chain interface testing device is disclosed for an embodiment of the present application. DETAILED DESCRIPTION

[0057] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0058] In actual application process, the commonly used performance test tool is Apache JMeter tool. Apache JMeter tool is a pressure test tool developed based on Java, which is used for pressure testing of software. Apache JMeter tool is initially designed for web application testing, but later extended to other testing fields, and can be used for testing static and dynamic resources, such as static files, Java servlets, CGI scripts, Java objects, databases and FTP servers, etc.

[0059] Apache JMeter tool can simulate huge load on servers, networks or objects, test their strength under different pressure categories and analyze overall performance.

[0060] In addition, Apache JMeter tool can perform function or regression testing on application program, and verify whether the program returns expected results by creating scripts with assertions. In order to maximize flexibility, Apache JMeter tool allows using regular expressions to create assertions.

[0061] The workflow of Apache JMeter tool is as follows:

[0062] (1) Create test plan: The plan in Apache JMeter tool is a collection concept, and use cases need to be created under the plan.

[0063] (2) Configure test cases: configure cases through a visual window, including parameters such as the number of concurrent threads, delay time, response assertion logic, etc. Test cases mainly solve the problems of "how to request an interface" and "how to process the response data of the interface". The execution logic of the use case is sequential. Each use case will determine whether the use case passes according to the response assertion.

[0064] (3) Start the test program: all use cases scheduled can be started at one time, or the test program can be started for a certain use case.

[0065] (4) Complete the test and output the results: output the test results in the form of a table.

[0066] However, Apache JMeter tool also has some shortcomings, for example, Apache JMeter tool is only suitable for synchronous interface testing and is not suitable for asynchronous interface testing of blockchain networks.

[0067] Due to the time difference caused by the inherent consensus algorithm and data synchronization of the blockchain network, each request cannot be processed in real time, so most of the asynchronous interfaces provided by the blockchain network are asynchronous interfaces. In this case, Apache JMeter tool needs to initiate two rounds of requests to complete the test task: the first round of requests sends the data to be processed to the blockchain network, and after the blockchain network forms a block, the second round of requests is initiated to obtain the data processing result. In general, Apache JMeter tool is not suitable for asynchronous interface performance testing.

[0068] Secondly, Apache JMeter tool is built using Java language, which requires a large amount of hardware resources, resulting in low cost performance of hardware resource utilization. In Java, shared memory (global variable) is often used as a medium for inter-thread communication, and using shared memory for communication often encounters thread safety problems, so we often need to perform a lot of additional processing, including locking (synchronization), using atomic classes, using volatile to improve visibility, etc., which will cause additional hardware loss on non-computing business.

[0069] In view of the fact that most of the current block link interface test solutions are difficult to adapt to complex and changeable business requirements, for this reason, the applicant has studied a block link interface test solution, which can be applied to different system environments without relying on the working environment; can one-key automatically complete the performance test of the block link interface, without the need for secondary request and confirmation action, simplifying the process of block link interface test, which can complete the performance test of the block link interface faster, better meet the needs of the block chain asynchronous interface test process, in addition, it can also improve the performance of block link interface test, different files can be configured according to the application scene, which has strong universality, and the process data generated in the block link interface performance test process and the finally generated test result report are recorded.

[0070] The method provided by the embodiments of the present application can be used in many general or special computing device environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor devices, distributed computing environments including any of the above devices or devices, etc.

[0071] The block link interface test solution provided by the embodiments of the present application can be applied to various interface test systems, and can also be applied to various computer terminals or intelligent terminals, and the execution subject can be a processor or server of a computer terminal or an intelligent terminal.

[0072] The following will be combined Figure 1 to introduce an optional system architecture that can realize block link interface performance test according to the embodiments of the present application, as Figure 1 shown, the system architecture can include: a launcher, a configuration reader, a request generator, a threshold detector and a response processor.

[0073] Among them,

[0074] The launcher can send a start signal after starting to initialize the block link interface test system, and at the same time can send a request to the target node of the block chain network.

[0075] In essence, a launcher is equivalent to the main entrance of a program system, therefore, the launcher can be equivalent to the main entrance of the block link interface test system.

[0076] After the launcher is started, the block link interface test system can be started.

[0077] Among them, the request can be a request to obtain the block height in the current network and cache the block in the memory, and at the same time mark the block as an initial block, marking the block as an initial block can help confirm whether the block data has been processed when reading the block data later.

[0078] The configuration reader can read the target configuration file from a preset storage path.

[0079] Among them,

[0080] The target configuration file can be used to provide configuration parameters for the starter, the request generator, the threshold detector, and the response processor.

[0081] The starter, the request generator, the threshold detector, and the response processor can configure the parameters required by each component according to the target configuration file provided by the configuration reader.

[0082] In actual application, the work of other components of the block link interface test system depends on the configuration information, based on this, the configuration reader can read the yaml configuration file from the specified path, and supply each component of the block link interface test system according to the needs of other components of the block link interface test system.

[0083] Among them,

[0084] The configuration file read by the configuration reader can include the following configuration items:

[0085] (1) Node connection information: can include the access IP address and port number of the node.

[0086] (2) System work limit: can include the access timeout time of the node interface and the time of waiting for block generation.

[0087] (3) Blockchain network threshold: can include the threshold index for determining that the blockchain network completes transaction data processing.

[0088] (4) Basic interface configuration: can include setting the access mode of the basic interface, including interface name, HTTP request mode, request URL, request body parameter, response result value mode. The basic interface configuration allows multiple.

[0089] (5) Test case configuration: the block link interface test system can initiate a request to the node according to this configuration item, and the configuration content includes the case name, the number of concurrent coroutines, the number of requests each coroutine needs to complete, and the request sending rate per second.

[0090] The request generator can start initialization after receiving the start signal of the block link interface test system, and perform connection pooling during initialization, while processing each coroutine in parallel.

[0091] In actual application, the request generator is the core component of the block link interface test system, and the request generator is mainly responsible for sending the preset network request according to the established rules.

[0092] The request generator has two core operation processes, which can include connection pooling and parallel processing of coroutines.

[0093] The request generator has two core operation processes, which can include connection pooling and parallel processing of coroutines.

[0094] The request generator has two core operation processes, which can include connection pooling and parallel processing of coroutines.

[0095] Step S101, a target object pool is constructed.

[0096] Specifically, when the block in the blockchain has a demand for using objects, the embodiment of the application can construct a target object pool to save objects.

[0097] In actual application, the object pool pattern manages a collection of replaceable objects. Components borrow objects from the pool, use them for some task, and return the objects when the task is complete. The returned objects are then available to satisfy requests, whether from the same component or from other components.

[0098] The object pool pattern can manage objects that represent real resources or that incur an expensive initialization cost that is amortized by reusing.

[0099] The object pool pattern is a variant of the singleton pattern, which provides an entry point to a collection of identical object instances.

[0100] It is useful when objects are needed to represent a collection of replaceable resources, each of which can be used by a component at a time.

[0101] Step S102, the capacity of the target object pool is initialized to a preset threshold.

[0102] Specifically, in actual application, the capacity of the target object pool is limited, therefore, after the target object pool is constructed, the capacity of the target object pool can be initialized to a preset threshold.

[0103] The preset threshold can be set according to the use scenario of the block chain interface test system.

[0104] The preset threshold can be set according to the use scenario of the block chain interface test system.

[0105] For example, the preset threshold can be set to 5000.

[0106] In the actual process, when the initiator receives the start signal of the block link interface test system, the request generator is immediately initialized, and the request generator can use the Golang open source framework github.com / valyala / fasthttp to initialize the target object pool to an upper limit of 5000 HTTP object pools.

[0107] Step S103, determine whether there is a request to use the object.

[0108] Specifically, after the target object pool is created, objects are only created when there is a need to use the object.

[0109] For example,

[0110] In actual application, HTTP objects are created only when they are used, and after the object is created, the created object is bound to the requested URL, which is a one-to-many binding relationship, that is, one URL can bind multiple objects.

[0111] For example,

[0112] When it is determined that an HTTP object needs to be used, the HTTP object needed is created and bound to the requested URL, wherein one URL can bind multiple HTTP objects.

[0113] Therefore, if it is determined that the object needs to be used, step S104 can be performed.

[0114] Step S104, create a target object and bind the requested URL corresponding to the request to use the target object.

[0115] Specifically, as described above, the application can determine whether there is a need to use the object, and if it is determined that the object needs to be used, the target object can be created according to the demand for using the object and the requested URL corresponding to the request to use the target object is bound.

[0116] So that the target object can be accessed according to the requested URL corresponding to the target object.

[0117] Step S105, determine whether the number of objects in the target object pool exceeds the preset threshold.

[0118] Specifically, as described above, each object pool has a fixed capacity, and in actual application, the created objects are used and then returned to the object pool. If there are too many objects in the object pool, it may cause system crash, and the excess objects need to be recycled.

[0119] As can be seen from the above, after the target object pool is constructed, a threshold is set for the capacity of the target object pool, so that after the target object is created, it can be determined in time whether the number of objects in the target object pool exceeds the preset threshold.

[0120] If the number of objects in the target object pool exceeds the preset threshold, the target object pool may not be able to accommodate the part of objects exceeding the preset threshold, which may cause the block interface test system to crash. Therefore, when it is determined that the number of objects in the target object pool exceeds the preset threshold, step S106 can be performed.

[0121] In step S106, the remaining objects in the target object pool that exceed the preset threshold are recycled.

[0122] Specifically, as can be seen from the above, when the objects are used up, they will be put into the object pool. In actual application, only the objects exceeding the upper limit value of the object pool will be recycled by the garbage collector.

[0123] Therefore, if it is determined that the number of objects in the target object pool exceeds the preset threshold, the remaining objects in the target object pool that exceed the preset threshold can be recycled.

[0124] For example, the Golang language creates a garbage collection mechanism to recycle the objects exceeding the upper limit value of the object pool.

[0125] For example, Figure 2 An HTTP object connection pooling process diagram is shown.

[0126] As Figure 2 shown, after each coroutine request in test case A uses an object, the present application can create multiple HTTP objects according to the requests of each coroutine and put them into the HTTP object pool. When each coroutine needs to use an object, it can take an object from the HTTP object pool. When each coroutine in test case A uses up each HTTP object, the used HTTP objects can be put into the HTTP object pool again.

[0127] When each coroutine in test case B needs to use an object, enough objects needed by each coroutine in test case B can be created according to the number of objects in the HTTP object pool at present, and the objects originally placed in the HTTP object pool can be reused by test case B. When each coroutine in test case B uses up the objects, the used objects can also be put into the HTTP object pool again.

[0128] The process of parallel processing of each coroutine by the request generator can include the following:

[0129] Step S201, when the target test case enters the execution queue, the request generator initializes the number of concurrent coroutines in the target test case configuration to the corresponding number of target coroutines.

[0130] Specifically, in actual application, when a test case enters the execution queue, the number of coroutines in the test case configuration is initialized to the corresponding number of coroutines, as shown in the coroutine group in the above Figure 2 .

[0131] Therefore, when the target test case enters the execution queue, the request generator initializes the number of concurrent coroutines in the target test case configuration to the corresponding number of target coroutines.

[0132] For example,

[0133] As described above Figure 2 , there are N coroutines in test case A, and when test case A enters the execution queue, the request generator initializes the number of concurrent coroutines in the test case A configuration to N coroutines.

[0134] Step S202, concurrently execute all target coroutines.

[0135] Specifically, as described above, when the target test case enters the execution queue, the request generator initializes the number of concurrent coroutines in the target test case configuration to the corresponding number of target coroutines.

[0136] After creating each of the target coroutines, the application can concurrently execute all target coroutines, wherein the execution flow of each target coroutine can be set to be consistent to achieve the purpose of concurrent request.

[0137] Step S203, record the response results of all coroutine requests as test report data evidence of the target test case.

[0138] Specifically, as described above, when the target test case enters the execution queue, the request generator initializes the number of concurrent coroutines in the target test case configuration to the corresponding number of target coroutines. And after creating each of the target coroutines, the application can concurrently execute all target coroutines.

[0139] After concurrently executing all target coroutines, in order to better monitor the execution of each target coroutine, the response results of all coroutine requests can be recorded as test report data evidence of the target test case.

[0140] Each response result of a request can include request time, response time, and response result.

[0141] In practical application, the threshold detector of the block chain interface test system is mainly responsible for two works in the interface test process, wherein the threshold detector works simultaneously with the request generator.

[0142] The threshold detector can be responsible for the completion threshold configuration of the coroutine group and the completion threshold configuration of the block chain network.

[0143] The threshold detector can be responsible for the completion threshold configuration of the coroutine group and the completion threshold configuration of the block chain network.

[0144] The process of the threshold detector configuring the completion threshold of the coroutine group includes:

[0145] Step S301, collecting the feedback results of each request in each coroutine group.

[0146] Specifically, in practical application, each coroutine in each coroutine group will be affected by network fluctuations, resource grabbing and other situations, resulting in inconsistent completion time. The threshold detector can collect the feedback results of each request in each coroutine group, so as to determine whether to enter the next test case process.

[0147] Therefore, after the concurrent execution of the test case coroutine group, the threshold detector can collect the feedback results of each request in each coroutine group, so as to monitor whether each coroutine completes the corresponding work in real time.

[0148] The feedback results of each request in each coroutine group include the original response of the three types of results that the block chain network indicates that the request is successful, the request fails and the request times out.

[0149] Step S302, comparing the total number of all feedback results with the product of the concurrent coroutine number set in the test case configuration and the request number each coroutine needs to complete.

[0150] Specifically, as introduced above, the embodiment of the present application can collect the feedback results of each request in each coroutine group.

[0151] The feedback results of each request in each coroutine group can feedback whether each request in each coroutine group is successful, times out, etc.

[0152] After collecting all the feedback results, the total number of all feedback results can be compared with the product of the concurrent coroutine number set in the test case configuration and the request number each coroutine needs to complete, so as to determine whether the current test case process has been completed.

[0153] Step S303, according to the comparison result of the feedback results of each request in each coroutine group and the product of the concurrent coroutine number set in the test case configuration and the request number each coroutine needs to complete, it is judged whether to enter the next test case process.

[0154] Specifically, as introduced above, the embodiment of the present application can collect the feedback results of each request in each coroutine group.

[0155] The feedback results of each request in each coroutine group can feedback the relevant state of each request of each coroutine.

[0156] After collecting the feedback results of each request in each coroutine group, whether to enter the next test case process can be determined according to the comparison result of the feedback results of each request in each coroutine group and the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine.

[0157] In actual application process, the threshold detector can compare the total number of all feedback results with the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine, to confirm whether the state of the feedback result is that the process corresponding to the current test case has been completed.

[0158] If the total number of feedback results is less than the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine, it indicates that the process of the current test case has not been completed, and then step S304 can be executed.

[0159] If the total number of feedback results is equal to the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine, it indicates that the process of the current test case has been completed, and then the next test case process can be entered, and step S305 can be executed.

[0160] In step S304, it is determined that the current test case process is not completed, and the remaining response results are continued to be waited for.

[0161] Specifically, as introduced above, the embodiment of the present application can compare the total number of all feedback results with the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine, to confirm whether the state of the feedback result is that the process corresponding to the current test case has been completed. If the total number of feedback results is less than the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine, it indicates that some feedback results of requests have not been collected, and it indicates that the process of the current test case has not been completed. Then it is determined that the current test case process is not completed, and the remaining response results are continued to be waited for.

[0162] In step S305, it is determined that the current test case process is completed, and then the completion threshold of the coroutine group is configured as the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine.

[0163] Specifically, as known from the above description, the threshold detector provided in the embodiments of the present application compares the total number of feedback results with the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine to determine whether the state of the feedback results is that the process corresponding to the current test case has been completed and whether it can enter the process of the next test case.

[0164] In actual application, when the total number of feedback results is equal to the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine, it indicates that the process of the current test case has been completed, and after the process of the current test case is completed, the process of the next test case can be entered.

[0165] Therefore, when it is determined that the process of the next test case can be entered, it indicates that the process of the current test case has been completed, and the completion threshold of the coroutine group can be configured as the product of the number of concurrent coroutines set in the test case configuration and the number of requests required to be completed by each coroutine.

[0166] For example, Figure 3 An example of a test case coroutine group completion threshold configuration and a blockchain network completion threshold configuration is shown in the figure.

[0167] As shown in the figure, Figure 3

[0168] When each coroutine group in the coroutine group of the test case A has completed the corresponding work, the embodiments of the present application can set the completion threshold of the test case A and determine that the process of the test case B can be entered.

[0169] The process of the threshold detector for configuring the completion threshold of the blockchain network can include the following:

[0170] Step S401, after all the coroutine group processes are completed, the delay waiting time is determined according to the time parameter of the waiting block generation in the configuration item system work limit.

[0171] Specifically, in actual application, after all the coroutine group processes of all the test cases are completed, the delay waiting needs to be done according to the time parameter of the waiting block generation in the configuration item system work limit, and no request is sent to the blockchain network during the delay waiting time, so that the blockchain network can use all the performance to process the request data.

[0172] Therefore, after all the coroutine group processes are completed, the delay waiting time is determined according to the time parameter of the waiting block generation in the configuration item system work limit, so that the related request can be suspended according to the delay waiting time.

[0173] Step S402, after the delay waiting is ended, the subsequent blocks are obtained one by one from the initial block height.​

[0174] Specifically, as introduced above, the application can determine the delay waiting time according to the time parameter generated by the waiting block in the configuration item system work limit after all the coroutine group flows are completed, so that the related request can be suspended according to the delay waiting time.

[0175] In actual application process, after the delay waiting ends, the application can obtain the subsequent blocks one by one from the initial block height, so as to count the number of transactions in the block.

[0176] Step S403, count the number of transactions in the block.

[0177] Specifically, as introduced above, after the delay waiting ends, the application can obtain the subsequent blocks one by one from the initial block height, and after obtaining all the blocks, in order to determine the transaction data of each block, the application can also count the number of transactions in the block, so as to understand the transaction data of each block.

[0178] Step S404, according to the number of transactions in the block, record the state of the transaction data in the block as successfully processed data.

[0179] Specifically, due to the characteristics of the block chain, the transaction data recorded in the block is all successfully processed data.

[0180] As introduced above, after the delay waiting ends, the application can obtain the subsequent blocks one by one from the initial block height, and after obtaining all the blocks, count the number of transactions in the block.

[0181] Further, after determining the number of transactions in the block, according to the number of transactions in the block, the state of the transaction data in the block is recorded as successfully processed data, so that whether there is a zero transaction block can be judged according to the state of the transaction data in the block as successfully processed data.

[0182] Step S405, according to the state of the transaction data in the block as successfully processed data, to judge whether there is a zero transaction block.

[0183] Specifically, due to the characteristics of the block chain, the transaction data recorded in the block is all successfully processed data.

[0184] Because the way the block chain confirms transaction data is to generate blocks, when a 0 transaction block is encountered, it means that the data processing on the block chain is complete, that is, all the data of this round of test is processed.

[0185] Therefore, if it is determined that there is a zero transaction block, step S406 can be executed.

[0186] Step S406, determine that all data of the blockchain is completed, and configure the completion threshold of the blockchain network as the zero transaction block.

[0187] Specifically, as known from the above description, since the way of the blockchain to confirm the transaction data is to generate a block, when the zero transaction block is encountered, it means that the data on the blockchain has been processed and completed, and all data of the current round of testing at the current time in the block network has been processed.

[0188] Therefore, if it is determined that there is a zero transaction block, it can be determined that all data of the blockchain is completed, and the completion threshold of the blockchain network is configured as the zero transaction block.

[0189] Further, the total number of data whose transaction data in the block is successfully processed can also be recorded, so that the "correctness" index in the final test report can be calculated by the total number of data whose transaction data in the block is successfully processed.

[0190] For example, as shown in Figure 3 , the test case A is completed, and the test case B is started.

[0191] When each coroutine group in the coroutine group of the test case A has completed the corresponding work, the embodiment of the application can set the completion threshold of the test case A, and confirm that the process of the test case B can be entered.

[0192] And after the process of the test case B is also completed, after the waiting delay time ends, the completion threshold configuration is performed on the blockchain network.

[0193] The response processor can parse the block data of the target network node of the blockchain and generate a test report of the target network node of the blockchain.

[0194] In actual application process, the purpose of block data analysis is to count the number of successfully processed transactions; the test report is to present according to the calculation result of related data.

[0195] The test report is output according to each test case, and the report content includes TPS, CTPS, correctness, minimum delay time, average delay time, and maximum delay time. The calculation method of each test index is as follows:

[0196] (1) TPS: (number of coroutines x number of requests each coroutine needs to complete) / (0 transaction block generation time-first transaction sending time)

[0197] (2) CTPS: (number of coroutines x number of requests each coroutine needs to complete) / (0 transaction block generation time-first transaction response time)

[0198] (3) Correctness: the number of successful transactions / (the number of coroutines x the number of requests each coroutine needs to complete)

[0199] (4) Minimum latency: min(response time of each request)

[0200] (5) Average latency: the sum of all request response times / (the number of coroutines x the number of requests each coroutine needs to complete)

[0201] (6) Maximum latency: max(response time of each request)

[0202] As can be seen from the above technical solutions, the test system provided by the embodiments of the present application can be independently run without relying on a working environment and can be applied to different system environments; one-key automatic performance testing of a block link interface can be completed without secondary requests and confirmation actions, the process of block link interface testing is simplified, the performance testing of the block link interface can be completed faster, the needs of the block chain asynchronous interface testing process can be better met, in addition, the performance of the block link interface testing can be improved, different files can be configured according to application scenarios, the generality is relatively strong, and process data generated during the performance testing of the block link interface and a test result report finally generated can be recorded.

[0203] Further, the present application further includes a block link interface testing method, which can be applied to the block link interface testing system described above, and the implementation steps of the block interface testing method can include the following:

[0204] Step S501, the launcher is started to send a start signal, the block link interface testing system is initialized, and a request is sent to a target node of a block chain network, wherein the request is to obtain a block height in a current network and cache the block in a memory, and the block is marked as an initial block.

[0205] Step S502, the configuration reader is called to read a target configuration file from a preset storage path, wherein the target configuration file is used to provide configuration parameters for the launcher, the request generator, the threshold detector, and the response processor.

[0206] Step S503, after the request generator receives the start signal of the block link interface testing system, initialization is generated, connection pooling is performed during the initialization, and each coroutine is processed in parallel.

[0207] Step S504, the threshold detector is called to configure a completion threshold for a coroutine group and configure a completion threshold for a block chain network.

[0208] Step S505: Call the response processor to parse the block data of the blockchain target network node and generate a test report for the blockchain target network node.

[0209] The specific processing flow for blockchain interface testing methods can be found in the previous section on blockchain interface testing systems, and will not be repeated here.

[0210] The blockchain interface testing method and system provided in this application can be applied to blockchain interface testing equipment, such as terminals like mobile phones and computers. Optionally, Figure 4 The hardware structure block diagram of the blockchain interface testing device is shown below. Figure 4 The hardware structure of a blockchain interface testing device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4.

[0211] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3 and communication bus 4 is at least one, and processor 1, communication interface 2 and memory 3 communicate with each other through communication bus 4.

[0212] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0213] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0214] The memory stores a program, and the processor can call the program stored in the memory. The program is used to implement the various processing flows in the aforementioned terminal blockchain interface testing scheme.

[0215] This application embodiment also provides a readable storage medium that can store a program suitable for processor execution, the program being used to: implement the various processing flows of the aforementioned terminal in the blockchain interface testing scheme.

[0216] Finally, it should be noted that the terms "first", "second", and the like, herein do not denote any order, quantity, combination, or importance, but rather are used to distinguish one element from another, and are not intended to denote the presence of any such actual relationship or order. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0217] The various embodiments in the specification are described with progression in this order of description. Embodiments of each order of description can be combined with embodiments of the other orders of description.

[0218] The above description of disclosed embodiments provides enabling teaching for a person skilled in the art to realize or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. The various embodiments can be combined with each other. Therefore, the present application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A block chain interface testing system, characterized by, The system comprises a starter, a configuration reader, a request generator, a threshold detector and a response processor; Wherein, The starter sends a start signal after starting to initialize the block chain interface test system and simultaneously sends a request to the target node of the block chain network, wherein the request is to obtain the block height in the current network and cache the block in the memory, and the block is marked as an initial block; The configuration reader reads a target configuration file from a preset storage path, wherein the target configuration file is used to provide configuration parameters for the starter, the request generator, the threshold detector and the response processor; The request generator receives the start signal of the block chain interface test system, generates an initialization, and performs connection pooling during the initialization process, and simultaneously processes the coroutines in parallel; The threshold detector is responsible for the completion threshold configuration of the coroutine group and the completion threshold configuration of the block chain network; The response processor analyzes the block data of the target block chain network node and generates a test report of the target block chain network node; The process of the threshold detector for the completion threshold configuration of the block chain network comprises: After all the coroutine group processes are completed, the delay waiting time is determined according to the time parameter of the waiting block in the configuration item system work limit; After the delay waiting ends, the subsequent blocks are obtained one by one from the initial block height; The number of transactions in the block is counted; According to the number of transactions in the block, the state of the transaction data recorded in the block is the successfully processed data; According to the successfully processed data of the transaction data in the block, it is judged whether there is a zero transaction block; If it is determined that there is a zero transaction block, it is determined that all the data of the block chain has been completed, and the completion threshold of the block chain network is configured as meeting the zero transaction block.

2. The system of claim 1, wherein, The target configuration file comprises: Node connection information, block chain interface test system work limit information, block chain network threshold information, block chain basic interface configuration information and test case configuration information.

3. The system of claim 1, wherein, The process of the request generator for connection pooling during the initialization process comprises: A target object pool is constructed; The capacity of the target object pool is initialized to a preset threshold; It is judged whether there is a request for using an object; If an object is needed, a target object is created and the request is bound to the corresponding website of the request using the target object; It is judged whether the number of objects in the target object pool exceeds the preset threshold; If the number of objects in the target object pool exceeds the preset threshold, the remaining objects in the target object pool that exceed the preset threshold are recycled.

4. The system of claim 1, wherein, The process of the request generator for parallel processing of each coroutine comprises: When a target test case enters the execution queue, the request generator initializes the number of concurrent coroutines in the target test case configuration to a corresponding number of target coroutines; All target coroutines are executed in parallel, wherein the execution flow of each target coroutine is consistent; record the response results of all requests of the coroutines as the test report data evidence of the target test case, wherein each response result of a request includes a request time, a response time, and a response result.

5. The system of claim 1, wherein, The threshold detector performs the process of configuring the completion threshold for the coroutine group, including: collecting the feedback results of each request in each coroutine group, wherein the feedback results of each request in each coroutine group include original responses representing three types of results of the blockchain network, i.e., request success, request failure, and request timeout; comparing the total number of all feedback results with the product of the number of concurrent coroutines and the number of requests required to be completed by each coroutine set in the test case configuration; determining whether to enter the next test case process according to the comparison result of the feedback results of each request in each coroutine group and the product of the number of concurrent coroutines and the number of requests required to be completed by each coroutine set in the test case configuration; if the total number of feedback results is less than the product of the number of concurrent coroutines and the number of requests required to be completed by each coroutine set in the test case configuration, it is determined that the current test case process is not completed, and the remaining response results are continued to be waited for; if the total number of feedback results is equal to the product of the number of concurrent coroutines and the number of requests required to be completed by each coroutine set in the test case configuration, it is determined that the current test case process is completed, and the completion threshold of the coroutine group is configured as the product of the number of concurrent coroutines and the number of requests required to be completed by each coroutine set in the test case configuration.

6. A method of block chain interface testing, the method comprising: The blockchain interface test system of claims 1-5, the system comprising: a starter, a configuration reader, a request generator, a threshold detector, and a response processor; wherein, the starter is started to send a start signal to initialize the blockchain interface test system, and at the same time, send a request to the target node of the blockchain network, wherein the request is to request the block height in the current network and cache the block in the memory, and at the same time, mark the block as an initial block; the configuration reader is called to read a target configuration file from a preset storage path, wherein the target configuration file is used to provide configuration parameters for the starter, the request generator, the threshold detector, and the response processor; the request generator is called to generate an initialization after receiving the start signal of the blockchain interface test system, and at the same time, perform connection pooling and parallel processing of each coroutine during the initialization process; the threshold detector is called to configure the completion threshold for the coroutine group and the blockchain network; the response processor is called to analyze the block data of the target blockchain network and generate a test report of the target blockchain network; the threshold detector performs the process of configuring the completion threshold for the blockchain network, including: after all the coroutine group processes are completed, a delay waiting time is determined according to a time parameter of waiting for a block in the configuration item system working limit; after the delay waiting ends, subsequent blocks are obtained one by one from the initial block height; the number of transactions in the block is counted; according to the number of transactions in the block, the state of the transaction data in the block is recorded as successfully processed data; Determine whether there is a zero transaction block according to the state of transaction data in the block being successfully processed; If it is determined that there is a zero transaction block, it is determined that all data of the blockchain has been completed, and the completion threshold of the blockchain network is configured to meet the zero transaction block.

7. The method of claim 6, wherein, The target configuration file includes: Node connection information, the blockchain interface test system working limit information, the blockchain network threshold information, the blockchain basic interface configuration information, and the configuration information of the test case.

8. A block interface test device, characterized by Comprise: One or more processors, and a memory; The memory stores computer readable instructions, and the computer readable instructions are executed by the one or more processors to implement the steps of the blockchain interface test method according to any one of claims 6 to 7.

9. A readable storage medium characterized by: The readable storage medium stores computer readable instructions, and the computer readable instructions are executed by one or more processors to make one or more processors implement the steps of the blockchain interface test method according to any one of claims 6 to 7.

Images