A regression testing method and system based on traffic playback and mock technology

Abstract

The application discloses a regression testing method and system based on traffic playback and Mock technology, and relates to the technical field of software testing. The method comprises the following steps: integrating interface configuration information of a to-be-tested system, third-party interface information, traffic classification configuration information and traffic selection strategy configuration information to form testing configuration data; intelligently classifying and sampling online traffic according to the configuration data to generate a regression testing case library; extracting all third-party interface calling information from the regression testing case library, classifying and arranging the third-party interface calling information through interface classification and interception strategies, and constructing Mock services for specified protocol types to generate a Mock interface service set; performing multi-thread parallel testing on a testing task based on the regression testing case library and the Mock interface service set; and performing return value comparison and performance comparison on testing result data based on the regression testing case library to generate a testing report. The application can improve the efficiency and quality of regression testing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software testing, in particular to a regression testing method and system based on traffic playback and Mock technology. BACKGROUND

[0002] During the development of software systems, regression testing is a key step to ensure that new functions or changes do not affect existing functions. With the increasing complexity of software systems, regression testing is facing greater and greater challenges. In the existing technical field, regression testing usually uses automated test cases or online traffic playback to verify that the system still works normally after changes.

[0003] Traditional regression testing methods mainly include manually configured automated test cases and online traffic playback-based testing methods. Automated test cases require testers to write and maintain a large number of test scripts, which is time-consuming and difficult to cover all scenarios; while the online traffic playback method can restore real user operation scenarios, but often requires processing a large amount of data, and may cause unnecessary calls to third-party systems during testing.

[0004] The current more advanced regression testing technology is a method that combines online traffic playback with interface Mock technology. This method records and plays back real online traffic data, and uses Mock technology to simulate the response of third-party system interfaces, avoiding calls to actual third-party systems. However, this method still has some technical difficulties in actual application.

[0005] When using online traffic for regression testing, the existing technology faces the problem of traffic selection: too much traffic will increase the pressure and cost of the test system, while too little traffic cannot guarantee the comprehensiveness of the test. At the same time, when Mocking third-party interfaces, it is usually necessary to manually configure Mock return values, which is time-consuming and difficult to cover various business branch scenarios. In addition, directly calling third-party systems without Mocking will generate additional call fees and dependency risks. Therefore, it seriously affects the quality, efficiency and cost control of regression testing. SUMMARY

[0006] The purpose of the present application is to provide a regression testing method and system based on traffic playback and Mock technology, aiming to solve the problems of unreasonable traffic selection, complex Mock configuration and low test efficiency in existing regression testing.

[0007] To achieve the above purpose, the present application provides a regression testing method based on traffic playback and Mock technology, comprising the following steps:

[0008] Integrate the obtained interface configuration information of the to-be-tested system, third-party interface information, traffic classification configuration information, and traffic selection strategy configuration information to form test configuration data;

[0009] Classify and sample online traffic data according to the test configuration data to generate a regression test case library;

[0010] Extract all third-party interface call information from the regression test case library, classify and arrange the third-party interface call information through a preset interface classification and interception strategy, and construct a Mock service for a specified protocol type to generate a Mock interface service set;

[0011] Based on the regression test case library and the Mock interface service set, perform multi-thread parallel testing on a test task related to the regression test case library to generate test result data, the test result data including an execution result of a test case indicated in the regression test case library;

[0012] Based on the regression test case library, perform return value comparison and performance comparison on the test result data to generate a test report.

[0013] Optionally, the step of classifying and sampling online traffic data according to the test configuration data to generate a regression test case library includes:

[0014] According to the traffic classification configuration information and the traffic selection strategy configuration information, perform statistical analysis on online traffic data, and calculate the traffic quantity distribution of each traffic category and traffic subcategory in a specified time range to generate a traffic distribution statistical table;

[0015] Proportionally calculate the traffic distribution statistical table and the traffic classification configuration information to determine the number of test cases that need to be selected for each traffic subcategory in each time period to generate a traffic selection quota table;

[0016] According to the traffic selection quota table and the traffic selection strategy configuration information, select a corresponding number of test cases from online traffic data in different time periods by using a preset time-weighted random sampling strategy, to generate an initial traffic test case set, wherein the time-weighted random sampling strategy is used to indicate that traffic data with a time difference less than a preset time difference threshold is preferentially selected;

[0017] Based on the initial traffic test case set and the traffic selection strategy configuration information, select a preset proportion of abnormal traffic to generate a supplementary traffic test case set for supplementing abnormal traffic;

[0018] According to the supplementary traffic test case set, perform data conversion, storage processing, and format conversion on the initial traffic test case set to generate a regression test case library.

[0019] Optionally, the third-party interface calling information is extracted from the regression test case library, classified and arranged through a preset interface classification and interception strategy, and Mock services for a specified protocol type are constructed to generate a Mock interface service set, including:

[0020] The regression test case library and the third-party interface information are data-analyzed to extract all third-party interface calling information, including request parameters, return results and calling time consumption;

[0021] The third-party interface calling information is classified and processed according to protocol types and systems to generate a plurality of interface calling information sets, including an HTTP interface calling information set, a Dubbo interface calling information set and other type interface calling information sets;

[0022] A preset Web filter algorithm is used to perform request interception, parameter matching and response simulation on the HTTP interface calling information set to construct an HTTP interface Mock service;

[0023] A preset Dubbo filter algorithm is used to perform request interception, parameter matching and response simulation on the Dubbo interface calling information set to construct a Dubbo interface Mock service;

[0024] An interception algorithm related to the other type interface calling information set is used to perform request interception, parameter matching and response simulation on the other type interface calling information set to construct other type interface Mock services;

[0025] The HTTP interface Mock service, the Dubbo interface Mock service and the other type interface Mock services are deployed into a test environment and organized into a Mock interface service set.

[0026] Optionally, based on the regression test case library and the Mock interface service set, a plurality of test tasks related to the regression test case library are tested in parallel in multiple threads to generate test result data, including:

[0027] Test cases included in the regression test case library are assigned as a plurality of test tasks that can be executed in parallel;

[0028] When it is detected based on the test tasks and the test environment that the to-be-tested system and the Mock interface service set are in a ready state, an environment ready confirmation result is output, the environment ready confirmation result being used to indicate that the test environment meets a preset execution condition;

[0029] In response to the environment readiness confirmation result, a plurality of test tasks are called in multi-thread parallel mode, and each thread executes a test case, collects the execution results of each test case, including interface return value, execution status and performance data, and generates original test result data;

[0030] Based on the original test result data, abnormal test cases with execution timeout or failure are identified, and the abnormal test cases are retested, and combining the original test result data and retest result data, compensation test result data is generated;

[0031] The compensation test result data is subjected to data conversion standardization processing and format conversion to generate the test result data.

[0032] Optionally, the test result data is subjected to return value comparison and performance comparison based on the regression test case library to generate a test report, including:

[0033] Based on the interface configuration information, the preset configuration interface and / or configuration file, return value comparison rules and performance threshold configuration rules are determined, wherein the return value comparison rules include ignored fields and comparison methods, and the performance threshold configuration rules include allowed response time deviation percentage;

[0034] The return value comparison of each test case is performed on the test result data, the original return value in the regression test case library and the return value comparison rules to generate return value comparison results;

[0035] The performance comparison of each test case performance indicator is performed on the test result data, the original performance data in the regression test case library and the performance threshold configuration rules to generate performance comparison results;

[0036] The return value comparison results and the performance comparison results are integrated, and test cases that do not meet expectations are marked to generate the test report.

[0037] Optionally, according to the traffic selection quota table and the traffic selection strategy configuration information, a preset time-weighted random sampling strategy is used to select a corresponding number of use cases from online traffic data in different time periods to generate an initial traffic use case set, including:

[0038] According to the traffic selection quota table, a PIPQ data structure with a double-layer structure is initialized and created, and an initialized PIPQ instance is generated from the PIPQ data structure, wherein the PIPQ data structure includes a worker level and a leader level, the worker level includes a plurality of thread-local priority queues, and the leader level is used to maintain a global highest priority element index;

[0039] For the traffic selection policy configuration information, online traffic data of different time periods is assigned to multiple worker threads for parallel processing to generate a candidate traffic set local to each worker thread, wherein each worker thread is used to scan online traffic data of a specific time period or a specific partition;

[0040] Based on the candidate traffic set, the time freshness, business scenario representativeness and abnormal features obtained in advance are combined to calculate a priority score corresponding to each online traffic data, and the online traffic data is inserted into the worker-level thread-local priority queue in parallel according to the priority score to generate a filled PIPQ instance;

[0041] According to the filled PIPQ instance, the current highest priority element is periodically extracted from the worker-level thread-local priority queue to update the index in the leader level to generate a sorted PIPQ instance;

[0042] Based on the sorted PIPQ instance and the traffic selection quota table, the minimum value of the thread-local priority queue is iteratively deleted, and the highest priority traffic data of each traffic subcategory is extracted in turn according to the quota limit of each traffic subcategory until the quota requirement is met to generate the initial traffic use case set.

[0043] Optionally, based on the regression test case library and the Mock interface service set, the test tasks related to the regression test case library are tested in multiple threads in parallel to generate test result data, further comprising:

[0044] According to the regression test case library and the test requirements, the test tasks are prioritized to generate a test task priority model, wherein the test task priority model includes weight configuration information of business importance, historical failure rate, and execution time;

[0045] Based on the test task priority model, a PIPQ scheduler with a double-layer structure is initialized and an initial PIPQ scheduler instance is generated, and the PIPQ scheduler is used to manage and schedule the test tasks;

[0046] The use case priority score corresponding to each test case in the regression test case library is calculated, and the test case is inserted into the worker-level queue of the PIPQ scheduler as a test task according to the use case priority score to generate a filled PIPQ scheduler instance;

[0047] The system resource status and the test task quantity are evaluated to determine the optimal number of worker threads, and a test execution thread pool for parallel execution of test tasks is created accordingly;

[0048] Under the cooperation of the filled PIPQ scheduler instance and the test execution thread pool, the working thread extracts the test task with the highest priority from the PIPQ scheduler and executes the test task, and meanwhile, new high-priority test tasks can be dynamically inserted to collect the task execution results of the test tasks and generate an original test result set.

[0049] Optionally, the classified sampling processing of the online traffic data according to the test configuration data to generate the regression test case library further includes:

