Unit test method based on large model

Abstract

The invention belongs to the technical field of software engineering, and particularly relates to software testing, in particular to a unit testing method based on a large model. Reading a source code from the tested unit; the code features are enhanced through an enhancement method; performing endpoint labeling and segmentation on the code by using a multi-dimensional code correlation comprehensive evaluation analysis method; inputting the segmented code into a code task unit test thinking chain template and generating a corresponding unit test; the segmented unit test is sent to coverage rate detection and coverage information analysis, and a unit test report is automatically generated according to a test report model; the uncovered information is fed back to the thinking chain to be repaired, and a repaired unit test case is generated and moved backwards. According to the method, the unit test case generated by the segmented feedback thinking is used, so that the test with higher coverage rate can be realized on the whole under the condition that a local high coverage effect is achieved.

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology, and particularly relates to the fields of software testing, unit testing, large models, and artificial intelligence. Specifically, it relates to a unit testing method based on a large model. Background Technology

[0002] Unit testing primarily refers to the inspection and verification of the smallest testable unit in software. Through unit testing, developers can identify defects and problems in the code early in the software development process, thereby effectively ensuring the correctness of the program. Unit testing is often performed by testers; however, the process of writing unit test cases requires testers to first understand the function's functionality and branches, understand boundary conditions and possible abnormal situations, which is time-consuming and labor-intensive, and there is a risk of omissions.

[0003] In existing testing technologies, different testing frameworks exist for different programming languages, such as JUnit, pytest, and CUnit. Each framework has its unique syntax, functionality, and usage. Testers need to spend a significant amount of time studying the documentation of these frameworks to understand their various concepts and operations. For different languages, testers need to understand how to write test case classes, how to use assertion methods, and how to parameterize test data. While automated testing frameworks have brought some convenience to software testing, the current software testing process still has some problems. Different testers may have different understandings and design approaches to test cases, leading to inconsistent test case quality. Moreover, due to the lack of systematic and standardized test case design, it is easy to overlook some important boundary conditions and special scenarios.

[0004] In summary, existing unit testing methods have several problems in areas such as test case design and writing. These problems not only affect the efficiency of software testing but also increase the workload of testers. Therefore, how to optimize unit testing methods, reduce the workload of testers, and improve the efficiency and quality of software testing has become an urgent problem to be solved in the current software development field. Summary of the Invention

[0005] The purpose of this invention is to address the problems of time-consuming and labor-intensive unit test case writing, low test case coverage, lack of systematic and standardized automated testing methods, and the generation illusion caused by large models in code tasks. This invention proposes a unit testing method based on a large language model, which can analyze the code to be tested and automatically generate unit test cases, automatically perform tests, and generate test reports.

[0006] The technical solution of this invention is: This invention provides a unit testing method based on a large model, which can automatically generate unit test cases and execute unit tests. It reads the source code from the unit under test, enhances the source code features using an enhancement method, calculates the inter-code relevance using a multi-dimensional code relevance comprehensive evaluation formula, and performs endpoint annotation and block segmentation. The segmented code is input into the large model's thought process chain to generate corresponding unit tests. These segmented unit tests are then sent to coverage detection and coverage information analysis. Coverage information is fed back to the thought process chain for repair, generating repaired unit test cases. This automatically generates unit test code for the target test source code, thus enabling unit testing of the target test source code.

[0007] Furthermore, the following steps are included: Step 1: Reading the source code of the unit under test and enhancing its features; Step 1.1: Read the code, determine the language and framework, and generate dependencies; Step 1.2: Employ code cleaning methods, including modifying code formatting and macro definitions, revising comments, enhancing source code features, and generating standardized comments. Step 2: Perform multi-dimensional code relevance analysis on the source code, perform endpoint annotation and block processing based on the relevance threshold, and update code comments; Step 2.1: Based on syntactic structure relevance, semantic relevance, data flow relevance, control flow relevance, code location relevance, code pattern relevance, code comment relevance, code modification history relevance, and execution result relevance, calculate the inter-line code relevance using a weighted formula. Step 2.2: Use the multi-dimensional code relevance comprehensive evaluation formula to obtain the relevance between lines of code, and perform endpoint labeling and block segmentation, and update the block information.

