Cross-terminal cross-regional interface test node deployment method and system

Abstract

The application relates to the technical field of software testing, and discloses a cross-terminal and cross-territory interface test node deployment method and system. The method comprises the following steps: based on node state information such as the running platform type, network territory identifier and available resource state of a distributed test node, a dynamically updated schedulable resource pool is constructed and maintained; an interface test task containing a running platform condition, a territory constraint condition and a comparability level parameter is received; if cross-node result comparability is required, a first test node meeting multiple conditions is selected from the resource pool based on an equivalence constraint condition, the equivalence constraint condition guarantees the equivalence of the node in terms of the consistency of test results; a target test node is determined from the first test node and a task is allocated, and a test execution result returned by the target test node is received. The method realizes automatic deployment and dynamic scheduling of test nodes, improves cross-terminal and cross-territory test efficiency and result reliability, and is suitable for a distributed interface test scene.

Description

Technical Field

[0001] This application relates to the field of software testing technology, specifically to a method and system for deploying interface testing nodes across devices and regions. Background Technology

[0002] In the field of software testing technology, interface testing, as a key component in ensuring system stability and availability, is widely used in scenarios such as distributed systems and cross-platform applications. Currently, most mainstream interface testing systems adopt an agent-server architecture, where an agent client is deployed on test nodes to interact with the web platform, completing information acquisition and test result uploading.

[0003] However, existing technologies have significant drawbacks when facing testing needs across multiple regions, platforms, and operating environments. First, test node deployment relies on manual, one-by-one adaptation. Nodes in different regions and operating systems require separate configuration, leading to high deployment complexity and demanding expertise from operators, resulting in increased communication costs and low testing efficiency. Second, the relationship between test nodes and the platform is static and fixed, unable to be dynamically adjusted based on real-time network conditions and node load, resulting in low resource utilization. Third, the test environment is tightly coupled with the nodes; when the same interface is executed on different nodes, environmental consistency is difficult to guarantee, leading to discrepancies in test results.

[0004] In particular, in cross-regional testing scenarios, differences in network topology, routing quality, and historical node load can introduce systematic biases. Existing scheduling schemes only focus on whether nodes are "available" and do not constrain and manage the "equivalence" of nodes that affect the consistency of test results. This makes it impossible for testers to distinguish whether the difference in results stems from the interface itself or the node environment, which seriously affects the reliability of tests in scenarios such as cross-regional regression testing and cross-regional performance baseline verification. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for deploying interface test nodes across devices and regions, so as to solve the problems mentioned in the background art.

[0006] According to one aspect of this application, a method for deploying interface test nodes across platforms and regions is provided, comprising the following steps:

[0007] Based on the node status information of multiple distributed test nodes, a dynamically updated schedulable resource pool is constructed and maintained. The node status information includes at least the running platform type, network region identifier, and available resource status of each test node.

[0008] Receive an interface test task, the interface test task includes test configuration parameters, the test configuration parameters include at least the running platform conditions, regional constraints, and a comparability level parameter that represents the comparability requirements of the test task for cross-node execution results;

[0009] In response to the comparability level parameter indicating the requirement for cross-node result comparability, based on the equivalence constraint corresponding to the comparability level parameter, at least one first test node that meets the operating platform conditions, the regional constraints, and the equivalence constraint is selected from the schedulable resource pool; the equivalence constraint is used to constrain the equivalence among the first test nodes in terms of affecting the consistency of interface test results.

[0010] Determine the target test node from the first test node, and assign the interface test task to the target test node;

[0011] Receive the test execution result returned by the target test node after executing the interface test task.

[0012] Preferably, selecting at least one first test node from the schedulable resource pool includes:

[0013] Based on the historical and / or real-time status information of each test node in the schedulable resource pool, an equivalent feature vector is constructed for each test node; the equivalent feature vector contains multiple feature parameters used to characterize the consistency of the node's execution capability in interface testing; an equivalent matching threshold is determined according to the comparability level parameter; using a test node in the schedulable resource pool as a reference node, the similarity between the equivalent feature vectors of other test nodes and the reference node is calculated;

[0014] The test nodes whose similarity is greater than or equal to the equivalence matching threshold, and the reference nodes, are determined as the first test nodes that satisfy the equivalence constraint conditions.

[0015] Preferably, the equivalent feature vector includes at least one of the following feature parameters: network latency feature parameter, historical interface response time distribution feature parameter, recent task concurrency feature parameter, operating environment feature parameter, and resource stability feature parameter.

[0016] Preferably, before constructing and maintaining a dynamically updated schedulable resource pool, the method further includes: receiving node status information reported periodically or by events from each test node; wherein the node status information further includes at least one of the following: network connection quality parameters and operating system type.

[0017] Preferably, determining the target test node from the first test nodes includes: performing weighted round-robin scheduling based on the remaining number of tasks that each of the first test nodes can handle to determine the target test node.

[0018] Preferably, an equivalent interference sample is generated based on a preset abnormal scenario. The interference sample includes complete node state information, an equivalent feature vector, and an interference sample identifier. In sync with the adversarial sample generation cycle, the similarity misjudgment rate between normal nodes and interference samples is calculated. If the misjudgment rate exceeds a preset threshold, the equivalent matching threshold corresponding to high comparability and medium comparability is adjusted by a gradient descent algorithm.

[0019] Preferably, after receiving the test execution result returned by the target test node after executing the interface test task, the method further includes:

[0020] In response to the interface test task being executed by multiple target test nodes, and the comparability level parameter indicating the requirement for cross-node result comparability, a cross-node comparative analysis is performed on the test execution results received from each target test node.

[0021] In another aspect, this application also provides a cross-platform and cross-regional interface testing node deployment system, including:

[0022] The schedulable resource construction module is used to build and maintain a dynamically updated schedulable resource pool based on the node status information of multiple distributed test nodes. The node status information includes at least the running platform type, network region identifier, and available resource status of each test node.

[0023] The test task receiving and parsing module is used to receive interface test tasks. The interface test tasks include test configuration parameters, which at least include running platform conditions, regional constraints, and comparability level parameters that represent the comparability requirements of the test task's cross-node execution results.

[0024] The test node filtering module is used to respond to the comparability level parameter indicating the requirement for cross-node result comparability, and based on the equivalence constraint condition corresponding to the comparability level parameter, to filter at least one first test node from the schedulable resource pool that meets the operating platform conditions, the regional constraints, and the equivalence constraint condition; the equivalence constraint condition is used to constrain the equivalence among the first test nodes in terms of affecting the consistency of interface test results.

[0025] The target test node determination module is used to determine the target test node from the first test node and assign the interface test task to the target test node;

[0026] The test result receiving module is used to receive the test execution result returned by the target test node after executing the interface test task.

[0027] This application also provides a computer device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the cross-end, cross-regional interface test node deployment method as described above.

[0028] In another aspect, this application provides a computer-readable storage medium having stored thereon computer program instructions that can be executed by a processor to implement the cross-terminal and cross-regional interface test node deployment method described above.

[0029] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the cross-terminal and cross-regional interface test node deployment method described above.

