Block chain cross-chain test development platform

Abstract

The invention provides a block chain cross-chain test development platform, which comprises a test function development basic service module used for standardizing a test task execution process into three stages and packaging traffic generation and data acquisition services; the tested system universal adaptation module is used for defining a standardized block chain client interface and collecting system internal data through an under-chain instrumentation mechanism; the test function extension module is used for accessing and managing a test function in a plug-in manner through a unified test function interface; the multi-task concurrent scheduling module is used for maintaining a task queue through a scheduling engine, allocating tasks in parallel based on a Worker pool, and tracking and managing the test tasks at the same time; and the test resource management module is used for managing chain-level resources and maintaining the client instance pool to realize intelligent distribution, recovery and cleaning. Therefore, the development efficiency of the cross-chain test function and the automation level of the test process are greatly improved, and powerful support is provided for performance and safety evaluation of a cross-chain system.

Description

Technical Field

[0001] This invention belongs to the field of blockchain testing technology, and in particular relates to a blockchain cross-chain testing development platform. Background Technology

[0002] Blockchain, as a decentralized, tamper-proof, and traceable distributed ledger technology, has been widely applied in finance, supply chain, government affairs, the judiciary, and the Internet of Things since its inception in 2008. With the continuous expansion of blockchain application scenarios, hundreds of public, consortium, and private blockchains have been deployed globally, forming a diverse and isolated blockchain ecosystem. However, the inherent isolation and trust boundaries between blockchains lead to a situation where "chains cannot directly interact," creating the so-called information silo problem. To address this issue, cross-chain technology has emerged, aiming to enable information exchange, value transfer, and business collaboration between blockchain systems.

[0003] The core of cross-chain technology lies in solving key issues such as cross-chain information transmission, information verification, and cross-chain transaction processing. Currently, various cross-chain technology architectures have been proposed and implemented in the industry. For example, the BTC Relay solution, based on direct connections, enables one-way cross-chain verification from Bitcoin to Ethereum; the Polkadot solution, based on a relay chain, unifies scheduling and bridges multiple parachains through the relay chain; and Cosmos connects various independent Zones (partition chains) through its core Hub (central hub chain).

[0004] Various heterogeneous blockchain networks interact through smart contracts, bridging protocols, and other methods, making cross-chain system architectures highly complex and heterogeneous. The inherent complexity of cross-chain technology, along with differences in implementation across various technical solutions, can easily lead to performance issues or introduce new security risks. Therefore, cross-chain testing has become a crucial step in promoting the practical application of cross-chain technology and ensuring the secure and stable operation of cross-chain systems.

[0005] Current blockchain system testing has established a certain research foundation, particularly in single-chain performance evaluation and smart contract security testing, with tools such as Blockbench and Hyperledger Caliper emerging. These tools primarily focus on performance metrics such as transaction throughput, latency, and resource consumption, or on static and dynamic analysis of contract code vulnerabilities, using frameworks like Securify and Mythril. However, most of these testing tools are single-chain designed, and their testing processes, metric collection, and resource scheduling mechanisms are based on assumptions about the internal chain environment, lacking consideration for multi-chain interactions, heterogeneous chain compatibility, and inter-chain communication. Therefore, although multi-chain support can be achieved to some extent through API extensions, structural deficiencies remain in areas such as test task orchestration, resource isolation, and inter-chain event handling, failing to meet the complex testing requirements of cross-chain systems.

[0006] In comparison, cross-chain testing faces more technical challenges. Cross-chain systems typically integrate multiple blockchain networks in their architecture, encompassing on-chain smart contracts, inter-chain communication protocols, and multiple off-chain components (such as gateways, validators, schedulers, etc.), forming a highly heterogeneous operating environment. The core testing issues are no longer limited to the performance or security of a single chain, but extend to the integrity of cross-chain data transmission, the effectiveness of verification mechanisms, and the consistency of transaction execution.

[0007] Current research on cross-chain testing is still in its early stages, and a complete methodological framework for testing cross-chain systems has not yet been established. Some studies have attempted to explore evaluation methods for cross-chain systems from the perspectives of formal verification, protocol implementation verification, and the construction of testing tools.

[0008] In the formal evaluation of cross-chain systems, some scholars have proposed introducing formal methods into the modeling and verification of cross-chain mechanisms. In the field of performance evaluation, queuing theory models have been proposed for typical cross-chain systems (such as the Cosmos relay mode) to analyze key performance indicators such as queue length, transaction rejection rate, and response time, providing analytical tools for the theoretical performance evaluation of related cross-chain systems. In the field of functional evaluation, TLA+ was used to formalize the core transport, authentication, and ordering (TAO) layer of the IBC protocol, and the TLC model checker was used to verify properties such as connection establishment and packet relay, successfully identifying problems such as incomplete handshakes and packet delays. This is an important example of applying formal methods to widely adopted interoperability protocols. However, while model-based analysis and formal proofs can provide theoretical guarantees and performance predictions, they cannot completely replace actual testing of real-world deployed systems in complex and dynamic environments.

[0009] Secondly, some cross-chain frameworks or community activities provide near-real-world auditing and simulation platforms: the XCM Emulator in the Polkadot ecosystem can simulate inter-chain message formats and transmissions, but due to the lack of real off-chain components and network environments, its verification scope is limited to the protocol layer; the Game of Zones hosted by the Cosmos community conducts security audits of the IBC protocol in the form of a multi-party "attack and defense competition." While these practices have achieved certain results within specific ecosystems, they are usually designed for specific systems or protocols and lack general applicability. Furthermore, methods such as public audits and custom simulator construction are costly to test and difficult to widely promote as standardized testing methods.

[0010] Finally, some work attempts to modify or extend existing single-chain testing tools to adapt to cross-chain scenarios, or to develop dedicated cross-chain testing tools. For example, attempts to extend single-chain tools have resulted in the development of the single-chain smart contract monitoring tool HIGHGUARD. By using business process notation as a model, it supports cross-chain runtime monitoring of smart contracts and utilizes a unified model to verify the legality of cross-chain transaction business logic. However, research focused on single metrics, functions, or ecosystems lacks universality and scalability, and there is still a lack of functional and performance testing tools for heterogeneous multi-chain scenarios.

[0011] Existing single-chain testing solutions cannot effectively address the new challenges brought about by cross-chain scenarios. First, the heterogeneous nature of multi-chain systems in cross-chain scenarios makes adapting testing systems difficult, leading to greater challenges in implementing cross-chain testing. Second, cross-chain technology introduces key issues such as information transmission, trust transfer, and transaction processing, creating new testing content not present in single-chain testing. Finally, cross-chain systems involve both on-chain and off-chain components, introducing testing requirements related to off-chain components. Therefore, single-chain testing methods and tools cannot be directly and fully applied to cross-chain testing scenarios, failing to meet all the requirements of cross-chain testing in terms of heterogeneity, interaction complexity, and coverage of unique risks.

[0012] However, existing cross-chain testing solutions have the following limitations:

