Test case generation method and device, equipment, medium and program product
By constructing a knowledge graph and employing multi-path recall technology, more accurate test cases are generated, solving the problems of insufficient accuracy and coverage in existing test cases and achieving higher-quality test case generation.
Patent Information
- Application Number
- CN202511543619.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-27
- Publication Date
- 2026-02-24
AI Technical Summary
Existing test case generation solutions suffer from insufficient accuracy and comprehensive coverage, and are easily limited by personal experience and knowledge, resulting in low-quality test cases that are difficult to adapt to flexible and ever-changing business needs and scenarios.
By constructing a knowledge graph, the relationships between business entities, historical test cases, and business documents are stored. Multi-path recall and reordering are performed using tagged test points and business scenario labels. Combined with business requirement information, enhanced context is generated to produce more accurate test points and test cases.
It improves the accuracy and comprehensiveness of test cases, reduces the risk of missing test points, and generates more accurate and comprehensive test cases that can adapt to complex business scenarios.
Smart Images
Figure CN121560733A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of testing technology, and in particular to a method, apparatus, device, medium, and program product for generating test cases. Background Technology
[0002] A test case is a set of test inputs, execution conditions, and expected results designed for a specific objective, in order to test a program path or verify whether a particular requirement is met. Test cases are an indispensable core component of the business requirements quality assurance system; their accuracy and comprehensiveness in covering business requirements determine the effectiveness of the testing. Summary of the Invention
[0003] To address the issue of improving the accuracy and comprehensiveness of test cases, this application provides a method, apparatus, device, medium, and program product for generating test cases.
[0004] According to some embodiments of this application, a method for generating test cases is provided, comprising: obtaining a business requirement document and business scenario information; obtaining business requirement information from the business requirement document; performing multi-way recall in a knowledge base based on the business requirement information and the business scenario information, and reordering the recall results, wherein the knowledge base stores a knowledge graph indicating business entities, historical test cases, historical business documents and their relationships, the business entities carrying attribute information, the attribute information including marked test points corresponding to the business entity and tags indicating the business scenarios corresponding to the marked test points; generating an enhanced context based on the reordering results and the business requirement information; generating test points corresponding to the business requirement document based on the enhanced context; and generating corresponding test cases based on each test point corresponding to the business requirement document.
[0005] According to some embodiments of this application, an apparatus for generating test cases is also provided, comprising: an acquisition module for acquiring a business requirement document and business scenario information; an extraction module for acquiring business requirement information from the business requirement document; a recall module for performing multi-way recall in a knowledge base based on the business requirement information and the business scenario information, and reordering the recall results, wherein the knowledge base stores a knowledge graph indicating business entities, historical test cases, historical business documents and their relationships, the business entities carrying attribute information, the attribute information including marked test points corresponding to the business entities and tags indicating the business scenarios corresponding to the marked test points; generating an enhanced context based on the reordering results and the business requirement information; a first generation module for generating test points corresponding to the business requirement document based on the enhanced context; and a second generation module for generating corresponding test cases based on each test point corresponding to the business requirement document.
[0006] According to some embodiments of this application, an electronic device is also provided, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to implement the test case generation method as described in any embodiment of this application.
[0007] According to some embodiments of this application, a computer-readable storage medium is also provided in this application. The computer-readable storage medium stores computer instructions, which, when executed by a processor, can implement the test case generation method as described in any embodiment of this application.
[0008] According to some embodiments of this application, a computer program product is also provided, including a computer program that, when at least a portion of the computer program is executed by a processor, can implement the test case generation method as described in any embodiment of this application.
[0009] The technical solution provided in this application constructs a knowledge base storing a knowledge graph that indicates business entities, historical test cases, historical business documents, and their relationships. This enables the structured representation of business relationships using the knowledge graph, allowing for precise parsing of the business requirements document based on the business requirement information within it. Furthermore, since the attributes of business entities include labeled test points and corresponding business scenario tags, combining business requirement information and business scenario information for retrieval in the knowledge base further strengthens the correlation between the retrieval results and the business scenario, resulting in higher accuracy. Labeling test points also reduces the risk of missed test points. Simultaneously, because the knowledge graph also involves historical test cases and historical business document information, it provides more references for the generation of test points and test cases. The resulting test cases will be more accurate and comprehensive.
[0010] In some embodiments, the step of performing multi-path recall in the knowledge base based on the business requirement information and the business scenario information includes: vectorizing the business requirement information to obtain a text vector; filtering business entities with tags corresponding to the business scenario information from the knowledge base; performing multi-path recall on the filtered business entities based on the text vector, and obtaining the historical test cases and historical business documents associated with the recalled business entities. Before multi-path recall, the business entities in the knowledge base are filtered based on the tags corresponding to the business scenario information, so that the results of multi-path recall can all conform to the business scenario information, that is, have a stronger association with the business scenario, improving the accuracy and reliability of the recall results, thereby making the test cases obtained based on this more accurate.
[0011] In some embodiments, obtaining business requirement information from the business requirement document includes: obtaining the business requirement information from the business requirement document according to a first intelligent agent; performing multi-way recall in a knowledge base based on the business requirement information and the business scenario information, and re-ranking the recall results includes: using a RAG model, performing multi-way recall in the knowledge base based on the business requirement information and the business scenario information, and re-ranking the recall results; generating an enhanced context based on the re-ranking result and the business requirement information includes: using the RAG model, generating the enhanced context based on the re-ranking result and the business requirement information; Generating test points corresponding to the business requirement document based on the enhanced context includes: generating a first prompt chain based on the enhanced context and a preset first prompt chain template; generating test points corresponding to the business requirement document using a second intelligent agent based on the first prompt chain; generating corresponding test cases based on each test point of the business requirement document includes: generating a second prompt chain corresponding to each test point of the business requirement document based on each test point of the business requirement document and a preset second prompt chain template; generating test cases corresponding to each test point of the business requirement document using a third intelligent agent based on the second prompt chain corresponding to each test point of the business requirement document. This is more intelligent, accurate, and reliable. Attached Figure Description
[0012] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.
[0013] Figure 1 This is a flowchart of a test case generation method provided in one embodiment of this application; Figure 2 This is a flowchart illustrating the implementation of step 102 in the test case generation method provided in another embodiment of this application; Figure 3 This is a flowchart illustrating the implementation of step 102 in the test case generation method provided in another embodiment of this application; Figure 4 This is a flowchart of a partial implementation of step 103 in the test case generation method provided in another embodiment of this application; Figure 5 This is a flowchart of a partial implementation of step 103 in the test case generation method provided in another embodiment of this application; Figure 6This is a flowchart illustrating the implementation of step 105 in the test case generation method provided in another embodiment of this application; Figure 7 This is a flowchart illustrating the implementation of step 106 in the test case generation method provided in another embodiment of this application; Figure 8 This is a flowchart of a test case generation method provided in another embodiment of this application; Figure 9 This is a flowchart of a test case generation method provided in another embodiment of this application; Figure 10 This is a schematic diagram of the deployment model corresponding to the test case generation method provided in another embodiment of this application; Figure 11 This is a schematic diagram of the deployment model corresponding to the test case generation method provided in another embodiment of this application; Figure 12 This is a schematic diagram of the structure of a test case generation device provided in another embodiment of this application; Figure 13 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation
[0014] As described in the background section, the accuracy of test cases and their comprehensive coverage of business requirements determine the effectiveness of testing. Therefore, to achieve better testing results, there is an urgent need for a solution that can improve the accuracy and comprehensiveness of test cases.
[0015] Analysis revealed that the existing test case generation schemes have room for improvement in terms of accuracy and comprehensiveness. At least two aspects are addressed: First, test cases are manually written by testers. Second, testers write text prompts based on templates, which are then automatically generated using a large-scale model. The former method is time-consuming and heavily reliant on individual experience, making it prone to errors due to human error. The latter method, limited by individual experience and knowledge, often results in text prompts that fail to accurately help the large-scale model understand the differences in business logic across various scenarios, hindering the generation of high-quality test cases and increasing the likelihood of missing test points or content. Providing prompts that adapt to flexible and dynamically changing business requirements and scenarios would significantly improve the accuracy and comprehensiveness of test case coverage.
[0016] Based on this, this application provides a method, apparatus, device, medium, and program product for generating test cases. It uses a knowledge graph to represent business relationships in a structured way, strengthens the association with business through tags, and provides reference for key and difficult test points by marking test points. At the same time, it introduces historical test cases and historical business documents into the knowledge graph, thereby providing more accurate and reliable reference information for the generation of test cases, and ultimately achieving the goal of improving the accuracy and comprehensiveness of test cases.
[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of this application to enable readers to better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments.
[0018] The division of the following embodiments is for ease of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.
[0019] This application provides a method for generating test cases, applicable to devices such as computers and servers. The following will be combined with... Figures 1 to 9 The process shown, and Figures 10 to 11 The model deployment structure shown illustrates the method for generating test cases.
[0020] In some embodiments, such as Figure 1 As shown, the process of generating test cases includes the following steps: Step 101: Obtain business requirements documents and business scenario information.
[0021] Step 102: Obtain business requirement information from the business requirement document.
[0022] Step 103: Based on business requirement information and business scenario information, perform multi-way recall in the knowledge base and reorder the recall results. The knowledge base stores a knowledge graph that indicates business entities, historical test cases, historical business documents and their relationships. Business entities carry attribute information, including the marked test points corresponding to the business entities and the tags indicating the business scenarios corresponding to the marked test points.
[0023] Step 104: Generate an enhanced context based on the reordering results and business requirement information.
[0024] Step 105: Generate test points corresponding to the business requirements document based on the enhanced context.
[0025] Step 106: Generate corresponding test cases based on each test point in the business requirements document.
[0026] exist Figure 1 In the illustrated embodiment, by constructing a knowledge base that stores a knowledge graph indicating business entities, historical test cases, historical business documents, and their relationships, it is possible to use the knowledge graph to structurally represent business relationships. This allows for accurate parsing of the business requirements document based on the business requirement information within the document. Furthermore, since the attributes of business entities include labeled test points and corresponding business scenario tags, combining business requirement information and business scenario information for retrieval in the knowledge base further strengthens the correlation between the retrieval results and the business scenario, resulting in higher accuracy. Labeling test points also reduces the risk of missing test points. Simultaneously, because the knowledge graph also involves historical test cases and historical business document information, it provides more references for the generation of test points and test cases. The final generated test cases will be more accurate and comprehensive.
[0027] For ease of understanding Figure 1 The steps of the illustrated embodiment will be explained below.
[0028] In step 101, the business requirements document is a document used to clarify product requirements and functions during the development process based on business requirements; the business scenario information is information related to the application scenario of any business requirement corresponding to the business requirements document.
[0029] It should be noted that the embodiments of this application do not limit the business requirements document and business scenario information, which vary depending on the business content, requirements, etc. For example, the business requirements document may include one or a combination of basic product information, functional requirements, performance requirements, and user needs; similarly, the business scenario may include one or a combination of front-end scenarios, back-end scenarios, etc., which will not be listed one by one here.
[0030] It should also be noted that the embodiments of this application do not limit the methods for obtaining business requirement documents and business scenario information. For example, business scenario information can be actively uploaded by the user along with the business requirement document to trigger the test case generation method provided in the embodiments of this application; or, business scenario information can be displayed on the user's interactive interface, prompting the user to select it on the interactive interface when needed, etc., and so on, which will not be listed here.
[0031] In step 102, the business requirement information is the content related to business and requirements in the business requirement document.
[0032] It should be noted that the embodiments of this application do not limit the specific content of the business requirement information. It is understood that the business requirement information will vary depending on the content of the business requirement document. For example, when the business requirement document includes basic product information, the business requirement information will also include basic product information; similarly, when the business requirement document includes user requirements, the business requirement information will also include user requirements.
[0033] It should also be noted that the embodiments of this application do not limit the method of obtaining business requirement information. For example, in some embodiments, models such as LLM (Large Language Model) can be used; in others, information extraction can be achieved using a preset rule model. Furthermore, in some embodiments, other data processing methods, such as deduplication and format conversion, can be combined during the process of obtaining business requirements. These will not be listed here.
[0034] For ease of understanding, this section mainly combines... Figure 2 and Figure 3 The process shown illustrates how to obtain business requirement information.
[0035] In some embodiments, such as Figure 2 As shown, obtaining business requirement information from the business requirement document can be achieved through the following steps: Step 102a: Obtain the text content of the business requirements document and perform inspection to generate initial business requirements information.
[0036] Step 102b: Remove irrelevant information from the initial business requirements information and perform text proofreading.
[0037] Step 102c: Convert the format of the proofread text to obtain the business requirement information.
[0038] exist Figure 2 In the illustrated embodiment, by removing irrelevant information, proofreading the text, and converting the format of the initial business requirement information obtained by scanning, the business requirement document can be transformed into a more unified and standardized form, avoiding the adverse effects of other interfering factors (such as different formats, text errors, redundant information), and facilitating subsequent processing.
[0039] For ease of understanding, the following will be... Figure 2 The steps of the illustrated embodiment will be explained.
[0040] In step 102a, this embodiment of the application does not limit the acquisition and detection of text content. It can be said that any method that can acquire and detect the entire content of the business requirement document can be used, such as text scanning, text recognition, and filtering based on preset rules.
[0041] Furthermore, this application embodiment does not limit the initial business requirement information. It is understood that since it will be processed subsequently, i.e., it is not required to obtain the necessary business requirement information all at once, the screening conditions for the initial business requirement can be relaxed compared to the business requirement information. For example, the initial business requirement information may involve options, values, text, conditional logic, etc. in the business scenario. These will not be listed one by one here.
[0042] In step 102b, this embodiment of the application does not limit information unrelated to business operations; such information varies depending on the content of different business requirement documents. For example, when a business requirement document has the signature of the document author, the signature is considered unrelated to business operations; similarly, when a business requirement document has document version information, this information is considered unrelated to business operations; furthermore, when pages in a business requirement document have headers and footers, the headers and footers are considered unrelated to business operations, and so on. These will not be listed in detail here.
[0043] Furthermore, the embodiments of this application do not limit the method of text proofreading. It can be any or some of the processes that help remove processed information and improve the standardization of expression. For example, it can include one or a combination of the following processes: checking whether the subject is missing and supplementing and correcting it in the context when the subject is missing; checking whether there are typos and correcting them when they are found; checking whether the grammatical expression is standard and correcting it when non-standard grammatical expression is found, etc., which will not be listed here one by one.
[0044] In step 102c, this embodiment does not limit the format of the converted data; it can be set according to the needs of subsequent processing or user requirements. For example, when processing with models such as LLM, the Markdown format can be set to the converted format to meet the data format requirements of LLM models; similarly, the XML format can be set to the converted format for output and user viewing of processing results. Correspondingly, the conversion method will adapt differently depending on the format before and after conversion. Related text conversion solutions have been described, and they are also applicable to the format conversion processing in this embodiment, so they will not be elaborated here.
[0045] In some embodiments, such as Figure 3 As shown, obtaining business requirement information from the business requirement document can be achieved through the following steps: Step 102d: Obtain the text content of the business requirements document and perform inspection to generate initial business requirements information.
[0046] Step 102e: Remove irrelevant information from the initial business requirements information and perform text proofreading.
[0047] Step 102f involves converting the format of the proofread text to obtain the business requirement information.
[0048] Step 102g: Compare the business requirement information with the initial business requirement information.
[0049] Adaptively, step 103 above can be implemented as follows: when the business requirement information is compared, multi-path retrieval is performed in the knowledge base based on the business requirement information and business scenario information.
[0050] exist Figure 3 In the illustrated embodiment, the initial business requirement information is further compared with the business requirement information obtained after irrelevant information removal, text proofreading, and format conversion. This allows verification of whether the aforementioned irrelevant information removal, text proofreading, and format conversion have resulted in unreasonable information loss, ensuring the reliability of the processing and preventing the loss of necessary information from affecting the accuracy of subsequent processing.
[0051] For ease of understanding, the following will be... Figure 3 The steps of the illustrated embodiment will be explained. Steps 102d to 102f are largely the same as steps 102a to 102c in the previous embodiments, and will not be described in detail here.
[0052] In step 102g, the comparison method can be text-by-text comparison, or it can be to determine the text similarity between the initial business requirement information and the business requirement information, so as to determine that the comparison fails when the text similarity is lower than a preset value. The embodiments of this application do not limit the specific comparison method, and will not be listed one by one here.
[0053] Of course, the above is only an example of how to implement step 102. In some embodiments, step 102 can also be implemented in other ways, which will not be listed here.
[0054] In step 103, the business document is a document used to describe the logical relationships between business functions.
[0055] It should be noted that the embodiments of this application do not limit the methods of multi-way recall and reordering. They can be any method that can obtain multiple results or sort multiple results; these will not be listed here. The following examples of multi-way recall and reordering are provided for ease of understanding, but this does not mean that the test case generation method of the embodiments of this application can only use the following implementation methods.
[0056] In some embodiments, such as Figure 4 As shown, multi-path retrieval in the knowledge base based on business requirements and business scenario information can be achieved in the following ways: Step 103a: Vectorize the business requirement information to obtain text vectors.
[0057] Step 103b: Filter business entities with tags corresponding to business scenario information from the knowledge base.
[0058] Step 103c: Based on the text vector, perform multi-path recall on the filtered business entities and obtain the historical test cases and historical business documents associated with the recalled business entities.
[0059] exist Figure 4 In the illustrated embodiment, before multi-path recall, business entities in the knowledge base are filtered based on tags corresponding to business scenario information, so that the results of multi-path recall can all conform to business scenario information, that is, have a stronger correlation with business scenario, thereby improving the accuracy and reliability of recall results, and the test cases obtained based on this will be more accurate.
[0060] For ease of understanding, the following will be... Figure 4 The steps of the illustrated embodiment will be explained.
[0061] In step 103a, this embodiment of the application does not limit the method of text vectorization. Any existing method that can achieve text vectorization can be applied to the implementation of this step, and will not be described in detail here.
[0062] In step 103b, this embodiment of the application does not limit the correspondence between business scenario information and tags. It is understood that the correspondence between business scenario information and tags will vary depending on the specific business scenario information. For example, business scenario information may have the same meaning as a tag. In this case, the tag corresponding to the business scenario information is a tag with the same content as the business scenario information. Alternatively, business scenario information may have different meanings from tags. In this case, the association between the business scenario information and the tag is based on their corresponding business scenario. In this case, the tag corresponding to the business scenario information can be determined through preset association logic or by using models, etc. These methods will not be listed here.
[0063] In step 103c, this embodiment of the application does not limit the recall method used in the multi-path recall. For example, it may include semantic matching-based retrieval, which ultimately returns the top K1 retrieval results with the highest semantic matching degree; or it may include keyword matching-based retrieval, which ultimately returns the top K2 retrieval results with the highest semantic matching degree, etc., which will not be listed here.
[0064] It should be noted that, as mentioned earlier, the knowledge graph in the knowledge base indicates business entities, historical test cases, historical business documents, and their relationships. Therefore, after finding a business entity based on multi-path retrieval, related historical test cases and historical business documents can be further found based on their relationships. The search method can be implemented based on graph search algorithms, etc., which will not be elaborated here.
[0065] In some embodiments, such as Figure 5 As shown, the results of the recall can be reordered in the following way: Step 103d involves scoring the results of each recall using different methods.
[0066] Step 103e: Sort the recall results according to the scores obtained in different ways.
[0067] exist Figure 5 In the illustrated embodiment, different scoring methods enable multi-dimensional scoring of the recall results, thereby making the ranking of the recall results more accurate and reliable by considering more dimensions of information.
[0068] For ease of understanding, the following will be... Figure 5 The steps of the illustrated embodiment will be explained.
[0069] In step 103d, this embodiment of the application does not limit the scoring method used; it can be any method capable of evaluating text content. For example, keyword matching can be performed on the results of each recall to generate a keyword matching score for each recall result; semantic similarity detection can be performed on the results of each recall and the business requirement information to generate a semantic similarity score for each recall result; or, based on the business requirement information, graph search can be performed on the results of each recall in a knowledge graph to generate a graph distance score for each recall result. Of course, the above are just examples, and the above scoring methods can be combined, or combined with other scoring methods, etc., which will not be listed here.
[0070] In step 103e, this embodiment of the application does not limit the sorting of scores obtained in different ways to form the recall results. For example, the recall results can be sorted according to the scores obtained in different ways, and the final sorting of the recall results can be generated according to the inverse fusion sorting algorithm based on the different sorting results. The sorting does not depend on specific scores, and the sorting is more objective and fair. Alternatively, the total score of the recall results can be determined by summing (or weighted summing, averaging, etc.) the scores obtained in different ways, and then the recall results can be sorted based on the total score. This is simple and efficient, etc., and will not be listed here.
[0071] In step 104, this embodiment of the application does not limit the association between the results of the reordering in the enhancement context. For example, only the best result in the sorting can be retained in the enhancement context, thereby reducing the data size in the enhancement context and reducing the pressure on subsequent processing; or, the recalled results can be sorted according to the sorting in the enhancement context, etc., which will not be listed here.
[0072] To better understand the meaning of enhanced context, the following provides an example of its structure.
[0073] In some embodiments, the structure of the enhanced context is as follows: { "Current Requirements": Contents of the business requirements document; "Related Business Documents": Historical business documents retrieved; "Related test cases": Related historical test cases; "Business Rules": Rules extracted from the knowledge graph; }
[0074] Of course, the above are just examples. In some cases, you can also directly splice together the content of business requirements documents, retrieved historical business documents, etc., which will not be listed here.
[0075] In step 105, the generation of test points in this embodiment of the application is not limited. For example, it can be implemented by parsing and enhancing the context through a preset rule model, or it can be implemented using LLM, etc., which will not be listed here. For ease of understanding, examples of its implementation are provided below, but this does not mean that the test case generation method provided in this embodiment of the application must use the following method to generate test points.
[0076] In some embodiments, such as Figure 6 As shown, generating test points corresponding to the business requirements document based on the enhanced context can be achieved through the following steps: Step 105a: Perform requirements analysis based on the enhanced context.
[0077] Step 105b: Based on the requirements obtained from the analysis, perform scene recognition for verification.
[0078] Step 105c: Based on the identified verification scenarios and the analyzed requirements, generate test points corresponding to the business requirement document.
[0079] exist Figure 6 In the illustrated embodiment, by analyzing requirements and identifying verification scenarios, accurate information for generating test points can be obtained, thereby generating accurate, reliable, and comprehensive test points.
[0080] For ease of understanding, the following will be... Figure 6 The steps of the illustrated embodiment will be explained.
[0081] In step 105a, this embodiment of the application does not limit the method of requirement analysis. It can be determined based on matching or implemented using LLM, etc., which will not be elaborated here. In step 105b, this embodiment of the application does not limit the identification of verification scenarios, which can vary depending on the verification scenario to be identified. For example, when focusing primarily on strong verification scenarios, verification scenario identification can be performed based on the analyzed requirements, which can be achieved as follows: based on the analyzed requirements, detect whether the current scenario corresponds to a strong verification scenario. Accordingly, subsequently, based on the identified verification scenario and the analyzed requirements, test points corresponding to the business requirement document can be generated, which can be achieved as follows: if a strong verification scenario is detected, test points corresponding to the business requirement document can be generated based on the corresponding strong verification scenario and the analyzed requirements. This allows for a greater focus on scenarios with stronger testing requirements, thereby making full use of resources. Of course, the above is only an example, and other verification scenarios can also be considered, or combined with other verification scenarios, for example, matching whether the current business scenario belongs to a strong verification scenario or a weak verification scenario, etc., which will not be listed here.
[0082] In step 106, this embodiment of the application does not limit the method of generating test cases, which may vary depending on the type of test point. Examples will be provided below, but this does not mean that the following examples must be used to generate test cases.
[0083] In some embodiments, such as Figure 7 As shown, generating corresponding test cases based on each test point in the business requirements document can be achieved through the following steps: Step 106a: Detect the type of each test point corresponding to the business requirements document.
[0084] Step 106b: If at least one test point in the business requirements document is of a functional type, generate corresponding functional test cases and reverse test cases based on the functions corresponding to the test points of the functional type in the business requirements document.
[0085] Step 106c: If at least one test point in the business requirements document is of a compatibility type, generate corresponding compatibility test cases based on the compatibility requirements of the test points of the compatibility type in the business requirements document.
[0086] exist Figure 7In the illustrated embodiment, the type of test point is identified, and different test cases are generated based on the corresponding type adaptability, making the generation of test cases more in line with testing requirements and more accurate and reliable.
[0087] For ease of understanding, the following will be... Figure 7 The steps of the illustrated embodiment will be explained.
[0088] In step 106a, this embodiment of the application does not limit the type detection method of the test point. For example, the feature information of the test point can be extracted from the business requirement document or business requirement information, and matching can be performed based on the feature information. Alternatively, it can be implemented using LLM, etc., which will not be elaborated here.
[0089] In step 106b, the test points for functional types focus more on functional effects. Therefore, adaptively generating functional test cases and reverse test cases is more in line with the test requirements.
[0090] In step 106c, the test points for compatibility types have a greater focus on compatibility. Therefore, adaptively generating compatibility test cases is more in line with the test requirements.
[0091] Of course, the above are just examples. In some embodiments, other methods can be used to generate test cases, or additional checks can be added to the test cases. For example, COT (Certificate of Test) checks can be performed on the obtained test cases to remove those that fail the COT check. The specific content of the COT check is not limited; it can include, for example, one or a combination of: field checks, strict text dependency principles (not generating tests unless explicitly stated in the requirements), explicit declaration principles (verification logic is reflected in the requirements, and external specifications are not referenced), and strict parameter control principles (no additions, deletions, or modifications are made to specific numbers, toast messages, pop-up prompts, etc.). These will not be listed here. Furthermore, test cases can be formatted, such as converted to JSON format, etc., which will not be listed here.
[0092] To facilitate understanding of the test case generation method and its effects provided in the embodiments of this application, the following will explain it in conjunction with the use of large models, etc.
[0093] In some embodiments, such as Figure 8 As shown, the process of generating test cases includes the following steps: Step 801: Obtain business requirements documents and business scenario information.
[0094] Step 802: Based on the first intelligent agent, obtain business requirement information from the business requirement document.
[0095] Step 803: Using the RAG model, based on business requirement information and business scenario information, perform multi-way recall in the knowledge base and re-rank the recall results. The knowledge base stores a knowledge graph that indicates business entities, historical test cases, historical business documents and their relationships. Business entities carry attribute information, including the marked test points corresponding to the business entities and the tags indicating the business scenarios corresponding to the marked test points.
[0096] Step 804: Using the RAG model, generate an enhanced context based on the reordering results and business requirement information.
[0097] Step 805: Generate the first prompt chain based on the enhanced context and the preset first prompt chain template.
[0098] Step 806: Using the second intelligent agent, generate test points corresponding to the business requirement document based on the first prompt chain.
[0099] Step 807: Generate the second prompt chain corresponding to each test point in the business requirements document based on the test points in the business requirements document and the preset second prompt chain template.
[0100] Step 808: Using a third intelligent agent, generate test cases for each test point in the business requirements document based on the second prompt chain corresponding to each test point in the business requirements document.
[0101] In some embodiments, such as Figure 9 As shown, the process of generating test cases includes the following steps: Step 901: Obtain business requirements documents and business scenario information.
[0102] Step 902: Based on the first intelligent agent, obtain business requirement information from the business requirement document.
[0103] Step 903: Using the RAG model, based on business requirement information and business scenario information, perform multi-way recall in the knowledge base and re-rank the recall results. The knowledge base stores a knowledge graph that indicates business entities, historical test cases, historical business documents and their relationships. Business entities carry attribute information, including the marked test points corresponding to the business entities and the tags indicating the business scenarios corresponding to the marked test points. Step 904: Using the RAG model, generate an enhanced context based on the reordering results and business requirement information.
[0104] Step 905: Generate the first prompt chain based on the enhanced context and the preset first prompt chain template.
[0105] Step 906: Using the second intelligent agent, generate test points corresponding to the business requirement document based on the first prompt chain.
[0106] Step 907: Generate a third prompt chain based on business requirements information and a preset third prompt chain template.
[0107] Step 908: Using the second intelligent agent, generate test points corresponding to the business requirement document based on the third prompt chain.
[0108] Step 909: Generate the second prompt chain corresponding to each test point in the business requirements document based on each test point in the business requirements document and the preset second prompt chain template. Step 910: Using a third intelligent agent, generate test cases for each test point in the business requirements document based on the second hint chain corresponding to each test point in the business requirements document.
[0109] It is not hard to see that Figure 8 and Figure 9 and Figure 1 The processes shown are largely the same; the main difference lies in... Figure 8 and Figure 9 The process incorporates intelligent agents and a RAG (Retrieval-Augmented Generation) model. Figure 8 The illustrated embodiments and Figure 9 The embodiments shown are similar, with the main difference being that, Figure 9 The illustrated embodiment is in Figure 8 The illustrated embodiment, based on the generation of test points using the first prompt chain, further introduces processing based on the generation of test points using the third prompt chain, thereby enabling... Figure 8 The embodiment shown corresponds to Figure 10 Based on the model deployment structure shown, Figure 9 The corresponding embodiment shown is as follows: Figure 11 The model deployment structure shown further increases the direct connection from the first agent to the second agent.
[0110] Depend on Figure 8 and Figure 9As can be seen from the embodiments shown, the test case generation method provided in this application achieves high accuracy and high coverage test case generation by constructing a knowledge graph, designing a strong regression verification hint strategy, and optimizing the retrieval and recall process. Through the structured representation and semantic reasoning capabilities of the knowledge graph, the model can accurately identify and understand the logical dependencies, constraints, and boundary scenarios in complex business rules, significantly improving the accuracy of business semantic parsing. The multi-path recall mechanism effectively improves the retrieval and recall hit rate of the retrieval enhancement generation RAG project, making the knowledge acquired by the model more effective and improving the overall accuracy of the test cases. By incorporating a hint engineering strategy that includes strong regression verification points for business scenarios, the generated test cases can more comprehensively cover key business logic, exception handling paths, and boundary conditions, effectively reducing the problem of missing key test scenarios.
[0111] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.
[0112] This application also provides a test case generation device, such as... Figure 12 As shown, it includes: The acquisition module is used to acquire business requirement documents and business scenario information; The extraction module is used to obtain business requirement information from the business requirement document; The recall module is used to perform multi-way recall in the knowledge base based on business requirement information and business scenario information, and to re-rank the recall results. The knowledge base stores a knowledge graph that indicates business entities, historical test cases, historical business documents and their relationships. Business entities carry attribute information, including the marked test points corresponding to the business entities and the tags indicating the business scenarios corresponding to the marked test points. Based on the re-ranking results and business requirement information, an enhanced context is generated. The first generation module is used to generate test points corresponding to the business requirement document based on the enhanced context; The second generation module is used to generate corresponding test cases based on each test point in the business requirements document.
[0113] It is not difficult to see that this embodiment is a device embodiment corresponding to the method embodiment, and this embodiment can be implemented in conjunction with the method embodiment. The relevant technical details mentioned in the method embodiment are still valid in this embodiment, and will not be repeated here to reduce repetition. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiment.
[0114] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.
[0115] This application also provides an electronic device, such as... Figure 13 As shown, it includes: at least one processor 1301; and a memory 1302 communicatively connected to at least one processor 1301; wherein the memory 1302 stores instructions executable by at least one processor 1301, the instructions being executed by at least one processor 1301 to enable at least one processor 1301 to execute the test case generation method described in any of the above method embodiments.
[0116] The memory 1302 and processor 1301 are connected via a bus. This bus can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors 1301 and memory 1302. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 1301 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 1301.
[0117] Processor 1301 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 1302 can be used to store data used by processor 1301 during operation.
[0118] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the above-described method embodiments.
[0119] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor 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.
[0120] This application also provides a computer program product, including a computer program, which, when at least a portion of the computer program is executed by a processor, can implement the test case generation method as described in any of the preceding claims.
[0121] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.
Claims
1. A method for generating test cases, characterized in that, include: Obtain business requirements documents and business scenario information; Obtain business requirement information from the aforementioned business requirement document; Based on the business requirement information and the business scenario information, a multi-way recall is performed in the knowledge base, and the recall results are reordered. The knowledge base stores a knowledge graph that indicates business entities, historical test cases, historical business documents and their relationships. The business entities carry attribute information, which includes the marked test points corresponding to the business entities and the tags indicating the business scenarios corresponding to the marked test points. Based on the reordering results and the aforementioned business requirement information, an enhanced context is generated; Based on the enhanced context, test points corresponding to the business requirement document are generated; Based on the test points corresponding to the business requirements document, generate corresponding test cases.
2. The test case generation method according to claim 1, characterized in that, The step of performing multi-path retrieval in the knowledge base based on the business requirement information and the business scenario information includes: The business requirement information is vectorized to obtain a text vector; From the knowledge base, select the business entities that have the tags corresponding to the business scenario information; Based on the text vector, multiple recalls are performed on the filtered business entities, and the historical test cases and historical business documents associated with the recalled business entities are obtained.
3. The method for generating test cases according to claim 1 or 2, characterized in that, The reordering of the recall results includes: The results of each recall were scored using different methods; The recall results are sorted according to the scores obtained in different ways; The different methods used to score the results of each recall include: Keyword matching is performed on the results of each recall to generate a keyword matching score for each recall result; And / or, Semantic similarity detection is performed on the results of each recall and the business requirement information to generate a semantic similarity score for each recall result; And / or, Based on the business requirement information, a graph search is performed on the recall results in the knowledge graph to generate a graph distance score for each recall result.
4. The method for generating test cases according to any one of claims 1 to 3, characterized in that, The step of generating test points corresponding to the business requirement document based on the enhanced context includes: Based on the enhanced context, perform requirements analysis; Based on the requirements obtained from the analysis, determine whether the current situation corresponds to a strong verification scenario; If a strong validation scenario is detected, test points corresponding to the business requirement document are generated based on the strong validation scenario and the requirements obtained from the analysis.
5. The method for generating test cases according to any one of claims 1 to 4, characterized in that, The step of generating corresponding test cases based on each test point in the business requirements document includes: The type of each test point corresponding to the business requirement document is detected; If at least one test point in the business requirements document is of a functional type, corresponding functional test cases and reverse test cases are generated based on the functions corresponding to the test points of the functional type in the business requirements document. If at least one test point corresponding to the business requirements document is of the compatibility type, corresponding compatibility test cases are generated based on the compatibility requirements of the test points of the compatibility type corresponding to the business requirements document.
6. The method for generating test cases according to any one of claims 1 to 5, characterized in that, The step of obtaining business requirement information from the business requirement document includes: According to the first intelligent agent, the business requirement information is obtained from the business requirement document; The step of performing multi-path retrieval in the knowledge base based on the business requirement information and the business scenario information, and reordering the retrieval results, includes: Using the RAG model, based on the business requirement information and the business scenario information, a multi-path retrieval is performed in the knowledge base, and the retrieval results are reordered. The step of generating an enhanced context based on the reordering result and the business requirement information includes: Using the RAG model, the enhanced context is generated based on the reordering result and the business requirement information; The step of generating test points corresponding to the business requirement document based on the enhanced context includes: Generate a first prompt chain based on the enhanced context and the preset first prompt chain template; Using a second intelligent agent, test points corresponding to the business requirement document are generated based on the first prompt chain; The step of generating corresponding test cases based on each test point in the business requirements document includes: Based on the test points corresponding to the business requirements document and the preset second prompt chain template, generate the second prompt chain corresponding to each test point of the business requirements document; Using a third intelligent agent, test cases are generated for each test point in the business requirement document based on the second prompt chain corresponding to each test point.
7. A test case generation device, characterized in that, include: The acquisition module is used to acquire business requirement documents and business scenario information; The extraction module is used to obtain business requirement information from the business requirement document; The recall module is used to perform multi-way recall in the knowledge base based on the business requirement information and the business scenario information, and to re-rank the recall results. The knowledge base stores a knowledge graph indicating business entities, historical test cases, historical business documents, and their relationships. Each business entity carries attribute information, including a marked test point corresponding to the business entity and a tag indicating the business scenario corresponding to the marked test point. An enhanced context is generated based on the re-ranking results and the business requirement information. The first generation module is used to generate test points corresponding to the business requirement document based on the enhanced context. The second generation module is used to generate corresponding test cases based on each test point in the business requirements document.
8. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the generation method of test cases as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions, which, when executed by a processor, enable the method for generating test cases as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, It includes a computer program that, when at least a portion of the computer program is executed by a processor, enables the method for generating test cases as described in any one of claims 1 to 6.