Unit test analysis method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a unit test analysis method and device, equipment and a storage medium, relates to the technical field of software testing, and obtains a test report through optimized assertion verification and variation testing to determine the effectiveness of unit test codes. The method comprises the following steps: determining a unit test code corresponding to a tested code needing to be subjected to unit test in a code file in the aviation business field; the unit test code is used for testing whether the tested code is valid; performing assertion logic test on the unit test code; under the condition that the unit test code passes the assertion logic test, modifying a logic statement of the tested code according to the mutation operator library, and determining a mutation copy of the tested code; performing variation test on the unit test code based on the variation copy; based on the variation test and the assertion logic test, determining an effectiveness evaluation result of the unit test code; and outputting a unit test analysis report based on the effectiveness evaluation result of each unit test code.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a unit test analysis method, apparatus, device and storage medium. Background Technology

[0002] In software testing, test effectiveness can typically be broken down into four key steps: test analysis, design, planning, and execution. Among these, the core of the test execution phase is the verification of unit test code, whose effectiveness directly impacts software quality and reliability. However, current technologies often lack a systematic analysis and intuitive report generation mechanism for the effectiveness of unit test code. This makes it difficult for developers to accurately assess the coverage, redundancy, and defect detection capabilities of unit test code, thus affecting overall test quality. Summary of the Invention

[0003] The purpose of this application is to provide a unit test analysis method, apparatus, device, and storage medium, aimed at determining the validity of unit test code.

[0004] To achieve the above objectives, the embodiments of this application provide the following technical solutions:

[0005] Firstly, a unit test analysis method is provided. This method includes: identifying the unit test code corresponding to the code under test that needs to be unit tested in a code file within the aviation business domain; the unit test code is used to test whether the code under test is effective; performing assertion logic tests on the unit test code; if the unit test code passes the assertion logic tests, modifying the logic statements of the code under test according to a mutation operator library to determine a mutated copy of the code under test; wherein the mutation operator library includes at least an aviation business mutation operator library and a general mutation operator library; the aviation business mutation operator library is used to indicate the modification methods for specific logic statements in aviation business. A general mutation operator library is used to indicate the modification methods of general logical statements; mutation testing is performed on unit test code based on mutated copies; the effectiveness evaluation results of unit test code are determined based on mutation testing and assertion logic testing; based on the effectiveness evaluation results of each unit test code, a unit test analysis report is output, which includes at least: mutation test coverage and effective unit test percentage; mutation test coverage is used to indicate the proportion of unit test code participating in mutation testing to the total number of unit test code; effective unit test percentage is used to indicate the proportion of effective unit test code to the total number of unit test code.

[0006] This application provides a unit test analysis method, which includes: identifying the unit test code corresponding to the code under test that needs to be unit tested in the code file of the aviation business domain; using the unit test code to test whether the code under test is effective; performing assertion logic tests on the unit test code; if the unit test code passes the assertion logic tests, modifying the logic statements of the code under test according to the mutation operator library to determine the mutated copy of the code under test; performing mutation tests on the unit test code based on the mutated copy; determining the effectiveness evaluation result of the unit test code based on the mutation tests and assertion logic tests; and outputting a unit test analysis report based on the effectiveness evaluation results of each unit test code. The technical solution proposed in this application first systematically judges the assertions in the unit test code; secondly, it conducts mutation tests based on the verified high-quality assertions, generates mutated copies by introducing preset code mutation operators, and uses optimized assertions to screen and detect the mutated copies, accurately identifying whether the test cases can discover these code mutations; finally, it outputs a test report by statistically analyzing the results of the preliminary judgment and the results of the mutation tests. Starting with assertion verification, proceeding through mutation testing, and finally reaching the complete process of validity determination, this approach provides objective and accurate quantitative evidence for the validity of unit test code, thereby enabling a more effective and scientific assessment of the validity of unit tests.

[0007] In some embodiments, the aviation business variation operator library is used to store, but is not limited to, at least one of the following: modification methods for seat selection-related logical statements, modification methods for order processing-related logical statements, and modification methods for additional fee-related logical statements.

[0008] In some embodiments, the general mutation operator library is used to store at least one of the following modification methods, including but not limited to: modification methods for logic statements related to incrementing loops, modification methods for logic statements related to decrementing loops, modification methods for logic statements related to conditional branch judgments, modification methods for logic statements related to relational comparisons, modification methods for logic statements related to arithmetic logic, and modification methods for logic statements related to function calls.

[0009] In some embodiments, the unit test analysis report also includes mutation logic statements, which are used to indicate the logic statements corresponding to the mutated copies of the unit test code that cause the mutation test to fail.

[0010] In some embodiments, the validity evaluation result of unit test code is determined based on mutation testing and assertion logic testing, including: determining the unit test code as invalid unit test code if the unit test code passes the assertion logic test but fails the mutation test; determining the unit test code as valid unit test code if the unit test code passes both the assertion logic test and the mutation test; and determining the unit test code as invalid unit test code if the unit test code fails the assertion logic test.

[0011] In some embodiments, performing mutation testing on unit test code based on a mutated copy includes: performing unit tests on the mutated copy using the unit test code; determining that the unit test code has failed the mutation test if the mutated copy passes the unit test; and determining that the unit test code has passed the mutation test if the mutated copy has failed the unit test.

[0012] In some embodiments, before performing mutation testing on the unit test code based on the mutated copy, the method further includes: verifying the input and output logic of the code under test to confirm that the input and output behavior of the code under test conforms to a preset specification.

[0013] Secondly, a unit test analysis apparatus is also provided, comprising a determination module, a test module, and an output module. The determination module is used to determine the unit test code corresponding to the code under test that needs to be unit tested in the code file of the aviation business domain. The unit test code is used to test whether the code under test is valid. The test module is used to perform assertion logic tests on the unit test code. The determination module is used to, if the unit test code passes the assertion logic test, modify the logic statements of the code under test according to the mutation operator library to determine a mutated copy of the code under test. The mutation operator library includes at least an aviation business mutation operator library and a general mutation operator library. The aviation business mutation operator library is used to indicate specific logic statements in the aviation business. The module defines the modification methods for logical statements; a general mutation operator library indicates the modification methods for general logical statements; a test module performs mutation tests on unit test code based on mutated copies; a determination module determines the effectiveness evaluation results of unit test code based on mutation tests and assertion logic tests; and an output module outputs a unit test analysis report based on the effectiveness evaluation results of each unit test code. The unit test analysis report includes at least: mutation test coverage and effective unit test percentage; mutation test coverage indicates the proportion of the number of tested code that participated in mutation tests to the total number of tested code; and effective unit test percentage indicates the proportion of the number of effective unit test code to the total number of unit test code.

[0014] In some embodiments, the aviation business variation operator library is used to store, but is not limited to, at least one of the following: modification methods for seat selection-related logical statements, modification methods for order processing-related logical statements, and modification methods for additional fee-related logical statements.