[0013] (1) The test logic is seriously repetitive and has low universality: the existing cross-chain test tools have high development costs and poor reusability; test programs often need to be built from scratch for different cross-chain scenarios, resulting in long development cycles and high costs; each new test function needs to implement repetitive logic such as task flow control, data collection, and resource preparation from scratch, which has high development threshold and low reusability.

[0014] (2) Inconsistent interfaces in heterogeneous systems lead to complex adaptation and development: Cross-chain systems have diverse underlying chains and inconsistent interface standards, resulting in differences between the systems under test. This leads to strong coupling between test functions and system adaptation, resulting in high maintenance costs. Existing cross-chain testing practices are fragmented, with test methods highly bound to the tested objects. Tools and methods are often tightly coupled to specific cross-chain systems or protocols, lacking a unified adaptation mechanism. This makes porting and maintenance difficult, and there is a lack of broad support for heterogeneous multi-chain scenarios, making it difficult to adapt to new cross-chain protocols or system changes. There is a lack of general-purpose testing tools on the market that are designed for heterogeneous multi-chain environments and possess both functional and performance testing capabilities.

[0015] (3) Lack of a unified mechanism for functional expansion and limited scalability: Traditional testing systems struggle to quickly integrate new testing functions, often requiring modifications to the underlying framework logic, which increases system maintenance difficulty and reduces flexibility. With the continuous evolution of cross-chain technology, existing testing solutions are difficult to flexibly expand to adapt to new testing needs and technical characteristics.

[0016] (4) Poor multi-task support and low execution efficiency: The current tools have poor support for concurrent tasks, which leads to test execution being scheduled in a sequential manner, resulting in low efficiency.

[0017] (5) Concurrent testing carries the risk of conflict, and manual conflict resolution is complicated: When multiple test tasks share the resources of the chain under test, conflicts are likely to occur, such as client re-entry and chain state pollution. Test task management usually relies on manual operation, and the order of tasks and resource dependencies are difficult to arrange, which can easily lead to conflicts or duplicate deployments, affecting efficiency and correctness.

[0018] The aforementioned shortcomings result in high development costs, high difficulty, low code reusability, low test execution efficiency, and high manual management complexity for current cross-chain testing tools. To address these issues, there is an urgent need for a general-purpose, scalable, and easy-to-use cross-chain testing development platform to provide fundamental support for the rapid development and execution of cross-chain testing functions, thereby reducing development barriers and costs, and improving testing efficiency and the accuracy of test results. Summary of the Invention

[0019] To address the problems existing in the prior art, this invention provides a blockchain cross-chain testing and development platform. Targeting highly complex and rapidly changing cross-chain system testing scenarios, it can provide general support for the development of various testing tools and support convenient expansion, thereby significantly reducing development difficulty and cost and improving R&D efficiency; at the same time, it can achieve high efficiency and security in test execution.

[0020] To achieve the above technical effects, this invention provides a blockchain cross-chain testing and development platform, including a basic service module for test function development, a general adaptation module for the system under test, a test function extension module, a multi-task concurrent scheduling module, and a test resource management module, wherein:

[0021] The aforementioned test function development basic service module is used to standardize the test task execution process into a pre-test preparation stage, a test execution stage, and a post-test cleanup stage, and encapsulates traffic generation services and data collection services for test functions to call.

[0022] The general adaptation module of the system under test is used to define a standardized blockchain client interface to provide interactive operations with heterogeneous blockchain systems, and to collect internal data of the system under test through an off-chain instrumentation mechanism; wherein, the interactive operations include one or more of transaction sending, status querying and event listening;

[0023] The test function extension module is used to access and manage test functions in a plug-in manner through a unified test function interface;

[0024] The multi-task concurrent scheduling module is used to maintain the task queue through the scheduling engine, and to allocate the test tasks in the task queue to idle worker nodes in parallel based on the worker pool for execution. At the same time, the test tasks are tracked and managed through the preset test task data structure and status definition.

[0025] The test resource management module is used to register, query, lock, release and reuse chain-level resources; and to maintain the blockchain client instance pool to realize intelligent allocation, unified recycling and expiration cleanup of clients.

[0026] Furthermore, the traffic generation service is configured to support multiple traffic modes, including multiple modes such as fixed rate mode, burst traffic mode, ramp growth mode and Poisson distribution mode.

[0027] The data acquisition service is configured to support multiple data acquisition modes, including single query, polling until state changes, polling until conditions are met, continuous collection of state changes, and event listening and unified callback.

[0028] Furthermore, the blockchain client interface is configured to perform the following operations:

[0029] Transaction-related operations include one or more of the following: creating a transaction, sending a transaction, obtaining the transaction status, and obtaining the transaction confirmation time;

[0030] Status query operations include retrieving the latest block, querying a specified block, querying account balance, and calling one or more contract methods;

[0031] Event-based operations include subscribing to events and retrieving one or more of the event's related properties.

[0032] Furthermore, the off-chain instrumentation mechanism specifically includes: uniformly encapsulating the data collected internally by the system under test into a metric data structure for forwarding, wherein the metric data structure includes event type, source identifier, timestamp, and data details fields.

[0033] Furthermore, the unified test function interface is used to create test instances and obtain test function metadata; the test function extension module also includes a test function manager, which is used to register, address, and manage the status of test functions that implement the test function interface.

[0034] Furthermore, the test function manager is also used to dynamically start and stop the test function, including setting the test function to a pre-disabled state and setting it to a disabled state after all test instances have been executed.

[0035] Furthermore, the preset test task data structure includes a unique task identifier, test context, task status, task status channel, and test result field.

[0036] Furthermore, the test resource management module includes:

[0037] The resource controller is used to manage the status of chain-level resources, maintain resource waiting queues and perform concurrent conflict judgments; and allocate exclusive locks or shared locks to the resources for the test tasks according to the resource isolation level requirements declared in the test function declaration.

[0038] The task tracker corresponds one-to-one with the test task and is used to maintain a list of all chain-level resources requested by the corresponding task.

[0039] Furthermore, the maintenance of the blockchain client instance pool to achieve intelligent allocation, unified recycling, and expiration cleanup of clients includes:

[0040] Idle client instances are preferentially selected from the blockchain client instance pool; when the number of instances in the blockchain client instance pool is insufficient, new instances are automatically created;

[0041] Release client instances that have been idle for a preset period of time.

[0042] Furthermore, the operations in the pre-test preparation phase include one or more of the following: task metadata registration, test resource isolation and locking, blockchain client initialization, and functional availability check.

[0043] The post-test cleanup phase includes one or more of the following: resource release, client instance return, and test result persistence.

[0044] The blockchain cross-chain testing and development platform provided by this invention addresses the challenges of universality, scalability, and efficiency in heterogeneous cross-chain testing through five modules: a basic service module for test function development standardizes the testing process and provides traffic generation and data collection services; a general adaptation module for the system under test shields underlying chain differences through a unified interface and instrumentation mechanism; a test function extension module enables plug-in access and management of test functions through standardized interfaces; a multi-task concurrent scheduling module enables parallel testing based on task queues and worker pools; and a test resource management module avoids resource conflicts and promotes resource reuse through resource controllers and client pool mechanisms. Thus, the blockchain cross-chain testing and development platform provided by this invention significantly reduces the development difficulty and repetitive costs of cross-chain testing functions, improves adaptability to different blockchain systems and platform scalability, and greatly enhances the automation level and efficiency of test execution through efficient concurrent scheduling and resource management, ensuring the accuracy and reliability of test results. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of the structure of the blockchain cross-chain test and development platform provided in an embodiment of the present invention;

