Test method and device based on block chain and computer equipment

Abstract

The invention is suitable for the technical field of block chains, and provides a test method and device based on a block chain and computer equipment, the test method is executed by a test system, and the test system comprises a test main node, a plurality of middleware and at least one agent node. The middleware is used for carrying out data transmission between the test master node and the proxy node, and the test method comprises the following steps: issuing a test event; target middleware matched with the test event is selected from the multiple pieces of middleware, and test data corresponding to the test event are obtained from the selected target middleware under the condition of preset test parameters; adjusting the preset test parameters according to the test data and a preset test data threshold value; and applying the adjusted preset test parameters to a test corresponding to the test event. Through the scheme, the problem that real-time feedback cannot be performed to dynamically adjust the test strategy can be solved.

Description

Technical Field

[0001] The present application belongs to the field of blockchain technology, and in particular, relates to a testing method, device and computer equipment based on blockchain. Background Art

[0002] In blockchain, message push is an important means to achieve communication and data synchronization between nodes. In decentralized applications (DApp), such as decentralized finance (DeFi) and decentralized social networks (DSN), message push is usually used to notify off-chain systems or other nodes when on-chain events occur to ensure the consistency of system status and the real-time user experience. However, the test of message push in blockchain usually cannot adjust the test parameters during the test according to the actual test situation, that is, there is a problem that cannot provide real-time feedback to dynamically adjust the test strategy, which needs to be solved urgently. Summary of the invention

[0003] The purpose of this application is to provide a blockchain-based testing method, device and computer equipment, aiming to solve the problem of being unable to provide real-time feedback to dynamically adjust the testing strategy.

[0004] A first aspect of an embodiment of the present application provides a blockchain-based testing method, the testing method being performed by a testing system, the testing system comprising a testing master node, a plurality of middlewares, and at least one proxy node, the middleware being used to perform data transmission between the testing master node and the proxy node, the testing method comprising:

[0005] Publish a test event;

[0006] Selecting a target middleware adapted to the test event from the plurality of the middlewares, and acquiring test data corresponding to the test event from the selected target middleware under preset test parameter conditions;

[0007] Adjusting the preset test parameters according to the test data and the preset test data threshold;

[0008] Apply the adjusted preset test parameters to the test corresponding to the test event.

[0009] In an optional embodiment, the selecting a target middleware adapted to the test event from the plurality of middlewares comprises:

[0010] Obtaining event parameters corresponding to the test event;

[0011] Determine the middleware type and middleware parameters corresponding to the test event according to the event parameters;

[0012] Based on the middleware type and the middleware parameter, a target middleware adapted to the test event is determined from among the plurality of middlewares.

[0013] In an optional embodiment, adjusting the preset test parameter according to the test data and a preset test data threshold includes:

[0014] comparing the test data with a preset test data threshold;

[0015] When the test data does not meet the preset test data threshold requirement, the preset test parameter is adjusted.

[0016] In an optional embodiment, when the test data does not meet the preset test data threshold requirement, adjusting the preset test parameter includes:

[0017] Input the test data into a machine learning model, and the machine learning model outputs test parameters corresponding to the test data based on a historical test data set;

[0018] The preset test parameters are adjusted to the test parameters corresponding to the test data.

[0019] In an optional embodiment, the issuing of a test event includes:

[0020] Deploy smart contracts in the blockchain;

[0021] The test master node initiates a user transaction simulation event, and the user transaction simulation event is used to trigger the smart contract;

[0022] A test event corresponding to the user transaction simulation event is generated through the smart contract and published to the middleware.

[0023] In an optional embodiment, the test system includes a plurality of proxy nodes, and after selecting a target middleware adapted to the test event from the plurality of middlewares, the test method further includes:

[0024] The selected target middleware receives the test event published by the smart contract and distributes the test event to each agent node, so that each agent node feeds back a message of receiving the test event to the test master node.

[0025] In an optional embodiment, after adjusting the preset test parameter according to the test data and the preset test data threshold, the method further includes:

[0026] Obtaining on-chain and off-chain test data of the blockchain;

[0027] Analyze the test data and generate data analysis results;

[0028] The data analysis results are input into the machine learning model, and the machine learning model outputs the test parameters corresponding to the next test process.

[0029] A second aspect of an embodiment of the present application provides a blockchain-based testing device, the testing device comprising:

[0030] A publishing module, used for publishing a test event;

