A high-compatibility blockchain SDK testing method and system, and a storage medium

Abstract

The application relates to the technical field of blockchain testing, in particular to a high-compatibility blockchain SDK testing method and system and a storage medium, wherein the method comprises the following steps: a use case layer stores a plurality of test cases; an adaptation layer provides a function calling interface for adapting a plurality of kinds of SDKs; a performing layer receives a first test instruction, and the test comprises executing a test script according to a parameter configuration table; the execution result of a function test program segment is recorded and written into a result reference file; the test instruction for other kinds of SDKs is received, and the test script is executed on the SDK; the execution result of the function test program segment is compared with the result reference file, if the execution result is consistent, the function test is passed; if all the function tests are passed, the SDK test is passed. The application has the beneficial technical effects that after one-time operation test, subsequent SDK tests of other language kinds can be automatically performed, and the compatibility and test efficiency of the SDK test are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain testing technology, and specifically to a highly compatible blockchain SDK testing method, system, and storage medium. Background Technology

[0002] Blockchain is essentially a decentralized database. It's a novel application model combining computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Blockchain systems naturally establish trusted proofs among users and possess characteristics of joint maintenance, transparency, and traceability, thus gaining widespread attention. It has been widely adopted in the financial, logistics, public service, digital copyright, and insurance sectors. Currently, users access blockchain through SDKs. This primarily includes deploying, calling, upgrading, and freezing smart contracts. To meet customer needs for different languages, various language-specific SDKs are available. Each SDK provides a complete interface for calling the blockchain. While this facilitates user access, it requires functional testing for each SDK, resulting in a large amount of repetitive testing work. Therefore, it's necessary to research technologies that can reduce the testing workload of SDKs in different languages.

[0003] Chinese patent document CN115292174A discloses a blockchain testing method and system. The blockchain testing system is generated by integrating a blockchain testing plugin into an interface testing tool. The blockchain testing plugin includes a blockchain software development kit (SDK) and multiple functional testing interfaces. Its technical solution involves obtaining a blockchain functional testing request, which carries a functional category identifier; responding to the request, determining the target functional testing interface that matches the functional category identifier from among multiple functional testing interfaces; and then calling the blockchain SDK through the target functional testing interface to perform the corresponding functional tests. However, this technical solution cannot solve the problem of testing multiple SDKs adapted to different languages. Summary of the Invention

[0004] The technical problem this invention aims to solve is the current lack of technical solutions for testing blockchain SDKs that are compatible with multiple languages. This invention proposes a highly compatible blockchain SDK testing method, system, and storage medium, which can improve the testing efficiency of SDKs in multiple languages.

[0005] To address the aforementioned technical problems, this invention employs the following technical solution: a highly compatible blockchain SDK testing method, used for execution on a testing system including a test case layer, an execution layer, and an adaptation layer, comprising the following steps:

[0006] The test case layer stores several test cases, each test case including a parameter configuration table and a test script, and the test script including several functional test program segments;

[0007] The adaptation layer provides function call interfaces for adapting to multiple types of SDKs;

[0008] The execution layer receives the initial test instruction and tests the selected SDK type. The test includes executing a test script according to the parameter configuration table.

[0009] During the initial test, the execution layer records the execution results of the functional test program segment and packages the execution results into a result reference file.

[0010] The execution layer receives test instructions for other types of SDKs, reads test cases, and executes test scripts on the SDK through the function call interface corresponding to the SDK type.

[0011] During the execution of the test script in the execution layer, the execution result of the functional test program segment is compared with the result reference file. If they match, the functional test passes; otherwise, the functional test fails.

[0012] If all functional tests pass, the SDK test passes; otherwise, if any functional test fails, the SDK test fails.

[0013] Preferably, the parameter configuration table of the test case records the number of times the test script is executed, the number of threads, the dataset path, and the execution timeout. The adaptation layer provides a configuration interface for modifying the parameter configuration table, and the test instructions include instructions for modifying the parameter configuration table.

[0014] Preferably, the test instructions include a list of functions to be tested, and when the execution layer executes the test script, it performs the following steps:

[0015] The execution layer selects the corresponding test cases based on the list of functions to be tested;

[0016] The functional test program segment of the test script is executed according to the number of times and the number of threads specified in the parameter configuration table.