[0030] This application achieves several technical benefits through a complete process, including node status information collection, schedulable resource pool construction, node selection and scheduling based on equivalence constraints, automatic test environment configuration, test task execution, and result analysis. First, it solves the problems of traditional test node deployment relying on manual intervention and high complexity, enabling automatic access, unified management, and dynamic scheduling of test nodes, supporting deployment across multiple platforms such as Windows, Android, iOS, Linux, and Docker, as well as across multiple regions nationwide and even globally. Second, through the node equivalence constraint deployment mechanism, it solves the problem of systematic deviations in test results caused by differences in node environments during cross-regional testing, ensuring that comparable test tasks possess cross-node statistical comparability and improving the credibility of test results. Third, it achieves automated and standardized configuration of the test environment, ensuring consistency across different node environments and avoiding interference from environmental differences in test results. Fourth, through weighted round-robin scheduling and dynamic maintenance of the resource pool, it improves the utilization rate of test resources and the efficiency of test task execution. Fifth, it forms a complete test closed loop, from task configuration, node scheduling, environment configuration, task execution to result analysis, all without manual intervention, simplifying the testing process and reducing the workload for testers. This method can be stably applied to various distributed interface testing scenarios, meeting testing needs with different comparability requirements, and providing an efficient, reliable, and accurate solution for interface testing. Attached Figure Description

[0031] Figure 1 This is a schematic diagram illustrating an application scenario of the deployment method provided in the embodiments of this application;

[0032] Figure 2 A schematic diagram illustrating a method for deploying interface test nodes across terminals and regions, provided in an embodiment of this application;

[0033] Figure 3 This is a schematic diagram of the node filtering process provided in an embodiment of this application;

[0034] Figure 4 A schematic diagram of a cross-platform and cross-regional interface test node deployment system provided in this application embodiment;

[0035] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0036] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0037] It should be noted that all user information (including but not limited to user device information, user personal information, object information corresponding to device usage data, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, device usage data, etc.) involved in all embodiments of this application are information and data authorized by the user or fully authorized by all parties.

[0038] The cross-platform and cross-regional interface test node deployment method described in this embodiment is applicable to distributed interface testing scenarios under multiple operating systems, multiple operating environments, and multiple network regions, and can be integrated into interface testing platforms, continuous integration testing systems, or automated testing platforms. Figure 1 The diagram illustrates the application scenario of the deployment method. This method is executed collaboratively by a central server and multiple distributed test nodes (hereinafter referred to as test nodes). Test nodes can be deployed in different geographical regions and different network environments, and support multiple operating platforms such as Windows, Android, iOS, Linux, and Docker. They can be deployed in various forms, including physical servers, virtual machines, or containers, and only need to meet the conditions of having network connectivity and the basic hardware resources required to run test tasks.

[0039] The following detailed description, in conjunction with specific embodiments, illustrates the implementation process of the cross-device and cross-regional interface test node deployment method described in this application. It should be noted that this embodiment is merely for explaining this application and not for limiting the scope of protection of this application. Any conventional adjustments or substitutions made by those skilled in the art to the steps without departing from the concept of this application should be included within the scope of protection of this application.

[0040] like Figure 2 As shown in the diagram, this application discloses a method for deploying interface test nodes that can be used across terminals and regions, including the following steps:

[0041] S1. Based on the node status information of multiple distributed test nodes, construct and maintain a dynamically updated schedulable resource pool. The node status information includes at least the running platform type, network region identifier, and available resource status of each test node.

[0042] S2, Receive interface test task, the interface test task includes test configuration parameters, the test configuration parameters include at least the running platform conditions, regional constraints, and comparability level parameters representing the comparability requirements of the test task for cross-node execution results;

[0043] S3, in response to the comparability level parameter indicating the requirement for cross-node result comparability, based on the equivalence constraint condition corresponding to the comparability level parameter, at least one first test node that meets the operating platform condition, the regional constraint condition, and the equivalence constraint condition is selected from the schedulable resource pool; the equivalence constraint condition is used to constrain the equivalence between the first test nodes in terms of affecting the consistency of interface test results.

[0044] S4, determine the target test node from the first test node, and assign the interface test task to the target test node;

[0045] S5, receive the test execution result returned by the target test node after executing the interface test task.

[0046] In some embodiments, the first step is to collect and receive node status information. This step, by receiving node status information periodically or triggered by events from the test nodes, enables the central server to fully grasp the real-time operating status of each test node, solving the problems of opaque and difficult-to-monitor status of traditional test nodes, and laying the foundation for subsequent accurate screening and scheduling.

[0047] The configuration includes test node status collection rules. Each test node is pre-configured with status collection rules, which include collection items, collection frequency, and triggering conditions. These rules can be uniformly distributed by the central server or configured locally on the test node during deployment and synchronized to the central server for record-keeping. Collection items must at least cover the operating platform type, network region identifier, available resource status, network connection quality parameters, and operating system type to ensure that the collected information comprehensively reflects the test node's execution capabilities and operating environment.

[0048] The data collection frequency is configured in a tiered manner. For static information such as the type of the running platform and the type of the operating system, the collection frequency can be configured to collect data once when the test node starts up, and then only when the information changes. For dynamic information such as network connection quality parameters and available resource status, the collection frequency can be configured to collect data periodically, for example, once every 30 seconds. Users can adjust the period length according to the test accuracy requirements. For special events such as node failure and network switching, event-triggered collection is configured to ensure that critical status changes are captured in a timely manner.

[0049] This includes node status information collection and encapsulation. Test nodes perform status collection operations according to preset collection rules:

[0050] Regarding the type of running platform and operating system: information is read by calling the system kernel interface, such as calling the GetVersionEx function in Windows, reading the / etc / os-release file in Linux, and reading container image metadata in Docker environment, to ensure that the information obtained accurately reflects the actual running carrier and system environment of the node;

[0051] For network region identifiers: they are obtained by a combination of IP resolution and manual configuration. The test node first resolves the region information corresponding to its own public IP through the built-in IP location database, such as province and city, and then reads the locally configured region identifier for verification. If the two are inconsistent, the manually configured identifier shall prevail.

[0052] Regarding the status of available resources: parameters such as CPU utilization, memory utilization, disk space remaining, and network connection count are collected through the system monitoring interface. For example, the average CPU utilization over 1 minute, the ratio of used memory capacity to total memory capacity, and the remaining storage space of a specified disk partition are collected.

[0053] For network connection quality parameters, including network latency, bandwidth, and packet loss rate, network latency is calculated by sending ICMP requests to the central server, calculating the time difference between the request being sent and the response being received, and taking the average value after five consecutive measurements. Bandwidth is determined by measuring the bidirectional data transmission volume between the central server and the central server per unit time. Packet loss rate is calculated by statistically analyzing the proportion of test data packets that were not successfully received out of 100 consecutively sent test packets.

[0054] After data collection is completed, the test node encapsulates all status information according to a preset data format, which can be structured using JSON format. The encapsulated data contains a unique identifier for the test node, which is a globally unique string generated during the initialization of the test node and is used by the central server to associate and identify the node.

[0055] Test nodes report encapsulated status information through a long-lived connection established with the central server. Periodically collected information is reported synchronously according to the collection cycle, while event-triggered information is reported immediately after collection. The central server listens on a designated port to receive status information reported by each test node. The central server can establish a dedicated status information database for each test node, storing the decapsulated status parameters associated with the node's unique identifier. A time-series database is used to store dynamically changing status information, such as network connection quality parameters and available resource status, facilitating the tracing of historical status. A relational database is used to store static information, such as operating platform type, operating system type, and network region identifier.

[0056] In some embodiments, for step S1, a dynamic schedulable resource pool is constructed based on the received node status information to achieve unified management and real-time synchronization of test nodes, solving the problems of decentralized management and lagging resource status in traditional test nodes, providing an efficient resource query and matching basis for test task screening and scheduling, and ensuring the timeliness and accuracy of scheduling decisions.

[0057] Specifically, regarding the design of the resource pool data structure, the schedulable resource pool built by the central server adopts a multi-dimensional indexed structured data model. The core data structure includes a node basic information table, a dynamic status data table, and a resource capability assessment table, with each table linked by a unique node identifier.