[0031] An acquisition module, used to select a target middleware adapted to the test event from a plurality of middlewares, and acquire test data corresponding to the test event from the selected target middleware under preset test parameter conditions;

[0032] An adjustment module, used for adjusting the preset test parameters according to the test data and the preset test data threshold;

[0033] The test module is used to apply the adjusted preset test parameters to the test corresponding to the test event.

[0034] A third aspect of an embodiment of the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in the first aspect when executing the computer program.

[0035] A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in the first aspect is implemented.

[0036] A fifth aspect of the embodiments of the present application provides a computer program product. When the computer program product is run on a terminal device, the terminal device executes the method described in the first aspect.

[0037] Beneficial effects of this application

[0038] By adopting the blockchain-based testing method, apparatus and computer equipment provided by the present application, multiple middlewares are set and target middleware that is adapted to the test event is selected from the multiple middlewares for testing, thereby avoiding the problem of too small a test scope caused by the existing testing technology that only supports a single middleware; in addition, under the preset test parameter conditions, the selected target middleware is monitored in real time, and the test data corresponding to the test event is obtained therefrom, and the preset test parameters are adjusted in combination with the preset test data threshold, thereby realizing real-time dynamic adjustment of the test strategy and flexibly responding to the ever-changing network environment and load conditions. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0040] Figure 1 One of the flowcharts of a blockchain-based testing method provided in an embodiment of the present application;

[0041] Figure 2 A flowchart of a blockchain-based testing method provided in an embodiment of the present application;

[0042] Figure 3 Flowchart 3 of a blockchain-based testing method provided in an embodiment of the present application;

[0043] Figure 4 A fourth flowchart of a blockchain-based testing method provided in an embodiment of the present application;

[0044] Figure 5 Flowchart 5 of a blockchain-based testing method provided in an embodiment of the present application;

[0045] Figure 6 Flowchart 6 of a blockchain-based testing method provided in an embodiment of the present application;

[0046] Figure 7 Flowchart 7 of a blockchain-based testing method provided in an embodiment of the present application;

[0047] Figure 8 Flowchart 8 of a blockchain-based testing method provided in an embodiment of the present application;

[0048] Fig. 9 A schematic diagram of the structure of a blockchain-based testing device provided in an embodiment of the present application;

[0049] Fig.10 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0051] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0052] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0053] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0054] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0055] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0056] It should be understood that the size of the serial numbers of the steps in this embodiment does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0057] In blockchain, message push is an important means to achieve communication and data synchronization between nodes. It is usually used to notify off-chain systems or other nodes when on-chain events occur to ensure the consistency of system status and the real-time user experience. However, the test of message push in blockchain is usually unable to adjust the test parameters during the test according to the actual test situation, that is, there is an urgent problem of being unable to provide real-time feedback to dynamically adjust the test strategy. In this regard, the present application provides a test method, device and computer equipment based on blockchain.

[0058] In order to illustrate the technical solution of the present application, specific embodiments are provided below.

[0059] Figure 1 A flowchart of a blockchain-based testing method provided in an embodiment of the present application is shown. Figure 1 The test method provided in the embodiment of the present application is executed by a test system, which includes a test master node, multiple middlewares and at least one proxy node. The test method specifically includes the following steps:

[0060] Step S101: Publish a test event;

[0061] Step S102: selecting a target middleware adapted to the test event from the plurality of middlewares, and acquiring test data corresponding to the test event from the selected target middleware under preset test parameter conditions;

[0062] Step S103: adjusting the preset test parameters according to the test data and the preset test data threshold;

[0063] Step S104: applying the adjusted preset test parameters to the test corresponding to the test event.

[0064] Among them, the test event in step S101 is used to simulate different types of on-chain activities, such as message sending, transaction submission, etc., and the test event is released to facilitate the acquisition of subsequent test data. The preset test parameters in step S102 refer to the parameters set before the test to control the test process or conditions, which may specifically include test frequency, node distribution or load intensity, etc.; the middleware is used to transmit data between the test master node and the agent node, and can specifically use RabbitMQ, Kafka and other message queues for data push. Taking Kafka as the push stream scenario as an example, the middleware is used as a bridge connecting the master node, the agent node and other system components to ensure the reliable delivery of tasks and test results; step S102 can specifically select the target middleware that can handle the test event from multiple middlewares according to the type and nature of the test event, and use the middleware monitor to continuously monitor under the preset test parameter conditions to obtain the test data corresponding to the test event in the target middleware, which is used as the basis for subsequent adjustment operations; it should be noted that the test data may specifically include indicators such as transaction delay time, network throughput, block generation time, network delay time and node status.

