Regression test method and system based on traffic playback and Mock technology

Abstract

The invention discloses a regression testing method and system based on traffic playback and Mock technologies, and relates to the technical field of software testing. The method comprises the following steps: integrating interface configuration information, third-party interface information, flow classification configuration information and flow selection strategy configuration information of a system to be tested to form test configuration data; performing intelligent classification sampling processing on the online traffic according to the configuration data to generate a regression test case library; all third-party interface calling information is extracted from the regression test case library, the third-party interface calling information is classified and arranged through an interface classification and interception strategy, Mock service for a specified protocol type is constructed, and a Mock interface service set is generated; based on the regression test case library and the Mock interface service set, performing multi-thread parallel test on the test task; and performing return value comparison and performance comparison on the test result data based on the regression test case library to generate a test report. According to the invention, the regression test efficiency and quality can be improved.

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: Integrate the interface configuration information, the third-party interface information, the traffic classification configuration information and the traffic selection strategy configuration information of the obtained to-be-tested system to form test configuration data; According to the test configuration data, perform classified sampling processing on online traffic data to generate a regression test case library; Extract all third-party interface calling information from the regression test case library, classify and arrange the third-party interface calling 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; 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; Based on the regression test case library, perform return value comparison and performance comparison on the test result data to generate a test report.

[0008] Optionally, according to the test configuration data, performing classified sampling processing on online traffic data to generate a regression test case library, includes: 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; According to the traffic distribution statistical table and the traffic classification configuration information, perform proportional calculation 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; According to the traffic selection quota table and the traffic selection strategy configuration information, use a preset time-weighted random sampling strategy to select a corresponding number of test cases from online traffic data in different time periods 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; 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; 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.

[0009] 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 a Mock service for a specified protocol type is constructed to generate a Mock interface service set, including: data parsing 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 consumption; The third-party interface calling information is classified and processed according to protocol types and systems to which the third-party interface calling information belongs, thereby generating 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; A preset Web filter algorithm is used to perform request interception, parameter matching and response simulation on the HTTP interface calling information set, thereby constructing 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, thereby constructing 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, thereby constructing other type interface Mock services; 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.

[0010] Optionally, based on the regression test case library and the Mock interface service set, multi-threaded parallel testing is performed on 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 a plurality of 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, the environment ready confirmation result being used to indicate that the test environment meets a preset execution condition; In response to the environment ready confirmation result, a plurality of test tasks are called in multi-threaded parallel mode, and each thread executes one test case, collects execution results of each test case, the execution results including interface return values, execution states and performance data, and generates original test result data; Based on the original test result data, abnormal test cases that execute overtime or fail are identified, and the abnormal test cases are retested, and compensation test result data is generated based on the original test result data and retest result data; The compensation test result data is subjected to data conversion standardization processing and format conversion to generate the test result data.

[0011] Optionally, the return value comparison and performance comparison are performed on the test result data based on the regression test case library, and a test report is generated, including: Based on the interface configuration information, a preset configuration interface and / or a configuration file, return value comparison rules and performance threshold configuration rules are determined, wherein the return value comparison rules include an ignore field and a comparison method, and the performance threshold configuration rules include an allowed response time deviation percentage; Return value comparison of each test case is performed on the test result data, original return values in the regression test case library, and the return value comparison rules, and return value comparison results are generated; Performance comparison of performance indicators of each test case is performed on the test result data, original performance data in the regression test case library, and the performance threshold configuration rules, and performance comparison results are generated; The return value comparison results and the performance comparison results are integrated, and test cases that do not meet expectations are marked, and the test report is generated.

[0012] 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: 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; For the traffic selection strategy configuration information, online traffic data in different time periods is assigned to a plurality of 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 in a specific time period or a specific partition; Based on the candidate traffic set, in combination with pre-acquired time freshness, business scenario representativeness and abnormal features, a priority score corresponding to each piece of 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, and a filled PIPQ instance is generated; According to the filled PIPQ instance, the current highest priority element is periodically extracted from the thread-local priority queue of the worker level to update the index in the leader level, and a sorted PIPQ instance is generated; Based on the completed PIPQ instance and the traffic selection quota table, the minimum value of the thread local priority queue is iteratively deleted, 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 reached, and the initial traffic use case set is generated.

