Message queue testing method and device for consortium chain, electronic equipment and program product

Abstract

The application is suitable for the field of blockchain technology, and provides a message queue test method and device of a consortium chain, an electronic device and a program product. The method comprises the following steps: determining a target parameter according to a test case corresponding to a to-be-tested message queue of the consortium chain; generating a test task and a test scene according to the target parameter, and scheduling test resources according to the test task and the test scene; selecting a message queue type of the to-be-tested message queue according to the target parameter; determining a target security transmission protocol and a target encryption algorithm according to the target parameter and the test scene; and performing an encryption test on the to-be-tested message queue through the test task, the test scene, the test resources, the message queue type, the target security transmission protocol and the target encryption algorithm. Through the method of the application, the electronic device can automatically test the message queue of the consortium chain, thereby improving the test efficiency of the message queue of the consortium chain.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a message queue testing method, device, electronic device and program product for consortium blockchains. Background Technology

[0002] During the testing of consortium blockchains, message queues are a key component used to enable asynchronous communication, transaction broadcasting, and event transmission between nodes.

[0003] Currently, the testing of message queues in consortium blockchains typically requires manual intervention. This includes manually generating test tasks and scenarios, manually scheduling test resources, and manually determining the target secure transmission protocol and encryption algorithm to be used during the test. As can be seen, the existing testing methods for message queues in consortium blockchains have a low level of intelligence, which reduces the testing efficiency of message queues in consortium blockchains. Summary of the Invention

[0004] In view of this, embodiments of this application provide a message queue testing method, apparatus, electronic device, and program product for consortium blockchains to solve the technical problem of low testing efficiency of message queues in consortium blockchains in the prior art.

[0005] In a first aspect, embodiments of this application provide a message queue testing method for consortium blockchains, including:

[0006] Determine the target parameters based on the test cases corresponding to the message queue to be tested in the consortium blockchain;

[0007] Based on the target parameters, test tasks and test scenarios are generated, and test resources are scheduled according to the test tasks and test scenarios.

[0008] Select the message queue type of the message queue to be tested based on the target parameters;

[0009] Based on the target parameters and the test scenario, determine the target secure transmission protocol and the target encryption algorithm;

[0010] The message queue to be tested is encrypted using the test task, the test scenario, the test resources, the message queue type, the target secure transmission protocol, and the target encryption algorithm.

[0011] Optionally, the target parameters include the node type of the consortium blockchain, the network topology of the consortium blockchain, the configuration parameters of the message queue to be tested, the test task generation strategy, and the test scenario generation strategy; generating test tasks and test scenarios according to the target parameters includes:

[0012] The test task is generated based on the node type, the network topology, the configuration parameters, and the test task generation strategy.

[0013] The test scenario is generated based on historical test data, custom test parameters, and the test scenario generation strategy.

[0014] Optionally, the target parameters include the business load characteristics of the consortium blockchain, the inter-node communication latency of the consortium blockchain, the consensus algorithm type of the consortium blockchain, and the message flow distribution mode of the consortium blockchain; selecting the message queue type of the message queue to be tested according to the target parameters includes:

[0015] The message queue type of the message queue to be tested is selected based on the business load characteristics, the inter-node communication latency, the consensus algorithm type, the message flow distribution pattern, the target selection weight corresponding to each candidate message queue type, and the preset queue type selection strategy.

[0016] Optionally, the target selection weight corresponding to each of the candidate message queue types is determined in the following way:

[0017] The target operating metric of the consortium blockchain is used as a reward function and input into the trained weight selection model to instruct the weight selection model to optimize and output the initial selection weights corresponding to each of the candidate message queue types according to the target operating metric; the target operating metric includes any one or more of the following: transaction processing per second, message latency, message processing error rate, and message retry rate;

[0018] The optimized initial selection weights corresponding to each of the candidate message queue types are respectively determined as the target selection weights corresponding to each of the candidate message queue types.

[0019] Optionally, the target parameters include the security level of the consortium blockchain and the testing strategy of the consortium blockchain; determining the target secure transmission protocol and the target encryption algorithm based on the target parameters and the testing scenario includes:

[0020] Based on the security level, the testing strategy, the testing scenario, and the preset secure transmission protocol, a strategy is determined, and the target secure transmission protocol is determined from a plurality of preset candidate secure transmission protocols.

