Block chain port test method and device based on event monitoring and state prediction

Abstract

The invention relates to a block chain port test method and device for event monitoring and state prediction, and the method comprises the steps: obtaining interface request data which comprises the request information of an interface request and a network environment parameter when the interface request is sent; predicting a response time point of an event triggered by the interface request according to the interface request data; at the response time point, calling a pre-constructed callback function according to an event triggered by the interface request; and obtaining a test result of the interface request according to the callback message generated after the callback function is called, and solving the problem of low efficiency of block chain interface test.

Description

Technical Field

[0001] The present application relates to the field of blockchain, and in particular to a blockchain interface testing method and device based on event monitoring and state prediction. Background Art

[0002] When the blockchain interface test performs asynchronous operations, the result will not be obtained immediately after sending the request. Instead, you need to wait for a while to confirm whether the operation is completed successfully.

[0003] In related technologies, to implement asynchronous operations in blockchain interface testing, the sleep function is often used to wait for a period of time before checking the request status, or polling is used to periodically check the operation status. As a result, additional waiting time is required for interface requests, reducing testing efficiency.

[0004] There is currently no effective solution to the problem of low efficiency in blockchain interface testing in related technologies. Summary of the Invention

[0005] Based on this, it is necessary to provide a blockchain interface testing method and device based on event monitoring and state prediction that can solve the above technical problems and improve the efficiency of blockchain interface testing.

[0006] First, in this embodiment, a blockchain interface testing method based on event monitoring and state prediction is provided, the method comprising:

[0007] Acquiring interface request data, the interface request data including request information of the interface request and network environment parameters when the interface request is sent;

[0008] Predicting a response time point of an event triggered by the interface request based on the interface request data;

[0009] At the response time point, calling a pre-built callback function according to the event triggered by the interface request;

[0010] The test result of the interface request is obtained according to the callback message generated after the callback function is called.

[0011] In some embodiments, at the response time point, calling a pre-built callback function according to the event triggered by the interface request includes:

[0012] Allocating corresponding callback function parameters for event types of events triggered by a plurality of the interface requests to construct the callback function, wherein the callback function is used to check the status of the interface request and / or the response result of the interface request;

[0013] Constructing a callback function list according to the event type and the callback function;

[0014] At the response time point, based on the type of the interface request, the callback function in the callback function list is called.

[0015] In some embodiments, obtaining the test result of the interface request according to the callback message generated after the callback function is called includes:

[0016] Sending the callback message to a message queue;

[0017] According to the sending time of the callback message, the data in the message queue is parsed in sequence to obtain the execution status information of the interface request;

[0018] The test result is generated according to the execution status information.

[0019] In some embodiments, predicting a response time point of an event triggered by the interface request according to the interface request data includes:

[0020] Obtain training data based on historical interface request data;

[0021] training a pre-built machine learning model based on the training data;

[0022] The interface request data is input into the trained machine learning model, and the response time point is output.

[0023] In some embodiments, inputting the interface request data into the trained machine learning model and outputting the response time point further includes:

[0024] Inputting the interface request data into the trained machine learning model, and outputting the response time point and the first computing resource required to execute the interface request;

[0025] Pre-allocate second computing resources for executing the interface request based on the first computing resources.

[0026] In some embodiments, inputting the interface request data into the trained machine learning model and outputting the response time point further includes:

[0027] Inputting the interface request data into the trained machine learning model;

[0028] When the machine learning model outputs the response time point and potential fault information, restart the faulty node or stop testing the interface request according to the potential fault information.

[0029] In some embodiments, obtaining request information of the interface request data includes:

[0030] Sending the interface request to the blockchain interface;

[0031] Determine the target event, target node of the blockchain, and monitoring time according to the type of the interface request;

[0032] Accessing the target node and monitoring the target event within the monitoring time;

[0033] According to the monitoring result, request information for requesting data from the interface is obtained.

[0034] In some embodiments, obtaining the interface request data associated with the interface request according to the monitoring result includes:

[0035] If it is determined according to the monitoring result that the interface request is in the target state, checking the integrity of the transaction data related to the interface request;

[0036] When it is determined that the transaction data related to the interface request is complete, the interface request data is obtained according to the monitoring result.

[0037] In a second aspect, a blockchain interface testing device based on event monitoring and state prediction is provided in this embodiment, and the device includes:

[0038] A collection module, configured to obtain interface request data, wherein the interface request data includes the type of the interface request, request parameters of the interface request, and network environment parameters when the interface request is sent;

[0039] A prediction module, configured to predict a response time point of an event associated with the interface request based on the interface request data;

[0040] A calling module, configured to call a pre-built callback function at the response time point according to an event triggered by the interface request;

[0041] The parsing module is used to obtain the test result of the interface request according to the response data generated after the callback function is called.