[0013] 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 multi-thread parallel mode to generate test result data, and the method further includes: According to the regression test case library and test requirements, a test task priority modeling process is performed to generate a test task priority model, and the test task priority model includes weight configuration information of business importance, historical failure rate, and execution time; Based on the test task priority model, a PIPQ scheduler with a double-layer structure is initialized and created, and an initial PIPQ scheduler instance is generated, and the PIPQ scheduler is used to manage and schedule the test tasks; A use case priority score corresponding to each test case in the regression test case library is calculated, and the test case is inserted into a 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 system resource status and test task quantity to determine an optimal number of worker threads, 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 threads extract the highest priority test task from the PIPQ scheduler for execution, while supporting dynamic insertion of new high-priority test tasks, to collect task execution results of each test task and generate an original test result set.

[0014] Optionally, the method of classifying and sampling online traffic data according to the test configuration data to generate a regression test case library further includes: 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 degree 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 a preset system business rule, test constraint relationships between the test constraint variables are determined, and the test constraint relationships include single-variable constraints and multi-variable constraints. According to the test constraint variables and the test constraint relationship, the online traffic data is mapped to a constraint variable space, a representation of each piece of online traffic data in the constraint variable space is generated, and a traffic data set in the constraint variable space is generated; A preset constraint satisfaction problem is used to classify and cluster the traffic data set and the test constraint relationship, a traffic subset satisfying different constraint combinations is identified, and the traffic distribution statistics table is generated; Based on the initial traffic use case set and the test constraint relationship, the coverage of the current initial traffic 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, and the supplementary traffic use case set is generated.

[0015] Optionally, the Mock system is optimized based on a symmetry breaking technology of directional spectrum partitioning, and the classification algorithm processing of the interface call information and the construction of the HTTP interface Mock service and the Dubbo interface Mock service are optimized, comprising: The third-party interface call information is subjected to dependency relationship analysis, 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; The interface call dependency graph is subjected to graph analysis, and a Laplacian matrix of the interface call dependency graph and corresponding eigenvalues and eigenvectors are obtained, and interface dependency features are generated based on the Laplacian matrix, the eigenvalues and the eigenvectors; Based on the interface dependency features, symmetric structures and patterns in the interface call dependency graph are identified, and an interface symmetry analysis report is generated 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; According to the interface symmetry analysis report, symmetric breaking clustering is performed on the third-party interfaces, so that third-party interfaces with similar symmetry features are aggregated into a logical group, and a symmetric-aware interface classification result is generated; For the interface classification result, a Mock strategy is formulated for each interface category, the Mock strategy including using a specified unified Mock template for an interface group with 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 the symmetric structure, and the interface call information set is generated; Based on the interface symmetry analysis report, a symmetric transformation response generation mechanism is realized by using a response conversion algorithm, when a request for a symmetric interface is received, the existing symmetric transformation response is symmetrically transformed to generate a new symmetric transformation response.

[0016] To achieve the above object, the application further provides a regression testing system based on traffic playback and Mock technology, comprising: A test configuration module is configured to integrate 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. A test case generation module is configured to classify and sample the online traffic data according to the test configuration data to generate a regression test case library. A Mock service construction module is configured to extract all third-party interface calling information from the regression test case library, classify and arrange the third-party interface calling information through a preset interface classification and interception strategy, construct Mock services for a specified protocol type, and generate a Mock interface service set. A test execution module is configured to perform multi-thread parallel testing on the 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, wherein the test result data comprises the execution results of the test cases indicated in the regression test case library, and the execution results comprise interface return values, execution states and performance data. A result analysis module is configured to compare the return values and performance of the test result data based on the regression test case library, and generate a test report.

[0017] The regression testing method and system based on traffic playback and Mock technology provided by the application can intelligently classify and sample online traffic data, acquire representative test cases, automatically construct Mock services for third-party interfaces, avoid dependence on actual third-party systems, and improve testing efficiency through multi-thread parallel testing. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 The flowchart of the regression testing method based on traffic playback and Mock technology provided by the embodiment of the application; Figure 2 The processing flowchart of the Mock service provided by the embodiment of the application; Figure 3A module structure diagram of the regression test system based on the traffic playback and Mock technology provided by the embodiments of the present application is shown. DETAILED DESCRIPTION

[0019] The present application will be further described below in conjunction with the drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application.

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

[0021] Step S1: 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.

[0022] 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 URL path, protocol type, parameter structure, return value structure, etc. of the to-be-tested interface. The third-party interface information includes interface URL, protocol type (such as HTTP, Dubbo, etc.), system to which it belongs, etc. The traffic classification configuration information includes main classification field (such as pid field), sub-classification field (such as status field), required number of test cases for each classification, etc. The traffic selection strategy configuration information includes time range (such as the last N days) of traffic selection, selection weight of each time period (such as 50% for the first day and 25% for the second day, etc.), abnormal traffic proportion (such as 20%), etc.

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