[0021] Based on the target secure transmission protocol, the test scenario, and the preset encryption algorithm combination determination strategy, at least one candidate encryption algorithm combination is determined; each candidate encryption algorithm combination includes several encryption algorithms.

[0022] Based on the test scenario, the performance parameters corresponding to each of the candidate encryption algorithm combinations are determined, and based on the performance parameters, the target encryption algorithm combination is determined from each of the candidate encryption algorithm combinations.

[0023] The various encryption algorithms included in the target encryption algorithm combination are collectively determined as the target encryption algorithm.

[0024] Optionally, the step of performing encryption testing on the message queue to be tested using the test task, the test scenario, the test resources, the message queue type, the target secure transmission protocol, and the target encryption algorithm includes:

[0025] Using the test resources, the message queue to be tested is deployed in the test scenario according to the message queue type, the target secure transmission protocol, and the target encryption algorithm.

[0026] According to the test task, the deployed message queue to be tested is subjected to encryption testing.

[0027] Optionally, after performing encryption testing on the message queue to be tested using the test task, the test scenario, the test resources, the message queue type, the target secure transport protocol, and the target encryption algorithm, the method further includes:

[0028] Acquire target data generated during the encryption test of the message queue to be tested; the target data includes any one or more of the following: block generation rate, message backlog length, and node synchronization delay;

[0029] Based on the target data, optimize any one or more of the following strategies: test task generation strategy, test scenario generation strategy, queue type selection strategy, secure transmission protocol determination strategy, and encryption algorithm combination determination strategy.

[0030] Secondly, embodiments of this application provide a message queue testing device for a consortium blockchain, comprising:

[0031] The first determining unit is used to determine the target parameters based on the test cases corresponding to the message queue to be tested in the consortium blockchain;

[0032] The scheduling unit is used to generate test tasks and test scenarios according to the target parameters, and to schedule test resources according to the test tasks and test scenarios;

[0033] The selection unit is used to select the message queue type of the message queue to be tested according to the target parameters.

[0034] The second determining unit is used to determine the target secure transmission protocol and the target encryption algorithm based on the target parameters and the test scenario.

[0035] The testing unit is used to perform encryption testing on the message queue to be tested using the test task, the test scenario, the test resources, the message queue type, the target secure transmission protocol, and the target encryption algorithm.

[0036] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the message queue testing method for consortium blockchains as described in any of the first aspects above.

[0037] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the message queue testing method for consortium blockchains as described in any of the first aspects above.

[0038] Fifthly, embodiments of this application provide a computer program product that, when run on a control device, causes the control device to execute the steps of the message queue testing method for consortium blockchains as described in any of the first aspects above.

[0039] The message queue testing method, apparatus, electronic device, and program product for consortium blockchains provided in this application have the following beneficial effects:

[0040] In the message queue testing method for consortium blockchains provided in this application embodiment, firstly, target parameters are determined based on the test cases corresponding to the message queue to be tested in the consortium blockchain. Then, test tasks and test scenarios are generated based on the target parameters, and test resources are scheduled according to the test tasks and test scenarios. Next, the message queue type of the message queue to be tested is selected based on the target parameters. Then, the target secure transmission protocol and target encryption algorithm are determined based on the target parameters and test scenarios. Finally, encryption testing is performed on the message queue to be tested using the test tasks, test scenarios, test resources, message queue type, target secure transmission protocol, and target encryption algorithm. Through this method, electronic devices can automatically test the message queues of consortium blockchains. Compared to existing testing methods that require manual completion of the entire testing process, the message queue testing method for consortium blockchains provided in this application improves the intelligence level of testing message queues in consortium blockchains, thereby improving the testing efficiency of message queues in consortium blockchains. Attached Figure Description

[0041] 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.

[0042] Figure 1 A flowchart illustrating the implementation of the message queue testing method for consortium blockchains provided in this application embodiment;

[0043] Figure 2 A schematic diagram of the structure of a message queue testing device for a consortium blockchain provided in an embodiment of this application;

[0044] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0045] It should be noted that the terminology used in the embodiments of this application is only for explaining specific embodiments of this application and is not intended to limit this application. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, "at least one" or "one or more" means one, two or more. The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0046] 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.