[0017] If the functional test program segment is executed within the execution timeout period and matches the result reference file, the corresponding functional test is deemed to have passed. Otherwise, if the execution times out or the execution result does not match the result reference file, the corresponding functional test is deemed to have failed.

[0018] Preferably, when the execution layer executes the test script, it also performs the following steps:

[0019] The execution layer randomly generates the number of concurrent users;

[0020] The execution layer executes a corresponding number of functional test program segments concurrently based on the generated concurrency level.

[0021] If all concurrent functional test segments complete execution within the timeout period and the execution results match the result reference file, the corresponding functional test is deemed to have passed. Conversely, if any functional test segment times out or the execution result does not match the result reference file, the corresponding functional test is deemed to have failed.

[0022] Preferably, the method for the execution layer to execute the functional test program segment of the test script includes:

[0023] The execution layer randomly generates the data required for the functional test program segment and stores it in the dataset path in the parameter configuration table;

[0024] The execution layer calls the function call interface provided by the adaptation layer to execute the function in the function test program segment, and the function call interface uses the data specified by the dataset path;

[0025] The execution layer records the execution results of the functional test program segment.

[0026] As a preferred method, the execution layer records the execution results of the functional test program segment, including:

[0027] The execution layer records the data-independent execution results of the functional test program segment.

[0028] Preferably, the method for recording the data-independent execution results of the functional test program segment at the execution layer includes:

[0029] The execution layer executes the functional test program segment multiple times using different data and records the execution result of each execution.

[0030] Compare the results of multiple executions, and use the identical parts as the final recorded execution results of the functional test program segment, which are unrelated to the data.

[0031] A blockchain SDK testing system is provided for executing the aforementioned highly compatible blockchain SDK testing method, including a test case layer, an execution layer, and an adaptation layer.

[0032] The test case layer stores several test cases, each test case including a parameter configuration table and a test script. Each test script includes several functional test program segments.

[0033] The adaptation layer provides function call interfaces for adapting to multiple types of SDKs.

[0034] The execution layer receives the initial test instruction and tests the selected SDK type. The test includes executing a test script according to a parameter configuration table.

[0035] During the initial testing, the execution layer records the execution results of the functional test program segments and packages the execution results into a result reference file.

[0036] The execution layer receives test instructions for other types of SDKs, reads test cases, and executes test scripts on the SDK through the corresponding SDK type's function call interface.

[0037] During the execution of the test script in the execution layer, the execution result of the functional test program segment is compared with the result reference file. If they match, the functional test passes; otherwise, the functional test fails.

[0038] If all functional tests pass, the SDK test passes; otherwise, if any functional test fails, the SDK test fails.

[0039] A computer system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the aforementioned highly compatible blockchain SDK testing method.

[0040] A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, which, when executed by a processor, implements the aforementioned highly compatible blockchain SDK testing method.

[0041] The beneficial technical effects of this invention include: recording the execution result and generating a result reference file when executing the first test instruction; providing basic function calls for different languages ​​through an adaptation layer, enabling the execution of functional test program segments in multiple languages; and obtaining the execution results of functional test program segments through the result reference file. This allows subsequent SDK tests in other languages ​​to be performed automatically after one test, significantly improving SDK testing compatibility and efficiency. The parameter configuration table allows control over the number of test executions and execution timeouts, providing rich test configuration methods and expanding the applicability of SDK testing. Furthermore, the execution results, independent of data, accurately record key execution results of functional test program segments, providing valuable reference results for testing other SDKs.

[0042] Other features and advantages of the present invention will be disclosed in detail in the following detailed description and accompanying drawings. Attached Figure Description

[0043] The invention will be further described below with reference to the accompanying drawings:

[0044] Figure 1This is a schematic diagram of the blockchain SDK testing method according to an embodiment of the present invention.

[0045] Figure 2 This is a schematic diagram of the method flow for executing test scripts in the execution layer according to an embodiment of the present invention.

[0046] Figure 3 This is a schematic diagram of the method for concurrent execution of test scripts in the execution layer according to an embodiment of the present invention.

[0047] Figure 4 This is a schematic diagram of the method flow for executing the functional test program segment in an embodiment of the present invention.

[0048] Figure 5 This is a schematic diagram of the blockchain SDK testing system structure according to an embodiment of the present invention.