[0008] Step 3: Construct a code task unit test mind chain template and generate unit test cases based on it; Step 3.1: Construct a code task unit test mind chain template. Step 3.2: Based on the function and logic of the code block, determine the type, range, and boundary conditions of its input parameters, as well as possible abnormal situations; Step 3.3: Use the code task unit test mind chain template to add the scope and boundary conditions to the mind chain to generate unit test cases.

[0009] Step 4: Obtain coverage information based on unit test cases; Step 4.1: Create a test report mind chain template. Step 4.2: Run the generated unit test cases to perform tests, collect coverage information, and generate a coverage report; Step 5: Based on the coverage information feedback back to the thinking chain, use the feedback thinking chain to automatically iterate test cases; Step 5.1: Determine if the block coverage meets the requirements. If it does, return to step 3.3 and generate unit test code for the next block. Step 5.2: If the requirements are not met, identify the missing conditions, return to Step 3.3, and feed back the uncovered information and missing conditions to the thought process chain to iterate on that block. If the requirements are not met, retain the valid unit test parts and send the uncovered information back to the unit test thought process chain, re-execute the generation and testing, and retain the test report information for each iteration until the coverage meets the requirements.

[0010] Furthermore, in step 1.2, the output format is specifically as follows: / / <Sequence Number><Statement Type: Declaration / Assignment / IO / Exception Handling / Branching / Object Operation / Function Call><Function Involved / No Function: Function Name><Variables Involved: Variable 1, Variable 2, ...><Statement Function: Related Function>.

[0011] Furthermore, in step 2.1, the specific formula is as follows:

[0012] (1)

[0013] in, ~ These are weight parameters, derived from the original weight parameters. Obtained through the softmax function The weighting parameters are adjusted according to the specific scenario. (Partial) The parameters are calculated using Jaccard similarity, which is expressed as follows:

[0014] in , There are two sets, each representing a line of code consisting of words. The elements in the set refer to the words contained in the line of code.

[0015] Specifically, It is a syntactic structural correlation, affected by variable name overlap, operator similarity, and statement type similarity. Its expression is:

[0016] in , , These are weight parameters, and their sum is 1. , It is a set of variable names in two lines. , It is the set of operators in two lines of code. The value is 1 if the two lines of code have the same type, and 0 if they have different types.

[0017] It is semantic relevance, influenced by the semantic association between variables and functions, and by the semantic context. Its expression is:

[0018] in , These are weight parameters, and their sum is 1. Obtained by embedding from the CodeT-BERT model. The context of two lines of code is read, and the semantic similarity between adjacent statements is calculated.

[0019] It refers to data flow correlation, which is affected by data dependencies, and its expression is:

[0020] in , These are collections of related data from the two lines of code.

[0021] It is control flow dependency, affected by control flow correlation, and its expression is:

[0022] in , These are the control flow paths where the two lines of code are located.

[0023] It is code position dependence, affected by line spacing and nesting relationships, and its expression is:

[0024] in , These are weight parameters, and their sum is 1. , These are the line numbers of two lines of code. , It refers to the nesting of two lines of code.

[0025] This refers to code pattern relevance, which is influenced by code template similarity and syntax repetition. Its expression is:

[0026] in , These are the string collections from the two lines of code.

[0027] This refers to code comment relevance, which is affected by the similarity of comment content. Its expression is:

[0028] in , These are comments in the two lines of code.

[0029] This refers to code modification history relevance, influenced by modification associations in version control. Its expression is:

[0030] in , These represent two lines of code respectively. For indicator functions, if and In the If all modifications are made in each submission, the value is 1; otherwise, it is 0. This is the time decay coefficient, which controls the rate at which the weights of historical submissions decay. This represents the total number of submissions to date. For all submissions and The total number of group practice sessions. For code .

[0031] It refers to the correlation of code execution results, which is affected by the similarity of output results. Its expression is:

[0032] in , These are the return types of the two lines of code. , It is the numerical value of the return value. The weights are 1, and the sum is 1.

