A test case generation method and device in a software development process

Abstract

The application relates to a test case generation method and device in a software development process, and belongs to the technical field of data processing, wherein the method comprises the following steps: acquiring multiple versions of requirement documents, and preprocessing and vectorizing the multiple versions of requirement documents to obtain a requirement document vector set; vectorizing a target function list to obtain a target function vector, determining a first preset number of requirement document vectors with the highest cosine similarity with the target function vector as a candidate vector set; correcting the cosine similarity between each candidate vector and the target function vector based on a dynamic weight decay factor of each candidate vector; determining a reserved vector set, and removing the requirement documents corresponding to the candidate vectors except the reserved vector set, updating the multiple versions of requirement documents; and generating test cases based on the updated multiple versions of requirement documents. The application can realize efficient and accurate generation of test cases.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and apparatus for generating test cases in the software development process. Background Technology

[0002] As the pace of software product development and iteration continues to accelerate, the frequency of changes to requirement documents, which serve as the core basis for product function definition, development implementation, and testing verification, has also increased significantly. In the integrated process of Agile development and DevOps, core functional modules of the product (such as user management modules, transaction settlement modules, etc.) often need to undergo multiple rounds of requirement iterations, forming a complete change chain from the initial version (R1) to iterative versions (R2, R3...Rn). Each iteration may involve adjustments and optimizations to details such as functional logic, field rules, and constraints.

[0003] In the implementation phase of automated testing, especially when using Large Language Model (LLM) combined with Retrieval-Augmented Generation (RAG) technology to automate test case generation and perform full-system smoke testing, the system needs to accurately retrieve core information such as business rules and functional definitions related to the test scenario from the historical requirements document library to provide reliable business basis for automated testing tasks. However, traditional RAG systems typically treat different versions of requirements documents as independent and unrelated text fragments when processing multiple versions, resulting in shortcomings in testing efficiency and accuracy.

[0004] Therefore, improving the efficiency and accuracy of test case generation during automated testing has become a pressing technical problem that needs to be solved. Summary of the Invention

[0005] In view of this, it is necessary to provide a test case generation method and apparatus in the software development process to solve the problem of low efficiency and accuracy of test case generation in existing solutions during automated testing.

[0006] To address the aforementioned problems, in a first aspect, the present invention provides a method for generating test cases during software development, comprising: Obtain multiple versions of requirement documents, and preprocess and vectorize them to obtain a set of requirement document vectors. Each requirement document includes the module identifier, version number, release timestamp, change type, requirement status, and the plan to which the requirement belongs. Obtain the target function list and vectorize it to obtain the target function vector. Determine the cosine similarity between each requirement document vector in the requirement document vector set and the target function vector. Then, determine the first preset number of requirement document vectors with the highest cosine similarity to the target function vector as the candidate vector set. Based on the release timestamp, change type, requirement status, and the plan to which the requirement belongs, the dynamic weight decay factor of each candidate vector in the candidate vector set is determined. Based on the dynamic weight decay factor of each candidate vector, the cosine similarity between each candidate vector and the target function vector is corrected to determine the similarity score of each candidate vector. The candidate vectors with the highest similarity scores among the second preset number of candidate vectors corresponding to the same module identifier are selected as the retained vector set. The requirement documents corresponding to the candidate vectors with the highest similarity scores among the second preset number of candidate vectors are removed except for the retained vector set. The requirement documents of multiple versions are updated. Test cases are generated based on multiple updated versions of the requirements document.

[0007] In one possible implementation, the preprocessing and vectorization of multiple versions of the requirements documents to obtain a set of requirements document vectors includes: For multiple versions of the requirements document, the format should be standardized, invalid content should be removed, and semantic blocks should be formed sequentially. Based on the semantic hash value, module identifier, version number, release timestamp, change type, requirement status, and the plan to which the requirement belongs after semantic segmentation of multiple versions of the requirement document, a set of requirement document vectors is obtained.

[0008] In one possible implementation, the change type includes addition, modification, and deletion, which are determined based on the corresponding content in two adjacent requirement documents for the same requirement.

[0009] In one possible implementation, determining the dynamic weight decay factor for each candidate vector based on its release timestamp, change type, demand status, and the plan to which the demand belongs in the candidate vector set includes: The time decay factor for each candidate vector is determined based on the release timestamp, demand status, and the plan to which the demand belongs. The change status correction factor for each candidate vector is determined based on the change type corresponding to each candidate vector. Based on the code implementation, submission implementation, and schema change implementation of each candidate vector, determine the multimodal confidence factor for each candidate vector; The dynamic weight decay factor of each candidate vector is determined based on the time decay factor, change state correction factor, and multimodal confidence factor of each candidate vector.

[0010] In one possible implementation, determining the time decay factor for each candidate vector based on the release timestamp, demand status, and the plan to which the demand belongs includes: The base time difference for each candidate vector is determined based on the difference between the release timestamp and the current time. The intergenerational decay coefficient for each candidate vector is determined based on the base time difference of each candidate vector and the duration of the plan to which the demand belongs. The sensitivity coefficient of each candidate vector is determined based on the demand state corresponding to each candidate vector. Based on the intergenerational decay coefficient, sensitivity coefficient, and basic time difference of each candidate vector, and the preset iteration period, the time decay factor of each candidate vector is determined.