[0042] In a third aspect, a computer device is provided in this embodiment, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the blockchain interface testing method based on event monitoring and state prediction described in the first aspect is implemented.

[0043] The above-mentioned blockchain interface testing method and device for event monitoring and status prediction estimates the response time point of the interface request triggering event based on the interface request data, and executes the trigger callback function based on the response time point to obtain the callback message, which can avoid invalid waiting and frequent checks and greatly improve test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is an application environment diagram of a blockchain interface testing method based on event monitoring and state prediction in one embodiment;

[0045] Figure 2 1. A flowchart of a blockchain interface testing method based on event monitoring and state prediction in one embodiment;

[0046] Figure 3 A schematic diagram of the interface test process in one embodiment;

[0047] Figure 4 This is a structural block diagram of a blockchain interface testing device based on event monitoring and state prediction in one embodiment;

[0048] Figure 5 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0050] The blockchain interface testing method based on event monitoring and state prediction provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store data that server 104 needs to process. The data storage system can be integrated with server 104 or located in the cloud or on other network servers. Blockchain interface testing is performed based on terminal 102 or the interaction between terminal 102 and server 104. Terminal 102 can be, but is not limited to, various personal computers, laptops, tablets, etc. Server 104 can be implemented as a standalone server or a server cluster consisting of multiple servers.

[0051] In one embodiment, Figure 2 As shown in the figure, a blockchain interface testing method based on event monitoring and state prediction is provided. Figure 1 Taking the terminal 102 in FIG. 1 as an example, the method includes the following steps:

[0052] Step 202: Acquire interface request data, where the interface request data includes request information of the interface request and network environment parameters when the interface request is sent.

[0053] An interface request is a request sent through a specific API (Application Programming Interface) or protocol when interacting with a blockchain network. Upon receiving the interface request data, the blockchain executes asynchronous operations. The interface request data includes request information such as the interface request type, request parameters, and request time. Request types can include transaction requests, query requests, and smart contract deployment requests. Request parameters are the specific information or data required when sending a request to the blockchain. The request time includes the time the request was initiated. The network environment parameters at the time the interface request was sent include network information such as bandwidth fluctuations and latency. Optionally, obtaining the interface request data includes: obtaining the interface request information from the blockchain log after initiating the interface request to the blockchain; and obtaining the network environment information at the time the interface request was sent using a network monitoring tool.

[0054] Step 204: predict the response time point of the event triggered by the interface request based on the interface request data.

[0055] The events triggered by an interface request are the various events triggered in response to an interface request after the interface request is issued to the blockchain. These events include not only the interface request results but also the intermediate events triggered by the interface request. Optionally, based on historical interface request data and the corresponding event response time points, an association relationship is established between the interface request data and the response time points of various triggering events. Based on this association relationship, the currently acquired interface request data is mapped to predict the response time point of the triggering event corresponding to the interface request data of the current interface request. When an interface request triggers multiple events, the response time points of multiple events can be predicted.

[0056] Step 206: At the response time point, the pre-built callback function is called according to the event triggered by the interface request.

[0057] The callback function can be used to receive intermediate request status, such as the transaction ID and confirmation status, block hash, and block number associated with the interface request. Alternatively, the callback function can be used to obtain the response result of the interface request. The callback function can also obtain both the status and response result of the interface request. Depending on the event triggered by the interface request, the corresponding callback function can be different or the same. The correspondence between the triggering event and the interface request can be configured according to test requirements.

[0058] Optionally, when the response time points of multiple events triggered by the interface request are predicted based on the interface request data, when each response time point arrives, the corresponding callback function is called according to the event type of the triggering event, so that the callback function obtains the callback message.

[0059] Step 208: Obtain the test result of the interface request according to the callback message generated after the callback function is called.

[0060] The callback message includes not only the response to the interface request but also intermediate status information about various intermediate events during the interface request process. Optionally, the callback messages are parsed sequentially according to their generation order to obtain execution status information about the interface request. This execution status information is used as the test result, allowing the test user to conduct analysis based on the execution status information.

[0061] In the above-mentioned blockchain interface testing method based on event monitoring and status prediction, the response time point of the interface request triggering event is predicted according to the interface request data, and the intermediate status information is received through the callback function, thereby avoiding invalid waiting and frequent checks of the interface status during the interface testing process, greatly improving the testing efficiency, reducing the server burden, and solving the problem of low efficiency of blockchain interface testing.

[0062] In one embodiment, at a response time point, a pre-built callback function is called according to an event triggered by an interface request, including: allocating corresponding callback function parameters for event types of events triggered by multiple interface requests to construct a callback function, wherein the callback function is used to check the status of the interface request and / or the response result of the interface request; constructing a callback function list according to the event type and the callback function; at a response time point, calling the callback function in the callback function list based on the type of the interface request.