[0046] Figure 2 The logical architecture diagram of the blockchain cross-chain test and development platform provided in one embodiment of the present invention;

[0047] Figure 3 This is a schematic diagram of the single-task flow control of the blockchain cross-chain test and development platform provided in an embodiment of the present invention;

[0048] Figure 4 This is a schematic diagram of the instrumentation data collection process of the blockchain cross-chain test development platform provided in an embodiment of the present invention;

[0049] Figure 5 This is a schematic diagram of multi-task scheduling of the blockchain cross-chain test and development platform provided in an embodiment of the present invention;

[0050] Figure 6 A schematic diagram of the chain-level resource management of the blockchain cross-chain test and development platform provided in an embodiment of the present invention;

[0051] Figure 7 This is a schematic diagram of a task tracker for a blockchain cross-chain test and development platform provided in an embodiment of the present invention;

[0052] Figure 8 This is a schematic diagram of the throughput testing logic design of the blockchain cross-chain test development platform provided in an embodiment of the present invention;

[0053] Figure 9This is a schematic diagram of the cross-chain information verification validity test logic design of the blockchain cross-chain test development platform provided in an embodiment of the present invention.

[0054] Figure 10 This is a flowchart illustrating the execution process of a test task initiated by the blockchain cross-chain test development platform provided in an embodiment of the present invention.

[0055] Figure 11 A flowchart illustrating the pre-test preparation phase of the blockchain cross-chain test development platform provided in an embodiment of the present invention for executing tasks;

[0056] Figure 12 This is a schematic diagram of the chain-level resource application logic in the test task of the blockchain cross-chain test development platform provided in an embodiment of the present invention;

[0057] Figure 13 This is a schematic diagram of the chain-level resource release logic in the test task of the blockchain cross-chain test development platform provided in an embodiment of the present invention;

[0058] Figure 14 This is a schematic diagram of the blockchain client management process of the blockchain cross-chain test development platform provided in an embodiment of the present invention;

[0059] Figure 15 The flowchart illustrates the acquisition and release of test functions in the blockchain cross-chain test development platform provided in one embodiment of the present invention. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0061] It should be noted that references to "an embodiment," "embodiment," "example embodiment," etc., in this specification refer to the described embodiment including specific features, structures, or characteristics, but not every embodiment must include these specific features, structures, or characteristics. Furthermore, such expressions do not refer to the same embodiment. Moreover, when describing specific features, structures, or characteristics in conjunction with embodiments, whether or not explicitly described, it is indicated that incorporating such features, structures, or characteristics into other embodiments is within the knowledge of those skilled in the art.

[0062] Furthermore, certain terms are used in the specification and subsequent claims to refer to specific components or parts. Those skilled in the art will understand that manufacturers may use different names or terms to refer to the same component or part. This specification and subsequent claims do not distinguish components or parts by differences in name, but rather by differences in function. The terms "comprising" and "including" used throughout the specification and subsequent claims are open-ended and should be interpreted as "including but not limited to." Additionally, the term "connection" here includes any direct and indirect electrical connection means. Indirect electrical connection means include connections made through other means.

[0063] To more clearly illustrate the specific implementation of the blockchain cross-chain testing and development platform of this invention, the current technical status and core challenges in the existing cross-chain testing field are first explained: Traditional single-chain testing methods and tools are difficult to adapt to cross-chain systems. The core reason is that the cross-chain environment introduces new complexities such as heterogeneous chain interaction, cross-chain message transmission and verification, and multi-party component collaboration. Existing cross-chain testing attempts are mostly customized for specific metrics, projects, or ecosystems, resulting in fragmented testing solutions, high development costs, and difficulty in promoting and reusing them for other cross-chain systems. Developing testing tools from scratch for new cross-chain systems or new testing requirements also presents problems such as long development cycles, poor reusability, and high technical barriers. Based on this, the technical effect to be achieved by this invention is: to design a general-purpose, scalable, and easy-to-use cross-chain testing and development platform to adapt to highly complex and rapidly changing cross-chain system testing scenarios, providing general support for the development of various testing tools and supporting convenient expansion, thereby significantly reducing development difficulty and cost, improving R&D efficiency, and providing effective means to ensure the efficiency and security of test execution. The invention will be described in detail below with reference to specific embodiments.

[0064] Figure 1 This invention illustrates a blockchain cross-chain test development platform 100 provided in an embodiment of the present invention, comprising a test function development basic service module 10, a test system general adaptation module 20, a test function extension module 30, a multi-task concurrent scheduling module 40, and a test resource management module 50, wherein:

[0065] The test function development basic service module 10 standardizes the test task execution process into a pre-test preparation stage, a test execution stage, and a post-test cleanup stage, and encapsulates traffic generation and data acquisition services for test function calls. The general adaptation module 20 of the system under test defines a standardized blockchain client interface to provide interactive operations with heterogeneous blockchain systems and collects internal data of the system under test through an off-chain instrumentation mechanism. The interactive operations include one or more of transaction sending, status querying, and event listening. The test function extension module 30 is used to access and manage test functions in a pluggable manner through a unified test function interface. The multi-task concurrent scheduling module 40 maintains the task queue through a scheduling engine and allocates test tasks in the task queue to idle worker nodes in parallel based on the worker pool. At the same time, it tracks and manages the test tasks through a preset test task data structure and status definition. The test resource management module 50 is used to register, query, lock, release, and reuse chain-level resources, and maintain a blockchain client instance pool to realize intelligent allocation, unified recycling, and expiration cleanup of clients.

[0066] Specifically, the test function development basic service module 10 abstracts and solidifies the execution flow of a single test task into three standardized stages: pre-test preparation (resource check, locking, initialization), test execution (calling core test logic), and post-test cleanup (resource release, result persistence). Simultaneously, this module encapsulates and provides general services that can be called by various test functions, such as traffic generation services simulating different load modes (e.g., fixed rate, burst traffic) and diverse data acquisition services (e.g., event listening, polling, instrumentation). The general adaptation module 20 for the system under test defines and implements a standardized blockchain client interface (e.g., BlockchainClient). This interface uniformly encapsulates underlying heterogeneous operations such as transaction sending, status querying, and event listening. Test functions interact with various blockchain systems through this unified interface, thus shielding the technical differences of the underlying chains. For off-chain components without native interfaces, this module collects internal data and forwards it to the platform through an off-chain instrumentation mechanism, solving the data observability problem. The test function extension module 30 provides a unified test function interface (e.g., TestFunction and...).