[0011] In one possible implementation, determining the change state correction factor for each candidate vector based on the change type corresponding to each candidate vector includes: Based on the change type corresponding to each candidate vector, determine the number of changes, change frequency threshold, and change type correction coefficient for the requirements corresponding to each candidate vector; The change status correction factor for each candidate vector is determined based on the number of changes to the requirements corresponding to each candidate vector, the change frequency threshold, and the change type correction coefficient.

[0012] In one possible implementation, determining the multimodal confidence factor for each candidate vector based on its code implementation, commit implementation, and schema change implementation includes: The code implementation deterministic score, submission implementation deterministic score, and schema change deterministic score for each candidate vector are determined based on the code implementation status, submission implementation status, and schema change implementation status of each candidate vector. Based on the code implementation deterministic score, submission implementation deterministic score, and schema change deterministic score for each candidate vector, as well as the preset discrimination weight, the multimodal confidence factor for each candidate vector is determined.

[0013] In one possible implementation, the generation of test cases based on multiple updated versions of the requirements document includes: The RAG search library is updated based on multiple updated versions of the requirements documents, and test cases are generated based on the RAG search library.

[0014] On the other hand, the present invention also provides a test case generation device in the software development process, comprising: The first acquisition module is used to acquire multiple versions of requirement documents, and preprocess and vectorize the multiple versions of requirement documents to obtain a set of requirement document vectors. The requirement documents include the module identifier, version number, release timestamp, change type, requirement status and the plan to which the requirement belongs. The second acquisition module is used to acquire the target function list and vectorize the target function list to obtain the target function vector, determine the cosine similarity between each requirement document vector in the requirement document vector set and the target function vector, and determine the first preset number of requirement document vectors with the highest cosine similarity to the target function vector as the candidate vector set. The first determining module is used to determine the dynamic weight decay factor of each candidate vector based on the release timestamp, change type, demand status and the plan to which the demand belongs in the candidate vector set, and to correct the cosine similarity between each candidate vector and the target function vector based on the dynamic weight decay factor of each candidate vector, and to determine the similarity score of each candidate vector. The second determining module is used to determine the candidate vector with the highest similarity score among the second preset number of candidate vectors with the highest similarity score that corresponds to the same module identifier as the retained vector set, and to remove the requirement documents corresponding to the candidate vectors other than the retained vector set among the second preset number of candidate vectors with the highest similarity score, and to update the requirement documents of multiple versions. The generation module is used to generate test cases based on multiple updated versions of the requirements document.

[0015] Secondly, the present invention also provides a test case generation device, including a data collector, a memory, and a processor, wherein, The data collector is used to acquire multiple versions of the requirements document and the list of target functions; The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the test case generation method in the software development process described in any of the above implementations.

[0016] The beneficial effects of this invention are as follows: The test case generation method and apparatus in the software development process provided by this invention first preprocesses and vectorizes multiple versions of requirement documents to obtain a set of requirement document vectors, improving the efficiency of subsequent data and thus improving the efficiency of test case generation. Then, the target function list is vectorized to obtain target function vectors. A first preset number of requirement document vectors with the highest cosine similarity to the target function vectors are determined as a candidate vector set, thereby filtering out requirement document vectors with strong relevance to the target function list. Next, the dynamic weight decay factor of each candidate vector is determined by the release timestamp, change type, requirement status, and requirement plan corresponding to each candidate vector in the candidate vector set to correct the cosine similarity between each candidate vector and the target function vector, determining the similarity score of each candidate vector. Then, a second preset number of candidate vectors with the highest similarity scores are determined. The candidate vectors with the highest similarity scores corresponding to the same module identifier are selected as the retained vector set, and the requirement documents corresponding to other candidate vectors are removed. Multiple versions of requirement documents are updated to avoid the old versions of requirement documents affecting the accuracy of test case generation, thereby improving the accuracy of test case generation. Finally, test cases are generated based on the updated multiple versions of requirement documents, achieving efficient and accurate test case generation. Attached Figure Description

[0017] Figure 1 A schematic flowchart of an embodiment of the test case generation method in the software development process provided by the present invention; Figure 2 This is a schematic flowchart of an embodiment of the test case generation process provided by the present invention; Figure 3 A schematic diagram of an embodiment of the test case generation device in the software development process provided by the present invention; Figure 4 This is a schematic diagram of an embodiment of the test case generation 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 a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0019] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0020] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] This invention provides a method and apparatus for generating test cases in the software development process, which will be described below.

[0023] Figure 1 This is a schematic flowchart of an embodiment of the test case generation method in the software development process provided by the present invention, as shown below. Figure 1 As shown, the methods for generating test cases in the software development process include: S101. Obtain multiple versions of requirement documents, and preprocess and vectorize them to obtain a set of requirement document vectors. The requirement documents include the module identifier, version number, release timestamp, change type, requirement status, and the plan to which the requirement belongs.

