Blockchain-based testing method, device and computer equipment

Abstract

The application is suitable for the field of blockchain technology, and provides a test method and device based on blockchain and computer equipment. The test method is executed by a test system, the test system comprises a test master node, a plurality of middlewares and at least one agent node, the middleware is used for data transmission between the test master node and the agent node, the test method comprises the following steps: publishing a test event; selecting a target middleware suitable for the test event from a plurality of middlewares, and obtaining test data corresponding to the test event from the selected target middleware under a preset test parameter condition; adjusting the preset test parameter according to the test data and a preset test data threshold; and applying the adjusted preset test parameter to the test corresponding to the test event. Through the above scheme, the problem that the test strategy cannot be dynamically adjusted in real time can be solved.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a blockchain-based testing method, apparatus and computer equipment. Background Technology

[0002] In blockchain, push notifications are a crucial means of enabling communication and data synchronization between nodes. In decentralized applications (DApps), such as decentralized finance (DeFi) and decentralized social networks (DSNs), push notifications are typically used to notify off-chain systems or other nodes when on-chain events occur, ensuring system consistency and real-time user experience. However, testing push notifications in blockchain often lacks the ability to adjust test parameters based on actual test conditions, highlighting a critical issue that needs to be addressed: the inability to provide real-time feedback for dynamic adjustments to testing strategies. Summary of the Invention

[0003] The purpose of this application is to provide a blockchain-based testing method, apparatus, and computer equipment, which aims to solve the problem of the inability to provide real-time feedback for dynamic adjustment of testing strategies.

[0004] A first aspect of this application provides a blockchain-based testing method, which is executed by a testing system. The testing system includes a test master node, multiple middleware components, and at least one proxy node. The middleware components are used for data transmission between the test master node and the proxy node. The testing method includes:

[0005] Release a test event;

[0006] Select a target middleware that is compatible with the test event from among the multiple middlewares, and obtain the test data corresponding to the test event from the selected target middleware under preset test parameter conditions;

[0007] Adjust the preset test parameters based on the test data and the preset test data threshold;

[0008] The adjusted preset test parameters are applied to the test corresponding to the test event.

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

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

[0011] Based on the event parameters, determine the middleware type and middleware parameters corresponding to the test event;

[0012] Based on the middleware type and the middleware parameters, a target middleware that is compatible with the test event is determined from among the multiple middlewares.

[0013] In an optional embodiment, adjusting the preset test parameters based on the test data and a preset test data threshold includes:

[0014] Compare the test data with the preset test data threshold;

[0015] If the test data does not meet the preset test data threshold requirements, the preset test parameters are adjusted.

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

[0017] The test data is input into a machine learning model, which outputs the test parameters corresponding to the test data based on the historical test dataset.

[0018] Adjust the preset test parameters to the test parameters corresponding to the test data.

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

[0020] Deploying smart contracts in a blockchain;

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

[0022] The smart contract generates test events corresponding to the simulated user transactions and publishes them to the middleware.

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

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

[0025] In an optional embodiment, after adjusting the preset test parameters based on the test data and the preset test data threshold, the method further includes:

[0026] Obtain 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, which then outputs the test parameters for the next testing process.

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

[0030] The publish module is used to publish a test event;

[0031] The acquisition module is used to select a target middleware that is compatible with the test event from multiple middlewares, and to acquire the test data corresponding to the test event from the selected target middleware under preset test parameter conditions.

[0032] The adjustment module is used to adjust the preset test parameters based on the test data and the preset test data threshold.

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

[0034] A third aspect of this 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 executes the computer program to implement the method described in the first aspect above.

[0035] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0036] A fifth aspect of this application provides a computer program product that, when run on a terminal device, causes the terminal device to execute the method described in the first aspect.

[0037] Beneficial effects of this application

[0038] The blockchain-based testing method, apparatus, and computer equipment provided in this application allow for the setting of multiple middlewares. A target middleware adapted to the test event is selected from these middlewares for testing, thus avoiding the problem of limited applicability caused by existing testing technologies that only support a single middleware. Furthermore, under preset test parameters, the selected target middleware is monitored in real time to obtain test data corresponding to the test event. The preset test parameters are then adjusted based on preset test data thresholds, enabling real-time dynamic adjustment of the testing strategy to flexibly respond to constantly changing network environments and load conditions. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

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