[0063] Different callback function parameters can be defined for different event types. This allows different callback functions to execute different predefined logic based on different triggering events, checking the status of the interface request and / or the response result of the interface request. Alternatively, the callback function can specify corresponding predefined logic based on the specific event data and event execution status of the interface request triggering event. For ease of understanding, the definition of callback function parameters is explained using the event types of transaction confirmation and block generation as examples: For the transaction confirmation event, the corresponding callback function is named handle_transaction_confirmation; and the callback function parameters are defined so that the callback function receives multiple information, including the transaction ID and confirmation status. Optionally, by defining callback function parameters, the callback function corresponding to the transaction confirmation event can check the confirmation status in the triggering event data: if the status is "confirmed", it executes predefined logic such as printing a confirmation message or updating a database record; if the status is not "confirmed", it executes other predefined logic such as printing an unconfirmed message or retrying the transaction. For block generation events, the corresponding callback function is named handle_block_generation and its parameters are defined so that the callback function receives multiple pieces of information, including a block hash and block number. Optionally, by defining callback function parameters, the callback function corresponding to the block generation event can check the block hash and block number in the incoming event data and execute corresponding logic based on the incoming event data. For example, the executed logic may include printing a block generation message or appending the block information to a log file.

[0064] Register a callback function based on the event type and callback function parameters to be called when the event occurs. Optionally, construct a method that takes the event type and the corresponding callback function as parameters. Furthermore, to quickly find and call the correct callback function when an event occurs, the event type and callback function can be stored in a data structure within the framework. For example, construct a register_event_handler method that accepts the event type and the callback function "transaction_confirmation" or "block_generation" mentioned above. Taking the example of storing the event type and callback function in a dictionary, optionally, when registering the callback function, specify the event type and corresponding callback function to be registered and receive the event type and callback function as input parameters. When calling the register method, check whether the passed event type already exists in the dictionary storing callback functions. If not, create an empty callback function list for the event type and add it to the dictionary. The passed callback function is then added to the callback function list for the corresponding event type. When the event type is triggered, all callback functions in the callback function list are called sequentially.

[0065] Based on the event type and callback function parameters, a callback function list is constructed, establishing a mapping between event types and functions. One event type can correspond to one or more callback functions. Optionally, to efficiently manage and store registered callback functions, a key-value pair approach can be used to quickly find and store data. The event type is used as the key in a dictionary, allowing users to quickly locate the corresponding callback function in the callback function list based on the event type. The callback function list is used as the value in the dictionary. This allows multiple callback functions to be defined and registered for the same event type, so a list is used to store these callback functions. For example, for the "Transaction Confirmation" event type, a callback function for logging transactions and another for updating account balances can be mapped separately. Both callback functions are stored in the "Transaction Confirmation" list. It is understood that callback function management and storage can also be implemented through hash tables, databases, and other methods.

[0066] Traditional callback functions typically only obtain the final response result and are unable to provide more valuable information during the execution of an interface request. In this embodiment, a callback function is customized according to the event type, so that the callback function has the ability to receive intermediate status information and the final response result during the interface request process. The callback message obtained through the callback can accurately obtain the test results. For example, based on the intermediate status information, the execution status of the request can be judged in advance. If a key step is found not to be executed as expected, appropriate measures can be taken in a timely manner, improving the timeliness of problem handling and the accuracy of testing.

[0067] In one embodiment, the test result of the interface request is obtained based on the callback message generated after the callback function is called, including: sending the callback message to the message queue; parsing the data in the message queue in sequence according to the sending time of the callback message to obtain the execution status information of the interface request; and generating the test result based on the execution status information.

[0068] The message queue can utilize a mature message queue system such as RabbitMQ or Kafka. Optionally, a message queue server can be installed and configured in the test environment. After an interface request is issued, when the callback function is triggered and the interface request generates a callback message, the callback message is sent to the message queue. The test program sequentially retrieves and parses messages from the message queue. This involves interacting with the message queue to retrieve callback messages. Upon receiving each message, the test program parses the message content to obtain the interface request execution status information carried in the callback message. This execution status information includes intermediate status information of the interface request and the final response result. Based on this execution status information, the interface request's normal operation can be determined. Optionally, after determining the normal operation of the interface request based on the execution status information, any anomalies detected can be promptly recorded, including the time of the anomaly, request parameters, and exception information. Recording anomalies facilitates subsequent analysis of the cause of interface testing issues, thereby achieving an efficient and accurate testing process.

[0069] In this embodiment, by introducing a message queue mechanism, the loss of callback messages due to network fluctuations can be prevented, thereby improving the accuracy of the blockchain interface testing method based on event monitoring and state prediction.