[0015] In some embodiments, the general mutation operator library is used to store at least one of the following modification methods, including but not limited to: modification methods for logic statements related to incrementing loops, modification methods for logic statements related to decrementing loops, modification methods for logic statements related to conditional branch judgments, modification methods for logic statements related to relational comparisons, modification methods for logic statements related to arithmetic logic, and modification methods for logic statements related to function calls.

[0016] In some embodiments, the unit test analysis report also includes mutation logic statements, which are used to indicate the logic statements corresponding to the mutated copies of the unit test code that cause the mutation test to fail.

[0017] In some embodiments, the determining module is used to determine the validity evaluation result of the unit test code based on mutation testing and assertion logic testing, including: determining the unit test code as invalid unit test code if the unit test code passes the assertion logic test but fails the mutation test; determining the unit test code as valid unit test code if the unit test code passes both the assertion logic test and the mutation test; and determining the unit test code as invalid unit test code if the unit test code fails the assertion logic test.

[0018] In some embodiments, the testing module is configured to perform mutation testing on unit test code based on the mutated copy, including: the testing module is specifically configured to perform unit testing on the mutated copy using the unit test code; the determining module is specifically configured to determine that the unit test code has failed the mutation test if the mutated copy passes the unit test; and the determining module is specifically configured to determine that the unit test code has passed the mutation test if the mutated copy has failed the unit test.

[0019] In some embodiments, the determining module is further configured to, before performing mutation testing on the unit test code based on the mutated copy, further include: performing input / output logic verification on the code under test to determine that the input / output behavior of the code under test conforms to a preset specification.

[0020] Thirdly, an electronic device is also provided, comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the method of the first aspect described above.

[0021] Fourthly, a computer-readable storage medium is also provided, comprising: computer software instructions; when the computer software instructions are executed in an electronic device, the electronic device causes the electronic device to implement the method of the first aspect described above.

[0022] The beneficial effects of the second to fourth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

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

[0024] Figure 1 A schematic diagram of the framework of a unit test analysis system provided in this application embodiment;

[0025] Figure 2 A flowchart illustrating a unit test analysis method provided in this application embodiment. Figure 1 ;

[0026] Figure 3 A flowchart illustrating a unit test analysis method provided in this application embodiment. Figure 2 ;

[0027] Figure 4 A flowchart illustrating a unit test analysis method provided in this application embodiment. Figure 3 ;

[0028] Figure 5 A complete flowchart of a unit test analysis method provided in this application embodiment;

[0029] Figure 6 This is a schematic diagram of the composition of a unit test analysis device provided in an embodiment of this application;

[0030] Figure 7 This is a schematic diagram of a unit test analysis device provided in an embodiment of this application. Detailed Implementation

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

[0032] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0033] In the embodiments of this application, the terms "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," "third," "fourth," "fifth," and "sixth" may explicitly or implicitly include one or more of that feature.

[0034] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0035] In the field of software testing, code coverage, as a classic metric for measuring test completeness, has long been widely used to evaluate the extent to which unit tests cover the source code. However, as the complexity of software systems continues to rise, the limitations of traditional code coverage have become increasingly apparent. It is essentially a procedural metric, only proving that the code has been "executed," but failing to answer the core question of "whether the tests truly verified the correctness of the code." For example, a piece of logic containing boundary condition checks might have all branches covered by test cases, but if the test cases do not include extreme value inputs, potential logical vulnerabilities will still be missed. Similarly, for code blocks containing complex business rules, even with 100% coverage, if the test cases do not verify the core constraints of the rules, it may still lead to online failures.

[0036] The root of this limitation lies in the fundamental disconnect between code coverage and unit test effectiveness. Effectiveness emphasizes the ability of test cases to discover defects, relying on a deep understanding of code logic, business scenarios, and exception scenarios. Coverage, on the other hand, only focuses on the formal result of "whether or not coverage is achieved," failing to reflect the design quality, logical rigor, and ability to anticipate potential risks of test cases. Therefore, accurately evaluating the effectiveness of unit test code and establishing a scientific analysis mechanism have become key challenges in improving test quality.

[0037] To address the aforementioned issues, this application provides a unit test analysis method. This method includes: identifying the unit test code corresponding to the code under test that requires unit testing in a code file within the aviation business domain; using the unit test code to test the validity of the code under test; performing assertion logic tests on the unit test code; if the unit test code passes the assertion logic tests, modifying the logic statements of the code under test according to a mutation operator library to determine a mutated copy of the code under test; wherein the mutation operator library includes at least an aviation business mutation operator library and a general mutation operator library; the aviation business mutation operator library indicates the modification methods for dedicated logic statements in aviation business; the general mutation operator library indicates the modification methods for general logic statements; performing mutation tests on the unit test code based on the mutated copy; determining the validity evaluation result of the unit test code based on the mutation tests and assertion logic tests; and outputting a unit test analysis report based on the validity evaluation results of each unit test code. The technical solution proposed in this application first systematically evaluates assertions in unit test code; second, it conducts mutation testing based on validated, high-quality assertions by introducing pre-defined code mutation operators to generate mutated copies, and then uses optimized assertions to filter and detect these mutated copies, accurately identifying whether test cases can detect these code mutations; finally, it outputs a test report by statistically analyzing the results of the preliminary evaluation and the mutation testing. Starting with assertion verification, proceeding through mutation testing, and ultimately reaching a complete process of validity determination, this approach provides objective and accurate quantitative evidence for the validity of unit test code, thus more effectively achieving a scientific assessment of unit test validity.

[0038] The unit test analysis method provided in this application can be applied to, for example, Figure 1 The system shown.

[0039] Figure 1 This is a schematic diagram of the framework of a unit test analysis system provided in an embodiment of this application. Figure 1 As shown, the system includes a single-test filtering module 101, a mutation testing module 102, and a report output module 103.

[0040] The unit test filtering module 101 is a key connecting component between the data input of the unit test validity determination system and the core processing layer of the system. Through preset filtering rules, it processes the initial input set of unit test codes and outputs a valid subset of unit tests that meet the requirements of subsequent mutation tests.

[0041] Unit testing refers to the process by which developers or testers independently and in isolation verify the smallest testable unit in a software system, such as a function, method, class, or module, based on detailed design documents or interface specifications, using a specific testing framework to write test cases. This verification aims to determine whether the unit can execute correctly according to the expected logic and whether it meets requirements such as functional requirements, data processing accuracy, and boundary condition adaptability.

[0042] The mutation testing module 102 is a key component of the core processing layer. It receives valid unit test cases output by the unit test filtering module 101, injects controllable mutations into the code under test, performs test verification and result analysis, quantitatively evaluates the defect detection capability of the unit test cases, and provides the core basis for the final validity judgment.

[0043] The report output module 103 is the core component for result presentation and value delivery. It receives the filtering results from the unit test filtering module 101 and the quantitative analysis data from the variation test module 102. Through structured integration, multi-dimensional visualization and scenario-based output, it transforms the underlying analysis results of the system into a unit test optimization solution that users can understand and execute.