[0058] Specifically, the node basic information table stores static information about the test nodes, including the node's unique identifier, running platform type, operating system type, network region identifier, and deployment location description, providing a basic matching basis for resource screening.

[0059] For the dynamic status data table: it stores real-time dynamic information of test nodes, including network connection quality parameters, available resource status, current number of tasks being executed, and remaining number of tasks that can be carried, etc., sorted by timestamp, and supports real-time query and update;

[0060] For the resource capability assessment table: the resource capability score of the node is calculated based on dynamic status data. The score range is 0-100 points. The higher the score, the stronger the node's ability to execute test tasks, which provides a basis for determining scheduling priority.

[0061] In one embodiment, for each test node that successfully reports status information and passes validity verification, the central server automatically creates a corresponding node resource record. This record covers the core fields of the node basic information table, dynamic status data table, and resource capability assessment table, forming a complete node resource description.

[0062] During the creation process, the central server calculates the remaining number of tasks that can be handled based on the available resource status reported by the nodes using a preset algorithm. For example, it determines the maximum number of tasks that a node can execute in parallel based on CPU utilization and memory utilization, and subtracts the number of currently executed tasks to obtain the remaining number of tasks that can be handled. For instance, if a node has a CPU utilization of 30% and a memory utilization of 40%, and the preset maximum number of tasks that can be executed in parallel under this resource status is 8, and 3 tasks have already been executed, then the remaining number of tasks that can be handled is 5.

[0063] Meanwhile, resource capability scores are calculated based on dynamic status data, and the scoring formula is as follows:

[0064] ;in, Score resource capabilities; , , , These are weighting coefficients, summing to 1, and can be configured as follows: , , , ; CPU utilization; Memory usage; This is a bandwidth normalization value, converting the actual bandwidth into a value between 0 and 1; This represents the packet loss rate. This formula comprehensively evaluates the resource capabilities of nodes, providing a quantitative reference for subsequent scheduling. It is understood that the weights can be set according to actual circumstances; this embodiment does not impose any restrictions.

[0065] In one embodiment, the update of the schedulable resource pool includes two methods: real-time update and timed update. For real-time update, when the central server receives new status information reported by the test node, it immediately updates the dynamic status data table and resource capacity evaluation table corresponding to the node, recalculates the remaining number of tasks that can be carried and the resource capacity score, and ensures that the node status in the resource pool is consistent with the actual status.

[0066] For scheduled updates, the central server can perform consistency checks on all node resource records in the resource pool every minute, check the update timestamp of the node status information, and for nodes that have not been updated for more than a preset time and are marked as normal, resend the status query request. If no response is received, update its status to offline and adjust its resource capability score to 0.

[0067] In addition, when a test node completes a test task or a new task is assigned, the central server updates the current number of tasks being executed and the remaining number of tasks that the node can handle in real time, and adjusts the resource capacity score accordingly to ensure that the resource pool can reflect the task occupancy of the node in a timely manner.

[0068] In one embodiment, to improve the efficiency of test task screening, the central server constructs a multi-dimensional index for the schedulable resource pool, including:

[0069] Regional Index: Classified by network regional identifier, it categorizes node resource records in the same region and supports quick query by province, city, and other dimensions;

[0070] Platform Index: Categorized by combination of running platform type and operating system type, such as Windows and physical servers, Docker and Linux, etc., to support precise matching of the platform requirements of test tasks;

[0071] Status Index: Classified by the current status of the node, including normal, busy, and offline. The normal status means that the node can receive new tasks, the busy status means that the node has less than or equal to 2 remaining tasks, and the offline status means that the node cannot communicate.

[0072] Capability Index: Categorized by resource capability score range, such as 80-100 points, 60-79 points, 40-59 points, 0-39 points, and supports filtering by node capability priority.

[0073] By using multi-dimensional indexing, the central server can quickly narrow down the filtering range after receiving test tasks, improve node matching efficiency, and save time for subsequent scheduling processes.

[0074] This step aims to achieve centralized and dynamic management of test node resources. Through a structured data model and multi-dimensional indexes, the central server can quickly and accurately query node resources that meet the requirements of the test task, providing basic support for the efficient scheduling of test tasks and ensuring that the resource pool can reflect the actual availability status of nodes in real time, avoiding unreasonable scheduling problems caused by lagging resource information.

[0075] In some embodiments, step S2 involves receiving and parsing the interface test task. This step receives the user-configured test parameters and generates the interface test task, clarifying the various constraints of the test task, especially the comparability level parameter. This provides a basis for subsequent node selection based on equivalence constraints, solving the problems of unclear configuration and difficulty in matching node equivalence requirements in traditional test tasks, and ensuring that the test task accurately reflects the user's test objectives.

[0076] Specifically, the central server receives test configuration parameters input by the user through the interface provided by the testing platform. The testing platform can provide a visual configuration interface, and users can complete the parameter configuration through drop-down selection, input boxes, check boxes, etc. The configuration interface performs real-time parameter validity verification to ensure that the input parameters meet the requirements.

[0077] Test configuration parameters should include at least the operating platform conditions, regional constraints, and comparability level parameters. Optional parameters include the target environment type, test case set, concurrency, response timeout, and interface version number. Among these:

[0078] Operating platform requirements: Users can select one or more operating platforms, such as simultaneously selecting a Linux system and a Docker environment, to support cross-platform testing needs;

[0079] Geographic constraints: Users can select one or more regions, such as a specific city, or a range identifier such as "national" or "global", and the system will automatically match the test nodes for the corresponding regions;

[0080] Comparability level parameter: Users can select three levels: "High Comparability", "Medium Comparability" and "Low Comparability". High comparability means that the statistical difference of the execution results across nodes is less than a preset threshold, which is suitable for scenarios such as cross-regional regression testing and pre-release consistency verification. Medium comparability means that the core indicators of the execution results across nodes are consistent, which is suitable for scenarios such as cross-regional performance baseline verification. Low comparability means that there is no explicit requirement for consistency of results across nodes, which is suitable for ordinary functional testing scenarios.

[0081] In one embodiment, the central server generates interface test tasks based on verified test configuration parameters, assigning a unique task identifier to each test task to ensure its uniqueness. Each test task includes task description information and task execution information. The task description information includes configuration information such as task identifier, operating platform conditions, regional constraints, comparability level parameters, and target environment type, used for node selection and environment configuration. The task execution information includes execution parameters such as test case set, concurrency, response timeout, and interface version number, used by test nodes to execute the test task.

[0082] The central server stores the generated interface test tasks in the task queue, sorts them by task reception time, and records the task status as "pending scheduling," waiting for subsequent nodes to filter and allocate them.

[0083] In one embodiment, the central server retrieves the interface test tasks to be scheduled from the task queue, parses the task description information, and extracts the core constraints, including parsing the running platform conditions to obtain the target running platform set, such as {Linux system, Docker environment}; parsing the regional constraints to obtain the target regional set; parsing the comparability level parameters to determine the corresponding equivalence constraint requirements, such as high comparability corresponding to a strict equivalence matching threshold; and parsing optional parameters to clarify auxiliary execution conditions such as target environment type and concurrency.

[0084] After parsing, the core constraints and auxiliary execution conditions are organized into a structured screening basis, providing clear matching standards for subsequent node screening.

[0085] In this step, the reception and parsing of the comparability level parameter is a key link related to the core innovation. This parameter directly determines the strictness of the subsequent node equivalence screening, which solves the problem that traditional testing tasks do not clearly define the cross-node result comparability requirements, enabling testing tasks to accurately match the node screening requirements in different scenarios and ensuring that the test results meet the user's expected use.