[0070] In one embodiment, the response time point of an event triggered by an interface request is predicted based on the interface request data, including: obtaining training data based on historical interface request data, and training a pre-built machine learning model based on the training data; inputting the interface request data into the trained machine learning model, and outputting the response time point.

[0071] The training data includes historical interface request information and network environment information. Request information includes, but is not limited to, request parameters such as transaction requests, query requests, and contract call requests, transaction amount, and specific attributes of the contract address. The network environment includes fluctuations in network bandwidth and latency. The request types and parameters of historical interface requests can be obtained from test logs and / or the blockchain node database. Optionally, detailed information for each interface request, including the request type, parameters, and time, can be obtained from the test logs. For example, in testing a consortium chain smart contract call, information such as the contract call function name, parameter values ​​passed in, and call initiation time can be obtained from the logs. Optionally, transaction details such as transaction inputs and outputs, transaction fees, and confirmation time can be obtained using the query interface provided by the consortium chain or by directly accessing the blockchain node database. The network environment in the training data can be obtained using network monitoring tools. Alternatively, specialized monitoring tools, such as Prometheus combined with Grafana, can be used to monitor network bandwidth, latency, and other network status information in real time, as well as the response time and request status of interface requests.

[0072] Furthermore, after obtaining the training data, the data can also be pre-processed. Optionally, the training data can be cleaned, including: using data processing tools to remove duplicate records in the collected data. In the case of training data with missing values, if the training data with missing values ​​is numerical data, it can be filled using methods such as mean and median; if the training data with missing values ​​is text data, if the missing values ​​exceed the specified exact ratio, the relevant records can be deleted. If the missing values ​​do not exceed the specified exact ratio, they can be supplemented according to business logic. Among them, numerical data includes network delay, network fluctuation, etc. Text data includes transaction notes information, contract address, etc.

[0073] Optionally, normalize the training data. This involves converting data of varying ranges and scales to a specific range. For example, use the MinMaxScaler (minimum-maximum normalizer) to convert network bandwidth data from actual bandwidth values ​​to the range [0, 1]. Normalizing training data makes it more suitable for the input requirements of machine learning models, improving model training results and accelerating model convergence.

[0074] Pre-built machine learning models trained on training data can use models such as long short-term memory networks and convolutional neural networks. LSTM (Long Short-Term Memory) is a special type of recurrent neural network that effectively processes time series data and addresses the vanishing and exploding gradient issues of traditional RNNs (Recurrent Neural Networks). It is well-suited for predicting time-related problems such as interface response times and state changes. Alternatively, using a long short-term memory network for intelligent prediction as an example, the following explains how to define the machine learning model structure:

[0075] model = Sequential()

[0076] model.add(LSTM(units=64, input_shape=(time_steps, features)))

[0077] model.add(Dense(1))

[0078] model.compile(optimizer='adam', loss='mse')

[0079] Here, time_steps represents the length of the time series, and features represents the number of features in the input data. The preprocessed training data is then divided into a training set and a test set according to the specified ratio. The training set ratio can be set between 70% and 80%. The training set data is input into the model for training. During training, parameters such as the learning rate and number of iterations are set as needed. For example, the learning rate can be set between 0.001 and 0.01, and the number of iterations can be set between dozens and hundreds. The LSTM model learns the patterns and features in the training data and automatically adjusts its parameters to achieve more accurate predictions.

[0080] After inputting the interface request data into the trained machine learning model, the response time from the interface request being issued to the response being received is output. For ease of understanding, under the current network bandwidth of 10Mbps and the latency of 50ms, the response time of a specific consortium chain smart contract calling the interface is predicted to be approximately 5 seconds. 5 seconds after the interface request is issued, the response time is determined to have been reached and the interface status check begins.

[0081] Furthermore, trained machine learning models can not only predict response times but also the status changes of interface requests. For example, a machine learning model can predict whether a blockchain transaction request will transition from the "pending confirmation" state to the "confirmed" state, or whether a smart contract deployment request will succeed. Predicting the status changes of interface requests can provide testers with an early estimate of the execution results of interface requests.

[0082] In this embodiment, the trained machine learning model can accurately predict the interface requests corresponding to different interface request data through in-depth analysis and learning of historical interface request data, and the time required from issuing a request to receiving a response, thereby avoiding blind waiting or frequent invalid checks on the interface status, and improving test efficiency and accuracy.

[0083] Furthermore, for complex interface requests, more computing resources will be consumed during their execution. In order to reduce the possibility of lag or failure during the execution of the interface request due to insufficient resources, in one embodiment, the interface request data is input into the trained machine learning model, and the response time point is output. It also includes: inputting the interface request data into the trained machine learning model, outputting the response time point and the first computing resources required to execute the interface request; and pre-allocating the second computing resources when executing the interface request based on the first computing resources.

