Method, apparatus, device, medium, and program product for test case generation

Abstract

A method, apparatus, device, medium and program product for test case generation are provided. The method comprises: obtaining a first requirement document and a first code, the first requirement document describing a function of an application, and the first code being used to implement at least part of the function of the application; extracting first information from the first code, the first information indicating processing logic of the first code; updating the first requirement document based on the first information to obtain a second requirement document, the second requirement document including second information, the second information describing a part of the processing logic that is not described by the first requirement document; and generating a first test case based on the second requirement document, the first test case being used to test the application. In this way, the part of the code processing logic that is not described by the requirement can be supplemented to the requirement document, and the test case for testing the application can be generated accordingly, so that the test generation takes into account both the functional requirement and the code implementation details.

Description

Technical Field

[0001] The embodiments of this disclosure generally relate to the field of computers, and particularly to methods, apparatus, devices, media, and program products for generating test cases. Background Technology

[0002] With the development of computer technology, more and more applications are being developed to enrich people's lives. To improve application quality, some applications can be tested using test cases. However, in application testing, ensuring that the generated test cases fully reflect functional requirements and specific processing conditions in the code remains a challenge. Summary of the Invention

[0003] In a first aspect of this disclosure, a method for generating test cases is provided. The method includes: obtaining a first requirements document and first code, the first requirements document describing the functionality of an application, and the first code for implementing at least a portion of the functionality of the application; extracting first information from the first code, the first information indicating the processing logic of the first code; updating the first requirements document based on the first information to obtain a second requirements document, the second requirements document including second information describing portions of the processing logic not described by the first requirements document; and generating a first test case based on the second requirements document, the first test case being used to test the application.

[0004] In a second aspect of this disclosure, an apparatus for generating test cases is provided. The apparatus includes: an acquisition module configured to acquire a first requirements document and first code, the first requirements document describing the functionality of an application, and the first code for implementing at least a portion of the functionality of the application; an extraction module configured to extract first information from the first code, the first information indicating the processing logic of the first code; an update module configured to update the first requirements document based on the first information to obtain a second requirements document, the second requirements document including second information describing a portion of the processing logic not described by the first requirements document; and a generation module configured to generate first test cases based on the second requirements document, the first test cases being used to test the application.

[0005] In a third aspect of this disclosure, an electronic device is provided. The device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the electronic device to perform the method of the first aspect.

[0006] In a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, the computer program being executable by a processor to implement the method of the first aspect.

[0007] In a fifth aspect of this disclosure, a computer program product is provided. The computer program product is tangibly stored in a computer storage medium and includes computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect.

[0008] In this way, parts of the code processing logic that are not described in the requirements can be added to the requirements document, and test cases can be generated for testing the application based on them, so that test generation takes into account both functional requirements and code implementation details.

[0009] It should be understood that the content described in this content section is not intended to limit the key or essential features of the examples in this disclosure, nor is it intended to restrict the scope of the solution. Other features will become readily apparent from the following description. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the various examples in this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1 A schematic diagram of the example environment is shown; Figure 2 A flowchart illustrating a test case generation method according to some embodiments is shown; Figure 3 A flowchart illustrating the required alignment and enhancement process according to some embodiments is shown; Figure 4 A block diagram of a test case generation apparatus according to some embodiments is shown; and Figure 5 A block diagram of an electronic device capable of implementing multiple embodiments is shown. Detailed Implementation

[0011] Examples of this disclosure will now be described in more detail with reference to the accompanying drawings. While some examples of this disclosure are shown in the drawings, it should be understood that solutions can be implemented in various forms and should not be construed as limited to the examples set forth herein. Rather, these examples are provided to provide a more thorough and complete understanding of the solutions. It should be understood that the drawings and examples in this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the solutions.

[0012] It should be noted that the headings of any section / subsection provided in this disclosure are not limiting. This disclosure describes a variety of examples throughout, and examples of any type may be included under any section / subsection. Furthermore, examples described in any section / subsection may be combined in any way with any other examples described in the same section / subsection and / or different sections / subsections.

[0013] In the description of examples in this disclosure, the term "comprising" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an example" or "the example" should be understood as "at least one example". The term "some examples" should be understood as "at least some examples". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0014] The examples in this disclosure may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and provisions. In the examples of this disclosure, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means in accordance with relevant laws and regulations. The specific methods of notification and / or authorization can vary depending on the actual situation and application scenario, and the scope of the solution is not limited in this regard.

[0015] In this manual and the sample solutions, any processing of personal information will be conducted only under legal grounds (such as obtaining the consent of the data subject or being necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0016] As used in this disclosure, the term "requirements document" refers to an information carrier that describes the functions that an application needs to implement and their expected behavior. A requirements document may include functional specifications, input / output requirements, parameter value conditions, and exception handling requirements, and may also include relevant content from the interface document. The first requirements document is the requirements document used in this round of updates, and the second requirements document is the requirements document obtained after updating the code information.

[0017] As used in this disclosure, the term "code" refers to program content used to implement at least part of the functionality of the application. The first code corresponds to the code analyzed in this round, and the second code corresponds to the code in earlier versions of the application. Code may include function definitions, parameters, conditional expressions, control flow, data dependencies, function calls, and exception handling statements.

[0018] As used in this disclosure, the term "processing logic" refers to the rules and execution relationships by which code processes input and produces corresponding results. Processing logic may include parameter validation, execution branches, call relationships, and exception handling. The first piece of information is information indicating the processing logic, which may take the form of a structured code description.

[0019] As used in this disclosure, the term "second information" refers to information obtained from code processing logic that describes code behavior not yet described in the first requirements document. Second information may include natural language descriptions of parameter ranges, boundary conditions, exception triggering conditions, and corresponding processing results. Second information can supplement missing information or enable existing descriptions to reflect implementation details not yet expressed in those descriptions.

[0020] As used in this disclosure, the term "test case" refers to information used to test the functionality or processing behavior of an application. A test case may include input data and the application's expected results in response to that input data, and may also include a test case identifier, test type, prerequisite states, and associated requirement identifiers. The first test case is the test case generated in this round, and the fourth test case is a supplementary test case generated for requirements that are not yet covered.

[0021] As used in this disclosure, the term "requirement entry" refers to a functional description unit in a requirements document that can be identified and compared. A requirement entry may describe a function, or it may describe the parameters, conditions, or exception handling of that function. Requirement identifiers are used to identify corresponding entries among documents, version comparison results, and test cases; changes to the content of an entry do not necessarily result in changes to its identifier.

[0022] As used in this disclosure, the term "first part" refers to the section in the first requirements document that describes the functionality corresponding to the code processing logic. This part can be a specific functional item, or it can be the content under that functional item that records parameter conditions or exception scenarios. The determination of the first part is used to establish the correspondence between code information and the location of requirement updates.

[0023] As used in this disclosure, the term "first condition" refers to a condition that limits the range of values ​​for code input parameters. This condition may involve a numerical range, string length, format, or allowed values. The second condition is a condition used to trigger an exception branch in the code, and the first response indicates to the application the result of processing that exception branch.

[0024] As used in this disclosure, the term "first score" refers to an evaluation result characterizing the degree of consistency between the functional description of the requirement and the code processing logic. The first threshold is a comparison threshold that determines whether to trigger a requirement update. This evaluation may reflect requirement omissions, boundary differences, missing anomaly descriptions, or other semantic differences, and may be accompanied by item-by-item explanatory information.

[0025] As used in this disclosure, the term "analysis scope" refers to the set of functions from which code information needs to be extracted in this round. The first function is the function identified as having changed during code version comparison, and the second function is a candidate function that directly or indirectly calls the first function. The analysis scope includes the first function and may include the second function identified according to the impact of the calls.