[0067] TestInstance); any new test function only needs to implement these interfaces to be "hot-swapped" into the platform in a plug-in manner; the platform registers, addresses, instantiates, and manages the lifecycle (such as state management, reference counting, dynamic start and stop) of these functional modules through the built-in test function manager, thereby achieving convenient expansion and unified management of functions. The multi-task concurrent scheduling module 40 introduces a central scheduling engine, which maintains a task queue to receive test requests and manages a Worker pool (worker thread pool); the scheduler takes tasks from the queue and assigns them to idle Workers in parallel for execution; through a preset test task data structure (such as TestTask), the status, context, and results of each task are tracked and managed in real time, thereby achieving efficient and automated concurrent execution of multiple tasks. The test resource management module 50 is used to uniformly register, monitor the status, and allocate and schedule the chain-level resources (such as blockchain nodes and repeaters) required for testing, and automatically apply locking mechanisms to avoid concurrent conflicts according to test requirements (exclusive / shared). At the same time, this module maintains a client instance pool for each blockchain, realizing intelligent reuse of clients (acquiring when needed and returning after use), unified recycling, and expiration cleanup, which greatly reduces resource creation overhead and leakage risk.

[0068] The blockchain cross-chain test development platform 100 provided in this embodiment integrates basic services for test function development, adaptation mechanisms for the system under test, test function extension mechanisms, task concurrency scheduling mechanisms, and resource management mechanisms through modular design and unified interfaces, providing comprehensive support for the development and execution of cross-chain test functions; the organizational structure of the blockchain cross-chain test development platform 100 is as follows: Figure 2 As shown.

[0069] To improve the versatility and development efficiency of testing functions, this embodiment designs a set of basic service modules 10 for testing function development in the blockchain cross-chain testing development platform 100. The standard execution process of testing tasks and the general capabilities required are abstracted, encapsulated and integrated for use by various cross-chain testing functions, and are uniformly controlled and scheduled by the platform. Developers only need to implement the core testing logic.

[0070] In the standardized test task flow control of the basic service module 10 for test function development, the execution flow of test tasks is divided into three stages: pre-test preparation, test execution, and post-test cleanup. The platform provides unified encapsulation for these three stages and automatically invokes them through the scheduling control framework, allowing developers to focus on implementing test logic and reducing the burden of repetitive operations. The pre-test preparation stage mainly completes: task metadata registration (such as task ID, task type, and test chain information); test resource isolation and locking (to prevent resource conflicts); client initialization (such as BlockchainClient registration and connection); and functional availability checks (detecting service status through functional status flags and interface responses). The test execution stage calls the core test logic of each test function (implemented by developers through TestInstance.ExecuteTest()); and utilizes the platform's built-in services such as transaction sending, event listening, and status query to execute specific test behaviors. The post-test cleanup stage completes client and resource release; data persistence and result report generation; test record archiving; and task status updates. This process is uniformly managed by the platform scheduler, ensuring consistency and high controllability in task execution. A flowchart is shown below. Figure 3 As shown.

[0071] Furthermore, while the logic of the test execution phase is unique to each test function, there are still parts that can be abstracted. To support different types of cross-chain test functions, this embodiment encapsulates commonly used test operation logic through the test function development basic service module 10, forming traffic generation and data collection services.

[0072] The traffic generation service is configured to support multiple traffic modes, including fixed rate mode, burst traffic mode, ramp growth mode, and Poisson distribution mode; the data acquisition service is configured to support multiple data acquisition modes, including single query, polling until state change, polling until conditions are met, continuous collection of state changes, and event listening and unified callback.

[0073] To cover different on-chain load scenarios, this module encapsulates various transaction triggering modes, which can be reused as transaction generators in different testing functions. The platform has built-in multiple traffic modes (such as fixed rate, burst traffic, ramp growth, and Poisson distribution) to simulate different on-chain load scenarios. Each transaction triggering mode controls its specific behavior through configuration parameters, such as total number of transactions, duration, interval, and burst frequency. The platform schedules the logic of each mode through a unified TransactionTrigger interface, automatically managing transaction generation and sending. Testing functions can be invoked as needed. In actual implementation, each time a transaction is triggered, the platform extracts the corresponding chain connection object from the BlockchainClient and uses a standard interface...

[0074] SendTransaction(payload) initiates a transaction to the target chain. The list of traffic generation services in this embodiment is shown in Table 1 below.

[0075] Table 1:

[0076]

[0077] Cross-chain testing requires real-time or near real-time observation of on-chain states to capture transaction execution results, state transitions, or anomalies. To this end, the platform provides diverse data collection modes (such as simple single query, polling until state changes, polling until conditions are met, continuous collection of state changes, multi-type event listening and unified callback, instrumentation data collection, etc.), supporting flexible configuration of collection targets, triggering mechanisms, and collection cycles to meet the data observation needs of different testing scenarios. Each observation mode is built based on the StateObserver interface, supporting access to three types of observation sources: chain-level state queries, event listening, and instrumentation data. The data collection service list for this embodiment is shown in Table 2 below.

[0078] Table 2:

[0079]

[0080]

[0081] The basic service for test function development proposed in this embodiment provides comprehensive support for the rapid development and execution of cross-chain test functions through the standardized design of test task execution process, transaction triggering logic, state observation strategy and data management structure.

[0082] Cross-chain testing scenarios involve various heterogeneous blockchain systems with significant differences in interface structure, data model, and transaction semantics, making it difficult to directly reuse testing functions and severely impacting the versatility and scalability of the testing platform. To address this, the universal adaptation module 20 for the system under test in this embodiment provides a universal adaptation mechanism. By defining standardized adaptation interfaces and encapsulating chain-level characteristics, a unified link layer is constructed, shielding underlying differences and improving the platform's compatibility with heterogeneous systems.

[0083] The blockchain client interface is configured to perform the following operations:

[0084] Transaction-related operations include one or more of the following: creating a transaction, sending a transaction, obtaining the transaction status, and obtaining the transaction confirmation time; status query operations include one or more of the following: obtaining the latest block, querying a specified block, querying the account balance, and calling a contract method; event-related operations include one or more of the following: subscribing to an event and obtaining event-related attributes.

[0085] The core adaptation mechanism of the general adaptation module 20 for the tested system uses the BlockchainClient interface as its abstract core, standardizing and encapsulating the basic operations of various blockchain systems. High-frequency operations such as transaction sending, status querying, and event listening are encapsulated into standard interface specifications, shielding the interface differences between different underlying blockchains. Each blockchain type can be uniformly called by the platform by implementing the BlockchainClient interface and registering an adapter instance. The adapter implementation is responsible for mapping and converting the platform's unified interface with the target chain system's native RPC, Web3, gRPC, and other calling methods. The platform dynamically creates a BlockchainClient instance for the chain during the task preparation phase and injects it into the test task context as needed for transparent use by the test functions. Specific interfaces are shown in Tables 3 to 5 below.

[0086] Table 3 lists the transaction-related interfaces:

[0087]

[0088] Table 4 lists the event class interfaces:

[0089]

[0090] Table 5 shows the status query interface:

[0091]

[0092] Considering that some blockchain systems do not expose complete on-chain state or event data, the platform supports embedding data acquisition logic through instrumentation. The platform provides a configurable off-chain instrumentation solution, embedding acquisition points in a standardized manner within cross-chain systems. This forwards state / event / call context data to the testing platform, solving the data acquisition challenge in scenarios without native interfaces. Instrumentation information is uniformly encapsulated into a metric data structure, including fields such as event type, source ID, timestamp, and data details, for use in testing functions. This mechanism supports collaborative on-chain and off-chain acquisition and is suitable for observation needs of specific critical paths (such as off-chain cross-chain information verification interface calls) in testing functions. The specific instrumentation data acquisition process is as follows: Figure 4 As shown.