[0044] The unit test validity determination system provided in this application firstly filters and standardizes valid unit test cases by a unit test filtering module 101, providing qualified input for a mutation testing module 102. The mutation testing module 102 generates mutated copies based on the valid test cases and executes the tests, outputting quantitative analysis data. The report output module 103 integrates data from the preceding modules, generating multi-dimensional reports and optimization suggestions, and the report conclusions can be used to optimize the preceding modules. The synergy of these three components significantly improves test evaluation efficiency, ensures the accuracy of validity determination, and transforms technical data into executable solutions, achieving a closed-loop optimization of the entire process from input to implementation for unit test validity determination.

[0045] The unit test analysis method provided in this application will be described below with reference to specific embodiments and accompanying drawings:

[0046] Figure 2 A flowchart illustrating a unit test analysis method provided in this application embodiment. Figure 1 This unit test analysis method can be applied to the above. Figure 1 In unit test analysis systems, such as Figure 2 The specific steps include S201-S206.

[0047] S201. Determine the unit test code corresponding to the code to be tested that needs to be unit tested in the code files of the aviation business domain.

[0048] Code files refer to files that store program code. In unit testing scenarios, two core types of code files are involved: the code file under test and the unit test code file. The code file under test stores the business function code, while the unit test code file stores the test logic for verifying the business code. Code files in the aviation business domain belong to the aviation business domain.

[0049] Unit testing is a testing activity that verifies the correctness of the smallest functional unit of software. It is the process of running "unit test code" to verify the "code under test". Its purpose is to discover logical errors and boundary issues in the code at an early stage and ensure the functional correctness of individual units.

[0050] The code under test refers to the core business code that needs to be verified for correctness, i.e., the object of unit testing verification, such as functions, classes, modules, etc. Its role is to implement the core functions of the software and is the main part of the software.

[0051] Unit test code is used to test whether the code being tested is effective.

[0052] Unit test code refers to code written to verify the correctness of code under test. Its purpose is to design test cases, call the code under test, and check whether its output meets expectations. It is designed individually for single functions, methods, etc., with finer granularity, and typically relies on a testing framework, such as pytest for Python or JUnit for Java.

[0053] In some implementations, the method provided in this application is centered on unit testing activities, with unit test code serving as the execution carrier, acting on the code under test, and jointly completing the verification of the functionality of the smallest unit of software.

[0054] In some implementations, the code to be tested for unit tests in the code file can be determined from at least one of the following aspects: functional independence, business coreness, logical complexity, explicitness of input and output, degree of dependency and coupling, frequency of change, etc.

[0055] For example, taking the code of an "order amount calculation" module as an example, the code file includes the `calculate_total` method, etc. The `calculate_total` method is core test code and is the code to be tested through unit testing. It meets the following requirements: functional independence, i.e., the inputs (product amount, shipping cost, discount rules, coupon amount) and output (total amount) are clear, requiring no external system dependency and can be executed independently; business coreness, i.e., it directly determines the final order amount, affecting user payment and platform revenue; logical complexity, i.e., it includes multi-condition discount judgments, exception handling (negative number verification), boundary value handling (total amount not less than 0), with many branches and prone to errors; input and output clarity, i.e., input parameters are quantifiable (e.g., `goods_amount = 100`, `coupon_amount = 20`), and the output result is assertible (expected total amount = 85); dependency and coupling, i.e., no external dependencies, only dependent on input parameters, requiring no complex decoupling for testing; and change frequency, as discount rules and coupon policies are frequently iterated, this method needs frequent adaptation and requires focused testing.

[0056] In some implementations, once the code under test that needs to be unit tested is identified, logical-level test cases must first be designed for it. These test cases are then implemented as executable unit test code, which can call the code under test to perform unit tests. The test cases can include different scenarios, such as normal scenarios, discount-triggered scenarios, negative number input scenarios, and scenarios where the total amount is negative.

[0057] In this embodiment, functions, methods, and other independent "test units" are first selected from the code file (excluding auxiliary code such as comments and constants). Then, dedicated unit test code for verifying the functionality is written according to their logic and scenario. This makes the unit test code more targeted, reduces redundancy and omissions, focuses on core vulnerabilities, discovers errors in advance, and reduces online risks. After the code is modified, the test can quickly regress to verify stability and also help developers understand the unit functions, improving collaboration efficiency.

[0058] S202. Perform assertion logic tests on the unit test code.

[0059] Assertion logic is the core judgment logic in unit test code used to verify whether the "actual result" is consistent with the "expected result," and it is the key means for unit test code to implement the "verification function." Assertion logic uses assertion statements in the code to clarify what result the code under test should produce under specific inputs, and automatically judges whether the actual running result meets this expectation. Assertion languages ​​can include assertEquals, assertTrue, etc.

[0060] For example, when testing an addition function `add(2,3)`, the assertion logic might be `assertEquals(5,add(2,3))`—clearly indicating the expected result is 5, and checking whether the function's actual return value is equal to 5. When testing a user registration function, the assertion logic might include multiple checks such as "after successful user registration, a new record should be added to the database" and "if registration fails, a specific exception should be thrown."

[0061] In one implementation, a systematic assessment of the assertion logic in the unit test code can be performed to verify the matching degree between the assertions and business requirements, the logical completeness, and the reasonableness of the conditions, thereby ensuring that the assertions can accurately reflect the expected behavior of the software unit test.

[0062] Among them, the degree of matching between assertions and business requirements refers to whether the behavior or result verified by the assertion fully and accurately reflects the goals and intentions of the original business requirements; logical integrity refers to whether the assertion covers all possible scenarios implied or explicit by the business requirements, including normal paths, abnormal paths and boundary cases; and conditional rationality refers to whether the preconditions such as the inputs and states that trigger the behavior verified by the assertion are set reasonably and effectively, and are consistent with the real business scenarios.

[0063] For example, regarding the match between assertions and business requirements: The test only asserted that calling the "Update Cart" API returned an HTTP status code 200. However, HTTP 200 only indicates that the request syntax was correct and the server received it; it doesn't prove that the product quantity was actually modified. This shows that the current technical details match, but the business goals don't. Regarding the completeness of the verification logic: the current test only covers the normal scenario (forward path) of changing the product quantity from 1 to 2. A complete test case should include assertions for other normal paths, boundary conditions (such as minimum / maximum quantities, zero values, negative numbers, etc.), and abnormal conditions (such as non-numeric characters, excessively long inputs, illegal operations, etc.). Currently, the test case set is incomplete and needs further supplementation. Regarding the reasonableness of the verification conditions: when testing "Flight Search," the departure and destination are set to the same airport. Although the program might need to handle this, from a business perspective, this is a very low-probability and meaningless operation with a very low priority.

[0064] In some embodiments, if unit test code fails the assertion logic test, the unit test code is determined to be invalid unit test code.