[0084] Among them, computing resources include CPU, memory and other resources required to execute the interface request. The second computing resource is greater than or equal to the first computing resource, so that the interface request will not be affected by insufficient computing resources.

[0085] Optionally, the type of the interface request can be obtained. When the interface request belongs to a preset type, it is determined that the interface request is of a type that will consume a large amount of CPU resources when executed. The machine learning model estimates the demand for computing resources during the execution of the current interface request based on the interface request data of the interface request to obtain the first computing resource, and determines the second computing resource reserved for the request on the test server based on the first computing resource; conversely, when the interface request does not belong to the preset type, the machine learning model does not predict the first computer resource.

[0086] In this embodiment, by pre-allocating the second computing resources, it is ensured that the interface request will not be stuck or fail due to insufficient resources during execution, thereby improving the stability and accuracy of the test.

[0087] Furthermore, in one embodiment, the interface request data is input into the trained machine learning model and the response time point is output, which also includes: inputting the interface request data into the trained machine learning model; when the machine learning model outputs the response time point and potential fault information, restarting the faulty node or stopping testing the interface request according to the potential fault information.

[0088] If the machine learning model detects abnormal patterns or trends in a certain type of interface request, such as a gradually increasing error rate or unusual response time fluctuations, based on interface request data, it can predict a potential system failure and output potential failure information. Alternatively, if the potential failure information indicates a blockchain node failure or an impending failure in a blockchain node service module, a callback mechanism is triggered to restart the node in an attempt to automatically restore the failed node's functionality. If the potential failure information indicates that the interface request cannot be executed, or if restarting the node fails, the step of calling the pre-built callback function at the response time point is determined not to be executed, and the test is terminated.

[0089] In this embodiment, the machine learning model can predict potential fault information by analyzing interface request data, thereby improving the stability and efficiency of interface testing.

[0090] In one embodiment, obtaining request information of interface request data includes: sending an interface request to a blockchain interface; determining a target event, a target node of the blockchain, and a listening time according to the type of the interface request; accessing the target node and listening to the target event within the listening time; and obtaining request information of the interface request data according to the listening result.

[0091] Different interface requests require different target events to monitor. Optionally, key monitoring events should be comprehensively identified for different blockchain interface types. When the interface request corresponds to a blockchain transaction interface, target events generated at each stage of the transaction, from initiation, verification, packaging, to confirmation, should be monitored. For example, taking a supply chain finance consortium chain transaction as an example, monitoring the initiation event will record the company information of both parties, the transaction amount, and the transaction time. Monitoring the verification event will determine whether the transaction complies with the consortium chain rules, for example, checking whether the transaction amount is within the company's credit limit and whether the transaction signature is valid. Monitoring the packaging event will determine whether the transaction is included in a new block to achieve final confirmation and confirm its immutability. Monitoring the confirmation event will determine whether the transaction is successfully completed, which can obtain request information such as the number of confirmations and the block height. When the interface request corresponds to a smart contract deployment interface, target events such as contract upload, compilation, and successful deployment should be monitored. Optionally, taking the deployment of a smart contract for product traceability as an example, by monitoring the upload event, the time and related information when the contract code is submitted to the consortium chain network can be recorded; by monitoring the compilation event, the compilation status of the contract code in the consortium chain environment can be fed back. If the compilation fails, detailed error information will be obtained, such as syntax errors, function call errors, etc.; by monitoring the deployment success event, the contract address, deployment transaction hash and other key information important for subsequent contract calls and tests can be obtained.

[0092] After determining the target event, you can further set the monitoring time for the target event and the target node associated with the target event. Optionally, a monitoring rule can be determined based on the type of interface request. Using the consortium chain node's inherent event monitoring functionality, the consortium chain continuously monitors designated event logs based on the target event, blockchain target node, and monitoring time specified in the monitoring rule. This method includes: determining the target event to monitor based on the type of interface request. Target events include initiation, verification, packaging, and confirmation events corresponding to transaction interfaces, and upload, compilation, and deployment success events corresponding to smart contract deployment interfaces. When target events correspond to transaction interfaces, they are matched using transaction identifiers (such as transaction hashes) to ensure that only transaction events relevant to the current test are processed. A monitoring time range can be set in the monitoring rule to focus only on events occurring within a specific time period, reducing unnecessary event processing. If the consortium chain has multiple nodes, node screening can be performed, including selecting events from the target node to monitor in the monitoring rule or aggregating events from multiple nodes.

[0093] Optionally, accessing the target node includes: configuring corresponding parameters according to the access specifications of the alliance chain, using the software development kit (SDK) or application programming interface (API) officially provided by the alliance chain, the configuration parameters including the address, port number, identity authentication information, etc. of the alliance chain node, and using the corresponding connection function to connect to the alliance chain node.