[0065] Step S103 compares the test data obtained from the target middleware with the preset test data threshold, and determines whether the test data meets the expected standards based on the comparison results. If not, the preset test parameters are adjusted according to the specific situation to optimize the test conditions and more effectively simulate different load conditions and network environments; in step S104, the adjusted preset test parameters are applied to the test environment to ensure the effective implementation of the test service.

[0066] Exemplarily, an "order creation" test event is published in the blockchain, and the middleware required for this test and its corresponding encryption protocol are selected as Kafka-SSL according to the test event. The test event is sent to the proxy node through the middleware, and the middleware monitor is used to obtain test data such as transaction delay time, network throughput, and node status during the sending process. The above test data is compared with the preset test data threshold, and the comparison result is used to adjust the data, and the adjusted preset test parameters are applied to the test corresponding to the test event.

[0067] In this embodiment of the present application, a target middleware that is adapted to the test event is selected from multiple middlewares for testing, thereby avoiding the problem of too small a test scope caused by only supporting a single middleware in existing testing technologies. In addition, under preset test parameter conditions, the selected target middleware is monitored in real time, and test data corresponding to the test event is obtained therefrom. The preset test parameters are adjusted in combination with the preset test data thresholds, thereby achieving real-time dynamic adjustment of the test strategy and flexible response to changing network environments and load conditions.

[0068] Reference Figure 2 In an embodiment that can be implemented in this application, step S101 specifically includes the following steps:

[0069] Step S1011: deploying smart contracts in the blockchain;

[0070] Step S1012: The test master node initiates a user transaction simulation event, and the user transaction simulation event is used to trigger the smart contract;

[0071] Step S1013: Generate a test event corresponding to the user transaction simulation event through the smart contract and publish it to the middleware.

[0072] Among them, step S1011 deploys the smart contract to the blockchain, and the smart contract can respond to specific transactions or events. In step S1012, the test master node initiates a user transaction simulation event to simulate the scenario of the user conducting transactions or performing operations on the blockchain, and the user transaction simulation event can trigger the execution of the smart contract. After the smart contract is triggered in step S1013, a test event corresponding to the user transaction simulation event is generated and published to the middleware, and the middleware transmits the data corresponding to the test event to the proxy node to ensure that all subscribers can receive notification of the test event in real time.

[0073] Exemplarily, a specific smart contract is deployed on the chain as an event generator. The test master node submits a user transaction simulation event that meets the trigger condition of "Executing Contract Contract-A" on the blockchain, such as simulating a user initiating a new buy or sell order. After the smart contract is triggered, it will generate and broadcast a specific "Order Creation" test event. The test event contains important order information, such as order ID, user address, transaction pair, price, quantity, etc. The smart contract publishes the test event to the middleware, and the middleware transmits the data corresponding to the test event to the proxy node to ensure that all subscribers can receive notifications of the test event in real time.

[0074] In this embodiment of the present application, by deploying a smart contract as an event generator, a series of predefined test events (such as message sending, transaction submission, etc.) can be generated after the trigger conditions are met, simulating various user behaviors in the blockchain, and can also simulate a variety of usage scenarios, such as high-frequency trading, node failures, network partitions, etc. By executing these events through automated scripts, the test system can dynamically evaluate their impact on network performance and stability, and provide data support for system optimization.

[0075] In the embodiments that can be implemented in this application, refer to Figure 3The step S102 of selecting a target middleware adapted to the test event from the plurality of middlewares may specifically include the following steps:

[0076] Step S1021: Obtain event parameters corresponding to the test event;

[0077] Step S1022: determining the middleware type and middleware parameters corresponding to the test event according to the event parameters;

[0078] Step S1023: Based on the middleware type and the middleware parameters, determine a target middleware that is adapted to the test event from among the plurality of middlewares.