[0041] Figure 2 A second flowchart illustrating a blockchain-based testing method provided in this application embodiment;

[0042] Figure 3 The third flowchart of a blockchain-based testing method provided for embodiments of this application;

[0043] Figure 4 A flowchart of a blockchain-based testing method provided for embodiments of this application;

[0044] Figure 5 The fifth flowchart of a blockchain-based testing method provided for embodiments of this application;

[0045] Figure 6 A flowchart of a blockchain-based testing method provided for embodiments of this application;

[0046] Figure 7 The seventh flowchart of a blockchain-based testing method provided for embodiments of this application;

[0047] Figure 8 The eighth flowchart of a blockchain-based testing method provided for embodiments of this application;

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

[0049] Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0050] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

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

[0052] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0053] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0054] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0055] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0056] It should be understood that the sequence number of each step in this embodiment does not imply 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 this application embodiment.

[0057] In blockchain, push notifications are a crucial means of communication and data synchronization between nodes. They are typically used to notify off-chain systems or other nodes when on-chain events occur, ensuring system consistency and real-time user experience. However, testing push notifications in blockchain often lacks the ability to adjust test parameters based on actual testing conditions, resulting in a lack of real-time feedback for dynamic adjustment of testing strategies. This application addresses this issue by providing a blockchain-based testing method, apparatus, and computer equipment.

[0058] To illustrate the technical solution of this application, specific embodiments are described below.

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

[0060] Step S101: Publish a test event;

[0061] Step S102: Select a target middleware that is compatible with the test event from among the multiple middlewares, and obtain the test data corresponding to the test event from the selected target middleware under preset test parameter conditions;

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

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

[0064] In step S101, the test events simulate different types of on-chain activities, such as message sending and transaction submission. Publishing these test events facilitates the acquisition of subsequent test data. The preset test parameters in step S102 refer to parameters set before testing to control the testing process or conditions. These parameters may include test frequency, node distribution, or load intensity. The middleware is used for data transmission between the test master node and the proxy node. Specifically, message queues such as RabbitMQ and Kafka for data push can be used. Taking Kafka as an example for push streaming, the middleware acts as a bridge connecting the master node, proxy node, and other system components, ensuring reliable transmission of tasks and test results. Step S102 specifically selects a target middleware capable of handling the test event from multiple middleware options based on its type and nature. Under the preset test parameters, a middleware monitor continuously monitors and acquires the test data corresponding to the test event in the target middleware, which serves as the basis for subsequent adjustments. It should be noted that the test data may specifically include indicators such as transaction latency, network throughput, block generation time, network latency, and node status.

[0065] Step S103 compares the test data obtained from the target middleware with the preset test data threshold. Based on the comparison result, it is determined whether the test data meets the expected standard. 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 performance of the test service.

[0066] For example, an "order creation" test event is published in the blockchain. Based on this test event, the middleware and its corresponding encryption protocol, Kafka-SSL, are selected for this test. The test event is sent to the proxy node through this middleware. The middleware monitor is used to obtain test data such as transaction latency, network throughput, and node status during the sending process. The above test data is compared with the preset test data thresholds to adjust the data based on the comparison results. The adjusted preset test parameters are then applied to the test corresponding to this test event.

[0067] In this embodiment of the application, by selecting a target middleware that is compatible with the test event from among multiple middlewares for testing, the problem of limited test applicability caused by the existing testing technology supporting only a single middleware is avoided. Furthermore, under the preset test parameter conditions, the selected target middleware is monitored in real time to obtain the test data corresponding to the test event. Then, the preset test parameters are adjusted in combination with the preset test data threshold, which enables real-time dynamic adjustment of the test strategy and flexible response to the ever-changing network environment and load conditions.

[0068] Reference Figure 2 In the embodiments achievable in this application, step S101 specifically includes the following steps:

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

[0070] Step S1012: The test master node initiates a user transaction simulation event, which 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] In step S1011, the smart contract is deployed to the blockchain. 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 a scenario where a user makes a transaction or performs an operation on the blockchain. The user transaction simulation event can trigger the execution of the smart contract. In step S1013, after the smart contract is triggered, it generates a test event corresponding to the user transaction simulation event and publishes it to the middleware. The middleware then transmits the data corresponding to the test event to the proxy node to ensure that all subscribers can receive the test event notification in real time.

