Task execution testing method and device, equipment, medium and product

Abstract

The invention discloses a task execution testing method and device, equipment, a medium and a product. The method can be applied to financial science. The method comprises the steps of obtaining a to-be-tested program execution task, performing task analysis on the to-be-tested program execution task, and determining a task execution resource demand, task execution environment dependency and a task scheduling strategy; sending a detection instruction to each actuator node to obtain an instruction response result, and determining candidate actuator nodes according to the instruction response result; obtaining data of candidate actuator nodes, and determining a target actuator node based on task execution environment dependence, task execution resource requirements and a task scheduling strategy of task execution of the to-be-tested program; calling the target actuator node to perform task execution on the to-be-tested program execution task to obtain a task execution result fed back by the target actuator node; and according to the task execution result and a task expected result corresponding to the to-be-tested program execution task, generating a task test result of the to-be-tested program execution task.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and in particular to a task execution testing method, apparatus, equipment, medium, and product. Background Technology

[0002] In the context of online financial services within the fintech sector, the task testing process of the program under test is a crucial step in verifying program quality, and its effectiveness determines the operational efficiency and security of online financial services. As online financial service scenarios become increasingly complex, the programs under test exhibit characteristics such as diverse task types and complex environmental dependencies.

[0003] Existing testing processes suffer from inaccurate task parsing, insufficient node matching, and inadequate result verification. They easily overlook resource requirements and environmental dependencies, leading to task failures when tests are executed directly. Furthermore, traditional executor node selection methods lack multi-dimensional state assessment, making it difficult to match the personalized execution needs of tasks. They also lack a mechanism for predicting node operational risks, and test results are only compared in a simple manner, lacking anomaly analysis, resulting in insufficient reference value. Ultimately, this makes it difficult for the testing process to meet the high-quality and high-security operational requirements of online financial services. Summary of the Invention

[0004] This invention provides a task execution testing method, apparatus, equipment, medium, and product to optimize the testing process of the program under test in the financial technology field, thereby ensuring the execution efficiency and stability of the program under test.

[0005] According to one aspect of the present invention, a task execution testing method is provided, the method comprising:

[0006] Obtain the execution task of the program to be tested, and perform task parsing on the execution task of the program to be tested to determine the task execution resource requirements, task execution environment dependencies and task scheduling strategy;

[0007] A probe command is sent to each actuator node, and each actuator node responds to the probe command based on the command response result. Candidate actuator nodes are then determined based on the command response result.

[0008] Obtain the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and determine the target executor node based on the task execution environment dependency, task execution resource requirements, and task scheduling strategy of the program under test, according to the node performance data, executable status data, and runtime environment data of the candidate executor nodes.

[0009] The target executor node is invoked to execute the task of the program under test, and the task execution result is obtained from the target executor node.

[0010] Based on the task execution results and the expected results of the task executed by the program under test, the task test results of the program under test are generated.

[0011] According to another aspect of the present invention, a task execution testing apparatus is provided, the apparatus comprising:

[0012] The task acquisition and parsing module is used to acquire the task to be executed by the program under test, and to parse the task to determine the task execution resource requirements, task execution environment dependencies and task scheduling strategy.

[0013] The candidate executor node determination module is used to send a probe command to each executor node, so that each executor node can determine the candidate executor node based on the command response result fed back by the probe command;

[0014] The target executor node determination module is used to acquire the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and determine the target executor node based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and based on the task execution environment dependency, task execution resource requirements, and task scheduling strategy of the program to be tested.

[0015] The task execution module is used to call the target executor node to perform task execution on the program under test and obtain the task execution result fed back by the target executor node;

[0016] The task test result generation module is used to generate the task test result of the program under test performing the task based on the task execution result and the expected result of the task corresponding to the program under test performing the task.

[0017] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0018] At least one processor; and

[0019] A memory that is communicatively connected to at least one processor; wherein,

[0020] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform a task execution test method according to any embodiment of the present invention.

[0021] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute a task execution test method according to any embodiment of the present invention.

[0022] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements a task execution testing method according to any embodiment of the present invention.

[0023] The technical solution of this invention obtains the execution task of the program under test, parses the task to determine the task execution resource requirements, task execution environment dependencies, and task scheduling strategy, sends probe commands to each executor node, and provides the command response results from each executor node based on the command response results. Based on the command response results, candidate executor nodes are determined, and their node performance data, executable status data, and runtime environment data are obtained. Based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and considering the task execution environment dependencies, task execution resource requirements, and task scheduling strategy of the program under test, a target executor node is determined. The target executor node is invoked to execute the task of the program under test, and the task execution result fed back by the target executor node is obtained. Based on the task execution result and the expected result corresponding to the task of the program under test, a task test result for the program under test is generated. The above technical solutions can improve the testing quality and efficiency of the program under test. On the one hand, they can avoid test interruptions or result distortion caused by resource mismatch or environmental incompatibility, allowing the test results to truly reflect the actual running status of the program under test. On the other hand, by reasonably matching executor nodes, invalid test attempts can be reduced, saving testing time and resource costs. At the same time, potential risks in program operation can be identified in advance, reducing the probability of failure after the program under test is actually applied, reducing the workload of subsequent maintenance and correction, and better meeting the high security and high stability requirements of online financial business in the financial technology field.

[0024] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart of a task execution testing method provided in Embodiment 1 of the present invention;

[0027] Figure 2 This is a flowchart of a task execution testing method provided in Embodiment 2 of the present invention;

[0028] Figure 3 This is a flowchart of a task execution testing method provided in Embodiment 3 of the present invention;

[0029] Figure 4 This is a schematic diagram of the structure of a task execution testing device according to Embodiment 4 of the present invention;

[0030] Figure 5 This is a schematic diagram of the structure of an electronic device that implements a task execution testing method according to an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] Example 1

[0034] Figure 1 This is a flowchart of a task execution testing method provided in Embodiment 1 of the present invention. This embodiment is applicable to application scenarios in the financial technology field for conducting full-process testing of the execution tasks of the program under test. The method can be executed by a task execution testing device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0035] S101. Obtain the execution task of the program to be tested, and perform task parsing to determine the task execution resource requirements, task execution environment dependencies and task scheduling strategy.