[0047] The execution subject of the message queue testing method for consortium blockchains provided in this application embodiment can be an electronic device, which may include, but is not limited to, electronic devices such as laptops, desktop computers, tablets, and mobile phones.

[0048] The message queue testing method for consortium blockchains provided in this application embodiment can be applied to any scenario where the message queue of a consortium blockchain needs to be tested. When a user needs to test the message queue of a consortium blockchain, they can execute the various steps of the message queue testing method provided in this application embodiment through an electronic device, thereby enabling automatic testing of the message queue of the consortium blockchain through an electronic device and improving the testing efficiency of the message queue of the consortium blockchain.

[0049] Please see Figure 1 , Figure 1 The flowchart illustrates the implementation of the message queue testing method for a consortium blockchain provided in this application embodiment. The message queue testing method for a consortium blockchain provided in this application embodiment may include steps S101 to S105, as detailed below:

[0050] In S101, the target parameters are determined based on the test cases corresponding to the message queue to be tested in the consortium blockchain.

[0051] In this embodiment of the application, when an electronic device needs to test the message queue to be tested of a consortium blockchain, it can first identify the test cases corresponding to the message queue to be tested in order to determine the target parameters corresponding to the message queue to be tested.

[0052] The specific parameters included in the target parameters can be found in other steps of the embodiments of this application, and will not be repeated here.

[0053] In S102, test tasks and test scenarios are generated based on the target parameters, and test resources are scheduled based on the test tasks and test scenarios.

[0054] In this application embodiment, the target parameters may include: the node type of the consortium blockchain, the network topology of the consortium blockchain, the configuration parameters of the message queue to be tested, the test task generation strategy, and the test scenario generation strategy.

[0055] Based on this, electronic devices can generate test tasks and test scenarios through steps a to b. Details are as follows:

[0056] In step a, test tasks are generated based on node type, network topology, configuration parameters, and test task generation strategy.

[0057] In this implementation, the test task generation strategy can be generated based on historical test data and a preset task generation strategy template. In practical applications, the test task generation strategy can be set according to actual needs, and is not limited here. The test task generation strategy determined by historical test data and the preset task generation strategy template ensures that the generated test tasks have scalability and universality.

[0058] The generated test task may include one or more of the following parameters: the type of nodes in the consortium blockchain, the number of nodes in the consortium blockchain, the test scale, the range of selectable secure transmission protocols, and the range of selectable encryption algorithms. These parameters can provide task definitions and constraints for subsequent tests.

[0059] In step b, test scenarios are generated based on historical test data, custom test parameters, and test scenario generation strategies.

[0060] In this implementation, the test scenario generation strategy can also be generated based on historical test data and preset test scenario generation strategy templates. In practical applications, the test scenario generation strategy and custom test parameters can be set according to actual needs, and there are no restrictions here.

[0061] Test scenarios generated using historical test data, custom test parameters, and test scenario generation strategies ensure that the generated test scenarios are scalable and universal.

[0062] After generating test tasks and test scenarios, the electronic device can determine the test resources that need to be scheduled based on these tasks and scenarios. Specifically, the test resources that need to be scheduled may include compute nodes, network bandwidth, and container resources. Then, resource scheduling can be performed based on the required test resources.

[0063] In one possible implementation, the electronic device can dynamically schedule computing nodes, network bandwidth, and container resources based on the test task and test scenario. For example, the electronic device can monitor server performance parameters such as CPU and memory usage in real time, allocating test tasks to idle or low-load nodes to avoid resource waste or overload. For example, the electronic device can dynamically allocate network bandwidth based on the data transmission speed requirements of the test scenario to prioritize the smooth communication of high-priority test tasks. For example, the electronic device can flexibly create, destroy, or migrate containers, allocating appropriate container resources to consortium blockchain nodes to adapt to the resource requirements of different test scales.

[0064] In S103, select the message queue type of the message queue to be tested based on the target parameters.

[0065] In this application embodiment, the target parameters may include: the business load characteristics of the consortium blockchain, the inter-node communication latency of the consortium blockchain, the consensus algorithm type of the consortium blockchain, and the message flow distribution mode of the consortium blockchain.