[0050] According to the interface configuration information and the traffic classification configuration information, the online traffic data is mapped to a multi-dimensional feature space to form a traffic feature space model, wherein each dimension in the traffic feature space model represents a key service feature;

[0051] Based on the traffic feature space model, a variable whose influence on the test coverage exceeds a preset influence threshold is identified as a test constraint variable for a constraint satisfaction problem;

[0052] Based on the test constraint variable and a preset system service rule, a test constraint relationship between the test constraint variables is determined, and the test constraint relationship includes a single-variable constraint and a multi-variable constraint;

[0053] According to the test constraint variable and the test constraint relationship, the online traffic data is mapped to a constraint variable space, and a representation of each piece of online traffic data in the constraint variable space is generated to generate a traffic data set in the constraint variable space;

[0054] The traffic data set and the test constraint relationship are classified and clustered by using a preset constraint satisfaction problem, a traffic subset satisfying different constraint combinations is identified, and a traffic distribution statistical table is generated;

[0055] Based on the initial traffic case set and the test constraint relationship, the coverage rate of the current initial traffic case set in the constraint variable space is evaluated, an insufficient coverage area table is generated, and the insufficient coverage area table and the test constraint relationship are solved by constraint to generate the supplementary traffic case set.

[0056] Optionally, the Mock system is optimized based on a symmetry breaking technique of directional spectrum partitioning, and the classified algorithm processing of the interface call information and the construction of the HTTP interface Mock service and the Dubbo interface Mock service are optimized, including:

[0057] perform dependency analysis on the third-party interface call information to construct an interface call dependency graph, wherein one node of the interface call dependency graph represents one third-party interface, an edge of the interface call dependency graph represents a call dependency relationship between the third-party interfaces, and a weight of the edge represents a call frequency or importance;

[0058] perform graph analysis on the interface call dependency graph to obtain a Laplacian matrix of the interface call dependency graph and corresponding eigenvalues and eigenvectors, and generate interface dependency features based on the Laplacian matrix, the eigenvalues and the eigenvectors;

[0059] identify symmetric structures and patterns in the interface call dependency graph based on the interface dependency features, and generate an interface symmetry analysis report through the symmetric structures and the patterns, the interface symmetry analysis report being used to indicate positions and roles of the third-party interfaces in the symmetric structures;

[0060] perform symmetry breaking clustering on the third-party interfaces according to the interface symmetry analysis report, so that third-party interfaces with similar symmetry features are aggregated into a logical group to generate a symmetrically aware interface classification result;

[0061] formulate a Mock strategy for each interface category with respect to the interface classification result, the Mock strategy including using a specified unified Mock template for an interface group with a symmetry higher than a preset symmetry threshold, performing a specified high-precision Mock on third-party interfaces on a key symmetry axis, and using a specified low-precision Mock for third-party interfaces on the edge of a symmetric structure, and generating the interface call information set;

[0062] based on the interface symmetry analysis report, implement a symmetric transformation response generation mechanism using a response conversion algorithm, when a request for a symmetric interface is received, perform symmetric transformation on an existing symmetric transformation response to generate a new symmetric transformation response.

[0063] To achieve the above object, the application further provides a regression testing system based on traffic playback and Mock technology, comprising:

[0064] a test configuration module configured to integrate the obtained interface configuration information of a to-be-tested system, third-party interface information, traffic classification configuration information and traffic selection strategy configuration information to form test configuration data;

[0065] a test case generation module configured to classify and sample online traffic data according to the test configuration data to generate a regression test case library;

[0066] The Mock service construction module is configured to extract all third-party interface call information from the regression test case library, classify and arrange the third-party interface call information through a preset interface classification and interception strategy, and construct a Mock service for a specified protocol type to generate a Mock interface service set.

[0067] The test execution module is configured to perform multi-thread parallel testing on a test task related to the regression test case library based on the regression test case library and the Mock interface service set, and generate test result data, wherein the test result data includes an execution result of a test case indicated in the regression test case library, and the execution result includes an interface return value, an execution state and performance data.

[0068] The result analysis module is configured to perform return value comparison and performance comparison on the test result data based on the regression test case library, and generate a test report.

[0069] The regression test method and system based on traffic playback and Mock technology provided by the present application can intelligently classify and sample online traffic data to obtain representative test cases, automatically construct Mock services of third-party interfaces to avoid dependence on actual third-party systems, and improve test efficiency through multi-thread parallel testing. The present application realizes intelligent screening of regression test cases and automatic Mock of third-party interfaces, and effectively improves the quality, efficiency and reliability of regression testing. BRIEF DESCRIPTION OF DRAWINGS

[0070] Figure 1 A flowchart of the regression test method based on traffic playback and Mock technology provided by the present application is shown.

[0071] Figure 2 A processing flowchart of the Mock service provided by the present application is shown.

[0072] Figure 3 A module structure diagram of the regression test system based on traffic playback and Mock technology provided by the present application is shown. DETAILED DESCRIPTION

[0073] The present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and not to limit the present application.

[0074] As shown in the figure, Figure 1 The present application provides a regression test method based on traffic playback and Mock technology, which includes the following steps S1 to S5.

[0075] Step S1: integrating the interface configuration information, third-party interface information, traffic classification configuration information and traffic selection strategy configuration information of the acquired to-be-tested system to form test configuration data.

[0076] Specifically, in the test preparation phase, first, the relevant configuration information of the to-be-tested system needs to be acquired, mainly including: interface configuration information, third-party interface information, traffic classification configuration information and traffic selection strategy configuration information of the to-be-tested system. The interface configuration information includes the URL path, protocol type, parameter structure, return value structure, etc. of the to-be-tested interface. The third-party interface information includes the interface URL, protocol type (such as HTTP, Dubbo, etc.), system to which it belongs, etc. The traffic classification configuration information includes the main classification field (such as the pid field), the sub-classification field (such as the status field), the number of test cases required for each classification, etc. The traffic selection strategy configuration information includes the time range of traffic selection (such as the last N days), the selection weight of each time period (such as 50% for the first day and 25% for the second day), the proportion of abnormal traffic (such as 20%), etc.

[0077] For example, the input / pid in the data field (JSON) in the traffic data can be configured as the use case classification, result / status as the sub-classification, and 1000 regression test cases are selected for each classification.

[0078] Step S2: classifying and sampling the online traffic data according to the test configuration data to generate a regression test case library.

[0079] In step S2, the online traffic data is classified and sampled according to the test configuration data to generate a regression test case library, which directly affects the quality and coverage of the final test.

[0080] Specifically, step S2 includes the following steps S2.1 to S2.5.

[0081] S2.1: According to the traffic classification configuration information and the traffic selection strategy configuration information, statistical analysis is performed on the online traffic data, and the traffic quantity distribution of each traffic category and traffic subcategory in the specified time range is calculated to generate a traffic distribution statistical table.

[0082] For example, the number of flows of each use case category in the past N days is calculated, and then the number of flows of each subcategory in each use case category is calculated. In step S2.1, statistical analysis is performed on online flow data according to flow classification configuration information and flow selection strategy configuration information. The main category field (such as the pid field) and the subcategory field (such as the status field) defined in the flow classification configuration information are read, and then the online flow data in a specified time range (such as the last N days) is scanned to count the number of flows of each subcategory under each main category. Through multi-dimensional data aggregation, the distribution of each flow category and flow subcategory in different time periods is calculated, and finally a detailed flow distribution statistical table is generated. For example, for the case where input / pid is configured as the main category and result / status is configured as the subcategory, the number of flows of different status values under each pid value is counted, and the number of flows is divided by day to form a complete flow distribution view.

[0083] S2.2: Perform proportional calculation on the flow distribution statistical table and the flow classification configuration information to determine the number of use cases to be selected for each flow subcategory in each time period, and generate a flow selection quota table.

[0084] For example, the number of flows of each subcategory is allocated according to the percentage of the number of flows of each subcategory in the number of flows of its use case category (for example, 1000). Next, proportional calculation is performed according to the flow distribution statistical table and the flow classification configuration information. The system reads the number of test use cases required for each category (such as 1000 regression use cases for each category) set in the flow classification configuration information, and then allocates the number of test use cases in proportion according to the flow proportion of each subcategory in the flow distribution statistical table. Specifically, the proportion of each subcategory in its main category is calculated, and then the total number of use cases in the main category is allocated to each subcategory in proportion. For example, if the flow proportions of subcategories A, B, and C under a main category are 15%, 30%, and 55% respectively, and 1000 use cases need to be selected for the main category, then subcategories A, B, and C need to select 150, 300, and 550 use cases respectively. This proportional allocation ensures that the distribution of test use cases is consistent with the distribution of actual online flows, improving the representativeness of testing. Through this step, a detailed flow selection quota table is generated, which specifies the number of use cases to be selected for each subcategory in each time period.

[0085] S2.3: According to the flow selection quota table and the flow selection strategy configuration information, use a preset time-weighted random sampling strategy to select a corresponding number of use cases from online flow data in different time periods to generate an initial flow use case set, wherein the time-weighted random sampling strategy is used to indicate that flow data with a time difference less than a preset time difference threshold is preferentially selected.

[0086] For example, according to the principle of selecting more use cases in more recent time, half of the use cases, i.e. 50%, are selected from the previous 1 day, the remaining half, i.e. 25%, are selected from the previous 2 days, and the remaining percentage of use cases is selected from the last day of configuration. In step S2.3, according to the traffic selection quota table and traffic selection strategy configuration information, a preset time-weighted random sampling strategy is used to select a corresponding number of use cases from online traffic data in different time periods. The time-weighted random sampling strategy preferentially selects traffic data in more recent time, as these data better reflect the current state of the system. According to the selection weights of each time period defined in the traffic selection strategy configuration information (such as 50% for the first day, 25% for the second day, etc.), use cases are extracted from traffic data in different time periods. For example, if 150 use cases need to be selected for a sub-category, then 75 use cases (50%) may be selected from data in the most recent day, 38 use cases (25%) may be selected from data in the second day, 19 use cases (12.5%) may be selected from data in the third day, and 18 use cases (12.5%) may be selected from data in the fourth day. Within each time period, traffic data that meets the conditions is randomly selected, but data with a time difference less than a preset time difference threshold is preferentially selected to ensure the timeliness of the test cases. Through this step, an initial traffic use case set is generated, which includes use cases of various categories selected according to the time weighting principle.

[0087] S2.4: Based on the initial traffic use case set and the traffic selection strategy configuration information, a preset proportion of abnormal traffic is selected to generate a supplementary traffic use case set to supplement abnormal traffic.