[0036] S102. Send probe commands to each actuator node so that each actuator node can respond to the command based on the probe command and determine the candidate actuator node based on the command response results.

[0037] S103. Obtain the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and determine the target executor node based on the task execution environment dependency, task execution resource requirements, and task scheduling strategy of the program under test.

[0038] S104. Call the target executor node to execute the task of the program to be tested, and obtain the task execution result fed back by the target executor node.

[0039] S105. Based on the task execution results and the expected results of the task corresponding to the task executed by the program under test, generate the task test results of the task executed by the program under test.

[0040] The task to be executed by the test program can be a bank customer information processing task triggered by modifications to the codebase. The codebase can be the program code space storing the bank customer information task. Task execution resource requirements can be the resources needed to support the test program. For example, a CPU (Central Processing Unit) of at least 4 cores and memory capacity greater than 6GB (gigabytes). Task execution environment dependencies can be the task environment required for the test program to execute the task, such as an operating system based on the bank's standard deployment environment and a standard database version. The task scheduling strategy can be a strategy for executing the test program tasks pre-set by relevant technical personnel based on the characteristics of banking business, such as a fault-tolerance priority strategy and a load balancing strategy.

[0041] For example, a code repository modification acquisition device automatically detects customer information applications in the code repository according to a parameterized period, obtains a list of modified programs and modification dates corresponding to the execution tasks of the program under test in the current time period, reads this list, and simultaneously parses the task execution resource requirements, task execution environment dependencies, and task scheduling strategies required by the program under test to complete the task parsing. The code repository modification acquisition device can be an automated component with automatic code repository detection and modification information collection capabilities.

[0042] The executor node can be a task execution unit capable of processing bank customer information, pre-stores a specified customer number processing range, and can respond to probe commands and undertake test tasks. The probe command can be a status verification command sent to each executor node to verify node availability, readiness status, and basic compatibility. The command response result can be the feedback data returned by the executor node after receiving the probe command, including key information such as node online status, readiness result, health status, and circuit breaker status. Candidate executor nodes are those that pass the probe command verification and meet the basic conditions for executing the test task.

[0043] For example, the batch controller sends probe commands to all actuator nodes. Each actuator node, upon receiving the command, checks its own startup status and readiness. If normal, it returns a successful preparation response; if it has not started, is faulty, or times out without feedback, it is considered a preparation failure. The batch controller collects all command response results, records the sequence numbers of failed and successful executors, and identifies the executor nodes that returned a successful preparation response as candidate executor nodes. The batch controller can be a control component responsible for actuator node detection, task scheduling, and status management.

[0044] Among them, node performance data can be a quantitative indicator reflecting the processing power and operational stability of the executor node. Executable status data provides information on the feasibility of the executor node's current tasks, including the number of currently running tasks, whether it is in maintenance mode, the node's continuous runtime, and available CPU and memory resources. Operating environment data includes the executor node's configuration details, such as operating system version, runtime environment, and database driver version. The target executor node is the one selected from the candidate executor nodes that perfectly matches the task execution resource requirements, environmental dependencies, and conforms to the task scheduling strategy.

[0045] For example, the executor allocator first obtains the node performance data, executable status data, and runtime environment data of each node from the candidate executor nodes in batches. Then, according to the selection rules pre-set by relevant technical personnel, it determines the target executor node based on the task execution environment dependency, task execution resource requirements, and task scheduling strategy of the program to be tested. The executor allocator can be a functional component responsible for executor node screening, evaluation, and task allocation.

[0046] Furthermore, to improve the accuracy and adaptability of target executor node selection and ensure the smooth execution of the test program, in one optional embodiment, the target executor node is determined based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and according to the task execution environment dependency, task execution resource requirements, and task scheduling strategy of the test program, including:

[0047] Step a1: Based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and the task execution environment dependency of the program to be tested, determine the reference executor node.

[0048] Step a2: Based on the node performance data and node parameter data of the reference executor node, determine the node performance score of the reference executor node according to the task execution resource requirements of the program under test.

[0049] Step a3: Based on the node performance score of the reference executor node and the task scheduling strategy of the program to be tested, determine the target executor node.

[0050] The reference executor node can be an executor node selected from the candidate executor nodes that meets the basic requirements such as the task execution environment dependency of the program to be tested.

[0051] For example, if the candidate executor nodes are executor node 2, executor node 3, and executor node 4, and the task execution environment of the program under test depends on the bank standard system with operating system version A and database driver version B, and requires at least 4 CPU cores, then according to the screening rules pre-set by relevant technical personnel, candidate executor nodes with corresponding operating environment data of bank standard system with operating system version A and database driver version B, and executable status data of CPU greater than or equal to 4 cores are selected from the candidate executor nodes. For example, executor node 2: bank standard system with operating system version A and database driver version B, with 6 available CPU cores; executor node 3: bank standard system with operating system version C and database driver version B, with 6 available CPU cores; executor node 4: bank standard system with operating system version A and database driver version B, with 8 available CPU cores. Executor node 2 and executor node 4 both meet the screening rules, then executor node 2 and executor node 4 are reference executor nodes.

[0052] Furthermore, to ensure the compatibility of the reference executor node with the task environment dependency and improve the accuracy of the reference executor node determination, in an optional embodiment, the reference executor node is determined based on the node performance data, executable state data, and runtime environment data of the candidate executor nodes, and the task execution environment dependency of the program under test, including:

[0053] Step b1: Determine the health score of the candidate executor node based on the node performance data of the candidate executor node, and determine the first executor node based on the health score of the candidate executor node and a preset health score threshold.

[0054] Step b2: Based on the executable status data of the first executor node and the preset execution status judgment conditions, determine the second executor node.

[0055] Step b3: Determine the reference executor node based on the runtime environment data of the second executor node and the task execution environment dependencies of the program to be tested.