[0026] As used in this disclosure, the term "call distance" refers to the number of call levels traversed from the candidate calling function to the changed function along the function call relationship. The attenuation coefficient is a parameter that adjusts how the degree of influence decreases as the call distance increases. The second threshold is the influence threshold that determines whether a candidate function is included in the analysis.

[0027] As used in this disclosure, the term "Abstract Syntax Tree" (AST) refers to a data structure that represents the syntactic components of code and their relationships in a tree structure. Tree nodes can represent parameters, conditional expressions, call statements, or exception handling statements. While the AST provides the syntactic structure of the code, the functional semantics of the code can still be analyzed in conjunction with the code context.

[0028] As used in this disclosure, the term "first model" refers to the model used to analyze the code processing logic. The second model is the model used to generate test cases. The first and second models can be distinguished by different processing tasks and input content, and the specific deployment location and implementation form of the models can be set according to application needs.

[0029] As used in this disclosure, the term "generative model" refers to a machine learning model capable of processing and generating language content based on input context. This model can be used for requirements analysis, code semantic analysis, requirements-code comparison, and test case generation. Generative models for code analysis (hereinafter referred to as "models") can utilize code and syntactic structure to generate structured descriptions containing functional meaning.

[0030] As used in this disclosure, the term "hint" refers to input information provided by the model, such as task requirements, context, and processing objects. Hints may include the analysis task to be performed, the required output fields, and task-related requirements and code snippets. The value requirements and output structure in the hints can help the model generate results that can be used for subsequent processing.

[0031] As used in this disclosure, the term "requirement variance" refers to changes in entries between different requirement documents. The first variance records additions, modifications, or deletions between earlier versions of the requirement and the current round of updated requirements. The second variance records all new entries in the initially created requirement document relative to an empty document.

[0032] As used in this disclosure, the term "second test case" refers to the test case in the existing test case library corresponding to the modified requirement item. The third test case is an existing test case corresponding to the deleted requirement item. The first suggestion is used to indicate updating the input data or expected result of the second test case, and the second suggestion is used to indicate discarding the third test case.

[0033] As used in this disclosure, the term "coverage" refers to the proportion of new or modified requirement items that need to be tested in this round that have been covered by generated test cases. The third threshold is a coverage threshold used to determine whether to continue generating test cases. This coverage is statistically correlated with requirement identifiers and is distinguished from the actual runtime coverage of lines of code or execution branches.

[0034] As used in this disclosure, the term "third information" refers to a functional description that is documented in the first requirements document but not yet implemented in the first code. The third information is retained in the second requirements document and can continue to be used to generate test cases. The third information has a different source from the second information supplemented according to the code.

[0035] As used in this disclosure, the term "original requirements document" refers to the initial functional description provided by the requester, which may not fully document the boundaries and exception handling in the code. An enhanced requirements document refers to a structured requirements document supplemented with code information. The current enhanced requirements document is the version that has been saved and used as the baseline for this round; the new version of the enhanced requirements document is the result of this round's update.

[0036] As used in this disclosure, the term "code change" refers to changes in the current code relative to a previous version. Code changes can be identified through version history and version differences, and can be organized as change files, functions, code locations, and corresponding content. Enhancement requirements documents can store their corresponding code version information to clarify the code benchmark used for the next round of comparisons.

[0037] As mentioned above, with the development of computer technology, more and more applications are being developed to enrich people's lives. To improve application quality, some applications can be tested using test cases. However, in application testing, ensuring that the generated test cases fully reflect functional requirements and specific processing conditions in the code remains a challenge.

[0038] A test case generation scheme is proposed. The scheme includes: obtaining a first requirements document and first code, wherein the first requirements document describes the functionality of the application, and the first code is used to implement at least some of the functionality of the application; extracting first information from the first code, wherein the first information indicates the processing logic of the first code; updating the first requirements document based on the first information to obtain a second requirements document, wherein the second requirements document includes second information, wherein the second information describes the parts of the processing logic not described by the first requirements document; and generating a first test case based on the second requirements document, wherein the first test case is used to test the application.

[0039] Through the above approach, the functional description of the requirements can be linked to the specific processing rules in the code, thus providing more comprehensive functional and implementation basis for test generation. Code information is first converted into identifiable content in the requirements, and then used to determine test inputs and expected results, thereby reducing test generation deviations caused by missing code processing conditions.

[0040] In this way, parts of the code processing logic that are not described in the requirements can be added to the requirements document, and test cases can be generated for testing the application based on them, so that test generation takes into account both functional requirements and code implementation details.

[0041] The various embodiments of this solution will be described in further detail below with reference to the accompanying drawings.

[0042] Figure 1 A schematic diagram of example environment 100 is shown. (e.g.) Figure 1 As shown, example environment 100 may include electronic device 110.

[0043] In this example environment 100, electronic device 110 can run an application 120 that supports test case generation. Application 120 can be any suitable type of application for test case generation, including but not limited to: test case generation tools, regression test maintenance tools, or other suitable applications. User 140 can interact with application 120 via electronic device 110 and / or its attached devices.

[0044] exist Figure 1 In environment 100, if application 120 is active, electronic device 110 can use application 120 to present interface 150 for supporting test case generation.

[0045] In some embodiments, electronic device 110 communicates with server 130 to provide services to application 120. For example... Figure 1 As shown, the requirements document library 160 can store original requirements and enhanced requirements for each version. The code repository 170 can store application code and its version history. The test case library 180 can store generated test cases and corresponding requirement identifiers. The electronic device 110 obtains the documents, code, and existing test cases required for this round of processing from these data sources, and can write the updated results back to the corresponding data sources.

[0046] Electronic device 110 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, handheld computers, portable gaming terminals, virtual reality (VR) / augmented reality (AR) devices, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, electronic device 110 may also support any type of user-facing interface (such as "wearable" circuitry).

[0047] Server 130 can be a single physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and artificial intelligence platforms. Server 130 may include, for example, computing systems / servers such as mainframes, edge computing nodes, computing devices in a cloud environment, etc. Server 130 can provide background services for application 120 in electronic device 110 that supports test case generation. In some embodiments, application 120 may include functional components such as a requirement feature extractor, change tracking analyzer, code feature extractor, requirement code alignment scorer, and requirement enhancer. Application 120 may also include a requirement version comparator, test case generator, requirement coverage verifier, and test case expiration detector. The following describes the collaboration of these components using examples of electronic device 110 performing various processes.

[0048] A communication connection can be established between server 130 and electronic device 110. This communication connection can be established via wired or wireless means. The communication connection can include, but is not limited to, Bluetooth, mobile network, Universal Serial Bus (USB), and Wireless Fidelity (WiFi) connections. In some embodiments, server 130 and electronic device 110 can interact via this communication connection.

[0049] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of the scheme.

[0050] Figure 2 A flowchart of an example process 200 generated according to some embodiments is shown. Process 200 can be implemented at electronic device 110. Figure 2 Boxes 210 to 240 in the diagram represent input acquisition, code information extraction, requirement update, and test case generation, respectively. The specific data processing steps are explained below.

[0051] like Figure 2 As shown in box 210, electronic device 110 acquires a first requirements document and first code. The first requirements document describes the functionality of the application, and the first code is used to implement at least some of the functionality of the application. Electronic device 110 can read requirements content from requirements document library 160 and read selected versions of code and version information from code repository 170.

[0052] It should be noted that, Figure 1 The test case generation application 120 shown is the application that performs the generation process, while the application described in the first requirements document is the application to be tested, which the test cases target. They serve different purposes. The first code is used to implement at least some of the functionality of the application to be tested, and does not necessarily have to be the code of the test case generation application 120 itself.

[0053] In some embodiments, the first requirement document used for the initial run is the original requirement document. For ease of understanding, this document uses the example of the original requirement documenting the input type for the login function and the behavior of redirecting to the homepage after successful verification. As an example, the original requirement may not specify input length, format validation, and failure handling rules. The electronic device 110 obtains the code that implements the login function as the first code for subsequently extracting processing logic.