[0093] In this embodiment, the universal adaptation module 20 for the system under test achieves universal adaptation to heterogeneous blockchain systems by designing a unified interface and building an adapter system. The adaptation mechanism decouples the testing logic from the specific implementation of the underlying blockchain system, improving the platform's compatibility, scalability, and maintainability. Its instrumentation mechanism further solves the observability problem caused by the closed nature of the blockchain system interface, providing stable and reusable support for the development of testing functions for complex cross-chain systems.

[0094] To enhance the scalability of the platform in terms of cross-chain testing functionality integration, this embodiment designs and implements a unified testing function extension mechanism within the blockchain cross-chain testing development platform 100. This mechanism, centered on standard interface definitions and integrated with registration management and scheduling, allows developers to quickly integrate new testing functions into the platform in a plug-in manner. The platform also includes a testing function manager responsible for the registration, storage, instance management, and lifecycle control of all testing functions, thereby enabling horizontal expansion of platform functionality and dynamic lifecycle management.

[0095] Specifically, the test function extension module 30 accesses and manages test functions in a plug-in manner through unified TestFunction and TestInstance interfaces; in practice, the platform defines standard interfaces.

[0096] TestFunction standardizes the structure and behavior of test function modules. New test functions only need to implement this interface to easily integrate with the platform and reuse the basic services and facilities provided by the platform. All test functions are integrated with the platform by implementing the platform-defined TestFunction interface, and the platform schedules and calls them through a unified registry. Specifically, the TestFunction interface is responsible for the metadata description of the test function and the creation of test instances, while the TestInstance interface encapsulates the execution logic and lifecycle management of specific test tasks (such as context binding, interface testing, test execution, and result retrieval). The interface design is shown in Tables 6 and 7 below.

[0097] Table 6 shows the test function interface table:

[0098]

[0099] Table 7 shows the interface table for the test instances:

[0100]

[0101] The test function manager is also used for dynamic start-stop control of the test functions, including setting the test function to a pre-disabled state and setting it to a disabled state after all test instances have been executed. In other words, the platform provides unified management of integrated test functions, including registration, addressing, instantiation, concurrency counting, and dynamic start-stop control (such as pre-disabled and disabled state management), ensuring the orderly integration and maintenance of test functions. During registration, the platform maintains a "Test Function Management Table" to record metadata such as function name, version, adapted chain type, and resource isolation level. During the test task initialization phase, the platform automatically matches and loads the target function according to the configuration and completes the initialization parameter injection. After the test task ends, the platform is responsible for recycling the state and clearing the cache; developers do not need to handle context switching issues. This gives the platform good scalability, allowing new test metrics and test scenarios to be added at any time to adapt to changes in requirements brought about by the evolution of cross-chain technology. The test function management design is shown in Table 8 below.

[0102] Table 8 is the test function management table:

[0103] Test type Test function interface Task counter Test Function Status ThroughputTest ThroughputTestFunction 1 Activate VeifyTest VeifyTestFunction 2 Pre-Deactivation HtlcTest HtlcTestFunction 0 Deactivated … … … …

[0104] This embodiment constructs a highly scalable test function management system through a unified TestFunction interface and dynamic management of functions. This mechanism not only significantly simplifies the process of integrating new functions but also effectively improves the platform's adaptability and maintainability in the face of diverse cross-chain testing needs, providing key support for building a sustainably evolving cross-chain testing platform.

[0105] See Figure 5 To address the multi-functional, multi-chain concurrent execution requirements in cross-chain testing, this embodiment provides a scheduling mechanism based on a Worker pool and task queue through a multi-task concurrent scheduling module 40. The platform maintains the task queue through a unified scheduling engine. By simultaneously enqueuing multiple test tasks from the same or different systems under test, a first-come, first-served strategy is used to allocate them in parallel to available Worker nodes for execution, enabling concurrent processing of multi-system or single-system multi-metric tests. This mechanism significantly improves test execution efficiency and automation, allowing users to initiate multiple test tasks simultaneously and reducing waiting time. The platform also tracks and manages the status of test tasks through the TestTask data structure (test task data structure) and status definitions. The TestTask data structure is shown in Table 9 below.

[0106] Table 9:

[0107] Fields meaning ID Task unique identifier Context test context Status Current status of the task Messagechan Task Status Channel Result Test Results

[0108] Specifically, the test resource management module 50 includes a resource controller and a task tracker, wherein: the resource controller is used to manage the status of chain-level resources, maintain resource waiting queues and perform concurrent conflict judgments; and allocate exclusive locks or shared locks to the test tasks according to the resource isolation level requirements declared in the test function; the task tracker corresponds one-to-one with the test tasks and is used to maintain a list of all chain-level resources applied for by the corresponding task.

[0109] Furthermore, maintaining the blockchain client instance pool to achieve intelligent allocation, unified recycling, and expiration cleanup of clients includes: preferentially acquiring idle client instances from the blockchain client instance pool; automatically creating new instances when there are insufficient instances in the blockchain client instance pool; and releasing client instances that have been idle for more than a preset time.

[0110] Cross-chain testing often involves multiple blockchain network instances and off-chain components, leading to significant resource conflicts. The test resource management module 50 in this embodiment provides a test resource management mechanism that supports resource registration, allocation, locking, and reuse, enabling unified management of various resources required during the testing process.

[0111] The test resource management module 50 is configured with resource registration and locking mechanisms as well as client reuse, including:

[0112] Resource Registration and Locking Mechanism: The platform provides unified management of the chain-level resources (such as blockchain nodes and repeaters) required for testing, supporting resource registration, querying, locking, release, and reuse; the chain-level resource management design is as follows: Figure 6 As shown in Table 10, the platform employs a resource controller to monitor resource status in real time and manage its lifecycle. The resource controller supports resource status management, resource queuing, and concurrent conflict detection, and can work in conjunction with the task scheduler to preempt and lock resources before tasks begin. Test functions declare their resource isolation level requirements (e.g., exclusive locks, shared locks) during registration. Each test task is registered with a task tracker by the resource manager, which maintains all required chain-level resources and sets up message channels, such as... Figure 7 As shown, in scenarios with multiple concurrent test tasks, the platform automatically locks, allocates, and releases resources according to requirements. Through resource locks and automatic queuing scheduling, it achieves on-demand isolation or sharing of resources between test tasks. Furthermore, it manages resource status and waiting queues through task trackers and resource controllers, effectively avoiding data pollution and conflicts caused by concurrent testing.

[0113] Table 10 shows the resource controller design:

[0114]

[0115] Client reuse: Unified management and reuse of blockchain clients avoids the performance waste caused by repeatedly creating client instances. The platform maintains a client instance pool for each blockchain, enabling intelligent allocation, unified recycling, and timeout cleanup of clients. Test tasks prioritize obtaining existing client instances from the pool, creating new ones only when insufficient, thereby reducing the overhead of frequently creating and destroying clients.