[0056] The health score is a real-time quantitative indicator output by the health profile model, reflecting the hardware stability and historical operating status of the nodes. The health score threshold can be a score preset by relevant technical personnel according to actual needs. The first executor node can be a node among the candidate executor nodes whose health score is greater than the preset health score threshold.

[0057] For example, the node performance data of candidate executor nodes are input into a pre-trained health profile model to obtain a health score output by the model. The health score is then compared with a preset health score threshold. If the health score is greater than the threshold, the corresponding candidate executor node is selected as the first executor node. For instance, if the health score of candidate executor node A is 50 and the health score of candidate executor node B is 80, and the preset threshold is 70, then candidate executor B is selected as the first executor node because its health score is greater than the threshold.

[0058] Furthermore, to provide a more detailed description of the health profile model, in an optional embodiment, the training process of the health profile model is as follows: Obtain executor node operation data over historical time periods, including node performance data, executable status data, and historical task execution data. Use the preprocessed historical operation data as sample data and generate a label set for the sample data containing health scores from 0 to 100. These labels can be annotated by relevant technical personnel according to actual needs. Input the sample data and its corresponding label set into a preset regression neural network model. Extract health-related features from the historical executor node operation data through the model's feature extraction layer. Map these features through a fully connected layer to obtain the predicted health score output by the model. Calculate the model loss value based on the actual health score of the sample data and the predicted health score output by the model. Iteratively update the network parameters of the neural network model based on the loss value until a preset model training termination condition is met, thus obtaining the pre-trained health profile model.

[0059] The model training termination condition can be preset by relevant technical personnel. For example, the termination condition could be that the number of model training iterations reaches a set iteration threshold, or that the change in the model loss value for consecutive preset rounds is less than a set magnitude threshold. This embodiment does not impose any restrictions on this. After training is completed, the health profile model can receive real-time running data from the executor nodes and output the corresponding health score.

[0060] The execution status judgment conditions can be circuit breaker status check rules and resource requirement matching rules pre-set by relevant technical personnel according to actual needs. The circuit breaker status check rules are used to determine the circuit breaker status of the current executor node, and the resource requirement matching rules are used to determine the load status of the current executor node. The circuit breaker status refers to the state of the executor node; if the executor node is in a circuit breaker state, it means that the current executor node can no longer process the test program task. The load status can be determined by whether the CPU of the current executor node meets the CPU requirements of the test program task and whether the memory of the current executor node meets the memory requirements of the test program task. The second executor node can be the first executor node that meets the preset execution status judgment conditions.

[0061] For example, the executable status data of the first executor node 1 and the first executor node 2 are obtained: First executor node 1: Circuit breaker closed, 6 available CPU cores, 8GB available memory; First executor node 2: Circuit breaker closed, 5 available CPU cores, 7GB available memory. The preset execution status judgment condition is that the circuit breaker of the executor node is closed and the executor node should meet the minimum requirements for the test program to execute the task. The minimum CPU requirement for the test program to execute the task is 4 cores and the minimum memory requirement is 6GB. According to the execution status judgment condition, both meet the resource matching and circuit breaker requirements. Therefore, the first executor node 1 and the first executor node 2 are both determined to be the second executor node.

[0062] For example, the runtime environment data of the second executor node 4 is obtained: operating system CentOS (Community Enterprise Operating System) 7.9, JDK (Java Development Kit) 1.8, and available memory of 5GB. The runtime environment data of the second executor node 5 is: operating system CentOS 7.9, JDK 1.7, and available memory of 6GB. The task execution environment dependencies of the program under test are: operating system CentOS 7.9, JDK 1.8, and required memory of 4GB. According to the verification rules, it is confirmed that the operating system, runtime version, and memory load all meet the task execution environment dependencies of the program under test. Finally, the second executor node 4 is determined as the reference executor node.

[0063] The above solution first determines the health score based on the node performance data of candidate executor nodes, then filters out nodes whose health scores reach a preset threshold. Next, it verifies the executable status of nodes based on preset execution status judgment conditions, retaining nodes that meet the execution requirements. Finally, it matches the node's runtime environment data with the task execution environment dependency of the program under test to determine the complete process of the reference executor node. This effectively eliminates nodes with high health risks, abnormal status, or incompatible environments, improving the reliability and adaptability of the reference executor node. In turn, it ensures the stable execution of batch testing tasks for bank customer information and improves the success rate and execution efficiency of automated testing.

[0064] The node parameter data can include the basic configuration and historical operation records of the reference executor node. The node performance score can be a quantitative score calculated based on the health status, load, location fault tolerance, resource matching degree, and historical execution performance of the reference executor node, combined with dynamic weights.

[0065] For example, the performance score of a node can be manually assigned by relevant technical personnel based on the node parameter data of the actuator node.

[0066] Furthermore, to clarify how to determine the node performance score of the reference executor node to improve the scheduling accuracy of batch testing tasks for bank customer information, in an optional embodiment, the node performance score of the reference executor node is determined based on the node performance data and node parameter data of the reference executor node, according to the task execution resource requirements of the program under test, including:

[0067] Step c1: Determine the health score of the reference actuator node based on the node performance data of the reference actuator node.

[0068] Step c2: Determine the load balance score of the reference executor node based on the CPU load and memory load in the node performance data of the reference executor node.

[0069] Step c3: Determine the position tolerance score of the reference actuator node based on the position tolerance parameter in the node parameter data of the reference actuator node.

[0070] Step c4: Based on the node performance data of the reference executor node, determine the resource matching degree based on the task execution resource requirements of the program under test.

[0071] Step c5: Determine the failure rate score of the reference executor node based on the historical task execution failure rate in the node parameter data of the reference executor node.

[0072] Step c6: Determine the node performance score of the reference executor node based on its health score, load balancing score, location tolerance score, resource matching score, and failure rate score.

[0073] For example, inputting the node performance data of the reference actuator node into a pre-trained health profile model can yield the health score of the reference actuator node output by the model.