[0094] Based on the monitoring results, the request information for the interface request data is obtained. For example, when a transaction confirmation event is detected on the consortium chain, the corresponding transaction request record is found in the local record based on the transaction hash, and the transaction status of the local record is updated from "pending confirmation" to "confirmed". Information such as the number of confirmations and the block height are also added.

[0095] In this embodiment, based on the type of interface request, monitoring rules including target event, target node of blockchain and monitoring time are obtained to achieve accurate monitoring of target event.

[0096] Furthermore, in one embodiment, interface request data associated with the interface request is obtained based on the monitoring results, including: when it is determined based on the monitoring results that the interface request is in the target state, checking the integrity of the transaction data related to the interface request; when it is determined that the transaction data related to the interface request is complete, obtaining the interface request data based on the monitoring results.

[0097] The status of an interface request refers to the state of the request from the moment it is issued to the moment it is responded to. The status of an interface request allows tracking of the request's response phase. The target state indicates that the blockchain has confirmed the interface request, meaning that the request has not only been accepted by nodes in the network but also packaged into a block. Optionally, when a transaction confirmation event is detected on the consortium chain, the corresponding transaction request record is found in the local record based on the transaction hash. The transaction status in the local record is updated from "pending confirmation" to "confirmed," and information such as the number of confirmations and the block height in which it is located is added to determine that the interface request is in the target state.

[0098] At the same time, the integrity of the transaction data is checked, including comparing the transaction amount, addresses of both parties, and other information in the transaction record with the records on the blockchain to ensure consistency. If the transaction data is complete, the interface request data is obtained based on the monitoring results. If the transaction data is incomplete, error information is promptly recorded, including missing fields and incorrect values, to facilitate subsequent troubleshooting.

[0099] In this embodiment, when it is determined through monitoring that the interface request is in the target state, the integrity of the transaction data is detected to provide a guarantee for obtaining the accurate interface state during interface testing.

[0100] In the related art, the asynchronous operation processing in the blockchain interface test currently mainly relies on the Sleep mechanism and the retry mechanism. Among them, the Sleep mechanism is that after the test script issues a request, it uses the Sleep function to wait for a period of time before checking the request status. This method is simple and easy, but inefficient, and the waiting time is difficult to determine. If it is too short, the status may not be synchronized, and if it is too long, it will waste testing time. After the request is issued, the retry mechanism continuously checks the request status through polling until the preset number of retries is reached or the status is updated. Although this method improves the success rate, it increases the network burden and testing time, and for some frequently changing interface states, it may still not be accurately captured. In addition, the retry mechanism increases the number of network requests and wastes test resources. Therefore, both the Sleep mechanism and the retry mechanism require additional waiting time, which reduces the test efficiency. Based on this, in one embodiment, Figure 3 A flowchart of the interface test is provided. Efficient and accurate testing is achieved by building real-time status monitoring, intelligent prediction models (trained machine learning models), and optimizing callback mechanisms, such as Figure 3 Shown, including:

[0101] Step 301, starting the test, is the starting point of the entire test execution phase.

[0102] Step 302: Issue an interface request: The test program sends an asynchronous request to the alliance chain interface.

[0103] Step 303, real-time status monitoring: Utilize the event monitoring function of the alliance chain node to monitor the event log according to the established monitoring rules. The monitoring rules include the target event to be monitored, the target node of the blockchain, and the monitoring time.

[0104] Step 304: Determine whether a key event has been detected. Determine whether the previously determined key event, i.e., the target event in the above embodiment, has been captured. The target event can be an event such as transaction confirmation, successful deployment of a smart contract, etc. If a key event is detected, the process proceeds to update the local record status, i.e., execute step 305; if no key event is detected, continue real-time status monitoring.

[0105] Step 305: Update the local record status. After a key event is detected, the locally recorded interface request status is updated, for example, the transaction status is updated from "waiting for confirmation" to "confirmed".

[0106] Step 306: Check data integrity: Perform an integrity check on the relevant transaction or contract data, comparing the local record with the data on the blockchain to ensure consistency. Optionally, set "Confirmed" as the target state, and perform the data integrity check when the locally recorded interface request status is updated to the target state.

[0107] Step 307: Determine whether the data is complete: Determine the result of the data integrity check. If the data is complete, proceed to the intelligent prediction and status check phase, i.e., execute step 309; if it is incomplete, record the data anomaly information, i.e., execute step 308.

[0108] Step 308: Record data anomaly information. Optionally, record the specific details of incomplete data, including missing fields, incorrect values, etc., for subsequent analysis.

[0109] Step 309, Intelligent Prediction and Status Check: This collects the interface request data for the current interface request and feeds it into the trained machine learning model. The interface status is checked at a selected time point within the response time predicted by the trained machine learning model. When the predicted response time point arrives, a pre-built callback function is automatically triggered to check the status and result of the interface request.