[0024] Step S2: according to the test configuration data, the online traffic data is classified and sampled to generate a regression test case library.

[0025] 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.

[0026] Specifically, step S2 comprises the following steps S2.1 to S2.5.

[0027] 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, and a traffic distribution statistical table is generated.

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

[0029] S2.2: Proportion calculation is performed on the traffic distribution statistical table and the traffic classification configuration information to determine the number of use cases to be selected for each traffic subcategory in each time period, and a traffic selection quota table is generated.

[0030] For example, according to the percentage of the traffic number of each subcategory in the traffic number of its use case classification, the selected traffic number configured for each classification (such as 1000) is allocated. Next, proportion calculation is performed according to the traffic distribution statistical table and the traffic classification configuration information. The system reads the required test use case number of each classification (such as 1000 regression test use cases for each classification) set in the traffic classification configuration information, and then allocates the test use case number in proportion according to the traffic proportion of each subcategory in the traffic distribution statistical table. Specifically, the proportion of each subcategory in its main classification is calculated, and then the total number of use cases of the main classification is allocated to each subcategory in proportion. For example, if the traffic proportions of subcategories A, B, and C under a main classification are 15%, 30%, and 55% respectively, and 1000 use cases need to be selected for the main classification, 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 traffic, improving the representativeness of the test. Through this step, a detailed traffic selection quota table is generated, which specifies the number of use cases to be selected for each subcategory in each time period.

[0031] S2.3: According to the traffic selection quota table and the traffic selection strategy configuration information, use a preset time-weighted random sampling strategy 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 traffic data with a time difference less than a preset time difference threshold is preferentially selected.