[0024] It should be noted that the test case generation method in the software development process provided by this invention can be applied to test case generation scenarios in the software development process, especially test case generation scenarios in the integrated process of agile development and DevOps.

[0025] When generating test cases, the test case generation device (such as a desktop or portable computer) first obtains multiple versions of requirement documents from the software development process. These requirement documents may include the module identifier, version number, release timestamp, change type, requirement status, and the plan to which the requirement belongs. Then, the multiple versions of requirement documents are preprocessed and vectorized to obtain a set of requirement document vectors. Preprocessing and vectorization improve the efficiency of subsequent data processing, thereby increasing the efficiency of test case generation.

[0026] S102. Obtain the target function list and vectorize the target function list to obtain the target function vector. Determine the cosine similarity between each requirement document vector in the requirement document vector set and the target function vector. Then, determine the first preset number of requirement document vectors with the highest cosine similarity to the target function vector as the candidate vector set.

[0027] It should be noted that: Next, the test case generation device can obtain the target function list and vectorize it to obtain the target function vector. Then, it calculates and determines the cosine similarity between each requirement document vector in the requirement document vector set and the target function vector. The requirement document vectors with the highest cosine similarity to the target function vector are determined as the first preset number (e.g., 10) of requirement document vectors as the candidate vector set, thereby filtering out the requirement document vectors that are highly relevant to the target function list.

[0028] S103. Based on the release timestamp, change type, requirement status, and the plan to which the requirement belongs, determine the dynamic weight decay factor of each candidate vector in the candidate vector set, and correct the cosine similarity between each candidate vector and the target function vector based on the dynamic weight decay factor of each candidate vector, and determine the similarity score of each candidate vector.

[0029] It should be noted that after determining the candidate vector set, in order to further improve the accuracy of subsequent test case generation, a dynamic weight decay factor can be determined for each candidate vector based on the release timestamp, change type, requirement status, and the plan to which the requirement belongs. Then, the cosine similarity between each candidate vector and the target function vector is corrected by the dynamic weight decay factor of each candidate vector, and the similarity score of each candidate vector is determined.

[0030] S104. Determine the candidate vectors with the highest similarity scores among the second preset number of candidate vectors that correspond to the same module identifier as the retained vector set, and remove the requirement documents corresponding to the candidate vectors other than the retained vector set from the second preset number of candidate vectors with the highest similarity scores, and update the requirement documents of multiple versions.

[0031] It should be noted that after determining the similarity score of each candidate vector, a second preset number (e.g., 5) of candidate vectors with the highest similarity scores can be determined first. Then, the candidate vectors with the highest similarity scores corresponding to the same module identifier are selected as the retained vector set, and the requirement documents corresponding to other candidate vectors are removed. Multiple versions of the requirement documents are updated to avoid the old version of the requirement documents affecting the accuracy of test case generation and improve the accuracy of test case generation.

[0032] S105. Generate test cases based on updated versions of the requirements documents.

[0033] It should be noted that: Finally, test cases can be generated based on multiple updated versions of the requirements document, achieving efficient and accurate test case generation.

[0034] In summary, the test case generation method in the software development process provided by this invention first preprocesses and vectorizes multiple versions of requirement documents to obtain a requirement document vector set, improving the efficiency of subsequent data processing and thus improving the efficiency of test case generation. Then, the target function list is vectorized to obtain target function vectors. A first preset number of requirement document vectors with the highest cosine similarity to the target function vectors are determined as a candidate vector set, thereby filtering out requirement document vectors with strong relevance to the target function list. Next, a dynamic weight decay factor is determined for each candidate vector in the candidate vector set based on the release timestamp, change type, requirement status, and the plan to which the requirement belongs. This factor corrects the cosine similarity between each candidate vector and the target function vector, determining the similarity score for each candidate vector. A second preset number of candidate vectors with the highest similarity scores are then determined. The candidate vectors with the highest similarity scores corresponding to the same module identifier are selected as the retained vector set, and the requirement documents corresponding to other candidate vectors are removed. Multiple versions of requirement documents are updated to avoid the impact of older versions on the accuracy of test case generation, thus improving the accuracy of test case generation. Finally, test cases are generated based on the updated multiple versions of requirement documents, achieving efficient and accurate test case generation.

[0035] In some embodiments of the present invention, the preprocessing and vectorization of multiple versions of requirement documents to obtain a set of requirement document vectors includes: For multiple versions of the requirements document, the format should be standardized, invalid content should be removed, and semantic blocks should be formed sequentially. Based on the semantic hash value, module identifier, version number, release timestamp, change type, requirement status, and the plan to which the requirement belongs after semantic segmentation of multiple versions of the requirement document, a set of requirement document vectors is obtained.

[0036] It should be noted that when preprocessing and vectorizing multiple versions of requirement documents to obtain a set of requirement document vectors, the requirement documents of multiple versions can be formatted, invalid content removed, and semantically segmented in sequence. Then, the requirement documents of multiple versions after semantic segmentation can be vectorized according to their semantic hash values, module identifiers, version numbers, release timestamps, change types, requirement status, and the plan to which the requirement belongs, to obtain a set of requirement document vectors.