[0116] The modules in this embodiment work together to form a complete blockchain cross-chain test and development platform architecture: the basic test function service and the system under test adaptation module improve the platform's versatility from both the aspects of test logic and system adaptation, and reduce the difficulty of test function development; the test function extension module enhances the platform's scalability; the task scheduling and resource management mechanism improves the test's concurrency and automation level, and improves the platform's usability.

[0117] The following describes the core working mechanism and complete operation process of the blockchain cross-chain test and development platform 100 provided in this embodiment.

[0118] Users define test tasks through a graphical interface or configuration file, including information such as the system under test identifier, test mode, and parameters.

[0119] I. The development process for testing functions based on the blockchain cross-chain testing and development platform 100 is as follows:

[0120] When developers use TestBase (a blockchain cross-chain testing development platform) to develop new cross-chain testing features, they should mainly follow these steps:

[0121] The core test logic is designed and implemented by encapsulating specific test steps (such as test case construction, transaction triggering, data collection, and result judgment) in the `ExecuteTest` method of the test instance class (e.g., `AInstance`). During development, basic services provided by the platform can be directly called, such as using the `StartTrafficByMode` service to generate test traffic, or using the `StateObserveMode` series of services to collect on-chain state or event data.

[0122] Implement the TestFunction interface:

[0123] i. Define a test function class (such as ATestFunction) that implements the TestFunction interface. Its NewInstance method is responsible for creating and returning the test instance (AInstance) based on the passed-in test context (TestContext).

[0124] The ii.GetMetaInfo method is responsible for returning the metadata of the test function, such as name, description, number of clients required, resource isolation level (exclusive or shared), etc. This information will be used for the platform's test function management and task scheduling.

[0125] iii. The test instance class (AInstance) also needs to implement other methods of the TestInstance interface, such as BindContext for binding test parameters and client resources, InterfaceTest for pre-testing the availability of the interface of the system under test, and GetResult and GetProcessData for providing the final test results and process data after the test is completed.

[0126] Interacting with the system under test: The test logic interacts with the heterogeneous cross-chain system under test through the BlockchainClient general adaptation interface provided by the platform, thereby shielding the underlying differences. If the component under test does not have a direct API, data collection can be performed using the instrumentation mechanism provided by the platform.

[0127] Register with the platform: Once the test function is developed, it is registered with the system through the platform's RegisterFunction interface, and then users can call it to execute test tasks.

[0128] For specific testing functions, TestBase provides two examples: cross-chain transmission throughput test and cross-chain information verification validity test.

[0129] This embodiment defines cross-chain transmission throughput as the number of cross-chain transactions that a cross-chain system can successfully complete per unit time under a specific load. This indicator reflects the cross-chain transaction processing performance of the cross-chain system, and a cross-chain transmission throughput testing function has been developed based on this embodiment.

[0130] Throughput test logic design as follows Figure 8 As shown, the specific process for developing throughput testing functional test logic using TestBase is as follows:

[0131] (1) Test Case Generation. This step initializes the test instance, where the test instance TpsInstance is bound to the TestContext via the BindContext method, and obtains the test parameters, the configuration of the system under test, and the general BlockchainClient client from the TestContext. The test parameters include cross-chain transaction parameters, test traffic generation mode, cross-chain transaction sending rate and concurrency, and test duration. Subsequently, a time window is calculated based on the parameters, and transaction data is pre-generated by calling the general interface through the BlockchainClient.

[0132] (2) Traffic Generation. During the set test duration, the traffic generation service is invoked according to preset load conditions.

[0133] The StartTrafficByMode(mode,BlockchainClient,rate,…) method continuously sends cross-chain transaction requests from the source chain.

[0134] (3) State Observation. This step is performed synchronously with the traffic generation step. The test determines that the cross-chain transaction was successfully sent by the source chain by issuing a cross-chain request event, and that the cross-chain transmission was successfully completed by the destination chain by issuing a cross-chain response event. Event listening is implemented by calling the platform's SubscribeEvents method, and the number of successfully sent transactions and the number of completed cross-chain transmissions are updated in the callback function.

[0135] (4) Results generation. Throughput is calculated by time window.

[0136] After the test logic is implemented, the TestFunction interface is encapsulated, containing the implementations of two methods:

[0137] Implement the `NewInstance` method. This method is required to return a concrete class `TpsInstance` that implements the `TestInstance` interface, which in turn implements the five interfaces of `TestInstance`. Therefore, after implementing the core test logic in the `ExecuteTest` interface, implement the `BindContext` method for test parameter parsing, implement the `InterfaceTest` method for interface testing, and finally return the test results and process data as the return values ​​of the `GetResult` and `GetProcessData` methods, respectively. After implementing `TpsInstance`, simply return it as the return value of the `NewInstance` method.

[0138] Implement the GetMetaInfo method. Throughput testing is a resource sensitivity test, with the isolation level set to exclusive lock. Determine the test metadata, such as test name and test description, and use it as the return value of the GetMetaInfo method.

[0139] The above steps ultimately implemented the cross-chain throughput testing function ThroughputTestFunction. By implementing the TestFunction interface, this function can be integrated into TestBase. All aspects of the test function development, including client instance generation and release, test result storage, and resource isolation checks and task scheduling required for test execution, directly call TestBase services.

[0140] In addition, a cross-chain information verification validity test function was developed, which defines the cross-chain information verification validity as the ability of the target chain to verify that the source chain data is credible, the content is complete, and has not been tampered with.

[0141] Cross-chain information verification validity test logic design, such as Figure 9 As shown, TestBase is used to verify the validity of cross-chain information; the specific process for developing the test logic for the test function is as follows:

[0142] (1) Test Case Generation. This stage initializes the test instance, where the test instance `VerifyInstance` is bound to `TestContext` via the `BindContext` method, and obtains test parameters, the configuration of the system under test, and general `BlockchainClient` client and relay information from `TestContext`. The test parameters are cross-chain transaction parameters. Subsequently, based on the cross-chain transaction parameters, transaction methods such as `CreateTransaction` and `SendTransaction` of `BlockchainClient` are used to construct and send cross-chain transactions. The `StartCollect` method of the instrumentation data collection service is used to start instrumentation data reporting, and verification credentials are obtained according to the `PollMetricsUnti` instrumentation data collection mode. Then, the `SubscribeEvents` method of the data collection service is called, passing in a callback function to record the verification results, to start event listening. Finally, two types of test cases, valid and invalid, are constructed based on the verification credentials.

[0143] (2) Test execution. Submit the verification credentials for the two types of test cases to the verification interface of the target chain in sequence.

[0144] (3) State observation. After the verification request is issued, the test obtains and records the verification result from the cross-chain information verification event thrown by the target chain.

[0145] (4) Result Generation. Check and verify whether the returned results meet expectations. Valid test cases should pass verification, and invalid test cases should fail verification.

[0146] After the test logic is implemented, the TestFunction interface is encapsulated, containing the implementations of two methods:

[0147] Implement the `NewInstance` method. This method is required to return an instance class `VerifyInstance` that implements the five interfaces of `TestInstance`. Therefore, after implementing the core test logic in the `ExecuteTest` method, continue to implement the `BindContext`, `InterfaceTest`, `GetResult`, and `GetProcessData` methods to implement the `TestInstance` interface.

[0148] Implement the GetMetaInfo method. Other on-chain transactions will not affect the result of the cross-chain information verification validity test; therefore, the isolation level is shared lock. Specify the test name, test description, and other metadata for this test function, and return them as the value of the GetMetaInfo method.

[0149] The above steps ultimately form the cross-chain information verification validity test function VerifyTestFunction, which is then integrated into the platform. In addition to the above steps, the code instrumentation of the system components under test before testing can utilize the platform's standard instrumentation data acquisition methods. TestBase provides services for everything from test client instance generation and release, test result storage, and task scheduling.

[0150] In the examples above, the TestBase platform guides testing functions through a standardized development process, ensuring seamless integration and providing a wealth of general-purpose basic services. As illustrated by these examples, the TestBase platform provided in this embodiment effectively reduces the development difficulty and cost of cross-chain testing functions.

[0151] II. The execution flow of test tasks based on the blockchain cross-chain test development platform 100 is as follows:

[0152] When a user initiates a test task through the platform, the execution flow is as follows: Figure 10 As shown, the details are as follows:

[0153] (1) Test request initiation: The user first deploys the cross-chain system under test and selects the test function to be executed through the visualization module. Then, the user selects the information of the object under test (such as selecting a chain and Relayer configuration from the list of registered chains), sets the test parameters, and sends the test request to the multi-task scheduling module.

[0154] (2) Task creation and queuing: The user's test request is converted into a test task (TestTask object) by the task scheduler, assigned a unique ID, and added to the global task waiting queue.

[0155] (3) Task scheduling: Idle Workers in the Worker pool obtain task scheduling tasks from the task queue and pass the task context information to the single task control module to enter the task execution process.

[0156] (4) Pre-test preparation: The platform automatically performs a series of preparatory tasks, including:

[0157] a) Check if the test function is available;

[0158] b) Lock the required chain resources and repeater resources;

[0159] c) Obtain the blockchain client;

[0160] Instantiate the test function (call TestFunction.NewInstance) and bind the client and test parameters to the test instance (call TestInstance.BindContext).

[0161] Perform interface connectivity testing (by calling TestInstance.InterfaceTest).

[0162] (5) Test Execution: After the preparation work is completed, the platform calls the ExecuteTest method of the test instance to execute the core test logic. During this stage, the test logic can call the traffic generation service provided by the platform to send cross-chain transactions to the system under test as needed, and use the data collection service to monitor the system status and collect event or instrumentation data.

[0163] (6) Post-test cleanup and result collection: After the test is completed, the platform automatically performs cleanup, including releasing locked chain-level resources and returning client instances to the pool. At the same time, it retrieves test results and detailed process data by calling the GetResult and GetProcessData methods of the test instance, and stores them for users to view and analyze.

[0164] III. The pre-test preparation and post-test cleanup procedures are as follows:

[0165] The platform's pre-testing preparation process before executing tasks is as follows: Figure 11 As shown, the specific description is as follows:

[0166] (1) Test function addressing. Check whether the test function is available and ensure that the current test type has not been disabled due to system upgrades or other reasons; at the same time, obtain the lock type of the test function (divided into shared lock and exclusive lock according to the actual test requirements) and update the test function counter.

[0167] (2) Test Chain Resource Locking. Based on the lock type of the test function and the chain-level resource ID required by the test in the test context, attempt to check whether the chain and repeater are available to ensure that only non-interfering tests run at the same time and prevent test data pollution. If all resources exist, acquire the resources normally; if the resources do not exist, unlock all acquired resources and return an error.

[0168] (3) Chain Client Application. Based on the test function requirements and test chain information, obtain the appropriate type and a sufficient number of blockchain clients, and store them in the context for interaction with the cross-chain system under test during the test.

[0169] (4) Test function instantiation. The test parameters obtained from the client and test context information are passed to the test function, and its NewInstance method is called to generate the test instance for this test.

[0170] (5) Interface connectivity testing of the test function. Use the client to test the interfaces required for the test function, check the connectivity between the adaptation layer and the cross-chain system under test, and ensure that the environment is normal.

[0171] The post-test cleanup process is exactly the same as the pre-test preparation process, except that the generation logic is changed to the release logic, which will not be elaborated here.

[0172] IV. The resource acquisition process for test tasks is as follows:

[0173] The acquisition of chain-level resources is completed in the "Test Resource Locking" phase of test preparation. At this point, the tracker for the test task is initialized, attempting to request all required chain-level resources at once. The logic for requesting chain-level resources is designed as follows: Figure 12 As shown, the details are as follows:

[0174] (1) Iterate through the required resources and attempt to lock them one by one. Successfully acquired resource IDs will be stored in the list of acquired resources in the task tracker. The resource lock acquisition logic is as follows:

[0175] a) If the resource is not occupied, lock it directly and record the holder;

[0176] b) If the current test already holds the resource, return success;

[0177] c) If the resource is held by another task, determine whether it needs to be added to the waiting queue based on the lock type. When the resource is held by a shared lock, a request for an exclusive lock or an exclusive lock already exists will enter the waiting queue; otherwise, the shared lock will be acquired directly.

[0178] (2) Rollback mechanism for locking failure. If any resource does not exist (indicated by the absence of a controller), the currently locked resource will be released and the task tracker will be cleared.

[0179] (3) Determine if all resources are ready. If all resources are successfully locked, return to the success state and the task can be executed immediately; otherwise, enter the "waiting for resources" state.

[0180] (4) Wait for resources to be released and wake up the task. The task waiting for the resource status will enter a blocked state and continuously listen to the tracker's information channel until the information channel receives an event, then it will check again whether all resources are ready.

[0181] The release of chain-level resources is completed during the "test chain resource unlocking" phase of the post-test cleanup stage. The logic for releasing chain-level resources is designed as follows: Figure 13 As shown, the details are as follows:

[0182] (1) Unlock resources and clean up status. After the task is completed or terminated, iterate through and release all the resource locks that are occupied.

[0183] (2) For each resource, release the lock that the task has on the resource.

[0184] a) If a resource has no other holder, it becomes unlocked, and the lock type of the chain-level resource is cleared. Then, the waiting queue is processed, resources are allocated to waiting tasks in sequence, and asynchronous notifications of resource readiness are sent through the task's message channel; if it is a shared lock, multiple shared requests can be woken up at once.

[0185] b) If the resource is still held by other tasks, no further processing of the resource will be performed, and other resources will continue to be processed directly.

[0186] (3) After releasing all resources, clean up the tracker for this task.

[0187] V. The client management process is as follows:

[0188] The client manager uses the following methods: Figure 14 The process implements client-side management as follows:

[0189] (1) Intelligent Allocation. During the test environment preparation process, the client manager automatically returns multiple client instances for each chain based on the chain type and number declared in the test function. Available client instances are preferentially retrieved from the client pool corresponding to the chain ID, and new instances are automatically created when resources in the pool are insufficient.