[0032] For example, according to the principle of selecting more use cases in a shorter 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 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. The time-weighted random sampling strategy preferentially selects traffic data with a shorter time, as this data better reflects the current state of the system. According to the selection weights of each time period defined in the traffic selection strategy configuration information (e.g., 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 subcategory, 75 use cases (50%) may be selected from the data of the most recent day, 38 use cases (25%) may be selected from the data of the second day, 19 use cases (12.5%) may be selected from the data of the third day, and 18 use cases (12.5%) may be selected from the data of 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 contains use cases of various categories selected according to the time weighting principle.

[0033] 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.

[0034] For example, 20% of abnormal traffic use cases (e.g., abnormal return status of the interface under test, abnormal return status of the three-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 an abnormal call of a third-party interface. Since these abnormal cases 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 increased. According to the abnormal traffic proportion (e.g., 20%) defined in the traffic selection strategy configuration information, a certain number of abnormal traffic is additionally selected from the online traffic data as a supplement. These abnormal traffic, together with the initial traffic use case set, will form a more comprehensive test case set.

[0035] 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.

[0036] Finally, 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 final regression test case library. The selected traffic data is converted into a standard test case format, including original request parameters, return results, call time consumption, and related third-party interface call information, etc. These information will be structured 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 foundation for subsequent Mock service construction and test execution.

[0037] In an optimized implementation scheme, 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.

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

[0039] 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 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.

[0040] In step S2.3.1, the quota table is selected according to the traffic, the PIPQ data structure with a double-layer structure is initialized, and the initialized PIPQ instance is generated. The double-layer structure of PIPQ includes worker level and leader level. The worker level contains multiple thread-local priority queues, each queue corresponding to a worker thread, and 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 simultaneously support high-concurrency data insertion and efficient priority element access, which is very suitable for large-scale traffic data processing.

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

[0042] In step S2.3.2, online traffic data of different time periods is allocated to multiple worker threads for parallel processing according to the traffic selection strategy configuration information. Each worker thread is responsible for scanning online traffic data of a specific time period or a specific partition, and works independently without interference. For example, the data of the last N days can be allocated to different worker threads by day, or the data of the same day can be allocated to different worker threads according to a certain partition key (such as the hash value of user ID). This parallel processing method greatly improves the efficiency of data scanning and processing, especially when processing large-scale online traffic data, which can significantly reduce processing time. Through this step, multiple candidate traffic sets local to multiple worker threads are generated, each containing a part of potential test cases.

[0043] S2.3.3: Based on the candidate traffic set, the time freshness, business scenario representativeness and abnormal characteristics obtained in advance are combined to calculate the priority score corresponding to each online traffic data, 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.

[0044] In step S2.3.3, based on the candidate traffic set of each worker thread, combined with the pre-acquired time freshness, business scenario representativeness, and abnormal feature, etc., the priority score of each on-line traffic data is calculated. It should be noted that the priority score is a comprehensive score, which reflects 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 * abnormal feature score, wherein w1 is the weight coefficient of time freshness, w2 is the weight coefficient of business scenario representativeness, and w3 is the weight coefficient of abnormal feature, which can be configured according to the test requirements. For example, if more attention is paid to the latest business scenario, the value of w1 can be increased; if more attention is paid to the abnormal processing capability of the system, the value of w3 can be increased. After the priority score is calculated, each traffic data is inserted into the thread local priority queue of the PIPQ worker level in parallel, and each worker thread only operates its own local queue to avoid lock contention. Through this step, the filled PIPQ instance is generated, which contains the traffic data of each category sorted by priority.

[0045] S2.3.4: 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, and generate a sorted PIPQ instance.

[0046] In step S2.3.4, 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. This process is the key to maintaining the accessibility of the global highest priority element of PIPQ. Regularly (such as every 100 milliseconds) scan the head elements of all worker queues (i.e. the element with the highest priority in each queue), find the global highest priority element, and update the index in the leader level. 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, a sorted PIPQ instance is generated, which can quickly access the global highest priority element.

[0047] 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 test case set.

[0048] Optionally, based on the completed 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 test case set; otherwise, the next highest priority element is searched for. This process will continue until all subcategories have reached the quota requirement or all available traffic data has 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.

[0049] Therefore, the embodiment completes the intelligent screening of online traffic data and generates a regression test case library that meets the actual traffic distribution and 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.

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

[0051] S2.6: 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.

[0052] 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 to form a traffic feature space model. Therefore, the embodiment identifies and extracts key business features in the traffic data, such as user type, operation type, resource type, and business status, and represents each traffic data as a point in a multi-dimensional space. For example, for an interface of an e-commerce system, user level, product category, payment method, and order status may be extracted; for an interface of a financial system, transaction type, amount range, risk level, and processing result 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 test case generation.

[0053] S2.7: Based on the traffic feature space model, a variable whose impact on test coverage exceeds a preset impact threshold is identified as a test constraint variable for the constraint satisfaction problem.

[0054] In step S2.7, based on the traffic feature space model, the variables that have an impact on the test coverage exceeding a preset impact threshold are identified as test constraint variables for the constraint satisfaction problem. The purpose of this step is to find out the truly important variables among the numerous features to reduce the complexity of the problem. The impact of each feature on the test coverage is evaluated through statistical analysis or machine learning methods, such as using information gain, correlation analysis or feature importance scoring techniques. Then, the features with an impact exceeding a preset threshold (such as contributing more than 80% of the information) are selected 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 type, product category and payment method may be selected as test constraint variables; in a financial system, transaction type, amount interval and risk level may be selected as test constraint variables.

[0055] 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.

[0056] Among them, based on the test constraint variables and the preset system business rules, the test constraint relationships between the test constraint variables are determined, aiming to capture various rules and restrictions in the business logic and build a complete constraint relationship model. Test constraint relationships mainly include two categories: single-variable constraints and multi-variable constraints. Single-variable constraints refer to restrictions on the value of a single variable, such as a variable must be within a certain range, can only take a few specific values, etc.; multi-variable constraints refer to the interdependence between variables, such as the value of one variable affecting the possible value range of another variable, two variables must satisfy a certain functional relationship, etc. These constraint relationships usually come from the system's business rules, regulatory requirements or technical limitations. For example, in an e-commerce system, there may be a multi-variable constraint "VIP users must support credit payment when purchasing luxury product categories"; in a financial system, there may be a multi-variable constraint "high-value transactions must undergo senior risk assessment". Therefore, this embodiment establishes a complete constraint relationship model, providing a rule basis for subsequent use case generation.

[0057] S2.9: According to the test constraint variables and the test constraint relationships, map the online traffic data to the constraint variable space, generate the representation of each online traffic data in the constraint variable space, and generate the traffic data set in the constraint variable space.

[0058] 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, so that subsequent analysis and calculation are 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, commodity category and payment method, the values of the three attributes are extracted from each traffic data to form a triple representation such as (user type, commodity category, payment method). This mapping not only reduces the dimension of the data, but also makes the test and application of the constraint relationship more direct and efficient. Therefore, the embodiment generates a traffic data set in the constraint variable space, which provides input data for subsequent classification and clustering.

[0059] S2.10: Using a preset constraint satisfaction problem, the traffic data set and the test constraint relationship are classified and clustered to identify traffic subsets that satisfy different constraint combinations and generate the traffic distribution statistics table.

[0060] It should be noted that the traffic data set in the constraint variable space and the test constraint relationship are classified and clustered using a preset constraint satisfaction problem algorithm to identify traffic subsets that satisfy different constraint combinations. In this regard, the traffic data is effectively organized and classified according to the constraint relationship. The udCSP (unbounded domain constraint satisfaction problem) solving techniques such as FPT algorithm in parameterized complexity theory, polymorphism theory, etc. are used to efficiently classify the traffic data. Specifically, traffic subsets that satisfy 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 in the traffic data is counted to generate a detailed traffic distribution statistics table. This statistics table not only reflects the actual use of the current system, but also provides data basis for subsequent use case selection.

[0061] S2.11: Based on the initial traffic use case set and the test constraint relationship, the coverage of the current initial traffic use 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 constraints to generate the supplementary traffic use case set.

[0062] In this embodiment, based on the initial traffic 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 the insufficient coverage area table and the test constraint relationship are constrained to solve, and a supplementary traffic use case set is generated, 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 important for system stability. Analyze the distribution of the initial traffic use case set in the constraint variable space, and identify the insufficient coverage area, such as insufficient number of use cases for some constraint combinations or complete absence. Then, use constraint solving techniques to construct test cases that meet these constraint combinations to supplement the insufficient coverage area. 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 traffic use case set, which, together with the initial traffic use case set, constitutes a complete regression test case library.

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

[0064] 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.

[0065] As shown in Figure 2 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.

[0066] S3.1: Data analysis is performed 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.

[0067] For example, the third-party interface call information in the traffic regression use case is classified and organized according to the type of the interface to be Mocked, such as the third-party interface call information of external HTTP interface calls is summarized to form a set, the third-party interface call information of Dubbo interface calls is summarized to form a set, and so on.

[0068] In step S3.1, the regression test case library and third-party interface information are data parsed, and the calling information of each third-party interface is extracted. Thus, all the calling data related to the third-party interface is obtained from the selected test cases, preparing for the subsequent Mock service construction. Analyze each record in the regression test case library, identify and extract all third-party interface calls involved, including request parameters, return results, and calling time, etc. 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, SMS services, and other third-party systems, extract the detailed information of these calls respectively. It needs to be specially noted that if the traffic information and third-party interface calling information are stored separately, they need to be correctly associated using thread ID or other association identifiers to ensure that the calling information of the Mocked interface corresponding to the traffic regression case can be obtained. Therefore, the embodiment obtains a complete set of third-party interface calling information, providing a data basis for subsequent classification and Mock service construction.

[0069] S3.2: Classify the third-party interface calling information according to protocol type and system to which it belongs, and generate multiple interface calling information sets, including HTTP interface calling information set, Dubbo interface calling information set, and other types of interface calling information set.

[0070] In step S3.2, the third-party interface calling information is classified and processed according to the protocol type and the system to which it belongs, and multiple interface calling information sets are generated, aiming to effectively organize the interface calling information and facilitate the subsequent use of different Mock strategies for different types of interfaces. Specifically, first, classify according to protocol type, such as HTTP interface, Dubbo interface, WebService interface, etc., because different protocol types of interfaces need to use different interception and simulation technologies. Then, within each protocol type, further classify according to the third-party system to which it belongs, such as payment system, risk control system, SMS system, etc., because interfaces from the same system usually have similar calling patterns and return formats. This two-level classification method enables the system to more finely manage interface calling information, improving the accuracy and efficiency of Mock service. Therefore, the embodiment generates multiple interface calling information sets, including HTTP interface calling information set, Dubbo interface calling information set, and other types of interface calling information set, providing a classification basis for subsequent Mock service construction.

[0071] For example, each third-party interface call information summary set is classified according to the third-party system. If the traffic information and the third-party interface call information are stored separately, the two are associated with the thread ID, so that the call information of the interface to be mocked corresponding to the traffic regression use case can be obtained.

[0072] S3.3: A preset Web filter algorithm is used to perform request interception, parameter matching, and response simulation on the HTTP interface call information set, and an HTTP interface Mock service is constructed.

[0073] For example, a Web filter is implemented in the automated testing system to filter all interfaces of all third-party systems of the HTTP type and to mock them. Using the third-party interface call information set of the HTTP type that has been sorted above, when the Web filter receives a request call, the type, URL, header information, parameter information, and body information of the request are obtained, and are compared with the third-party interface call information set to find matching traffic call information, and the HTTP interface is returned according to the return value and the call time of the traffic call information.

[0074] In step S3.3, a preset Web filter algorithm is used to perform request interception, parameter matching, and response simulation on the HTTP interface call information set, and an HTTP interface Mock service is constructed. 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 third-party systems. When an HTTP request is received, the filter obtains the method (GET, POST, etc.), URL path, header information, query parameters, and request body content of the request, and then finds a matching record in the HTTP interface call information set. The matching process usually adopts a multi-level matching strategy, which first screens according to the URL path and the request method, and then performs accurate matching according to the header key field and the request parameter. After a matching record is found, the response of the HTTP interface is simulated according to the return result and the call time in the record, and if necessary, a certain delay is also simulated to restore the real call experience. If a completely matching record cannot be found, a most similar matching or a default response strategy may be adopted. 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.

[0075] S3.4: A preset Dubbo filter algorithm is used to perform request interception, parameter matching, and response simulation on the Dubbo interface call information set, and a Dubbo interface Mock service is constructed.

[0076] 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 to mock them. With the set of third-party interface call information of the Dubbo type sorted above, when the Dubbo filter receives a request call, the API, parameter information and other related information of the request are obtained, compared with the set of third-party interface call information, 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.

[0077] Specifically, the Dubbo interface call information set is intercepted, the parameters are matched, and the response is simulated by using a preset Dubbo filter algorithm to construct 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. A Dubbo filter is implemented in the automated testing environment, 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 finds the 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 accurately matches according to the request parameters. Since the parameters of the Dubbo interface are usually complex objects, deep comparison or ignoring of some non-key fields may be required. After the matching record is found, 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 constructed, effectively solving the problem of dependence on third-party Dubbo systems.

[0078] S3.5: Using an 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 construct an other type of interface Mock service.

[0079] For example, for Mock of other types of third-party interfaces, referring to Mock of HTTP type interfaces and Mock of 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, match with the sorted set of third-party interface call information of the type, find the return value and call time of the appropriate call traffic information, and then return the original time and original value.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] Therefore, the embodiment realizes automatic Mock of various third-party interfaces. Compared with the 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 the third-party system, and greatly improves the quality and efficiency of regression testing. Meanwhile, since the actual third-party system is avoided to be called, the embodiment also reduces the testing cost, reduces the dependence on external environment, enables the regression testing to be performed in a completely isolated environment, and improves the reliability and repeatability of the testing.

[0084] In a preferred embodiment, the Mock system can be optimized based on the symmetry breaking technique of directional spectrum division in step S3, and the interface calling information is classified and processed by an algorithm, and the HTTP interface Mock service and the Dubbo interface Mock service are constructed, and the specific steps S3.7 to S3.12 are as follows.

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

[0086] S3.8: graph spectrum analysis is performed on the interface calling dependency graph to obtain the Laplacian matrix of the interface calling dependency graph and the corresponding eigenvalue and eigenvector, and interface dependency features are generated based on the Laplacian matrix, the eigenvalue and the eigenvector.

[0087] 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 the 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.

[0088] S3.9: Identify the symmetric structure and pattern in the interface call dependency graph based on the interface dependency features, and generate an interface symmetry analysis report based on 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.

[0089] 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.

[0090] 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.

[0091] 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 realized. Specifically, first, the interfaces are preliminarily clustered according to the distribution of the feature vectors, and the 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.

[0092] S3.11: For the interface classification result, formulate Mock strategy for each interface category, the Mock strategy 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] Note that the symmetry breaking clustering and symmetric transformation response generation of the embodiment can generate an infinite number of possible responses based on limited sample data, which greatly reduces the data requirements and maintenance costs of the Mock service. 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.