[0065] Among them, the situations in which unit test code fails the assertion logic test include, but are not limited to: the case where the unit test code does not contain assertion-related logic statements; and the case where the assertion logic test in the unit test code fails.

[0066] For example, if a test case merely calls the function or method under test but lacks any assertion statements to verify whether its return result or state change matches expectations, the test code will be deemed invalid. For instance, a test case for the function `add(2,3)` only executes the operation `result = add(2,3)`, but lacks crucial assertion logic like `assert result == 5`. Even if such a test passes, it cannot prove the correctness of the code and can be considered invalid unit test code. Therefore, by continuously iterating and updating the code to ensure it meets current requirements, a solid foundation is laid for subsequent testing phases.

[0067] Analyzing unit test code to determine the presence of assertion-related logical statements can ensure that the unit test code has effective verification capabilities in advance, avoiding test vulnerabilities caused by missing or incorrect assertions from the source, thereby improving the completeness and reliability of the testing process.

[0068] This embodiment describes how unit test code can be deemed invalid when it fails assertion logic testing. Here, "assertion logic testing" refers to verifying whether the assertion statements in the unit test code can correctly detect the expected behavior of the target code, including normal and abnormal cases. If the assertion logic itself is flawed, even if the tested code actually has defects, the test will still fail correctly. This indicates that the test case has lost its defect detection capability and is therefore deemed invalid unit test code.

[0069] For example, suppose there's a simple function `add(a, b)` that calculates the sum of two numbers. Its unit test might contain the assertion: `assert add(2, 2) == 5`. This assertion sets an incorrect expected result (the correct result should be 4). When the test runs, even if the `add` function correctly performs addition (returns 4), the test will fail due to the flawed assertion logic. In this case, the test code cannot effectively verify the correctness of the function being tested and can be considered invalid unit test code. Therefore, it's crucial to update the code promptly to maintain its effectiveness and provide a reliable foundation for subsequent testing.

[0070] In this embodiment, by performing assertion logic tests on unit test code, its validity can be pre-assessed, and invalid test code can be filtered out. This step lays an important foundation for subsequent mutation testing—only after the unit test passes the assertion logic verification can it enter the mutation testing stage for deeper defect detection. This layered verification mechanism significantly improves the accuracy and reliability of judging the validity of unit test code through multiple verification dimensions.

[0071] Based on the above steps S201-S202, a schematic diagram of a specific implementation example for initially filtering out valid and invalid unit test code is given, as follows: Figure 3 As shown, Figure 3 A flowchart illustrating a unit test analysis method provided in this application embodiment. Figure 2 First, the system receives the user's input of the project directory path and ANT path rules. Then, it scans all rules under the path matching the ANT path rules and retrieves all code files under the target path based on those rules. Next, the system calls a parsing tool to parse the class structure file by file, extracting relevant information for each method (including method body, comments, etc.). The system parses method comments and associated launchers (such as test annotations), determining whether it contains a specific class from a predefined annotation library (e.g., JUnit's @Test annotation). If so, the method is marked as unit test code, and the number of unit test codes is accumulated. Subsequently, the system removes comments and string content from the method, retaining only the code logic structure, and then analyzes the call relationships within the method body. It checks whether it contains classes from an assertion library. If the analysis shows that it does not reference any classes from the assertion library (e.g., the Assert class), the unit test is determined to be invalid; otherwise, it is added to the mutation test queue, awaiting subsequent mutation test execution.

[0072] In another possible implementation, in the unit test filtering module, the class analyzer serves as the fundamental core component for analyzing unit test code. By flexibly utilizing various source code analysis tools (such as JavaParser, APT, JDT, Spoon), custom syntax parsing tools (such as ANTLR), or bytecode parsing tools (such as ASM), it can efficiently and accurately extract the structure, methods, and metadata information of test classes. This provides solid data support for subsequent test case selection, priority ranking, and test execution, significantly improving the automation and reliability of test analysis and laying a solid foundation for the smooth progress of the entire testing process.

[0073] S203. If the unit test code passes the assertion logic test, modify the logic statements of the code under test according to the mutation operator library to determine the mutated copy of the code under test.

[0074] The mutation operator library stores the original logical statements and the modification methods between them. A mutated copy refers to a modified copy of the tested code that intentionally introduces errors.

[0075] In some embodiments, before performing mutation testing on the unit test code based on the mutated copy, the method further includes: verifying the input and output logic of the code under test to confirm that its input and output behavior conforms to a preset specification.

[0076] Among them, the preset specifications refer to the interface specifications or business rules that conform to the project agreement.

[0077] In one possible implementation, the logic statements of the code under test are modified according to a mutation operator library, and the code under test has already completed the detection of input and output parameter verification logic.

[0078] For example, checking whether the input is valid and whether the output conforms to the specifications, such as the function check_input(num) used to verify whether the input parameter num is a positive integer, belongs to the input parameter verification logic; the function check_output(result) used to verify whether the result is a non-empty list and all elements are positive integers, belongs to the output verification logic.

[0079] The input and output logic of the code under test is verified to confirm that its behavior conforms to the preset specifications. This step can verify the correctness of the interface behavior of the code under test before conducting specific assertion tests, laying a solid foundation for subsequent in-depth logic testing, thereby ensuring the accuracy and effectiveness of the test results.

[0080] In this embodiment of the application, the unit tests are further preliminarily screened according to the above steps S201-S202. The unit test code that passes the assertion logic test will be added to the mutation test queue. Then, according to the mutation operator library, the logic statement of the code under test is modified to obtain different mutated copies. The mutated copies are then subjected to unit tests. The validity of the unit test code is further determined based on the unit test results. The accuracy and reliability of the validity judgment of the unit test code are significantly improved through multiple verification dimensions.

[0081] In some embodiments, the mutation operator library includes at least a general business logic mutation operator library and an airline mutation operator library, wherein the airline business mutation operator library is used to indicate the modification method of dedicated logic statements in airline business, and the general mutation operator library is used to indicate the modification method of general logic statements.

[0082] The general business logic operator library is configured to provide various variant implementations of logical control operators and is used to store at least one of the following modification methods, including but not limited to: modification methods for logic statements related to incrementing loops, modification methods for logic statements related to decrementing loops, modification methods for logic statements related to conditional branch judgments, modification methods for logic statements related to relational comparisons, modification methods for logic statements related to arithmetic logic, and modification methods for logic statements related to function calls.

[0083] Exemplarily, the modification method for the general business logic operator library to store can be shown in Table 1 below. This Table 1 includes the corresponding conversion between the logic statements before and after the modification of the general business logic. It should be noted that the embodiments described in this table are only a part of the embodiments of this application, rather than all embodiments.

[0084] Table 1

[0085] Original Logic variant + - - + * / > < > >＝ ＝＝ ！＝ ！＝ ＝＝ is is not is not is || && ^ ＝＝ and or