[0079] Among them, the event parameters in step S1021 refer to the specific information or attributes contained in the test event. These parameters define the type and nature of the event, etc., and are used to distinguish different events and determine their processing logic. Step S1021 obtains the event parameters of the test event to provide necessary input information for subsequent steps. The middleware type in step S1022 refers to the type of middleware classified according to function, purpose or technical architecture, etc. Different middleware types are suitable for processing different types of test events. The middleware parameters refer to the specific parameters or configurations that the middleware needs to follow or rely on when processing the test event. Specific middleware parameters may include encryption protocols, processing speeds, capacity limits, and interface specifications, etc. Step S1022 determines the corresponding middleware type and middleware parameters according to the type, nature and other characteristics of the event by analyzing the event parameters, and ensures that the selected middleware type and parameters can meet the processing requirements of the test event by comprehensively considering the overall architecture and performance requirements of the test system. Step S1023 screens the available middleware set according to the determined middleware type and middleware parameters, evaluates the applicability of each candidate middleware, and selects the middleware that best meets the test event processing requirements as the target middleware.

[0080] Through the above steps, the middleware adapted to the test event can be effectively and accurately selected to ensure the smooth progress of the test process and the accuracy of the test results.

[0081] It should be noted that the middleware and encryption protocol corresponding to the test event can be obtained by parsing the configuration file, and the corresponding middleware services can be automatically deployed to ensure the normal operation and communication of these services.

[0082] Exemplarily, the middleware and encryption protocol required by the test event specified in the configuration file, namely Kafka-SSL, are used to automatically deploy and manage the Kafka service, while ensuring the correct configuration of the SSL encryption protocol to protect the security of data transmission.

[0083] In the embodiments that can be implemented in this application, in order to ensure that the test system can run stably under high load and concurrent scenarios, it is necessary to set up multiple proxy nodes in the test system. Figure 4 After step S102, the testing method provided in the embodiment of the present application further includes the following steps:

[0084] Step S201: The selected target middleware receives the test event published by the smart contract and distributes the test event to each agent node, so that each agent node feeds back the message of receiving the test event to the test master node.

[0085] By setting up multiple proxy nodes, the test system can run test tasks in parallel on multiple nodes. The proxy nodes work together with the test master node to ensure the effectiveness and stability of test tasks in high-load and concurrent scenarios through efficient message queues and load balancing mechanisms. At the same time, the test system can support on-demand expansion of test proxy nodes to meet larger-scale testing needs.

[0086] In the embodiments that can be implemented in this application, refer to Figure 5 Step S103 may specifically include the following steps:

[0087] Step S1031: comparing the test data with a preset test data threshold;

[0088] Step S1032: When the test data does not meet the preset test data threshold requirement, adjust the preset test parameters.

[0089] For details, please refer to Figure 6 When the test data does not meet the preset test data threshold requirements, the test data can be input into a machine learning model, which will output test parameters corresponding to the test data based on the historical test data set, and then adjust the above preset test parameters to the test parameters corresponding to the test data.

[0090] Exemplarily, the test starts by sending transactions to each blockchain node at a transaction sending rate of 100TPS. Through real-time monitoring, it is detected that the transaction delay time in the current test data begins to increase, with a specific value of 3s, and the network throughput decreases. The system feedback believes that the blockchain network is close to the load limit, and the preset test data threshold corresponding to the transaction delay time is 2s. By comparison, it can be seen that the test data does not meet the requirements of the preset test data threshold. Therefore, the test data is input into the machine learning model. The machine learning model predicts based on the historical test data set that if the load continues to increase, the transaction delay will further increase and may cause node overload. Therefore, the model outputs that the transaction sending rate corresponding to the current test data should be 80TPS. Therefore, the transaction sending rate is adjusted from 100TPS to 80TPS to relieve the pressure.

[0091] By comparing the test data with the preset test data threshold and combining it with the machine learning model, the preset test parameters can be adjusted in a targeted manner, which can ensure the effectiveness and stability of the test task under high load and concurrent scenarios.

[0092] In the embodiments that can be implemented in this application, refer to Figure 7 After step S103, the test method provided in the embodiment of the present application further includes the following steps:

[0093] Step S301: Acquire on-chain and off-chain test data of the blockchain;

[0094] Step S302: Analyze the test data and generate data analysis results;

[0095] Step S303: Input the data analysis results into the machine learning model, and the machine learning model outputs the test parameters corresponding to the next test process.

[0096] Specifically, by collecting and analyzing on-chain and off-chain test data, a detailed test report is generated, which includes data analysis results on order data processing efficiency, response time, network performance, etc. The test system is iteratively optimized using the data analysis results, that is, the data analysis results are input into the machine learning model, and the machine learning model outputs the test parameters corresponding to the next test process, thereby automatically adjusting the test parameters for the next round of testing to ensure that the test system continuously improves its accuracy and reliability.