[0074] The CPU load can be calculated as the real-time utilization of the reference executor node's CPU, i.e., the current CPU load divided by the total capacity. For example, if the current reference executor node has 8GB of CPU and the load is 4GB, then the CPU load is 4 / 8 × 100% = 50%. The memory load can be calculated as the real-time utilization of the reference executor node's memory, i.e., the currently used memory divided by the total memory capacity. For example, if the current reference executor node has 8GB of memory and the load is 8GB, then the memory load is 8 / 8 × 100% = 100%. The load balance score can be a quantitative indicator calculated based on CPU load and memory load.

[0075] For example, the load balancing score can be calculated using a formula pre-set by relevant technical personnel. Load balancing score = CPU load × CPU load weight + Memory load × Memory load weight. The CPU load weight and memory load weight can be pre-set by relevant technical personnel according to actual needs. For example, load balancing score = 1 - (0.6 × CPU load + 0.4 × Memory load).

[0076] The location tolerance parameter can be the physical location topology information of the reference actuator node, including its region, availability zone, and other related data. The location tolerance score measures how well a task avoids cascading failures when migrating due to node failure; non-migrating tasks receive a score of 1 by default.

[0077] For example, if the task to be tested is a non-fault migration task, the location tolerance score of the reference actuator node is 1.0 by default. If the task to be tested is a fault migration task, the location tolerance parameter of the reference actuator node needs to be assigned a different value by relevant technical personnel. For example, if the reference actuator node and the original fault node belong to different availability zones, its location tolerance score is assigned to 0.8. If the reference actuator node and the original fault node are in different racks in the same zone, its location tolerance score is assigned to 0.6.

[0078] Among them, resource matching degree can be defined as the degree to which the available resources of the reference executor node match the resource requirements of task execution.

[0079] For example, resource matching degree can be divided into CPU matching degree, memory matching degree, etc. The calculation method of resource matching degree can be obtained by multiplying the corresponding matching degree with the weights preset by relevant technical personnel. For example, resource matching degree = CPU matching degree × CPU matching degree weight + memory matching degree × memory matching degree weight.

[0080] The historical task execution failure rate represents the percentage of times a reference executor node fails to execute a test task within a pre-defined time period. The failure rate score is a quantitative indicator calculated by relevant technical personnel based on the historical task execution failure rate using a pre-defined formula. For example, the resource requirements for the program under test are: more than 4 CPU cores and more than 8GB of memory. The available resources of the reference executor node are: 3 CPU cores and 6GB of memory. CPU matching degree = 3 cores ÷ 4 cores = 0.75, memory matching degree = 6GB ÷ 8GB = 0.75. With a preset CPU weight of 0.6 and a memory weight of 0.4, the resource matching degree = 0.75 × 0.6 + 0.75 × 0.4 = 0.75.

[0081] For example, the failure rate score can be calculated using the formula 1 - min(1.0, 2 × historical task execution failure rate). For instance, if the historical task execution failure rate of reference executor node 2 is 0%, the failure rate score = 1 - min(1, 2 × 0) = 1.0. Additionally, if the current reference executor node has no historical tasks, the failure rate score can take a default value pre-set by relevant technical personnel.

[0082] For example, the node performance score can be calculated by weighted summation based on five indicators: health score, load balancing score, location tolerance score, resource matching score, and failure rate score of the reference executor node. These indicators are configured by relevant technical personnel according to actual needs and the business scenario weights of the task under test. The node performance score is calculated as follows: Node Performance Score = Health Score × Health Weight + Load Balancing Score × Load Weight + Location Tolerance Score × Tolerance Weight + Resource Matching Score × Resource Weight + Failure Rate Score × Failure Rate Weight. For example, if the scores of the reference executor node are as follows: Health Score 0.9, Load Balancing Score 0.78, Location Tolerance Score 0.8, Resource Matching Score 1.0, and Failure Rate Score 1.0, then the node performance score is calculated as follows: Node Performance Score = 0.9 × 0.3 + 0.78 × 0.2 + 0.8 × 0.1 + 1.0 × 0.2 + 1.0 × 0.2 = 0.27 + 0.156 + 0.08 + 0.2 + 0.2 = 0.906.

[0083] The above solution achieves a comprehensive quantitative evaluation of the reference executor node through five dimensions: health score, load balancing score, location fault tolerance score, resource matching score, and failure rate score. This avoids decision-making bias caused by single-dimensional screening. At the same time, the node performance score is calculated according to a scientific formula to ensure that the score results are consistent with the actual needs of the batch testing task of bank customer information, improve the scientificity and rationality of task scheduling, and further ensure the stability and efficiency of batch testing of bank customer information.

[0084] The target executor node can be the optimal execution node selected based on the node performance score of the reference executor node.

[0085] For example, the reference executor node with the highest node performance score can be selected as the target executor node. For instance, if reference executor node 1 has a node performance score of 0.895 and node 2 has a score of 0.8325, then reference executor node 1 can be selected as the target executor node.

[0086] The above technical solution determines reference executor nodes based on the node performance data, executable status data, and runtime environment data of candidate executor nodes, combined with the task execution environment dependencies of the program under test. Then, it determines the node performance score based on the node performance data and node parameter data of the reference executor nodes, combined with the task execution resource requirements. Finally, it selects the target executor node based on the node performance score and task scheduling strategy. This ensures the environmental and resource compatibility between the executor nodes and the tasks, and accurately matches the optimal executor node according to scheduling requirements. This avoids the problem of blindly allocating tasks, improves the resource utilization efficiency of the executor cluster, ensures the automated and accurate execution of batch testing tasks for bank customer information, and improves the success rate of program task testing.

[0087] Furthermore, to clarify the selection logic of the target executor node and improve the scheduling adaptability and execution stability of the batch testing task of bank customer information, in an optional embodiment, the target executor node is determined based on the node performance score of the reference executor node and the task scheduling strategy of the program under test, including:

[0088] Step d1: If the task scheduling strategy of the program to be tested is a scheduling optimization strategy, then the reference executor node with the highest node performance score is determined as the target executor node.