[0073] For example, a specific smart contract can be deployed on the blockchain as an event generator. The test master node submits a simulated user transaction event on the blockchain that meets the triggering conditions of "Contract-A". For example, it can simulate 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. This test event contains important order information, such as order ID, user address, trading pair, price, and quantity. The smart contract publishes this test event to the middleware, which then transmits the data corresponding to the test event to the proxy node to ensure that all subscribers can receive the test event notification in real time.

[0074] In this embodiment of the 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 triggering conditions are met, simulating various user behaviors in the blockchain, and can also simulate diverse usage scenarios, such as high-frequency trading, node failure, network partition, etc. By executing these events through automated scripts, the test system can dynamically evaluate their impact on network performance and stability, providing data support for system optimization.

[0075] In embodiments achievable under this application, reference is made to Figure 3Step S102, which involves selecting a target middleware that is compatible with the test event from among the multiple middlewares, may specifically include the following steps:

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

[0077] Step S1022: Determine the middleware type and middleware parameters corresponding to the test event based on the event parameters;

[0078] Step S1023: Based on the middleware type and the middleware parameters, determine the target middleware that is compatible with the test event among the multiple middlewares.

[0079] In step S1021, the event parameters refer to specific information or attributes contained in the test event. These parameters define the type and nature of the event, used to distinguish different events and determine their processing logic. Step S1021 provides necessary input information for subsequent steps by obtaining the event parameters of the test event. In step S1022, the middleware type refers to the categories of middleware classified according to function, purpose, or technical architecture. Different middleware types are suitable for handling different types of test events. Middleware parameters refer to specific parameters or configurations that the middleware needs to follow or depend on when processing test events. Specific middleware parameters may include encryption protocols, processing speed, capacity limits, and interface specifications. Step S1022 analyzes the event parameters and determines the corresponding middleware type and parameters based on the type and nature of the event. By comprehensively considering the overall architecture and performance requirements of the test system, it ensures that the selected middleware type and parameters can meet the processing needs of the test events. In step S1023, based on the determined middleware type and parameters, a selection process is conducted from the available middleware set. The applicability of each candidate middleware is evaluated, and the middleware that best meets the processing needs of the test events is selected as the target middleware.

[0080] By following the steps above, middleware that is compatible with the test events can be selected effectively and accurately, ensuring 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 through configuration file parsing, and the corresponding middleware services can be automatically deployed, ensuring the normal operation and communication of these services.

[0082] For example, the Kafka service can be automatically deployed and managed using the middleware and encryption protocol required for the test events specified in the configuration file, namely Kafka-SSL, while ensuring that the SSL encryption protocol is correctly configured to protect the security of data transmission.

[0083] In the embodiments achievable in this application, to ensure the stable operation of the testing system under high load and concurrency scenarios, multiple proxy nodes need to be set up in the testing system, with corresponding references... Figure 4 After step S102, the testing method provided in this application embodiment 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 proxy node, so that each proxy node will send a message of receiving the test event back to the test master node.

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

[0086] In embodiments achievable under this application, reference is made to Figure 5 Step S103 may specifically include the following steps:

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

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

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

[0090] For example, the test begins by sending transactions to each blockchain node at a transaction sending rate of 100 TPS. Real-time monitoring detects that the transaction latency in the current test data begins to increase, specifically by 3 seconds, and the network throughput decreases. The system feedback indicates that the blockchain network is approaching its load limit. The preset test data threshold for transaction latency is 2 seconds. By comparison, it can be seen that the test data does not meet the preset test data threshold requirement. Therefore, the test data is input into the machine learning model. Based on historical test datasets, the machine learning model predicts that if the load continues to increase, the transaction latency will further increase and may lead to node overload. Therefore, the model outputs that the transaction sending rate corresponding to the current test data should be 80 TPS. Thus, the transaction sending rate is adjusted from 100 TPS to 80 TPS to alleviate the pressure.

[0091] By comparing the test data with preset test data thresholds and combining them with machine learning models, 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 concurrency scenarios.

[0092] In embodiments achievable under this application, reference is made to Figure 7 After step S103, the testing method provided in this application embodiment further includes the following steps:

[0093] Step S301: Obtain 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, detailed test reports are generated, including data analysis results on order data processing efficiency, response time, network performance, and other aspects. The test system is then iteratively optimized using these data analysis results. This involves inputting the data analysis results into a machine learning model, which then outputs the test parameters for the next testing phase. This allows for automatic adjustment of test parameters for the next round of testing, ensuring the test system continuously improves its accuracy and reliability.