[0033] Furthermore, in step 2.2, starting from the first statement after the function declaration statement, the correlation between the current line and the previous lines is calculated sequentially to complete the traversal of the entire function.

[0034] Furthermore, in step 2.2, the first line inside the function to be tested is taken as the first endpoint, and the search continues to find lines with a correlation lower than the threshold, or when a branch statement is encountered, it is taken as the second endpoint, and so on, until the traversal of the function is completed.

[0035] Furthermore, in step 2.2, the data is divided into blocks based on the endpoint annotation results. The annotations for each previous line are updated to include the block information.

[0036] Furthermore, the CodeT-BERT model specifically employs the following methods: It additionally accepts AST paths through multiple code channels to compensate for the structural information missing in plain text. A cross-modal bridge is established, allowing natural language and code to interact at each layer. Code-specific structural prediction and sentence order prediction are introduced, enabling weight sharing in the lower-level Transformer and adding sparse attention to the higher-level code pyramid to capture long-range dependencies.

[0037] The advantages of this invention are: This invention proposes a goal-oriented (high coverage), closed-loop feedback-driven automated unit test generation framework that integrates advanced code analysis techniques (multi-dimensional correlation, CodeT-BERT) and LLM capabilities (thought chain, code generation). It represents an important research direction for improving software testing efficiency and quality using AI, possessing significant innovation and practical potential, especially when dealing with logically clear and well-modularized code. It has the following innovative advantages: 1. Significantly improves the level of test automation.

[0038] Key automation steps: Achieve full automation of the entire process from code parsing → logic segmentation → test generation → coverage analysis → iterative optimization, significantly reducing the workload of manually writing test cases and analyzing code logic.

[0039] Lowering the technical barrier: Even non-testing experts can quickly understand code logic and test intent through standardized comments and reports generated by LLM.

[0040] 2. Breaking through the limitations of traditional block-based approaches, it accurately locates the testing target.

[0041] Intelligent logic block segmentation: Based on multi-dimensional dynamic correlation analysis (especially the innovative historical co-revision penalty mechanism), it replaces rigid syntax block segmentation (such as segmentation by function / class), making the block segmentation closer to the actual functional boundaries of the code.

[0042] Focus on core logic: Avoid over-testing low-relevance code (such as independent configuration items), and concentrate resources on highly cohesive logic units.

[0043] 3. Deep code understanding drives the generation of high-quality tests.

[0044] Structured semantic parsing: CodeT-BERT integrates AST and text to enhance LLM's deep understanding of code semantics (such as data flow and exception handling).

[0045] Boundary condition explicitness: This requires mandatory analysis of parameter types / ranges / boundaries, and guides the LLM to generate targeted use cases (such as extreme values ​​and illegal inputs) through mind chain templates.

[0046] 4. A closed-loop optimization mechanism oriented towards coverage.

[0047] Real-time feedback iteration: Coverage data and uncovered scenarios are directly fed back to the LLM mind chain, driving dynamic optimization of test cases and solving the blindness of traditional generative testing.

[0048] Incremental enhancement: This strategy of retaining valid use cases and iteratively filling gaps avoids repetitive work and is far more efficient than regenerating all use cases.

[0049] 5. Enhance the interpretability and traceability of the testing process.

[0050] Transparent decision-making process: Standardized annotations, relevance formulas, and mind chain logs make LLM code comprehension and test decision logic auditable.

[0051] Complete traceability: Retain test reports and coverage changes from each iteration to facilitate locating difficult code and verifying optimization effects.

[0052] 6. Historical data empowers engineering practice.

[0053] Version history intelligent utilization: Modify historical relevance to introduce "time decay" and "co-repair penalty" to make the block results fit the actual development model (e.g., code that is frequently co-repaired should be tested in the same block).

[0054] Team experience accumulation: The development logic implicit in the historical commit patterns is transformed into a basis for block division, forming organizational-level knowledge reuse. Attached Figure Description