[0089] Step d2: If the task scheduling strategy of the program to be tested is a load balancing strategy, then select the first current executor node according to the node performance score of the reference executor node, and determine the target executor node according to the load balancing score corresponding to the first current executor node.

[0090] Step d3: If the task scheduling strategy of the program to be tested is a high availability strategy, then select the second current executor node according to the node performance score of the reference executor node, and determine the target executor node according to the health score corresponding to the second current executor node.

[0091] Among them, the scheduling optimization strategy can be a scheduling rule with the optimal comprehensive adaptability of nodes as the core.

[0092] For example, if the task scheduling strategy for the program to be tested is a scheduling optimization strategy, and the node performance scores of reference executor nodes 1, 2, and 3 are 0.92, 0.85, and 0.78 respectively, then node 1 with the highest score is directly selected as the target executor node according to the scheduling optimization strategy.

[0093] Among them, the load balancing strategy can be a scheduling rule with the uniform distribution of cluster resources as its core.

[0094] For example, if the task scheduling strategy for the program under test is a load balancing strategy, the reference executor nodes can be sorted according to their node performance scores. The reference executor node with the highest node performance score is selected as the first current executor node. Among the first current executor nodes, the node with the lowest load balancing score can be selected as the target executor node. For instance, if the node performance scores of reference executor nodes 1, 2, 3, and 4 are 0.71, 0.92, 0.91, and 0.82, respectively, and their load balancing scores are 0.98, 0.82, 0.91, and 0.92, respectively, the top three reference executor nodes with the highest node performance scores can be selected as the first current executor nodes, i.e., reference executor nodes 2, 3, and 4 are the first current executor nodes. Among the first current executor nodes, the node with the lowest load balancing score can be selected as the target executor node, i.e., reference executor node 2 is the target executor node.

[0095] Among them, the high availability strategy can be a scheduling rule with the lowest possible risk of failure as its core.

[0096] For example, if the task scheduling strategy for the program under test is a high-availability strategy, the reference executor nodes can be sorted according to their node performance scores. The reference executor node with the higher node performance score is selected as the second current executor node. Among the second current executor nodes, the node with the highest health score can be selected as the target executor node. For instance, if the node performance scores of reference executor nodes 1, 2, and 3 are 0.81, 0.92, and 0.96 respectively, and their health scores are 85, 88, and 90 respectively, the two reference executor nodes with the highest node performance scores can be selected as the second current executor nodes, i.e., reference executor nodes 2 and 3 are the second current executor nodes. Among the second current executor nodes, the node with the highest health score can be selected as the target executor node, i.e., reference executor node 3 is the target executor node.

[0097] The aforementioned solution provides three strategies—scheduling optimization, load balancing, and high availability—to address the scheduling needs of different business scenarios. These strategies achieve precise matching of target executor nodes, with scheduling optimization ensuring optimal task execution efficiency, load balancing allocating cluster resources rationally, and high availability mitigating the risk of failures and outages. Furthermore, preliminary screening based on node performance scoring and secondary verification of the task scheduling strategy ensures the basic adaptability of executor nodes, improves task execution success rate and cluster operational stability, and provides support for the efficient advancement of automated testing in the banking sector.

[0098] The task execution result can be the test result after the executor node executes the task requirements of the program to be tested.

[0099] The expected task result can be the actual result after the executor node executes the task requirements according to the program under test, corresponding to the confirmed real business data in the database. The task test result can be the result obtained by comparing the task execution result with the expected task result, such as test success or test failure.

[0100] For example, the task test result can be obtained by determining whether the task execution result is equal to the expected result. For instance, if the task execution result of the program under test is to change the validity period of customer A's certificate to three months, while the expected result is that customer A's certificate is valid for five months, then the task execution result does not match the expected result, and the task test result is a test failure.

[0101] The technical solution of this invention obtains the execution task of the program under test, parses the task to determine the task execution resource requirements, task execution environment dependencies, and task scheduling strategy, sends probe commands to each executor node, and provides the command response results from each executor node based on the command response results. Based on the command response results, candidate executor nodes are determined, and their node performance data, executable status data, and runtime environment data are obtained. Based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and considering the task execution environment dependencies, task execution resource requirements, and task scheduling strategy of the program under test, a target executor node is determined. The target executor node is invoked to execute the task of the program under test, and the task execution result fed back by the target executor node is obtained. Based on the task execution result and the expected result corresponding to the task of the program under test, a task test result for the program under test is generated. The above technical solutions can improve the testing quality and efficiency of the program under test. On the one hand, they can avoid test interruptions or result distortion caused by resource mismatch or environmental incompatibility, allowing the test results to truly reflect the actual running status of the program under test. On the other hand, by reasonably matching executor nodes, invalid test attempts can be reduced, saving testing time and resource costs. At the same time, potential risks in program operation can be identified in advance, reducing the probability of failure after the program under test is actually applied, reducing the workload of subsequent maintenance and correction, and better meeting the high security and high stability requirements of online financial business in the financial technology field.

[0102] Example 2

[0103] Figure 2 This is a flowchart of a task execution testing method provided in Embodiment 2 of the present invention. This embodiment optimizes and improves upon the above-mentioned technical solutions. The step "generating a task test result for the program under test based on the task execution result and the expected task result corresponding to the task executed by the program under test" is refined to "compare the result consistency between the task execution result and the expected task result corresponding to the task executed by the program under test, and obtain a consistency comparison result. If the consistency comparison result is consistent, the task test result for the program under test is considered successful. If the consistency comparison result is inconsistent, a difference field is generated between the task execution result and the expected task result, the task test result is determined to be a failure, and the difference field is used as an additional result of the task test result." This improves the process for determining the task test result.

[0104] It should be noted that for parts not described in detail in the embodiments of the present invention, please refer to the descriptions in other embodiments. For example... Figure 2 As shown, the method includes the following specific steps:

[0105] S201. Obtain the execution task of the program to be tested, and perform task parsing to determine the task execution resource requirements, task execution environment dependencies and task scheduling strategy.

[0106] S202. Send probe commands to each actuator node so that each actuator node can respond to the command based on the probe command and determine the candidate actuator node based on the command response results.