[0088] For example, 20% of abnormal traffic use cases (such as those with abnormal return status of the interface under test or those with abnormal return status of the third-party interface) are forcibly increased to enrich the regression test cases. Specifically, based on the initial traffic use case set and the traffic selection strategy configuration information, a preset proportion of abnormal traffic is selected to generate a supplementary traffic use case set to supplement abnormal traffic. Abnormal traffic refers to traffic whose execution result does not meet the normal expectation, such as traffic with an error code returned by the interface or traffic with abnormal third-party interface calls. Since these abnormal situations occur less frequently in actual operation, but are very important for robustness testing of the system under test, their proportion in the test cases needs to be deliberately increased. According to the abnormal traffic proportion defined in the traffic selection strategy configuration information (such as 20%), a certain number of abnormal traffic is additionally selected from online traffic data as a supplement. These abnormal traffic, together with the initial traffic use case set, form a more comprehensive test case set.

[0089] S2.5: According to the supplementary traffic use case set, data conversion, storage processing, and format conversion are performed on the initial traffic use case set to generate a regression test case library.

[0090] Finally, according to the supplementary traffic use case set, the initial traffic use case set is subjected to data conversion, storage processing and format conversion to generate the final regression test case library. The selected traffic data is converted into a standard test case format, including original request parameters, return results, calling time consumption and related third-party interface calling information, etc. These information is structured and stored in the regression test case library for subsequent test execution and result analysis. Through this step, the conversion from online traffic data to regression test case library is completed, providing a basis for subsequent Mock service construction and test execution.

[0091] In an optimized implementation, step S2.3 can also use PIPQ (Parallel Insertion Priority Queue) technology to further improve performance. PIPQ is a high-efficiency data structure, especially suitable for parallel insertion and priority sorting scenarios of large-scale data. The application of PIPQ in traffic selection is described in detail below.

[0092] In a preferred embodiment, step S2.3 can further include the following sub-steps S2.3.1 to S2.3.5.

[0093] S2.3.1: According to the traffic selection quota table, initialize the creation of a PIPQ data structure with a double-layer structure, and generate an initialized PIPQ instance from the PIPQ data structure, wherein the PIPQ data structure contains a worker level and a leader level, the worker level contains multiple thread-local priority queues, and the leader level is used to maintain the index of the global highest priority element.

[0094] In step S2.3.1, according to the traffic selection quota table, a PIPQ data structure with a double-layer structure is initialized and created, and an initialized PIPQ instance is generated. The double-layer structure of PIPQ includes a worker level and a leader level. The worker level contains multiple thread-local priority queues, each queue corresponding to a worker thread, which can independently perform insertion operations, avoiding lock contention between threads; the leader level maintains the index of the global highest priority element, ensuring that the system can quickly access the element with the highest priority. Through the design of this double-layer structure, PIPQ can support high-concurrency data insertion and efficient priority element access at the same time, which is very suitable for processing large-scale traffic data.

[0095] S2.3.2: According to the traffic selection strategy configuration information, the online traffic data of different time periods is allocated to multiple worker threads for parallel processing to generate multiple candidate traffic sets local to the worker threads, wherein each worker thread is used to scan the online traffic data of a specific time period or a specific partition.

[0096] In step S2.3.2, based on the traffic selection strategy configuration information, online traffic data from different time periods are allocated to multiple worker threads for parallel processing. Each worker thread is responsible for scanning online traffic data within a specific time period or partition, working independently without interference. For example, data from the most recent N days can be allocated to different worker threads by day, or data from the same day can be allocated to different worker threads according to a certain partition key (such as the hash value of the user ID). This parallel processing method greatly improves the efficiency of data scanning and processing, especially when processing large-scale online traffic data, significantly reducing processing time. Through this step, multiple candidate traffic sets are generated locally for each worker thread, and each set contains a subset of potential test cases.

[0097] S2.3.3: Based on the candidate traffic set, combined with the pre-acquired time freshness, business scenario representativeness and abnormal characteristics, calculate the priority score corresponding to each online traffic data, and insert the online traffic data into the worker-level thread local priority queue in parallel according to the priority score to generate a filled PIPQ instance.

[0098] In step S2.3.3, based on the candidate traffic set of each worker thread, and combined with pre-acquired factors such as time freshness, business scenario representativeness, and anomaly characteristics, a priority score is calculated for each online traffic data. It should be noted that the priority score is a comprehensive rating reflecting the value of the traffic data as a test case. The calculation formula can be expressed as: Priority Score = w1 * Time Freshness Score + w2 * Business Scenario Representativeness Score + w3 * Anomaly Characteristic Score, where w1 is the weighting coefficient for time freshness, w2 is the weighting coefficient for business scenario representativeness, and w3 is the weighting coefficient for anomaly characteristics. These can be configured according to testing needs. For example, if more emphasis is placed on testing the latest business scenarios, the value of w1 can be increased; if more emphasis is placed on the system's anomaly handling capabilities, the value of w3 can be increased. After calculating the priority score, each traffic data is inserted in parallel into the thread-local priority queue at the PIPQ worker level. Each worker thread only operates on its own local queue, avoiding lock contention. Through this step, a populated PIPQ instance is generated, containing traffic data of each category sorted by priority.

[0099] S2.3.4: Based on the filled PIPQ instance, periodically extract the current highest priority element from the worker-level thread-local priority queue to update the index in the leader level, and generate a sorted PIPQ instance.

[0100] In step S2.3.4, according to the filled PIPQ instance, the current highest priority element is periodically extracted from the worker-level thread-local priority queue to update the index in the leader level. This process is the key to PIPQ to keep the global highest priority element accessible. The head elements (i.e., the highest priority elements in each queue) of all worker queues are scanned periodically (e.g., every 100 milliseconds) to find the global highest priority element, and the index in the leader level is updated. This periodic update mechanism balances real-time performance and performance overhead, avoiding the high overhead of global update after each insertion operation. Through this step, the sorted PIPQ instance is generated, and the global highest priority element can be quickly accessed.

[0101] S2.3.5: Based on the sorted PIPQ instance and the traffic selection quota table, iteratively delete the minimum value of the thread-local priority queue, and extract the highest priority traffic data of each traffic subcategory in turn according to the quota limit of each traffic subcategory, until the quota requirement is met, and generate the initial traffic use case set.

[0102] Optionally, based on the sorted PIPQ instance and the traffic selection quota table, the formal selection of test cases begins. According to the quota limit of each traffic subcategory, the highest priority traffic data of each subcategory is extracted in turn. Specifically, the delete-min operation is iteratively performed to delete and return the current highest priority element from the PIPQ, and if the element belongs to a subcategory that has not reached the quota, it is added to the initial traffic use case set; otherwise, the next highest priority element is searched. This process will continue until all subcategories have reached the quota requirement or all available traffic data have been traversed. In this way, the highest priority traffic data in each subcategory can be selected as test cases to meet the quota requirement, ensuring the quality and representativeness of the test cases.

[0103] Therefore, the embodiment completes the intelligent screening of online traffic data and generates a regression test case library that meets the actual traffic distribution, has good timeliness and representativeness. This PIPQ-based implementation scheme is particularly suitable for processing large-scale online traffic data and can significantly improve the efficiency and quality of traffic screening, providing a solid foundation for subsequent regression testing.

[0104] In another preferred embodiment, step S2 can further include steps S2.6 to S2.11.

[0105] S2.6: According to the interface configuration information and the traffic classification configuration information, map the online traffic data to a multi-dimensional feature space to form a traffic feature space model, wherein each dimension in the traffic feature space model represents a key service feature.

[0106] In step S2.6, the online traffic data is mapped to a multi-dimensional feature space according to the interface configuration information and the traffic classification configuration information, forming a traffic feature space model. Therefore, the embodiment identifies and extracts key business features in the traffic data, such as user types, operation types, resource types, and business states, and represents each piece of traffic data as a point in a multi-dimensional space. For example, for an interface of an e-commerce system, user levels, product categories, payment methods, and order states may be extracted; for an interface of a financial system, transaction types, amount ranges, risk levels, and processing results may be extracted. This feature extraction usually combines the knowledge of domain experts to ensure that the selected features can fully reflect the essential properties of the business. Thus, a multi-dimensional feature space model is established, in which each dimension represents a key business feature, providing a basis for subsequent constraint analysis and use case generation.

[0107] S2.7: Based on the traffic feature space model, identify variables whose impact on test coverage exceeds a preset impact threshold as test constraint variables for the constraint satisfaction problem.

[0108] In step S2.7, based on the traffic feature space model, identify variables whose impact on test coverage exceeds a preset impact threshold as test constraint variables for the constraint satisfaction problem. The purpose of this step is to find truly important variables among numerous features to reduce the complexity of the problem. Through statistical analysis or machine learning methods, evaluate the impact of each feature on test coverage, such as using information gain, correlation analysis, or feature importance scoring techniques. Then, select features whose impact exceeds a preset threshold (such as contributing more than 80% of the information) as test constraint variables. These variables are usually fewer in number (such as 3-5) but can well represent the core business logic of the system. For example, in an e-commerce system, user types, product categories, and payment methods may be selected as test constraint variables; in a financial system, transaction types, amount intervals, and risk levels may be selected as test constraint variables.

[0109] S2.8: Based on the test constraint variables and the preset system business rules, determine the test constraint relationships between the test constraint variables, including single-variable constraints and multi-variable constraints.

[0110] The test constraint relationship between the test constraint variables is determined based on the test constraint variables and the preset system business rules, aiming to capture various rules and restrictions in the business logic and build a complete constraint relationship model. The test constraint relationship mainly includes two types: single variable constraint and multi-variable constraint. The single variable constraint refers to the limitation on the value of a single variable, such as the variable must be within a certain range, can only take a few specific values, etc. The multi-variable constraint refers to the interdependence between variables, such as the value of a variable will affect the possible value range of another variable, two variables must satisfy a certain functional relationship, etc. These constraint relationships usually come from the business rules, regulatory requirements or technical limitations of the system. For example, in an e-commerce system, there may be a multi-variable constraint that "VIP users must support credit payment when purchasing luxury goods"; in a financial system, there may be a multi-variable constraint that "high-value transactions must undergo senior risk assessment". Therefore, the embodiment establishes a complete constraint relationship model, providing a rule basis for subsequent use case generation.