[0066] Based on this, the electronic device can select the message queue type of the message queue to be tested through step c. Details are as follows:

[0067] In step c, the message queue type of the message queue to be tested is selected based on the business load characteristics, inter-node communication latency, consensus algorithm type, message flow distribution pattern, target selection weight corresponding to each candidate message queue type, and preset queue type selection strategy.

[0068] In this implementation, business load characteristics can refer to the resource consumption and task pressure characteristics related to business, such as the number of transactions, the amount of data, and the concurrency of requests processed by nodes in the actual operation or testing scenarios of the consortium blockchain system.

[0069] Inter-node communication latency refers to the time delay when different nodes (such as consensus nodes, non-consensus nodes, and cross-organization nodes) transmit data over the network in a consortium blockchain.

[0070] Consensus algorithm type can be the core rule for achieving data consistency among nodes in a consortium blockchain. It can be used to determine how nodes confirm the validity of transactions and generate blocks through interaction.

[0071] The message flow distribution pattern can refer to the transmission path, flow characteristics, or distribution density of messages (such as transaction messages, consensus messages, and block synchronization messages) between different nodes in a consortium blockchain.

[0072] The target selection weights for each candidate message queue type are used to describe the priority or probability of each candidate message queue type.

[0073] In one possible implementation, the electronic device can determine the target selection weight corresponding to each candidate message queue type in the following way:

[0074] First, the electronic device can input the target performance metrics of the consortium blockchain as a reward function into the trained weight selection model. This instructs the weight selection model to optimize and output the initial selection weights corresponding to each candidate message queue type based on the target performance metrics. The target performance metrics include any one or more of the following: transactions per second, message latency, message processing error rate, and message retry rate. Then, the electronic device can determine the optimized initial selection weights corresponding to each candidate message queue type as the target selection weights for that specific candidate message queue type.

[0075] In this implementation, transactions per second (TPS) describes the number of transactions the message queue can successfully process per unit of time. Message latency describes the total time it takes for a message in the message queue to be sent from the producer to the consumer and successfully received. Message processing error rate describes the proportion of messages that failed to process within the message queue to the total number of messages in the message queue per unit of time. Message retry rate describes the proportion of messages in the message queue that need to be reprocessed via a retry mechanism to the total number of messages in the message queue per unit of time.

[0076] By optimizing the initial selection weights for each candidate message queue type using a weighted selection model, the accuracy of electronic devices in selecting the message queue type to be tested can be continuously improved.

[0077] Furthermore, the queue type selection strategy can be generated based on historical test data and a preset queue type selection strategy template. In practical applications, the queue type selection strategy can be set according to actual needs, and no limitation is made here. The test task generation strategy determined by historical test data and the preset queue type selection strategy template can ensure that the selected message queue type for the message queue to be tested has scalability and versatility.

[0078] The message queue type selected by step c takes into account multiple target parameters in the consortium blockchain, thus resulting in a high accuracy in selecting the message queue type for the message queue to be tested.

[0079] In S104, the target secure transmission protocol and target encryption algorithm are determined based on the target parameters and test scenario.

[0080] In this application embodiment, the target parameters may include: the security level of the consortium blockchain and the testing strategy of the consortium blockchain.

[0081] Based on this, the electronic device can determine the target secure transmission protocol and the target encryption algorithm through steps d to g. Details are as follows:

[0082] In step d, a strategy is determined based on the security level, testing strategy, testing scenario, and preset secure transmission protocol, and a target secure transmission protocol is selected from a plurality of preset candidate secure transmission protocols.

[0083] In this implementation, the specific implementation method for determining the target secure transmission protocol from a set of pre-set candidate secure transmission protocols based on the security level of the consortium blockchain, the consortium blockchain's testing strategy, the testing scenario, and the pre-set secure transmission protocol determination strategy can be set according to actual needs and is not limited here. Furthermore, the specific protocol types included in the pre-set candidate secure transmission protocols can also be set according to actual needs and are not limited here.

[0084] In step e, a strategy is determined based on the target secure transmission protocol, the test scenario, and the preset combination of encryption algorithms, and at least one candidate encryption algorithm combination is determined; each candidate encryption algorithm combination includes several encryption algorithms.