[0055] Figure 1 A flowchart of the unit testing method based on a large model provided by this invention; Figure 2 A schematic diagram of the multi-dimensional code relevance comprehensive evaluation formula provided by this invention; Figure 3 This invention provides a schematic diagram for generating unit test reports based on a mind chain template; Figure 4 The flowchart of the unit test generation algorithm based on a large model feedback thinking chain provided by this invention is shown. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0057] The features and illustrative embodiments of various aspects of the present invention will now be described in detail. Numerous specific details are set forth in the following detailed description to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced without requiring some of these specific details. The following description of embodiments is merely intended to provide a better understanding of the invention by illustrating examples of the invention. The invention is by no means limited to any specific setups and methods set forth below, but covers any improvements, substitutions, and modifications to structures, methods, and devices without departing from the spirit of the invention. Well-known structures and techniques are not shown in the drawings and the following description to avoid unnecessarily obscuring the invention.

[0058] Example 1 Step 1: Reading the source code of the unit under test and enhancing its features; Step 1.1: Read the code, determine the language and framework, and generate dependencies; Step 1.2: Employ code cleaning methods, including modifying code formatting and macro definitions, and altering comments, to enhance source code features and generate standardized comments. The output format is as follows: / / <Sequence Number><Statement Type: Declaration / Assignment / IO / Exception Handling / Branching / Object Operation / Function Call><Function Involved / No Function: Function Name><Variables Involved: Variable 1, Variable 2, ...><Statement Function: Related Function> Step 2: Perform multi-dimensional code relevance analysis on the source code, perform endpoint annotation and block processing based on the relevance threshold, and update code comments; Step 2.1: Based on syntactic structure relevance, semantic relevance, data flow relevance, control flow relevance, code location relevance, code pattern relevance, code comment relevance, code modification history relevance, and execution result relevance, calculate the inter-line code relevance using a weighted formula:

[0059] (1)

[0060] in, ~ These are weight parameters, derived from the original weight parameters. Obtained through the softmax function The weight parameters can be adjusted according to the specific scenario. (Partial) The parameters are calculated using Jaccard similarity, which is expressed as follows:

[0061] in , These are two sets, which in this example represent two lines of code consisting of tokens. The elements in the sets refer to the tokens contained in the lines of code.

[0062] Specifically, It is a syntactic structural correlation, affected by variable name overlap, operator similarity, and statement type similarity. Its expression is:

[0063] in , , These are weight parameters, and their sum is 1. , It is a set of variable names in two lines. , It is the set of operators in two lines of code. The value is 1 if the two lines of code have the same type, and 0 if they have different types.

[0064] It is semantic relevance, influenced by the semantic association between variables and functions, and by the semantic context. Its expression is:

[0065] in , These are weight parameters, and their sum is 1. Obtained by embedding from the CodeT-BERT model. The context of two lines of code is read, and the semantic similarity between adjacent statements is calculated.

[0066] CodeT-BERT is an improved BERT model proposed in this invention, designed for code. It accepts additional AST paths through multiple code channels to compensate for the structural information missing in plain text. It establishes a cross-modal bridge, allowing natural language and code to interact at every layer, rather than just being concatenated at the top level. This enables weight sharing in the lower-level Transformer and adds sparse attention to the higher-level code pyramid to capture long-range dependencies.

[0067] It refers to data flow correlation, which is affected by data dependencies, and its expression is:

[0068] in , These are collections of related data from the two lines of code.

[0069] It is control flow dependency, affected by control flow correlation, and its expression is:

[0070] in , These are the control flow paths where the two lines of code are located.

[0071] It is code position dependence, affected by line spacing and nesting relationships, and its expression is:

[0072] in , These are weight parameters, and their sum is 1. , These are the line numbers of two lines of code. , It refers to the nesting of two lines of code.

[0073] This refers to code pattern relevance, which is influenced by code template similarity and syntax repetition. Its expression is:

[0074] in , These are the string collections from the two lines of code.

[0075] This refers to code comment relevance, which is affected by the similarity of comment content. Its expression is:

[0076] in , These are comments in the two lines of code.

[0077] This refers to code modification history relevance, influenced by modification associations in version control. Its expression is:

[0078] in , These represent two lines of code respectively. For indicator functions, if and In the If all modifications are made in each submission, the value is 1; otherwise, it is 0. This is the time decay coefficient, which controls the rate at which the weights of historical submissions decay. This represents the total number of submissions to date. For all submissions and The total number of group practice sessions. For code The total number of times a code has been modified across all commits. This factor incorporates time decay and co-modification significance assessment, with more recent co-modifications receiving higher weights to avoid long-term interference from early irrelevant modifications. If two lines of code are frequently modified individually but have a low co-modification rate, this factor will penalize relevance to prevent false positives for high-frequency but irrelevant modifications.

[0079] It refers to the correlation of code execution results, which is affected by the similarity of output results. Its expression is:

[0080] in , These are the return types of the two lines of code. , It is the numerical value of the return value.

[0081] These parameters take values ​​between 0 and 1. The weights can be modified depending on the scenario, or left to the trained model to determine. For each line of code, calculate its correlation coefficient with previous lines using the above formula, and determine the correlation threshold based on the relative length of the overall code.

[0082] Step 2.2: Use the multi-dimensional code relevance comprehensive evaluation formula to obtain the relevance between lines of code, and perform endpoint labeling and block segmentation, and update the block information.

[0083] Starting from the first line after the function declaration, calculate the relevance between the current line and the previous lines sequentially to complete the traversal of the entire function. Using the first line inside the function as the first endpoint, search for lines with a relevance below the threshold, or for branches, using them as the second endpoint, and so on, until the function traversal is complete. Divide the code into blocks based on the endpoint annotations. Update the comments for each previous line, adding the block information.

[0084] Step 3: Construct a code task unit test mind chain template and generate unit test cases based on it; Step 3.1: Construct a code task unit test mind chain template, as follows: <instruction> Perform unit tests on the blocks to ensure they correctly handle various inputs.< / instruction> <description> The block function information obtained in step 3.1< / description> <input> Parameter 1, Parameter 2... <rationale> The block branch information obtained in step 3.1, as well as possible previously generated unit test information.< / rationale> <code> "block code" < / code> <step> 1. Thought Process< / step> <step> 2. Thought Process< / step> <step> ……< / step> <result> Pass / Fail< / result> Step 3.2: Based on the function and logic of the code block, determine the type, range, and boundary conditions of its input parameters, as well as possible abnormal situations; Step 3.3: Use the code task unit test mind chain template to add the scope and boundary conditions to the mind chain to generate unit test cases.

[0085] Step 4: Obtain coverage information based on unit test cases; Step 4.1: Create a test report mind chain template. The template is as follows: <instruction> Generate a detailed test report covering the results and analysis of all test cases.< / instruction> <test_environment> - hardware: - software: - operating system: < / test_environment> <test_case> <description> "Test Objective"< / description> <input> "Test Input" <expected_output> Expected Results< / expected_output> <actual_output> <code> "Related Code" < / code> < / actual_output> <assertion> <code> "Code corresponding to test cases" < / code> < / assertion> <result> Pass / Fail< / result> < / test_case> <test_summary> - Total number of test cases: - Number of test cases passed: - Number of failed test cases: - Uncovered test scenarios: < / test_summary> <issue_analysis> - No obvious problems found\line x is missing.

[0086] < / issue_analysis> <improvement_suggestions> - Add more test cases with boundary conditions.

[0087] - Consider adding processing logic for non-numeric inputs.

[0088] < / improvement_suggestions> Step 4.2: Run the generated unit test cases to perform tests, collect coverage information, and generate a coverage report; Step 5: Based on the coverage information feedback back to the thinking chain, use the feedback thinking chain to automatically iterate test cases; Step 5.1: Determine if the block coverage meets the requirements. If it does, return to step 3.3 and generate unit test code for the next block. Step 5.2: If the requirements are not met, identify the missing conditions, return to Step 3.3, and feed back the uncovered information and missing conditions to the thought process chain to iterate on that block. If the requirements are not met, retain the valid unit test parts and send the uncovered information back to the unit test thought process chain, re-execute the generation and testing, and retain the test report information for each iteration until the coverage meets the requirements.