[0111] S2.9: According to the test constraint variables and the test constraint relationship, the online traffic data is mapped to the constraint variable space, and the representation of each online traffic data in the constraint variable space is generated, and a traffic data set in the constraint variable space is generated.

[0112] It should be noted that according to the test constraint variables and the test constraint relationship, the online traffic data is mapped to the constraint variable space, and the representation of each online traffic data in the constraint variable space is generated, so that the original multi-dimensional feature space is simplified to a space containing only key constraint variables, making subsequent analysis and calculation more efficient. The attribute values related to the test constraint variables in each traffic data are extracted to generate a simplified representation. For example, if the test constraint variables include user type, product category and payment method, the values of these three attributes are extracted from each traffic data to form a triple representation of (user type, product category, payment method). This mapping not only reduces the dimensionality of the data, but also makes the verification and application of the constraint relationship more direct and efficient. Therefore, the embodiment generates a traffic data set in the constraint variable space, providing input data for subsequent classification and clustering.

[0113] S2.10: Adopting a preset constraint satisfaction problem, the traffic data set and the test constraint relationship are classified and clustered, and traffic subsets satisfying different constraint combinations are identified, and a traffic distribution statistics table is generated.

[0114] It should be noted that the preset constraint satisfaction problem algorithm is used to classify and cluster the flow data set in the constraint variable space and the test constraint relationship, and identify the flow subsets that meet different constraint combinations. In this regard, the flow data is effectively organized and classified according to the constraint relationship. The udCSP (unbounded domain constraint satisfaction problem) solving techniques such as the FPT algorithm in the parameterized complexity theory, the polymorphism theory, etc. are used to efficiently classify the flow data. Specifically, the flow subsets that meet different constraint combinations are identified, such as "VIP user + luxury + credit payment", "ordinary user + daily necessities + cash payment", etc. For each constraint combination, the number distribution thereof in the flow data is counted, and a detailed flow distribution statistics table is generated. This statistics table not only reflects the actual use of the current system, but also provides data basis for subsequent use case selection.

[0115] S2.11: Based on the initial flow use case set and the test constraint relationship, evaluate the coverage of the current initial flow use case set in the constraint variable space, generate an insufficient coverage area table, and perform constraint solving on the insufficient coverage area table and the test constraint relationship to generate the supplementary flow use case set.

[0116] In this embodiment, based on the initial flow use case set and the test constraint relationship, the coverage of the current use case set in the constraint variable space is evaluated, an insufficient coverage area table is generated, and constraint solving is performed on the insufficient coverage area table and the test constraint relationship to generate a supplementary flow use case set, aiming to ensure that the test cases can comprehensively cover various business scenarios, especially those boundary conditions that are less likely to occur in actual traffic but are very important to system stability. The distribution of the initial flow use case set in the constraint variable space is analyzed, and the insufficient coverage areas are identified, such as insufficient number of use cases for certain constraint combinations or complete absence of use cases. Then, using constraint solving techniques, test cases that meet these constraint combinations are constructed to supplement the insufficient coverage areas. These supplementary cases may come from rare cases in historical data, or may be automatically generated according to the constraint relationship. Therefore, this example generates a more comprehensive supplementary flow use case set, which together with the initial flow use case set constitutes a complete regression test case library.

[0117] Therefore, this embodiment realizes advanced flow classification and test case generation based on udCSP. Compared with traditional methods based on simple rules or random sampling, this embodiment can better understand the business logic, generate more representative and coverage test cases, and significantly improve the quality and effectiveness of regression testing.

[0118] Step S3: Extract all third-party interface call information from the regression test case library, classify and organize the third-party interface call information through a preset interface classification and interception strategy, and construct a Mock service for a specified protocol type to generate a Mock interface service set.

[0119] As Figure 2 shown, when the system under test calls a third-party interface, the request is routed to the Mock service, which looks up the matching call record in the interface call information set according to the request information and returns the corresponding response content. Specifically, this step S3 can further include the following steps S3.1 to S3.6.

[0120] S3.1: Perform data analysis on the regression test case library and the third-party interface information to extract all third-party interface call information, including request parameters, return results, and call time.

[0121] For example, classify and organize the third-party interface call information in the traffic regression test case according to the type of the Mock interface, such as summarizing the third-party interface call information of external HTTP interface calls to form a set, summarizing the third-party interface call information of Dubbo interface calls to form a set, and so on.

[0122] In step S3.1, the regression test case library and the third-party interface information are analyzed to extract the call information of each third-party interface. Thus, all third-party interface-related call data is obtained from the selected test cases, preparing for the subsequent Mock service construction. Each record in the regression test case library is analyzed to identify and extract all third-party interface calls involved, including request parameters, return results, and call time information. This process usually needs to be combined with third-party interface information configuration to ensure that all Mocked interface calls can be accurately identified. For example, if the test case contains calls to payment gateways, risk control systems, and short message service third-party systems, the detailed information of these calls is extracted. It should be noted that if the traffic information and the third-party interface call information are stored separately, they need to be correctly associated using thread IDs or other association identifiers to ensure that the call information of the Mocked interface corresponding to the traffic regression test case can be obtained. Therefore, this embodiment obtains a complete set of third-party interface call information, providing a data foundation for subsequent classification and Mock service construction.

[0123] S3.2: Classify and process the third-party interface call information according to protocol type and system, generate multiple interface call information sets, including HTTP interface call information set, Dubbo interface call information set, and other types of interface call information set.

[0124] In step S3.2, third-party interface call information is categorized according to protocol type and system, generating multiple interface call information sets. This aims to effectively organize the interface call information, facilitating the application of different Mock strategies for different types of interfaces. Specifically, it is first categorized by protocol type, such as HTTP interfaces, Dubbo interfaces, and WebService interfaces, because different protocol types require different interception and simulation technologies. Then, within each protocol type, it is further categorized by the third-party system it belongs to, such as payment systems, risk control systems, and SMS systems, because interfaces from the same system usually have similar call patterns and return formats. This two-level categorization method allows the system to manage interface call information more precisely, improving the accuracy and efficiency of the Mock service. Therefore, this embodiment generates multiple interface call information sets, including HTTP interface call information sets, Dubbo interface call information sets, and other types of interface call information sets, providing a classification basis for subsequent Mock service construction.

[0125] For example, the aggregated collection of third-party API call information for each category should be further categorized according to the third-party system. If traffic information and third-party API call information are stored separately, it is essential to associate the two using thread IDs in order to obtain the call information of the API to be mocked corresponding to the traffic regression test case.

[0126] S3.3: Use a preset Web filter algorithm to perform request interception, parameter matching and response simulation on the HTTP interface call information set to build an HTTP interface Mock service.

[0127] For example, an automated testing system can implement a web filter to filter all interfaces of all third-party systems using HTTP types and mock them. Using the compiled set of third-party interface call information for HTTP types, when the web filter receives a request, it retrieves the request type, URL, header information, input parameter information, and body information. This information is then compared with the set of third-party interface call information to find matching traffic call information. Based on the return value and call duration of the traffic call information, the HTTP interface is returned.

[0128] In step S3.3, the HTTP interface call information set is subjected to request interception, parameter matching and response simulation using a preset Web filter algorithm to construct an HTTP interface Mock service. HTTP is one of the most commonly used interface protocols, and many third-party systems provide HTTP interfaces for external calls, so effective Mock of the HTTP interface is crucial. A Web filter is implemented in the automated testing environment, which can intercept all HTTP requests sent to the third-party system. When an HTTP request is received, the filter obtains the request method (GET, POST, etc.), URL path, header information, query parameters and request body content, and then searches for a matching record in the HTTP interface call information set. The matching process usually adopts a multi-level matching strategy, first screening according to the URL path and request method, and then performing accurate matching according to the header key field and request parameters. After finding the matching record, the response of the HTTP interface is simulated according to the return result and call time in the record, and if necessary, a certain delay is simulated to restore the real calling experience. If no completely matching record is found, the most similar matching or default response strategy can be used. Therefore, the Mock service constructed in this embodiment can simulate various HTTP interface behaviors, effectively solving the problem of dependence on third-party HTTP systems.

[0129] S3.4: The Dubbo interface call information set is subjected to request interception, parameter matching and response simulation using a preset Dubbo filter algorithm to construct a Dubbo interface Mock service.

[0130] For example, a Dubbo filter is implemented in the automated testing system to filter all interfaces of all third-party systems of the Dubbo type and Mock them. Using the above-mentioned third-party interface call information set of the Dubbo type, when the Dubbo filter receives a request call, the API, parameter information and other related information of the request are obtained, compared with the third-party interface call information set, the matching traffic call information is found, and the Dubbo interface is returned according to the return value and call time of the traffic call information.

[0131] Specifically, a preset Dubbo filter algorithm is used to perform request interception, parameter matching, and response simulation on the Dubbo interface call information set to build a Dubbo interface Mock service. Dubbo is a popular RPC framework and is widely used in many enterprise-level applications, so effective Mock of Dubbo interfaces is also very important. In an automated testing environment, a Dubbo filter is implemented, which can intercept all Dubbo calls to third-party systems. When a Dubbo call request is received, the filter obtains the interface name, method name, version number, and request parameters of the request, and then searches for a matching record in the Dubbo interface call information set. The matching process usually first screens according to the interface name and method name, and then performs accurate matching according to the request parameters. Since the parameters of Dubbo interfaces are usually complex objects, deep comparison or ignoring of certain non-key fields may be required. After finding the matching record, the response of the Dubbo interface is simulated according to the return result and call time in the record. If the call may throw an exception, the corresponding exception behavior can be simulated. Through this step, a Mock service that can simulate various Dubbo interface behaviors is built, effectively solving the problem of dependence on third-party Dubbo systems.

[0132] S3.5: Using the interception algorithm related to the other type of interface call information set, performing request interception, parameter matching, and response simulation on the other type of interface call information set to build an other type of interface Mock service.

[0133] For example, for other types of third-party interface Mock, referring to the Mock of HTTP type interfaces and Dubbo type interfaces, similar filter technology is also used for other types of third-party interfaces to intercept call requests, identify request addresses, request headers, and request parameters, and match them with the sorted third-party interface call information set of this type to find the return value and call time of the appropriate call traffic information, and then return the original time and original value.