[0097] To facilitate understanding, a complete example is provided below to illustrate the testing method provided in the embodiments of this application. Figure 8 The diagram shows a flowchart of a testing method provided in an embodiment of this application. Figure 8The test flow shown is an example of a test method implemented through the cooperation of various on-chain and off-chain modules, units, or components, based on the test methods described in the foregoing method embodiments. (Refer to...) Figure 8 The process of implementing the testing method provided in this application mainly involves an on-chain event generator, a middleware adaptation and automated deployment module, a middleware monitor, a dynamic test strategy adjustment module, a highly scalable test proxy 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. This 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 simulate diverse use cases, such as high-frequency trading, node failure, network partition, etc. By executing these events through automated scripts, the system can dynamically evaluate their impact on network performance and stability.

[0099] The middleware adaptation and automated deployment module provides adaptation interfaces for middleware and encryption protocols, supporting the automated deployment of required middleware services through configuration files. The system parses the required middleware types and their parameters from 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, listen to events triggered by the on-chain event generator in real time, and generate corresponding test data based on the event type and testing strategy.

[0101] The dynamic test strategy adjustment module works by employing a dynamic feedback mechanism to continuously monitor key metrics during the testing process (such as transaction latency, network throughput, and node status). Based on the feedback data, machine learning models or rule engines are used to automatically adjust the test strategy, such as changing load intensity, node distribution, or test frequency, to more accurately simulate behavior in a real-world environment.

[0102] The highly scalable test proxy module enables the system to run test tasks in parallel on multiple nodes through a distributed test proxy architecture. The proxy nodes work together with the master node, and through efficient message queues and load balancing mechanisms, the effectiveness and stability of test tasks under high load and concurrency scenarios are guaranteed. At the same time, the system supports the expansion of test proxy nodes as needed to meet larger-scale testing requirements.

[0103] The analysis and iterative feedback module collects all data from the middleware monitor and off-chain test agents, including message delivery latency, packet loss rate, and security vulnerabilities. This module performs statistical analysis on this data, generates comprehensive test reports, and provides real-time feedback to the middleware monitor to adjust testing strategies. For example, it can dynamically adjust message sending frequency or packet size to simulate different load conditions. Based on the results of the analysis and feedback module, the testing process iterates, gradually optimizing the performance and security of message push in the decentralized network. Through multiple iterations, different aspects of message push (such as real-time performance, reliability, and security) can be comprehensively evaluated, providing data support for system optimization.

[0104] Taking "using middleware to adapt to the Kafka-SSL encryption protocol in a blockchain" as an example, the execution flow of the testing method provided in this application will be further explained. Firstly, it involves the generation and triggering of on-chain events. In the blockchain's smart contract, when a user, i.e., the test master node, initiates a new buy or sell order (such as a limit order or market order), the smart contract generates and broadcasts a specific "order creation" event. This event contains important order information, such as order ID, user address, trading pair, price, and quantity. The smart contract publishes this event in the blockchain network through a pre-defined event interface, ensuring that all subscribers (such as middleware monitors and broker nodes) can receive the event notification in real time. To ensure secure and smooth data transmission, the Kafka service needs to be automatically deployed and managed according to the middleware and encryption protocol required for this test, i.e., Kafka-SSL, specified in the configuration file. Simultaneously, the correct configuration of the SSL encryption protocol must be ensured to protect the security of data transmission. Next, the middleware monitor continuously listens for "order creation" events on the blockchain. Upon detecting such an event, the monitor immediately captures event data (including order ID, user address, transaction pair, price, quantity, etc.). Based on a predefined testing strategy, the captured event data is standardized and used as a comparison for test verification. This involves parsing the captured data, removing invalid, duplicate, or erroneous data to ensure accuracy and completeness. This serves as the verification basis for the correctness of the test data obtained during actual testing. The test system uses a large number of distributed proxy nodes to receive order data from the Kafka channel, ensuring stable operation under high load and concurrency scenarios. The middleware monitor monitors performance data (such as response time, network latency, etc.) throughout the entire testing process and dynamically adjusts the testing strategy, i.e., test parameters, based on real-time feedback. For example, if the system load is found to be too high at a certain moment, the Kafka message sending frequency can be reduced, or the number of Kafka partitions and message processing threads can be adjusted. By collecting and analyzing on-chain and off-chain test data, a detailed test report is generated. 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, automatically adjusting the parameters and strategies for the next round of testing to ensure that the testing system continuously improves its accuracy and reliability.