[0089] Example 2 Step 1: Reading the source code of the unit under test and enhancing its features Step 1.1: Read the code, determine the language and framework, and generate dependencies; The source code of the function to be tested is as follows. This function cleans, weights, and calculates the average score of the user-input score dictionary: def process_user_scores(raw_data, bonus=0, strict=False): if not isinstance(raw_data, dict): raise TypeError("raw_data must be a dict") if not isinstance(bonus, (int, float)): raise ValueError("bonus must be a number") valid_scores = [] for name, score in raw_data.items(): if not isinstance(name, str) or not name.strip(): continue try: score = float(score) except (TypeError, ValueError): if strict: raise ValueError(f"Invalid score for {name}: {score}") continue if score < 0 or score > 100: continue valid_scores.append(score + bonus) if not valid_scores: return None return round(sum(valid_scores) / len(valid_scores), 2) Language: Python Testing framework: pytest Step 1.2: Use code cleaning methods, including modifying code formatting and macro definitions, and modifying comments, to enhance source code features and generate standardized comments. The automatically generated standardized comments are as follows: / / 1 Function declaration process_user_scores raw_data bonus strict Process user score dictionary / / 2 Branch isinstance raw_data dict type checking: raw_data / / 3. Raise TypeError if no TypeError is raised / / 4-branch isinstance bonus (int, float) type check: bonus / / 5. Raise ValueError if no ValueError is raised. / / 6 Declare valid_scores (no initialization required) as a list of valid scores / / 7 Loop through raw_data.items() name score Iterate through the dictionary items / / 8 Branch isinstance name str Empty string check key validity / / 9 Control continue (no skipping illegal keys) / / 10 Try `float(score) score` Try converting the score to a floating-point number. / / 11 Exceptions except TypeError ValueError score Catching illegal values / / 12 branches strict (no indication of strict mode) / / 13 Exception raise ValueError name score Throws a ValueError / / 14 Control continue without skipping illegal values / / 15 Branches: score < 0 or > 100. Check the score range. / / 16 Control continue without skipping out-of-bounds scores / / 17 The expression append score+bonus adds the weighted score to the list. / / Branch 18 not valid_scores Check if the valid_scores list is empty / / 19 Returns None. Returns an empty result if no result is found. / / 20 Returns the expression round(sum(...) / len(...), 2) valid_scores Returns the average score Step 2: Perform multi-dimensional code relevance analysis on the source code, and perform endpoint labeling and block processing based on the relevance threshold; The correlation between lines is obtained based on a multi-dimensional code relevance comprehensive evaluation formula. Here are some examples: Lines 8-9 (Illegal key handling): Correlation 0.91 Lines 11-12 (Exception Handling): Correlation 0.87 Lines 18-19 (empty list returned): Relevance 0.93 Line 2-17: Correlation 0.12 (low coupling) Set the relevance threshold to 0.5, and force the division to use raise, continue, and return as endpoints, ultimately resulting in 4 independent blocks: Block 1: Line 1 (Function Declaration) Block 2: Lines 2-5 (Input validity check) Block 3: Lines 6-17 (Circulatory Cleansing and Weighting) Block 4: Lines 18-20 (Result Calculation and Return) Add a [Block X] marker after the existing line comment to facilitate subsequent template location.

