Defect retrieval method and system for software development test

Abstract

The invention belongs to the technical field of software testing, and provides a defect retrieval method and system for software development testing, which comprises the following steps: aiming at the problem of integrated logic test missing caused by overuse of a Mock object in a recognition unit test, and combining code coverage rate analysis and a Mock object optimization strategy to obtain a defect retrieval result; software defects caused by excessive Mock are accurately positioned and retrieved, the limited number of Mock objects in the unit test cases is determined according to the coverage rate of integrated logic codes during replacement of the Mock objects, unqualified unit test cases are identified in the unit test cases according to the limited number of the Mock objects, and necessity analysis is performed on the Mock objects in the unqualified unit test cases, so that the unit test cases are identified. By quantitatively evaluating the necessity of the Mock object, determining the reasonable use threshold and optimizing the test case, the integrity of the integrated logic test is effectively improved, the production environment defects caused by test distortion are reduced, and the software quality and stability are improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of software testing, in particular to a defect retrieval method and system for software development testing. BACKGROUND

[0002] In the software development testing process, unit testing can improve testing efficiency by isolating the tested unit from external dependencies using Mock objects, but excessive use of Mock objects can cause the test to deviate from the real environment and hide integration logic defects (such as abnormal data interaction between modules, transaction coordination failure, etc.). In the prior art, the rationality of Mock objects is mostly dependent on manual experience, lacking quantitative analysis means, making it difficult to accurately retrieve software defects caused by excessive Mock dependency, resulting in frequent integration logic-related failures in production environments.

[0003] By identifying the integration logic test missing problem caused by excessive use of Mock objects in unit testing, combining code coverage analysis and Mock object optimization strategies, accurately positioning and retrieving software defects caused by excessive Mock, and quantitatively evaluating the necessity of Mock objects, determining a reasonable use threshold, and optimizing test cases, the completeness of integration logic testing is effectively improved, reducing production environment defects caused by distorted testing, and improving software quality and stability.

[0004] To this end, the present application provides a defect retrieval method and system for software development testing. SUMMARY

[0005] In order to make up for the deficiencies of the prior art and solve at least one technical problem raised in the background art.

[0006] The technical solution adopted by the present application to solve its technical problems is:

[0007] The use range of Mock objects in unit testing is analyzed to determine whether there is excessive Mock dependency, and if so, it is marked as a Mock excessive dependency test case;

[0008] The integration logic code coverage of the Mock excessive dependency test case is analyzed to determine whether the integration logic has been effectively tested;

[0009] If not, the Mock objects in the unit test case that the integration logic has not been effectively tested are replaced step by step, and the integration logic code coverage before and after the replacement is compared and analyzed to determine whether the integration logic has not been effectively tested due to excessive Mock dependency;

[0010] If it is caused by excessive Mock dependency, the Mock object limit quantity in the unit test case is determined according to the integration logic code coverage when the Mock object is replaced;

[0011] According to the Mock object limitation quantity, unqualified unit test cases are identified in the unit test case, and necessity analysis is performed on the Mock objects in the unqualified unit test cases, and the Mock objects are replaced according to the analysis result.

[0012] Further, the way of judging whether there is Mock over-dependence is:

[0013] The number of modules replaced by the Mock object in the unit test case is counted, and proportional calculation is performed with the total number of modules depended on by the unit test case to obtain the Mock module number proportion;

[0014] Among the modules replaced by the Mock object, the number of modules with cross-module interaction properties is counted, and proportional calculation is performed with the number of modules replaced by the Mock object to obtain the cross-module interaction Mock proportion;

[0015] Among the modules replaced by the Mock object, the number of modules with cross-module interaction properties is counted, and proportional calculation is performed with the number of modules replaced by the Mock object to obtain the cross-module interaction Mock proportion;

[0016] The Mock module number proportion and the module interaction Mock proportion are added to obtain a Mock dependency value, and the Mock dependency value is compared with a preset dependency value;

[0017] If the Mock dependency value is greater than the preset dependency value, there is Mock over-dependence in the unit test.

[0018] Further, the way of judging whether the integrated logic is effectively tested is:

[0019] The total number of lines of integrated logic code in the test process and the number of lines of integrated logic code covered by the unit test are counted;

[0020] The number of lines of integrated logic code covered by the unit test is proportional to the total number of lines of integrated logic code to obtain an integrated logic code coverage rate;

[0021] The integrated logic code coverage rate is compared with a preset coverage rate, and if the integrated logic code coverage rate is less than the preset coverage rate, the integrated logic in the unit test is not effectively tested.

[0022] Further, the process of judging whether the integrated logic is not effectively tested due to Mock over-dependence is:

[0023] For the Mock objects in the unit test class in which the integrated logic is not effectively tested, the replacement priority is determined;

[0024] Remove mock objects in the test one by one according to their replacement priority, and use real service implementations through dependency injection. After each replacement, record the integration logic code coverage of the unit test case.

[0025] Mark the effective test cases according to the coverage of the integrated logic code after each replacement, and then obtain the proportion of effective test cases;

[0026] Compare the proportion of valid test cases with the proportion threshold. If the proportion of valid test cases is greater than or equal to the proportion threshold, the integration logic is not effectively tested due to excessive mocking.

[0027] Furthermore, the replacement priority is determined as follows:

[0028] Count the number of times the unit under test calls dependencies in normal business processes, and sort the dependencies to be replaced by mock objects by the number of calls. The sorting result is the replacement priority of the mock objects.

[0029] Furthermore, the calculation method of the effective test case ratio is:

[0030] For each unit test case, calculate the difference between the integration logic code coverage after each replacement of the Mock object and before the replacement, and compare it with the set significant increase threshold;

[0031] If the difference before and after the replacement is greater than the significant increase threshold, it is determined that the replacement has significantly improved the integrated logic code coverage;

[0032] If the coverage of the integrated logic code is significantly improved after at least one replacement in the unit test case, the unit test case is marked as a valid test case;

[0033] For all unit test cases whose integration logic has not been effectively tested, count the number of effective test cases and calculate the ratio with the number of unit test cases whose integration logic has not been effectively tested to obtain the proportion of effective test cases.

[0034] Furthermore, the method for determining the limit number of Mock objects is as follows:

[0035] For each unit test case, during the replacement of the Mock object, record the coverage of the integrated logic code after each replacement and generate a coverage sequence [c0, c1, ..., c m ], where m is the integration logic code coverage after replacing the Mock object for the mth time;