[0105] In this example, the system modified the configuration file according to the testing requirements, realizing the automated deployment of Kafka middleware adapted to the SSL encryption protocol, providing a stable middleware environment for the current test. When the smart contract in the blockchain triggers the "order creation" event, the middleware monitor promptly captures the event and verifies the correctness and performance of the messages pushed by the module under test. The entire process involves on-chain event generation, event data capture and transmission, off-chain data processing and display, dynamic strategy adjustment, and test result analysis, thereby achieving comprehensive testing of transaction order management.

[0106] Figure 9 This is a schematic diagram of a blockchain-based testing device provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

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

[0108] Module 901 is used to publish a test event;

[0109] The acquisition module 902 is used to select a target middleware that is compatible with the test event from multiple middlewares, and to acquire the test data corresponding to the test event from the selected target middleware under preset test parameter conditions.

[0110] The adjustment module 903 is used to adjust the preset test parameters according to the test data and the preset test data threshold.

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

[0112] Specifically, the release module 901 releases test events to simulate different types of on-chain activities, facilitating the acquisition of subsequent test data. The acquisition module 902 selects a target middleware from multiple middlewares based on the type and nature of the test event. Under preset test parameters, a middleware monitor continuously monitors and acquires the test data corresponding to the test event in the target middleware, which serves as the basis for subsequent adjustments. The adjustment module 903 compares the test data acquired from the target middleware with preset test data thresholds. Based on the comparison results, it determines whether the test data meets the expected standards. If not, the preset test parameters are adjusted according to the specific situation to optimize test conditions and more effectively simulate different load conditions and network environments. The test module 904 applies the adjusted preset test parameters to the test environment to ensure the effective execution of the test service.

[0113] The aforementioned testing device allows for the selection of a target middleware that is compatible with the test event from among multiple middlewares for testing. This avoids the problem of limited applicability caused by existing testing technologies that only support a single middleware. Furthermore, under preset test parameters, the selected target middleware is monitored in real time to obtain test data corresponding to the test event. Combined with preset test data thresholds, preset test parameters can be adjusted to achieve real-time dynamic adjustment of the test strategy and flexibly respond to constantly changing network environments and load conditions.

[0114] Figure 10 This application provides a schematic diagram of the structure of a computer device 1001. The computer device 1001 includes: at least one processor 1002. Figure 10 Only one is shown in the diagram. 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, are also shown. When the processor 1002 executes the computer program 1004, it implements the steps described in the blockchain-based test method embodiment above, for example... Figure 1 Steps 101 to 104 are shown. Alternatively, when the processor 1002 executes the computer program 1004, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 10 The functions of units 1001 to 1004 are shown.

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

[0116] The publish module is used to publish a test event;

[0117] The acquisition module is used to select a target middleware that is compatible with the test event from among a plurality of middlewares, and to acquire the test data corresponding to the test event from the selected target middleware under preset test parameter conditions.

[0118] The adjustment module is used to adjust the preset test parameters based on the test data and the preset test data threshold.

[0119] The testing 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 desktop computer, laptop, handheld computer, or cloud server, etc. This computer device may include, but is not limited to, a processor 1002 and a memory 1003. Those skilled in the art will understand that... Figure 10 The computer device 1001 is merely an example and does not constitute a limitation on the computer device 1001. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0121] The processor 1002 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), 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.

[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 be an external storage device of the computer device 1001, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 1001. Furthermore, the memory 1003 may include both internal and external storage units of the computer device 1001. The memory 1003 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 1003 can also be used to temporarily store data that has been output or will be output.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to 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 embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0124] In the above embodiments, the descriptions of each embodiment have different focuses. If a certain embodiment does not describe or record a certain part in detail, please refer to the relevant descriptions of other embodiments.

[0125] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.

[0126] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described method embodiments.

[0127] Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0128] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0130] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The aforementioned units can be implemented in hardware or software.

[0131] If the integrated module / unit is implemented as 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed 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 electrical carrier signals and telecommunication signals.