[0086] In some embodiments, step S3 involves node screening and scheduling based on equivalence constraints. This step addresses the technical problem of traditional scheduling schemes that only focus on whether nodes are "available" without considering "comparability," leading to systematic biases in cross-regional test results. This is achieved by constructing node equivalence feature vectors, setting matching thresholds, calculating similarity, screening equivalent nodes, and performing weighted round-robin scheduling. The core principle is to quantify the characteristics of nodes influencing the consistency of test results, screen out a set of nodes with similar characteristics, and ensure that nodes within this set are scheduled to execute test tasks. This reduces the interference of node environment differences on test results, making cross-node test results statistically comparable and facilitating testers' accurate judgment of whether result differences are caused by the interface itself.

[0087] Please see Figure 3 , Figure 3 This is a schematic diagram of the node screening process provided in an embodiment of this application. In S301, the equivalence feature vector is constructed. The construction of the equivalence feature vector is based on the historical and real-time state information of each test node in the schedulable resource pool. Key feature parameters that can affect the consistency of interface test results are selected to ensure that the feature vector can comprehensively and accurately characterize the equivalence of the nodes.

[0088] Specifically, this includes (1) the selection and definition of feature parameters. Optionally, the equivalent feature vector contains at least one or more of the following feature parameters, and the definition and acquisition methods of each parameter are as follows:

[0089] Network latency characteristic parameters: The average latency is calculated by selecting the network latency data reported by the test node in the most recent 100 tests. Delay standard deviation The average latency reflects the average speed of network transmission at each node, while the standard deviation of latency reflects the stability of network latency. The smaller the standard deviation, the more stable the network and the less impact it has on the consistency of test results.