[0085] In this implementation, the number of candidate encryption algorithm combinations can be set according to actual needs, and the number of encryption algorithms included in each candidate encryption algorithm combination can also be set according to actual needs. For example, the electronic device can determine a strategy based on the target secure transmission protocol, the test scenario, and preset encryption algorithm combinations, determining three candidate encryption algorithm combinations (candidate encryption algorithm combination 1, candidate encryption algorithm combination 2, and candidate encryption algorithm combination 3), and each candidate encryption algorithm combination can include three encryption algorithms. For example, candidate encryption algorithm combination 1 can include encryption algorithm 1, encryption algorithm 2, and encryption algorithm 3; candidate encryption algorithm combination 2 can include encryption algorithm 4, encryption algorithm 5, and encryption algorithm 6; and candidate encryption algorithm combination 3 can include encryption algorithm 7, encryption algorithm 8, and encryption algorithm 9.

[0086] In step f, based on the test scenario, the performance parameters corresponding to each candidate encryption algorithm combination are determined, and based on each performance parameter, the target encryption algorithm combination is determined from each candidate encryption algorithm combination.

[0087] In this implementation, the electronic device can determine the performance parameters of each candidate encryption algorithm combination according to the test scenario using a preset method. For example, the performance parameters of candidate encryption algorithm combination 1, candidate encryption algorithm combination 2, and candidate encryption algorithm combination 3 are determined respectively. Then, based on the performance parameters of candidate encryption algorithm combination 1, candidate encryption algorithm combination 2, and candidate encryption algorithm combination 3, the target encryption algorithm combination can be determined from candidate encryption algorithm combination 1, candidate encryption algorithm combination 2, and candidate encryption algorithm combination 3.

[0088] In step g, the various encryption algorithms included in the target encryption algorithm combination are collectively determined as the target encryption algorithm.

[0089] In this implementation, for example, if the electronic device determines that the candidate encryption algorithm combination 1 is the target encryption algorithm combination, then the encryption algorithm 1, encryption algorithm 2 and encryption algorithm 3 included in the candidate encryption algorithm combination 1 can be jointly determined as the target encryption algorithm.

[0090] In S105, encryption tests are performed on the message queue to be tested by using test tasks, test scenarios, test resources, message queue types, target secure transmission protocols, and target encryption algorithms.

[0091] In this embodiment of the application, after generating test tasks and test scenarios, scheduling test resources, selecting the message queue type of the message queue to be tested, and determining the target secure transmission protocol and target encryption algorithm, the electronic device can first deploy the message queue to be tested in the test scenario using test resources, according to the message queue type, target secure transmission protocol, and target encryption algorithm. Then, it can perform encryption tests on the deployed message queue to be tested according to the test task.

[0092] In practical applications, electronic devices can deploy message queues under test in test scenarios based on message queue type, target secure transmission protocol, and target encryption algorithm, according to actual needs. In addition, the specific method for electronic devices to perform encryption tests on the deployed message queues under test according to test tasks can also be set according to actual needs.

[0093] In one possible implementation, after each encryption test on the message queue under test, the electronic device can also acquire target data generated during the encryption test. This target data includes any one or more of the following: block generation rate, message backlog length, and node synchronization latency. Furthermore, based on the target data, any one or more of the following strategies can be optimized: test task generation strategy, test scenario generation strategy, queue type selection strategy, secure transport protocol determination strategy, and encryption algorithm combination determination strategy.

[0094] Among them, the block generation rate can be used to describe the number of valid blocks successfully generated and submitted to the chain per unit time in the consortium; the message backlog length can be used to describe the total number of messages that have been received in the message queue but have not yet been processed by the consortium chain nodes at a certain moment; and the node synchronization delay can be used to describe the total time taken for a non-consensus node (or a newly joined node) in the consortium chain to go from receiving a block to having data that is completely consistent with that of the consensus node.

[0095] Specifically, electronic devices can use a deep reinforcement learning-based strategy optimization mechanism to take target data and test case execution results as feedback signals. This allows them to automatically optimize any one or more of the strategies used in this application's embodiments, such as test task generation strategy, test scenario generation strategy, queue type selection strategy, secure transmission protocol determination strategy, and encryption algorithm combination determination strategy, in multiple tests. As a result, the optimized strategy can be directly adopted in the next test to improve the testing efficiency and effectiveness of the consortium blockchain's message queue.