[0054] In some embodiments, the first requirements document used for version iteration can be a previously saved enhanced requirements document. The electronic device 110 can retrieve the earlier version code based on the code commit identifier recorded in the document and use the newly committed code as the first code. This maintains a correspondence between the requirements baseline and the code baseline, avoiding the mixing and comparison of requirements and code from different historical stages.

[0055] Electronic device 110 can receive original requirements upon first application access or when requirements change. For runs triggered solely by code version changes, saved enhanced requirements can be reused as input. User 140 can provide input of requirements and code via interface 150 and obtain the generated results through that interface.

[0056] In some embodiments, the electronic device 110 can parse natural language requirements into structured function points using a requirement feature extractor. This process can use a generative model (hereinafter referred to as the model) to extract function names, inputs, function descriptions, and expected behaviors, and save explicitly stated conditions and exception handling separately. For locations where corresponding content is not yet recorded, an empty set of conditions or exceptions can be saved.

[0057] In some embodiments, the model can be invoked and executed at electronic device 110. Additionally, electronic device 110 can send requirements, code snippets, and prompts related to the corresponding task via a communication connection with server 130. After server 130 completes model processing and returns structured results, electronic device 110 continues with requirements writing, version management, or use case association processing.

[0058] Requirements analysis can be performed in parallel with code change analysis and code feature extraction. For version iterations, electronic device 110 can also read saved enhancement requirements while extracting code information. Alignment comparison is performed only after both sides of the results are prepared, thus maintaining data dependencies and reducing serial waiting. When performing requirements analysis, the model can also combine long contexts and implicit logic in the documents to determine the semantic relationships between functional units.

[0059] For example, parsing the login requirement above yields a login function entry. This entry's input includes a login identifier and a verification string, and the expected behavior is redirection to the homepage upon successful verification. Since the original requirement did not describe length conditions and failure lockout rules, corresponding conditions and exception fields do not yet have entries. These gaps provide identifiable documentation locations for subsequent comparison with code information.

[0060] In this way, the functional meaning in the original requirements can be transformed into data objects that can be read by subsequent processing. Structured functional points and stable requirement identifiers also enable code comparison, content writing, and use case association to use the same positioning criteria, thereby reducing the need to repeatedly parse natural language documents at different processing stages.

[0061] In box 220, electronic device 110 extracts first information from first code. The first information indicates the processing logic of the first code, which may include function definitions, parameter ranges, control flow, data dependencies, function calls, and exception handling.

[0062] In some embodiments, the electronic device 110 can compare a first code and a second code to determine a first function in the first code that has been modified. The second code is code applied in a prior version. The electronic device 110 further determines an analysis scope based on the first function and the call relationships in the first code, and extracts first information from functions within that scope. This analysis scope includes the first function itself.

[0063] Specifically, electronic device 110 can use version difference information to determine the locations of changed files and code, and map these locations to functions based on function definition ranges. Then, it can use static call relationships to trace other functions that directly or indirectly call the changed function, forming candidate analysis objects. The obtained ranges can record the function identifier, the file it belongs to, the call distance, and the degree of impact.

[0064] For example, the previous version of the code limited the login identifier length to 6 to 20 characters, while the current version changes this range to 8 to 30 characters. Electronic device 110 can identify the login function containing the length verification as the first function. If there are no other functions in the call relationship that need to be included in the analysis, the analysis scope can include only the login function. When there is no historical code baseline on the first run, functions in the acquired code can also be used as the extraction objects for this round.

[0065] In this way, this round of requirement enhancement can focus on actual code changes and their impact, thereby reducing the computational overhead caused by redundant analysis.

[0066] In some embodiments, the electronic device 110 can determine the call distance between a second function and a first function. The second function directly or indirectly calls the first function. Based on the call distance and an attenuation coefficient, the electronic device 110 determines the degree to which the second function is affected by changes to the first function, and includes the second function in the analysis if the degree is not lower than a second threshold. The degree of influence decreases as the call distance increases.

[0067] For a specific implementation, the direct impact of the changed function can be set to 1, and the impact of the candidate function can be determined by applying a decay effect for each call level. Let Indicates the degree of influence of the candidate function. This represents the attenuation coefficient that affects propagation. This represents the call distance from the candidate function to the changed function along the call relationship. The corresponding calculation can be expressed as the following formula (1): Formula (1) in, The value is a non-negative integer, and the distance corresponding to the change function itself is 0. The attenuation coefficient can be set within the parameter range of 0 to 1, for example, 0.1. In implementations that require the influence to decrease progressively with distance, a coefficient greater than 0 and less than 1 can be selected; a value of 0 means no distance attenuation, and a value of 1 means the influence of the positive distance function is 0. The change function itself is still treated as having an initial influence of 1.

[0068] For example, in an implementation with a decay coefficient of 0.1, the influence level corresponding to a candidate function that directly calls the change function can be 0.9. When there are two call levels in between, the influence level can be 0.81. The electronic device 110 compares the calculation result with a second threshold to determine whether the candidate function enters the analysis range. The second threshold can be configured according to application needs and is not restricted in this respect.

[0069] Electronic device 110 can start by modifying a function and process its callers layer by layer along the call relationship. If the same function is reached through multiple paths, the path with the greater impact can be retained and propagated as its impact improves. Processed objects and their corresponding impact can be used to avoid repeatedly processing the same result. For multiple call paths to the same function, this is equivalent to prioritizing the path with the stronger impact on that function.

[0070] In this way, the scope of analysis can reflect the differences in how different functions in the call chain are affected by the change. Remote callers that are less affected do not need to be processed indiscriminately in subsequent models, thereby reducing unnecessary function parsing and input data transfer, and mitigating large-scale redundant analysis caused by small-scale changes.

[0071] In some embodiments, the electronic device 110 can perform syntactic analysis on the first code to obtain an abstract syntax tree representing its syntactic structure. The electronic device 110 uses a first model to process the first code and the abstract syntax tree to obtain first information. The first model is used to analyze the processing logic of the code, and this method can be used for all code or code segments within the aforementioned analysis scope.

[0072] In its implementation, electronic device 110 can read parameter names and types, conditional expressions, exception statements, and function calls from the abstract syntax tree. Electronic device 110 provides the code snippets and this structured information to the first model, while specifying the parameter conditions to be extracted, exception triggering reasons, and functional semantics in the prompts. The prompts can also limit the output fields and require that the results be based on the actual processing present in the code.

[0073] For example, the syntax node for length validation can provide upper and lower bounds of 6 and 20, along with the corresponding comparison relationships. An exception statement can indicate that a parameter validation error is returned when the length exceeds the bounds. The first model combines these syntax elements with the login function context to form code descriptions for "login identifier length is 6 to 20 characters" and "a validation error is generated when the length does not meet this range." This simultaneously preserves numerical boundaries and the relationship between conditions and results.

[0074] For format validation of the validation string, the first piece of information can record that it must contain both letters and numbers. For a failed lock branch, the first piece of information can record that locking is triggered when the failure count reaches 3 and the lock duration is 10 minutes. For a validation mismatch branch, the first piece of information can record the error response and failure count update. The corresponding control sequence can also be saved as part of the first piece of information.

[0075] It's important to note that the timing of the exception should be determined based on its execution location within the specific code. For example, if the code first checks the cumulative number of failures, then performs the current verification and updates the count, the check conditions and the count update action should be extracted separately. It cannot be assumed that the error response necessarily occurred in the same request on the third failure simply because the count threshold is 3. Testing with a pre-failure state that has already reached the count threshold can clearly verify the behavior of the locking branch itself.