[0090] Historical API response time distribution characteristics: Query the response time data of the test node for the same API test tasks executed in the past 7 days, and calculate the average response time. Response time variation coefficient coefficient of variation ( (For response time standard deviation), the smaller the coefficient of variation, the more stable the response time of the node when performing similar interface tests, and the better the equivalence;

[0091] Recent task concurrency characteristic parameter: The average task concurrency of the test node in the most recent hour. This is the ratio of the total number of tasks executed within a given time period to the total time (hours). Nodes with similar concurrency levels are more consistent in their resource usage, thus avoiding test result deviations caused by differences in node load.

[0092] Runtime environment characteristic parameters: Encode runtime environment information such as operating system version, container image version, and dependent library version. For example, use one-hot encoding to convert different versions of the operating system into binary vectors to ensure that nodes with consistent runtime environments have the same or similar values ​​for this characteristic parameter.

[0093] Resource stability characteristic parameters: Calculate the coefficient of variation of CPU utilization reported by the test node in the most recent 50 reports. Coefficient of variation of memory usage The smaller the coefficient of variation, the more stable the resource status of the node, and the more balanced the resource supply when executing test tasks, which helps to ensure the consistency of test results.

[0094] (2) Standardization of feature parameters. Since the dimensions and value ranges of each feature parameter are different, direct similarity calculation will lead to deviation in the results. Therefore, it is necessary to standardize all feature parameters and convert them into values ​​in the range of [0,1] to eliminate the influence of dimensions.

[0095] The min-max normalization method is used, and the calculation formula is as follows:

[0096] ;in, These are the standardized eigenvalues. These are the original values ​​of the feature parameters. This is the minimum value of this feature parameter among all the test nodes to be screened. This is the maximum value of the feature parameter across all test nodes to be screened.

[0097] For the average latency among the network latency characteristic parameters Standardized value The smaller the value, the shorter the network latency; for latency standard deviation... Standardized value The smaller the value, the more stable the network latency. For historical interface response time distribution characteristic parameters, recent task concurrency characteristic parameters, and resource stability characteristic parameters, the smaller the standardized value, the better the stability of the corresponding feature.

[0098] For non-numerical features such as runtime environment characteristic parameters, one-hot encoding eliminates the need for min-max normalization. The encoded binary vector has each element with a value of 0 or 1, which can be directly used for similarity calculation.

[0099] (3) Assembly of equivalent feature vectors. The standardized feature parameters are assembled in a preset order to form the equivalent feature vector for each test node. For example, if network latency characteristic parameters are selected ( , ), historical interface response time distribution characteristic parameters ( , ), recent task concurrency feature parameters ( Operating environment characteristic parameters () , , ,in , , (Binary value after one-hot encoding), resource stability characteristic parameters ( , Then the equivalent eigenvector is:

[0100] Each test node corresponds to an equivalent feature vector with the same dimension. The vector dimension is determined by the number of selected feature parameters. The number of feature parameters can be adjusted according to actual testing needs, thereby adjusting the vector dimension.

[0101] In S302, the equivalence matching threshold is determined. Based on the comparability level parameter of the test task, the corresponding equivalence matching threshold is determined. This threshold is used to determine whether the equivalence feature vectors of two test nodes meet the similarity requirements. Different comparability levels correspond to different thresholds to adapt to the testing needs in different scenarios.

[0102] For example, the preset comparability level and equivalence matching threshold correspond as follows:

[0103] High comparability: Equivalent feature vector similarity threshold It is suitable for scenarios with extremely high requirements for the consistency of test results, such as consistency verification before release, to ensure that the statistical differences of test results across nodes are minimal;

[0104] Moderate comparability: Equivalent feature vector similarity threshold It is suitable for scenarios where there are certain requirements for the consistency of test results, such as cross-regional performance baseline verification, and allows for small statistical differences in test results across nodes;

[0105] Low comparability: No need to set an equivalence matching threshold, no equivalence screening is performed, and nodes are directly screened based on basic constraints. It is suitable for ordinary functional testing scenarios, and only needs to ensure that the nodes are available.

[0106] The threshold can be adjusted by the user on the testing platform according to the actual test accuracy requirements. The system provides the above threshold range by default. The threshold adjusted by the user must be within the range of [0,1] to ensure the reasonableness of the threshold setting.

[0107] In S303, the similarity of equivalent feature vectors is calculated. The cosine similarity algorithm is used to calculate the similarity between the equivalent feature vectors of two test nodes. Cosine similarity can effectively measure the directional consistency of two vectors. The closer the value is to 1, the more consistent the directions of the two vectors are, and the more similar the corresponding test nodes are in terms of equivalent features. This makes it more suitable for performing test tasks that require comparability.

[0108] The formula for calculating cosine similarity is as follows:

[0109] ;in, For test nodes With test node The equivalent feature vector similarity, with a value range of [0,1]; For test nodes The equivalent feature vector; For test nodes The equivalent feature vector; The dimension of the equivalent feature vector is the number of feature parameters selected.

[0110] The specific calculation process is as follows: (1) Select a reference node from the schedulable resource pool. The selection method of the reference node can be configured to select the node with the highest resource capability score or the node that has executed the same type of test task the most times in history, so as to ensure that the reference node has good execution capability and stability; (2) Calculate the similarity feature vector similarity between the reference node and each other test node in the schedulable resource pool; (3) Associate the similarity calculation result with the node unique identifier of the test node and store it to form a similarity list, which provides a basis for subsequent node selection.

[0111] In S304, the first test node is selected. The selection process for the first test node is divided into two stages: basic selection and equivalence selection. Basic selection ensures that the node meets the basic execution conditions of the test task, while equivalence selection ensures that the node meets the comparability requirements of the test task.

[0112] (1) Basic screening: Based on the parsed test task constraints, the central server performs basic screening on the test nodes in the schedulable resource pool. The screening rules are as follows:

[0113] Running platform matching rules: The running platform type of the test node must belong to the running platform condition set of the test task. For example, if the running platform condition of the test task is {Linux system, Docker environment}, then only test nodes with the running platform being Linux system or Docker environment will be retained.

[0114] Geographic matching rules: The network geographic identifier of the test node must belong to the geographic constraint set of the test task. For example, if the geographic constraint of the test task is {City X, City Y, City Z}, then only test nodes with network geographic identifiers of City X, City Y, or City Z will be retained.

[0115] Available status rules: The current status of the test node must be "normal" and the number of remaining tasks that can be carried must be greater than 0 to ensure that the node has the ability to execute new test tasks;

[0116] Target environment matching rules: Test nodes must be configured with the target environment type required by the test task. For example, if the target environment of the test task is a pre-production environment, only test nodes that have completed the pre-production environment configuration will be retained.

[0117] Through basic screening, a set of nodes that meet the basic execution conditions is obtained, denoted as . .

[0118] (2) Equivalence screening: For test tasks that require the comparability of results across nodes, the node set obtained from the basic screening is used as an indicator of the comparability level parameter. Based on this, an equivalence screening is performed, including:

[0119] From the node set Reference nodes are selected, and the selection rules for reference nodes are the same as those described above; the set of computation nodes is then calculated. The similarity of the equivalent feature vectors of each node and the reference node is calculated. Nodes with similarity greater than or equal to the corresponding comparability level threshold, along with the reference node, are identified as the first test nodes that satisfy the equivalence constraint, forming the first test node set. .

[0120] For example, if the comparability level of the test task is high comparability, the threshold... Node set It contains 5 nodes, with the reference node being node . Each node and its relation to other nodes The similarity of the nodes are respectively (0.991), node (0.923), node (0.876), node (0.958) then the nodes are selected. , , , Form the first test node set ,node Excluded because the similarity was below the threshold.

[0121] If the first test node set obtained after equivalence screening If the result is empty, or the number of nodes is less than the concurrency requirement of the test task, the central server will automatically lower the comparability threshold by one level and re-filter. For example, if the number of nodes is insufficient after high comparability filtering, a medium comparability threshold will be used. The similarity is recalculated and filtered. If the number of nodes still does not meet the requirements after lowering the threshold, the central server returns a prompt message to the testing platform, indicating that there are currently not enough test nodes to meet the equivalence constraints. It is recommended that users adjust the regional constraints, the comparability level, or increase the deployment of test nodes.

[0122] In some embodiments, an equivalent interference sample is generated based on a preset abnormal scenario. The interference sample includes complete node state information, an equivalent feature vector, and an interference sample identifier.

[0123] In sync with the adversarial sample generation cycle, the similarity misclassification rate between normal nodes and interference samples is calculated. If the misclassification rate exceeds the preset threshold, the equivalence matching thresholds corresponding to high comparability and medium comparability, as well as the weight ratio of equivalence feature parameters, are adjusted through the gradient descent algorithm.

[0124] Specifically, to enhance the anti-interference capability of equivalence judgment, this embodiment adds a similarity calibration mechanism based on adversarial training. By simulating abnormal scenarios, dynamically calibrating thresholds, and verifying screening results in real time, it ensures that equivalence judgment is not affected by instantaneous node anomalies or environmental interference. The specific implementation is as follows:

[0125] The system automatically simulates common abnormal scenarios for nodes at fixed intervals, generating multiple sets (e.g., 10 sets) of equivalent interference samples, which are then injected into a schedulable resource pool for dynamic maintenance. The abnormal scenario simulation closely resembles interference that may occur in actual test environments, ensuring the authenticity and representativeness of the samples. Specific simulation types include:

[0126] Network jitter simulation: By injecting random fluctuations in network latency, such as ±30%, and instantaneous packet loss rate, such as 5%-10%, into the samples, we simulate the scenario of unstable cross-regional network links;

[0127] Instantaneous high load simulation: Set instantaneous peak CPU utilization, such as 80%-90%, lasting for 1-3 minutes, and sudden increase in memory usage, such as 60%-70%, to simulate the load fluctuation scenario of a node temporarily undertaking high-concurrency tasks.

[0128] Simulation of minor differences in software dependency versions: In the runtime environment characteristics of the sample, set 1-2 non-core dependency library version deviations to simulate minor oversights in node environment configuration.

[0129] Simulation of instantaneous fluctuations in hardware resources: Simulate disk I / O response latency increasing from 5ms to 20ms, and CPU cache hit rate decreasing from 95% to 85%, simulating instantaneous performance degradation scenarios at the hardware level.

[0130] Each set of interference samples contains complete node state information and equivalent feature vectors, and carries an interference sample identifier, which is stored separately from normal node resource records to ensure accurate identification during subsequent calculations and verifications. After sample injection, the dynamic state data table of the schedulable resource pool will be updated synchronously, participating in the real-time update and index construction of the resource pool, without affecting the screening and scheduling of normal nodes.

[0131] The system periodically performs a threshold calibration process in sync with the adversarial sample generation cycle. It verifies the anti-interference capability of the current threshold using interference samples and dynamically adjusts and optimizes it. The specific steps are as follows:

[0132] Extract all normal nodes and 10 sets of interference samples from the schedulable resource pool, and calculate the similarity of the equivalent feature vectors between normal nodes and each set of interference samples. Count the number of times the interference sample is judged as an equivalent node, that is, the number of times the similarity is ≥ the current comparability level threshold, and divide it by the total number of calculations, i.e., the number of normal nodes × 10 sets of samples, to obtain the similarity misclassification rate.

[0133] If the similarity misclassification rate caused by interfering samples exceeds a preset threshold such as 8%, the current threshold is deemed to have insufficient anti-interference capability, and dynamic threshold adjustment is initiated; if the misclassification rate is ≤8%, the current threshold remains unchanged.

[0134] For example, with the optimization goal of reducing the false positive rate to below 5%, the equivalence matching threshold is fine-tuned using the gradient descent algorithm. For instance, the high comparability threshold is fine-tuned from 0.9 to 0.93, and the medium comparability threshold is fine-tuned from 0.7 to 0.75, with an adjustment step size of 0.01-0.03, to ensure the smoothness of the threshold adjustment;

[0135] Specifically, the implementation process of adjusting the threshold using the gradient descent algorithm is as follows:

[0136] With a false positive rate of ≤5% as the core objective, a loss function is constructed. ,in The equivalence matching threshold is set to a high / medium comparability threshold. The larger the loss value, the further the current threshold deviates from the target.

[0137] Set an initial threshold such as high comparability Medium comparability Configure and adjust step size This range controls the adjustment magnitude to ensure smoothness;

[0138] Calculate the initial threshold The actual misclassification rate is substituted into the loss function to obtain the loss value. ;

[0139] Find the loss function with respect to the threshold The gradient is the derivative, and the direction of the gradient is the direction in which the "false positive rate increases";

[0140] Update the threshold in the opposite direction of the gradient. ( (This is the current gradient), meaning that when the false positive rate is higher than 5%, the threshold is slightly adjusted in the direction of increasing;

[0141] Recalculate the new threshold The corresponding false positive rate and loss value are iterated repeatedly;

[0142] When the loss value is ≤0 (false positive rate ≤5%), or the number of iterations reaches the preset upper limit such as 20 times, the adjustment is stopped and the final threshold is obtained; at the same time, the threshold is constrained to always be in the range of [0,1] to avoid exceeding the reasonable range;

[0143] The entire process uses small-step iterations and gradient reversal adjustments to ensure a smooth increase in the threshold and precise convergence to the target of a false positive rate of less than 5%, ensuring no abrupt adjustments.

[0144] Optionally, the core feature parameters that cause misjudgments in the interference samples can be analyzed simultaneously, and the weight of anti-interference related features can be increased accordingly. For example, if network jitter samples cause the highest misjudgment rate, the weight of network latency feature parameters can be increased from the original proportion; if load fluctuation samples have a significant impact, the weight of resource stability feature parameters can be increased to ensure that the feature vector is more sensitive to interference factors.

[0145] After the threshold and weight are adjusted, the constraint rule base in the test task receiving and parsing module will be updated synchronously. Newly received test tasks will be filtered for nodes using the calibrated threshold and weight, while tasks already being executed will continue to use the original configuration to ensure the continuity of task execution.

[0146] After the first test node screening is completed, a real-time anti-interference verification step is added to verify the anti-interference effectiveness of the screening results. The specific process is as follows:

[0147] Extract all nodes carrying interference sample identifiers from the schedulable resource pool, and randomly select a few groups, such as 3 groups of interference samples, as the verification benchmark.

[0148] Calculate the similarity of the equivalent feature vectors of each node in the first test node set with the three sets of verification samples, and take the average of the three similarities as the final similarity between the node and the interference samples.

[0149] If the final similarity between all nodes in the first test node set and the interference sample is ≤0.7, the screening result is deemed valid and no interference sample is mixed in, and the subsequent target node determination stage can be entered; if any node has a final similarity >0.7 with the interference sample, the screening result is deemed to have interference risk, and the S304 screening process needs to be re-executed, that is, the reference node is re-selected, the similarity is calculated, and the first test node is screened.

[0150] Real-time anti-interference verification can effectively eliminate the mixing of non-equivalent nodes caused by environmental interference and sample misjudgment, ensuring the equivalence purity of the first test node set and providing double protection for the comparability of subsequent test results.

[0151] In some embodiments, for step S4, from the first test node set The target test node is determined, and a weighted round-robin scheduling algorithm based on the number of remaining tasks is adopted. This algorithm can allocate tasks according to the remaining carrying capacity of the node, achieve load balancing, avoid some nodes being overloaded while others are idle, and ensure that the test tasks are executed efficiently.

[0152] The specific implementation process of the weighted round-robin scheduling algorithm is as follows:

[0153] Step 1: Obtain the first set of test nodes The remaining number of tasks that each node can handle. ( (As the node index), it is used as the weight of that node. ;

[0154] Step 2: Calculate the sum of the weights of all nodes. ,in For the first set of test nodes The number of nodes in;

[0155] Step 3: Generate a number from 0 to... Random numbers between ;

[0156] Step 4: Accumulate the weights according to the node order. When the accumulated value is greater than the random number... When this happens, select that node as the target test node;

[0157] Step 5: Repeat steps 3-4 until a target test node with the same number of concurrent test tasks is selected. If the test task does not need to be executed concurrently, select 1 target test node.

[0158] For example, the first set of test nodes Includes nodes (Remaining number of tasks that can be handled is 5, weight) ),node (Remaining number of tasks that can be handled is 3, weight) ),node (Remaining number of tasks that can be handled is 4, weight) ),node (Remaining number of tasks that can be handled is 6, weight) ), total weight If the generated random number Weights are accumulated sequentially: Nodes Accumulate 5 (≤10), node Add 3 (5+3=8≤10), node Add 4 (8+4=12>10), then select the node. As the target test node; if the generated random number ,node Accumulate 5 (≤15), node Accumulate 3 (8≤15), node Accumulate 4 (12≤15), node Add 6 (12+6=18>15), then select the node. As the target test node.

[0159] In one embodiment, after the target test node is determined, the central server sends the task description information and task execution information of the interface test task to each target test node. The sending process is carried out through a long connection, and the transmitted data is encrypted to ensure data security.

[0160] Meanwhile, the central server updates the resource status of the target test node: increments the current number of tasks executed by the node by 1, decrements the remaining number of tasks that can be carried by 1, recalculates the resource capacity score, and synchronously updates the node resource records in the schedulable resource pool to ensure that the resource pool status is consistent with the actual status.

[0161] In addition, the central server records task allocation information, including task identifier, unique identifier of target test node, allocation time, and task status (allocated), which facilitates subsequent tracking of task execution progress.

[0162] Optionally, during the execution of test tasks on the target test node, the node's equivalence characteristics may drift due to factors such as changes in network status and fluctuations in resource load, leading to equivalence degradation and affecting the comparability of test results. Therefore, the central server monitors the status information of the target test node in real time and establishes an equivalence degradation perception mechanism.

[0163] Specifically, (1) Degradation judgment criteria. The central server periodically (e.g., every 5 minutes) collects the real-time status information of the target test node, updates the equivalence feature vector, and calculates its real-time similarity with the reference node. If the real-time similarity is lower than the equivalence matching threshold corresponding to the test task, and the duration exceeds the preset duration (e.g., 1 minute), then the node is judged to have degraded equivalence.

[0164] (2) Degradation handling mechanism. When the equivalence degradation of the target test node is detected, the central server triggers one of the following handling mechanisms:

[0165] Automatic node replacement: from the first test node set In the process, a new target test node that meets the equivalence requirements is selected, and a task switching command is issued. The original target test node stops executing the current test task, and the new target test node continues to execute, ensuring that the test task is completed on the equivalent node.

[0166] Result annotation: If the test task has executed some test cases and the node cannot be switched, the equivalence degradation information of the node will be marked in the subsequent test results to prompt testers to consider the impact of changes in the node environment when analyzing the results.

[0167] This further ensures the stability of node equivalence during the execution of the test task, ensures that the comparability of test results is not affected by dynamic changes in node states, and improves the robustness of the method.

[0168] This solves the technical problem of systematic deviations in the execution results of the same interface on different nodes in cross-regional and multi-network environments. It enables comparable test tasks to be executed within a set of nodes with similar equivalence characteristics, reducing the interference of node environment differences on test results and ensuring statistical comparability of cross-node test results. It achieves load balancing through weighted round-robin scheduling, improving the utilization rate of test resources. Through the equivalence degradation perception mechanism, it ensures the stability of node equivalence during the test process, thereby improving the credibility of test results.

[0169] In some embodiments, the test environment is automatically configured. This step is performed by the target test node, which automatically completes the configuration of the local test environment according to the test environment configuration requirements issued by the central server. This solves the problems of traditional test environment configuration relying on manual intervention, strong coupling with nodes, and inconsistencies between different node environments. It ensures that the test environment of the target test node is fully matched with the test task requirements, and that the test environments of different target test nodes are consistent, providing environmental support for the accuracy and comparability of test results.

[0170] The target test node receives the test environment configuration requirements issued by the central server through a long connection. The configuration requirements include information such as the target environment type, dependent software versions, configuration parameters, and environment variables. For example, if the target environment is a pre-production environment, the dependent software includes JDK 11 and MySQL 8.0, the configuration parameters include the database connection address and port number, and the environment variables include the interface service address and log storage path.

[0171] The target test node parses the configuration requirements, extracts the core configuration items, and categorizes them by software dependencies, system configurations, and environment variables to form a configuration list, ensuring that subsequent configuration operations are executed in an orderly manner.

[0172] The test node queries the current local environment status, including installed software and versions, system configuration parameters, environment variable settings, etc., and compares them item by item with the parsed configuration list to analyze the differences. The differences include: missing items: software or dependent libraries required by the configuration are not installed locally; version mismatch items: the version of the software installed locally is inconsistent with the configuration requirements; configuration inconsistencies items: system configuration parameters and environment variables do not match the configuration requirements.

[0173] The target test node automatically performs configuration operations based on the difference analysis results, without manual intervention:

[0174] Missing Item Installation: For missing software or dependency libraries, the target test node automatically downloads the installation package through a preset software source (such as the official source or internal private source). After verifying the integrity and legality of the installation package, it installs it according to the default path or the path required by the configuration. For example, it installs MySQL 8.0 through the apt-get command and installs Python dependency libraries through the pip command.

[0175] Version upgrade / downgrade: For software with incompatible versions, automatically uninstall the current version, download and install the version that meets the configuration requirements, and verify whether the version meets the requirements after installation;

[0176] Configuration parameter adjustment: For cases where system configuration parameters and environment variables do not match, the corresponding configuration files or system registry will be automatically modified to set the required parameter values. For example, the connection address and port number in the database configuration file will be modified, and environment variables will be set and applied.

[0177] Docker environment configuration: If the target test node is a Docker container environment, automatically pull the container image required by the configuration, start the container and configure parameters such as port mapping, data volume mounting, and environment variable injection to ensure that the container environment meets the test requirements.

[0178] The target test node reports the environment configuration completion status to the central server and enters the test task execution preparation state.

[0179] In some embodiments, for step S5, the target test node performs the test task, collects the test execution results and reports them to the central server, ensuring that the test task is completed as required and the test results are completely and accurately fed back to the central server, providing data support for subsequent result analysis.

[0180] The target test node loads the test case set of the test task, parses the request method, request address, request parameters, expected response result, response timeout and other information of each test case, and starts the corresponding number of threads or processes according to the concurrency requirements of the test task.

[0181] The target test node executes test tasks in the order of test cases, and the execution process is as follows:

[0182] Constructing requests: Based on the request method, address, and parameters of the test case, construct HTTP or other protocol requests, and set parameters such as request headers and timeout.

[0183] Sending requests and receiving responses: Send the constructed request to the target interface and wait for a response. If no response is received within a timeout period, record the response timeout result. If a response is received, read the response status code, response body, and other information.

[0184] Result comparison: The actual response result is compared with the expected response result. The comparison methods include exact comparison (response body is completely consistent) and fuzzy comparison (core fields are consistent). For example, the user information query test case uses fuzzy comparison, which only needs to ensure that the core fields such as user ID and name are consistent.

[0185] Results Recording: Record the execution result (pass / fail), execution time, response time, and failure reason (such as response timeout, status code error, data inconsistency) for each test case.

[0186] Optionally, during the execution of the test task, the target test node records execution logs in real time, including execution details and exception information for each test case, which facilitates subsequent troubleshooting.

[0187] After all test cases are executed, the target test node organizes and encapsulates the test execution results, generating test result data in a preset format. The data includes information such as task identifier, node unique identifier, execution time, total number of test cases, number of passes, number of failures, detailed results for each test case, and execution logs.

[0188] The encapsulated test results data are reported to the central server via a long connection using an encrypted method. After the target test node completes the report, it sends a report completion notification to the central server. After the central server confirms receipt, the target test node updates its local task status to "completed" and releases the occupied resources.

[0189] In one embodiment, test results are collected and compared across nodes. This step is performed by the central server, which collects the test execution results reported by each target test node, performs cross-node comparative analysis on test tasks that require comparability, and solves the problems of scattered test result management and difficulty in comparing cross-node results in traditional methods. This provides users with clear and intuitive test result display and analysis conclusions, making it easier for users to judge interface performance and consistency.

[0190] The central server receives test result data reported by each target test node and performs integrity and legality checks on the received data, including integrity checks: checking whether the data contains core fields such as task identifier, node unique identifier, and test case results, and whether any fields are missing; legality checks: checking whether the data format is correct, whether numeric fields are within a reasonable range (e.g., the number of test cases passed cannot exceed the total number), and whether the signature is valid (to prevent data tampering).

[0191] If the verification passes, the central server will associate the test result data with the task identifier and the node's unique identifier and store it in the result database; if the verification fails, it will return a retransmission request to the target test node to ensure the integrity and accuracy of the test result data.

[0192] The central server organizes the verified test results data, classifies them by task identifier, extracts core indicators, including test case pass rate, average response time, maximum response time, minimum response time, and distribution of failed test cases, and forms a results summary.

[0193] A time-series database is used to store detailed test results, supporting queries by task identifier, node identifier, and time range. A relational database is used to store result summaries for quick display and statistical analysis. Simultaneously, test execution logs are stored in association with the test results, allowing users to view the detailed execution process.

[0194] In one embodiment, when an interface testing task is executed by multiple target test nodes, and the comparability level parameter indicates the requirement for cross-node result comparability, the central server performs cross-node comparative analysis:

[0195] Pass rate comparison: Statistically calculate the pass rate of test cases for each target test node, calculate the standard deviation of the pass rate. If the standard deviation is less than a preset threshold (e.g., 5%), the pass rate is considered to be consistent. If the standard deviation is greater than the threshold, mark the nodes with large differences in pass rate and prompt the user to analyze the reasons.

[0196] Response time comparison: Calculate the average response time of each target test node, and use analysis of variance (ANOVA) to determine whether there are significant differences in the response time of each node. If there are no significant differences (P value > 0.05), it indicates that the response time is consistent. If there are significant differences (P value ≤ 0.05), combine the node equivalence feature vector to analyze whether the difference is caused by node equivalence degradation or other abnormal factors.

[0197] Failed test case comparison: Compare the failed test cases of each target test node. If the failed test cases are completely identical and the reasons for failure are the same, then the failure is determined to be caused by the interface itself. If the failed test cases are different or the reasons for failure are different, then analyze whether the failure is caused by the differences in the node environment by combining the node environment configuration and equivalence status.

[0198] The central server generates a cross-node comparison report based on the comparative analysis results. The report includes comparative data, charts, analysis conclusions, and anomaly alerts for various indicators, providing direct evidence for users to analyze the performance and consistency of the interface.

[0199] The central server feeds back the compiled test results and cross-node comparison reports to the testing platform. The testing platform displays these results to users through a visual interface, including a task execution overview, detailed results for each node, cross-node comparison charts, and a test report download function. Users can intuitively view the test results, download the test reports, and determine whether there are any problems with the interface based on the analysis conclusions.

[0200] This enables unified management and cross-node comparative analysis of test results, especially providing professional result analysis for test tasks that require comparability, helping users quickly determine interface performance and consistency, and enhancing the utilization value of test results.

[0201] The cross-platform and cross-regional interface test node deployment method described in this embodiment achieves several technical effects through a complete process including node status information collection, schedulable resource pool construction, node selection and scheduling based on equivalence constraints, automatic test environment configuration, test task execution, and result analysis. Firstly, it solves the problems of traditional test node deployment relying on manual labor and high complexity, enabling automatic access, unified management, and dynamic scheduling of test nodes, supporting deployment across multiple platforms such as Windows, Android, iOS, Linux, and Docker, as well as across multiple regions nationwide and even globally. Secondly, it utilizes node equivalence constraints for deployment. This mechanism addresses the systematic bias in test results caused by differences in node environments during cross-regional testing, ensuring statistical comparability across nodes for tasks requiring comparability and improving the reliability of test results. Thirdly, it automates and standardizes test environment configuration, ensuring consistency across different nodes and avoiding interference from environmental differences. Fourthly, it improves test resource utilization and task execution efficiency through weighted round-robin scheduling and dynamic resource pool maintenance. Fifthly, it forms a complete testing loop, from task configuration, node scheduling, environment configuration, task execution to result analysis, all without manual intervention, simplifying the testing process and reducing the workload for testers. This method can be stably applied to various distributed interface testing scenarios, meeting different comparability requirements and providing an efficient, reliable, and accurate solution for interface testing.

[0202] Please see Figure 4 , Figure 4 This application provides an embodiment of an interface test node deployment system 400 capable of cross-platform and cross-regional deployment. This system embodiment is similar to... Figure 1 Corresponding to the illustrated method embodiments, this system can be specifically applied to various computer devices. The system specifically includes:

[0203] The schedulable resource construction module 401 is used to construct and maintain a dynamically updated schedulable resource pool based on the node status information of multiple distributed test nodes. The node status information includes at least the running platform type, network region identifier, and available resource status of each test node.

[0204] The test task receiving and parsing module 402 is used to receive interface test tasks. The interface test tasks include test configuration parameters, which at least include running platform conditions, regional constraints, and comparability level parameters that represent the comparability requirements of the test task for cross-node execution results.

[0205] The test node screening module 403 is used to respond to the comparability level parameter indicating the requirement for cross-node result comparability, and based on the equivalence constraint condition corresponding to the comparability level parameter, to screen at least one first test node from the schedulable resource pool that meets the operating platform conditions, the regional constraints, and the equivalence constraint condition; the equivalence constraint condition is used to constrain the equivalence among the first test nodes in terms of affecting the consistency of interface test results.

[0206] The target test node determination module 404 is used to determine a target test node from the first test node and assign the interface test task to the target test node;

[0207] The test result receiving module 405 is used to receive the test execution result returned by the target test node after executing the interface test task.

[0208] Based on the same inventive concept, this application also provides a computer device, the method corresponding to which can be the method in the foregoing embodiments, and the principle of solving the problem is similar to that method. The computer device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0209] The computer device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and smart bands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0210] Figure 5The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0211] The following components are connected to I / O interface 505: input section 506 including keyboard, mouse, touch screen, microphone, infrared sensor, etc.; output section 507 including cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; storage section 508 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and communication section 509 including network interface card such as LAN (local area network) card, modem, etc. Communication section 509 performs communication processing via a network such as the Internet.