[0037] In some embodiments of the present invention, the change type includes addition, modification, and deletion, which are determined based on the corresponding content in two adjacent requirement documents for the same requirement.

[0038] It should be noted that the change types of the requirements document specifically include addition, modification, and deletion, which can be determined based on the corresponding content of the same requirement in two adjacent versions of the requirements document.

[0039] In some embodiments of the present invention, determining the dynamic weight decay factor for each candidate vector based on the release timestamp, change type, demand status, and the plan to which the demand belongs in the candidate vector set includes: The time decay factor for each candidate vector is determined based on the release timestamp, demand status, and the plan to which the demand belongs. The change status correction factor for each candidate vector is determined based on the change type corresponding to each candidate vector. Based on the code implementation, submission implementation, and schema change implementation of each candidate vector, determine the multimodal confidence factor for each candidate vector; The dynamic weight decay factor of each candidate vector is determined based on the time decay factor, change state correction factor, and multimodal confidence factor of each candidate vector.

[0040] It should be noted that when determining the dynamic weight decay factor of each candidate vector based on its release timestamp, change type, requirement status, and the plan to which the requirement belongs, the following methods can be used: First, determine the time decay factor based on the release timestamp, requirement status, and the plan to which the requirement belongs. Second, determine the change status correction factor based on the change type. Third, determine the multimodal confidence factor based on the code implementation, commit implementation, and schema change implementation of each candidate vector. Finally, determine the dynamic weight decay factor based on the time decay factor, change status correction factor, and multimodal confidence factor. For example, the dynamic weight decay factor can be determined by multiplying the time decay factor, change status correction factor, and multimodal confidence factor.

[0041] In some embodiments of the present invention, determining the time decay factor for each candidate vector based on the release timestamp, demand status, and the plan to which the demand belongs includes: The base time difference for each candidate vector is determined based on the difference between the release timestamp and the current time. The intergenerational decay coefficient for each candidate vector is determined based on the base time difference of each candidate vector and the duration of the plan to which the demand belongs. The sensitivity coefficient of each candidate vector is determined based on the demand state corresponding to each candidate vector. Based on the intergenerational decay coefficient, sensitivity coefficient, and basic time difference of each candidate vector, and the preset iteration period, the time decay factor of each candidate vector is determined.

[0042] It should be noted that when determining the time decay factor of each candidate vector based on its release timestamp, demand status, and the plan to which the demand belongs, the basic time difference of each candidate vector can be determined first by the difference between its release timestamp and the current time. Then, the generational decay coefficient of each candidate vector can be determined based on its basic time difference and the duration of the plan to which the demand belongs. Next, the sensitivity coefficient of each candidate vector can be determined based on its demand status. Finally, the time decay factor of each candidate vector can be determined based on its generational decay coefficient, sensitivity coefficient, basic time difference, and preset iteration period.

[0043] In some embodiments of the present invention, determining the change state correction factor for each candidate vector based on the change type corresponding to each candidate vector includes: Based on the change type corresponding to each candidate vector, determine the number of changes, change frequency threshold, and change type correction coefficient for the requirements corresponding to each candidate vector; The change status correction factor for each candidate vector is determined based on the number of changes to the requirements corresponding to each candidate vector, the change frequency threshold, and the change type correction coefficient.

[0044] It should be noted that when determining the change status correction factor for each candidate vector based on the change type corresponding to each candidate vector, one can first determine the number of changes, change frequency threshold, and change type correction coefficient for the requirement corresponding to each candidate vector based on the change type corresponding to each candidate vector, and then determine the change status correction factor for each candidate vector based on the number of changes, change frequency threshold, and change type correction coefficient for the requirement corresponding to each candidate vector.

[0045] In some embodiments of the present invention, determining the multimodal confidence factor for each candidate vector based on its code implementation, commit implementation, and schema change implementation includes: The code implementation deterministic score, submission implementation deterministic score, and schema change deterministic score for each candidate vector are determined based on the code implementation status, submission implementation status, and schema change implementation status of each candidate vector. Based on the code implementation deterministic score, submission implementation deterministic score, and schema change deterministic score for each candidate vector, as well as the preset discrimination weight, the multimodal confidence factor for each candidate vector is determined.

[0046] It should be noted that when determining the multimodal confidence factor of each candidate vector based on its code implementation, submission implementation, and schema change implementation, one can first determine the code implementation deterministic score, submission implementation deterministic score, and schema change deterministic score of each candidate vector based on its code implementation, submission implementation, and schema change implementation. Then, based on the code implementation deterministic score, submission implementation deterministic score, and schema change deterministic score of each candidate vector, and the preset discrimination weight, the multimodal confidence factor of each candidate vector can be determined.

[0047] In some embodiments of the present invention, the generation of test cases based on updated versions of multiple requirements documents includes: The RAG search library is updated based on multiple updated versions of the requirements documents, and test cases are generated based on the RAG search library.