[0096] As can be seen from the above, in the message queue testing method for consortium blockchains provided in this application embodiment, firstly, target parameters are determined based on the test cases corresponding to the message queue to be tested in the consortium blockchain. Then, test tasks and test scenarios are generated based on the target parameters, and test resources are scheduled according to the test tasks and test scenarios. Next, the message queue type of the message queue to be tested is selected based on the target parameters. Then, the target secure transmission protocol and target encryption algorithm are determined based on the target parameters and test scenarios. Finally, encryption testing is performed on the message queue to be tested using the test tasks, test scenarios, test resources, message queue type, target secure transmission protocol, and target encryption algorithm. Through the method of this application, electronic devices can automatically test the message queues of consortium blockchains. Compared with existing testing methods that require manual completion of the entire testing process, the message queue testing method for consortium blockchains provided in this application can improve the intelligence level of testing message queues in consortium blockchains, thereby improving the testing efficiency of message queues in consortium blockchains.

[0097] Based on the message queue testing method for consortium blockchains provided in the above embodiments, this application further provides a message queue testing apparatus for consortium blockchains that implements the above method embodiments. Please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a schematic diagram of the structure of a message queue testing device for a consortium blockchain, provided as an embodiment of this application. Figure 2 As shown, the message queue testing device 20 for a consortium blockchain may include: a first determining unit 21, a scheduling unit 22, a selection unit 23, a second determining unit 24, and a testing unit 25. Wherein:

[0098] The first determining unit 21 is used to determine the target parameters based on the test cases corresponding to the message queue to be tested in the consortium blockchain.

[0099] The scheduling unit 22 is used to generate test tasks and test scenarios according to the target parameters, and to schedule test resources according to the test tasks and test scenarios.

[0100] Selection unit 23 is used to select the message queue type of the message queue to be tested according to the target parameters.

[0101] The second determining unit 24 is used to determine the target secure transmission protocol and the target encryption algorithm based on the target parameters and the test scenario.

[0102] The testing unit 25 is used to perform encryption testing on the message queue to be tested using the test task, the test scenario, the test resources, the message queue type, the target secure transmission protocol, and the target encryption algorithm.

[0103] Optionally, the target parameters include the node type of the consortium blockchain, the network topology of the consortium blockchain, the configuration parameters of the message queue to be tested, the test task generation strategy, and the test scenario generation strategy. The scheduling unit 22 is specifically used for:

[0104] The test task is generated based on the node type, the network topology, the configuration parameters, and the test task generation strategy.

[0105] The test scenario is generated based on historical test data, custom test parameters, and the test scenario generation strategy.

[0106] Optionally, the target parameters include the business load characteristics of the consortium blockchain, the inter-node communication latency of the consortium blockchain, the consensus algorithm type of the consortium blockchain, and the message flow distribution mode of the consortium blockchain. Selection unit 23 is specifically used for:

[0107] The message queue type of the message queue to be tested is selected based on the business load characteristics, the inter-node communication latency, the consensus algorithm type, the message flow distribution pattern, the target selection weight corresponding to each candidate message queue type, and the preset queue type selection strategy.

[0108] Optionally, selection unit 23 is specifically used for:

[0109] The target operating metric of the consortium blockchain is used as a reward function and input into the trained weight selection model to instruct the weight selection model to optimize and output the initial selection weights corresponding to each of the candidate message queue types according to the target operating metric; the target operating metric includes any one or more of the following: transaction processing per second, message latency, message processing error rate, and message retry rate;

[0110] The optimized initial selection weights corresponding to each of the candidate message queue types are respectively determined as the target selection weights corresponding to each of the candidate message queue types.

[0111] Optionally, the target parameters include the security level of the consortium blockchain and the testing strategy of the consortium blockchain. The second determining unit 24 is specifically used for:

[0112] Based on the security level, the testing strategy, the testing scenario, and the preset secure transmission protocol, a strategy is determined, and the target secure transmission protocol is determined from a plurality of preset candidate secure transmission protocols.