[0036] For the coverage sequence [c0,c1,...,c mk times of replacement tests are performed, according to the replacement test results, a minimum k value is selected from all k values meeting the standard, and then c k+1 is the first significant growth coverage, c k+1 The number of remaining Mock objects in the corresponding unit test case is the Mock object limit number.

[0037] Further, the judgment method of the k value meeting the standard is:

[0038] The coverage sequence [c0, c1,..., c m ] is divided into a stable segment and a growth segment based on the k value, wherein the stable segment is [c0, c1,..., c k ], and the growth segment is [c k ,c k+1 ,...,c m ];

[0039] The judgment standard of k is set based on the stable segment and the growth segment:

[0040] The slope s 稳定 (k) of the stable segment is 0, that is, there is no obvious growth trend in the early stage;

[0041] The slope s 增长 (k) of the growth segment is greater than β, wherein β is a set significant growth threshold, that is, there is a significant upward trend in the later stage;

[0042] The slope difference Δs(k) is greater than γ, wherein γ is a preset difference threshold, that is, the trend difference between the stable segment and the growth segment is significant;

[0043] Each growth amount c k+1 -c k of the growth segment of the k+1th replacement exceeds the maximum single growth amount in the stable segment, that is, c k+1 -c k >max|c i -c i-1 | 稳定 ;

[0044] Wherein, the acquisition method of each growth amount of the growth segment and the maximum single growth amount in the stable segment is:

[0045] For the coverage sequence, starting from the second element, the difference between each element and the previous element is calculated to obtain the growth amount, which includes: the each growth amount c k+1 -c k of the growth segment and the maximum single growth amount max|c i -c i-1 | 稳定 in the stable segment, wherein c iThe integrated logic code coverage rate after the i-th replacement in the stable stage.

[0046] Further, the necessity analysis on the Mock object in the unqualified unit test case and the process of replacing the Mock object according to the analysis result are as follows:

[0047] For each unit test case, the number of Mock objects is compared with the Mock object limit number, and the unit test case greater than the Mock object limit number is divided into an unqualified unit test case;

[0048] For the unqualified unit test case, the code coverage tool is used to execute the unqualified unit test case to generate a coverage report, and the code line in the integrated logic range with a coverage rate of 0 is screened out;

[0049] For the real dependency replaced by the Mock object in the unqualified unit test case, it is checked whether the real dependency directly participates in the execution of the integrated logic code line with a coverage rate of 0;

[0050] If the real dependency corresponding to the Mock object directly participates in the integrated logic code line with a coverage rate of 0, the Mock object is an unnecessary Mock object;

[0051] All unnecessary Mock objects in the unqualified unit test case are replaced by real dependencies.

[0052] A defect retrieval system for software development testing, comprising the following modules:

[0053] Mock over-reliance identification module: analyzing the use range of the Mock object in the unit test, judging whether there is Mock over-reliance, and if so, marking as a Mock over-reliance test case;

[0054] Integrated logic test effectiveness evaluation module: analyzing the integrated logic code coverage rate of the Mock over-reliance test case, and judging whether the integrated logic is effectively tested;

[0055] Mock over-reliance cause verification module: if not effectively tested, the Mock object in the unit test case in which the integrated logic is not effectively tested is replaced step by step, and the integrated logic code coverage rate before and after the replacement is compared and analyzed to judge whether the integrated logic is not effectively tested due to Mock over-reliance;

[0056] Mock object limit number determination module: if it is due to Mock over-reliance, the Mock object limit number in the unit test case is determined according to the integrated logic code coverage rate when the Mock object is replaced;

[0057] The test case optimization and Mock replacement module identifies unqualified unit test cases in the unit test cases according to the Mock object limit quantity, analyzes the necessity of Mock objects in the unqualified unit test cases, and replaces the Mock objects according to the analysis result.

[0058] The beneficial effects of the present application are as follows: by identifying the problem of missing integrated logic testing caused by excessive use of Mock objects in unit testing, combining code coverage analysis and Mock object optimization strategy, accurately positioning and retrieving software defects caused by excessive Mock, by quantitatively evaluating the necessity of Mock objects, determining a reasonable use threshold, optimizing test cases, replacing manual judgment with data-driven (such as comprehensive risk index, coverage difference), improving the accuracy of defect retrieval, focusing on defects caused by excessive Mock, avoiding blind optimization of all test cases, saving testing resources, replacing unnecessary Mock, covering real integrated scenarios, retrieving defects hidden in traditional testing, effectively improving the integrity of integrated logic testing, reducing defects in production environment caused by distorted testing, and improving software quality and stability. BRIEF DESCRIPTION OF DRAWINGS

[0059] The present application will be further described below with reference to the accompanying drawings.

[0060] Figure 1 is a step flow chart of a defect retrieval method for software development testing according to the embodiment 1 of the present application;

[0061] Figure 2 is a logic judgment chart of a defect retrieval method for software development testing according to the embodiment 1 of the present application;

[0062] Figure 3 is a program block diagram of a defect retrieval system for software development testing according to the embodiment 2 of the present application. DETAILED DESCRIPTION

[0063] In order to make the technical means, creative features, purposes and effects of the present application easy to understand, the present application will be further described below with reference to the specific embodiments.

[0064] Embodiment 1

[0065] Please refer to Figure 1 The defect retrieval method for software development testing according to the embodiment of the present application includes the following steps:

[0066] Step 1: analyze the use range of Mock objects in unit testing, judge whether there is Mock over-reliance, if there is, mark it as Mock over-reliance test case;

[0067] In step one, the Mock object is a virtual object that mimics the behavior of the actual object, but does not contain the actual implementation logic. Mock objects are used to replace real object dependencies to control the test environment. The role of Mock objects is:

[0068] Isolate the unit under test to avoid the side effects of real dependencies (such as network calls, database access);

[0069] Simulate various scenarios (such as exceptions, specific return values) to improve test coverage;

[0070] Verify the interaction behavior with the dependent object (such as method call times, parameters, etc.);

[0071] Mock objects are used in the following application scenarios of unit testing:

[0072] Dependencies cannot be accessed or controlled: such as remote services, external APIs, databases, etc. Mock these dependencies to ensure stable testing;

[0073] Complex dependency initialization: some dependent objects require complex setup or configuration. Using Mock simplifies the initialization of dependencies;

[0074] Verify interaction behavior: ensure that the unit under test correctly calls the methods of the dependent object and passes the correct parameters;

[0075] Simulate exception scenarios: simulate the error behavior of dependent objects (such as throwing exceptions) to test boundary conditions;

[0076] In step one, the process of determining whether there is Mock over-reliance includes:

[0077] Use the reporting function of the test framework to export a list of all test cases, including test name, method name, and test purpose;

[0078] According to the function modules targeted by the test cases, classify them, for example: test cases related to user management are classified as the user management module, and test cases related to order processing are classified as the order module, etc. Through classification, a clear test case module attribution list is formed to facilitate subsequent focus on the testing of each module;

[0079] For each divided test case, count the number of external resources or modules relied on during execution, and specify the dependency type, which may include other software modules, databases, third-party services, file systems, etc. Each dependency is marked in the test case to form a dependency type marker list for each test case;

[0080] According to the official documents of the programming language and test framework used, determine the set of keywords representing Mock, and perform a line-by-line review of the code for each test case to filter out test cases containing Mock keywords in the test code;

[0081] For test cases using Mock objects, build a dependency mapping table to record the name or number of each test case, as well as the name of the dependency module being Mocked, and simultaneously mark the real module name, function, and role in the system that the Mock module replaces;

[0082] Statistically count the number of modules replaced by Mock objects in the dependency mapping table of each unit test case, and calculate the proportion of Mock module quantity based on the total number of dependency modules;

[0083] Among the modules replaced by Mock objects, mark the modules with cross-module interaction properties by comparing the system architecture diagram, and count the number of modules with cross-module interaction properties, where cross-module interaction properties represent modules that have cross-module data transmission, state changes, and business collaboration, etc.;

[0084] Calculate the proportion of modules involved in cross-module interaction and the number of modules replaced by Mock objects to obtain the cross-module interaction Mock proportion;

[0085] Add the Mock module quantity proportion and the cross-module interaction Mock proportion to obtain the Mock dependency value, and compare the Mock dependency value with the preset dependency value. If the Mock dependency value is greater than the preset dependency value, there is a Mock over-dependency problem in the unit test;

[0086] It can be understood that the physical meaning of the Mock dependency value is that it quantitatively reflects the Mock dependency degree, taking into account both the size of the Mock and the influence range of the interaction logic, improving the accuracy of judgment;

[0087] The role of determining whether there is a Mock over-dependency problem in the unit test according to the Mock dependency value is:

[0088] Role 1: By quantitatively evaluating the degree of Mock usage, it reflects the degree of dependence on virtual objects in the test environment and the impact of this dependence on the interaction logic between modules. It can quickly and accurately determine whether there is a Mock over-dependency problem in the unit test. Excessive dependence on Mocks can cause the test to deviate from the real environment and fail to effectively verify the integration logic. Through strict analysis of the scope of Mock usage, it can timely discover and correct the problem of excessive Mock, reduce defects in the production environment caused by distorted tests, and ensure that the test results can truly reflect the state of the software in actual operation, improving software quality and stability;

[0089] Action 2: After marking the test cases that excessively rely on Mock, the focus and direction of subsequent test optimization work can be indicated. These problematic test cases can be further analyzed to determine the necessity of Mock objects, and the Mock usage strategy can be adjusted or integrated testing can be supplemented, thereby improving the overall test system and enhancing the comprehensiveness and effectiveness of testing;

[0090] Step two: Analyze the integration logic code coverage of the Mock excessively dependent test cases to determine whether the integration logic is effectively tested.

[0091] In step two, the integration logic code refers to the code that implements the interaction behavior between modules, including:

[0092] Cross-module interface calling code: the implementation logic of method calling between different modules (such as A module calling B module's getOrderInfo() method);

[0093] Data interaction processing logic: serialization / deserialization, format conversion code for data transmission between modules (such as JSON data parsing logic between modules);

[0094] State coordination control code: control logic for multi-module state synchronization (such as the trigger mechanism for notifying the inventory module after the order module modifies the state);

[0095] Transaction boundary code: key code for cross-module transaction management (such as the commit / rollback coordination logic of each module in distributed transactions);

[0096] In step two, the process of determining whether the integration logic is effectively tested includes:

[0097] Use code analysis tools to identify integration logic code and count the number of lines, which is the total integration logic code line number. Integration logic code mainly refers to code segments related to module interface calling, data transmission, transaction processing, and other interaction behaviors;

[0098] During the unit test running process, use code analysis tools to record the actual number of code lines executed through bytecode instrumentation technology, which is the integration logic code line number covered by unit testing;

[0099] Calculate the integration logic code coverage by comparing the integration logic code line number covered by unit testing with the total integration logic code line number;

[0100] Compare the integration logic code coverage with the preset coverage. If the integration logic code coverage is less than the preset coverage, the integration logic in the unit test is not effectively tested;

[0101] It can be understood that quantitatively evaluating the coverage of unit testing on integrated logic from the code execution level, automatically collecting and calculating coverage data through tools, accurately positioning the missing unit test classes of integrated logic testing, providing objective basis for subsequent improvement of test cases and supplement of integrated logic testing, effectively avoiding system-level defects caused by insufficient testing of integrated logic, and ensuring the correctness of the interaction function between system modules;

[0102] Step three: if not effectively tested, whether the integrated logic not effectively tested is caused by excessive Mock by gradually replacing the Mock objects in the unit test cases of the integrated logic not effectively tested, and comparing and analyzing the integrated logic code coverage before and after replacement;

[0103] In step three, the process of determining whether the integrated logic not effectively tested is caused by excessive Mock includes:

[0104] For Mock objects in unit test classes of integrated logic not effectively tested, determine the replacement priority, which is determined according to the degree of relevance between the replaced Mock object and the integrated logic of the unit under test, including:

[0105] Count the number of times the dependent is called in the normal business process, the more the number of calls, the higher the degree of relevance, and sort the replaced Mock object dependencies by call number as the replacement priority of the Mock object;

[0106] Build a test environment, start other microservices dependent on the module under test, create an independent test database, isolate it from the production data, and initialize it with test data;

[0107] According to the replacement priority of the Mock object, remove the Mock object in the test configuration in turn, and use the real service implementation through dependency injection, record the integrated logic code coverage corresponding to the unit test case after each replacement;

[0108] For each unit test case, calculate the difference in integrated logic code coverage after each replacement of the Mock object and before the replacement, and compare it with the set significance growth threshold, if the difference before and after the replacement is greater than the significance growth threshold, it is determined that the replacement has significantly improved the integrated logic code coverage;

[0109] If the integrated logic code coverage is significantly improved after at least one replacement in the unit test case, mark the unit test case as an effective test case;

[0110] For all unit test cases of integrated logic not effectively tested, count the number of effective test cases, and calculate the proportion of effective test cases to the number of unit test cases of integrated logic not effectively tested.

[0111] The proportion threshold is set, and the effective test case proportion is compared with the proportion threshold. If the effective test case proportion is greater than or equal to the proportion threshold, it is indicated that most of the integrated logic that is not effectively tested by the unit test case can be solved by replacing the Mock, that is, the integrated logic that is not effectively tested is caused by excessive dependence on Mock;

[0112] It can be understood that the physical meaning of the effective test case proportion is that the effective test case proportion refers to the proportion of the number of test cases that can significantly improve the integrated logic code coverage by replacing the Mock object among all the integrated logic that is not effectively tested by the unit test case, and the total number, which quantifies the influence of "excessive Mock" on the integrated logic test loss. The higher the proportion, the more test cases that originally do not effectively test the integrated logic can improve the test effect by reducing Mock (replaced by real service), that is, excessive Mock is the main reason for the integrated logic that is not effectively tested. On the contrary, the lower the proportion, the more integrated logic test loss is caused by other factors rather than excessive Mock;

[0113] By comparing the integrated logic code coverage before and after replacing the Mock, it is accurately judged whether the root cause of the integrated logic that is not effectively tested is excessive dependence on Mock. The effects include:

[0114] Effect 1: Distinguish whether the integrated logic test loss is caused by "excessive dependence on Mock (leading to real interaction not being tested)" or "insufficient design of test cases", to avoid blindly adjusting the test strategy;

[0115] Effect 2: By the coverage change data, the necessity of the current Mock object is objectively evaluated. If the coverage is significantly improved after replacement, it is indicated that the dependency that is Mocked is strongly related to the integrated logic, and excessive Mock hides the real interaction scenario;

[0116] Effect 3: If it is determined that excessive Mock causes it, unnecessary Mock objects can be reduced, and dependencies that significantly improve the coverage are preferentially replaced to improve the test effectiveness;

[0117] The beneficial effects of judging whether the integrated logic that is not effectively tested is caused by excessive Mock include:

[0118] Through data comparison (coverage difference, threshold judgment), we can avoid the problem of subjective judgment of "over-mock", make the conclusion more objective and reliable, and optimize only the test deficiencies caused by excessive mocking. There is no need to blindly adjust all use cases, saving the time cost of environment construction and use case reconstruction. After clarifying the mock objects that need to be replaced, we can introduce real service interactions in a targeted manner to cover the integration scenarios originally shielded by mocks (such as interface calls, data interactions, exception handling, etc.), improve test integrity, and provide data support for test strategy optimization: In the long run, by accumulating coverage impact data of different mock objects, we can form a "mock rationality evaluation standard" to guide the use of mocks in subsequent test case design (such as which dependencies should avoid mocking and which can be safely mocked);

[0119] Step 4: If the problem is caused by excessive use of mocks, determine the limit on the number of mock objects in the unit test case based on the integrated logic code coverage when the mock objects are replaced;

[0120] In step 4, the process of determining the limit number of Mock objects according to the integrated logic code coverage during Mock object replacement includes:

[0121] For each unit test case, during the replacement of the Mock object, run the unit test after each replacement, collect the coverage data of the integrated logic code, record the coverage of the integrated logic code after each replacement, and generate the coverage sequence [c0, c1, ..., c m ], where m is the integration logic code coverage after replacing the Mock object for the mth time;

[0122] Assume that a sudden change occurs after the kth replacement, that is, the stable segment: [c0, c1, ..., c k ](When replacing 0 to k Mock objects, the coverage is in a stable state), growth segment: [c k ,c k+1 ,...,c m ](Starting from replacing k+1 Mock objects, the coverage enters the growth state), the goal is to find the smallest k so that the trend difference between the stable segment and the growth segment reaches the "significant" level;

[0123] The trend slopes of the stable and growing segments were calculated by linear regression, and the standard deviations of the coverage rates of the stable and growing segments were calculated.

[0124] Traverse all possible k (from k = 0 to k = m-1), and calculate for each k: the slope of the stable segment s 稳定 (k) and the slope of the growth segment s 增长 (k), and calculate the slope difference Δs(k)=s 增长 (k)-s稳定 (k);

[0125] For the coverage sequence, starting from the second element, the difference between each element and the previous element is calculated to get the growth amount, which includes: the growth amount c of each growth segment k+1 -c k and the maximum single growth amount max|c within the stable segment i -c i-1 | 稳定 ;

[0126] Setting judgment criteria:

[0127] Steady phase slope s 稳定 (k) = 0, which means there is no obvious growth trend in the early stage;

[0128] Growth slope s 增长 (k)>β, where β is the set significant growth threshold, that is, there is a clear upward trend in the later period;

[0129] The slope difference Δs(k)>γ, where γ is the preset difference threshold, indicating that the trend difference between the two ends is significant;

[0130] The amount of growth c of each growth segment replaced in the k+1th time k+1 -c k Exceeding the maximum single growth in the stable segment, that is, c k+1 -c k >max|c i -c i-1 | 稳定 ,,where ci is the integrated logic code coverage after the ith replacement in the stable segment,,ensuring that this growth is not a continuation of the previous fluctuation;

[0131] From all k that meet the judgment criteria, select the smallest k, that is, the position where the trend mutation occurs for the first time, and the corresponding c k+1 This is the first significant increase in coverage, c k+1 The number of Mock objects remaining in the corresponding unit test case is the limit number of Mock objects;

[0132] It can be understood that the physical meaning of the limit on the number of mock objects in unit test cases is: under the premise of ensuring the isolation of the core unit test, the minimum number of mock objects retained can trigger the effective testing of the integration logic code. The limit is the balance point between "isolation" and "integration testability". When the limit is lower than the limit, the integration logic is fully tested but the isolation is insufficient. When the limit is higher than the limit, the isolation is too strong but the integration logic is not covered. The number of mock objects corresponding to the limit itself can achieve the optimal balance between the two.

[0133] For example, assume that the coverage sequence is: C = [30%, 31%, 30%, 32%, 45%, 58%, 60%] (coverage when replacing 0 to 6 mock objects);

[0134] Stable segment analysis (first 4 points, k-3): The stable segment is [30%, 31%, 30%, 32%], the slope is close to 0, and the maximum fluctuation is 1%;

[0135] Growth segment analysis: (starting from k=3): The growth segment is [45%, 58%, 60%], with a significantly positive slope. The increment of the fourth replacement is 13%, which is much larger than the maximum fluctuation of the stable segment (1%), and the slope difference is significant.

[0136] Conclusion: The first significant increase occurs at i=4 (after replacing 4 mock objects), that is, k=3 is the mutation point, which means that the limit number of mock objects in this unit test case is 6-4=2;

[0137] By analyzing the changing patterns of the integrated logic code coverage during the replacement of mock objects, we can accurately determine the appropriate number of mock objects in unit test cases. This has the following benefits:

[0138] Through methods such as linear regression, slope analysis, and fluctuation comparison, the judgment of "whether coverage has increased significantly" is converted into quantifiable indicators (such as the slope of the stable period is close to 0, the slope of the growth period is significantly positive, and the increment exceeds the previous maximum fluctuation). This avoids subjective judgment bias and uses a data-driven approach to find a balance between "mock isolation" and "integration logic testability." The limited number of mock objects it outputs provides a clear and executable standard for optimizing unit test cases and improving integration logic coverage.

[0139] Step 5: Identify unqualified unit test cases in the unit test cases based on the limited number of mock objects, conduct a necessity analysis on the mock objects in the unqualified unit test cases, and replace the mock objects based on the analysis results;

[0140] In step 5, the process of performing necessity analysis on the Mock objects in the unqualified unit test cases and replacing the Mock objects according to the analysis results includes:

[0141] For each unit test case, compare the number of mock objects with the limit number of mock objects, and classify the unit test cases with a number greater than the limit number of mock objects as unqualified unit test cases;

[0142] Use code coverage tools to pinpoint key lines of code that are not covered by tests. The core lines of code for integration logic typically include:

[0143] Cross-module interface calls: such as the code for service A calling the / api / order interface of service B, and the producer / consumer code for modules to communicate through message queues.

[0144] Transaction boundary code: such as transaction commit / rollback logic within methods marked with the @Transactional annotation, branch transaction coordination code in distributed transactions, etc.

[0145] Data interaction logic: such as JOIN statement execution code for cross-database queries, cache and database synchronization logic, etc.

[0146] For unqualified unit test cases, use a code coverage tool to execute the unqualified unit test cases, generate a coverage report, and filter out code lines with zero coverage within the integration logic range;

[0147] For real dependencies replaced by mock objects in unqualified unit test cases, check whether the real dependencies are directly involved in the execution of integration logic code lines with zero coverage;

[0148] If the real dependency corresponding to the mock object directly participates in the integration logic code line with a coverage rate of 0, the mock object is an unnecessary mock object;

[0149] It can be understood that by accurately associating uncovered integration logic code with the real dependencies of the Mock objects, it is possible to determine whether the Mock objects are unnecessary, providing a basis for subsequent replacement of Mock objects and improving the coverage of integration logic tests;

[0150] Replace all unnecessary mock objects in unqualified unit test cases with real dependencies. After the replacement is completed, compare the number of remaining mock objects with the mock object limit. If the number of remaining mock objects is less than the mock object limit, the unqualified test case is converted to a qualified test case after the replacement of the mock objects.

[0151] Through quantitative analysis and precise replacement, unit testing is pushed from "excessive isolation" to "moderate integration." While ensuring test efficiency, it effectively verifies the integration logic of the system during actual runtime. This avoids both the testing blind spots caused by "isolation for isolation's sake" and the surge in testing costs caused by "blind integration," ultimately improving software quality, stability, and maintainability.

[0152] The technical solutions and benefits of the embodiments of the present application are:

[0153] The use range of the Mock object in the unit test is analyzed, whether Mock over-reliance exists is judged, if the Mock over-reliance exists, the Mock over-reliance test case is marked, the integration logic code coverage of the Mock over-reliance test case is analyzed, whether the integration logic is effectively tested is judged, if the integration logic is not effectively tested, the Mock object in the unit test case in which the integration logic is not effectively tested is replaced step by step, and the integration logic code coverage before and after replacement is compared and analyzed, whether the integration logic is not effectively tested is caused by over-Mock is judged, if the integration logic is not effectively tested is caused by over-Mock, the Mock object limit quantity in the unit test case is determined according to the integration logic code coverage when the Mock object is replaced, the unqualified unit test case in the unit test case is identified according to the Mock object limit quantity, and the Mock object in the unqualified unit test case is analyzed in necessity, and the Mock object is replaced according to the analysis result. The application identifies the integration logic test missing problem caused by the overuse of the Mock object in the unit test, combines the code coverage analysis with the Mock object optimization strategy, accurately locates and retrieves the software defects caused by the overuse of the Mock object, quantitatively evaluates the necessity of the Mock object, determines a reasonable use threshold, optimizes the test case, effectively improves the integrity of the integration logic test, reduces the production environment defects caused by test distortion, and improves software quality and stability.

[0154] Embodiment 2

[0155] Please refer to Figure 3 The defect retrieval system for software development test provided by the embodiment of the application comprises the following modules:

[0156] The Mock over-reliance identification module analyzes the use range of the Mock object in the unit test, judges whether Mock over-reliance exists, and marks the Mock over-reliance test case if the Mock over-reliance exists;

[0157] The Mock object is a virtual object that simulates the behavior of an actual object but does not contain the actual implementation logic, and the Mock object is used to replace the dependency of the real object to control the test environment, and the Mock object has the following functions:

[0158] Isolating the unit under test to avoid the side effects of real dependencies (such as network calls, database access);

[0159] Simulating various scenarios (such as exceptions, specific return values) to improve test coverage;

[0160] Verifying the interaction behavior with the dependent object (such as the number of method calls, parameters, etc.);

[0161] The application scenarios of the Mock object in the unit test include:

[0162] Dependence on inaccessible or uncontrollable: such as remote services, external APIs, databases, etc. These dependencies are simulated by Mock to ensure stable testing;

[0163] Complex dependency initialization: some dependent objects require complex setup or configuration, and Mock simplifies the initialization of dependencies;

[0164] Verify interaction behavior: ensure that the unit under test correctly calls the methods of the dependent object and passes the correct parameters;

[0165] Simulate exception scenarios: simulate the error behavior of dependent objects (such as throwing exceptions) to test boundary conditions;

[0166] The process of determining whether there is an over-reliance on Mock includes:

[0167] Export all test case lists using the reporting function of the test framework, including test name, method name, and test purpose;

[0168] According to the function modules targeted by the test cases, for example: user management related test cases are classified as user management modules, order processing related test cases are classified as order modules, etc. Through classification, a clear test case module attribution list is formed, which facilitates subsequent focus on the test situation of each module;

[0169] For each divided test case, count the number of external resources or modules depended on during execution, and specify the dependency type, which may include other software modules, databases, third-party services, file systems, etc. Each dependency is marked in the test case to form a dependency type marker list for each test case;

[0170] According to the official documents of the programming language and test framework used, determine the keyword set representing Mock, and perform line-by-line review of each test case code to filter out test cases containing Mock keywords in the test code;

[0171] For test cases using Mock objects, construct a dependency mapping table to record the name or number of each test case and the name of the dependent module that is Mocked, and simultaneously mark the real module name, function, and role in the system that is replaced by the Mock module;

[0172] Statistical each unit test case in the dependency mapping table of the number of modules replaced by Mock objects, and do proportional calculation with the total number of dependent modules to get the proportion of Mock module number;

[0173] In the module replaced by the Mock object, mark the modules with cross-module interaction properties according to the system architecture diagram, and count the number of modules with cross-module interaction properties, wherein the cross-module interaction properties represent that the module has cross-module data transmission, state change, business cooperation and the like;

[0174] The number of modules related to cross-module interaction is proportionally calculated with the number of modules replaced by the Mock object to obtain a cross-module interaction Mock proportion;

[0175] The Mock dependency value is obtained by adding the Mock module proportion and the cross-module interaction Mock proportion, and the Mock dependency value is compared with the preset dependency value. If the Mock dependency value is greater than the preset dependency value, there is a Mock over-dependence problem in the unit test;

[0176] It can be understood that the physical meaning of the Mock dependency value is that the Mock dependency degree is quantitatively reflected, both the number scale of the Mock and the influence range of the interaction logic are considered, and the judgment accuracy is improved;

[0177] The role of judging whether there is a Mock over-dependence problem in the unit test according to the Mock dependency value is:

[0178] Role 1: The Mock usage degree is quantitatively evaluated, the dependency degree of the virtual object in the test environment is reflected, and the influence of such dependency on the interaction logic between modules is reflected. Whether there is a Mock over-dependence problem in the unit test can be quickly and accurately determined. Over-dependence on Mock will cause the test to be disconnected from the real environment, and the integrated logic cannot be effectively verified. Through strict analysis of the Mock usage range, the over-Mock problem can be found and corrected in time, the production environment defects caused by test distortion are reduced, the test result can reflect the state of the software in actual operation, and the software quality and stability are improved;

[0179] Role 2: After the test cases with over-dependence are marked, the focus and direction of subsequent test optimization work can be indicated. These problem cases can be further analyzed for the necessity of Mock objects, and the Mock usage strategy can be reasonably adjusted or integrated testing can be supplemented, so as to perfect the entire test system and improve the comprehensiveness and effectiveness of the test;

[0180] Integrated logic test effectiveness evaluation module: the integrated logic code coverage of the Mock over-dependence test case is analyzed to determine whether the integrated logic is effectively tested;

[0181] The integrated logic code refers to the code for implementing the interaction behavior between modules, including:

[0182] Cross-module interface call code: implementation logic of method calls between different modules (such as A module calling B module's getOrderInfo() method);

[0183] Data interaction processing logic: serialization / deserialization, format conversion code for data transmission between modules (such as JSON data parsing logic between modules);

[0184] State coordination control code: control logic for multi-module state synchronization (such as the trigger mechanism for notifying the inventory module after the order module modifies the state);

[0185] Transaction boundary code: key code for cross-module transaction management (such as commit / rollback coordination logic for each module in a distributed transaction);

[0186] The process of judging whether the integration logic is effectively tested includes:

[0187] Use code analysis tools to identify integration logic code, count the number of lines, which is the total integration logic code lines, where integration logic code mainly refers to code segments related to module interface calls, data transmission, transaction processing, and other interaction behaviors;

[0188] During the unit test running process, use code analysis tools to record the actual executed code lines through bytecode instrumentation technology, which is the integration logic code lines covered by unit testing;

[0189] Calculate the integration logic code coverage rate by proportioning the integration logic code lines covered by unit testing and the total integration logic code lines;

[0190] Compare the integration logic code coverage rate with the preset coverage rate. If the integration logic code coverage rate is less than the preset coverage rate, the integration logic in the unit test is not effectively tested;

[0191] It can be understood that the coverage degree of unit testing on integration logic is quantitatively evaluated from the code execution level, the coverage rate data is automatically collected and calculated by tools, and the unit test class with missing integration logic testing is accurately located. This provides an objective basis for subsequent improvement of test cases and supplement of integration logic testing, effectively avoids system-level defects caused by insufficient testing of integration logic, and ensures the correctness of the interaction function between system modules;

[0192] Mock over-reliance on causal verification modules: if not effectively tested, replace the Mock object in the unit test case with missing integration logic testing step by step, and compare and analyze the integration logic code coverage rate before and after replacement to determine whether the missing integration logic testing is caused by excessive Mock;

[0193] The process of determining whether the integration logic is not effectively tested due to excessive reliance on mocks includes:

[0194] For mock objects in unit test classes whose integration logic has not been effectively tested, determine the replacement priority. The replacement priority is determined based on the relevance of the dependency replaced by the mock object to the integration logic of the unit under test, including:

[0195] Count the number of times the unit under test calls dependencies in normal business processes. The more calls, the higher the relevance. The dependencies to be replaced by the mock objects are sorted by the number of calls as the replacement priority of the mock objects.

[0196] Set up the test environment, start other microservices that the module under test depends on, create an independent test database, isolate it from production data, and initialize it with test data;

[0197] Remove mock objects from the test configuration one by one according to their replacement priority, and use real service implementations through dependency injection. After each replacement, record the integration logic code coverage of the unit test case.

[0198] For each unit test case, calculate the difference between the integration logic code coverage after each replacement of the mock object and before the replacement, and compare it with the set significant increase threshold. If the difference before and after the replacement is greater than the significant increase threshold, it is determined that the replacement has significantly improved the integration logic code coverage;

[0199] If the coverage of the integrated logic code is significantly improved after at least one replacement in the unit test case, the unit test case is marked as a valid test case;

[0200] For all unit test cases where the integration logic has not been effectively tested, count the number of valid test cases and calculate the ratio of them to the number of unit test cases where the integration logic has not been effectively tested to obtain the ratio of valid test cases.

[0201] Set a percentage threshold and compare the percentage of valid test cases with the percentage threshold. If the percentage of valid test cases is greater than or equal to the percentage threshold, it means that most unit test cases where the integration logic is not effectively tested can be solved by replacing mocks. In other words, the ineffective testing of the integration logic is caused by excessive reliance on mocks.

[0202] It can be understood that the physical meaning of the effective test case proportion is that the effective test case proportion refers to the proportion of the number of test cases that can significantly improve the integrated logic code coverage by replacing the Mock object in all integrated logic unit test cases that are not effectively tested, which quantifies the influence degree of "over Mock" on the integrated logic test loss. The higher the proportion, the more test cases that are not effectively tested for integrated logic, and the test effect can be improved by reducing Mock (replaced by real service). That is, over Mock is the main reason for the ineffective test of integrated logic. On the contrary, the lower the proportion, the more integrated logic test loss is caused by other factors rather than over Mock;

[0203] By comparing the integrated logic code coverage before and after replacing Mock, it can be accurately judged whether the root cause of the ineffective test of integrated logic is over Mock. The effects include:

[0204] Effect 1: Distinguish whether the integrated logic test loss is caused by "over-reliance on Mock (leading to real interaction not being tested)" or "insufficient design of test cases", to avoid blindly adjusting the test strategy;

[0205] Effect 2: Objectively evaluate the necessity of the current Mock object through coverage change data. If the coverage significantly improves after replacement, it means that the Mocked dependency is strongly related to the integrated logic, and over Mock hides the real interaction scenario;

[0206] Effect 3: If it is determined that over Mock is the cause, unnecessary Mock objects can be reduced, and dependencies that significantly improve coverage can be replaced first to improve test effectiveness;

[0207] The beneficial effects of determining whether the ineffective test of integrated logic is caused by over Mock include:

[0208] Through data comparison (coverage difference, threshold judgment), the problem of subjective judgment of "over Mock" is avoided, making the conclusion more objective and reliable. Only the test loss caused by over Mock is optimized, without blindly adjusting all test cases. The time cost of environment building and test case reconstruction is saved. After identifying the Mock objects that need to be replaced, real service interaction can be introduced to cover the integrated scenarios (such as interface calling, data interaction, exception handling, etc.) that were previously shielded by Mock, improving test integrity and providing data support for test strategy optimization. In the long run, the coverage influence data of different Mock objects can be accumulated to form a "Mock rationality evaluation standard" to guide the use principles of Mock in subsequent test case design (such as which dependencies should avoid Mock and which can be safely Mocked);

[0209] Mock object limit number determination module: If the problem is caused by excessive reliance on Mock, the limit number of Mock objects in the unit test case is determined based on the integrated logic code coverage when the Mock object is replaced;

[0210] The process of determining the limit number of Mock objects according to the integrated logic code coverage during Mock object replacement includes:

[0211] For each unit test case, during the replacement of the Mock object, run the unit test after each replacement, collect the coverage data of the integrated logic code, record the coverage of the integrated logic code after each replacement, and generate the coverage sequence [c0, c1, ..., c m ], where m is the integration logic code coverage after replacing the Mock object for the mth time;

[0212] Assume that a sudden change in trend occurs after the kth replacement, that is, the stable segment: [c0, c1, ..., c k ](When replacing 0 to k Mock objects, the coverage is in a stable state), growth segment: [c k ,c k+1 ,...,c m ](Starting from replacing k+1 Mock objects, the coverage enters the growth state), the goal is to find the smallest k so that the trend difference between the stable segment and the growth segment reaches the "significant" level;

[0213] The trend slopes of the stable and growing segments were calculated by linear regression, and the standard deviations of the coverage rates of the stable and growing segments were calculated.

[0214] Traverse all possible k (from k = 0 to k = m-1), and calculate for each k: the slope of the stable segment s 稳定 (k) and the slope of the growth segment s 增长 (k), and calculate the slope difference Δs(k)=s 增长 (k)-s 稳定 (k);

[0215] For the coverage sequence, starting from the second element, the difference between each element and the previous element is calculated to get the growth amount, which includes: the growth amount c of each growth segment k+1 -c k and the maximum single growth in the stable segment max|c i -c i-1 | 稳定 , where c i is the integrated logic code coverage after the i-th replacement in the stable segment;

[0216] Set judgment criteria:

[0217] Steady phase slope s稳定 (k) = 0, i.e. no obvious growth trend in the early stage;

[0218] slope of growth segment s 增长 (k) > β, where β is a set significant growth threshold, i.e. there is a significant upward trend in the later stage;

[0219] slope difference Δs(k) > γ, where γ is a preset difference threshold, i.e. the trend difference between the two ends is significant;

[0220] each growth amount c of the growth segment of the k+1th replacement k+1 -c k exceeds the maximum single growth amount in the stable segment, i.e. c k+1 -c k > max | c i -c i-1 | 稳定 , to ensure that this growth is not a continuation of the previous fluctuations;

[0221] From all ks that meet the judgment criteria, the smallest k is selected, i.e. the position of the first trend mutation, and the corresponding c k+1 is the coverage rate of the first significant growth, and c k+1 The number of remaining Mock objects in the corresponding unit test case is the Mock object limit number;

[0222] It can be understood that the physical meaning of the Mock object limit number in the unit test case is: under the premise of ensuring the core isolation of the unit test, the minimum number of Mock objects that can trigger the integrated logic code to be effectively tested, and the limit number is the balance point between "isolation" and "integrated testability", below the limit number, the integrated logic is fully tested but the isolation is insufficient, above the limit number, the isolation is too strong but the integrated logic is not covered, and the Mock object number corresponding to the limit number itself can achieve the optimal balance between the two;

[0223] By analyzing the change rule of the integrated logic code coverage in the Mock object replacement process, the reasonable number of Mock objects in the unit test case is accurately determined, and the effects include:

[0224] Through linear regression, slope analysis, fluctuation comparison and other methods, the judgment of "whether the coverage rate is significantly increased" is converted into quantifiable indicators (such as the stable segment slope close to 0, the growth segment slope significantly positive, and the increment exceeding the maximum fluctuation in the early stage), avoiding the deviation of subjective judgment, and finding a balance point between "Mock isolation" and "integrated logic testability" through data-driven way, and the output Mock object limit number provides a clear and executable standard for optimizing the unit test case and improving the integrated logic coverage;

[0225] The test case optimization and Mock replacement module: according to the Mock object limit number, identify unqualified unit test cases in the unit test cases, and analyze the necessity of Mock objects in the unqualified unit test cases, and replace the Mock objects according to the analysis results;

[0226] The process of analyzing the necessity of Mock objects in unqualified unit test cases and replacing Mock objects according to the analysis results includes:

[0227] For each unit test case, compare the number of Mock objects with the limit number of Mock objects, and divide the unit test cases greater than the limit number of Mock objects into unqualified unit test cases;

[0228] Accurately locate the key code lines that are not covered by testing through code coverage tools, wherein the core code lines of integrated logic usually include:

[0229] Cross-module interface calls: such as the code of service A calling the / api / order interface of service B, the producer / consumer code of inter-module communication through message queues, etc.;

[0230] Transaction boundary code: such as transaction commit / rollback logic within methods marked with @Transactional annotations, branch transaction coordination code in distributed transactions, etc.;

[0231] Data interaction logic: such as JOIN statement execution code for cross-database queries, cache and database synchronization logic, etc.;

[0232] For unqualified unit test cases, execute the unqualified unit test cases using code coverage tools to generate coverage reports, and filter out code lines within the integrated logic range with a coverage rate of 0;

[0233] For real dependencies replaced by Mock objects in unqualified unit test cases, check whether the real dependencies directly participate in the execution of the integrated logic code lines with a coverage rate of 0;

[0234] If the real dependency corresponding to the Mock object directly participates in the integrated logic code line with a coverage rate of 0, the Mock object is an unnecessary Mock object;

[0235] It can be understood that by accurately associating the uncovered integrated logic code with the real dependency of the Mock object, it is determined whether the Mock object is unnecessary, which provides a basis for subsequent replacement of Mock objects and improvement of integrated logic test coverage;

[0236] All unnecessary Mock objects in the unqualified unit test case are replaced by real dependencies, and after the replacement, the number of remaining Mock objects is compared with the Mock object limit number, if the number of remaining Mock objects is less than the Mock object limit number, the unqualified test case is converted into a qualified test case after the replacement of the Mock object;

[0237] Through quantitative analysis and accurate replacement, the unit test is pushed from 'excessive isolation' to'moderate integration', while ensuring the test efficiency, the integrated logic of the system in the real running time is effectively verified, the test blind area caused by 'isolating for isolation' is avoided, and the test cost caused by 'blind integration' is prevented, and finally the quality, stability and maintainability of the software are improved.

[0238] The basic principle, main features and advantages of the present application are shown and described above. It should be understood by those skilled in the art that the present application is not limited by the above examples, and the above examples and descriptions in the specification are only to illustrate the principle of the present application, and various changes and improvements can be made without departing from the spirit and scope of the present application, and these changes and improvements all fall within the scope of the present application. The scope of protection of the present application is defined by the appended claims and their equivalents.

Claims

1. A defect retrieval method for software development testing, characterized by: include: Analyze the usage scope of mock objects in unit tests to determine whether there is mock over-dependence. If so, mark it as a mock over-dependence test case. Analyze the code coverage of the integration logic where mocks are overly dependent on test cases to determine whether the integration logic is effectively tested; If the integration logic is not effectively tested, gradually replace the mock objects in the unit test cases where the integration logic is not effectively tested, and compare and analyze the integration logic code coverage before and after the replacement to determine whether the integration logic is not effectively tested due to excessive reliance on mocks. If it is caused by excessive reliance on mocks, determine the limit on the number of mock objects in the unit test case based on the integrated logic code coverage when the mock objects are replaced; Identify unqualified unit test cases in unit test cases based on the limited number of mock objects, perform necessity analysis on the mock objects in the unqualified unit test cases, and replace the mock objects based on the analysis results.

2. A defect retrieval method for software development testing according to claim 1, characterized in that: The method for determining whether there is excessive dependency on Mock is: Count the number of modules replaced by mock objects in unit test cases, and calculate the ratio with the total number of modules that the unit test cases depend on to get the proportion of mock modules. Among the modules replaced by mock objects, count the number of modules with cross-module interaction and calculate the ratio with the number of modules replaced by mock objects to get the proportion of cross-module interaction mocks. Among them, cross-module interaction nature means that modules have cross-module data transmission, state changes and business collaboration; Add the percentage of mock modules and the percentage of module interaction mocks to get the mock dependency value, and compare the mock dependency value with the preset dependency value; If the Mock dependency value is greater than the preset dependency value, there is excessive Mock dependency in the unit test.

3. The defect retrieval method for software development and testing according to claim 1, characterized in that: The method for determining whether the integrated logic is effectively tested is: Count the total number of lines of integrated logic code during the test process and the number of lines of integrated logic code covered by unit tests; The integration logic code coverage rate is calculated by calculating the ratio of the number of integration logic code lines covered by unit tests to the total number of integration logic code lines. Compare the integration logic code coverage with the preset coverage. If the integration logic code coverage is less than the preset coverage, the integration logic in the unit test is not effectively tested.

4. A defect retrieval method for software development testing according to claim 1, characterized in that: The process of determining whether the integration logic is not effectively tested due to excessive reliance on Mock is as follows: Determine replacement priority for mock objects in unit test classes whose integration logic has not been effectively tested; Remove mock objects in the test one by one according to their replacement priority, and use real service implementations through dependency injection. After each replacement, record the integration logic code coverage of the unit test case. Mark the effective test cases according to the coverage of the integrated logic code after each replacement, and then obtain the proportion of effective test cases; Compare the proportion of valid test cases with the proportion threshold. If the proportion of valid test cases is greater than or equal to the proportion threshold, the integration logic is not effectively tested due to excessive mocking.

5. A defect retrieval method for software development and testing according to claim 4, characterized in that: The replacement priority is determined as follows: Count the number of times the unit under test calls dependencies in normal business processes, and sort the dependencies to be replaced by mock objects by the number of calls. The sorting result is the replacement priority of the mock objects.

6. A defect retrieval method for software development and testing according to claim 4, characterized in that: The calculation method of the effective test case ratio is: For each unit test case, calculate the difference between the integration logic code coverage after each replacement of the Mock object and before the replacement, and compare it with the set significant increase threshold; If the difference before and after the replacement is greater than the significant increase threshold, it is determined that the replacement has significantly improved the integrated logic code coverage; If the coverage of the integrated logic code is significantly improved after at least one replacement in the unit test case, the unit test case is marked as a valid test case; For all unit test cases whose integration logic has not been effectively tested, count the number of effective test cases and calculate the ratio with the number of unit test cases whose integration logic has not been effectively tested to obtain the proportion of effective test cases.

7. A defect retrieval method for software development and testing according to claim 1, characterized in that: The method for determining the limit number of Mock objects is as follows: For each unit test case, during the replacement of the Mock object, record the coverage of the integrated logic code after each replacement and generate a coverage sequence [c0, c1, ..., c m ], where m is the integration logic code coverage after replacing the Mock object for the mth time; For the coverage sequence [c0,c1,...,c m ] Perform k replacement tests, and select the minimum k value among all k values ​​that meet the criteria according to the replacement test results, then c k+1 This is the first significant increase in coverage, c k+1 The number of Mock objects remaining in the corresponding unit test case is the limit number of Mock objects.

8. The defect retrieval method for software development and testing according to claim 5, characterized in that: The method for determining the k value that meets the standard is: Based on the k value, the coverage sequence [c0,c1,...,c m ] is divided into a stable segment and a growth segment, where c m It represents the integrated logic code coverage of the unit test case after the mth replacement, and the stable segment is [c0,c1,...,c k ], c k It represents the integrated logic code coverage of the unit test case after the kth replacement, and the growth segment is [c k ,c k+1 ,...,c m ]; The judgment criteria for setting k based on the stable phase and the growth phase are: Steady phase slope s 稳定 (k) = 0, which means there is no obvious growth trend in the early stage; Growth slope s 增长 (k)>β, where β is the set significant growth threshold, that is, there is a clear upward trend in the later period; The slope difference Δs(k)>γ, where γ is the preset difference threshold, indicating that the trend difference between the stable segment and the growth segment is significant; The amount of growth c of each growth segment replaced in the k+1th time k+1 -c k Exceeds the maximum single growth amount max|c within the stable period i -c i-1 | 稳定 , that is, c k+1 -c k >max|c i -c i-1 | 稳定 , where c i represents the integrated logic code coverage after the i-th replacement in the stable segment; The method for obtaining the growth amount of each growth phase and the maximum single growth amount in the stable phase is as follows: For the coverage sequence, starting from the second element, the difference between each element and the previous element is calculated to get the growth amount, which includes: the growth amount c of each growth segment k+1 -c k and the maximum single growth amount max|c within the stable segment i -c i-1 | 稳定 .

9. The defect retrieval method for software development and testing according to claim 1, characterized in that: The process of performing necessity analysis on the Mock objects in the unqualified unit test cases and replacing the Mock objects according to the analysis results is as follows: For each unit test case, compare the number of mock objects with the limit number of mock objects, and classify the unit test cases with a number greater than the limit number of mock objects as unqualified unit test cases; For unqualified unit test cases, use a code coverage tool to execute the unqualified unit test cases, generate a coverage report, and filter out code lines with zero coverage within the integration logic range; For real dependencies replaced by mock objects in unqualified unit test cases, check whether the real dependencies are directly involved in the execution of integration logic code lines with zero coverage; If the real dependency corresponding to the mock object directly participates in the integration logic code line with a coverage rate of 0, the mock object is an unnecessary mock object; Replace all unnecessary mock objects in failed unit test cases with real dependencies.

10. A defect retrieval system for software development and testing, comprising the following modules: Mock over-dependence identification module: Analyzes the usage scope of Mock objects in unit tests to determine whether there is Mock over-dependence. If so, it is marked as a Mock over-dependence test case; Integration logic test effectiveness evaluation module: Analyzes the code coverage of integration logic that is overly dependent on test cases for mocks to determine whether the integration logic is effectively tested; Mock over-dependence causal verification module: If the integration logic is not effectively tested, the mock objects in the unit test cases where the integration logic is not effectively tested are gradually replaced. The code coverage of the integration logic before and after the replacement is compared and analyzed to determine whether the ineffective testing of the integration logic is caused by excessive mock dependence. Mock object limit number determination module: If the problem is caused by excessive reliance on Mock, the limit number of Mock objects in the unit test case is determined based on the integrated logic code coverage when the Mock object is replaced; Test case optimization and mock replacement module: Identify unqualified unit test cases in unit test cases based on the limited number of mock objects, perform necessity analysis on the mock objects in unqualified unit test cases, and replace the mock objects based on the analysis results.

Images