[0212] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 501, it performs the functions defined in the methods of this application.

[0213] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0214] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0215] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0216] Furthermore, the inclusion of a single word does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a system claim may also be implemented by a single unit or device through software or hardware. Terms such as "first," "second," etc., are used to indicate names and do not indicate any particular order.

Claims

1. A method for deploying interface test nodes across devices and regions, characterized in that, Includes the following steps: Based on the node status information of multiple distributed test nodes, a dynamically updated schedulable resource pool is constructed and maintained. The node status information includes at least the running platform type, network region identifier, and available resource status of each test node. The system receives an interface testing task, which includes test configuration parameters. These parameters include at least the operating platform conditions, regional constraints, and a comparability level parameter representing the comparability requirements of the test task's cross-node execution results. The comparability level parameter includes high comparability, medium comparability, and low comparability. High comparability means that the statistical difference between the cross-node execution results is less than a preset threshold. Medium comparability means that the core indicators of the cross-node execution results are consistent. Low comparability means that there is no explicit requirement for consistency of cross-node results. In response to the comparability level parameter indicating the requirement for cross-node result comparability, based on the equivalence constraints corresponding to the comparability level parameter, at least one first test node is selected from the schedulable resource pool that satisfies the operating platform conditions, the regional constraints, and the equivalence constraints. The equivalence constraints are used to constrain the equivalence among the first test nodes in terms of influencing the consistency of interface test results. The equivalence constraints include: constructing an equivalence feature vector for each test node based on the historical and / or real-time status information of each test node in the schedulable resource pool, wherein the equivalence feature vector contains multiple feature parameters used to characterize the consistency of the node's execution capability in interface testing; determining the corresponding equivalence matching threshold according to the comparability level parameter; using a test node in the schedulable resource pool as a reference node, calculating the similarity between the equivalence feature vectors of other test nodes and the reference node, and determining the test nodes whose similarity is greater than or equal to the equivalence matching threshold and the reference node as the first test nodes that satisfy the equivalence constraints. Determine the target test node from the first test node, and assign the interface test task to the target test node; Receive the test execution result returned by the target test node after executing the interface test task.