[0049] Figure 6 This is a schematic diagram of the computer system structure according to an embodiment of the present invention.

[0050] The components are: 10. Test Case Layer, 11. Parameter Configuration Table, 12. Test Script, 20. Execution Layer, 21. Test Case Execution Module, 22. Random Data Generation and Concurrency Module, 23. Recording Module, 24. Automatic Execution Module, 30. Adaptation Layer, 31. Service API, 32. Config, 33. Utils, 34. Data, 40. Computer System, 41. Memory, 42. Computer Program, 43. Processor. Detailed Implementation

[0051] The technical solutions of the embodiments of the present invention will be explained and described below with reference to the accompanying drawings. However, the following embodiments are only preferred embodiments of the present invention and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments in the implementation methods without creative effort are all within the protection scope of the present invention.

[0052] In the following description, terms such as “inner,” “outer,” “upper,” “lower,” “left,” and “right” are used only to indicate orientation or positional relationship for the convenience of describing the embodiments and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention.

[0053] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0054] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in 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 application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. Furthermore, the terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0055] Before introducing the technical solution of this embodiment, the application scenario and related technologies of this embodiment will be introduced.

[0056] SDK, short for Software Development Kit, refers to a blockchain application toolkit in this example. In blockchain applications, applications that directly provide services to users do not interact directly with the blockchain but indirectly manipulate it using an SDK. Common blockchain operations include contract deployment, invocation, and update; and query operations such as querying block information (getBlockByHash) and node information (getNodeHash). Common SDKs include Java SDK, Go SDK, and Js SDK, corresponding to applications written in Java, Go, and JavaScript, respectively. Testing blockchain SDKs requires testing SDKs in different languages, resulting in a heavy workload. Therefore, it is necessary to research highly compatible blockchain SDK testing solutions that can achieve cross-language compatibility to reduce the workload of blockchain SDK testing.

[0057] This embodiment provides a highly compatible blockchain SDK testing method for execution on a test system including a test case layer 10, an execution layer 20, and an adaptation layer 30. Please refer to the appendix. Figure 1 This includes the following steps:

[0058] Step A01) The test case layer 10 stores several test cases. The test cases include a parameter configuration table 11 and a test script 12. The test script 12 includes several functional test program segments.

[0059] Step A02) Adaptation layer 30 provides function call interfaces for adapting to multiple types of SDKs;

[0060] Step A03) Execution layer 20 receives the first test instruction and tests the selected type of SDK. The test includes executing test script 12 according to parameter configuration table 11.

[0061] Step A04) During the initial test, execution layer 20 records the execution results of the functional test program segment and packages the execution results into a result reference file;

[0062] Step A05) Execution layer 20 receives test instructions for other types of SDKs, reads test cases, and executes test script 12 on the SDK through the function call interface of the corresponding SDK type;

[0063] Step A06) During the execution of test script 12 in the execution layer 20, the execution result of the functional test program segment is compared with the result reference file. If they match, the functional test passes; if they do not match, the functional test fails.

[0064] Step A07) If all functional tests pass, the SDK test passes; otherwise, if any functional test fails, the SDK test fails.

[0065] When testing blockchain SDKs in different languages, calling function calls is easy because the total number of function types is limited and can be achieved through exhaustive enumeration. However, judging the results of each function test in different language SDK tests is something that existing technologies cannot achieve. The blockchain SDK testing method provided in this embodiment first selects a blockchain SDK in any language and uses the execution method of the use case layer 10, execution layer 20, and adaptation layer 30 provided in this embodiment to conduct manual testing. During the testing process, the execution layer 20 records the execution results of each function test program segment. Since the execution results will inevitably differ due to different data and parameters, the parts unrelated to the data will be consistent. For example, in the contract deployment function, when a smart contract is successfully deployed on the blockchain using the blockchain SDK, the blockchain will return a contract ID. When the contract ID is not empty, it means the contract deployment was successful; therefore, a non-empty contract ID is used as the execution result, rather than directly using the contract ID as the execution result. The specific content recorded as execution results for each functional program segment is determined directly and unambiguously by the functional program segment itself, and therefore can be determined and implemented by those skilled in the art. In testing blockchain SDKs in other languages, comparing the execution results of the functional test program segments with the result reference file determines whether the corresponding functions of the blockchain SDK can be executed correctly.