[0086] In one possible implementation, the modification method of the logic statements related to the increment loop means that the increment iteration method in the loop can be changed to decrement, or the step value of the loop can be changed, thereby possibly changing the loop boundary or behavior, and then generating a mutant copy of the tested code.

[0087] For example, changing for(i = 0; i < n; i++) to for(i = 0; i < n; i--). This example involves the above-mentioned logic statements before and after the modification, changing the increment iteration method to decrement.

[0088] In one possible implementation, the modification method of the logic statements related to the decrement loop is opposite to the increment loop mutation. The decrement iteration method in the loop is changed to increment, and then a mutant copy of the tested code is generated.

[0089] For example, changing for(i = n; i > 0; i--) to for(i = n; i > 0; i++). This example changes the decrement iteration method in the loop to increment.

[0090] In one possible implementation, the modification method of the logic statements related to the conditional branch judgment means that the logic of the conditional judgment statement can be changed, and then a mutant copy of the tested code is generated.

[0091] For example, forcing the condition to be true or false, changing if(condition) to if(true) or if(false); reversing the comparison operator, changing if(a > b) to if(a < b).

[0092] In one possible implementation, the modification method of the logic statements related to the relational comparison means that mutations are specifically made for the comparison operators (<, >, <=, >=, ==,!=), and they are replaced with another operator, and then a mutant copy of the tested code is generated.

[0093] For example, changing a b, a <= b, a == b, etc.; changing a == b to a!= b, etc.

[0094] In one possible implementation, modifying the logic statements related to function calls indicates a change in the behavior of the function call, thereby generating a mutated copy of the code under test.

[0095] For example, modifying the passed parameters, replacing them with another function, or directly removing the function call, such as changing func(a,b) to func(b,a), or changing func(a) to otherFunc(a), etc.

[0096] In this embodiment, the logic statements modified based on the methods for modifying incrementing and decrementing loop logic statements enable unit test code to effectively detect infinite loops or logical errors caused by incorrect changes in the direction of loop variable terms; the logic statements modified based on the method for modifying conditional branch judgment logic statements enable unit test code to effectively detect incorrect branch paths taken by the program; the logic statements modified based on the method for modifying relational comparison logic statements enable unit test code to effectively detect logical errors in boundary conditions or equality conditions; the logic statements modified based on the method for modifying arithmetic logic statements enable unit test code to effectively detect abnormal outputs caused by mathematical calculation logic errors; and the logic statements modified based on the method for modifying function call logic statements enable unit test code to effectively detect abnormalities in subsequent states or outputs caused by function call errors. Based on these different methods of modifying general logic-related statements, error localization deviations caused by variations can be accurately located, providing a clear direction for subsequent judgment of the effectiveness of unit test code.

[0097] The airline variation operator library is configured to provide multiple variant implementations of business system logic and stores at least one of the following modification methods, including but not limited to: modification methods for seat selection-related logic statements, modification methods for order processing-related logic statements, and modification methods for additional fee-related logic statements.

[0098] In one possible implementation, the modification methods for seat selection-related, order processing-related, and surcharge-related logic statements in the airline mutation operator library provide specific mutation modification rules, adjustment logic, and solutions for various business scenarios related to seat selection, order processing, and surcharges, thereby generating mutated copies of the code under test. Its core function is to provide crucial support for verifying the effectiveness of the corresponding business unit test code by simulating mutation scenarios in these business scenarios, thereby helping to cover more business boundaries and abnormal situations, and ensuring the accuracy and stability of the business logic implementation.

[0099] For example, the modification method used to store the airline variation operator library can be shown in Table 2 below. Table 2 includes the correspondence between the logic statements before and after the modification of the airline-specific business logic. It should be noted that the embodiments described in this table are only some embodiments of this application, and not all embodiments.

[0100] Table 2

[0101] Original Logic variant Issue EMO Refund EMO Refund EMO Issue EMO Choose seat Random seat Random seat Choose seat Surcharge None None Surcharge

[0102] For example, the original logic was "Choose a seat" and can be modified to "Randomly select a seat". This means that if the original business logic was "assigned according to rules" (such as first-class passengers always choosing the front row seats), the modified logic becomes "randomly assigned". Unit tests are then performed based on this.

[0103] For example, the original logic was "Issue EMO for pending orders," which was changed to "Refund EMO for canceled orders." This means that if the original business logic's order processing rule was "pending orders," but the changed rule is "cancelled orders," then unit tests will be performed based on this.

[0104] For example, Surcharge is changed to None, indicating that the additional fee existed in the original business logic, but the additional fee will not exist after the mutation, and then unit testing is performed based on this.

[0105] In some embodiments, the design guidelines for mutation operators define the design direction for both general-purpose and specialized operator libraries, ensuring that both are developed around predetermined functional boundaries. These guidelines are presented in tabular form, including mutation operators and their corresponding descriptions, clearly defining the functional objectives of each type of mutation operator.

[0106] For example, the mutation operators included in the design guidelines for mutation operators and their corresponding descriptions are shown in Table 3 below. It should be noted that the embodiments described in this table are only some embodiments of this application, and not all embodiments.

[0107] Table 3

[0108] Mutation Operator describe AAR Reference modification AOR Arithmetic operators replaced ASA Aviation system logic modification CRP constant substitution DER Modify the do statement DSA Modify the data statement GLR goto tag replacement LCR Logical operator substitution ROR Relational operator substitution RSR The return statement can be replaced by SDL Statement deletion SVR Variable substitution UOI Insert unary operator

[0109] For example, taking the mutation testing scenario of an airline ticketing system as an example, the design guidelines for mutation operators first clarify the core direction, determine the mutation operators and descriptions such as ASA (functional goal is to modify the airline seat selection logic and simulate seat selection rule errors) and CRP (functional goal is to replace constants and simulate pricing calculation errors), and define the design boundaries. On this basis, the general operator library undertakes the general functional goals of NCL, and implements universal operations based on the general business mutation operator library. For example, changing "ticket price × 1 (original price settlement)" to "ticket price × 0.9 (error trigger 90% discount)" not only conforms to the guidance direction of numerical calculation modification, but is also applicable to various scenarios that require numerical calculation, while providing basic structure templates. The airline mutation operator library closely follows the aviation-specific functional goals of ASL, and designs customized operations for the airline seat selection scenario. For example, changing "prioritize allocating window seats to passengers with children" to "prioritize allocating aisle seats" not only does not deviate from the guidance of modifying the airline seat selection logic, but also accurately adapts to the needs of the airline ticketing system.

[0110] In this embodiment, by integrating a general business logic operator library and an airline-specific operator library, and relying on the design guidelines for mutation operators, a two-dimensional mutation basis is constructed: on the one hand, based on the general business logic operator library, basic mutations are implemented at the level of universal business rules; on the other hand, combined with the airline mutation operator library, targeted mutations are carried out for business logic specific to the aviation field. These two forms cover both the commonalities and characteristics of business logic, forming a multi-faceted and comprehensive mutation support system. Different mutated copies of the code under test are constructed, providing a clear and effective execution basis for the mutation processing and laying a solid foundation for subsequent unit test code validity determination.

