Iterative contextual retrieval method, apparatus, and medium for defect reproduction test generation
By using an iterative contextual retrieval method, combined with production code and test suites, the generation of defect reproduction tests is optimized, solving the problems of insufficient and redundant retrieval in existing technologies, and achieving efficient and accurate generation of defect reproduction tests.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHEJIANG UNIV
- Filing Date
- 2026-03-31
- Publication Date
- 2026-06-12
AI Technical Summary
Existing defect reproduction methods fail to effectively distinguish between the retrieval needs of production code and test code, ignore function call relationships, and lack an iterative feedback mechanism for generation and retrieval, resulting in insufficient or redundant retrieval results, which affects the accuracy and efficiency of defect reproduction testing.
An iterative context retrieval method is adopted. Keywords are extracted by parsing defect descriptions, and combined with production code base and test suites. A large language model is used to generate and optimize test drafts, calculate text and function call similarity, perform iterative re-ranking, and finally generate high-quality context.
It significantly improves the accuracy and efficiency of defect reproduction testing, reduces redundant code, lowers the cost of API calls, and increases the success rate of generating large language models.
Smart Images
Figure CN122195850A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software engineering, and more particularly to an iterative context retrieval method, device, and medium for defect reproduction test generation. Background Technology
[0002] As software systems grow increasingly large and code logic becomes more complex, code defects are often unavoidable during software development. Code defects not only cause system malfunctions and severely impact user experience, but can also lead to significant economic losses. With the accelerating pace of software iteration, the workload of reproducing and fixing code defects has exploded, making manual reproduction and repair extremely time-consuming and difficult. Therefore, automating the generation of bug reproduction tests is crucial for helping developers quickly locate problems, verify patches, and ensure software quality.
[0003] In recent years, Large Language Models (LLMs) have been widely used for automatically generating defect reproduction tests due to their powerful understanding and generation capabilities. The effectiveness of this automated generation is highly dependent on the quality of the retrieved context. Insufficient or redundant contextual information directly limits the model's reasoning depth regarding the defect logic. Existing LLM-based defect reproduction methods typically use traditional word frequency matching (such as BM25) or LLM-driven retrieval agents to obtain context. However, these retrieval methods have significant limitations: First, existing retrieval methods often employ a uniform retrieval strategy to process software repositories under test, failing to fully consider the fundamental differences in retrieval requirements between production code and test code, resulting in retrieval results that are difficult to balance business logic and test scenarios. Second, current retrieval methods mainly rely on text semantic similarity, neglecting function call relationships that reflect the relevance of dynamic code behavior. Finally, existing retrieval processes are usually unidirectional and static, lacking a feedback loop that utilizes generated results to optimize the retrieval, causing the retrieval engine to be unable to adaptively optimize the context selection strategy.
[0004] In summary, there is an urgent need for a retrieval method that can distinguish between production code and test cases, accurately assess behavioral relevance by combining text and function call structure similarity, and introduce an iterative feedback mechanism from the generation stage to the retrieval stage. Summary of the Invention
[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing an iterative context retrieval method, device, and medium for defect reproduction testing.
[0006] The objective of this invention is achieved through the following technical solution: In a first aspect, the present invention provides an iterative context retrieval method for defect reproduction testing, comprising the following steps: (1) Production code retrieval: Parse the defect description and extract the keyword set, and retrieve the production code related to the defect description based on the production code library; (2) Initial test code retrieval: Provide a set of calling tools for the large language model, conduct initial exploration of the project's test suite based on defect descriptions, and obtain a preliminary set of relevant test codes; (3) Generate test draft: merge the production code obtained in step (1) with the relevant test code of the current round into a context, input it into the test generator based on the large language model, and generate the defect reproduction test draft of the current round; (4) Similarity calculation: Extract the features of each existing test case in the defect reproduction test draft generated in step (3) and the test suite, and calculate the text similarity and function call similarity between them respectively; (5) Candidate test code reordering: Select the top k test cases based on the two similarities calculated in step (4), and combine them with the test cases selected in the previous iteration round. Input them into the large language model for reordering and output the updated set of related test codes. (6) Iteration termination determination: Repeat steps (3) to (5) until the preset maximum number of iterations is reached, and take the last output of the candidate test code set as the final relevant test code; (7) Generate a high-quality context: merge the relevant production code output in step (1) with the final relevant test code output in step (6) to generate a high-quality context for generating defect reproduction tests.
[0007] Furthermore, step (1) specifically includes: The large language model is used to extract potential code-related entities from the defect description, which is the keyword set. These entities include function names, class names, and module names. The codebase is parsed into a hierarchical structure tree consisting of files, classes, and methods. An initial set of candidate nodes is obtained by matching the set of keywords with the node names in the hierarchical structure tree. Heuristic rules are used to score and filter the initial set of candidate nodes to determine the final relevant production code.
[0008] Furthermore, the heuristic rules for scoring and filtering the initial candidate node set specifically include the following evaluation dimensions: evaluating node uniqueness (keywords with fewer matching nodes are more specific, and their corresponding candidate nodes are given higher priority); evaluating file co-occurrence relationships (if the same code file contains candidate nodes matched by multiple different keywords, the candidate nodes in that file are considered to have higher relevance); and evaluating structural relevance (if multiple candidate nodes share the same parent node in the hierarchical structure tree, these candidate nodes are considered to have higher relevance).
[0009] Furthermore, in step (2), the set of calling tools includes tools for listing directory structures, tools for identifying test functions within files, and tools for reading the production code of specific functions.
[0010] Furthermore, in step (3), the relevant test code specifically refers to: in the first iteration, the set of test codes initially related to the defect description obtained in step (2); and in subsequent iterations, the updated set of relevant test codes output in step (5).
[0011] Further, in step (4), the text similarity is calculated as follows: the function name similarity and code text similarity between the defect reproduction test draft and the existing test cases are calculated using the BM25 algorithm, and the two are added together to obtain the final text similarity.
[0012] Furthermore, in step (4), the calculation of the function call similarity specifically includes: Construct the pruned function call tree for the defect reproduction test draft respectively. Pruned function call tree compared to existing test cases The expansion stops when the call path enters the module to which the production code belongs; For each function node in the pruned function call tree Calculate weights Its calculation expression is as follows: in, The set of keywords extracted in step (1), This represents the inverse document frequency of non-keyword functions in the test suite. The highest inverse document frequency, The basic weight parameters are set; Based on the above weights Calculate the test draft call tree Compared with the existing test case call tree Weighted tree edit distance between ; Based on the weighted tree edit distance Calculate function call similarity The expression is as follows: in, and Representing the call tree and The sum of the weights of all nodes in the equation.
[0013] Further, in step (6), the loop convergence determination is as follows: if the maximum number of iterations has not been reached, then feedback is sent to S3 to start a new round of generation; if the maximum number of iterations has been reached, then the loop execution is terminated in S7, and the test set output at the last time is used as the final relevant test code.
[0014] In a second aspect, the present invention provides an electronic device, including a memory and a processor, wherein the memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the above-described iterative context retrieval method for generating defect reproduction tests.
[0015] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, characterized in that, when the program is executed by a processor, it implements the iterative context retrieval method for generating defect reproduction tests.
[0016] Compared with the prior art, the beneficial effects of the present invention are specifically reflected in the following aspects: 1. This invention achieves differentiated and precise retrieval of production code and test code: By distinguishing the different needs of production code and existing tests, it breaks through the limitations of the single retrieval strategy of existing methods, provides a more complete and high-quality code context for large language models, and significantly improves the completeness and relevance of input information; 2. This invention deeply captures the behavioral correlations between test codes. By constructing a pruned function call tree and calculating the weighted tree edit distance, this invention effectively overcomes the lack of semantic understanding in traditional text matching algorithms and can accurately identify test cases that are logically related at the code structure level but differ greatly in text. 3. This invention transforms the retrieval process from the traditional static one-way to a dynamic iteration, using the test drafts generated by the generator as feedback signals for the next round of similarity retrieval, so that the retrieval focus can gradually approach the optimal and most core test cases. 4. The present invention provides a more concise and efficient context for large language models, which not only significantly improves the success rate of automated defect reproduction test generation, but also significantly reduces the inference cost of API calls. In addition, the method has good versatility and can be integrated into automated defect reproduction test generation tools as a plug-and-play module. Attached Figure Description
[0017] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation
[0018] 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, and 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.
[0019] It should be noted that, unless otherwise specified, the features in the following embodiments and implementation methods can be combined with each other.
[0020] In a first aspect, the present invention provides an iterative context retrieval method for defect reproduction testing generation, the flowchart of which is shown below. Figure 1 This includes the following steps: S1, Production Code Retrieval: This step aims to parse the defect description from the natural language description and extract the keyword set, and retrieve the production code related to the defect description based on the structured production code library.
[0021] S1.1: Extract the keyword set First, prompt words are constructed. A large language model is used to extract potential code-related entities from the defect description in natural language. These entities include function names, class names, and module names. The extracted entities are then used to form a keyword set. For example, the large language model might extract keywords such as "ExpressionWrapper," "Q," "annotate," and "values" from the defect description. To improve the robustness of the extraction, the large language model infers the complete path of the entities, for example, by supplementing the keywords in the description with "Queryset.annotate."
[0022] S1.2: Obtain the initial set of candidate nodes The target project's codebase is parsed into a hierarchical structure tree consisting of files, classes, and methods. An initial set of candidate nodes is obtained by matching extracted keywords with the node names in this structure tree. If no match is found based on the full path, the last name of the entity is used for backup searching.
[0023] S1.3: Determining relevant production code based on heuristic rules Frequently used keywords (such as "values") may appear in multiple different locations in the codebase, leading to a large number of irrelevant candidate nodes and causing matching ambiguity, thus reducing retrieval accuracy. This step uses heuristic rules to score and filter the initial candidate node set to determine the final relevant production code. The heuristic rules comprehensively evaluate the following three dimensions for scoring and filtering: First, assess node uniqueness: count the number of nodes matched for each keyword. Keywords with fewer matching nodes are more specific, and their corresponding candidate nodes will be given higher priority. For example, the keyword "Queryset.annotate" only matches one independent node in the codebase, so it is considered a high-confidence match result. Second, evaluate file co-occurrence relationships: check if the same code file contains multiple candidate nodes matched by different keywords; if the same code file contains candidate nodes matched by multiple different keywords, then the candidate nodes in the file are considered to have higher relevance; for example, if the first candidate node for the keyword "values" and the matching node for the keyword "annotate" are both located in the same code file (such as query.py), it suggests that they have higher relevance. Third, assess structural relevance: check whether multiple candidate nodes share the same parent node in the hierarchical structure tree. If they have the same parent node (e.g., they both belong to the same class), then these candidate nodes are considered to have higher relevance. For example, the first candidate node for the keyword "values" and the matching node for "annotate" have the same parent node "Queryset", which indicates that there is a strong structural relevance between them.
[0024] S2, Initial Test Code Retrieval: The system provides a set of calling tools for large language models, and conducts an initial exploration of the project's test suite based on defect descriptions to obtain a preliminary set of relevant test code.
[0025] Specifically, the system configures a set of executable utility functions for the large language model, providing a set of invocation tools. These tools include: tools for listing directory structures, tools for identifying test functions within files, and tools for reading the generated code of specific functions. The large language model, acting as an intelligent agent, utilizes this set of invocation tools to perform exploratory searches within the test suite, selecting a set of test code initially relevant to the defect description.
[0026] S3, Generate test draft: The relevant production code obtained in step S1 is merged with the relevant test code of the current round into a context, which is then input into the test generator based on a large language model to generate a defect reproduction test draft for the current round.
[0027] In the first iteration, the "relevant test code" specifically refers to the set of test codes initially related to the defect description obtained in step S2. In subsequent iterations, the "relevant test code" refers to the final sorted and updated set of test codes output after reordering in step S5 of the previous iteration. The test generator generates a defect reproduction test draft based on the merged context; this draft provides feedback information on text content and function call structure to guide the next round of test code retrieval.
[0028] S4, Similarity Calculation: Extract the features of the defect reproduction test draft obtained in step S3 and each existing test case in the test suite, and calculate the text similarity and function call similarity between the two respectively.
[0029] S4.1: Calculation of total text similarity The total text similarity is calculated as follows: the BM25 algorithm is used to calculate the function name similarity and code text body similarity between the test draft and the existing test cases, and the two are added together to obtain the total text similarity.
[0030] S4.2: Function Call Similarity Calculation The calculation process for function call similarity is as follows: First, construct the pruned function call tree for the defect reproduction test drafts. Pruned function call tree compared to existing test cases In order to filter out interference from irrelevant low-level implementation details, the downward expansion stops when the call path enters the module to which the production code belongs.
[0031] Secondly, considering that different functions have different levels of importance in expressing the test intent, each function node in the pruned function call tree is... Calculate weights The weights The calculation expression is as follows: in, This refers to the set of keywords extracted in step S1.1; for other ordinary functions, This represents the inverse document frequency of non-keyword functions in the test suite. The highest inverse document frequency; These are the basic weight parameters that are set.
[0032] If function node If a keyword belongs to the aforementioned keyword set, it is assigned a weight. The value is 1.0; preferably, the basic weight parameter is... It is set to 0.1 to ensure that highly specific functions dominate the similarity calculation.
[0033] Next, based on the above weights The Zhang-Shasha algorithm is used to calculate the pruned function call tree of the defect reproduction test draft. Pruned function call tree compared to existing test cases Weighted tree edit distance between .
[0034] Finally, the weighted tree edit distance is calculated according to the following formula. Normalized to function call similarity: in, and Representing the call tree and The sum of the weights of all nodes in the equation; the closer this value is to 1, the more similar the behavioral logic of the two is.
[0035] S5, candidate test code rearrangement: Select the top k test cases with the highest total text similarity and function call similarity calculated in step S4, and combine them with the test cases selected in the previous iteration round, and input them into the large language model for reordering.
[0036] Specifically, the system summarizes the top k test cases based on text similarity scores and the top k test cases based on function call similarity scores, along with the test cases selected in the previous iteration, as candidate code structures. The large language model comprehensively analyzes the natural language defect descriptions and the aforementioned candidate code structures, outputting an updated set of relevant test codes. Preferably, after reordering, the number of relevant test cases output is strictly limited to no more than 5.
[0037] S6, Cycle convergence determination: To determine whether the current iteration count has reached the preset maximum iteration count, the system uses the defect reproduction test draft generated in step S3 as feedback and continuously executes steps S3 to S5. If the maximum iteration count has not been reached, feedback is sent to S3 to start a new round of generation; if the maximum iteration count has been reached, the loop is terminated and S7 is executed, and the last output test set is used as the final relevant test code.
[0038] Preferably, the maximum number of iterations is set to 3, which balances maximizing retrieval accuracy with reasonable control of computing resources.
[0039] Through the closed-loop mechanism of generation, retrieval, and rearrangement described above, the optimal context is gradually approached.
[0040] S7, generating high-quality context By merging the relevant production code obtained in step S1 with the final relevant test code, a high-quality context can be generated for generating defect reproduction tests.
[0041] Specifically, the system assembles the extracted core-related production code with the most core test cases refined through multiple rounds of iterations, and finally delivers this context to the large language model to drive it to complete the task of generating automated defect reproduction tests.
[0042] like Figure 2 As shown, this application provides an electronic device including a memory 101 for storing one or more programs and a processor 102. When the one or more programs are executed by the processor 102, they implement the method as described in any of the first aspects above.
[0043] The system also includes a communication interface 103. The memory 101, processor 102, and communication interface 103 are electrically connected directly or indirectly to each other to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The memory 101 can be used to store software programs and modules, and the processor 102 executes various functional applications and data processing by executing the software programs and modules stored in the memory 101. The communication interface 103 can be used for signaling or data communication with other node devices.
[0044] The memory 101 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.
[0045] The processor 102 can be an integrated circuit chip with signal processing capabilities. The processor 102 can be a general-purpose processor 102, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0046] In the embodiments provided in this application, it should be understood that the disclosed methods and systems can also be implemented in other ways. The method and system embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0047] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0048] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program thereon. When executed by processor 102, the computer program implements the methods described in any of the first aspects above. If the functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0049] Example: To verify the effectiveness and advancement of the iterative context retrieval method for defect reproduction test generation described in this invention under real-world defect scenarios, this embodiment performs an end-to-end evaluation based on two benchmark datasets: SWT-bench Lite and TDD-bench Verified. These datasets compile real-world software defects collected from multiple mature open-source projects and provide a natural language description of each defect, the code versions before and after the fix, and real-world defect reproduction test cases as benchmarks.
[0050] To evaluate the impact of retrieval methods on automated test generation, this invention combines different retrieval methods with the same basic test generator based on a large language model (GPT-4o) for end-to-end testing, in order to quantify the impact of different retrieval strategies on the quality of the final automated defect reproduction test generation.
[0051] This invention selects the traditional BM25 algorithm and existing retrieval methods based on large language models, including the AEGIS retrieval engine, the AssertFlip retrieval engine, and the Otter retrieval engine, as comparative baselines. BM25 is a traditional text retrieval method based on word frequency matching; the AEGIS retrieval engine is a framework based on intelligent agents, employing a search agent with tool-invoking capabilities to explore the codebase; the AssertFlip retrieval engine uses a hierarchical retrieval method, but focuses only on retrieving production code and ignores test case retrieval; the Otter retrieval engine also uses a hierarchical retrieval method, but it separates the retrieval of production code and test code into two independent stages. The evaluation results of different retrieval methods based on the same underlying generator on the defect reproduction task are shown in Table 1 below: Table 1: Evaluation results of different retrieval methods based on the same basic generator on the defect reproduction task. The Fail-to-Pass (F→P(@K)) metric represents the percentage of defects that fail on the defective version but pass on the patched version, out of the top K generated test cases.
[0052] Experimental results show that, on two independent benchmark datasets, the retrieval method proposed in this invention significantly outperforms all baseline methods in all F→P(@K) metrics. Specifically, if the model only outputs the first recommended defect reproduction test (F→P(@1)), the method of this invention achieves success rates of 42.0% and 52.8% on SWT-bench Lite and TDD-bench Verified, respectively. Compared with the current second-best performing baseline (i.e., Otter's retrieval device), the method of this invention helps the model achieve relative performance improvements of 31.7% (SWT-bench Lite) and 19.7% (TDD-bench Verified) in the F→P(@1) metric, respectively.
[0053] Furthermore, in terms of system overhead and computational efficiency, the context length statistics further demonstrate that the average context length output by the method of this invention remains between 2468 and 2603 tokens. This length is not only significantly shorter than the traditional BM25 algorithm (over 20,000 tokens), but also significantly reduced compared to the AssertFlip retriever (4324 tokens) and the AEGIS retriever (3766 tokens). Particularly on the TDD-bench Verified dataset, the context length of the method of this invention is further reduced by 12.6% compared to the Otter retriever.
[0054] In summary, the experimental data fully validates the effectiveness of this invention. The retrieval method proposed in this invention, which distinguishes code types, combines function call structures, and introduces iterative feedback generation, can not only provide the most accurate defect reproduction context for large language models to significantly improve accuracy, but also effectively reduce redundant code, thereby reducing the API inference cost and computing power consumption of large language models.
[0055] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only.
[0056] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.
Claims
1. An iterative context retrieval method for defect reproduction testing generation, characterized in that, Includes the following steps: (1) Production code retrieval: Parse the defect description and extract the keyword set, and retrieve the production code related to the defect description based on the production code library; (2) Initial test code retrieval: Provide a set of calling tools for the large language model, conduct initial exploration of the project's test suite based on defect descriptions, and obtain a preliminary set of relevant test codes; (3) Generate test draft: merge the production code obtained in step (1) with the relevant test code of the current round into a context, input it into the test generator based on the large language model, and generate the defect reproduction test draft of the current round; (4) Similarity calculation: Extract the features of each existing test case in the defect reproduction test draft generated in step (3) and the test suite, and calculate the text similarity and function call similarity between them respectively; (5) Candidate test code reordering: Select the top k test cases based on the two similarities calculated in step (4), and combine them with the test cases selected in the previous iteration round. Input them into the large language model for reordering and output the updated set of related test codes. (6) Iteration termination determination: Repeat steps (3) to (5) until the preset maximum number of iterations is reached, and take the last output of the candidate test code set as the final relevant test code; (7) Generate a high-quality context: merge the relevant production code output in step (1) with the final relevant test code output in step (6) to generate a high-quality context for generating defect reproduction tests.
2. The iterative context retrieval method for defect reproduction testing generation according to claim 1, characterized in that, The specific steps in step (1) are as follows: The large language model is used to extract potential code-related entities from the defect description, which is the keyword set. These entities include function names, class names, and module names. The codebase is parsed into a hierarchical structure tree consisting of files, classes, and methods. An initial set of candidate nodes is obtained by matching the set of keywords with the node names in the hierarchical structure tree. Heuristic rules are used to score and filter the initial set of candidate nodes to determine the final relevant production code.
3. The iterative context retrieval method for defect reproduction testing generation according to claim 2, characterized in that, The heuristic rules for scoring and filtering the initial candidate node set specifically include the following evaluation dimensions: evaluating node uniqueness (keywords with fewer matching nodes are more specific, and their corresponding candidate nodes are given higher priority); evaluating file co-occurrence relationships (if a code file contains candidate nodes matched by multiple different keywords, the candidate nodes in that file are considered to have higher relevance); and evaluating structural correlation (if multiple candidate nodes share the same parent node in the hierarchical structure tree, these candidate nodes are considered to have higher relevance).
4. The iterative context retrieval method for defect reproduction testing generation according to claim 1, characterized in that, In step (2), the set of calling tools includes tools for listing directory structures, tools for identifying test functions within files, and tools for reading the production code of specific functions.
5. The iterative context retrieval method for defect reproduction testing generation according to claim 1, characterized in that, In step (3), the relevant test code is specifically: in the first iteration, it is the set of test codes initially related to the defect description obtained in step (2); in subsequent iterations, it is the updated set of relevant test codes output in step (5).
6. The iterative context retrieval method for defect reproduction testing generation according to claim 1, characterized in that, In step (4), the text similarity is calculated as follows: the function name similarity and code text similarity between the defect reproduction test draft and the existing test cases are calculated using the BM25 algorithm, and the two are added together to obtain the final text similarity.
7. The iterative context retrieval method for defect reproduction testing generation according to claim 1, characterized in that, In step (4), the calculation of the function call similarity specifically includes: Construct the pruned function call tree for the defect reproduction test draft respectively. Pruned function call tree compared to existing test cases The expansion stops when the call path enters the module to which the production code belongs; For each function node in the pruned function call tree Calculate weights Its calculation expression is as follows: in, The set of keywords extracted in step (1), This represents the inverse document frequency of non-keyword functions in the test suite. The highest inverse document frequency, The basic weight parameters are set; Based on the above weights Calculate the test draft call tree Compared with the existing test case call tree Weighted tree edit distance between ; Based on the weighted tree edit distance Calculate function call similarity The expression is as follows: in, and Representing the call tree and The sum of the weights of all nodes in the equation.
8. The iterative context retrieval method for defect reproduction testing generation according to claim 1, characterized in that, In step (6), the loop convergence determination is as follows: if the maximum number of iterations has not been reached, the loop is fed back to S3 to start a new round of generation; if the maximum number of iterations has been reached, the loop is terminated and S7 is executed, and the last output test set is used as the final relevant test code.
9. An electronic device comprising a memory and a processor, characterized in that, The memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the iterative context retrieval method for defect reproduction test generation as described in any one of claims 1-8.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the iterative context retrieval method for generating defect reproduction tests as described in any one of claims 1-8.