[0134] Specifically, the interception algorithm related to the other type interface call information set is adopted to perform request interception, parameter matching, and response simulation on the other type interface call information set to construct the other type interface Mock service. In addition to HTTP and Dubbo, other types of interfaces such as WebService, gRPC, custom RPC, and the like can also need to be processed. For these interfaces, similar filter technology is adopted, and a corresponding interception mechanism is implemented for each protocol type. Although the specific interception implementation can vary depending on the protocol type, the basic principle is similar: intercept the call request, identify the request characteristics, find a matching record in the pre-prepared interface call information set, and then simulate the response behavior according to the record. For some special protocols or non-standard interfaces, custom interception components can need to be developed, or protocol adapters can be used to convert them into standard protocols for processing. Through this step, Mock services that can simulate the behavior of various special type interfaces are constructed, ensuring the integrity and independence of the regression test environment.

[0135] S3.6: Deploy the HTTP interface Mock service, the Dubbo interface Mock service, and the other type interface Mock service into the test environment and organize them into a Mock interface service set.

[0136] In step S3.6, the HTTP interface Mock service, the Dubbo interface Mock service, and the other type interface Mock service are deployed into the test environment and organized into a Mock interface service set. The purpose of this step is to integrate various Mock services into a unified service set and ensure that they can run normally in the test environment. The various Mock services constructed in the foregoing are deployed to appropriate locations in the test environment, such as deploying the HTTP Mock service into a Web container, deploying the Dubbo Mock service into a Dubbo container, and the like. Then, the network environment of the system under test is configured, and requests originally directed to the real third-party system are redirected to these Mock services. This usually involves modifying DNS configurations, network routing or proxy settings, or directly modifying the configuration files of the system under test. In addition, a series of verification tests need to be performed to ensure that the Mock services can correctly receive and respond to requests, and that the system under test can correctly access these Mock services. Therefore, the embodiment completes the deployment and configuration of the Mock interface service set, creating an independent and controllable test environment for subsequent regression test execution.

[0137] Therefore, the embodiment realizes automatic Mock of various third-party interfaces. Compared with a traditional manual configuration Mock return value method, the automatic Mock method based on real traffic records has higher accuracy and coverage, can more realistically simulate the behavior of a third-party system, and greatly improves the quality and efficiency of regression testing. Meanwhile, since the actual third-party system is avoided, the embodiment also reduces testing costs, reduces dependence on external environments, enables regression testing to be performed in a completely isolated environment, and improves testing reliability and repeatability.

[0138] In a preferred embodiment, the Mock system can be optimized based on a symmetry breaking technique of directional spectrum division in step S3. The optimization of the interface call information classification algorithm processing and the construction of the HTTP interface Mock service and the Dubbo interface Mock service includes the following steps S3.7 to S3.12.

[0139] S3.7: dependency relationship analysis is performed on the third-party interface call information, and an interface call dependency graph is constructed, wherein a node of the interface call dependency graph represents a third-party interface, an edge of the interface call dependency graph represents a call dependency relationship between the third-party interfaces, and a weight of the edge represents a call frequency or importance;

[0140] In step S3.7, dependency relationship analysis is performed on the third-party interface call information, and an interface call dependency graph is constructed to reflect the complex call relationship and dependency structure between the third-party interfaces. Specifically, first, each record in the regression test case library is analyzed to identify the order and association of all third-party interface calls, determine which interface calls trigger other interface calls, and which interface calls have a prior dependency. Then, a directed weighted graph structure is constructed, wherein each node represents a third-party interface, a directed edge represents a call dependency relationship, and the weight of the edge represents a call frequency or business importance. For example, if in the test case, the call of interface A often triggers the call of interface B, then there is a directed edge from A to B in the graph, and the weight value is proportional to the call association strength of the two. This graph structure can intuitively show the complex call network of the third-party interfaces and provide a data basis for subsequent spectrum analysis. Through this step, a comprehensive interface call dependency graph is generated, which reveals the internal call mode of the third-party interfaces in the business system.

[0141] S3.8: graph spectrum analysis is performed on the interface call dependency graph to obtain a Laplacian matrix of the interface call dependency graph and corresponding eigenvalues and eigenvectors, and interface dependency features are generated based on the Laplacian matrix, the eigenvalues, and the eigenvectors.

[0142] In step S3.8, the interface call dependency graph is subjected to graph analysis, and the Laplacian matrix and its eigenvalues and eigenvectors are calculated. This step introduces the spectral graph theory in complex network analysis, and through mathematical transformation of the graph structure, hidden patterns and characteristics in the network are mined. Specifically, first, the Laplacian matrix L = D - A is constructed according to the interface call dependency graph, where D is the degree matrix (the degree of each node on the diagonal line) and A is the adjacency matrix (representing the connection relationship between nodes). Then, the eigenvalues λ and the corresponding eigenvectors v of this Laplacian matrix are calculated, which satisfy Lv = λv. Among them, these eigenvalues and eigenvectors contain the essential characteristics of the graph structure, especially the second smallest eigenvalue (i.e. Fiedler value) and its corresponding eigenvector, which are of great significance to reveal the community structure and symmetry in the graph. Based on the results of the Laplacian matrix and eigenvalue decomposition, the interface dependency features are generated, which are a set of mathematical descriptions that can accurately express the topological structure characteristics of the interface call network. Through this step, the complex interface dependency relationship is transformed into quantifiable mathematical features, laying the foundation for subsequent symmetry recognition.

[0143] S3.9: identifying the symmetric structure and pattern in the interface call dependency graph based on the interface dependency features, and generating an interface symmetry analysis report through the symmetric structure and the pattern, the interface symmetry analysis report being used to indicate the position and role of each third-party interface in the symmetric structure.

[0144] In step S3.9, the symmetric structure and pattern in the interface call dependency graph are identified based on the interface dependency features. This step uses the symmetry theory in graph theory to find the symmetric elements and invariant structures in the network by analyzing the distribution and value range of the eigenvectors. First, the zero components and sign changes of the eigenvectors are analyzed, which often indicate the symmetry axes or dividing lines in the graph. Then, the node sets with similar eigenvector components are found, which may play similar roles or have similar connection patterns in the network. For example, a group of payment interfaces may form a symmetric substructure in the call network, or a group of user authentication interfaces may occupy a symmetric position in the network. Based on these analyses, a detailed interface symmetry analysis report is generated, which contains the position and role of each third-party interface in the symmetric structure, such as whether it is located on the symmetry axis, whether it belongs to the symmetric subgroup, and the strength of the symmetry, etc. This report not only provides structural insights into the interface call network, but also provides decision-making basis for subsequent interface classification and Mock strategy formulation. Through this step, the hidden symmetry in the interface call network is revealed, which often reflects the inherent rules and patterns in the business logic.

[0145] S3.10: According to the interface symmetry analysis report, symmetry breaking clustering is performed on the third-party interfaces, so that third-party interfaces with similar symmetry characteristics are aggregated into a logical group, and a symmetry-aware interface classification result is generated.

[0146] In step S3.10, according to the interface symmetry analysis report, symmetry breaking clustering is performed on the third-party interfaces. According to the symmetry breaking theory in quantum physics, by identifying and breaking the symmetry in the system, effective analysis and processing of complex systems are achieved. Specifically, first, the interfaces are preliminarily clustered according to the distribution of feature vectors, and interfaces with similar feature vector components are grouped together. Then, the symmetry characteristics of these preliminary clusters are further analyzed, such as whether a complete symmetry group is formed, how strong the symmetry is, etc. For those interface groups with similar symmetry characteristics, they are aggregated into a logical group. These interfaces usually play similar roles or implement similar functions in the business logic. This symmetry-based clustering method is different from the traditional similarity-based clustering method. It can capture deeper structural associations between interfaces, not only considering the characteristics of the interfaces themselves, but also considering the position and role of the interfaces in the entire call network. Through this step, a symmetry-aware interface classification result is generated. This classification can better reflect the essential characteristics and logical relationships of the interfaces, and provide a more scientific basis for subsequent Mock strategy formulation.

[0147] S3.11: For the interface classification result, formulate a Mock strategy for each interface category, which includes using a specified unified Mock template for interface groups with symmetry higher than a preset symmetry threshold, performing a specified high-precision Mock on third-party interfaces on the key symmetry axis, and using a specified low-precision Mock for third-party interfaces on the edge of the symmetry structure, and generating the interface call information set.

[0148] For the interface classification results, develop corresponding Mock strategies for each interface category. This step takes advantage of the symmetry features identified earlier to design differentiated Mock processing solutions for different types of interfaces. Specifically, according to the position and role of the interface in the symmetric structure, different Mock strategies are adopted: for interface groups with symmetry higher than the preset threshold, a unified Mock template is used, as these interfaces usually have similar input-output patterns and business semantics; for third-party interfaces located on the key symmetry axis, high-precision Mock is performed to ensure that the simulated behavior of these core interfaces is highly consistent with the real behavior; for third-party interfaces located on the edge of the symmetric structure, low-precision Mock may be used to save computing resources. This differentiated Mock strategy not only improves the overall simulation efficiency, but also ensures the simulation quality of key interfaces. For example, for a group of payment callback interfaces, it may be identified that they form a highly symmetric structure in the calling network, so a unified Mock template can be used, and only a small number of parameters need to be replaced to simulate the behavior of different interfaces; while for core payment interfaces located on the symmetry axis, high-precision Mock is used to ensure the accuracy of the behavior simulation. Through this step, Mock strategies are generated for different interface categories, achieving rational allocation of resources and optimization of simulation effect.

[0149] S3.12: Based on the interface symmetry analysis report, a response conversion algorithm is used to implement a symmetric transformation response generation mechanism. When a request for a symmetric interface is received, the existing symmetric transformation response is symmetrically transformed to generate a new symmetric transformation response.

[0150] In this embodiment, based on the interface symmetry analysis report, a response conversion algorithm is used to implement a symmetric transformation response generation mechanism. This step is a further application of the symmetry breaking technique in Mock response generation. Through symmetric transformation operations, the system can generate diversified Mock responses based on limited response samples. When a request for a certain symmetric interface is received, if no completely matching record can be found in the existing interface call information set, the response record of the symmetrically corresponding interface is found, and then the response is symmetrically transformed to generate a new response. For example, if it is identified that interface A and interface B form a symmetric structure in the calling network, and their request parameters also have corresponding symmetric relationships, when a request for interface A is received without a matching record, the response record of interface B can be found, and through specific conversion rules (such as replacing specific fields, converting data formats, etc.), it can be converted into a response suitable for interface A. This symmetric transformation response generation mechanism greatly expands the coverage of the Mock service, can handle more unseen request situations, and improves the flexibility and robustness of the Mock service. Through this step, the response generation capability based on symmetry is realized, which is an advanced feature that traditional Mock services do not have.