[0111] S204. Perform mutation testing on unit test code based on mutated copies.

[0112] Among them, the unit test code refers to the unit test code that has undergone preliminary screening through steps S201-S202; the mutated copy is the mutated copy obtained by calling the general business logic operator library and the airline-specific operator library in step S203.

[0113] In some embodiments, performing mutation testing on unit test code based on a mutated copy includes: performing unit tests on the mutated copy using the unit test code; determining that the unit test code has failed the mutation test if the mutated copy passes the unit test; and determining that the unit test code has passed the mutation test if the mutated copy has failed the unit test.

[0114] For example, the original function `calcDiscount(price, discount)` calculates the discounted price of a product. Its logic is "original price multiplied by the discount ratio" (i.e., `returnprice*discount`). Unit test code is designed for this function, including test cases where `price = 100` and `discount = 0.8`, with an expected output of 80. The core logic is whether the function's return value equals 80. In mutation testing, a mutated copy of the original function, `calcDiscountMut`, is first generated. This copy changes the "multiplication" in the original logic to "addition" (i.e., `returnprice+discount`). The mutated copy is then tested using the aforementioned unit test code. When the test cases are executed, `calcDiscountMut` returns 100.8, which is inconsistent with the expected output of 80. Therefore, this mutated copy fails the unit test. According to the rules, the original unit test code passed this mutation test, indicating that it can effectively detect mutations such as "operator errors" in the function logic.

[0115] In this embodiment, the unit test code is first preliminarily screened through steps S201-S202 to accurately extract preliminary effective unit test code. This step eliminates invalid and redundant code from the source, avoiding the problem of low test efficiency caused by invalid code occupying resources during subsequent testing. Then, the mutated copy obtained in step S203 is called to start the unit test. On the one hand, the unit test is focused on the effective code, reducing unnecessary testing steps, greatly improving testing efficiency, and avoiding the waste of time and resources. On the other hand, the mutated copy can simulate code changes under various business scenarios. Combined with the effective code selected in the early stage, it can more comprehensively detect the stability and reliability of the code under different mutation scenarios, effectively improving the effectiveness of unit tests and providing a strong guarantee for the stable operation of subsequent business.

[0116] S205. Based on mutation testing and assertion logic testing, determine the effectiveness evaluation results of the unit test code.

[0117] The validity evaluation results can be determined according to the following embodiments, and can at least depend on the results of the variation test and the assertion logic test.

[0118] In some embodiments, if the unit test code fails the assertion logic test, the unit test code is determined to be invalid. The specific details of this embodiment can be found in the description of step S202 above.

[0119] In some embodiments, if the unit test code passes both the assertion logic test and the mutation test, the unit test code is determined to be invalid unit test code.

[0120] In one possible implementation, if the unit test code passes the assertion logic test, the logic statements of the code under test are modified according to the general business logic mutation operator library or the airline mutation operator library to determine the mutated copy of the code under test. The mutated copy is then subjected to unit testing. When the preset result and the actual test result are consistent, the unit test is considered to have passed. This indicates that no mutation was found in the unit test code, meaning the unit test code failed the mutation test and can be determined to be invalid unit test code.

[0121] For example, if the unit test only verifies that "passengers will eventually obtain a valid seat number" (e.g., only checking that the seat number format is correct and not duplicated), without verifying the specific rules for seat allocation (e.g., how cabin class and seat area are modified), the mutated random allocation may still satisfy the lenient condition of "valid seat," causing the test to pass. This situation does not indicate that the mutation logic is correct, but rather that the test case has not touched upon the core constraints of the business rules and has failed to identify the rule-level mutation. This indicates that the unit test code is insufficiently effective, thus determining that the unit test code is invalid. Simultaneously, the mutation logic statements in the current unit test code should be identified to provide precise location for further improvement of the unit test code.

[0122] In some embodiments, if unit test code passes assertion logic tests but fails mutation tests, the unit test code is determined to be invalid unit test code.

[0123] In one possible implementation, if the unit test performed on the mutated copy fails when the preset result is inconsistent with the actual test result, it indicates that the unit test code has discovered the mutation, that is, the unit test code has passed the mutation test. In this case, the unit test code is determined to be valid unit test code.

[0124] For example, the original logic was "Choose a seat," which was changed to "Randomly select a seat." This means that if the original business logic specified seat selection as "by rule" (e.g., first-class passengers always choose front-row seats), the modified logic becomes "randomly assigned," and unit tests are then performed based on this. If the unit tests have explicit rule validation (e.g., asserting "first-class passengers' seat numbers must be in the first 10 rows"), the modified random assignment is very likely to produce results that do not conform to the rules (e.g., first-class passengers are assigned to back rows), causing the assertion to fail and the test to fail. This demonstrates that the test cases accurately cover the core logic of the original business rules, effectively identify deviations from expectations, and verify the effectiveness of the test code. At this point, the unit test code is determined to be valid unit test code.

[0125] Based on the above steps S203-S206, a specific embodiment diagram of unit test code that has undergone mutation testing to determine its validity and invalidity is given, as follows: Figure 4 As shown, Figure 4 A flowchart illustrating a unit test analysis method provided in this application embodiment. Figure 3 First, obtain the logical statements of the code under test corresponding to the unit test; second, compare them with the mutation operator library and modify the logical statements of the code under test; then, generate different mutated copies by calling the mutation testing tool; next, execute the unit test on the mutated copy; determine whether the unit test execution passes, if it does, mark the unit test as invalid unit test code and record the logical statements of the mutated copy; otherwise, mark the unit test as valid unit test code.

[0126] S206. Based on the effectiveness evaluation results of each unit test code, output a unit test analysis report. The unit test analysis report shall include at least: variant test coverage and effective unit test percentage.

[0127] Among them, mutation test coverage is used to indicate the proportion of the number of tested code segments that participate in mutation testing to the total number of tested code segments.

[0128] Mutation test coverage is an important indicator for measuring the adequacy of software testing and is closely linked to the effectiveness of unit tests. A higher coverage rate means that the testing process covers a wider range of code mutations. This indicator not only directly reflects the ability of unit test code to detect potential defects in the code under test. For example, if the coverage is low, it means that the existing test cases may not be able to identify the actual errors simulated by some code mutations, and the test plan needs to be further optimized. It can also help developers discover redundant logic or weak links in the code. Optimizing unit test design to address these issues can promote the upgrade of unit tests from "simply covering lines of code" to "precisely covering potential defects", further improving the effectiveness of unit tests.

[0129] In one possible implementation, if the mutation test coverage is lower than a preset mutation test coverage threshold, at least one of the following can be taken: classify surviving mutated copies by type to identify test blind spot patterns; prioritize the analysis and handling of surviving mutated copies located in core business logic and complex code areas; examine and strengthen the assertions of existing tests; supplement test cases; and use boundary value and attribute-based tests to generate more comprehensive test data.