[0066] The test cases in this embodiment include both parameter configuration table 11 and test script 12, with test script 12 comprising several functional test program segments. Each test case targets a single SDK function or several related SDK functions. The functional test program segments included in test script 12 are functional test program segments compiled for different testing methods of the same SDK function. For example, the functional test of blockchain SDK contract calls includes both direct call methods and condition-triggered call methods. Therefore, there will be two corresponding functional test program segments: one for direct call testing and the other for setting trigger conditions and automatically providing the trigger conditions through the program after setting them.

[0067] Test scripts 12 in different languages ​​are also easily implemented. They can be written manually through exhaustive search, or existing language conversion tools can be used to convert a test script 12 in one language to another. However, this embodiment provides function call interfaces for different languages ​​through the adaptation layer 30, allowing the test script 12 to be written in any language. When a function needs to be called in the test script 12, the corresponding SDK language function call interface implementation is automatically selected from the adaptation layer 30.

[0068] The parameter configuration table 11 of the test case records the number of times the test script 12 is executed, the number of threads, the dataset path, and the execution timeout. The adaptation layer 30 provides a configuration interface for modifying the parameter configuration table 11, and the test instructions include instructions for modifying the parameter configuration table 11.

[0069] The parameter configuration table 11 records the number of executions, number of threads, dataset path, and execution timeout of test script 12, guiding its execution. Furthermore, the configuration interface provided by the adaptation layer 30 for modifying parameter configuration table 11 allows for customized parameter configurations, providing richer testing methods. Although the number of executions and the number of threads used in test script 12 may differ after changing the parameter configuration, the results after each execution should still match the result reference file. The data corresponding to the dataset path may also differ, but the execution results recorded in the result reference file are data-independent; therefore, comparing the results with the execution result file allows for the determination of whether the execution result of the corresponding function's test script 12 program segment is correct.

[0070] The test instructions include a list of functions to be tested; please refer to the appendix. Figure 2 When execution layer 20 executes test script 12, the following steps are performed:

[0071] Step B01) Execution layer 20 selects the corresponding test cases based on the list of functions to be tested;

[0072] Step B02) Execute the functional test program segment of test script 12 according to the number of executions and threads specified in parameter configuration table 11;

[0073] Step B03) If the functional test program segment is executed within the execution timeout period and matches the result reference file, the corresponding functional test is deemed to have passed. Otherwise, if the execution times out or the execution result does not match the result reference file, the corresponding functional test is deemed to have failed.

[0074] The implementation can specify a list of functions to be tested for each test, or a unified list of functions to be tested can be used, because although the languages ​​of the blockchain SDKs are different, the functions they can provide are the same. If the functional test program segment is executed within the execution timeout period and matches the result reference file, the corresponding functional test is considered passed, a test result file is generated, and the test results for each function are displayed.

[0075] When execution layer 20 executes test script 12, test script 12 is executed concurrently to test the concurrency functionality of the blockchain SDK. Please refer to the appendix. Figure 3 Concurrent execution of test script 12 includes the following steps:

[0076] Step C01) Execution layer 20 randomly generates the number of concurrent connections;

[0077] Step C02) Execute layer 20 to generate the number of concurrent executions, and concurrently execute the corresponding number of functional test program segments;

[0078] Step C03) If all concurrent functional test segments complete execution within the timeout period and the execution result matches the result reference file, the corresponding functional test is deemed to have passed. Conversely, if any functional test segment times out or the execution result does not match the result reference file, the corresponding functional test is deemed to have failed.

[0079] Execution layer 20 randomly generates a concurrency level and executes the functional test program segments concurrently according to the concurrency level. If the SDK's concurrency function is normal, all concurrently executed functional test program segments should be executed correctly, and the execution result of each functional test program segment should match the result reference file.

[0080] Please see the appendix Figure 4 The methods by which execution layer 20 executes the functional test program segment of test script 12 include:

[0081] Step D01) Execution layer 20 randomly generates the data required for the functional test program segment and stores it in the dataset path in parameter configuration table 11;

[0082] Step D02) Execution layer 20 calls the function call interface provided by adaptation layer 30 to execute the function in the function test program segment. The function call interface uses the data specified by the dataset path.

[0083] Step D03) Execution layer 20 records the execution results of the execution function test program segment.