[0097] For ease of understanding, the following is an introduction to the test method provided in the embodiment of the present application in conjunction with a complete example. Figure 8 As shown, a flow chart of a testing method provided in an embodiment of the present application is shown. Figure 8The test process shown is based on the test methods introduced in the above-mentioned various method embodiments, and is an example of a test method process implemented by the cooperation of various modules, units or components on and off the chain. Figure 8 The process of implementing the testing method provided in the embodiment of the present application mainly involves an on-chain event generator, a middleware adaptation and automated deployment module, a middleware monitor, a dynamic testing strategy adjustment module, a highly scalable testing agent module, and an analysis and iterative feedback module.

[0098] The role of the on-chain event generator is to deploy a specific smart contract on the chain as an event generator before the test begins. The contract is used to generate a series of predefined events (such as message sending, transaction submission, etc.) to simulate various user behaviors in the decentralized network. The event generator can also be used to simulate a variety of usage scenarios, such as high-frequency trading, node failures, network partitions, etc. By executing these events through automated scripts, the system can dynamically evaluate their impact on network performance and stability.

[0099] The role of the middleware adaptation and automatic deployment module is to provide the adaptation interface of the middleware and encryption protocol, and support the automatic deployment of the required middleware services through the configuration file. The system parses the required middleware type and its parameters according to the configuration file, automatically deploys the corresponding middleware services, and ensures the normal operation and communication of these services.

[0100] The middleware monitor can connect to the blockchain network, monitor the events triggered by the on-chain event generator in real time, and generate corresponding test data based on the event type and test strategy.

[0101] The role of the dynamic test strategy adjustment module is that the system has designed a dynamic feedback mechanism to continuously monitor key indicators during the test process (such as transaction latency, network throughput, node status, etc.). Based on the feedback data, the machine learning model or rule engine is used to automatically adjust the test strategy, such as changing the load intensity, node distribution or test frequency, to more accurately simulate the behavior in the real environment.

[0102] The role of the highly scalable test agent module is that, through the distributed test agent architecture, the system can run test tasks in parallel on multiple nodes. The agent nodes work together with the main node to ensure the effectiveness and stability of test tasks in high-load and concurrent scenarios through efficient message queues and load balancing mechanisms. At the same time, the system supports on-demand expansion of test agent nodes to meet larger-scale testing needs.

[0103] The role of the analysis and iterative feedback module is to collect all data from the middleware monitor and the off-chain test agent, including message delivery delays, packet loss rates, security vulnerabilities, etc. The module performs statistical analysis on this data, generates a comprehensive test report, and provides real-time feedback to the middleware monitor to adjust the test strategy. For example, the frequency of message sending or the size of the data packet can be dynamically adjusted to simulate different load conditions. According to the results of the analysis and feedback module, the test process is iterated to gradually optimize the performance and security of message push in the decentralized network. Through multiple iterations, different aspects of message push (such as real-time, reliability, security, etc.) can be comprehensively evaluated, and data support can be provided for system optimization.

[0104] Taking "Using middleware to adapt Kafka-SSL encryption protocol in blockchain" as an example, the execution process of the test method provided by this application is further explained. First of all, it involves the generation and triggering of events on the chain. In the smart contract of the blockchain, when the user, that is, the test master node, initiates a new buy and sell order (such as a limit order or a market order), the smart contract will generate and broadcast a specific "order creation" event, which contains important order information, such as order ID, user address, transaction pair, price, quantity, etc. The smart contract publishes this event in the blockchain network through a preset event interface to ensure that all subscribers (such as middleware monitors and proxy nodes) can receive notifications of this event in real time; in order to ensure the safe and smooth transmission of data, it is necessary to automatically deploy and manage the Kafka service according to the middleware and encryption protocol required for this test specified in the configuration file, that is, Kafka-SSL, and ensure the correct configuration of the SSL encryption protocol to protect the security of data transmission. Next, the middleware monitor will continue to listen to the "order creation" event on the chain. When the event is detected, the monitor will immediately capture the event data (including order ID, user address, transaction pair, price, quantity, etc.), and standardize the captured event data according to the predefined test strategy as a comparison basis for test verification, that is, to parse the captured data, remove invalid, duplicate or erroneous data, and ensure the accuracy and completeness of the data, which will be used as a basis for verifying whether the test data obtained during the actual test process is correct. The test system sets up a large number of distributed proxy nodes to receive order data from the Kafka channel to ensure stable operation under high load and concurrent scenarios. The middleware monitor monitors the performance data (such as response time, network delay, etc.) in the entire test process, and dynamically adjusts the test strategy, that is, the test parameters, according to real-time feedback information. For example, if the system load is too high at a certain moment, the frequency of Kafka message sending can be reduced, or the number of Kafka partitions and message processing threads can be adjusted. A detailed test report is generated by collecting and analyzing the test data on and off the chain. The report includes analysis results on order data processing efficiency, response time, network performance, etc. This module uses the analysis results to iteratively optimize the system and automatically adjust the parameters and strategies for the next round of testing to ensure that the test system continuously improves its accuracy and reliability.