[0076] In this way, the syntactic structure provides locatable parameters, conditions, and exception criteria, while the model processing further provides semantics corresponding to the functional description. The combination of these two approaches improves the interpretability of code information extraction and reduces boundary or exception relationship errors caused by inferring processing logic solely from text fragments.

[0077] In box 230, electronic device 110 updates the first requirement document based on the first information to obtain a second requirement document. The second requirement document includes second information, which describes the parts of the processing logic of the first code that are not described in the first requirement document. Electronic device 110 can convert the code information into a natural language description and write it into the functional part corresponding to the processing logic.

[0078] For example, the original login requirement only states that the user will be redirected to the homepage after successful verification, while the first piece of information also includes the length range, format conditions, and failure lockout rules. Electronic device 110 can add corresponding conditions and exception descriptions under the login function item to form the first version of the enhanced requirements. Existing function descriptions are retained, and the processing not yet expressed in the requirements in the code becomes the basis for new testing.

[0079] In some embodiments, the electronic device 110 may first compare the consistency between the requirements and the code, and then update the content that needs to be enhanced. For specific document location, scoring comparison, natural language conversion, and version saving, please refer to the following... Figure 3 Example description.

[0080] In box 240, electronic device 110 generates a first test case based on the second requirements document. The first test case is used to test the application. The second requirements document provides the functional objectives and updated processing requirements, which electronic device 110 can use to construct test inputs and corresponding expected results, and associate the generated test cases with the corresponding requirements items.

[0081] For example, if the second requirements document states that the login identifier length is 6 to 20 characters, boundary inputs with lengths of 6 and 20 can be generated, and out-of-bounds inputs with lengths of 5 and 21 can be generated. For use cases that only verify the length condition, the expected results are length validation passing and length validation error, respectively. If the expected result is further set to login success, other validation conditions, validation data, and prerequisite states must also meet the corresponding requirements simultaneously.

[0082] In this way, the application's functional descriptions can participate in the formation of test criteria along with the code implementation details. Length, format, and exception conditions are organized into associative requirement content, enabling test generation to cover implementation behaviors not explicitly stated in the original requirements. This process can reduce generated results that do not match the boundaries of test input and actual processing, and enhance the traceability of test expectations.

[0083] In some embodiments, the first requirements document is the original requirements document. In response to the absence of a historical requirements document for the application, the electronic device 110 compares the second requirements document with the empty document to obtain a second difference. The second difference records the requirements entries in the second requirements document as new entries, and the electronic device 110 generates a first test case based on these new entries.

[0084] For newly formed enhanced requirements, electronic device 110 can record login functionality, length conditions, format conditions, and lockout exceptions as new entries. Then, it generates a full set of test cases based on these entries, and saves the requirement version and generated test cases to the requirement document library 160 and test case library 180, respectively.

[0085] In this way, the initial generation can use the same requirement difference handling mechanism as subsequent incremental generation. An empty baseline allows all requirement items to be added to the new set, avoiding the need to maintain a separate set of full generation rules unrelated to version differences, thereby reducing redundant processing logic in the process implementation.

[0086] In some embodiments, the first requirements document is obtained based on the code of an earlier version of the application. Electronic device 110 compares the first requirements document and the second requirements document to obtain a first difference. The first difference records the changed requirements items and their change types. Based on the newly added or modified requirements items indicated by the first difference and the first information, electronic device 110 generates a first test case.

[0087] For example, the saved enhanced requirement version 1 records a length range of 6 to 20 characters. After the code change, the enhanced requirement version 2 obtained by electronic device 110 updates this range to 8 to 30 characters. Electronic device 110 compares the two requirement versions and records the length condition as a modification entry. If the format validation and locking processes remain unchanged, they do not need to be included in the test objects for this round of additions or modifications.

[0088] This approach allows requirement differences to define the scope of requirements addressed in this round of generation, while providing a basis for code descriptions to support test data and expected results. Compared to repeatedly generating test cases for the entire requirements document, generating incremental test cases for new and modified content reduces redundant model calls and the need to save duplicate test case data.

[0089] In some embodiments, the first and second requirement documents organize requirement entries in a tree structure. Electronic device 110 matches entries in the two documents according to requirement entry identifiers. In response to differences in the content of the matched entries, electronic device 110 records the corresponding requirement identifier and the content before and after modification in a first difference record.

[0090] For example, a function item can be a parent node, length and format conditions can be conditional child nodes under that node, and locking can be an exception child node. Electronic device 110 recursively traverses the function point tree and builds an index based on the identifiers of function, condition, and exception items. Even when the order of items changes within the document, the comparison object can still be determined based on the same identifier.

[0091] For identifiers that only exist in the new version, electronic device 110 records the addition type and added content. For identifiers that only exist in the old version, it can record the deletion type and removed content. For identifiers that exist in both versions and have different content, it records the modification type, old content, and new content. Entries with identical content do not need to be included in the requirement difference section.

[0092] In the length example above, the length condition uses the same requirement identifier in both versions. The first difference record shows that the old content corresponding to this identifier is "Login identifier length is 6 to 20 characters," and the new content is "Login identifier length is 8 to 30 characters." The difference record can also include the base version, target version, and first-run identifier to facilitate subsequent processing in distinguishing between full additions and version changes.

[0093] In this way, requirement comparison establishes object correspondences using stable identifiers, avoiding the mistaken modification of the same requirement for different requirements. The tree structure and identifier index also support recursive comparison of structured entries without requiring a complete natural language semantic reasoning to be performed for each version comparison.

[0094] In some embodiments, the electronic device 110 constructs a prompt based on the change type indicated by the first difference and the content of the requirement item before and after modification. The prompt also includes a code snippet in the first code corresponding to the requirement item. The electronic device 110 processes the prompt using a second model to generate a first test case that includes input data and the expected results of the application for the input data.

[0095] For new entries, the prompt can request the generation of use cases for normal, boundary, and abnormal scenarios based on the entry's content. For modified entries, the prompt can request attention to the differences between the old and new content, and coverage of changed boundaries and adjacent out-of-bounds inputs. For deleted entries, instead of generating new use cases for that entry, the deletion is handled by the applicability processing of existing use cases.

[0096] For example, in the implementation of the corresponding scenario, one normal test case, one boundary test case, and one abnormal test case can be generated for each new requirement. For requirements with multiple range endpoints or multiple abnormal conditions, multiple test cases can also be generated according to the specific conditions. The scenario and number of each test case correspond to the actual test conditions included in the requirement.

[0097] Electronic device 110 can directly reuse the first information extracted from box 220 and combine it with relevant code snippets to construct prompts. The prompts can specify that each use case includes a use case identifier, associated requirement identifier, type, input data, and expected result. The second model forms a structured output based on these fields for subsequent coverage checks and use case update processing.

[0098] For the requirement to adjust the length range from 6 to 20 to 8 to 30, the prompt can explicitly indicate the change type as "modification" and simultaneously provide length descriptions for both versions, as well as length validation snippets from the new code. The generated incremental test cases can respectively verify the boundaries of lengths 8 and 30, and out-of-bounds behavior for lengths 7 and 31. Therefore, electronic device 110 can construct input using test strings conforming to the indicated lengths, ensuring that other conditions such as format, validation status, and failure count do not obstruct the path to the test. This allows input to be constructed based on actual length values, avoiding inconsistencies between the text length of the example string and the length recorded in the test case.

[0099] In some embodiments, the electronic device 110 can use a test diversity coefficient to adjust the temperature parameters or input variation requirements in the prompts during model generation. This coefficient can be configured between 0 and 1.

[0100] In this way, the model can simultaneously obtain both the changes in requirements and the code basis for implementing those changes, making the generated use cases clearly reflect the correspondence between inputs and expected results. Reusing extracted code descriptions can also reduce repetitive semantic extraction and narrow the context scope of the model's current processing round.