[0113] Based on the target secure transmission protocol, the test scenario, and the preset encryption algorithm combination determination strategy, at least one candidate encryption algorithm combination is determined; each candidate encryption algorithm combination includes several encryption algorithms.

[0114] Based on the test scenario, the performance parameters corresponding to each of the candidate encryption algorithm combinations are determined, and based on the performance parameters, the target encryption algorithm combination is determined from each of the candidate encryption algorithm combinations.

[0115] The various encryption algorithms included in the target encryption algorithm combination are collectively determined as the target encryption algorithm.

[0116] Optionally, test unit 25 is specifically used for:

[0117] Using the test resources, the message queue to be tested is deployed in the test scenario according to the message queue type, the target secure transmission protocol, and the target encryption algorithm.

[0118] According to the test task, the deployed message queue to be tested is subjected to encryption testing.

[0119] Optionally, the message queue testing device 20 of the consortium blockchain may also include a policy optimization unit. Wherein:

[0120] The strategy optimization unit is specifically used for:

[0121] Acquire target data generated during the encryption test of the message queue to be tested; the target data includes any one or more of the following: block generation rate, message backlog length, and node synchronization delay;

[0122] Based on the target data, optimize any one or more of the following strategies: test task generation strategy, test scenario generation strategy, queue type selection strategy, secure transmission protocol determination strategy, and encryption algorithm combination determination strategy.

[0123] It should be noted that the information interaction and execution process between the above-mentioned units are based on the same concept as the method embodiments of this application. Their specific functions and technical effects can be referred to the method embodiments section, and will not be repeated here.

[0124] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 provided in this embodiment may include: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program for a message queue testing method for a consortium blockchain. When the processor 30 executes the computer program 32, it implements the steps described above in the embodiment of the message queue testing method for a consortium blockchain, for example... Figure 1S101~S105 are shown. Alternatively, when processor 30 executes computer program 32, it implements the functions of each module / unit in the above embodiment of the consortium blockchain message queue testing device, for example... Figure 2 The functions of units 21-25 shown.

[0125] For example, computer program 32 can be divided into one or more modules / units, one or more of which are stored in memory 31 and executed by processor 30 to complete this application. 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 computer program 32 in electronic device 3. For example, computer program 32 can be divided into a first determining unit 21, a scheduling unit 22, a selection unit 23, a second determining unit 24, and a testing unit 25. For the specific functions of each unit, please refer to [link to relevant documentation]. Figure 2 The relevant descriptions in the corresponding embodiments are not repeated here.

[0126] Those skilled in the art will understand that Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or use different components.

[0127] The processor 30 can be a central processing unit (CPU), or 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 can be a microprocessor or any conventional processor.

[0128] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, or flash card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0129] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units is merely an example. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the consortium blockchain message queue testing device can be divided into different functional units to complete all or part of the functions described above. The functional units 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 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 in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0130] This application also 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.

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

[0132] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, refer to the relevant descriptions of other embodiments.

[0133] 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.

[0134] 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 message queue testing method for a consortium blockchain, characterized in that, include: Determine the target parameters based on the test cases corresponding to the message queue to be tested in the consortium blockchain; Based on the target parameters, test tasks and test scenarios are generated, and test resources are scheduled according to the test tasks and test scenarios. Select the message queue type of the message queue to be tested based on the target parameters; Based on the target parameters and the test scenario, determine the target secure transmission protocol and the target encryption algorithm; The message queue to be tested is encrypted using the test task, the test scenario, the test resources, the message queue type, the target secure transmission protocol, and the target encryption algorithm. The target parameters include the business load characteristics of the consortium blockchain, the inter-node communication latency of the consortium blockchain, the consensus algorithm type of the consortium blockchain, and the message flow distribution mode of the consortium blockchain; the step of selecting the message queue type of the message queue to be tested according to the target parameters includes: The message queue type of the message queue to be tested is selected based on the business load characteristics, the inter-node communication latency, the consensus algorithm type, the message flow distribution mode, the target selection weight corresponding to each candidate message queue type, and the preset queue type selection strategy; the message flow distribution mode refers to the transmission path, flow characteristics, or distribution density of messages between different nodes in the consortium blockchain.