[0098] In addition, the symmetry-based Mock strategy of 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.

[0099] Step S4: Based on the regression test case library and the Mock interface service set, perform multi-threaded parallel testing on the test tasks related to the regression test case library, and generate test result data, wherein the test result data includes the execution results of the test cases indicated in the regression test case library.

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

[0101] S4.1: Assign the test cases contained in the regression test case library to a plurality of test tasks that can be executed in parallel.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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".

[0107] 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.

[0108] 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.

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

[0110] 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.

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

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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 to ensure that important and urgent test tasks can be 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), 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.

[0117] 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; 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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 use case intelligent screening and Mock service construction link to form an efficient and reliable end-to-end regression test system.

[0126] 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.

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

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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 such as time fields, randomly generated identifiers, or other dynamic values with little business significance can be intelligently ignored according to configuration. 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, and the specific fields and values that do not match.

[0132] 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.

[0133] 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 configured, 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.

[0134] 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.

[0135] In the last step, the previously generated return value comparison results and performance comparison results are fully 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 allocate repair resources reasonably. The final test report is not only intuitive and easy to read but also rich in information, providing strong support for subsequent problem repair and system optimization.

[0136] 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.

[0137] As shown in Figure 3 The embodiment of the application also provides a regression test system based on traffic playback and Mock technology, which comprises: 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; 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; 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; 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 results of the test cases indicated in the regression test case library, and the execution results comprise interface return values, execution states and performance data; A 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 to generate a test report.

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