[0101] In some embodiments, electronic device 110 retrieves a second test case from an existing test case library based on a first difference. The second test case corresponds to the modified requirement entry indicated by the first difference. Electronic device 110 provides a first suggestion, instructing the input data or expected result of the second test case to be updated according to the modified entry.

[0102] Specifically, electronic device 110 can retrieve test case library 180 based on the requirement identifier of the modified item to obtain existing test cases covering the item. For changes in length boundaries, test cases originally using lengths of 6 and 5 can be adjusted to lengths of 8 and 7 respectively, and test cases originally using lengths of 20 and 21 can be adjusted to lengths of 30 and 31 respectively. Corresponding suggestions can be provided to user 140 through interface 150.

[0103] It's important to note that a change in the requirements corresponding to a use case does not necessarily mean that the expected result for each specific input will be reversed. For example, a length of 20 may still pass length validation within the new range of 8 to 30, but it no longer represents the upper boundary. A length of 21, on the other hand, changes from being an out-of-bounds value to a value within the range. Therefore, update suggestions can be made by adjusting the inputs, boundary testing objectives, or expected results of the use cases to correspond to the new requirements.

[0104] In this way, existing use cases can be located and maintained along their associated requirements, reducing the work of manually searching for the impact of changes one by one. Update prompts also preserve the relationship between old use cases and new requirements, which can reduce misjudgments of test results due to the continued use of failure boundary conditions.

[0105] In some embodiments, electronic device 110 retrieves a third test case from an existing test case library based on a first difference. The third test case corresponds to a deleted requirement entry indicated by the first difference. Electronic device 110 provides a second suggestion indicating that the third test case should be discarded. This process can be implemented separately from providing update suggestions for requirement modifications.

[0106] For example, if a requirement that originally described additional formatting conditions for code is removed in the new version of the document, electronic device 110 can locate existing formatting test cases based on the entry's identifier and include them in the obsolescence recommendation. This is based on the requirement version comparison confirming that the entry has been removed. Simply because the current code does not implement an existing requirement does not automatically make that requirement and its test cases worthy of removal.

[0107] For existing use cases not affected by the first difference, electronic device 110 can retain their original state. The processing results can be recorded separately for newly added use cases, use cases requiring updates or replacements, use cases recommended for obsolescence, and unaffected use cases. Use case expiration detection can retrieve existing use cases before generating new use cases, or it can establish replacement relationships based on generated and verified use cases.

[0108] Additionally, the use case expiration detector can receive the code change scope output by the change tracing analyzer and read the corresponding version from the requirements document library. This scope helps determine the association between requirements and use cases that need attention; specific update or obsolescence recommendations are still formed based on the items and change types in the requirements differences. When the existing use case library is empty on the first run, all validated use cases can be recorded as new additions.

[0109] In this way, the states of deleted requirements and unimplemented requirements can be distinguished. Providing suggestions for discarding test cases for deleted requirements can reduce the continued use of invalid tests and prevent the accidental removal of test data corresponding to unimplemented features.

[0110] In some embodiments, the electronic device 110 determines the requirement items that need to be tested based on a first difference; these items are newly added or modified requirement items. The electronic device 110 determines coverage according to the requirement identifier associated with the first test case. This coverage is the proportion of the number of items to be tested that have been covered by the first test case to the total number of items to be tested. In response to a coverage level below a third threshold, the electronic device 110 generates fourth test cases for the uncovered items.

[0111] make This indicates the number of new or modified requirements that need to be tested in this round. This indicates the number of different requirement items that have been associated with the generated use cases. This indicates the coverage of requirement items. When the value is greater than 0, it can be calculated using the following formula (2): Formula (2) For multiple use cases corresponding to the same requirement identifier, electronic device 110 removes duplicates of that identifier when calculating the number of covered items. If no new or modified items are added in this round, a result can be generated directly without the need to generate new use cases.

[0112] For example, the items to be tested during the initial generation include login functionality, length conditions, format conditions, and locking exceptions, totaling four items. If the generated test cases are already associated with these four requirement identifiers, the coverage is 1. If the locking exception items are not covered, the coverage is 0.75. Electronic device 110 can use 0.95 as a third threshold to feed back the missing locking exception items and their input conditions to the second model and generate the corresponding fourth test cases.

[0113] After the supplementary generation, electronic device 110 can include the newly added use cases in the current round of results and then check the coverage according to the requirement identifier. Results are output when the coverage reaches the third threshold; if the coverage is still below the third threshold, it can continue to provide feedback on the uncovered items. This feedback focuses on missing requirements and does not require regenerating all items already associated with use cases.

[0114] In the length range change example, the set added or modified in this round can contain only one item: the length condition. Although the four boundary test cases are associated with the same requirement identifier, the number of covered items is still 1. This ratio indicates that the requirement item has been associated with the test case, but it does not alone prove that all lines of code or execution paths have been actually executed. Whether the boundary inputs and expected results are correct still needs to be verified against the requirements and code conditions.

[0115] In this way, the test results can provide computationally complete feedback on changes in requirements in this round. Missing entries are provided to the model in a targeted manner, which can fill in the missing functional scenarios and reduce the inference and storage overhead caused by repeatedly generating covered content.

[0116] In some embodiments, the second requirements document also retains third information. This third information comes from the first requirements document and describes functionality that has not yet been implemented in the first code. The electronic device 110 generates first test cases based on this third information, ensuring that requirements not yet implemented in the code still have corresponding test entry points.

[0117] For example, a requirement might describe a 10-minute lockout when the failure count reaches 3, but the current code doesn't yet include a corresponding branch. Electronic device 110 can retain this requirement and generate a test case based on the previous failure count reaching the threshold. The expected result of this test case comes from the retained requirement description and is not rewritten to mean that locking is unnecessary simply because the current code doesn't produce a locking result.

[0118] In this way, the scope of testing can include both implementation details supplemented by code and existing functionality that has not yet been implemented. Retaining information from these two different sources reduces the likelihood of mistaking missing code behavior for correct expectations and enhances the ability to identify incomplete application functionality.

[0119] In the length change example above, the initial run generates 8 sample test cases, including 1 normal login test case, 4 length boundary test cases, 2 format exception test cases, and 1 lock exception test case. Version iterations can generate 4 new boundary test cases for the length condition and recommend updating 4 old boundary test cases. The 4 test cases unrelated to this change can be retained.

[0120] If, based on the update recommendations, four new boundary use cases replace corresponding old use cases, the updated complete use case set can contain four new boundary use cases and four retained use cases, for a total of eight use cases. The newly added set, replacement relationships, and the final valid use case set belong to different record objects; the replaced old use cases should not be counted again in the valid results. Electronic device 110 can simultaneously output new enhanced requirements, incremental use case sets, and update or obsolescence recommendations.

[0121] In some embodiments, requirements parsing, code semantic analysis, alignment interpretation, requirements enhancement, and test generation can be achieved through different task cues from the model. The corresponding processing can leverage existing model capabilities without requiring the preparation of large amounts of requirements, code, and use case pairing data for each new application. The content upon which the model generation is based can still come from the current input and saved versions, reducing the need to reorganize dedicated training data for application migration.

[0122] In model implementations supporting the corresponding programming languages ​​and functional domains, new applications can proceed with the above processing after providing requirements documents and code, without needing to prepare requirement, code, and test case triples for special fine-tuning. When migrating to other supported programming languages ​​or functional domains, the prompt-driven processing method can be reused without retraining the model. This reduces the overhead of organizing, storing, and processing dedicated training samples.

[0123] In some embodiments, the entries returned when coverage is insufficient, along with corresponding adjustment prompts, can be reused in subsequent build tasks. This preserves application-specific build requirements and provides context when processing similar requirements later. This process leverages the relationship between requirements, build results, and missing feedback to improve subsequent builds without requiring changes to already defined requirements to meet coverage statistics.