[0048] It should be noted that when generating test cases based on multiple updated versions of the requirements document, the RAG retrieval library can be updated according to the updated versions of the requirements document, and then test cases can be generated through the RAG retrieval interface using the large language model.

[0049] The following specific embodiment illustrates the detailed implementation process of the test case generation method provided by the present invention: In the test case generation scenario during software development, the test case generation device (e.g., a desktop computer) first obtains multiple versions of requirement documents from the development history archive data. These requirement documents are then preprocessed and vectorized to obtain a requirement document vector set, thereby reducing data complexity and improving the efficiency of test case generation. Next, a feature list provided by the user is obtained. Based on this feature list, a candidate vector set is selected for test case generation. By calculating the dynamic weight decay factor of each candidate vector within the set, older versions of requirement documents that might affect the test case generation results are eliminated. Multiple versions of requirement documents are then updated to improve the accuracy of test case generation. Finally, test cases are generated using the updated versions of requirement documents.

[0050] Combination Figure 2 The test case generation process specifically includes the following steps: 1. Data preprocessing and vectorization.

[0051] Chunking is performed on different versions of the requirements document (R1, R2, ..., Rn). For each text block, its metadata is extracted, including: the module ID (Module_ID), the version number (Version), and the release timestamp (...). ), Change type (Change_Type, such as add, modify, delete), Requirement status ( The text blocks are converted into vector embeddings. (This is related to the requirement and its associated plan.)

[0052] (1) Document preprocessing and standardization. Convert all versions of the requirements document into plain text with a structured hierarchy to avoid formatting issues that could lead to segmentation failures.

[0053] (1.1) Standardize the document format and convert it to Markdown.

[0054] (1.2) Clean up useless content, such as: delete headers, footers, table of contents, watermarks, revision marks; merge line breaks, extra spaces, and tabs.

[0055] (1.3) Retain structural tags, including: heading levels (level 1, level 2, level 3), lists, and paragraphs.

[0056] (2) Document Chunking. The document is divided into the smallest independent semantic blocks. Each block can be a complete requirement / functional point / rule point.

[0057] (2.1) Using the hierarchical semantic chunking method, the output is: R1_chunk_001, R1_chunk_002, ..., R2_chunk_001, R2_chunk_002.

[0058] (3) Generate a unique fixed ID for each block so that the same requirement point maintains the same ID in R1, R2, and R3 in order to determine the change. Rule: Block ID = Module ID + semantic hash value; Output: Chunk_ID = Module_ID + _ + hash (the core semantic content of the block); hash uses MinHash / SimHash (allowing slight text changes to still maintain the same ID).

[0059] (4) Automatic extraction of metadata.

[0060] (4.1) Extract the module ID (Module_ID). Rule: Level 1 heading = module. Assign a fixed number to each level 1 heading: M001, M002, M003... The module_ID is inherited from the heading to which the block belongs.

[0061] (4.2) Extract the version number. Obtain it directly from the file name / document name: R1: Version=1, R2: Version=2.

[0062] (4.3) Extract the publication timestamp ( Document attribute reading (creation / modification time).

[0063] (4.4) Generate embedding vectors for each block. Convert text blocks into embedding vectors for retrieval and comparison. Output: A floating-point array for each block, stored in a vector library.

[0064] (4.5) Extract Change Type (e.g., Add, Modify, Delete). Change type definition: Add: R2 has it, R1 does not; Modify: R2 and R1 have the same Chunk_ID, but different content; Delete: R1 has it, R2 does not. The specific change type can be determined by calculating the cosine similarity between the block vectors of the two versions. Cosine similarity ≥ 0.90: indicates basically the same semantics, no change; Cosine similarity between 0.70 and 0.90: indicates slight semantic modification, marked as modified; Cosine similarity < 0.70: indicates significantly different semantics, considered a new block.

[0065] 2. Execute the dynamic weight decay algorithm.

[0066] When the system receives the feature list uploaded by the user, it performs the following calculations: (1) Preliminary search: Use a vector database to retrieve the top-K candidate text blocks C = { that have the highest similarity to the content in the feature list. , ,..., } Where k is recommended to be ≥10, to balance effect and performance.

[0067] Basic similarity calculation: Calculates the similarity between the contents of the feature list and each candidate block. cosine similarity .

[0068] (2) Calculation of dynamic weight decay factor: (2.1) For each candidate block Let its version time be... The latest system time is .

[0069] (2.2) Define the time decay factor Introducing the concept of a Version State Machine. This factor not only senses the passage of time, but also the "activity" of requirements throughout the software development lifecycle.

[0070] (2.2.1) Calculate the base time difference.

[0071] Base time difference: .

[0072] (2.2.2) Calculate the state mapping and dynamic attenuation coefficient .

[0073] according to Dynamically adjust the "sensitivity" of attenuation: The request has been closed, and at this point, time has minimal impact on the weighting. (Almost no decay).

[0074] When a requirement is activated or changed, time has a significant impact on the weighting. (High attenuation sensitivity).

[0075] (2.2.3) Iteration window correction.

[0076] Introducing the test iteration window function .if If the current demand plan's end point is exceeded, "generational decay" is triggered.

[0077] in, The intergenerational decay coefficient, Based on the time difference, The duration of the current demand plan.

[0078] (2.2.4) Final Calculation formula:

[0079] in A standard iteration cycle (e.g., once a week).

[0080] (2.3) Introduce a change status correction factor : (2.3.1) Define the number of requirement changes This represents the total number of times the requirement or related requirements have been modified, updated, or transitioned in status. The higher the value, the more unstable the demand, the more chaotic the logic, and the lower the reliability as a basis for testing.

[0081] (2.3.2) Define the stability threshold for the change frequency This is a preset "requirement convergence" threshold for the system. This threshold is dynamically adjusted based on the project type (e.g., the threshold for agile projects can be set to 5, and the threshold for core systems can be set to 1).

[0082] (2.3.3) Define the change type correction factor This system uses natural language processing to semantically classify changelogs and requirement descriptions, mapping unstructured text descriptions to structured numerical weights. Its core function is to distinguish between "destructive changes" and "non-destructive changes." In testing, modifying the logic of a core interface (destructive) is far more important than changing the wording of a help document (non-destructive), thus requiring different weighting coefficients. The definitions of the weighting coefficients are shown in Table 1.

[0083] Table 1: Definition of Weighting Coefficients

[0084] (2.3.4) Final Calculation formula:

[0085] in Prioritize the current needs. It has the highest priority.

[0086] (2.4) Introducing a multimodal confidence factor : (2.4.1) Semantic matching verification of code implementation. The semantic vector similarity of the requirement block text with functions, classes, comments and parameter validation logic in the code library is performed. If the matching degree exceeds the set threshold, it is determined that there is evidence of code implementation.

[0087] (2.4.2) Code commit record association verification. By using fields such as commit information, modified file path, associated requirement ID, and branch name, the code commit record corresponding to the current requirement block is retrieved; if a clearly associated commit record exists, it is determined that there is evidence of code commit implementation.

[0088] (2.4.3) Database Schema Change Log Verification. Compare the field rules, data types, and constraints in the requirement block with the database DDL change records and field addition / modification logs; if the field rules described in the requirement are completely or partially consistent with the database schema, then evidence of schema implementation exists.

[0089] (2.4.4) Determine the certainty of each type of evidence. .

[0090] Strong deterministic evidence (code commit history, schema changes): If a match is found, ;otherwise .

[0091] Weak deterministic evidence (semantic matching, visual quality): Take the normalized similarity or quality score.

[0092] (2.4.5) Based on the consensus in the field of software engineering on the levels of certainty of evidence, the system assigns a theoretical discrimination weight to each type of evidence. (Ordinal scale based on the nature of evidence).

[0093] Factual evidence (submission history): (This represents the strongest ability to eliminate uncertainty).

[0094] Structural evidence (Schema change): .

[0095] Semantic / visual level evidence (semantic matching, image quality): (This represents auxiliary verification.)

[0096] (2.4.5) Dynamic normalization calculation, confidence level It is a linear synthesis of the baseline confidence level (0.5, representing a state of no information) and the weighted evidence coverage:

[0097] (2.5) Calculation of overall score: Final score .

[0098] (3) Reordering and truncation: according to Sort set C in descending order.

[0099] (4) Execute "version mutual exclusion logic": If multiple versions of the same module exist in the first N results after sorting, only keep the version that is not specified. The highest-ranking version (i.e., the latest valid version) is used, discarding other older versions of the module to prevent old rules from interfering with the generation. A value of 3-5 for N is recommended to balance effectiveness and performance.

[0100] 3. Generate test cases.

[0101] The reordered and filtered vector embeddings are constructed and indexed, updated in the RAG retrieval library, and then the large language model is used to obtain the latest and most relevant effective content through the RAG retrieval interface to generate test cases.

[0102] To better implement the test case generation method in the software development process according to the embodiments of the present invention, based on the test case generation method in the software development process, correspondingly, as follows: Figure 3As shown, this embodiment of the invention also provides a test case generation device for the software development process. The test case generation device 300 for the software development process includes: The first acquisition module 301 is used to acquire multiple versions of requirement documents, and to preprocess and vectorize the multiple versions of requirement documents to obtain a set of requirement document vectors. The requirement documents include the module identifier, version number, release timestamp, change type, requirement status and the plan to which the requirement belongs. The second acquisition module 302 is used to acquire the target function list and vectorize the target function list to obtain the target function vector, determine the cosine similarity between each requirement document vector in the requirement document vector set and the target function vector, and determine the first preset number of requirement document vectors with the highest cosine similarity to the target function vector as the candidate vector set. The first determining module 303 is used to determine the dynamic weight decay factor of each candidate vector based on the release timestamp, change type, demand status and the plan to which the demand belongs in the candidate vector set, and to correct the cosine similarity between each candidate vector and the target function vector based on the dynamic weight decay factor of each candidate vector, and to determine the similarity score of each candidate vector. The second determining module 304 is used to determine the candidate vector with the highest similarity score among the second preset number of candidate vectors with the highest similarity score that corresponds to the same module identifier as the retained vector set, and to remove the requirement documents corresponding to the candidate vectors other than the retained vector set among the second preset number of candidate vectors with the highest similarity score, and to update the requirement documents of multiple versions. Module 305 is used to generate test cases based on updated versions of the requirements document.

[0103] The test case generation device 300 in the software development process provided in the above embodiments can implement the technical solutions described in the above embodiments of the test case generation method in the software development process. The specific implementation principles of each module or unit can be found in the corresponding content in the above embodiments of the test case generation method in the software development process, and will not be repeated here.

[0104] like Figure 4 As shown, the present invention also provides a test case generation device 400. The test case generation device 400 includes a processor 401, a memory 402, a display 403, and a data acquisition unit 404. Figure 4 Only a portion of the components of the test case generation device 400 are shown; however, it should be understood that implementation of all shown components is not required, and more or fewer components may be implemented instead.

[0105] In some embodiments, processor 401 may be a central processing unit (CPU), microprocessor, or other data processing chip, used to run program code stored in memory 402 or process data, such as the test case generation method in the software development process of this invention.

[0106] In some embodiments, processor 401 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, processor 401 may be local or remote. In some embodiments, processor 401 may be implemented on a cloud platform. In one embodiment, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-cloud, etc., or any combination thereof.

[0107] In some embodiments, memory 402 may be an internal storage unit of the test case generation device 400, such as a hard disk or memory of the test case generation device 400. In other embodiments, memory 402 may also be an external storage device of the test case generation device 400, such as a pluggable hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the test case generation device 400.

[0108] Furthermore, the memory 402 may include both internal storage units of the test case generation device 400 and external storage devices. The memory 402 is used to store application software and various types of data installed on the test case generation device 400.

[0109] In some embodiments, display 403 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an organic light-emitting diode (OLED) touchscreen. Display 403 is used to display information from the test case generation device 400 and to display a user interface for visualization. Components 401-403 of the test case generation device 400 communicate with each other via a system bus.

[0110] In some embodiments, the data acquisition unit 404 may be a data acquisition unit of the test case generation device 400, such as a data acquisition circuit or sensor on the test case generation device 400.

[0111] In one embodiment, when processor 401 executes a test case generation program in the software development process stored in memory 402, the following steps can be implemented: Obtain multiple versions of requirement documents, and preprocess and vectorize them to obtain a set of requirement document vectors. Each requirement document includes the module identifier, version number, release timestamp, change type, requirement status, and the plan to which the requirement belongs. Obtain the target function list and vectorize it to obtain the target function vector. Determine the cosine similarity between each requirement document vector in the requirement document vector set and the target function vector. Then, determine the first preset number of requirement document vectors with the highest cosine similarity to the target function vector as the candidate vector set. Based on the release timestamp, change type, requirement status, and the plan to which the requirement belongs, the dynamic weight decay factor of each candidate vector in the candidate vector set is determined. Based on the dynamic weight decay factor of each candidate vector, the cosine similarity between each candidate vector and the target function vector is corrected to determine the similarity score of each candidate vector. The candidate vectors with the highest similarity scores among the second preset number of candidate vectors corresponding to the same module identifier are selected as the retained vector set. The requirement documents corresponding to the candidate vectors with the highest similarity scores among the second preset number of candidate vectors are removed except for the retained vector set. The requirement documents of multiple versions are updated. Test cases are generated based on multiple updated versions of the requirements document.

[0112] It should be understood that when the processor 401 executes the test case generation program in the software development process in the memory 402, in addition to the functions mentioned above, it can also perform other functions, as detailed in the description of the corresponding method embodiments above.

[0113] Furthermore, this embodiment of the invention does not specifically limit the type of the test case generation device 400 mentioned. The test case generation device 400 can be a portable electronic device such as a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, or laptop computer. Exemplary embodiments of portable electronic devices include, but are not limited to, portable electronic devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable electronic devices can also be other portable electronic devices, such as laptop computers with touch-sensitive surfaces (e.g., touch panels). It should also be understood that in some other embodiments of the invention, the test case generation device 400 may not be a portable electronic device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0114] The above provides a detailed description of the test case generation method and apparatus for the software development process provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for generating test cases in the software development process, characterized in that, include: Obtain multiple versions of requirement documents, and preprocess and vectorize them to obtain a set of requirement document vectors. Each requirement document includes the module identifier, version number, release timestamp, change type, requirement status, and the plan to which the requirement belongs. Obtain the target function list and vectorize it to obtain the target function vector. Determine the cosine similarity between each requirement document vector in the requirement document vector set and the target function vector. Then, determine the first preset number of requirement document vectors with the highest cosine similarity to the target function vector as the candidate vector set. Based on the release timestamp, change type, requirement status, and the plan to which the requirement belongs, the dynamic weight decay factor of each candidate vector in the candidate vector set is determined. Based on the dynamic weight decay factor of each candidate vector, the cosine similarity between each candidate vector and the target function vector is corrected to determine the similarity score of each candidate vector. The candidate vectors with the highest similarity scores among the second preset number of candidate vectors corresponding to the same module identifier are selected as the retained vector set. The requirement documents corresponding to the candidate vectors with the highest similarity scores among the second preset number of candidate vectors are removed except for the retained vector set. The requirement documents of multiple versions are updated. Test cases are generated based on multiple updated versions of the requirements document.

2. The test case generation method in the software development process according to claim 1, characterized in that, The preprocessing and vectorization of multiple versions of the requirements documents yields a set of requirements document vectors, including: For multiple versions of the requirements document, the format should be standardized, invalid content should be removed, and semantic blocks should be formed sequentially. Based on the semantic hash value, module identifier, version number, release timestamp, change type, requirement status, and the plan to which the requirement belongs after semantic segmentation of multiple versions of the requirement document, a set of requirement document vectors is obtained.

3. The test case generation method in the software development process according to claim 2, characterized in that, Change types include addition, modification, and deletion, which are determined based on the corresponding content in two adjacent requirement documents for the same requirement.

4. The test case generation method in the software development process according to claim 1, characterized in that, The dynamic weight decay factor for determining each candidate vector based on its release timestamp, change type, demand status, and the plan to which the demand belongs in the candidate vector set includes: The time decay factor for each candidate vector is determined based on the release timestamp, demand status, and the plan to which the demand belongs. The change status correction factor for each candidate vector is determined based on the change type corresponding to each candidate vector. Based on the code implementation, submission implementation, and schema change implementation of each candidate vector, determine the multimodal confidence factor for each candidate vector; The dynamic weight decay factor of each candidate vector is determined based on the time decay factor, change state correction factor, and multimodal confidence factor of each candidate vector.

5. The test case generation method in the software development process according to claim 4, characterized in that, The process of determining the time decay factor for each candidate vector based on its release timestamp, demand status, and the plan to which the demand belongs includes: The base time difference for each candidate vector is determined based on the difference between the release timestamp and the current time. The intergenerational decay coefficient for each candidate vector is determined based on the base time difference of each candidate vector and the duration of the plan to which the demand belongs. The sensitivity coefficient of each candidate vector is determined based on the demand state corresponding to each candidate vector. Based on the intergenerational decay coefficient, sensitivity coefficient, and basic time difference of each candidate vector, and the preset iteration period, the time decay factor of each candidate vector is determined.

6. The test case generation method in the software development process according to claim 4, characterized in that, The step of determining the change state correction factor for each candidate vector based on the change type corresponding to each candidate vector includes: Based on the change type corresponding to each candidate vector, determine the number of changes, change frequency threshold, and change type correction coefficient for the requirements corresponding to each candidate vector; The change status correction factor for each candidate vector is determined based on the number of changes to the requirements corresponding to each candidate vector, the change frequency threshold, and the change type correction coefficient.

7. The test case generation method in the software development process according to claim 4, characterized in that, The determination of the multimodal confidence factor for each candidate vector based on its code implementation, commit implementation, and schema change implementation includes: The code implementation deterministic score, submission implementation deterministic score, and schema change deterministic score for each candidate vector are determined based on the code implementation status, submission implementation status, and schema change implementation status of each candidate vector. Based on the code implementation deterministic score, submission implementation deterministic score, and schema change deterministic score for each candidate vector, as well as the preset discrimination weight, the multimodal confidence factor for each candidate vector is determined.

8. The test case generation method in the software development process according to claim 1, characterized in that, The generation of test cases based on multiple updated versions of the requirements document includes: The RAG search library is updated based on multiple updated versions of the requirements documents, and test cases are generated based on the RAG search library.

9. A test case generation device for software development, characterized in that, include: The first acquisition module is used to acquire multiple versions of requirement documents, and preprocess and vectorize the multiple versions of requirement documents to obtain a set of requirement document vectors. The requirement documents include the module identifier, version number, release timestamp, change type, requirement status and the plan to which the requirement belongs. The second acquisition module is used to acquire the target function list and vectorize the target function list to obtain the target function vector, determine the cosine similarity between each requirement document vector in the requirement document vector set and the target function vector, and determine the first preset number of requirement document vectors with the highest cosine similarity to the target function vector as the candidate vector set. The first determining module is used to determine the dynamic weight decay factor of each candidate vector based on the release timestamp, change type, demand status and the plan to which the demand belongs in the candidate vector set, and to correct the cosine similarity between each candidate vector and the target function vector based on the dynamic weight decay factor of each candidate vector, and to determine the similarity score of each candidate vector. The second determining module is used to determine the candidate vector with the highest similarity score among the second preset number of candidate vectors with the highest similarity score that corresponds to the same module identifier as the retained vector set, and to remove the requirement documents corresponding to the candidate vectors other than the retained vector set among the second preset number of candidate vectors with the highest similarity score, and to update the requirement documents of multiple versions. The generation module is used to generate test cases based on multiple updated versions of the requirements document.

10. A test case generation device, characterized in that, Includes a data acquisition unit, memory, and processor, among which, The data collector is used to acquire multiple versions of the requirements document and the list of target features; The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the test case generation method in the software development process according to any one of claims 1 to 7.

Images