[0090] Step 3: Construct a code task unit test mind chain template and generate unit test cases based on it; Generate a code task unit test mind chain based on the code task unit test mind chain template and previous information, taking Block 3 as an example: <instruction> Perform unit testing on Block 3 to ensure that the cleaning, conversion, and weighting logic within the loop is correct.< / instruction> <description> Traverse dictionary key-value pairs, perform type checking, value range checking, exception handling, and weighted summation.< / description> <input> raw_data: dict, bonus: float, strict: bool <rationale> - Valid keys: non-empty strings - Valid values: can be converted to float and are between 0 and 100. - When strict=True, illegal values ​​must throw a ValueError. - All valid values ​​need to be added together as a bonus. < / rationale> <code> ...(Block 3 source code)... < / code> <step> 1. Constructor key is an illegal type (int) → Should be skipped< / step> <step> 2. Constructing a value of the string "abc" → if strict=False, skip; if strict=True, raise a ValueError.< / step> <step> 3. Constructing values ​​out of bounds -5 and 105 → Skip< / step> <step> 4. Constructing normal values ​​80 and 90 → After weighting, it should be [80 + bonus, 90 + bonus].< / step> <result> pass< / result> Based on the above code task unit testing thought process, the generated pytest test case snippet is as follows: import pytest from module import process_user_scores @pytest.mark.parametrize("data,bonus,strict,expected", [ ({"Alice": 80, "Bob": 90}, 5, False, 87.5), ({"": 50, 123: 60}, 0, False, None), ({"A": "abc"}, 0, True, pytest.raises(ValueError)), ({"A": -5, "B": 105}, 0, False, None), ]) def test_block3(data, bonus, strict, expected): if hasattr(expected, "__enter__"): # Handle pytest.raises with expected: process_user_scores(data, bonus, strict) else: assert process_user_scores(data, bonus, strict) == expected Step 4: Obtain coverage information based on unit test cases; Run the generated unit test cases to perform tests, collect coverage information, and generate a coverage report; <test_summary> - Total number of test cases: 12 - Number of test cases passed: 12 - Number of failed test cases: 0 - Uncovered test scenario: strict=False and internal exception branch < / test_summary> <issue_analysis> - The except branch on line 11 did not throw an exception when strict=False. < / issue_analysis> <improvement_suggestions> - Added test for empty dictionary input - Add boundary tests for negative bonuses < / improvement_suggestions> Step 5: Based on the coverage information feedback back to the thinking chain, use the feedback thinking chain to automatically iterate test cases; Based on the uncovered information, the system calls the thought process chain again, generating test cases only for the missing branches: Input: {"A": "NaN"}, 0, False Expected outcome: Skip "NaN" and return None. After supplementary testing, the branch coverage increased to 100%, thus obtaining high-coverage test cases for the function under test.

[0091] It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other, and the various embodiments can be referenced and cited in each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0092] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should be covered within the protection scope of the present invention.

Claims

1. A unit testing method based on a large model, characterized in that, By reading the source code from the unit under test, enhancing the features of the source code through enhancement methods, calculating the correlation between codes using a multi-dimensional code relevance comprehensive evaluation formula, and performing endpoint labeling and block segmentation, the segmented code is input into the large model's thinking chain to generate corresponding unit tests. The segmented unit tests are then sent to coverage detection and coverage information is analyzed. Coverage information is fed back to the thinking chain for repair, generating repaired unit test cases, and automatically generating unit test code for the target test source code, thus enabling unit testing of the target test source code.

2. The method as described in claim 1, characterized in that, Includes the following steps: Step 1: Reading the source code of the unit under test and enhancing its features; Step 1.1: Read the code, determine the language and framework, and generate dependencies; Step 1.2: Employ code cleaning methods, including modifying code formatting and macro definitions, revising comments, enhancing source code features, and generating standardized comments. Step 2: Perform multi-dimensional code relevance analysis on the source code, perform endpoint annotation and block processing based on the relevance threshold, and update code comments; Step 2.1: Based on syntactic structure relevance, semantic relevance, data flow relevance, control flow relevance, code location relevance, code pattern relevance, code comment relevance, code modification history relevance, and execution result relevance, calculate the inter-line code relevance using a weighted formula. Step 2.2: Use the multi-dimensional code relevance comprehensive evaluation formula to obtain the relevance between lines of code, and perform endpoint labeling and block segmentation, and update the block information; Step 3: Construct a code task unit test mind chain template and generate unit test cases based on it; Step 3.1: Construct a code task unit test mind chain template. Step 3.2: Based on the function and logic of the code block, determine the type, range, and boundary conditions of its input parameters, as well as possible abnormal situations; Step 3.3: Use the code task unit test mind chain template to add the scope and boundary conditions to the mind chain to generate unit test cases; Step 4: Obtain coverage information based on unit test cases; Step 4.1: Create a test report mind chain template. Step 4.2: Run the generated unit test cases to perform tests, collect coverage information, and generate a coverage report; Step 5: Based on the coverage information feedback back to the thinking chain, use the feedback thinking chain to automatically iterate test cases; Step 5.1: Determine if the block coverage meets the requirements. If it does, return to step 3.3 and generate unit test code for the next block. Step 5.2: If the requirements are not met, identify the missing conditions, return to step 3.3, and feed back the uncovered information and missing conditions to the thinking chain to iterate on this block; if the requirements are not met, retain the valid unit test parts and send the uncovered information back to the unit test thinking chain, re-execute the generation and testing, retain the test report information of each iteration until the coverage meets the requirements.