[0151] Therefore, the embodiment utilizes the symmetry breaking technology based on directional spectrum division, applies advanced concepts in complex network theory and quantum physics to the field of software testing, and realizes more intelligent and efficient Mock service construction by in-depth analysis of the structural characteristics of the interface call network. The embodiment not only can identify deep associations between interfaces, but also can generate more accurate and comprehensive Mock responses using these associations, greatly improving the quality and efficiency of regression testing. Compared with traditional Mock methods based on simple rules or one-to-one matching, the embodiment can handle more complex business scenarios and cope with more unknown situations, and is a more advanced and intelligent Mock technology.

[0152] It should be noted that the embodiment can generate infinite possible responses based on limited sample data through symmetry breaking clustering and symmetric transformation response generation, which greatly reduces the data requirements and maintenance costs of Mock services. For interfaces with low call frequency but high business importance, traditional methods may not be able to provide effective Mock due to insufficient samples, while the embodiment can generate reasonable Mock responses based on limited samples through symmetry analysis and transformation, ensuring the comprehensiveness and effectiveness of testing.

[0153] In addition, the Mock strategy based on symmetry in the embodiment can also optimize the allocation of system resources, and adopt Mock schemes with different precisions for interfaces with different importance, thereby reducing the computational and storage overhead while ensuring the testing quality. This fine-grained resource allocation strategy enables the system to handle larger-scale interface sets and support more complex business scenario testing, further improving the efficiency and economy of regression testing.

[0154] Step S4: Based on the regression test case library and the Mock interface service set, multi-threaded parallel testing is performed on the test tasks related to the regression test case library, and test result data is generated, including the execution results of the test cases indicated in the regression test case library.

[0155] Specifically, the step S4 can further include the following steps S4.1 to S4.5.

[0156] S4.1: The test cases contained in the regression test case library are assigned as a plurality of test tasks that can be executed in parallel.

[0157] In step S4.1, the test cases contained in the regression test case library are assigned as multiple test tasks that can be executed in parallel. Therefore, a large number of test cases are reasonably organized for efficient parallel processing. Specifically, the characteristics of each test case, such as execution time, resource requirements, dependency relationships, etc., are first analyzed, and then they are divided into multiple independent test tasks. The principle of division is to ensure the independence between tasks and the balance of resource use, avoiding mutual interference and resource competition between test tasks. For example, test cases can be grouped according to interface type, business scenario, or estimated execution time to ensure that the execution time of each group of test tasks is similar, reducing the overall waiting time caused by a single long task. For test cases that have dependency relationships, they are assigned to appropriate execution sequences to ensure that the dependency relationships are met. Through this intelligent task allocation strategy, good conditions are created for subsequent parallel execution, improving the overall test efficiency.

[0158] S4.2: When it is detected that the to-be-tested system and the Mock interface service set are both in a ready state based on the test tasks and the test environment, an environment ready confirmation result is output, which indicates that the test environment meets the preset execution conditions.

[0159] Specifically, when it is detected that the to-be-tested system and the Mock interface service set are both in a ready state based on the test tasks and the test environment, an environment ready confirmation result is output. Therefore, it is ensured that the test environment meets the preset execution conditions, avoiding starting the test in an imperfect environment, resulting in invalid test results. A comprehensive check is performed on the test environment to verify whether the to-be-tested system has been correctly deployed and started, and whether the configurations meet the test requirements; at the same time, it is also checked whether the Mock interface service set is ready, which can correctly respond to the interface calls in the test process. This check usually includes sending a series of probe requests to verify the response status of each component, and checking system logs and monitoring indicators to confirm that the to-be-tested system is running normally. Only when all necessary components are in a normal working state, the environment ready confirmation result is output, indicating that the test environment meets the conditions for starting the test. This strict environment verification mechanism ensures the effectiveness of the test and the reliability of the results, avoiding test failures and result deviations caused by environmental problems.

[0160] S4.3: In response to the environment ready confirmation result, multiple test tasks are called in multiple threads in parallel, and each thread executes a test case, collects the execution results of each test case, including interface return values, execution status and performance data, and generates raw test result data.

[0161] For example, use the smart filtered regression test cases, call the to-be-tested interface of the to-be-tested system, multi-thread parallel call, each thread runs a test case, each test case runs, stores the call return result and time-consuming information to the regression test case library, and marks the state as "called".

[0162] In this embodiment, in response to the environment readiness confirmation result, a plurality of test tasks are multi-threaded and called in parallel, and each thread executes a test case. The execution results of each test case, including interface return value, execution state and performance data, are collected to generate original test result data. Among them, an efficient parallel processing strategy is adopted, which greatly improves the execution efficiency of the test. Specifically, a plurality of worker threads are created, and each thread is responsible for executing a test case. These threads can run in parallel, fully utilizing the multi-core processing capability of the system. Each thread will call the to-be-tested interface of the to-be-tested system, pass in the request parameters defined in the test case, then wait for the system response, record the return result and execution time-consuming information, etc. These information will be stored in real time to the original test result data, and the execution state of the test case is marked as "called". Optionally, a series of performance indicators such as response time, CPU usage, memory occupation, etc. are collected, which can help to evaluate the performance of the system and identify potential performance bottlenecks. Through this multi-thread parallel execution mode, a large number of test cases can be executed in a short time, significantly improving the efficiency and economy of the test.

[0163] S4.4: Based on the original test result data, identify the abnormal test cases that execute timeout or failure, and retest the abnormal test cases. Combine the original test result data and the retest result data to generate compensation test result data.

[0164] For example, for the cases that do not reach the "called" state, reinitiate test calls for compensation.

[0165] In step S4.4, based on the original test result data, the abnormal test cases that execute timeout or fail are identified, and the abnormal test cases are retested, and the compensation test result data is generated by combining the original test result data and the retest result data. Thus, the abnormal situation in the test process is handled, and the reliability and integrity of the test result are improved. Analyze the original test result data, identify those test cases that execute timeout (such as execution time exceeding a preset threshold) or fail (such as interface returning error code, throwing exception, etc.). For these abnormal cases, retest is arranged to exclude the influence of accidental errors or environmental fluctuations. The retest may use different strategies, such as increasing the timeout threshold, replacing the execution thread, adjusting the execution order, etc., to improve the success rate of the test. The results of the retest will be analyzed together with the original test results, and if the retest is successful, the original failure may be determined as an accidental error; if the retest still fails, it may be marked as a stable failure. These analysis results will form the compensation test result data, providing a basis for subsequent result analysis and problem diagnosis. Through this retry and compensation mechanism, the accuracy and reliability of the test result can be improved, and false failure reports can be reduced.

[0166] S4.5: Data conversion standardization processing and format conversion are performed on the compensation test result data to generate the test result data.

[0167] In step S4.5, the compensation test result data is processed by data conversion standardization and format conversion to generate the test result data. Therefore, the original test result data is processed into a standard, easy-to-analyze and display format. The compensation test result data is cleaned and standardized, redundant information is removed, data format is corrected, field name and value range are unified, and data consistency and integrity are ensured. Then, the processed data is converted into a specified result format, such as JSON, XML, CSV, etc., to facilitate subsequent data analysis and result display. This standardization processing and format conversion not only improves the readability and usability of the test result, but also creates conditions for subsequent automated analysis and report generation. Through this step, the test result data with uniform format and clear structure is generated, which facilitates the analysis and interpretation of the test result.

[0168] Therefore, the embodiment improves the overall test efficiency through task allocation, and then ensures the effectiveness of the test and the reliability of the result through environment verification, avoids test failure and result deviation caused by environmental problems, and then executes a large number of test cases in a short time through multi-thread parallel execution of test tasks, significantly improves the efficiency and economy of the test, and improves the accuracy and reliability of the test result through retry and compensation of the original test result data, reduces false failure reports.

[0169] In a preferred embodiment, step S4 also introduces a PIPQ (Parallel Insertion Priority Queue) based intelligent scheduling mechanism, which enables more refined test task management and execution optimization through steps S4.6 to S4.10, further improving the efficiency and quality of testing.

[0170] S4.6: According to the regression test case library and test requirements, priority modeling processing is performed on the test tasks to generate a test task priority model, which includes business importance, historical failure rate, and execution time weight configuration information.

[0171] In step S4.6, according to the regression test case library and test requirements, priority modeling processing is performed on the test tasks to generate a test task priority model. The purpose of this step is to assign reasonable execution priority to test tasks, ensuring that important and urgent test tasks are executed first. Analyze multiple influencing factors such as business importance (i.e. the business value of the function covered by the test case), historical failure rate (i.e. the failure frequency of the test case in past execution), and execution time (i.e. the estimated running time of the test case), etc., and assign weights to these factors to build a comprehensive priority scoring model. For example, business importance may be assigned a weight of 50%, historical failure rate a weight of 30%, and execution time a weight of 20%, and then the comprehensive priority score of each test task is calculated according to these weights. This multi-factor based priority model can more comprehensively reflect the actual importance and urgency of test tasks, providing a scientific basis for subsequent intelligent scheduling. Through this step, a test task priority model containing detailed weight configuration information is generated, preparing for the creation of a PIPQ scheduler and task scheduling in the future.

[0172] S4.7: Based on the test task priority model, initialize the creation of a PIPQ scheduler with a double-layer structure and generate an initial PIPQ scheduler instance, which is used to manage and schedule the test tasks;

[0173] It is necessary to note that based on the test task priority model, the PIPQ scheduler with double-layer structure is initialized and the initial PIPQ scheduler instance is generated. This step introduces an advanced PIPQ data structure, which provides support for efficient parallel task scheduling. PIPQ is a special queue structure that supports parallel insertion and priority queuing, and is particularly suitable for handling large-scale parallel test tasks. A PIPQ scheduler with double-layer structure is created: the worker level contains multiple thread-local priority queues, each corresponding to a worker thread, supporting parallel insertion operations; the leader level maintains the index of the global highest priority element, ensuring that the test task with the highest priority can be quickly accessed. This double-layer structure design balances the efficiency of parallel insertion and the accuracy of priority access, which is the core advantage of PIPQ. Through this step, an initial PIPQ scheduler instance is created, which prepares for subsequent test task insertion and scheduling.