[0139] The regression test method and system based on traffic playback and Mock technology provided by the embodiment of the application can intelligently classify and sample online traffic data to 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 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.

[0140] The above is only a specific embodiment of the application, but the protection scope of the application is not limited to this. Any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the application, which should be covered within the protection scope of the application. Therefore, the protection scope of the 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 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; online traffic data is classified and sampled according to the test configuration data to generate a regression test case library; all third-party interface calling information is extracted from the regression test case library, the third-party interface calling information is classified and arranged through a preset interface classification and interception strategy, a Mock service for a specified protocol type is constructed, and a Mock interface service set is generated; 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, the test result data including an execution result of a test case indicated in the regression test case library; the test result data is compared in terms of return value and performance based on the regression test case library to generate a test report.

2. The method of claim 1, wherein, The regression test case library is generated by classifying and sampling online traffic data according to the test configuration data, and the method comprises the following steps: statistical analysis is performed on the online traffic data according to the traffic classification configuration information and the traffic selection strategy configuration information, and the number distribution of each traffic category and traffic subcategory in a specified time range is calculated to generate a traffic distribution statistical table; the traffic distribution statistical table and the traffic classification configuration information are proportionally calculated to determine the number of test cases that need to be selected for each traffic subcategory in each time period, and a traffic selection quota table is generated; a preset time-weighted random sampling strategy is used to select a corresponding number of test cases from online traffic data in different time periods according to the traffic selection quota table and the traffic selection strategy configuration information, and an initial traffic test case set is generated, 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; a preset proportion of abnormal traffic is selected based on the initial traffic test case set and the traffic selection strategy configuration information to generate a supplementary traffic test case set for supplementing abnormal traffic; the initial traffic test case set is converted, stored, and formatted according to the supplementary traffic test case set to generate a regression test case library.