[0132] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A blockchain-based testing method, characterized in that, The testing method is executed by a testing system, which includes a test master node, multiple middleware components, and at least one proxy node. The middleware is used for data transmission between the test master node and the proxy node. The testing method includes: The process of publishing a test event includes: deploying a smart contract in the blockchain; initiating a user transaction simulation event by the test master node, the user transaction simulation event being used to trigger the smart contract; generating a test event corresponding to the user transaction simulation event through the smart contract, and publishing it to the middleware; Selecting a target middleware adapted to the test event from among multiple middlewares, and obtaining test data corresponding to the test event from the selected target middleware under preset test parameter conditions; the test data includes transaction latency, network throughput, block generation time, network latency, and node status; the middleware is used for data transmission between the test master node and the proxy node, using a message queue for data push; the middleware is a bridge connecting the master node, proxy node, and other system components; selecting a target middleware adapted to the test event from among multiple middlewares includes: obtaining event parameters corresponding to the test event; determining the middleware type and middleware parameters corresponding to the test event based on the event parameters; and determining the middleware adapted to the test event from among the multiple middlewares based on the middleware type and the middleware parameters. The test method further includes: a target middleware adapted to the test event; event parameters defining the type and nature of the event to distinguish different events and determine their processing logic; middleware type referring to the categories of middleware classified according to function, purpose, or technical architecture, with different middleware types suitable for handling different types of test events; middleware parameters referring to specific parameters or configurations that the middleware needs to follow or rely on when processing test events, including encryption protocols, processing speed, capacity limits, and interface specifications; after selecting a target middleware adapted to the test event from among the multiple middlewares, the test method further includes: the selected target middleware receiving the test event published by the smart contract and distributing the test event to each proxy node, so that each proxy node will feed back the message of receiving the test event to the test master node; Adjust the preset test parameters based on the test data and the preset test data threshold; The adjusted preset test parameters are applied to the test corresponding to the test event.

2. The method according to claim 1, characterized in that, The step of adjusting the preset test parameters based on the test data and the preset test data threshold includes: Compare the test data with the preset test data threshold; If the test data does not meet the preset test data threshold requirements, the preset test parameters are adjusted.

3. The method according to claim 2, characterized in that, When the test data does not meet the preset test data threshold requirement, adjusting the preset test parameters includes: The test data is input into a machine learning model, which outputs the test parameters corresponding to the test data based on the historical test dataset. Adjust the preset test parameters to the test parameters corresponding to the test data.

4. The method according to claim 3, characterized in that, After adjusting the preset test parameters based on the test data and the preset test data threshold, the method further includes: Obtain 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, which then outputs the test parameters for the next testing process.

5. A blockchain-based testing device, characterized in that, The testing apparatus includes: The publishing module is used to publish a test event, including: deploying a smart contract in the blockchain; initiating a user transaction simulation event by the test master node, the user transaction simulation event being used to trigger the smart contract; generating a test event corresponding to the user transaction simulation event through the smart contract, and publishing it to the middleware; The acquisition module is used to select a target middleware adapted to the test event from multiple middlewares, and to acquire test data corresponding to the test event from the selected target middleware under preset test parameter conditions. The test data includes transaction latency, network throughput, block generation time, network latency, and node status. The middleware is used for data transmission between the test master node and the proxy node, using a message queue for data push. The middleware serves as a bridge connecting the master node, proxy node, and other system components. Selecting a target middleware adapted to the test event from multiple middlewares includes: acquiring event parameters corresponding to the test event; determining the middleware type and middleware parameters corresponding to the test event based on the event parameters; and selecting a target middleware adapted to the test event from multiple middlewares based on the middleware type and the middleware parameters. The process involves determining a target middleware adapted to the test event; the event parameters define the type and nature of the event, used to distinguish different events and determine their processing logic; the middleware type refers to the category of middleware classified according to function, purpose, or technical architecture, and different middleware types are suitable for handling 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 test events, including encryption protocols, processing speed, capacity limits, and interface specifications; after selecting a target middleware adapted to the test event from among the multiple middlewares, the process further includes: the selected target middleware receiving the test event published by the smart contract and distributing the test event to each proxy node, so that each proxy node will feed back the message of receiving the test event to the test master node; The adjustment module is used to adjust the preset test parameters based on the test data and the preset test data threshold. The testing module is used to apply the adjusted preset test parameters to the test corresponding to the test event.

6. 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, it implements the method as described in any one of claims 1 to 4.

7. A computer program product, when run on a computer device, causes the computer device to perform the method as described in any one of claims 1 to 4.

Images