[0105] In this example, the system modifies the configuration file according to the test requirements, realizes the automatic deployment of Kafka middleware adapted to the SSL encryption protocol, and provides a stable middleware environment for the current test. When the smart contract in the blockchain triggers the "order creation" event, the middleware monitor captures the event in time to verify the correctness and performance of the message pushed by the tested module. The whole process involves on-chain event generation, event data capture and transmission, off-chain data processing and display, dynamic strategy adjustment and test result analysis, thus realizing a full range of testing for transaction order management.

[0106] Fig. 9 A schematic diagram of the structure of a blockchain-based testing device provided in an embodiment of the present application. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0107] The test device may specifically include the following modules:

[0108] Publishing module 901, used to publish a test event;

[0109] An acquisition module 902 is used to select a target middleware adapted to the test event from a plurality of middlewares, and acquire test data corresponding to the test event from the selected target middleware under a preset test parameter condition;

[0110] An adjustment module 903, configured to adjust the preset test parameters according to the test data and a preset test data threshold;

[0111] The testing module 904 is used to apply the adjusted preset test parameters to the test corresponding to the test event.

[0112] Specifically, a test event is published through the publishing module 901 to simulate different types of on-chain activities to facilitate the subsequent acquisition of test data; a target middleware that can handle the test event is selected from multiple middlewares according to the type and nature of the test event through the acquisition module 902, and under the preset test parameter conditions, the middleware monitor is used for continuous monitoring to obtain the test data corresponding to the test event in the target middleware, which is used as the basis for subsequent adjustment operations; the test data obtained from the target middleware through the adjustment module 903 is compared with the preset test data threshold, and it is determined whether the test data meets the expected standards based on the comparison result. If not, the preset test parameters are adjusted according to the specific situation to optimize the test conditions and more effectively simulate different load conditions and network environments; the adjusted preset test parameters are applied to the test environment through the test module 904 to ensure the effective implementation of the test service.

[0113] Through the above-mentioned testing device, a target middleware adapted to the test event is selected from multiple middlewares for testing, thereby avoiding the problem of too small a test scope caused by only supporting a single middleware in existing testing technologies. In addition, under the preset test parameter conditions, the selected target middleware is monitored in real time, and the test data corresponding to the test event is obtained therefrom. The preset test parameters are adjusted in combination with the preset test data threshold, so that the test strategy can be adjusted in real time and flexibly respond to the ever-changing network environment and load conditions.

[0114] Fig.10 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. The computer device 1001 includes: at least one processor 1002 ( Fig.10 (only one is shown in the figure) a processor, a memory 1003, and a computer program 1004 stored in the memory 1003 and executable on the at least one processor 1002, such as a blockchain-based test program. When the processor 1002 executes the computer program 1004, the steps in the above-mentioned blockchain-based test method embodiment are implemented, such as Figure 1 Alternatively, when the processor 1002 executes the computer program 1004, the functions of each module / unit in the above-mentioned device embodiments are implemented, for example Fig.10 The functions of units 1001 to 1004 are shown.

[0115] Exemplarily, the computer program 1004 may be divided into one or more modules / units, which are stored in the memory 1003 and executed by the processor 1002 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 1004 in the computer device 1001. For example, the computer program 1004 may be divided into a publishing module, an acquisition module, an adjustment module, and a testing module, and the specific functions of each program module are as follows:

[0116] A publishing module, used for publishing a test event;

[0117] An acquisition module, used to select a target middleware adapted to the test event from the plurality of the middlewares, and acquire test data corresponding to the test event from the selected target middleware under preset test parameter conditions;

[0118] An adjustment module, used for adjusting the preset test parameters according to the test data and the preset test data threshold;

[0119] The test module is used to apply the adjusted preset test parameters to the test corresponding to the test event.

[0120] The computer device 1001 may be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The computer device may include, but is not limited to, a processor 1002 and a memory 1003. Those skilled in the art will appreciate that Fig.10 The computer device 1001 is merely an example and does not constitute a limitation on the computer device 1001 . The computer device 1001 may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the computer device 1001 may also include input and output devices, network access devices, etc.

[0121] The processor 1002 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0122] In some embodiments, the memory 1003 may be an internal storage unit of the computer device 1001, such as a hard disk or memory of the computer device 1001. In other embodiments, the memory 1003 may also be an external storage device of the computer device 1001, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the computer device 1001. Further, the memory 1003 may also include both an internal storage unit of the computer device 1001 and an external storage device. The memory 1003 is used to store an operating system, an application program, a boot loader (Boot Loader), data and other programs, such as the program code of the computer program, etc. The memory 1003 may also be used to temporarily store data that has been output or is to be output.