[0130] For example, in safety-critical industries such as aviation, healthcare, and autonomous driving, the preset mutation test coverage threshold can be 85%-90%. When the mutation test coverage falls below the preset threshold, targeted modifications to the code files are required.

[0131] The percentage of valid unit tests indicates the ratio of the number of valid unit tests to the total number of unit tests.

[0132] The percentage of effective unit tests (DUTs) is the percentage of effective unit tests that accurately detect defects, conform to specifications, and have verification value, out of the total number of unit tests. It directly reflects the effectiveness of unit tests; a higher percentage indicates that more of the unit tests are truly effective. In practical terms, this metric reduces resource waste by identifying duplicate and redundant tests, while simultaneously enabling the team to optimize test case design (such as adding boundary tests and improving assertions), allowing unit tests to more accurately verify code functionality and further enhancing their effectiveness. This lays a solid foundation for subsequent testing and software quality.

[0133] In one possible implementation, if the percentage of effective unit tests is lower than a preset threshold for the percentage of effective unit tests, at least one of the following can be taken: regularly clean up redundant and outdated tests, retain representative scenarios and delete duplicate and invalid tests through test case clustering; use tools to automatically detect and ignore equivalent and duplicate variant copies, or manually configure to exclude variants of irrelevant code, thereby reducing noise and focusing on core logic; reduce maintenance costs by improving the maintainability of test code and avoiding excessive simulation, and make tests more focused on behavior rather than implementation details.

[0134] For example, for projects with frequent iterations, the preset effective unit test percentage threshold can be 85%. When code is frequently modified, ineffective tests will significantly increase system execution time and slow down iteration efficiency. Tests below 85% must be cleaned up first. For all types of projects, the preset effective unit test percentage threshold can be 80%. When it is below 80%, it means that more than 20% of the test cases are "ineffective costs," which greatly affects the effectiveness of the unit test code.

[0135] In some embodiments, the unit test analysis report also includes mutation logic statements, which are used to indicate the logic statements corresponding to the mutated copies of the unit test code that cause the mutation test to fail.

[0136] Mutation logic refers to the technical logic of generating mutated copies by making minor modifications to the logical statements in invalid unit test code. Its core function is to accurately locate logical defects in invalid unit tests. By comparing the execution results of the mutated copy with the original code under test, defects that cannot be effectively detected, logical redundancy, or problems that do not meet verification requirements in the original code under test can be quickly identified. This provides a clear direction for the team to optimize unit test case design, reduces the resources consumed by invalid tests, indirectly improves the overall effectiveness of unit tests, and provides technical support for ensuring software testing quality.

[0137] In one possible implementation, the following optimization measures can be taken for the mutated logic corresponding to the invalid unit tests: First, based on priority, unit test development should be concentrated on internal logic areas such as core algorithms, complex condition judgments, and core business rules, striving to achieve high mutation scores and strong assertion verification in these high-risk modules; deep unit testing should be implemented for complex internal logic, using combinatorial testing techniques to efficiently cover multi-condition combination scenarios, using state machine testing to traverse internal state transition paths, and injecting simulated exceptions to verify the unit's fault tolerance capability and kill mutated copies related to exception handling; finally, these strategies should be integrated into an automated and sustainable optimization closed loop: regularly run mutation tests and analyze reports to accurately identify core vulnerabilities and redundancies.

[0138] Based on the above S201-S206, a complete specific implementation of the unit test analysis method is given, such as... Figure 5 As shown, Figure 5 This is a complete flowchart illustrating a unit test analysis method provided in an embodiment of this application. First, the code file is scanned to filter out unit test classes. The assertions in the unit test code and the verification logic of the input and output parameters of the code under test are analyzed. Then, it is determined whether the assertions and verification logic of the unit test code exist. If not, the unit test code is recorded as invalid unit test code. If yes, the filtered code is added to the mutation test queue. The code under test in the queue is modified to generate a mutated copy of the code under test. The unit tests are run, and the unit test results are collected. It is determined whether the unit test execution failed. If yes, the unit test code is recorded as valid unit test code; otherwise, it is recorded as invalid unit test code, and the mutation logic is recorded. Based on the invalid unit test code obtained from the first determination and the result of the second determination, the mutation test coverage, the percentage of valid unit tests, the name of the invalid unit test method, and the mutation logic are output.

[0139] The method provided in this application first systematically evaluates assertions in unit test code, comprehensively verifying their matching degree with business requirements, logical completeness, and conditional rationality to ensure that assertions accurately reflect the expected behavior of software units. Based on this, mutation testing is conducted using validated, high-quality assertions. Pre-defined code mutation operators are introduced to generate mutated copies, and optimized assertions are used to filter and detect these mutated copies, accurately identifying whether test cases can detect these code mutations. Finally, a test report is output by statistically analyzing the preliminary evaluation results and the mutation test results. Starting with assertion verification, proceeding through mutation testing, and ultimately reaching a complete validity determination process, this provides objective and accurate quantitative evidence for the validity of unit test code. Particularly for airline scenarios, this process, by specifically configuring the mutation operator library in conjunction with business characteristics and conducting targeted mutation testing, further improves the accuracy and practicality of the unit test validity determination results, thereby more effectively achieving a scientific assessment of unit test validity.

[0140] This application embodiment can divide the above-described electronic device into functional modules based on the method example described above. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0141] In some embodiments, this application also provides a unit test analysis apparatus, which may include one or more functional modules for implementing the unit test analysis method described in the above method embodiments.

[0142] For example, Figure 6 This is a schematic diagram illustrating the composition of a unit test analysis device provided in an embodiment of this application. Figure 6As shown, the device includes: a determination module 601, a test module 602, and an output module 603. The determination module 601 is used to determine the unit test code corresponding to the code under test that needs to be unit tested in the code file of the aviation business domain. The unit test code is used to test whether the code under test is valid. The test module 602 is used to perform assertion logic tests on the unit test code. The determination module 601 is used to, if the unit test code passes the assertion logic test, modify the logic statements of the code under test according to the mutation operator library to determine a mutated copy of the code under test. The mutation operator library includes at least an aviation business mutation operator library and a general mutation operator library. The aviation business mutation operator library is used to indicate specific logic statements in aviation business. The modification method; a general mutation operator library is used to indicate the modification method of general logical statements; test module 602 is used to perform mutation tests on unit test code based on mutated copies; determination module 601 is used to determine the effectiveness evaluation result of unit test code based on mutation tests and assertion logic tests; output module 603 is used to output a unit test analysis report based on the effectiveness evaluation result of each unit test code. The unit test analysis report includes at least: mutation test coverage and effective unit test percentage; mutation test coverage is used to indicate the proportion of the number of tested code that participated in mutation tests to the total number of tested code; effective unit test percentage is used to indicate the proportion of the number of effective unit test code to the total number of unit test code.