[0190] (2) Unified recycling. During the post-test cleanup phase, all clients are automatically recycled to the corresponding pools. Each return operation refreshes the timeout timer of the pool (e.g., 5 minutes).

[0191] (3) Expiration cleanup. Client pools that have exceeded the preset idle time will be automatically released to avoid resource leaks.

[0192] VI. The test function management process is as follows:

[0193] Figure 15 The process for acquiring and releasing test functions is illustrated. The specific process for enabling test functions and obtaining their instances is described below:

[0194] (1) Obtain test functions. The test process controller requests the specified test functions from the DefaultTestFunctionManager.

[0195] (2) Functional status check.

[0196] a) If the test function is in the StatusActivate state, you can continue;

[0197] b) If it is in the PreDeactivation or Deactivated state, it is considered unavailable and a failure is returned directly.

[0198] (3) Instance generation and reference counting.

[0199] a) If the functionality status is available, DefaultTestFunctionManager creates a test functionality instance;

[0200] b) Call the addCounter method of Counter to increment the function instance reference count.

[0201] (4) Return to the test function instance. The successfully created test function instance will be returned to the test process controller.

[0202] The detailed process for disabling the testing function is described below:

[0203] (1) Call the test function deactivation function (UnBindFunction). The test process controller requests...

[0204] DefaultTestFunctionManager disables the specified test functionality.

[0205] (2) Set to be disabled.

[0206] a) The status is updated to StatusPreDeactivation;

[0207] b) indicates that the function is waiting for its referenced instance to be released and cannot be fully recycled yet.

[0208] (3) Enter the waiting judgment loop.

[0209] a) Poll the Counter periodically (every 5ms);

[0210] b) If the counter value is greater than 0, continue to wait, indicating that there are still functional instances in use;

[0211] c) If the counter value is 0, it means that no other task is using this function.

[0212] (4) The status changes to deactivated. When the reference count reaches zero, the status is set to StatusDeactivated, and the function deactivation process is complete.

[0213] Compared with existing technologies, the blockchain cross-chain testing and development platform provided by this invention has the following significant advantages:

[0214] This invention addresses a series of technical pain points in the current cross-chain testing field, such as poor test tool versatility, high development costs, difficulty in adaptation, insufficient scalability, and low degree of test execution automation. It provides a complete solution by systematically integrating five core mechanisms: test process service, system under test adaptation, functional extension mechanism, task scheduling, and resource management. The platform effectively overcomes the technical challenges of cross-chain testing at five key levels: functional generalization, system heterogeneity adaptation, functional scalability, multi-task concurrent scheduling, and resource coordination. It proposes a general platform architecture that combines high abstraction with engineering feasibility.

[0215] In summary, the technical solution proposed in this invention significantly improves the development efficiency of cross-chain testing functions, greatly reduces the cost of repetitive development and adaptation, enhances the automation level and execution efficiency of the testing process, and provides reliable and efficient support for the performance evaluation and security verification of cross-chain systems. It has good industrial application value and promotion prospects.

[0216] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0217] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0218] Of course, the present invention may have other various embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention, but these corresponding changes and modifications should all fall within the protection scope of the appended claims.

Claims

1. A blockchain cross-chain test and development platform, characterized in that, It includes a basic service module for test function development, a general adaptation module for the system under test, a test function extension module, a multi-task concurrent scheduling module, and a test resource management module, among which: The aforementioned test function development basic service module is used to standardize the test task execution process into a pre-test preparation stage, a test execution stage, and a post-test cleanup stage, and encapsulates traffic generation services and data collection services for test functions to call. The general adaptation module of the system under test is used to define a standardized blockchain client interface to provide interactive operations with heterogeneous blockchain systems, and to collect internal data of the system under test through an off-chain instrumentation mechanism; wherein, the interactive operations include one or more of transaction sending, status querying and event listening; The test function extension module is used to access and manage test functions in a plug-in manner through a unified test function interface; The multi-task concurrent scheduling module is used to maintain the task queue through the scheduling engine, and to allocate the test tasks in the task queue to idle worker nodes in parallel based on the worker pool for execution. At the same time, the test tasks are tracked and managed through the preset test task data structure and status definition. The test resource management module is used to register, query, lock, release and reuse chain-level resources; and to maintain the blockchain client instance pool to realize intelligent allocation, unified recycling and expiration cleanup of clients.

2. The blockchain cross-chain test and development platform according to claim 1, characterized in that, The traffic generation service is configured to support multiple traffic modes, including fixed rate mode, burst traffic mode, ramp growth mode and Poisson distribution mode. The data acquisition service is configured to support multiple data acquisition modes, including single query, polling until state changes, polling until conditions are met, continuous collection of state changes, and event listening and unified callback.

3. The blockchain cross-chain test and development platform according to claim 1, characterized in that, The blockchain client interface is configured to perform the following operations: Transaction-related operations include one or more of the following: creating a transaction, sending a transaction, obtaining the transaction status, and obtaining the transaction confirmation time; Status query operations include retrieving the latest block, querying a specified block, querying account balance, and calling one or more contract methods; Event-based operations include subscribing to events and retrieving one or more of the event's related properties.

4. The blockchain cross-chain test and development platform according to claim 1, characterized in that, The off-chain instrumentation mechanism specifically includes: uniformly encapsulating the data collected internally by the system under test into a metric data structure for forwarding, wherein the metric data structure includes event type, source identifier, timestamp, and data details fields.

5. The blockchain cross-chain test and development platform according to claim 1, characterized in that, The unified test function interface is used to create test instances and obtain test function metadata; the test function extension module also includes a test function manager, which is used to register, address and manage the status of test functions that implement the test function interface.

6. The blockchain cross-chain test and development platform according to claim 5, characterized in that, The test function manager is also used to dynamically start and stop the test function, including setting the test function to a pre-disabled state and setting it to a disabled state after all test instances have been executed.

7. The blockchain cross-chain test and development platform according to claim 1, characterized in that, The preset test task data structure includes a unique task identifier, test context, task status, task status channel, and test result field.

8. The blockchain cross-chain test and development platform according to claim 1, characterized in that, The test resource management module includes: The resource controller is used to manage the status of chain-level resources, maintain resource waiting queues and perform concurrent conflict judgments; and allocate exclusive locks or shared locks to the resources for the test tasks according to the resource isolation level requirements declared in the test function declaration. The task tracker corresponds one-to-one with the test task and is used to maintain a list of all chain-level resources requested by the corresponding task.

9. The blockchain cross-chain test and development platform according to claim 1, characterized in that, The maintenance of the blockchain client instance pool enables intelligent allocation, unified recycling, and expiration cleanup of clients, including: Idle client instances are preferentially selected from the blockchain client instance pool; when the number of instances in the blockchain client instance pool is insufficient, new instances are automatically created; Release client instances that have been idle for a preset period of time.

10. The blockchain cross-chain test and development platform according to claim 1, characterized in that, The pre-test preparation phase includes one or more of the following: task metadata registration, test resource isolation and locking, blockchain client initialization, and functional availability checks. The post-test cleanup phase includes one or more of the following: resource release, client instance return, and test result persistence.

Images