[0123] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0124] In the above embodiments, the description of each embodiment has its own emphasis. If a rated part is not described or recorded in detail in a certain embodiment, reference may be made to the relevant description of other embodiments.

[0125] An embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0126] An embodiment of the present application provides a computer program product. When the computer program product runs on a mobile terminal, the mobile terminal can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0127] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0128] In the embodiments provided in the present application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0129] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0130] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above units may be implemented in the form of hardware or software.

[0131] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0132] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A testing method based on blockchain, characterized in that: The test method is executed by a test system, the test system includes a test main node, a plurality of middlewares and at least one agent node, the middleware is used for performing data transmission between the test main node and the agent node, and the test method includes: Publish a test event; Selecting a target middleware adapted to the test event from the plurality of the middlewares, and acquiring test data corresponding to the test event from the selected target middleware under preset test parameter conditions; Adjusting the preset test parameters according to the test data and the preset test data threshold; Apply the adjusted preset test parameters to the test corresponding to the test event.

2. The method according to claim 1, characterized in that The step of selecting a target middleware adapted to the test event from among the plurality of middlewares comprises: Obtaining event parameters corresponding to the test event; Determine the middleware type and middleware parameters corresponding to the test event according to the event parameters; Based on the middleware type and the middleware parameter, a target middleware adapted to the test event is determined from among the plurality of middlewares.

3. The method according to any one of claims 1-2, characterized in that: The adjusting the preset test parameters according to the test data and the preset test data threshold comprises: comparing the test data with a preset test data threshold; When the test data does not meet the preset test data threshold requirement, the preset test parameter is adjusted.

4. The method according to claim 3, characterized in that: When the test data does not meet the preset test data threshold requirement, adjusting the preset test parameter includes: Input the test data into a machine learning model, and the machine learning model outputs test parameters corresponding to the test data based on a historical test data set; The preset test parameters are adjusted to the test parameters corresponding to the test data.

5. The method according to claim 1, characterized in that The release of a test event includes: Deploy smart contracts in the blockchain; The test master node initiates a user transaction simulation event, and the user transaction simulation event is used to trigger the smart contract; A test event corresponding to the user transaction simulation event is generated through the smart contract and published to the middleware.

6. The method according to claim 5, characterized in that The test system includes a plurality of proxy nodes. After selecting a target middleware adapted to the test event from the plurality of middlewares, the test method further includes: The selected target middleware receives the test event published by the smart contract and distributes the test event to each agent node, so that each agent node feeds back a message of receiving the test event to the test master node.

7. The method according to claim 4, characterized in that After adjusting the preset test parameters according to the test data and the preset test data threshold, the method further includes: Obtaining on-chain and off-chain test data of the blockchain; Analyze the test data and generate data analysis results; The data analysis results are input into the machine learning model, and the machine learning model outputs the test parameters corresponding to the next test process.

8. A testing device based on blockchain, characterized in that: The testing device comprises: A publishing module, used for publishing a test event; An acquisition module, used to select a target middleware adapted to the test event from a plurality of middlewares, and acquire test data corresponding to the test event from the selected target middleware under preset test parameter conditions; An adjustment module, used for adjusting the preset test parameters according to the test data and the preset test data threshold; The test module is used to apply the adjusted preset test parameters to the test corresponding to the test event.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

10. A computer program product, when the computer program product is run on a computer device, enables the computer device to execute the method according to any one of claims 1 to 7.

Images