[0084] During testing, the dataset path in parameter configuration table 11 can be modified using the adaptation layer 30 based on the actual data location. Alternatively, the actual data can be placed in the corresponding location according to the dataset path in parameter configuration table 11, and then directly called by the functional test program segment. When executing the functional test program segment, the execution layer 20 executes the code through the function call interface provided by the adaptation layer 30. For example, the file reading code in the functional test program segment will be implemented by the file reading code in a language that matches the language of the SDK being tested, provided by the adaptation layer 30. Thus, the functional test program segment can be written in only one language, and the adaptation layer 30 can provide the corresponding language function call interface implementation for SDKs of different languages.

[0085] The method for recording the execution results of the functional test program segment in execution layer 20 includes: recording the data-independent execution results of the functional test program segment in execution layer 20.

[0086] The methods for recording data-independent execution results of functional test program segments in execution layer 20 include:

[0087] Execution layer 20 executes the function test program segment multiple times using different data and records the execution result of each execution;

[0088] By comparing the results of multiple executions, the identical parts are recorded as the final, data-independent execution results of the functional test program segment. The test is repeated using different data, and successful tests are manually calibrated. The results of these successful tests are compared, and the identical parts are recorded as the final, data-independent execution results of the functional test program segment, and entered into a reference file.

[0089] For reference, the result reference file in this embodiment includes account information, contract information, call information, and result information, and is recorded in a JSON file according to a predetermined format. Part of the content of the JSON generated in this embodiment is as follows:

[0090] {

[0091] "Contracts":{

[0092] "DemoContract":{

[0093] "PropPath":"contracts / fvm / docJson / demo / demo.properties",

[0094] "CodePath":"contracts / fvm / docJson / demo / lib.rs",

[0095] "Type":"fvm",

[0096] "Address":

[0097] }

[0098] },

[0099] "Accounts":{

[0100] a:{

[0101] "accountJson":"{\"address\":\"0x46df0dadcb2b7c5687fb1b0d0c219cfd\"}",

[0102] "adress":"0x611237c1e0730987cb67b06081619af1",

[0103] "passwd":"12345600",

[0104] "type":"ECDSA_GENESIS_4"

[0105] }

[0106] }

[0107] "Prepares":[{

[0108] "AccountRef":"a",

[0109] "ContractRef":"DemoContract",

[0110] "IsArgs":"false",

[0111] "Args":[{

[0112] "ArgsType":"",

[0113] "ArgsData34":""

[0114] }]

[0115] }],

[0116] "Invokes":[{

[0117] "ContractRef":"DemoContract",

[0118] "AccountRef":"a",

[0119] "Method":{

[0120] "MethodName":"set_hash",

[0121] "Args":[{

[0122] "ArgsType":"String",

[0123] "ArgsData34":["key001","key002"]

[0124] },{

[0125] "ArgsType":"String",

[0126] "ArgsData34":["value001","value002"]

[0127] }]

[0128] }

[0129] },

[0130] "OptType":"invoke",

[0131] "Extra":"",

[0132] "Expected":{

[0133] "Receipt":["",""],

[0134] "ReceiptLog":["",""],

[0135] "ReceiptErr":["",""]

[0136] }

[0137] }]

[0138] }

[0139] The Contracts field includes contract-related information: contract name, API, source file, type, and address.

[0140] The Accounts field includes relevant account information: the account's JSON file, password, and type.

[0141] The Prepares field includes information related to the deployment contract: the deployer account, the contract, and whether constructor parameters are included.

[0142] The Invokes field includes information related to the contract operation: the contract invoked, the caller's account, the method, the parameters, the type of operation on the contract, and the return value.

[0143] The above is a simple example of a JSON file recorded after a test case is executed. Other SDKs can use this JSON file to compare the execution results.

[0144] A blockchain SDK testing system for executing the aforementioned highly compatible blockchain SDK testing method; please refer to the appendix. Figure 5 It includes the use case layer 10, the execution layer 20, and the adaptation layer 30.

[0145] The test case layer 10 stores several test cases. Each test case includes a parameter configuration table 11 and a test script 12. The test script 12 includes several functional test program segments.

[0146] Adaptation layer 30 provides function call interfaces for adapting to multiple types of SDKs.

[0147] The execution layer 20 receives the initial test command and tests the selected SDK type. The test includes executing test script 12 according to parameter configuration table 11.