[0124] In this way, the functional description of the requirements can be linked to the specific processing rules in the code, thus providing more comprehensive functional and implementation basis for test generation. The code information is first converted into identifiable content in the requirements, and then used to determine the test input and expected results, thereby reducing test generation deviations caused by missing code processing conditions.

[0125] In this way, parts of the code processing logic that are not described in the requirements can be added to the requirements document, and test cases can be generated for testing the application based on them, so that test generation takes into account both functional requirements and code implementation details.

[0126] Figure 3 A flowchart of an example process 300 for alignment and enhancement according to some embodiments is shown. Process 300 can be executed by electronic device 110 and used to implement... Figure 2 Frame 230. Figure 3 The first requirement document 301 and the first information 302 in the document correspond to the requirement input and the code information extracted in box 220, respectively, while the second requirement document 350 is the processing result of this round.

[0127] In box 310, electronic device 110 can determine a first part of the first requirements document 301 based on first information 302. This first part describes the function corresponding to the processing logic. Electronic device 110 can map the processing in the code to the required functional points according to the functional meaning, input parameters, and expected behavior, and determine the functional nodes where conditions or exception descriptions should be written.

[0128] For example, the login function corresponds to the login functionality in the first requirement document 301. Length conditions and validation string format conditions can be written into the condition set of this function node, while failure locking and validation exceptions can be written into its exception set. For functional behaviors that exist in the code but are not described in the requirements, corresponding functional descriptions can be formed based on the code semantics, and their positions in the function point tree can be determined.

[0129] In this way, the converted code information can be written to the location corresponding to its functional meaning. Requirement identifiers and functional nodes together provide the basis for location, reducing the error of mistakenly writing a code condition into another functional item.

[0130] In some embodiments, the electronic device 110 can also compare the functional description in the first requirements document 301 with the first information 302 to obtain a first score. The first score indicates the degree of consistency between the functional description and the processing logic. The comparison results can indicate whether the requirements describe the corresponding behavior, whether the code contains the corresponding implementation, and whether the two are consistent in terms of conditions and results.

[0131] Electronic device 110 can perform item-by-item comparisons using a requirement code alignment scorer and utilize the model to generate explanations corresponding to the differences. The aspects to be compared can include input range, format, normal behavior, and exception handling. Model hints can request item-by-item output of requirement documentation, code implementation details, consistency, and sources of code evidence to avoid simply providing an overall score that cannot be located.

[0132] In one implementation, the comparison aspects involved in the requirements or code can be formed into a comparison set, and the aspects that are included and consistent on both sides can be counted. Let... Indicates the quantity of consistent aspects. This indicates the total number of aspects in the comparison set. This indicates the first score in this implementation. When When the value is greater than 0, the ratio shown in formula (3) can be used: Formula (3) The aforementioned ratio represents a scoring implementation. Additionally, the electronic device 110 can utilize the model to perform semantic scoring on the item-by-item comparison results, generating an evaluation value between 0 and 1 along with explanatory information. The specific scoring method can be configured according to the application, and the threshold used should correspond to this scoring method. The lower the initial score, the more significant the difference between the requirements and the code that needs further processing.

[0133] In an example of item-by-item explanation, the requirement allows negative integer input while the code parameter validation only allows positive integers. The comparison result can indicate a difference in the range of values. When using a deduction method to form a score, this difference can be deducted by 0.15 for example, with the corresponding code basis provided. This explanation allows users to pinpoint the difference and formulate further processing suggestions, which can also serve as input for the next round of processing.

[0134] User 140 can determine adjustment requirements or code modifications based on the item-by-item explanation. Additionally, alignment scores, explanation reports, and coverage verification can be provided as independent inspection processes or implemented in conjunction with the aforementioned generation process. When used independently, each process still inputs and outputs scores, explanations, and missing items based on the corresponding requirements, code, and use cases; when used in conjunction, these results further participate in triggering requirement enhancements or supplementing use cases.

[0135] For example, in an implementation using semantic scoring, a score of 0.62 can be obtained when the original requirement does not specify length, format, or locking exceptions. A similar score of 0.60 can be obtained for a comparison where version 1's length requirement was 6 to 20, and the code has changed to 8 to 30. These figures illustrate examples of insufficient consistency and do not imply that the same counting ratio will necessarily be obtained based solely on the listed differences.

[0136] In box 320, electronic device 110 can determine whether a first score is lower than a first threshold to decide whether to trigger demand enhancement. The first threshold can be configured between 0 and 1, for example, set to 0.75. Electronic device 110 compares the first score with this threshold and selects the corresponding processing path based on the comparison result.

[0137] In response to a first score being lower than a first threshold, electronic device 110 updates the first requirement document 301 based on first information 302, resulting in a second requirement document 350. This update is performed along boxes 330 and 340. For example, if the score is 0.62 or 0.60 and the threshold is 0.75, the process of generating supplementary content based on code information can proceed. If the first score is not lower than the first threshold, process 300 retains the existing requirement document and proceeds to the output position corresponding to the second requirement document 350.

[0138] For versions that only change the code format without altering the corresponding processing meaning, a comparison between the requirements and the code indicates that the feature description does not need to be updated. In this case, the current requirement content can be used as the result of this round of version processing. If the requirement version comparison does not produce any new or modified items, then subsequent incremental test cases do not need to be generated. This path does not require forcibly constructing requirement updates for code changes that do not affect the requirements.

[0139] In this way, requirement enhancement can be conditionally performed based on the results of consistency comparisons, focusing updates on functionalities that need to be added or adjusted. For comparison results that do not require updates, redundant calculations caused by requirement generation, documentation writing, and test regeneration can be reduced.

[0140] In block 330, electronic device 110 forms second information based on code information to supplement or modify the function description. In some embodiments, electronic device 110 can obtain a first condition from first information 302. The first condition defines the value range of the first code input parameter. Electronic device 110 adds a natural language description of the condition to the first part, making it constitute the second information and retaining the corresponding boundary values.

[0141] For numerical or length ranges, the electronic device 110 can extract the upper and lower bounds and their comparison relationships, and then convert this content into natural language consistent with the functional description. For example, when the code allows login identifier lengths from 6 to 20 characters, it can write "Login identifier length is 6 to 20 characters, including two boundary values". This expression preserves the meaning of whether the endpoints are allowed, avoiding the mistaken writing of a range including boundaries as strictly greater than the lower bound or strictly less than the upper bound.

[0142] Additionally, input conditions can involve formatting or allowed values. For example, when validating a string that requires both letters and numbers, these two compositional requirements and the relationship between them can be written into the condition entry. For enumerated values ​​in the code, the set of allowed values ​​can be converted into the corresponding requirement description.

[0143] In the version iteration example, the length range given in the first message 302 changes to 8 to 30 characters. Electronic device 110 can update the original length description of 6 to 20 characters to 8 to 30 characters, while retaining the identifier of the requirement entry. Subsequent version comparisons can therefore identify this change as a modification of the same requirement, rather than an unrelated deletion or addition.

[0144] In this way, requirement entries can directly provide the numerical values ​​and range relationships needed to construct boundary test inputs. Keeping code boundaries consistent with natural language descriptions can reduce biases caused by re-inferring the meaning of endpoints during test generation.

[0145] In some embodiments, the electronic device 110 can obtain a second condition and a first response from the first information 302. The second condition is used to trigger an exception branch in the first code, and the first response indicates the result of the application executing the exception branch. The electronic device 110 adds the second information to the first part to describe the condition and its corresponding response.

[0146] For example, when the login identifier length is below the lower bound or above the upper bound, the second condition is that the length does not meet the allowed range, and the first response could be a parameter validation error. For handling missing letters or numbers in the validation string, the corresponding condition failure and format validation error can be described separately. For handling mismatched validation data, validation errors and an increase in the failure count can be described.