[0107] S203. Obtain the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and determine the target executor node based on the task execution environment dependency, task execution resource requirements, and task scheduling strategy of the program under test.

[0108] S204. Call the target executor node to execute the task of the program to be tested, and obtain the task execution result fed back by the target executor node.

[0109] S205. Compare the result of the task execution with the expected result of the task corresponding to the execution of the task by the program under test to obtain the consistency comparison result.

[0110] S206. If the consistency comparison result is consistent, then execute S207; if the consistency comparison result is inconsistent, then execute S208.

[0111] S207. The test result of the task executed by the program to be tested is successful.

[0112] S208. Generate a difference field between the task execution result and the expected task result, determine the task test result as a test failure, and use the difference field as an additional result of the task test result.

[0113] Among them, the consistency comparison result can be the result obtained by comparing the task execution result with the expected result of the task execution result of the program under test.

[0114] For example, the task executed by the program under test is a batch modification task of customer certificate validity periods. The task objective is to uniformly extend the certificate validity periods of customer numbers 001-200 to 2030-12-31. The expected result is the actual modified data of this batch of customers in the system, i.e., a list of customer information whose certificate validity periods have been updated to 2030-12-31. The task execution result is the actual list of certificate validity periods of customer numbers 001-200 collected after the target executor node completes the modification operation. Following the rules of unique matching of customer numbers and precise comparison of the certificate validity period field, the two lists are verified for each customer. The final result is 198 data entries with a validity period of 2030-12-31, and 2 data entries with the original validity period of 2025-12-31. Therefore, the consistency comparison result is inconsistent.

[0115] For example, if the consistency comparison result of the task execution of the program under test is consistent, it means that the test is successful. The relevant data of the target executor node can be synchronized to the health profile model for iteration and task scheduling strategy optimization.

[0116] The difference fields can be specific data fields whose values ​​do not match the expected results of the task. Additional results can be a combination of the difference field set and anomaly information, such as the difference field type, preset comparison rules, and possible causes of the anomaly.

[0117] For example, if the consistency comparison result of the task executed by the program under test is inconsistent, firstly extract the difference field: the certificate validity period field of customer number 015: execution result value 2025-12-31, expected result value 2030-12-31. Then, the difference field is compared with the field type: date, the comparison rule: exact match, the possible reasons for the exception: the customer certificate status is frozen or the node modification permission is insufficient, to form additional results. Finally, the task test result of the program under test is determined to be a test failure, and a complete test report containing the task ID, failure identifier, difference field details, and additional results is output.

[0118] This invention ensures consistency between task execution results and standard expectations by comparing fields, avoiding test misjudgments caused by data deviations and meeting the accuracy requirements of bank customer information processing. It simplifies the result output process for successful scenarios, quickly generating standardized reports and improving testing efficiency. For failed scenarios, it accurately extracts discrepancies and supplements auxiliary troubleshooting information, significantly reducing the cost of problem localization for technical personnel and shortening fault repair time. The entire process achieves automated judgment of test results and accurate traceability of anomalies, solving the problem of low efficiency in traditional manual verification and ensuring the accuracy and traceability of batch testing of bank customer information, further improving the automation success rate of testing tasks and the efficiency of problem handling.

[0119] Example 3

[0120] Figure 3 This is a flowchart of a task execution testing method provided in Embodiment 3 of the present invention. Based on the above embodiments, this embodiment provides a preferred example.

[0121] S301. Obtain the execution task of the program to be tested, and perform task parsing on the execution task of the program to be tested to determine the task execution resource requirements, task execution environment dependencies and task scheduling strategy.

[0122] S302. Send probe commands to each actuator node so that each actuator node can respond to the command based on the probe command and determine the candidate actuator node based on the command response results.

[0123] S303. Obtain the node performance data, executable status data, and operating environment data of the candidate executor nodes, and determine the health score of the candidate executor nodes based on the node performance data of the candidate executor nodes. Based on the health score of the candidate executor nodes and a preset health score threshold, determine the first executor node.

[0124] S304. Based on the executable status data of the first executor node and the preset execution status judgment conditions, determine the second executor node. Based on the runtime environment data of the second executor node and the task execution environment dependency of the program to be tested, determine the reference executor node.

[0125] S305. Determine the health score of the reference actuator node based on the node performance data of the reference actuator node.

[0126] S306. Determine the load balance score of the reference actuator node based on the CPU load and memory load in the node performance data of the reference actuator node.

[0127] S307. Determine the position tolerance score of the reference actuator node based on the position tolerance parameter in the node parameter data of the reference actuator node.

[0128] S308. Based on the node performance data of the reference executor node, determine the resource matching degree based on the task execution resource requirements of the program under test.

[0129] S309. Determine the failure rate score of the reference executor node based on the historical task execution failure rate in the node parameter data of the reference executor node.

[0130] S310. Determine the node performance score of the reference executor node based on its health score, load balancing score, location tolerance score, resource matching score, and failure rate score.

[0131] S311. If the task scheduling strategy of the program under test is a scheduling optimization strategy, then execute S312. If the task scheduling strategy of the program under test is a load balancing strategy, then execute S313. If the task scheduling strategy of the program under test is a high availability strategy, then execute S314.

[0132] S312. The reference executor node with the highest node performance score is determined as the target executor node.

[0133] S313. Based on the node performance score of the reference executor node, select the first current executor node, and determine the target executor node based on the load balancing score corresponding to the first current executor node.

[0134] S314. Based on the node performance score of the reference executor node, select the second current executor node, and determine the target executor node based on the health score corresponding to the second current executor node.

[0135] S315. Invoke the target executor node to execute the task of the program under test, and obtain the task execution result returned by the target executor node. Compare the result of the task execution with the expected result of the task corresponding to the task of the program under test, and obtain the consistency comparison result.

[0136] S316. If the consistency comparison result is consistent, then execute S317; if the consistency comparison result is inconsistent, then execute S318.

[0137] S317. The task test result of the program to be tested is successful.