[0143] In some embodiments, the aviation business variation operator library is used to store, but is not limited to, at least one of the following: modification methods for seat selection-related logical statements, modification methods for order processing-related logical statements, and modification methods for additional fee-related logical statements.

[0144] In some embodiments, the general mutation operator library is used to store at least one of the following modification methods, including but not limited to: modification methods for logic statements related to incrementing loops, modification methods for logic statements related to decrementing loops, modification methods for logic statements related to conditional branch judgments, modification methods for logic statements related to relational comparisons, modification methods for logic statements related to arithmetic logic, and modification methods for logic statements related to function calls.

[0145] In some embodiments, the unit test analysis report also includes mutation logic statements, which are used to indicate the logic statements corresponding to the mutated copies of the unit test code that cause the mutation test to fail.

[0146] In some embodiments, the determining module 601 is used to determine the validity evaluation result of the unit test code based on mutation testing and assertion logic testing, including: determining the unit test code as invalid unit test code if the unit test code passes the assertion logic test but fails the mutation test; determining the unit test code as valid unit test code if the unit test code passes both the assertion logic test and the mutation test; and determining the unit test code as invalid unit test code if the unit test code fails the assertion logic test.

[0147] In some embodiments, the test module 602 is configured to perform mutation testing on the unit test code based on the mutated copy, including: the test module 602 is specifically configured to perform unit testing on the mutated copy using the unit test code; the determination module 601 is specifically configured to determine that the unit test code has failed the mutation test if the mutated copy passes the unit test; the determination module 601 is specifically configured to determine that the unit test code has passed the mutation test if the mutated copy has failed the unit test.

[0148] In some embodiments, the determining module 601 is further configured to, before performing mutation testing on the unit test code based on the mutated copy, further include: performing input / output logic verification on the code under test to determine that the input / output behavior of the code under test conforms to a preset specification.

[0149] In an exemplary embodiment, this application also provides an electronic device, which may be the unit test analysis device in the above method embodiments. Figure 7 This is a schematic diagram of the structure of a unit test analysis device provided in an embodiment of this application, as shown below. Figure 7 As shown, the unit test analysis apparatus includes a processor 701 and a memory 702; the memory 702 stores instructions executable by the processor 701; when the processor 701 is configured to execute instructions, it causes an electronic device, network device, or manager to implement the method described in the foregoing method embodiments.

[0150] In an exemplary embodiment, this application also provides a computer-readable storage medium storing computer program instructions thereon; when the computer program instructions are executed by a computer, the computer causes the computer to implement the methods described in the foregoing embodiments. The computer may be an electronic device, a network device, or a manager. The computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0151] In the description of the embodiments of this application, specific features, structures, materials or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0152] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A unit test analysis method, characterized in that, The method includes: Identify the unit test codes corresponding to the code under test that requires unit testing in the code files of the aviation business domain; the unit test codes are used to test whether the code under test is effective. Perform assertion logic tests on the unit test code; If the unit test code passes the assertion logic test, the logic statements of the code under test are modified according to the mutation operator library to determine the mutated copy of the code under test; wherein, the mutation operator library includes at least an aviation business mutation operator library and a general mutation operator library; the aviation business mutation operator library is used to indicate the modification method of dedicated logic statements in aviation business; the general mutation operator library is used to indicate the modification method of general logic statements; The unit test code is subjected to mutation testing based on the mutated copy; Based on the mutation test and the assertion logic test, the effectiveness evaluation result of the unit test code is determined; Based on the effectiveness evaluation results of each unit test code, a unit test analysis report is output. The unit test analysis report includes at least: mutation test coverage and effective unit test percentage. The mutation test coverage is used to indicate the proportion of the number of tested code that participated in mutation testing to the total number of tested code. The effective unit test percentage is used to indicate the proportion of the number of effective unit test code to the total number of unit test code.

2. The method according to claim 1, characterized in that, The aviation business variation operator library is used to store at least one of the following: modification methods for seat selection-related logical statements, modification methods for order processing-related logical statements, and modification methods for additional fee-related logical statements.

3. The method according to claim 1, characterized in that, The general mutation operator library is used to store at least one of the following modification methods, including but not limited to: modification methods for logic statements related to incrementing loops, modification methods for logic statements related to decrementing loops, modification methods for logic statements related to conditional branch judgments, modification methods for logic statements related to relational comparisons, modification methods for logic statements related to arithmetic logic, and modification methods for logic statements related to function calls.

4. The method according to claim 1, characterized in that, The unit test analysis report also includes mutation logic statements, which are used to indicate the logic statements corresponding to the mutated copies that cause the unit test code to fail the mutation test.

5. The method according to claim 1, characterized in that, The determination of the effectiveness evaluation result of the unit test code based on the mutation test and the assertion logic test includes: If the unit test code passes the assertion logic test but fails the mutation test, the unit test code is determined to be invalid unit test code. If the unit test code passes the assertion logic test and the mutation test, the unit test code is determined to be valid unit test code. If the unit test code fails the assertion logic test, the unit test code is determined to be invalid.

6. The method according to claim 1, characterized in that, The mutation testing of the unit test code based on the mutated copy includes: Use the unit test code to perform unit tests on the mutated copy; If the mutated copy passes the unit test, it is determined that the unit test code fails the mutation test; If the mutated copy fails the unit test, the unit test code is determined to have passed the mutation test.

7. The method according to claim 1, characterized in that, Before performing mutation testing on the unit test code based on the mutated copy, the method further includes: The input / output logic of the code under test is verified to confirm that the input / output behavior of the code under test conforms to the preset specifications.

8. A unit test analysis device, characterized in that, The device includes a determination module, a test module, and an output module; The determination module is used to determine the unit test code corresponding to the test code that needs to be unit tested in the code files of the aviation business domain. The unit test code is used to test whether the code under test is effective; The testing module is used to perform assertion logic tests on the unit test code; The determination module is used to, in the case that the unit test code passes the assertion logic test, modify the logic statements of the code under test according to the mutation operator library, and determine the mutated copy of the code under test; wherein, the mutation operator library includes at least an aviation business mutation operator library and a general mutation operator library; the aviation business mutation operator library is used to indicate the modification method of dedicated logic statements in aviation business; the general mutation operator library is used to indicate the modification method of general logic statements; The testing module is used to perform mutation testing on the unit test code based on the mutated copy; The determination module is used to determine the effectiveness evaluation result of the unit test code based on the mutation test and the assertion logic test. The output module is used to output a unit test analysis report based on the effectiveness evaluation results of each unit test code. The unit test analysis report includes at least: mutation test coverage and effective unit test percentage. The mutation test coverage is used to indicate the proportion of the number of tested code that participated in mutation testing to the total number of tested code. The effective unit test percentage is used to indicate the proportion of the number of effective unit test code to the total number of unit test code.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory; The memory stores instructions that the processor can execute; When the processor is configured to execute the instructions, the electronic device performs the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes: computer software instructions; When the computer software instructions are executed in an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-7.

Images