[0110] Step 3010: The callback mechanism is triggered. When the response time point arrives, the interface request has an intermediate state change or a final response result, and the callback function is triggered through the callback mechanism to obtain a callback message.

[0111] Step 3011, sending the callback message to the message queue: sending the message generated by the callback function to the message queue to ensure that the message will not be lost due to network fluctuations and other problems.

[0112] In step 3012, the test program retrieves messages from the queue. Optionally, the test program retrieves messages from the message queue in chronological order from the front to the back.

[0113] Step 3013, parsing the message content: parsing the obtained callback message to extract the interface request execution status information therein.

[0114] Step 3014: Determine whether the interface request is normal: Based on the parsed callback message, determine whether the interface request is executed normally. If the interface request is normal, proceed to the next request phase, that is, execute step 302; if the interface request is abnormal, record the abnormal information, that is, execute step 3015.

[0115] Step 3015, record exception information: record the exception situation during the execution of the interface request, such as the reason for the request failure, error code, etc.

[0116] Step 3016, continue to the next request: prepare to perform the test process of the next interface request.

[0117] Step 3017, determine whether there are any requests: determine whether there are any untested interface requests. If yes, return to the interface request issuance phase to continue testing, i.e., execute step 302; if no, enter the end test phase, i.e., execute step 3018.

[0118] Step 3018, end the test: indicates that the entire test execution phase is completed.

[0119] In this embodiment, the real-time status monitoring method can quickly capture changes in interface status, providing a guarantee for obtaining accurate interface status; the intelligent prediction model (trained machine learning model) can accurately estimate the response time point, avoid ineffective waiting and frequent checks, greatly improve test efficiency, reduce waiting time, and reduce server burden. The callback mechanism is executed at the response time point, and the callback function is redesigned in the callback mechanism to receive intermediate status information, thereby improving the timeliness of problem handling and test accuracy; by introducing the callback message generated by the callback function into the message queue, the reliable delivery of the message can be ensured, which can reduce retries caused by network fluctuations and reduce network resource consumption. In addition, by obtaining key interface request data through real-time monitoring methods, the intelligent prediction model accurately grasps the response time point based on the interface request data and handles abnormal information in a timely manner, comprehensively improving test accuracy and ensuring reliable test results.

[0120] It should be understood that, although the various steps in the flowcharts involved in the above embodiments are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps. For example, when the callback mechanism is triggered and the callback message is sent to the message queue, the steps of the test program obtaining the message from the queue and parsing the message content can be executed synchronously.

[0121] Based on the same inventive concept, the embodiment of the present application also provides a blockchain interface testing device based on event monitoring and state prediction for implementing the above-mentioned blockchain interface testing method based on event monitoring and state prediction. The implementation solution provided by the device is similar to the implementation solution described in the above-mentioned method. Therefore, the specific limitations of one or more embodiments of the blockchain interface testing device based on event monitoring and state prediction provided below can be found in the above-mentioned limitations on the blockchain interface testing method based on event monitoring and state prediction, and will not be repeated here.

[0122] In one embodiment, Figure 4 As shown, a blockchain interface testing device based on event monitoring and state prediction is provided, including: an acquisition module, a prediction module, a call module and a parsing module, wherein:

[0123] The acquisition module is used to obtain interface request data, which includes the type of interface request, the request parameters of the interface request, and the network environment parameters when the interface request is sent;

[0124] A prediction module is used to predict the response time point of the event associated with the interface request based on the interface request data;

[0125] The calling module is used to call the pre-built callback function according to the response time point; the callback function is used to check the status of the interface request and / or the response result of the interface request;

[0126] The parsing module is used to obtain the test result of the interface request based on the response data generated after the callback function is called.

[0127] In some of these embodiments, the calling module calls a pre-built callback function at a response time point according to an event triggered by an interface request, including: allocating corresponding callback function parameters for event types of events triggered by multiple interface requests to construct a callback function, wherein the callback function is used to check the status of the interface request and / or the response result of the interface request; constructing a callback function list according to the event type and the callback function; and calling the callback function in the callback function list at the response time point based on the type of the interface request.

[0128] In some embodiments, the parsing module obtains the test result of the interface request based on the callback message generated after the callback function is called, including: sending the callback message to the message queue; parsing the data in the message queue in sequence according to the sending time of the callback message to obtain the execution status information of the interface request; and generating the test result based on the execution status information.

[0129] In some embodiments, the prediction module predicts the response time point of an event triggered by an interface request based on the interface request data, including: obtaining training data based on historical interface request data; training a pre-built machine learning model based on the training data; inputting the interface request data into the trained machine learning model, and outputting the response time point.

[0130] Optionally, the prediction module inputs the interface request data into the trained machine learning model and outputs the response time point, and also includes: inputting the interface request data into the trained machine learning model, outputting the response time point and the first computing resources required to execute the interface request; based on the first computing resources, pre-allocating the second computing resources when executing the interface request.