[0174] S4.8: Calculate the corresponding test case priority score for each test case in the regression test case library, and insert the test case as a test task into the worker level queue of the PIPQ scheduler according to the test case priority score, to generate a filled PIPQ scheduler instance.

[0175] Calculate the corresponding test case priority score for each test case in the regression test case library, and insert the test case as a test task into the worker level queue of the PIPQ scheduler according to the priority score. This step realizes the efficient distribution and priority sorting of test tasks. According to the priority model established in the previous step, a priority score is calculated for each test case, which takes into account factors such as business importance, historical failure rate and execution time. Then, these test cases are converted into test tasks and inserted into the worker level queue of the PIPQ scheduler according to their priority scores. The insertion process uses multi-thread parallel operation, with each thread responsible for processing a part of the test cases and inserting them into its own local queue. This parallel insertion strategy greatly improves the efficiency of task distribution, especially when dealing with a large number of test cases. Through this step, a filled PIPQ scheduler instance is generated, which contains various test tasks sorted by priority, providing a foundation for subsequent efficient execution.

[0176] S4.9: Perform resource evaluation on system resource status and test task quantity, determine the optimal number of worker threads, and create a test execution thread pool for parallel execution of test tasks accordingly.

[0177] In step S4.9, resource evaluation is performed on the system resource status and the amount of test tasks, the optimal number of worker threads is determined, and a test execution thread pool for parallel execution of test tasks is created accordingly. The purpose of this step is to optimize resource allocation according to actual conditions, ensuring efficient execution of test tasks without excessive resource consumption. Analyze the available computing resources (such as CPU core number, memory capacity, etc.) and the characteristics of test tasks (such as task quantity, estimated execution time, etc.), then use a specific algorithm to determine the optimal number of worker threads. This number is usually a multiple of the CPU core number, but also takes into account the IO intensity and resource requirements of the tasks. After determining the number of threads, a fixed-size thread pool is created, which is responsible for actually executing test tasks, and each thread will get tasks from the PIPQ scheduler and execute them. Through this resource optimization strategy, it can ensure test efficiency while avoiding system performance degradation caused by excessive resource usage, achieving the best balance between resource usage and test efficiency.

[0178] S4.10: Under the cooperation of the filled PIPQ scheduler instance and the test execution thread pool, the worker threads extract the highest priority test tasks from the PIPQ scheduler and execute them, while supporting dynamic insertion of new high-priority test tasks to collect the task execution results of each test task and generate the original test result set.

[0179] In step S4.10, under the cooperation of the filled PIPQ scheduler instance and the test execution thread pool, the worker threads extract the highest priority test tasks from the PIPQ scheduler and execute them, while supporting dynamic insertion of new high-priority test tasks. This step is the core link of test execution, which realizes efficient task scheduling and execution. The worker threads in the test execution thread pool will continuously get the test tasks with the highest priority from the PIPQ scheduler, then execute these tasks and collect the execution results. The PIPQ scheduler will ensure that tasks with high priority are executed first, and through its double-layer structure design, it supports dynamic insertion of new high-priority tasks during test execution. These new tasks will be inserted into the appropriate position according to their priority, and may be executed in priority to existing tasks. This dynamic scheduling capability can respond to sudden high-priority test requirements, such as urgent regression tests or specific function verification tests, improving the flexibility and adaptability of the system. After executing each test task, the worker thread will collect the execution results of the task, including interface return value, execution status, time consumption statistics, etc. These information will be summarized to form the original test result set, providing data basis for subsequent result analysis.

[0180] Therefore, the embodiment realizes efficient regression test execution and result collection. Compared with traditional serial testing or simple parallel testing, the PIPQ-based intelligent scheduling method has the following advantages: first, the embodiment can prioritize according to the business importance and historical performance of the test task, ensure important tasks are executed first, and improve the effectiveness of the test; second, an efficient parallel processing strategy is adopted, which fully utilizes the multi-core processing capability of the system, significantly improves the execution efficiency of the test; third, the embodiment supports dynamic task insertion and priority adjustment, which can flexibly respond to changes and urgent needs in the test process; finally, through resource assessment and optimization, the system performance is improved while the test efficiency is ensured, and the best balance between resource use and test efficiency is achieved.

[0181] In addition, the embodiment can be applied to handle large-scale regression test scenarios, efficiently complete the execution of a large number of test cases and generate reliable test results under limited time and resource conditions, providing a solid data foundation for subsequent result analysis and problem positioning. The embodiment cooperates with the previous case intelligent screening and Mock service construction link to form an efficient and reliable end-to-end regression test system.

[0182] Step S5: performing return value comparison and performance comparison on the test result data based on the regression test case library, and generating a test report.

[0183] Specifically, the step S5 can further include the following steps S5.1 to S5.4.

[0184] S5.1: determining return value comparison rules and performance threshold configuration rules based on the interface configuration information, a preset configuration interface and / or a configuration file, wherein the return value comparison rules include ignored fields and comparison methods, and the performance threshold configuration rules include allowed response time deviation percentage.

[0185] In this step, first, clear comparison standards need to be established in order to objectively evaluate the test results later. Read the characteristic parameters defined in the interface configuration information, combine the preferences set by the user through the configuration interface or the pre-stored configuration file, and generate two types of core rules: return value comparison rules and performance threshold configuration rules. The return value comparison rules mainly define which fields can be ignored in the comparison process (such as timestamp, randomly generated ID, and non-business critical fields), and which comparison method should be used (such as exact string matching, JSON structure comparison, regular expression matching, etc.). The performance threshold configuration rules mainly define the acceptable performance fluctuation range, usually expressed in response time deviation percentage, for example, the response time of the test environment is allowed to be 20% slower than that of the production environment.

[0186] S5.2: Perform return value comparison for each test case on the test result data, the original return value in the regression test case library, and the return value comparison rule, to generate return value comparison results.

[0187] In this step, detailed return value comparison analysis is performed. For each test case, the actual return result obtained after the current test execution is compared with the original return value stored in the regression test case library. The comparison process strictly follows the return value comparison rules determined in the previous step. This embodiment supports multiple comparison modes, including simple string complete matching and more complex JSON structure comparison. In particular, in the JSON comparison mode, specific JSON paths can be intelligently ignored according to the configuration, such as time fields, randomly generated identifiers, or other dynamic values that have no business significance. This flexible comparison mechanism ensures that the test can focus on verifying the correctness of the key business logic, without false positives due to reasonable changes in non-critical fields. After the comparison is completed, detailed comparison results are generated for each test case, indicating whether it passes or fails, as well as the specific fields and values that do not match.

[0188] S5.3: Perform performance comparison on the performance indicators of each test case on the test result data, the original performance data in the regression test case library, and the performance threshold configuration rule, to generate performance comparison results.

[0189] In addition to functional correctness verification, comprehensive performance comparison analysis is also performed. For each test case, the performance indicators recorded during the current test process (mainly response time) are compared with the original performance data stored in the regression test case library. This comparison follows the performance threshold configuration rules defined earlier, with particular attention to changes in response time. The percentage deviation between the actual response time and the baseline response time is calculated and compared with the configured allowed deviation threshold. For example, if a 20% performance decline is allowed, and the actual response time of a test case is 30% slower than the baseline value, the case will be marked as a performance comparison failure. This performance comparison mechanism can timely detect the degradation of system performance and help the development team intervene before the problem expands. After the comparison is completed, detailed performance comparison results are generated, including performance indicator comparison data for each case and pass / fail status.

[0190] S5.4: Integrate the return value comparison results and the performance comparison results, and mark the test cases that do not meet expectations, to generate the test report.

[0191] In the last step, the previously generated return value comparison results and performance comparison results are comprehensively integrated to form a complete test report. Therefore, through the generation of the test report, not only the overall pass rate and failure rate statistics are included, but also all test cases that do not meet expectations are listed in detail. For each failed test case, the report clearly indicates the specific reason for the failure (whether the return value does not match or the performance does not meet the standard), as well as relevant detailed information (such as the mismatched field, the difference between the actual value and the expected value, the performance deviation percentage, etc.). This detailed failure information can help developers and testers quickly locate the root cause of the problem, improving problem-solving efficiency. In addition, the failed test cases are classified and prioritized, highlighting those that affect critical business functions or have severe performance degradation, helping the team to reasonably allocate repair resources. The final test report is intuitive and informative, providing strong support for subsequent problem repair and system optimization.

[0192] For example, after organizing the test case information of the interface call return value comparison failure and the interface call time consumption comparison failure, the information is fed back to the user for further processing.

[0193] As shown in Figure 3 The embodiment of the application also provides a regression testing system based on traffic playback and Mock technology, which comprises:

[0194] A test configuration module 10 is configured to integrate the interface configuration information, third-party interface information, traffic classification configuration information and traffic selection strategy configuration information of the obtained to-be-tested system to form test configuration data;

[0195] A test case generation module 20 is configured to classify and sample the online traffic data according to the test configuration data to generate a regression test case library;

[0196] A Mock service construction module 30 is configured to extract all third-party interface call information from the regression test case library, classify and organize the third-party interface call information through a preset interface classification and interception strategy, construct a Mock service for a specified protocol type, and generate a Mock interface service set;

[0197] A test execution module 40 is configured to perform multi-thread parallel testing on a test task related to the regression test case library based on the regression test case library and the Mock interface service set to generate test result data, wherein the test result data comprises the execution result of a test case indicated in the regression test case library, and the execution result comprises an interface return value, an execution state and performance data;

[0198] The result analysis module 50 is configured to perform return value comparison and performance comparison on the test result data based on the regression test case library, and generate a test report.

[0199] The modules in the embodiment can implement the corresponding steps in the foregoing method embodiments, and the specific implementation process can refer to the related description in the foregoing method embodiments, which will not be described here again.

[0200] The regression test method and system based on traffic playback and Mock technology provided in the embodiment can intelligently classify and sample online traffic data, obtain representative test cases, automatically construct Mock services of third-party interfaces, avoid dependence on actual third-party systems, and improve test efficiency through multi-thread parallel testing. The embodiment realizes intelligent screening of regression test cases and automatic Mock of third-party interfaces, and effectively improves the quality, efficiency and reliability of regression testing.