3. The method of claim 2, wherein, The Mock interface service set is generated by extracting all third-party interface calling information from the regression test case library, classifying and arranging the third-party interface calling information through a preset interface classification and interception strategy, and constructing a Mock service for a specified protocol type, and the method comprises the following steps: data analysis is performed on the regression test case library and the third-party interface information to extract all third-party interface calling information, the third-party interface calling information including request parameters, return results, and calling time consumption; the third-party interface calling information is classified and processed according to protocol types and systems to generate multiple interface calling information sets, the interface calling information set including an HTTP interface calling information set, a Dubbo interface calling information set, and other types of interface calling information sets; The HTTP interface call information set is subjected to request interception, parameter matching and response simulation by using a preset Web filter algorithm to construct an HTTP interface Mock service; The Dubbo interface call information set is subjected to request interception, parameter matching and response simulation by using a preset Dubbo filter algorithm to construct a Dubbo interface Mock service; The other type interface call information set is subjected to request interception, parameter matching and response simulation by using an interception algorithm related to the other type interface call information set to construct an other type interface Mock service; 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, The test tasks related to the regression test case library are subjected to multi-thread parallel testing based on the regression test case library and the Mock interface service set to generate test result data, including: The test cases contained in the regression test case library are assigned as a plurality of 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 both 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; In response to the environment ready confirmation result, a plurality of test tasks are subjected to multi-thread parallel calling, and each thread executes one test case, and execution results of the test cases are collected, the execution results including interface return values, execution states and performance data, and original test result data is generated; Based on the original test result data, abnormal test cases that are executed overtime or fail are identified, and the abnormal test cases are retested, and compensation test result data is generated based on the original test result data and retest result data; 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, a preset configuration interface and / or a configuration file, return value comparison rules and performance threshold configuration rules are determined, wherein the return value comparison rules include ignored fields and comparison manners, and the performance threshold configuration rules include an allowed response time deviation percentage; The test result data, original return values 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, 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, The initial traffic use case set is generated by selecting a corresponding number of use cases from online traffic data of different time periods according to the traffic selection quota table and the traffic selection strategy configuration information using a preset time-weighted random sampling strategy, and includes the following steps: According to the traffic selection quota table, a PIPQ data structure with a double-layer structure is initialized to create an initialized PIPQ instance 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; According to the traffic selection strategy configuration information, online traffic data of different time periods is assigned to a plurality of worker threads for parallel processing to generate a candidate traffic set locally to each worker thread, wherein each worker thread is used to scan online traffic data of a specific time period or a specific partition; 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 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, the current highest priority element is periodically extracted from the thread-local priority queue of the worker level to update the index in the leader level to generate a sorted PIPQ instance; 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 sequentially extracted according to the quota limit of each traffic subcategory until the quota requirement is met to generate the initial traffic use case set.