[0148] During the initial testing, execution layer 20 records the execution results of the functional test program segments and packages the execution results into a result reference file.

[0149] The execution layer 20 receives test instructions for other types of SDKs, reads test cases, and executes test script 12 on the SDK through the corresponding SDK type's function call interface.

[0150] During the execution of test script 12 in the execution layer 20, the execution result of the functional test program segment is compared with the result reference file. If they match, the functional test passes; otherwise, the functional test fails.

[0151] If all functional tests pass, the SDK test passes; otherwise, if any functional test fails, the SDK test fails.

[0152] Furthermore, this embodiment provides a system for implementing blockchain SDK testing. The test case layer 10 stores test cases. The adaptation layer 30 provides function call interfaces corresponding to SDKs in multiple languages ​​to implement basic function functionalities, allowing test cases to be written in only one language.

[0153] Specifically, the adaptation layer 30 includes the following four modules: Service API 31, which provides the implementation and encapsulation of function call interfaces; Config 32, which provides reading and modification of various configuration files, including modification of the parameter configuration table 11 for test cases; Utils 33, which provides the implementation and encapsulation of function call interfaces for basic public methods; and Data 34, which provides interfaces for generating various types of data to generate data matching the test script 12 for the execution layer 20, such as randomly generating blockchain virtual accounts and corresponding private keys, and providing the execution layer 20 with randomly generated transaction information, smart contract names, and randomly generated smart contract call requests. Service API 31 includes: HTTP service for sending transactions to blockchain nodes; fuzzyData 34 for generating the required data of this type; parseData 34 for parsing and modifying various files; and multithread for controlling the number of concurrent threads.

[0154] The execution layer 20 is used to execute test cases and test the target SDK. Specifically, the execution layer 20 includes a test case execution module 21, a random data generation and concurrency module 22, a recording module 23, and an automatic execution module 24. The test case execution module 21 executes the initial test command. The random data generation and concurrency module 22 calls the Data34 interface of the adaptation layer 30 to generate the data required for the test cases and simultaneously generate the concurrency count. The recording module 23 records the execution results of the functional test program segments generated during the initial test command and packages the execution results into a result reference file. The automatic execution module 24 automatically implements tests for SDKs in other languages ​​based on the test cases and the result reference file.

[0155] A computer system 40, please refer to the appendix. Figure 6 The computer system 40 includes a memory 41, a processor 43, and a computer program 42 stored in the memory 41 and executable on the processor 43. When the computer program 42 is executed by the processor 43, it implements the highly compatible blockchain SDK testing method described above.

[0156] Computer system 40 can be a general-purpose computer system 40 or a special-purpose computer system 40. In a specific implementation, computer system 40 can be a server cluster including multiple servers. Those skilled in the art will understand that... Figure 6 This is merely an example of computer system 40 and does not constitute a limitation on computer system 40. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0157] Processor 43 can be a Central Processing Unit (CPU), or it can 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. General-purpose processor 43 can be a microprocessor or any conventional processor.

[0158] In some embodiments, memory 41 may be an internal storage unit of computer system 40, such as a hard disk or RAM of computer system 40. In other embodiments, memory 41 may be an external storage device of computer system 40, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on computer system 40. Furthermore, memory 41 may include both internal storage units and external storage devices of computer system 40. Memory 41 is used to store operating system, application programs, boot loader, data, and other programs. Memory 41 may also be used to temporarily store data that has been output or will be output.

[0159] A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program 42, which, when executed by a processor 43, implements the aforementioned highly compatible blockchain SDK testing method.

[0160] The beneficial technical effects of this invention include: by recording the execution result and generating a result reference file when executing the first test instruction, and by providing basic function calls for different languages ​​through the adaptation layer 30, it is possible to execute functional test program segments in multiple languages ​​and obtain the execution results of the functional test program segments through the result reference file. This enables subsequent SDK tests in other languages ​​to be performed automatically after one test, significantly improving the compatibility and efficiency of SDK testing; the parameter configuration table 11 can control the number of test executions and execution timeouts, providing rich test configuration methods and improving the applicability of SDK testing; and the execution results, which are independent of data, can accurately record the key execution results of the functional test program segments, providing valuable reference results for testing other SDKs.