[0147] Additionally, when the failure count reaches 3 and the corresponding check branch is entered, a 10-minute lockout can be triggered. Electronic device 110 can write the failure count condition, lockout action, and duration together into the exception requirement, and describe the trigger point in conjunction with the check location in the code. The resulting test can set the corresponding pre-count state and then verify whether the application produces the expected lockout result.

[0148] In this way, abnormal requirements simultaneously record the triggering conditions and processing results, enabling subsequent generation to identify abnormal inputs and their expected responses. Maintaining a pairwise association between conditions and responses reduces use cases that only generate abnormal inputs without a basis for result judgment.

[0149] In box 340, electronic device 110 can use the second information to update the first part of the first requirements document 301. Thus, electronic device 110 can obtain the second requirements document 350. Electronic device 110 also retains the third information in the first requirements document 301 describing functions that have not yet been implemented in the code. Requirements enhancement thus allows for the addition of code details while maintaining the basis for the unimplemented functions in the original requirements.

[0150] In one implementation, the requirement enhancer can generate structured update records. Each update record includes an operation type, a target path, and new content. The operation type can represent addition, replacement, or deletion, and the target path points to a function, condition, or exception location in the function point tree. Electronic device 110 reads the path to locate the target entry and then writes the natural language content to the corresponding location according to the operation type.

[0151] For example, enhancing the initial login requirement can create three new records: one adding length and format requirements to the login function's condition set, and another adding a failure lockout requirement to the exception set. During version iterations, replacement records can be created, pointing to the description field of the same length entry and writing a new range of 8 to 30.

[0152] For deletion operations, a distinction should be made between entries originally formed based on code-attached behaviors and existing requirements describing functions that have not yet been implemented. The former can be deleted via the target path once the requirement's content has been determined to be removed. The latter should not be deleted simply because a corresponding implementation is not found in the current code; they should be retained as third-party information for test generation. This avoids mistakenly interpreting omitted functionality in code as a requirement that no longer demands that functionality.

[0153] Electronic device 110 saves the updated document as second requirement document 350, and can record the version number, generation time, corresponding code commit identifier, and parent version number. The parent version of the first enhanced version can be empty, and the next version points to the previously saved version. This metadata in document library 160 supports backtracking and comparison, and also enables the corresponding benchmark to be found when the second code is obtained later.

[0154] Figure 3 The scoring achievement path and the update path converge at point 350 of the second requirements document. The update path outputs the document containing the second information, while the scoring achievement path retains the existing requirements content as the result of this round. Both results can be entered... Figure 2 The requirement version comparison and test generation process described in Box 240, whether or not new test cases are generated depends on the requirement differences.

[0155] In this way, requirement updates can be applied to the corresponding functionalities along a structured path, while retaining test data for unimplemented features. Version metadata further clarifies the correspondence between update results and code baselines, reducing object confusion in subsequent version comparisons and test case maintenance.

[0156] A corresponding apparatus for implementing the above methods or processes is also provided.

[0157] Figure 4 A block diagram of a test case generation device 400 according to some embodiments is shown. Device 400 may be implemented as or included in electronic device 110. Various modules in device 400 may be implemented by hardware, software, firmware, or any combination thereof.

[0158] like Figure 4As shown, the apparatus 400 includes an acquisition module 410, an extraction module 420, an update module 430, and a generation module 440. The acquisition module 410 is configured to acquire a first requirements document and first code. The first requirements document describes the functionality of the application, and the first code is used to implement at least some of the application's functionality. The extraction module 420 is configured to extract first information from the first code, the first information indicating the processing logic of the first code. The update module 430 is configured to update the first requirements document based on the first information to obtain a second requirements document. The second requirements document includes second information, the second information describing the portion of the processing logic not described by the first requirements document. The generation module 440 is configured to generate a first test case based on the second requirements document, the first test case being used to test the application.

[0159] In some embodiments, the update module 430 may also be configured to determine a first part of the first requirements document based on the first information. The first part describes the function corresponding to the processing logic. The update module 430 may also be configured to update the first part using second information to obtain a second requirements document.

[0160] In some embodiments, the update module 430 may also be configured to obtain a first condition from the first information. The first condition defines the value range of the first code input parameter. The update module 430 may also be configured to add a natural language description of the first condition to the first part, the natural language description constituting the second information and preserving the boundary values ​​of the value range.

[0161] In some embodiments, the update module 430 may also be configured to obtain a second condition and a first response from the first information. The second condition is used to trigger an exception branch in the first code, and the first response indicates the result of the application executing the exception branch. The update module 430 may also be configured to add second information to the first part, the second information describing the second condition and the first response.

[0162] In some embodiments, the update module 430 may also be configured to compare the functional description in the first requirements document with the first information to obtain a first score. The first score indicates the degree of consistency between the functional description and the processing logic. The update module 430 may also be configured to update the first requirements document and obtain a second requirements document based on the first information in response to the first score being lower than a first threshold.

[0163] In some embodiments, the extraction module 420 may also be configured to compare the first code and the second code to determine the first function in the first code that has been modified. The second code is the code applied in the earlier version. The extraction module 420 may also be configured to determine the analysis scope based on the first function and the call relationships in the first code, and extract first information from the functions within the analysis scope. The analysis scope includes the first function.

[0164] In some embodiments, the extraction module 420 may also be configured to determine the call distance between the second function and the first function. The second function directly or indirectly calls the first function. The extraction module 420 may also be configured to determine the degree to which the second function is affected by changes in the first function based on the call distance and a decay coefficient. This degree decreases as the call distance increases. The extraction module 420 may also be configured to include the second function in the analysis scope in response to the degree being not lower than a second threshold.

[0165] In some embodiments, the extraction module 420 may also be configured to perform syntactic analysis on the first code to obtain an abstract syntax tree representing the syntactic structure of the first code. The extraction module 420 may also be configured to process the first code and the abstract syntax tree using a first model to obtain first information. The first model is used to analyze the processing logic of the code.

[0166] In some embodiments, the first requirements document is obtained based on the code of an earlier version of the application. The generation module 440 can also be configured to compare the first requirements document and the second requirements document to obtain a first difference that records the changed requirements items and the types of their changes. The generation module 440 can also be configured to generate a first test case based on the newly added or modified requirements items indicated by the first difference and the first information.

[0167] In some embodiments, the first and second requirement documents organize requirement entries in a tree structure. The generation module 440 can also be configured to match requirement entries in the two documents according to requirement entry identifiers. The generation module 440 can also be configured to record the corresponding requirement identifier and the content before and after modification in a first difference in response to differences in the content of the matched entries.

[0168] In some embodiments, the generation module 440 may also be configured to construct a hint based on the change type indicated by the first difference and the content of the requirement item before and after modification. The hint also includes a code snippet in the first code corresponding to the requirement item. The generation module 440 may also be configured to process the hint using a second model to generate a first test case. The first test case includes input data and the expected results of the application in response to the input data.

[0169] In some embodiments, the generation module 440 may also be configured to obtain a second test case from an existing test case library based on a first difference. The second test case corresponds to the modified requirement entry indicated by the first difference. The generation module 440 may also be configured to provide a first suggestion, which indicates that the input data or expected result of the second test case be updated according to the modified requirement entry.

[0170] In some embodiments, the generation module 440 may also be configured to obtain a third test case from an existing test case library based on a first difference. The third test case corresponds to the deleted requirement entry indicated by the first difference. The generation module 440 may also be configured to provide a second suggestion, which indicates that the third test case should be discarded.

[0171] In some embodiments, the generation module 440 may also be configured to determine the requirement items that need to be tested based on a first difference. The items to be tested are newly added or modified requirement items. The generation module 440 may also be configured to determine coverage according to the requirement identifier associated with the first test case. Coverage is the ratio of the number of items that have been covered by the first test case to the total number of items that need to be tested. The generation module 440 may also be configured to generate fourth test cases for requirement items not covered by the first test cases in response to coverage falling below a third threshold.