2. The method for deploying interface test nodes across terminals and regions according to claim 1, characterized in that, The equivalent feature vector includes at least one of the following feature parameters: network latency feature parameter, historical interface response time distribution feature parameter, recent task concurrency feature parameter, operating environment feature parameter, and resource stability feature parameter.

3. The method for deploying interface test nodes across terminals and regions according to claim 2, characterized in that, Before building and maintaining a dynamically updated schedulable resource pool, the method also includes: receiving node status information reported periodically or by events from each test node; wherein the node status information includes at least one of the following: network connection quality parameters and operating system type.

4. The method for deploying interface test nodes across terminals and regions according to claim 1, characterized in that, Determining the target test node from the first test nodes includes: performing weighted round-robin scheduling based on the remaining number of tasks that each of the first test nodes can handle, to determine the target test node.

5. The method for deploying interface test nodes across terminals and regions according to claim 2, characterized in that, It also includes generating equivalent interference samples based on preset abnormal scenarios, wherein the interference samples include complete node state information, equivalent feature vectors and interference sample identifiers; In sync with the adversarial sample generation cycle, the similarity misclassification rate between normal nodes and interference samples is calculated. If the misclassification rate exceeds a preset threshold, the equivalence matching thresholds corresponding to high comparability and medium comparability are adjusted using the gradient descent algorithm.