[0131] Optionally, the prediction module inputs the interface request data into the trained machine learning model and outputs the response time point, and also includes: inputting the interface request data into the trained machine learning model; when the machine learning model outputs the response time point and potential fault information, restarting the faulty node or stopping testing the interface request according to the potential fault information.

[0132] In some embodiments, the acquisition module obtains request information of the interface request data, including: sending an interface request to the blockchain interface; determining the target event, the target node of the blockchain and the listening time according to the type of the interface request; accessing the target node and listening to the target event within the listening time; and obtaining the request information of the interface request data according to the listening result.

[0133] Furthermore, the acquisition module obtains interface request data associated with the interface request based on the monitoring results, including: when it is determined based on the monitoring results that the interface request is in the target state, checking the integrity of the transaction data related to the interface request; when it is determined that the transaction data related to the interface request is complete, obtaining the interface request data based on the monitoring results.

[0134] Each module in the aforementioned blockchain interface testing device based on event monitoring and state prediction can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a memory in a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0135] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 5As shown. The computer device includes a processor, memory, an input / output (I / O) interface, and a communication interface. The processor, memory, and I / O interface are connected via a system bus, and the communication interface is connected to the system bus via the I / O interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store interface test data. The I / O interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals via a network connection. When executed by the processor, the computer program implements a blockchain interface testing method based on event monitoring and state prediction.

[0136] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0137] In one embodiment, a computer device is further provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0138] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0139] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0140] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), data processing logic devices based on quantum computing, and the like.

[0141] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0142] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A blockchain interface testing method based on event monitoring and state prediction, characterized in that: The method comprises: Acquiring interface request data, the interface request data including request information of the interface request and network environment parameters when the interface request is sent; Predicting a response time point of an event triggered by the interface request based on the interface request data; At the response time point, calling a pre-built callback function according to the event triggered by the interface request; The test result of the interface request is obtained according to the callback message generated after the callback function is called.

2. The method according to claim 1, characterized in that At the response time point, the pre-built callback function is called according to the event triggered by the interface request, including: Allocating corresponding callback function parameters for event types of events triggered by a plurality of the interface requests to construct the callback function, wherein the callback function is used to check the status of the interface request and / or the response result of the interface request; Constructing a callback function list according to the event type and the callback function; At the response time point, based on the type of the interface request, the callback function in the callback function list is called.

3. The method according to claim 1, characterized in that Obtaining the test result of the interface request according to the callback message generated after the callback function is called, including: Sending the callback message to a message queue; According to the sending time of the callback message, the data in the message queue is parsed in sequence to obtain the execution status information of the interface request; The test result is generated according to the execution status information.

4. The method according to claim 1, wherein Predicting a response time point of an event triggered by the interface request according to the interface request data includes: Obtain training data based on historical interface request data; training a pre-built machine learning model based on the training data; The interface request data is input into the trained machine learning model, and the response time point is output.

5. The method according to claim 4, characterized in that Inputting the interface request data into the trained machine learning model and outputting the response time point further includes: Inputting the interface request data into the trained machine learning model, and outputting the response time point and the first computing resource required to execute the interface request; Pre-allocate second computing resources for executing the interface request based on the first computing resources.

6. The method according to claim 4, characterized in that Inputting the interface request data into the trained machine learning model and outputting the response time point further includes: Inputting the interface request data into the trained machine learning model; When the machine learning model outputs the response time point and potential fault information, restart the faulty node or stop testing the interface request according to the potential fault information.

7. The method according to claim 1, characterized in that Obtaining the request information for the interface request data includes: Sending the interface request to the blockchain interface; Determine the target event, target node of the blockchain, and monitoring time according to the type of the interface request; Accessing the target node and monitoring the target event within the monitoring time; According to the monitoring result, request information for requesting data from the interface is obtained.

8. The method according to claim 7, characterized in that Obtaining the interface request data associated with the interface request according to the monitoring result, including: If it is determined according to the monitoring result that the interface request is in the target state, checking the integrity of the transaction data related to the interface request; When it is determined that the transaction data related to the interface request is complete, the interface request data is obtained according to the monitoring result.

9. A blockchain interface testing device based on event monitoring and state prediction, characterized in that: The device comprises: A collection module, configured to obtain interface request data, wherein the interface request data includes the type of the interface request, request parameters of the interface request, and network environment parameters when the interface request is sent; A prediction module, configured to predict a response time point of an event associated with the interface request based on the interface request data; A calling module, configured to call a pre-built callback function at the response time point according to an event triggered by the interface request; The parsing module is used to obtain the test result of the interface request according to the response data generated after the callback function is called.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 8 are implemented.

Images