[0161] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the contents described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A highly compatible blockchain SDK testing method, used for execution on a test system including a test case layer, an execution layer, and an adaptation layer, characterized in that, Includes the following steps: The test case layer stores several test cases, each test case including a parameter configuration table and a test script, and the test script including several functional test program segments; The adaptation layer provides function call interfaces for adapting to multiple types of SDKs; The execution layer receives the initial test instruction and tests the selected SDK type. The test includes executing a test script according to the parameter configuration table. During the initial test, the execution layer records the execution results of the functional test program segment and packages the execution results into a result reference file. The execution layer receives test instructions for other types of SDKs, reads test cases, and executes test scripts on the SDK through the function call interface corresponding to the SDK type. During the execution of the test script in the execution layer, the execution result of the functional test program segment is compared with the result reference file. If they match, the functional test passes; otherwise, the functional test fails. If all functional tests pass, the SDK test passes; otherwise, if any functional test fails, the SDK test fails. Methods for recording the execution results of functional test program segments at the execution layer include: The execution layer records the data-independent execution results of the functional test program segment.

2. The highly compatible blockchain SDK testing method according to claim 1, characterized in that, The parameter configuration table of the test cases records the number of times the test script is executed, the number of threads, the dataset path, and the execution timeout. The adaptation layer provides a configuration interface for modifying the parameter configuration table, and the test instructions include instructions for modifying the parameter configuration table.

3. The highly compatible blockchain SDK testing method according to claim 2, characterized in that, The test instructions include a list of functions to be tested. When the execution layer executes the test script, it performs the following steps: The execution layer selects the corresponding test cases based on the list of functions to be tested; The functional test program segment of the test script is executed according to the number of times and the number of threads specified in the parameter configuration table. If the functional test program segment is executed within the execution timeout period and matches the result reference file, the corresponding functional test is deemed to have passed. Otherwise, if the execution times out or the execution result does not match the result reference file, the corresponding functional test is deemed to have failed.

4. The highly compatible blockchain SDK testing method according to claim 3, characterized in that, When the execution layer executes the test script, it also performs the following steps: The execution layer randomly generates the number of concurrent users; The execution layer executes a corresponding number of functional test program segments concurrently based on the generated concurrency level. If all concurrent functional test segments complete execution within the timeout period and the execution results match the result reference file, the corresponding functional test is deemed to have passed. Conversely, if any functional test segment times out or the execution result does not match the result reference file, the corresponding functional test is deemed to have failed.

5. A highly compatible blockchain SDK testing method according to any one of claims 1 to 4, characterized in that, The method for the execution layer to execute the functional test program segment of the test script includes: The execution layer randomly generates the data required for the functional test program segment and stores it in the dataset path in the parameter configuration table; The execution layer calls the function call interface provided by the adaptation layer to execute the function in the function test program segment, and the function call interface uses the data specified by the dataset path; The execution layer records the execution results of the functional test program segment.

6. The highly compatible blockchain SDK testing method according to claim 1, characterized in that, The method for recording the data-independent execution results of the functional test program segment at the execution layer includes: The execution layer executes the functional test program segment multiple times using different data and records the execution result of each execution. Compare the results of multiple executions, and use the identical parts as the final recorded execution results of the functional test program segment, which are unrelated to the data.

7. A blockchain SDK testing system for executing the highly compatible blockchain SDK testing method as described in any one of claims 1 to 6, characterized in that, It includes the use case layer, execution layer, and adaptation layer. The test case layer stores several test cases, each test case including a parameter configuration table and a test script. Each test script includes several functional test program segments. The adaptation layer provides function call interfaces for adapting to multiple types of SDKs. The execution layer receives the initial test instruction and tests the selected SDK type. The test includes executing a test script according to a parameter configuration table. During the initial testing, the execution layer records the execution results of the functional test program segments and packages the execution results into a result reference file. The execution layer receives test instructions for other types of SDKs, reads test cases, and executes test scripts on the SDK through the corresponding SDK type's function call interface. During the execution of the test script in the execution layer, the execution result of the functional test program segment is compared with the result reference file. If they match, the functional test passes; otherwise, the functional test fails. If all functional tests pass, the SDK test passes; otherwise, if any functional test fails, the SDK test fails.

8. A computer system, characterized in that, The computer system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the highly compatible blockchain SDK testing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the highly compatible blockchain SDK testing method as described in any one of claims 1 to 6.

Images