6. The method for deploying interface test nodes across terminals and regions according to claim 1, characterized in that, After receiving the test execution result returned by the target test node after executing the interface test task, the method further includes: In response to the interface test task being executed by multiple target test nodes, and the comparability level parameter indicating the requirement for cross-node result comparability, a cross-node comparative analysis is performed on the test execution results received from each target test node.

7. A cross-platform and cross-regional interface testing node deployment system, characterized in that, include: The schedulable resource construction module is used to build and maintain a dynamically updated schedulable resource pool based on the node status information of multiple distributed test nodes. The node status information includes at least the running platform type, network region identifier, and available resource status of each test node. The test task receiving and parsing module is used to receive interface test tasks. The interface test tasks include test configuration parameters, which at least include running platform conditions, regional constraints, and comparability level parameters representing the comparability requirements of the test task's cross-node execution results. The comparability level parameters include high comparability, medium comparability, and low comparability. High comparability means that the statistical difference of the cross-node execution results is less than a preset threshold. Medium comparability means that the core indicators of the cross-node execution results are consistent. Low comparability means that there is no explicit requirement for consistency of cross-node results. A test node filtering module is used to respond to the comparability level parameter indicating the requirement for cross-node result comparability, and based on the equivalence constraint conditions corresponding to the comparability level parameter, to filter at least one first test node from the schedulable resource pool that meets the operating platform conditions, the regional constraints, and the equivalence constraint conditions; the equivalence constraint conditions are used to constrain the equivalence among the first test nodes in terms of affecting the consistency of interface test results; the equivalence constraint conditions include: constructing an equivalence feature vector for each test node based on the historical and / or real-time status information of each test node in the schedulable resource pool, the equivalence feature vector containing multiple feature parameters used to characterize the consistency of the node's execution capability in interface testing; determining the corresponding equivalence matching threshold according to the comparability level parameter; using a test node in the schedulable resource pool as a reference node, calculating the similarity between the equivalence feature vectors of other test nodes and the reference node, and determining the test nodes whose similarity is greater than or equal to the equivalence matching threshold and the reference node as the first test nodes that meet the equivalence constraint conditions. The target test node determination module is used to determine the target test node from the first test node and assign the interface test task to the target test node; The test result receiving module is used to receive the test execution result returned by the target test node after executing the interface test task.

8. A computer device, wherein the computer device is characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 6.

9. A computer-readable medium having computer program instructions stored thereon, characterized in that, The computer program instructions can be executed by a processor to implement the method as described in any one of claims 1 to 6.

Images