[0172] In some embodiments, the first requirement document is the original requirement document. The generation module 440 can also be configured to, in response to a historical requirement document that does not exist for the application, compare the second requirement document with an empty document to obtain a second difference. The second difference records requirement entries in the second requirement document as new entries. The generation module 440 can also be configured to generate a first test case based on the new entries indicated by the second difference.

[0173] In some embodiments, the second requirements document also retains third information. This third information comes from the first requirements document and describes functionality that has not yet been implemented in the first code. The generation module 440 can also be configured to generate first test cases based on this third information.

[0174] The modules included in device 400 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more modules may be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the units in device 400 may be implemented at least partially by one or more hardware logic components. By way of example and not limitation, exemplary types of hardware logic components that may be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard parts (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), and so on.

[0175] Figure 5 A block diagram of an electronic device 500 in which one or more examples can be implemented is shown. It should be understood that... Figure 5 The electronic device 500 shown is merely exemplary and should not be construed as limiting the functionality and scope of the examples described in this disclosure. Figure 5 The electronic device 500 shown can be used to implement the electronic device 110 discussed above.

[0176] like Figure 5 As shown, electronic device 500 is in the form of a general-purpose electronic device. Components of electronic device 500 may include, but are not limited to, one or more processing units or processors 510, memory 520, storage devices 530, one or more communication units 540, one or more input devices 550, and one or more output devices 560. Processor 510 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 520. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 500.

[0177] Electronic device 500 typically includes multiple computer storage media. Such media can be any accessible media that is accessible to electronic device 500, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 520 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof). Storage device 530 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data and can be accessed within electronic device 500.

[0178] Electronic device 500 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 5 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus via one or more data media interfaces. Memory 520 may include computer program product 525 having one or more program modules configured to perform various methods or actions of various examples.

[0179] The communication unit 540 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 500 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 500 can operate in a networked environment using logical connections to one or more other servers, networked personal computers, or another network node.

[0180] Input device 550 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 560 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 500 can also communicate with one or more external devices (not shown) via communication unit 540 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 500, or with any device that enables electronic device 500 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via an input / output (I / O) interface (not shown).

[0181] A computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. A computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0182] The flowcharts and / or block diagrams of the methods, apparatus, devices, and computer program products referred to herein describe various aspects. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0183] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0184] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0185] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to some embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0186] Various examples have been described above. The foregoing description is exemplary and not exhaustive, nor is it limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used in this disclosure is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations of this disclosure.

Claims

1. A method for generating test cases, comprising: Obtain a first requirements document and first code, wherein the first requirements document describes the functionality of the application and the first code is used to implement at least some of the functionality of the application; Extract first information from the first code, the first information indicating the processing logic of the first code; Based on the first information, the first requirement document is updated to obtain a second requirement document. The second requirement document includes second information, which describes the portion of the processing logic not described by the first requirement document; and Based on the second requirements document, a first test case is generated, which is used to test the application.

2. The method according to claim 1, wherein updating the first requirement document based on the first information to obtain a second requirement document includes: Based on the first information, a first part of the first requirement document is determined, wherein the first part describes the function corresponding to the processing logic; as well as Using the second information, the first part is updated to obtain the second requirements document.

3. The method of claim 2, wherein updating the first portion using the second information comprises: From the first information, a first condition is obtained, and the first condition limits the range of values ​​for the input parameters of the first code; as well as In the first part, a natural language description of the first condition is added, the natural language description constitutes the second information, and the boundary values ​​of the value range are preserved.

4. The method of claim 2, wherein updating the first portion using the second information comprises: From the first information, a second condition and a first response are obtained. The second condition is used to trigger an exception branch in the first code, and the first response is used to instruct the application to execute the processing result of the exception branch. as well as In the first part, the second information is added, which describes the second condition and the first response.

5. The method according to claim 1, wherein updating the first requirement document based on the first information to obtain a second requirement document includes: The first score is obtained by comparing the functional description in the first requirement document with the first information. The first score indicates the degree of consistency between the functional description and the processing logic. as well as In response to the first score being lower than the first threshold, the first requirement document is updated based on the first information to obtain the second requirement document.

6. The method according to claim 1, wherein extracting the first information from the first code comprises: By comparing the first code and the second code, a first function in the first code that has been modified is identified, and the second code is the code of a prior version of the application; Based on the first function and the call relationships in the first code, the analysis scope is determined, and the analysis scope includes the first function; and The first information is extracted from the functions within the scope of the analysis.

7. The method according to claim 6, wherein determining the analysis range includes: Determine the call distance between the second function and the first function, wherein the second function directly or indirectly calls the first function; Based on the call distance and attenuation coefficient, the degree to which the second function is affected by the change in the first function is determined, and the degree decreases as the call distance increases; as well as In response to the degree being not less than the second threshold, the second function is included in the analysis scope.

8. The method according to claim 1, wherein extracting the first information from the first code comprises: The first code is subjected to syntactic analysis to obtain an abstract syntax tree, which represents the syntactic structure of the first code; as well as Using the first model, the first code and the abstract syntax tree are processed to obtain the first information. The first model is used to analyze the processing logic of the code.

9. The method of claim 1, wherein the first requirements document is obtained based on the code of a prior version of the application, and generating the first test case based on the second requirements document comprises: Compare the first requirement document and the second requirement document to obtain the first difference, and the first difference records the requirement items that have been changed and their change types; as well as The first test case is generated based on the new or modified requirement items indicated by the first difference and the first information.

10. The method of claim 9, wherein the first requirement document and the second requirement document organize requirement entries in a tree structure, and the comparison of the first requirement document and the second requirement document to obtain a first difference comprises: Match the requirement entries in the first requirement document and the second requirement document according to the identifier of the requirement entry; as well as In response to the different contents of mutually matching requirement items, the corresponding requirement identifier and the contents before and after modification are recorded in the first difference.

11. The method of claim 9, wherein generating the first test case based on the newly added or modified requirement item indicated by the first difference and the first information comprises: Based on the change type indicated by the first difference and the content before and after the modification of the requirement item, a prompt is constructed, and the prompt also includes the code segment in the first code corresponding to the requirement item; as well as Using the second model, the prompts are processed to generate the first test case, which includes input data and the application's expected results for the input data.

12. The method of claim 9, further comprising: Based on the first difference, a second test case is obtained from the existing test case library, the second test case corresponding to the modified requirement item indicated by the first difference; as well as A first recommendation is provided, which instructs that the input data or expected results of the second test case be updated according to the modified requirement entry.

13. The method of claim 9, further comprising: Based on the first difference, a third test case is obtained from the existing test case library, the third test case corresponding to the deleted requirement item indicated by the first difference; as well as A second recommendation is provided, which instructs that the third test case be discarded.

14. An apparatus for generating test cases, comprising: The acquisition module is configured to acquire a first requirements document and first code, wherein the first requirements document describes the functionality of the application and the first code is used to implement at least some of the functionality of the application. The extraction module is configured to extract first information from the first code, wherein the first information indicates the processing logic of the first code; The update module is configured to update the first requirement document based on the first information to obtain a second requirement document. The second requirement document includes second information, which describes the part of the processing logic that is not described by the first requirement document. as well as The generation module is configured to generate a first test case based on the second requirements document, the first test case being used to test the application.

15. An electronic device comprising: At least one processor; as well as At least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to any one of claims 1 to 13 when executed by the at least one processor.

16. A computer-readable storage medium having stored thereon computer-executable instructions that can be executed by a processor to implement the method according to any one of claims 1 to 13.

17. A computer program product tangibly stored in a computer storage medium and comprising computer-executable instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 13.

Images