[0138] S318. Generate a difference field between the task execution result and the expected task result, determine the task test result as a test failure, and use the difference field as an additional result of the task test result.

[0139] The information collected in the above embodiments of the present invention is all information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse.

[0140] Example 4

[0141] Figure 4This is a schematic diagram of a task execution testing device provided in Embodiment 4 of the present invention. The task execution testing device provided in this embodiment of the present invention is applicable to testing scenarios in the financial technology field where the program to be tested executes tasks. This task execution testing device can be implemented in hardware and / or software, and can be applied to a task execution testing method. Specifically, it can be configured in a controller, such as... Figure 4 As shown, the device includes: a task acquisition and parsing module 401, a candidate executor node determination module 402, a target executor node determination module 403, a task execution module 404, and a task test result generation module 405. Wherein:

[0142] The task acquisition and parsing module 401 is used to acquire the task to be executed by the program under test, and to parse the task to determine the task execution resource requirements, task execution environment dependencies and task scheduling strategy.

[0143] The candidate executor node determination module 402 is used to send probe commands to each executor node, so that each executor node can determine the candidate executor node based on the command response results fed back by the probe commands.

[0144] The target executor node determination module 403 is used to obtain the node performance data, executable status data and runtime environment data of the candidate executor nodes, and determine the target executor node based on the node performance data, executable status data and runtime environment data of the candidate executor nodes, the task execution environment dependency, task execution resource requirements and task scheduling strategy of the program to be tested.

[0145] The task execution module 404 is used to call the target executor node to execute the task of the program under test and obtain the task execution result fed back by the target executor node.

[0146] The task test result generation module 405 is used to generate the task test result of the program under test based on the task execution result and the expected result of the task corresponding to the program under test executing the task.

[0147] The technical solution of this invention obtains the execution task of the program under test, parses the task to determine the task execution resource requirements, task execution environment dependencies, and task scheduling strategy, sends probe commands to each executor node, and provides the command response results from each executor node based on the command response results. Based on the command response results, candidate executor nodes are determined, and their node performance data, executable status data, and runtime environment data are obtained. Based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and considering the task execution environment dependencies, task execution resource requirements, and task scheduling strategy of the program under test, a target executor node is determined. The target executor node is invoked to execute the task of the program under test, and the task execution result fed back by the target executor node is obtained. Based on the task execution result and the expected result corresponding to the task of the program under test, a task test result for the program under test is generated. The above technical solutions can improve the testing quality and efficiency of the program under test. On the one hand, they can avoid test interruptions or result distortion caused by resource mismatch or environmental incompatibility, allowing the test results to truly reflect the actual running status of the program under test. On the other hand, by reasonably matching executor nodes, invalid test attempts can be reduced, saving testing time and resource costs. At the same time, potential risks in program operation can be identified in advance, reducing the probability of failure after the program under test is actually applied, reducing the workload of subsequent maintenance and correction, and better meeting the high security and high stability requirements of online financial business in the financial technology field.

[0148] Optionally, the target executor node determination module 403 includes:

[0149] The reference executor node determination unit determines the reference executor node based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and based on the task execution environment dependency of the program under test.

[0150] The node performance scoring unit determines the node performance score of the reference executor node based on the node performance data and node parameter data of the reference executor node and the task execution resource requirements of the program under test.

[0151] The target executor node determination unit determines the target executor node based on the node performance score of the reference executor node and the task scheduling strategy for the program to be tested.

[0152] Optionally, the reference actuator node determination unit is specifically used for:

[0153] Based on the node performance data of the candidate executor nodes, the health score of the candidate executor nodes is determined. Based on the health score of the candidate executor nodes and a preset health score threshold, the first executor node is determined.

[0154] Based on the executable status data of the first executor node and the preset execution status judgment conditions, the second executor node is determined.

[0155] The reference executor node is determined based on the runtime environment data of the second executor node and the task execution environment dependencies of the program under test.

[0156] Optionally, a node performance scoring and determination unit is used specifically for:

[0157] The health score of the reference actuator node is determined based on the node performance data of the reference actuator node.

[0158] The load balance score of the reference executor node is determined based on the CPU load and memory load in the node performance data of the reference executor node.

[0159] The position tolerance score of the reference actuator node is determined based on the position tolerance parameter in the node parameter data of the reference actuator node.

[0160] Based on the node performance data of the reference executor node, the resource matching degree is determined according to the task execution resource requirements of the program under test.

[0161] The failure rate score of the reference executor node is determined based on the historical task execution failure rate in the node parameter data of the reference executor node.

[0162] The node performance score of the reference executor node is determined based on its health score, load balancing score, location tolerance score, resource matching score, and failure rate score.

[0163] Optionally, the target actuator node determination unit is specifically used for:

[0164] If the task scheduling strategy of the program to be tested is a scheduling optimization strategy, then the reference executor node with the highest node performance score is determined as the target executor node.

[0165] If the task scheduling strategy of the program to be tested is a load balancing strategy, then the first current executor node is selected based on the node performance score of the reference executor node, and the target executor node is determined based on the load balancing score corresponding to the first current executor node.

[0166] If the task scheduling strategy of the program to be tested is a high availability strategy, then the second current executor node is selected based on the node performance score of the reference executor node, and the target executor node is determined based on the health score of the second current executor node.

[0167] Optional, the task test result generation module 405 is specifically used for:

[0168] The consistency comparison results are obtained by comparing the task execution results with the expected results of the task corresponding to the task executed by the program under test.

[0169] If the consistency comparison result is consistent, then the test result of the program to be tested is considered successful.

[0170] If the consistency comparison result is inconsistent, a difference field is generated between the task execution result and the expected result of the task, the task test result is determined to be a test failure, and the difference field is used as an additional result of the task test result.

[0171] The task execution testing device provided in this embodiment of the invention can execute a task execution testing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0172] Example 5