3. The method as described in claim 2, characterized in that, In step 1.2, the output format is specifically as follows: / / <Sequence Number> <Statement Type: Declaration / Assignment / IO / Exception Handling / Branching / Object Operation / Function Call> <Function Involved / No Function: Function Name> <Variables Involved: Variable 1, Variable 2, ...> <Statement Function: Related Function>.

4. The method as described in claim 2, characterized in that, In step 2.1, the specific formula is as follows: (1) in, ~ These are weight parameters, derived from the original weight parameters. Obtained through the softmax function The weighting parameters are adjusted according to the specific scenario; some The parameters are calculated using Jaccard similarity, which is expressed as follows: in , There are two sets, each representing a line of code consisting of words. The elements in the set refer to the words contained in the line of code. Specifically, It is a syntactic structural correlation, affected by variable name overlap, operator similarity, and statement type similarity. Its expression is: in , , These are weight parameters, and their sum is 1. , It is a set of variable names in two lines. , It is the set of operators in two lines of code; The value is 1 if the two lines of code have the same type, and 0 if they are different. It is semantic relevance, influenced by the semantic association between variables and functions, and by the semantic context. Its expression is: in , These are weight parameters, and their sum is 1. Obtained by embedding from the CodeT-BERT model. The context of two lines of code is read, and the semantic similarity between adjacent statements is calculated. It refers to data flow correlation, which is affected by data dependencies, and its expression is: in , These are collections of related data from the two lines of code; It is control flow dependency, affected by control flow correlation, and its expression is: in , These are the control flow paths where the two lines of code are located; It is code position dependence, affected by line spacing and nesting relationships, and its expression is: in , These are weight parameters, and their sum is 1. , These are the line numbers of two lines of code. , It refers to the nesting of two lines of code; This refers to code pattern relevance, which is influenced by code template similarity and syntax repetition. Its expression is: in , These are the string collections in the two lines of code; This refers to code comment relevance, which is affected by the similarity of comment content. Its expression is: in , These are comments in the two lines of code; This refers to code modification history relevance, influenced by modification associations in version control. Its expression is: in , These represent two lines of code respectively. For indicator functions, if and In the If all commits are modified, the value is 1; otherwise, the value is 0. This is the time decay coefficient, which controls the rate at which the weights of historical submissions decay. This represents the total number of submissions to date. For all submissions and The total number of group practice sessions. For code ; It refers to the correlation of code execution results, which is affected by the similarity of output results. Its expression is: in , These are the return value types of the two lines of code. , It is the numerical value of the return value. The weights are 1, and the sum is 1.

5. The method as described in claim 2, characterized in that, In step 2.2, starting from the first statement after the function declaration statement, the correlation between the current line and the previous lines is calculated sequentially to complete the traversal of the entire function.

6. The method as described in claim 5, characterized in that, Take the first line inside the function under test as the first endpoint, and search for lines with a relevance lower than the threshold, or for branches, take them as the second endpoint, and so on, until the function is traversed.

7. The method as described in claim 6, characterized in that, The data is divided into blocks based on the endpoint annotations; the annotations of each previous line are updated to include the block information.

8. The method as described in claim 2, characterized in that, The specific method of the CodeT-BERT model is as follows: additional AST paths are received through multiple code channels to make up for the structural information missing in plain text; a cross-modal bridge is established to allow natural language and code to interact at each layer, introducing code-specific structural prediction and sentence order prediction, realizing weight sharing of the lower-level Transformer, and adding sparse attention to the higher-level code tower to capture long-range dependencies.

Images