A method and system for block function testing
By leveraging the spiderweb-like characteristics of blockchain systems, the server pushes a task list to the test block, which then generates a task queue and iterates through nodes to execute tasks. This solves the problems of low testing efficiency and high resource consumption in blockchain systems, achieving low-loss asynchronous data sharing and efficient test result reception.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- 福建天晴在线互动科技有限公司
- Filing Date
- 2024-06-11
- Publication Date
- 2026-07-31
AI Technical Summary
Functional testing of blockchain systems suffers from inefficiency and high resource consumption, particularly in terms of data sharing and testing latency, which are difficult to improve.
The test task list is pushed to the test block by the server. The test block generates a task queue based on the task list and traverses the block nodes. After matching the test tasks, the task is executed on the node and the result is returned after execution. The asynchronous data sharing is achieved by using the block spider web feature.
Low-loss block function testing was achieved. The server does not need to wait for test results in real time, but can receive task execution results periodically, which improves testing efficiency and reduces resource consumption.
Smart Images
Figure CN118733547B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of block testing, and in particular to a method and system for testing block functionality. Background Technology
[0002] With the rapid development of blockchain technology, it has been widely applied in various fields such as finance, supply chain management, and the Internet of Things. However, the complexity and distributed nature of blockchain systems make functional testing an important and complex task. Traditional functional testing methods typically rely on real-time synchronous data sharing and centralized task management, which is not only inefficient in blockchain systems but may also lead to high resource consumption and test delays.
[0003] One of the characteristics of blockchain systems is the distributed storage and updating of data, which means that data consistency and correctness among nodes must be ensured during testing. Furthermore, the consensus mechanism and smart contract execution of the blockchain are also key aspects of functional testing. However, existing testing methods often suffer from problems such as difficulty in improving testing efficiency and high resource consumption. Summary of the Invention
[0004] The technical problem to be solved by the present invention is to provide a method and system for testing block functionality, which can utilize the characteristics of block spider web to achieve asynchronous data sharing in order to achieve low-loss testing.
[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:
[0006] A method for testing block functionality includes the following steps:
[0007] The server pushes the test task list to the test block;
[0008] The test block obtains a test task queue based on the test task list, traverses the block nodes according to each test task in the test task queue, and executes the first test task using the first block node when the first test task in the test task queue matches the test attribute of the first block node. At the same time, the information of the next block node is stored in the first block node. After the test task is executed, the task execution result is returned to the server.
[0009] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows:
[0010] A system for testing block functionality includes:
[0011] The server is used to push the list of test tasks to the test block;
[0012] The test block is used to obtain a test task queue based on the test task list, traverse the block nodes according to each test task in the test task queue, and execute the first test task using the first block node when the first test task in the test task queue matches the test attribute of the first block node. At the same time, the information of the next block node is stored in the first block node. After the test task is executed, the task execution result is returned to the server.
[0013] The beneficial effects of this invention are as follows: The test block obtains a test task queue based on the test task list pushed by the server, and traverses the block nodes according to each test task in the test task queue. When the first test task in the test task queue matches the test attribute of the first block node, the first block node is used to execute the first test task. At the same time, the information of the next block node is stored in the first block node. After the test task is completed, the task execution result is returned to the server. In this way, after the server provides the test task list, the task execution results of the test block can be received periodically, without the server needing to actively and in real-time wait for test results. Furthermore, this testing method can utilize the block spider web characteristic to achieve asynchronous data sharing, thereby achieving low-loss testing. Attached Figure Description
[0014] Figure 1 This is a flowchart illustrating a method for testing block functionality according to an embodiment of the present invention;
[0015] Figure 2 This is a schematic diagram of a block function testing system according to an embodiment of the present invention;
[0016] Figure 3 This is an internal relationship diagram of a block function testing system according to an embodiment of the present invention. Detailed Implementation
[0017] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.
[0018] Definitions:
[0019] Detached testing means the server is offline. After the task is published, all relevant blocks are traversed, spreading out layer by layer like a spider web, hence the detached nature of the test. The task is reported to the server only after the server comes online, or when the test client is offline.
[0020] Please refer to Figure 1 This invention provides a method for testing block functionality, comprising the following steps:
[0021] The server pushes the test task list to the test block;
[0022] The test block obtains a test task queue based on the test task list, traverses the block nodes according to each test task in the test task queue, and executes the first test task using the first block node when the first test task in the test task queue matches the test attribute of the first block node. At the same time, the information of the next block node is stored in the first block node. After the test task is executed, the task execution result is returned to the server.
[0023] As described above, the beneficial effects of this invention are as follows: The test block obtains a test task queue based on the test task list pushed by the server, and traverses the block nodes according to each test task in the test task queue. When the first test task in the test task queue matches the test attribute of the first block node, the first block node is used to execute the first test task. Simultaneously, the information of the next block node is stored in the first block node. After the test task is completed, the task execution result is returned to the server. In this way, after the server provides the test task list, the task execution results of the test block can be received periodically, without the server needing to actively and in real-time wait for test results. Furthermore, this testing method can utilize the characteristics of the block spider web to achieve asynchronous data sharing, thereby achieving low-loss testing.
[0024] Furthermore, the test block obtains a test task queue based on the test task list, which then includes:
[0025] The test block parses and stores the corresponding test target attributes and task status for each test task according to the test task queue.
[0026] As described above, once the test block obtains the test task queue, it can determine the test target attributes and task status of each test task, so as to match the appropriate block node for testing different test tasks and facilitate the management of test tasks.
[0027] Furthermore, the information of the next block node is simultaneously stored in the first block node, including:
[0028] The test block continues to match block nodes according to the first test task, and stores the information of the next matched block node into the first block node.
[0029] As described above, when the first test task in the test task queue matches the test attributes of the first block node, a handshake connection for the next block is performed for the first test task, and the information of the next block node is stored in the first block node for use when the test block is free.
[0030] Furthermore, after the test task is completed, it also includes:
[0031] Update the task status corresponding to the test task.
[0032] As described above, updating the task status based on the task's return information allows for understanding the specific details of the test through the test block, ensuring the reliability of the testing process.
[0033] Furthermore, it also includes:
[0034] After the test block completes its task by traversing the block nodes according to each test task in the test task queue, it returns the total task execution result of the test task queue to the server.
[0035] As described above, in addition to receiving the periodic results returned by individual tasks, the server can also receive the total task execution results provided by the test blocks, without requiring the server to wait for each block to submit test results in real time, thereby reducing test overhead.
[0036] Please refer to Figure 2 Another embodiment of the present invention provides a system for testing block functionality, comprising:
[0037] The server is used to push the list of test tasks to the test block;
[0038] The test block is used to obtain a test task queue based on the test task list, traverse the block nodes according to each test task in the test task queue, and execute the first test task using the first block node when the first test task in the test task queue matches the test attribute of the first block node. At the same time, the information of the next block node is stored in the first block node. After the test task is executed, the task execution result is returned to the server.
[0039] As described above, the beneficial effects of this invention are as follows: The test block obtains a test task queue based on the test task list pushed by the server, and traverses the block nodes according to each test task in the test task queue. When the first test task in the test task queue matches the test attribute of the first block node, the first block node is used to execute the first test task. Simultaneously, the information of the next block node is stored in the first block node. After the test task is completed, the task execution result is returned to the server. In this way, after the server provides the test task list, the task execution results of the test block can be received periodically, without the server needing to actively and in real-time wait for test results. Furthermore, this testing method can utilize the characteristics of the block spider web to achieve asynchronous data sharing, thereby achieving low-loss testing.
[0040] Furthermore, the test block obtains a test task queue based on the test task list, which then includes:
[0041] The test block parses and stores the corresponding test target attributes and task status for each test task according to the test task queue.
[0042] As described above, once the test block obtains the test task queue, it can determine the test target attributes and task status of each test task, so as to match the appropriate block node for testing different test tasks and facilitate the management of test tasks.
[0043] Furthermore, the information of the next block node is simultaneously stored in the first block node, including:
[0044] The test block continues to match block nodes according to the first test task, and stores the information of the next matched block node into the first block node.
[0045] As described above, when the first test task in the test task queue matches the test attributes of the first block node, a handshake connection for the next block is performed for the first test task, and the information of the next block node is stored in the first block node for use when the test block is free.
[0046] Furthermore, after the test task is completed, it also includes:
[0047] Update the task status corresponding to the test task.
[0048] As described above, updating the task status based on the task's return information allows for understanding the specific details of the test through the test block, ensuring the reliability of the testing process.
[0049] Furthermore, it also includes:
[0050] After the test block completes its task by traversing the block nodes according to each test task in the test task queue, it returns the total task execution result of the test task queue to the server.
[0051] As described above, in addition to receiving the periodic results returned by individual tasks, the server can also receive the total task execution results provided by the test blocks, without requiring the server to wait for each block to submit test results in real time, thereby reducing test overhead.
[0052] The method and system for block functionality testing described above are suitable for implementing low-loss functionality testing of blocks, where the server does not need to wait for data results in real time. The following is a detailed description of specific implementation methods:
[0053] Example 1
[0054] Please refer to Figure 1 and Figure 3 A method for testing block functionality, comprising the following steps:
[0055] S1. The server pushes the test task list to the test block.
[0056] Specifically, after the server releases the test, the task is traversed by the test block.
[0057] S2. The test block obtains a test task queue based on the test task list, and traverses the block nodes according to each test task in the test task queue. When the first test task in the test task queue matches the test attribute of the first block node, the first test task is executed using the first block node. At the same time, the information of the next block node is stored in the first block node. After the test task is completed, the task execution result is returned to the server.
[0058] The test block includes the following structural information for data storage during free testing:
[0059] The task queue is used to store the types and quantities of test tasks in the test task list;
[0060] Task status is used to store the status of test tasks, such as test completed, test in progress, etc.
[0061] The task return value is used to store the task execution result data.
[0062] Target push, used to store a list of test tasks pushed by the server;
[0063] The source code target is used to store the test target attributes required by the test task, including network attributes, region attributes, and hardware configuration information;
[0064] The target result is used to store the status data of each item in the test task list, and can return the overall task execution result to the server.
[0065] Therefore, after receiving the test task list, the test block can obtain a test task queue, and parse and store the corresponding test target attributes and task status for each test task according to the test task queue. In this embodiment, the test tasks can be interface tests or event tests for game functions.
[0066] Then, the block nodes are traversed according to each test task in the test task queue. When the first test task in the test task queue matches the test attribute of the first block node, the first test task is executed using the first block node. At the same time, the first test task is handshake-connected to the next block and the information of the next block node is stored in the first block node for use when the test block is detached.
[0067] In this embodiment, the block node includes multiple node members. During member configuration, network attributes, regional attributes, and hardware configuration information are configured, where network attributes include network operator category. This approach allows for the collection of different regional attribute data and different hardware configurations across different network attributes. When test data fails, data samples can be compared to analyze whether the failure is due to regional, hardware, or network issues.
[0068] After each test task is completed, the task status corresponding to the test task needs to be updated, and the periodic results of the task execution need to be returned to the server.
[0069] After each test task in the test task queue has completed its traversal of the block nodes, the test block returns the total task execution result of the test task queue to the server.
[0070] Therefore, the block function testing method in this embodiment creates a free-state test block for existing block node members to perform free testing. At the same time, it does not need to return results to the server in real time, but only needs to retrieve the results periodically. It utilizes the block spider web characteristic to achieve asynchronous data sharing, thereby achieving low-loss testing.
[0071] Example 2
[0072] Please refer to Figure 2 A system for testing block functionality, comprising:
[0073] The server is used to push the list of test tasks to the test block;
[0074] The test block is used to obtain a test task queue based on the test task list, traverse the block nodes according to each test task in the test task queue, and execute the first test task using the first block node when the first test task in the test task queue matches the test attribute of the first block node. At the same time, the information of the next block node is stored in the first block node. After the test task is executed, the task execution result is returned to the server.
[0075] Furthermore, the test block obtains a test task queue based on the test task list, which then includes:
[0076] The test block parses and stores the corresponding test target attributes and task status for each test task according to the test task queue.
[0077] Furthermore, the information of the next block node is simultaneously stored in the first block node, including:
[0078] The test block continues to match block nodes according to the first test task, and stores the information of the next matched block node into the first block node.
[0079] Furthermore, after the test task is completed, it also includes:
[0080] Update the task status corresponding to the test task.
[0081] Furthermore, it also includes:
[0082] After the test block completes its task by traversing the block nodes according to each test task in the test task queue, it returns the total task execution result of the test task queue to the server.
[0083] In summary, the present invention provides a method and system for testing block functionality. The test block obtains a test task queue based on a test task list pushed by the server. It then traverses block nodes according to each test task in the queue. When the first test task in the queue matches the test attribute of the first block node, the first block node is used to execute the first test task. Simultaneously, the information of the next block node is stored in the first block node. After the test task is completed, the task execution result is returned to the server. In this way, once the server provides the test task list, the task execution results of the test block can be received periodically, without the server needing to actively and in real-time wait for test results. Furthermore, this testing method can utilize the block spider web characteristic to achieve asynchronous data sharing, thus achieving low-loss testing.
[0084] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A method of block functional testing, characterized by, Including the following steps: The server pushes the test task list to the test block, including: after the server publishes the test, the tasks are traversed by the test block; the test block includes the following structure information to save data during detached testing: task queue, task status, task return, target push, source code target, target result; The test block obtains a test task queue based on the test task list, traverses the block nodes according to each test task in the test task queue, and executes the first test task using the first block node when the first test task in the test task queue matches the test attribute of the first block node. At the same time, the information of the next block node is stored in the first block node. After the test task is executed, the task execution result is returned to the server. Meanwhile, the information of the next block node is stored in the first block node, including: the test block continues to match block nodes according to the first test task, and stores the information of the next matched block node in the first block node; Simultaneously storing the information of the next block node in the first block node also includes: simultaneously performing a handshake connection for the next block for the first test task, and storing the information of the next block node in the first block node for use when the test block is detached, and creating a detached test block for detached testing of existing block node members.
2. The method of testing a block function according to claim 1, wherein, The test block obtains a test task queue based on the test task list, and then includes: The test block parses and stores the corresponding test target attributes and task status for each test task according to the test task queue.
3. A method of block functional testing according to claim 2, wherein, After the test task is completed, it also includes: Update the task status corresponding to the test task.
4. The method of testing a block function according to claim 1, wherein, Also includes: After the test block completes its task by traversing the block nodes according to each test task in the test task queue, it returns the total task execution result of the test task queue to the server.
5. A system for testing block functionality, characterized in that, include: The server is used to push the test task list to the test block, including: after the server publishes the test, the tasks are traversed by the test block; the test block includes the following structure information to save data during detached testing: task queue, task status, task return, target push, source code target, and target result; The test block is used to obtain a test task queue based on the test task list, traverse the block nodes according to each test task in the test task queue, and execute the first test task using the first block node when the first test task in the test task queue matches the test attribute of the first block node. At the same time, the information of the next block node is stored in the first block node. After the test task is executed, the task execution result is returned to the server. Meanwhile, the information of the next block node is stored in the first block node, including: the test block continues to match block nodes according to the first test task, and stores the information of the next matched block node in the first block node; Simultaneously storing the information of the next block node in the first block node also includes: simultaneously performing a handshake connection for the next block for the first test task, and storing the information of the next block node in the first block node for use when the test block is detached, and creating a detached test block for detached testing of existing block node members.
6. The system for testing block functionality according to claim 5, characterized in that, The test block obtains a test task queue based on the test task list, and then includes: The test block parses and stores the corresponding test target attributes and task status for each test task according to the test task queue.
7. The system for testing block functionality according to claim 6, characterized in that, After the test task is completed, it also includes: Update the task status corresponding to the test task.
8. The system for testing block functionality according to claim 5, characterized in that, Also includes: After the test block completes its task by traversing the block nodes according to each test task in the test task queue, it returns the total task execution result of the test task queue to the server.