7. The method of claim 6, wherein, The test result data is generated by performing multi-thread parallel testing on the test tasks related to the regression test case library based on the regression test case library and the Mock interface service set, and further includes the following steps: According to the regression test case library and the test requirements, a test task priority modeling process is performed to generate a test task priority model, which includes business importance, historical failure rate, and execution time weight configuration information; Based on the test task priority model, a PIPQ scheduler with a double-layer structure is initialized to create an initial PIPQ scheduler instance, and the PIPQ scheduler is used to manage and schedule the test tasks; The corresponding use case priority score is calculated for each test case in the regression test case library, and the test cases are inserted into the worker level queue of the PIPQ scheduler as test tasks in parallel according to the use case priority score to generate a filled PIPQ scheduler instance; The system resource status and 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; Under the cooperation of the filled PIPQ scheduler instance and the test execution thread pool, a worker thread extracts a test task with the highest priority from the PIPQ scheduler and executes the test task, and meanwhile, a new high-priority test task can be dynamically inserted, so as to collect the execution results of the test tasks and generate an original test result set.

8. The method of claim 7, wherein, The classification sampling processing of the online traffic data according to the test configuration data to generate the regression test case library further includes: 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; Based on the traffic feature space model, a variable whose influence on test coverage exceeds a preset influence threshold is identified as a test constraint variable for a constraint satisfaction problem; 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; 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; 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; 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 to generate an insufficient coverage area table, and the insufficient coverage area table and the test constraint relationship are solved by constraint to generate the supplementary traffic case set.

9. The method of claim 8, wherein, The Mock system is optimized based on a symmetry breaking technology of directional spectrum division, and the classification 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: The third-party interface call information is analyzed for a dependency relationship to construct an interface call dependency graph, 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; The interface call dependency graph is analyzed for a graph atlas to obtain a Laplacian matrix of the interface call dependency graph and corresponding eigenvalues and eigenvectors, and an interface dependency feature is generated based on the Laplacian matrix, the eigenvalues and the eigenvectors; Based on the interface dependency feature, a symmetric structure and a mode in the interface call dependency graph are identified, and an interface symmetry analysis report is generated through the symmetric structure and the mode, the interface symmetry analysis report being used to indicate positions and roles of the third-party interfaces in the symmetric structure; and The Mock system is optimized based on a symmetry breaking technology of directional spectrum division, and the classification 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: The third-party interface call information is analyzed for a dependency relationship to construct an interface call dependency graph, 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; The interface call dependency graph is analyzed for a graph atlas to obtain a Laplacian matrix of the interface call dependency graph and corresponding eigenvalues and eigenvectors, and an interface dependency feature is generated based on the Laplacian matrix, the eigenvalues and the eigenvectors; Based on the interface dependency feature, a symmetric structure and a mode in the interface call dependency graph are identified, and an interface symmetry analysis report is generated through the symmetric structure and the mode, the interface symmetry analysis report being used to indicate positions and roles of the third-party interfaces in the symmetric structure; and 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; For the interface classification result, a Mock strategy is formulated for each interface category, the Mock strategy including using a specified unified Mock template for an interface group with symmetry higher than a preset symmetry threshold, performing a specified high-precision Mock on a third-party interface on a key symmetry axis, and using a specified low-precision Mock for a third-party interface on the edge of a symmetry structure, and generating the interface call information set; Based on the interface symmetry analysis report, a symmetry transformation response generation mechanism is implemented using a response conversion algorithm, and when a request for a symmetric interface is received, an existing symmetry transformation response is subjected to symmetry transformation to generate a new symmetry transformation response.

10. A regression testing system based on traffic playback and Mock techniques, characterized in that, Comprising: a test configuration module configured to 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; 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; 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 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; a test execution module configured to perform multi-threaded 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, the test result data including execution results and performance data execution results of test cases indicated in the regression test case library, 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 to generate a test report.

Images