[0201] The above merely describes specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A regression testing method based on traffic playback and Mock techniques, characterized in that, The method comprises the following steps: Data integration is performed on the interface configuration information, third-party interface information, traffic classification configuration information and traffic selection strategy configuration information of the acquired to-be-tested system to form test configuration data; According to the test configuration data, online traffic data is classified and sampled to generate a regression test case library; All third-party interface calling information is extracted from the regression test case library, classified and arranged through a preset interface classification and interception strategy, and Mock services for a specified protocol type are constructed to generate a Mock interface service set; Based on the regression test case library and the Mock interface service set, a test task related to the regression test case library is tested in multiple threads in parallel to generate test result data, which includes the execution results of the test cases indicated in the regression test case library; Based on the regression test case library, the test result data is subjected to return value comparison and performance comparison to generate a test report; The method according to the test configuration data, the online traffic data is classified and sampled to generate a regression test case library, comprising: According to the interface configuration information and the traffic classification configuration information, the online traffic data is mapped to a multi-dimensional feature space to form a traffic feature space model, wherein each dimension in the traffic feature space model represents a key business feature; Based on the traffic feature space model, variables whose influence on test coverage exceeds a preset influence threshold are identified as test constraint variables for constraint satisfaction problems; Based on the test constraint variables and preset system business rules, test constraint relationships between the test constraint variables are determined, including single-variable constraints and multi-variable constraints; According to the test constraint variables and the test constraint relationships, the online traffic data is mapped to a constraint variable space, and the representation of each piece of online traffic data in the constraint variable space is generated to generate a traffic data set in the constraint variable space; A preset constraint satisfaction problem is used to classify and cluster the traffic data set and the test constraint relationships, identify traffic subsets that satisfy different constraint combinations, and generate a traffic distribution statistical table; Based on the initial traffic case set and the test constraint relationships, the coverage of the current initial traffic case set in the constraint variable space is evaluated to generate an insufficient coverage area table, and the insufficient coverage area table and the test constraint relationships are subjected to constraint solving to generate the supplementary traffic case set.

2. The method of claim 1, wherein, The method according to the test configuration data, the online traffic data is classified and sampled to generate a regression test case library, further comprising: According to the traffic classification configuration information and the traffic selection strategy configuration information, online traffic data is subjected to statistical analysis, and the traffic quantity distribution of each traffic category and traffic subcategory in a specified time range is calculated to generate a traffic distribution statistical table; Proportionally calculate the traffic distribution statistics table and the traffic classification configuration information to determine the number of use cases that each traffic subcategory needs to select in each time period, and generate a traffic selection quota table; According to the traffic selection quota table and the traffic selection strategy configuration information, a preset time-weighted random sampling strategy is used to select a corresponding number of use cases from online traffic data in different time periods to generate an initial traffic use case set, wherein the time-weighted random sampling strategy is used to indicate that the traffic data with a time difference less than a preset time difference threshold is preferentially selected; Based on the initial traffic use case set and the traffic selection strategy configuration information, a preset proportion of abnormal traffic is selected to generate a supplementary traffic use case set to supplement abnormal traffic; According to the supplementary traffic use case set, data conversion, storage processing and format conversion are performed on the initial traffic use case set to generate a regression test case library.

3. The method of claim 2, wherein, The third-party interface calling information is extracted from the regression test case library, classified and arranged through a preset interface classification and interception strategy, and Mock services for a specified protocol type are constructed to generate a Mock interface service set, including: Data analysis is performed on the regression test case library and the third-party interface information to extract all third-party interface calling information, including request parameters, return results and calling time; The third-party interface calling information is classified and processed according to protocol type and system to generate multiple interface calling information sets, including HTTP interface calling information set, Dubbo interface calling information set and other type interface calling information set; A preset Web filter algorithm is used to perform request interception, parameter matching and response simulation on the HTTP interface calling information set to construct an HTTP interface Mock service; A preset Dubbo filter algorithm is used to perform request interception, parameter matching and response simulation on the Dubbo interface calling information set to construct a Dubbo interface Mock service; An interception algorithm related to the other type interface calling information set is used to perform request interception, parameter matching and response simulation on the other type interface calling information set to construct other type interface Mock services; The HTTP interface Mock service, the Dubbo interface Mock service and the other type interface Mock service are deployed into a test environment and organized into a Mock interface service set.

4. The method of claim 3, wherein, Based on the regression test case library and the Mock interface service set, multi-threaded parallel testing is performed on the test tasks related to the regression test case library to generate test result data, including: The test cases included in the regression test case library are assigned as multiple test tasks that can be executed in parallel; When it is detected based on the test tasks and the test environment that the to-be-tested system and the Mock interface service set are in a ready state, an environment ready confirmation result is output, which indicates that the test environment meets a preset execution condition; In response to the environment readiness confirmation result, multiple test tasks are called in multi-thread parallel mode, each thread executes a test case, collects the execution results of each test case, the execution results include interface return value, execution status and performance data, and generates original test result data; Based on the original test result data, abnormal test cases with execution timeout or failure are identified, and the abnormal test cases are retested, and combined with the original test result data and retest result data, compensation test result data is generated; The compensation test result data is subjected to data conversion standardization processing and format conversion to generate the test result data.

5. The method of claim 4, wherein, The test result data is subjected to return value comparison and performance comparison based on the regression test case library to generate a test report, including: Based on the interface configuration information, the preset configuration interface and / or configuration file, return value comparison rules and performance threshold configuration rules are determined, wherein the return value comparison rules include ignored fields and comparison methods, and the performance threshold configuration rules include allowed response time deviation percentage; The test result data, the original return value in the regression test case library and the return value comparison rules are subjected to return value comparison of each test case to generate return value comparison results; The test result data, the original performance data in the regression test case library and the performance threshold configuration rules are subjected to performance comparison of performance indicators of each test case to generate performance comparison results; The return value comparison results and the performance comparison results are integrated, and test cases that do not meet expectations are marked to generate the test report.

6. The method of claim 5, wherein, According to the traffic selection quota table and the traffic selection strategy configuration information, an initial traffic case set is generated by using a preset time-weighted random sampling strategy to select a corresponding number of cases from online traffic data in different time periods, including: According to the traffic selection quota table, a PIPQ data structure with a double-layer structure is initialized and created, and an initialized PIPQ instance is generated from the PIPQ data structure, wherein the PIPQ data structure includes worker level and leader level, the worker level includes multiple thread local priority queues, and the leader level is used to maintain the global highest priority element index; For the traffic selection strategy configuration information, online traffic data in different time periods is assigned to multiple worker threads for parallel processing to generate candidate traffic sets in multiple worker threads, wherein each worker thread is used to scan online traffic data in a specific time period or a specific partition; Based on the candidate traffic set, combined with the time freshness, business scenario representativeness and abnormal characteristics obtained in advance, the priority score corresponding to each online traffic data is calculated, and the online traffic data is inserted into the thread local priority queue of the worker level in parallel according to the priority score to generate a filled PIPQ instance; According to the filled PIPQ instance, periodically extract the current highest priority element from the worker-level thread local priority queue to update the index in the leader level, generate a sorted PIPQ instance; Based on the sorted PIPQ instance and the traffic selection quota table, iteratively delete the minimum value of the thread local priority queue, and extract the highest priority traffic data of each traffic subcategory in turn according to the quota limit of each traffic subcategory, until the quota requirement is met, and generate the initial traffic use case set.

7. The method of claim 6, wherein, Based on the regression test case library and the Mock interface service set, the test task related to the regression test case library is tested in multiple threads in parallel to generate test result data, and the method further comprises: According to the regression test case library and test requirements, the test task priority modeling processing is performed to generate a test task priority model, wherein the test task priority model includes business importance, historical failure rate, and execution time weight configuration information; Based on the test task priority model, a double-layer PIPQ scheduler is initialized and created, and an initial PIPQ scheduler instance is generated, wherein the PIPQ scheduler is used to manage and schedule the test task; For each test case in the regression test case library, a corresponding use case priority score is calculated, and the test case is inserted into the worker-level queue of the PIPQ scheduler as a test task in parallel according to the use case priority score, and a filled PIPQ scheduler instance is generated. Resource evaluation is performed on the system resource status and the test task amount, the optimal number of worker threads is determined, and a test execution thread pool for parallel execution of test tasks is created accordingly; Under the synergistic action of the filled PIPQ scheduler instance and the test execution thread pool, the worker thread extracts the highest priority test task from the PIPQ scheduler and executes it, while supporting dynamic insertion of new high-priority test tasks, to collect the task execution results of each test task and generate an original test result set.

8. A regression testing system based on traffic playback and Mock techniques, characterized in that, Comprise: A test configuration module for integrating the interface configuration information, third-party interface information, traffic classification configuration information and traffic selection strategy configuration information of the acquired system under test to form test configuration data; A test case generation module for classifying and sampling online traffic data according to the test configuration data to generate a regression test case library; Wherein, the test case generation module for classifying and sampling online traffic data according to the test configuration data to generate a regression test case library comprises: According to the interface configuration information and the traffic classification configuration information, the online traffic data is mapped to a multi-dimensional feature space to form a traffic feature space model, wherein each dimension in the traffic feature space model represents a key business feature; Based on the traffic feature space model, identify variables whose influence on test coverage exceeds a preset influence threshold as test constraint variables for constraint satisfaction problem; determine a test constraint relationship between the test constraint variables based on the test constraint variables and preset system service rules, the test constraint relationship including single-variable constraints and multi-variable constraints; map the online traffic data to a constraint variable space according to the test constraint variables and the test constraint relationship, generate a representation of each piece of online traffic data in the constraint variable space, and generate a traffic data set in the constraint variable space; classify and cluster the traffic data set and the test constraint relationship by using a preset constraint satisfaction problem, identify traffic subsets that meet different constraint combinations, and generate the traffic distribution statistics table; evaluate coverage of the initial traffic use case set in the constraint variable space based on the initial traffic use case set and the test constraint relationship, generate an insufficient coverage area table, and perform constraint solving on the insufficient coverage area table and the test constraint relationship to generate the supplemental traffic use case set; a Mock service construction module configured to extract all third-party interface call information from the regression test case library, classify and arrange the third-party interface call information by using a preset interface classification and interception strategy, and construct Mock services for a specified protocol type to generate a Mock interface service set; a test execution module configured to perform multi-threaded parallel testing on test tasks related to the regression test case library based on the regression test case library and the Mock interface service set, and generate test result data, the test result data including execution results of test cases indicated in the regression test case library and performance data execution results, the execution results including interface return values, execution states, and performance data; a result analysis module configured to perform return value comparison and performance comparison on the test result data based on the regression test case library, and generate a test report.

Images