[0173] Figure 5 A schematic diagram of an electronic device 50 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0174] like Figure 5As shown, the electronic device 50 includes at least one processor 51 and a memory, such as a read-only memory (ROM) 52 and a random access memory (RAM) 53, communicatively connected to the at least one processor 51. The memory stores computer programs executable by the at least one processor. The processor 51 can perform various appropriate actions and processes based on the computer program stored in the ROM 52 or loaded from storage unit 58 into the RAM 53. The RAM 53 can also store various programs and data required for the operation of the electronic device 50. The processor 51, ROM 52, and RAM 53 are interconnected via a bus 54. An input / output (I / O) interface 55 is also connected to the bus 54.

[0175] Multiple components in electronic device 50 are connected to I / O interface 55, including: input unit 56, such as keyboard, mouse, etc.; output unit 57, such as various types of monitors, speakers, etc.; storage unit 58, such as disk, optical disk, etc.; and communication unit 59, such as network card, modem, wireless transceiver, etc. Communication unit 59 allows electronic device 50 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0176] Processor 51 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 51 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 51 performs the various methods and processes described above, such as a task execution testing method.

[0177] In some embodiments, a task execution testing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 58. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 50 via ROM 52 and / or communication unit 59. When the computer program is loaded into RAM 53 and executed by processor 51, one or more steps of the task execution testing method described above may be performed. Alternatively, in other embodiments, processor 51 may be configured as a task execution testing method by any other suitable means (e.g., by means of firmware).

[0178] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0179] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0180] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0181] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0182] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0183] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0184] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0185] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A task execution testing method, characterized in that, include: Obtain the execution task of the program to be tested, and perform task parsing on the execution task of the program to be tested to determine the task execution resource requirements, task execution environment dependencies and task scheduling strategy; A probe command is sent to each actuator node, and each actuator node responds to the probe command based on the command response result. Candidate actuator nodes are then determined based on the command response result. Obtain the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and determine the target executor node based on the task execution environment dependency, task execution resource requirements, and task scheduling strategy of the program under test, according to the node performance data, executable status data, and runtime environment data of the candidate executor nodes. The target executor node is invoked to execute the task of the program under test, and the task execution result is obtained from the target executor node. Based on the task execution results and the expected results of the task executed by the program under test, the task test results of the program under test are generated.

2. The method according to claim 1, characterized in that, The step of determining the target executor node based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and based on the task execution environment dependencies, task execution resource requirements, and task scheduling strategies of the program under test, includes: Based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and considering the task execution environment dependency of the program under test, a reference executor node is determined. Based on the node performance data and node parameter data of the reference executor node, and the task execution resource requirements of the program under test, the node performance score of the reference executor node is determined. Based on the node performance score of the reference executor node and the task scheduling strategy for the task to be executed by the program under test, the target executor node is determined.

3. The method according to claim 2, characterized in that, The step of determining a reference executor node based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and considering the task execution environment dependency of the program under test, includes: Based on the node performance data of the candidate executor nodes, the health score of the candidate executor nodes is determined. Based on the health score of the candidate executor nodes and a preset health score threshold, the first executor node is determined. Based on the executable status data of the first executor node and the preset execution status judgment conditions, the second executor node is determined; The reference executor node is determined based on the runtime environment data of the second executor node and the task execution environment dependencies of the program under test.

4. The method according to claim 2, characterized in that, The step of determining the node performance score of the reference executor node based on the node performance data and node parameter data of the reference executor node, and based on the task execution resource requirements of the program under test, includes: The health score of the reference actuator node is determined based on the node performance data of the reference actuator node. The load balance score of the reference executor node is determined based on the CPU load and memory load in the node performance data of the reference executor node. The position tolerance score of the reference actuator node is determined based on the position tolerance parameter in the node parameter data of the reference actuator node. Based on the node performance data of the reference executor node, and the task execution resource requirements of the program under test, the resource matching degree is determined. The failure rate score of the reference executor node is determined based on the historical task execution failure rate in the node parameter data of the reference executor node. The node performance score of the reference executor node is determined based on its health score, load balancing score, location tolerance score, resource matching score, and failure rate score.

5. The method according to claim 2, characterized in that, The step of determining the target executor node based on the node performance score of the reference executor node and the task scheduling strategy for the program under test includes: If the task scheduling strategy of the program to be tested is a scheduling optimization strategy, then the reference executor node with the highest node performance score is determined as the target executor node. If the task scheduling strategy of the program to be tested is a load balancing strategy, then the first current executor node is selected according to the node performance score of the reference executor node, and the target executor node is determined according to the load balancing score corresponding to the first current executor node. If the task scheduling strategy of the program under test is a high availability strategy, then the second current executor node is selected based on the node performance score of the reference executor node, and the target executor node is determined based on the health score corresponding to the second current executor node.

6. The method according to claim 1, characterized in that, The step of generating the task test result of the program under test based on the task execution result and the expected task result corresponding to the task execution of the program under test includes: The consistency comparison result is obtained by comparing the task execution result with the expected result of the task corresponding to the task executed by the program under test. If the consistency comparison result is consistent, then the task test result of the program under test is a successful test. If the consistency comparison result is inconsistent, a difference field is generated between the task execution result and the expected result of the task, the task test result is determined to be a test failure, and the difference field is used as an additional result of the task test result.

7. A task execution testing device, characterized in that, include: The task acquisition and parsing module is used to acquire the task to be executed by the program under test, and to parse the task to determine the task execution resource requirements, task execution environment dependencies and task scheduling strategy. The candidate executor node determination module is used to send a probe command to each executor node, so that each executor node can determine the candidate executor node based on the command response result fed back by the probe command; The target executor node determination module is used to acquire the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and determine the target executor node based on the node performance data, executable status data, and runtime environment data of the candidate executor nodes, and based on the task execution environment dependency, task execution resource requirements, and task scheduling strategy of the program to be tested. The task execution module is used to call the target executor node to perform task execution on the program under test and obtain the task execution result fed back by the target executor node; The task test result generation module is used to generate the task test result of the program under test performing the task based on the task execution result and the expected result of the task corresponding to the program under test performing the task.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a task execution test method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute a task execution test method according to any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements a task execution test method according to any one of claims 1-6.

Images