2. The method according to claim 1, characterized in that, The target parameters include the node type of the consortium blockchain, the network topology of the consortium blockchain, the configuration parameters of the message queue to be tested, the test task generation strategy, and the test scenario generation strategy. The step of generating test tasks and test scenarios based on the target parameters includes: The test task is generated based on the node type, the network topology, the configuration parameters, and the test task generation strategy. The test scenario is generated based on historical test data, custom test parameters, and the test scenario generation strategy.

3. The method according to claim 1, characterized in that, The target selection weight corresponding to each of the candidate message queue types is determined in the following way: The target operating metric of the consortium blockchain is used as a reward function and input into the trained weight selection model to instruct the weight selection model to optimize and output the initial selection weights corresponding to each of the candidate message queue types according to the target operating metric; the target operating metric includes any one or more of the following: transaction processing per second, message latency, message processing error rate, and message retry rate; The optimized initial selection weights corresponding to each of the candidate message queue types are respectively determined as the target selection weights corresponding to each of the candidate message queue types.

4. The method according to claim 1, characterized in that, The target parameters include the security level of the consortium blockchain and the testing strategy of the consortium blockchain; determining the target secure transmission protocol and the target encryption algorithm based on the target parameters and the testing scenario includes: Based on the security level, the testing strategy, the testing scenario, and the preset secure transmission protocol, a strategy is determined, and the target secure transmission protocol is determined from a plurality of preset candidate secure transmission protocols. Based on the target secure transmission protocol, the test scenario, and the preset encryption algorithm combination determination strategy, at least one candidate encryption algorithm combination is determined; each candidate encryption algorithm combination includes several encryption algorithms. Based on the test scenario, the performance parameters corresponding to each of the candidate encryption algorithm combinations are determined, and based on the performance parameters, the target encryption algorithm combination is determined from each of the candidate encryption algorithm combinations. The various encryption algorithms included in the target encryption algorithm combination are collectively determined as the target encryption algorithm.

5. The method according to claim 2, characterized in that, The encryption test of the message queue to be tested, using the test task, the test scenario, the test resources, the message queue type, the target secure transmission protocol, and the target encryption algorithm, includes: Using the test resources, the message queue to be tested is deployed in the test scenario according to the message queue type, the target secure transmission protocol, and the target encryption algorithm. According to the test task, the deployed message queue to be tested is subjected to encryption testing.

6. The method according to any one of claims 1 to 5, characterized in that, After performing encryption testing on the message queue to be tested using the test task, the test scenario, the test resources, the message queue type, the target secure transport protocol, and the target encryption algorithm, the method further includes: Acquire target data generated during the encryption test of the message queue to be tested; the target data includes any one or more of the following: block generation rate, message backlog length, and node synchronization delay; Based on the target data, optimize any one or more of the following strategies: test task generation strategy, test scenario generation strategy, queue type selection strategy, secure transmission protocol determination strategy, and encryption algorithm combination determination strategy.

7. A message queue testing device for a consortium blockchain, characterized in that, include: The first determining unit is used to determine the target parameters based on the test cases corresponding to the message queue to be tested in the consortium blockchain; The scheduling unit is used to generate test tasks and test scenarios according to the target parameters, and to schedule test resources according to the test tasks and test scenarios; The selection unit is used to select the message queue type of the message queue to be tested according to the target parameters. The second determining unit is used to determine the target secure transmission protocol and the target encryption algorithm based on the target parameters and the test scenario. The testing unit is used to perform encryption testing on the message queue to be tested using the test task, the test scenario, the test resources, the message queue type, the target secure transmission protocol, and the target encryption algorithm. The target parameters include the business load characteristics of the consortium blockchain, the inter-node communication latency of the consortium blockchain, the consensus algorithm type of the consortium blockchain, and the message flow distribution mode of the consortium blockchain; the selection unit is specifically used for: The message queue type of the message queue to be tested is selected based on the business load characteristics, the inter-node communication latency, the consensus algorithm type, the message flow distribution pattern, the target selection weight corresponding to each candidate message queue type, and the preset queue type selection strategy.

8. An electronic 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 each step of the message queue testing method for consortium blockchains as described in any one of claims 1 to 6.

9. A computer program product, characterized in that, When the computer program product is executed by a processor, it implements the steps of the message queue testing method for consortium blockchains as described in any one of claims 1 to 6.

Images