Test case generation method, device, program product, and electronic device

Abstract

The application discloses a test case generation method and device, a program product and electronic equipment, and relates to the field of financial technology or other related technical fields. The method comprises the following steps: analyzing L project documents of financial software to obtain test metadata, wherein each field constraint rule in the test metadata is used to represent a value range and a logical limit condition corresponding to each input field in a test scene of the financial software; analyzing source code of the financial software to obtain a code execution path set; performing a verification operation on the test metadata and M code execution paths in the code execution path set; and generating a test case of the financial software based on the test metadata and the M code execution paths in the case where the test metadata and the M code execution paths pass the verification operation. The application solves the technical problem of low test efficiency caused by manually writing test cases based on project documents in the prior art.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related technical fields, and more specifically, to a method, apparatus, program product, and electronic device for generating test cases. Background Technology

[0002] With the increasing complexity of software architectures, especially the widespread adoption of microservice architectures, the combinations of system interface parameters are growing exponentially, posing significant challenges to traditional software testing methods. Current testing practices primarily rely on manually written test cases to cover business logic. However, manually written test cases struggle to fully cover complex business branches, especially boundary conditions and exception flows, and there is often a disconnect between design documents, code implementation, and test cases. This disconnect not only easily leads to test omissions or excessively redundant test cases but also makes it difficult for requirement-based testing to effectively connect to underlying code branches. Furthermore, existing code coverage tools typically only passively count executed paths and cannot proactively generate test cases, further limiting the comprehensiveness and efficiency of testing.

[0003] There is currently no effective solution to the problem of low testing efficiency caused by manually writing test cases based on project documents. Summary of the Invention

[0004] This application provides a method, apparatus, program product, and electronic device for generating test cases, in order to at least solve the technical problem of low testing efficiency caused by manually writing test cases based on project documents in the prior art.

[0005] According to one aspect of this application, a method for generating test cases is provided, comprising: parsing L project documents of financial software to obtain test metadata, wherein L is a positive integer, the L project documents include program design specifications and data structure specifications, and the test metadata includes at least one field constraint rule, each field constraint rule being used to characterize the value range and logical constraints corresponding to each input field in the test scenario of the financial software; parsing the source code of the financial software to obtain a set of code execution paths, wherein the set of code execution paths includes M code execution paths, M being a positive integer; performing a verification operation on the test metadata and the M code execution paths in the set of code execution paths; and generating test cases for the financial software based on the test metadata and the M code execution paths if the test metadata and the M code execution paths pass the verification operation.

[0006] Optionally, the L project documents of the financial software are parsed to obtain test metadata, including: entity recognition of the L project documents using a preset natural language understanding model to obtain structured constraint data, wherein the structured constraint data includes at least one of the following: data type constraints, non-null constraints, uniqueness constraints, enumeration value constraints, regular expression constraints, and business logic constraints; boundary value description data is extracted from the L project documents using a preset regular expression engine, wherein the boundary value description data includes at least one of the following: null value boundaries, extreme value boundaries, invalid value boundaries, and enumeration value boundaries; N field constraint rules are generated based on the structured constraint data and boundary value description data, and the N field constraint rules are used as test metadata, wherein N is a positive integer.

[0007] Optionally, the source code of the financial software is parsed to obtain a set of code execution paths, including: after performing lexical and syntactic analysis on the source code, creating an abstract syntax tree based on the analysis results; traversing the nodes in the abstract syntax tree to identify control flow nodes, wherein the control flow nodes are used to represent the program execution order and branching direction of the source code, and the control flow nodes include entry nodes, branch nodes, merging nodes and exit nodes; and generating M code execution paths in the set of code execution paths based on the control flow nodes, wherein each code execution path corresponds to a triggering condition and an expected execution result.

[0008] Optionally, a verification operation is performed on the M code execution paths in the test metadata and code execution path set, including: parsing the field constraint rules in the test metadata to obtain K atomic constraint conditions, where K is a positive integer, and each atomic constraint condition is a logical judgment unit of the smallest granularity; combining the K atomic constraint conditions to obtain M combination results, and generating an expected execution path based on each combination result, where each combination result includes at least one atomic constraint condition; matching each combination result in the code execution path set to obtain the code execution path corresponding to each combination result; and performing a consistency verification between the expected execution path and the code execution path corresponding to each combination result.

[0009] Optionally, after performing consistency verification on the expected execution path and the code execution path corresponding to each combination result, the test case generation method further includes: generating a prompt message based on the i-th combination result if no code execution path corresponding to the i-th combination result is matched in the code execution path set or if the expected execution path and the code execution path corresponding to the i-th combination result are inconsistent.

[0010] Optionally, test cases for the financial software are generated based on test metadata and M code execution paths, including: determining P parameter factors based on test metadata and M code execution paths, where P is a positive integer and the P parameter factors are input variables affecting the program execution logic of the source code; generating a test case matrix based on the P parameter factors, where each row of the test case matrix corresponds to a test scenario and each column of the test case matrix corresponds to all values ​​of a parameter factor; and generating Q test cases for the financial software and the test script corresponding to each test case based on the test case matrix, where Q is a positive integer.

[0011] Optionally, after generating test cases for the financial software based on test metadata and M code execution paths, the test case generation method further includes: executing the test script corresponding to each test case to obtain the test result of each test case; if the test result of the j-th test case represents a test failure, checking whether the source code has been updated; if the source code has been updated, generating new test cases based on the updated source code.

[0012] According to another aspect of this application, a test case generation apparatus is also provided, comprising: a document parsing unit for parsing L project documents of financial software to obtain test metadata, wherein L is a positive integer, the L project documents include program design specifications and data structure specifications, and the test metadata includes at least one field constraint rule, each field constraint rule being used to characterize the value range and logical constraints corresponding to each input field in the test scenario of the financial software; a code parsing unit for parsing the source code of the financial software to obtain a set of code execution paths, wherein the set of code execution paths includes M code execution paths, M being a positive integer; a consistency verification unit for performing verification operations on the test metadata and the M code execution paths in the set of code execution paths; and a test case generation unit for generating test cases for the financial software based on the test metadata and the M code execution paths, provided that the test metadata and the M code execution paths have passed the verification operations.

[0013] According to another aspect of this application, a computer program product is also provided, which stores a computer program, wherein a method for generating test cases that controls the computer program product to execute any of the above-mentioned items is provided when the computer program is running.

[0014] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a method for generating test cases of any of the above.

[0015] In this application, firstly, L project documents of the financial software are parsed to obtain test metadata, where L is a positive integer. The L project documents include program design specifications and data structure specifications. The test metadata includes at least one field constraint rule, each of which characterizes the value range and logical constraints corresponding to each input field in the test scenario of the financial software. Next, the source code of the financial software is parsed to obtain a set of code execution paths, where the set includes M code execution paths, where M is a positive integer. Then, a verification operation is performed on the test metadata and the M code execution paths in the set. Finally, if the test metadata and the M code execution paths pass the verification operation, test cases for the financial software are generated based on the test metadata and the M code execution paths.

[0016] As described above, this application employs a linked approach of design document parsing, source code parsing, and test case generation. By parsing the contents of the program design specification and data structure specification, field constraint rules are extracted to generate test metadata. Simultaneously, the source code is parsed to construct an abstract syntax tree to identify defensive code and logical branches, forming a set of code execution paths. The consistency of the two is then verified to discover potential functional omissions. Subsequently, test cases are automatically generated based on the verified test metadata and code execution path set. This achieves the technical effect of improving the efficiency of test case generation and the coverage of code branches by test cases, thereby solving the technical problem of low testing efficiency caused by manually writing test cases based on project documents in the prior art. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a hardware structure block diagram of an optional computer terminal (or mobile device) for implementing a test case generation method according to an embodiment of this application.

[0019] Figure 2 This is a flowchart of an optional test case generation method according to an embodiment of this application;

[0020] Figure 3 This is an architecture diagram of an optional test case generation system according to an embodiment of this application;

[0021] Figure 4 This is a flowchart of an optional source code program control flow diagram according to an embodiment of this application;

[0022] Figure 5This is a schematic diagram of an optional test case generation apparatus according to an embodiment of this application;

[0023] Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] It should also be noted that all information and data (including but not limited to information used for display and analysis) involved in this application are authorized by the user or fully authorized by all parties. For example, if there is an interface between this system and the relevant user or organization, before obtaining the relevant information, it is necessary to send a request to the aforementioned user or organization through the interface, and obtain the relevant information only after receiving consent from the aforementioned user or organization.

[0027] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary security measures have been taken. They do not violate public order and good morals. In addition, this application provides corresponding operation entry points for users to choose to agree to authorization or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.

[0028] The present invention will now be described in detail with reference to various embodiments.

[0029] Example 1

[0030] According to an embodiment of this application, an embodiment of a test case generation method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a test case generation method according to an embodiment of this application. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0032] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0033] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the test case generation method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned test case generation method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0034] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0035] The display can be configured as a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0036] Under the aforementioned operating environment, this application provides a test case generation system (hereinafter referred to as the generation system) for executing the test case generation method of this application. Figure 2 This is a flowchart of an optional test case generation method according to an embodiment of this application. Figure 3 This is an architecture diagram of an optional test case generation system according to an embodiment of this application. The test case generation system includes a document parsing module, a code parsing module, a consistency verification module, a test case generation module, a test executor, and a self-healing module. Figure 2 and Figure 3 As shown, Figure 2 The method for generating test cases in [the system] includes the following steps:

[0037] Step S201: Parse the L project documents of the financial software to obtain test metadata, where L is a positive integer, the L project documents include program design specifications and data structure specifications, and the test metadata includes at least one field constraint rule. Each field constraint rule is used to characterize the value range and logical constraints corresponding to each input field in the test scenario of the financial software.

[0038] Optionally, the generation system receives and reads L project documents (i.e., ...) through the document parsing module. Figure 3 The document type includes at least a program design specification and a data structure specification. Then, the document parsing module calls the preset natural language processing model (NLU) to identify the structured constraint data in the L project documents, and calls the preset regular expression engine to extract the boundary value description data in the L project documents. Then, based on the structured constraint data and boundary value description data, field constraint rules are generated, and the field constraint rules are used as test metadata.

[0039] Optionally, the program design specification is a design document that describes the software's functional logic, interface definitions, and business rules; the data structure specification is a design document that describes the database table structure, field types, and constraints.

[0040] Optionally, the project document is parsed by the document parsing module to generate test metadata, realizing the conversion from natural language to structured machine language. The technical effects that can be achieved include: (1) directly extracting structured constraint information (i.e. field constraint rules) from the project document, avoiding ambiguity caused by human understanding of the document, and ensuring the accuracy of the test cases generated later; (2) combining the program design specification and the data structure specification, it can capture business logic constraints and underlying data constraints at the same time, ensuring that the test metadata contains both business rules and data integrity rules, laying a data foundation for the subsequent generation of high-quality test cases.

[0041] Step S202: Parse the source code of the financial software to obtain a set of code execution paths, wherein the set of code execution paths includes M code execution paths, where M is a positive integer.

[0042] Optionally, the generation system reads the source code files of the financial software through the code parsing module, constructs the abstract syntax tree (AST) of the source code using a static code analysis engine (such as an AST-based parser), then traverses the AST nodes, identifies control flow nodes, and constructs the program's control flow graph (CFG) based on the identified control flow nodes, thereby extracting M code execution paths from the function entry point to the exit point. Each code execution path consists of a series of conditional expressions (i.e., triggering conditions) and corresponding expected results (such as exception types defined by defensive code), ultimately forming a set of code execution paths.

[0043] Optionally, the code execution path set is obtained by parsing the source code through the code parsing module, realizing the mapping from static code to dynamic logical behavior. The technical effects that can be achieved include: (1) It does not rely on human memory or document description, but extracts the path based on the actual logic of the code, so as to truly reflect the existing defense mechanism and business branches of the code; (2) It can identify defensive branches in the code (such as null value checking and exception throwing), which are edge cases that are easy to miss by manual testing, thus providing an accurate comparison benchmark for subsequent consistency verification.

[0044] Step S203: Perform a verification operation on the M code execution paths in the test metadata and code execution path set.

[0045] Optionally, the system call consistency verification module performs the verification operation. Specifically, the consistency verification module searches the code execution path set for the atomic constraint conditions used in the expected execution path (i.e., the logical path that the project documentation requires the source code to include) derived from the field constraint rules. If the conditions in the expected execution path cannot find a matching branch in the code execution path set (for example, the atomic constraint condition requires verification of the role field, but there is no judgment branch related to the role field in the code execution path set), or if the actual execution path obtained by the query is inconsistent with the expected execution path, then the verification is determined to have failed and a prompt message is generated.

[0046] Optionally, the verification operation refers to the process of comparing the execution logic expected by the project documentation with the actual execution logic included in the current source code.

[0047] Optionally, the technical effects that can be achieved by performing verification operations through the consistency verification module include: (1) proactively discovering defects: being able to proactively discover differences between the code implementation and design requirements (such as missing functions or missing logic) before test cases are generated, rather than only discovering problems during the test execution phase; (2) improving code quality: through the prompts provided by the verification feedback, developers can be guided to correct the code, so that the implementation of the source code follows the design specifications of the project document, reducing code logic errors caused by misunderstandings of document requirements.

[0048] Step S204: If the test metadata and M code execution paths pass the verification operation, generate test cases for the financial software based on the test metadata and M code execution paths.

[0049] Optionally, the system call test case generation module generates test cases for the financial software. Specifically, the test case generation module extracts field constraint rules from the test metadata and conditional expressions contained in each code execution path from the code execution path set as parameter factors. Then, based on the extracted parameter factors, a pre-set combination algorithm (such as orthogonal experiment method or Cartesian product combination) is used to generate a test case matrix. Then, according to the test case matrix, the parameter values ​​in the pre-set template are automatically filled and assertion logic is generated. Finally, executable test cases and test scripts corresponding to each test case are output.

[0050] Optionally, test cases are generated based on the verification results through the test case generation module, which automates and improves the efficiency of test generation, thereby eliminating manual dependence and improving testing efficiency. Furthermore, since the generation is based on the consistency of document constraints and code paths, the generated test cases can accurately cover all key business branches and boundary conditions, avoiding omissions or redundancies that may be caused by manual writing, and ensuring the effectiveness and comprehensiveness of the tests.

[0051] As described above, this application employs a linked approach of design document parsing, source code parsing, and test case generation. By parsing the contents of the program design specification and data structure specification, field constraint rules are extracted to generate test metadata. Simultaneously, the source code is parsed to construct an abstract syntax tree to identify defensive code and logical branches, forming a set of code execution paths. The consistency of the two is then verified to discover potential functional omissions. Subsequently, test cases are automatically generated based on the verified test metadata and code execution path set. This achieves the technical effect of improving the efficiency of test case generation and the coverage of code branches by test cases, thereby solving the technical problem of low testing efficiency caused by manually writing test cases based on project documents in the prior art.

[0052] In one optional embodiment, the document parsing module first performs entity recognition on L project documents using a preset natural language understanding model to obtain structured constraint data. The structured constraint data includes at least one of the following: data type constraints, non-null constraints, uniqueness constraints, enumeration value constraints, regular expression constraints, and business logic constraints. Then, it extracts boundary value description data from the L project documents using a preset regular expression engine. The boundary value description data includes at least one of the following: null value boundaries, extreme value boundaries, invalid value boundaries, and enumeration value boundaries. Finally, it generates N field constraint rules based on the structured constraint data and the boundary value description data, and uses the N field constraint rules as test metadata, where N is a positive integer.

[0053] Optionally, the preset natural language understanding model refers to a pre-configured algorithm model used to understand and process natural language text; entity recognition refers to the process of extracting keywords or phrases that can represent data constraint rules from natural language text; and the preset regular expression engine refers to a pre-configured text extraction tool used to match and process text based on regular expression patterns.

[0054] Optionally, data type constraints include: such as the data type of the field (e.g., INT, VARCHAR); NOT NULL constraints, such as whether the field is allowed to be null (NOT NULL); Uniqueness constraints, such as whether the field value must be unique (UNIQUE); Enumeration constraints, such as whether the field value is limited to a specific set (ENUM); Regular expression constraints, such as whether the field format conforms to a specific regular expression; and Business logic constraints, such as the logical relationships between fields or the business rules restrictions of financial software.

[0055] Optionally, null value boundary: if the field is empty, a test value null or "" will be generated; extreme value boundary: if the field has a maximum or minimum value, a boundary value such as length=50 (maximum), length=0 (minimum), value=-999999 (minimum integer) will be generated; invalid value boundary: if the field value exceeds the preset range; enumeration value boundary: if the enumeration type lists compliant and non-compliant values.

[0056] Optionally, the technical effects that the document parsing module can achieve through the above steps include: (1) improving the richness of test metadata: by introducing a dual parsing mechanism that combines a natural language understanding model and a regular expression engine, the complementarity from "semantic understanding" to "pattern matching" is realized, ensuring that the test metadata contains both business logic constraints and boundary value details, thereby improving the richness of test metadata; (2) helping to improve the coverage of test cases: by integrating structured constraint data and boundary value description data, N field constraint rules are generated, and the vague natural language description in the document is transformed into accurate, machine-understandable test metadata, so that the subsequent consistency verification module can perform code path comparison based on finer-grained constraints, and the test case generation module can generate test cases that cover more boundary scenarios, thereby improving the coverage of test cases for complex business branches (such as boundary conditions and abnormal processes).

[0057] In one optional embodiment, the code parsing module first performs lexical and syntactic analysis on the source code, then creates an abstract syntax tree based on the analysis results. Next, it traverses the nodes in the abstract syntax tree to identify control flow nodes, which are used to represent the program execution order and branching direction of the source code. Control flow nodes include entry nodes, branch nodes, merging nodes, and exit nodes. Then, based on the control flow nodes, it generates M code execution paths from the code execution path set, where each code execution path corresponds to a triggering condition and an expected execution result.

[0058] Optionally, entry nodes represent the starting point of program or function execution; branch nodes represent the conditional judgment points where the program execution flow branches (such as IF and SWITCH statements); merging nodes represent the points where different branch execution paths are re-merged; and exit nodes represent the points where program or function execution ends (such as RETURN and THROW statements).

[0059] For example, Figure 4 This is a flowchart of an optional source code program control flow graph according to an embodiment of this application, such as... Figure 4 As shown, the program control flow graph represents a three-layer defense logic. Taking the user login scenario of financial software as an example, part of the source code is as follows:

[0060] public JwtResponse login(LoginRequest request) {

[0061] / / Defense layer 1: Null check

[0062] if (request.getUsername() == null || request.getPassword() == null){

[0063] throw new ValidationException("Username and password cannot be empty");

[0064] }

[0065] / / Defense Layer 2: Authentication

[0066] User user = userRepo.findByUsername(request.getUsername())

[0067] .orElseThrow(() -> new AuthException("User does not exist"));

[0068] if (!passwordEncoder.matches(request.getPassword(), user.getPassword())) {

[0069] throw new AuthException("Incorrect password");

[0070] }

[0071] / / Defense Layer 3: Status Check

[0072] if (!user.getIsActive()) {

[0073] throw new AuthException("Account is disabled");

[0074] }

[0075] / / Generate JWT token

[0076] return new JwtResponse(jwtUtil.generateToken(user));

[0077] }

[0078] The control flow graph generated by the code parsing module based on the control flow nodes obtained from the above source code parsing is as follows: Figure 4 As shown, the process includes login entry, control checks, user queries, password verification, status checks, and token generation. Then, the code parsing module generates the code execution path based on the above control flow graph.

[0079] Optionally, the technical effects that the code parsing module can achieve through the above steps include: (1) Implementing structured parsing of code logic: By constructing an abstract syntax tree through lexical analysis and syntax analysis, the unstructured source code is transformed into structured tree data, eliminating the subjectivity and error-proneness of manual code reading. By traversing the AST to identify control flow nodes, the control flow structure of the program can be accurately captured, laying a data foundation for the subsequent generation of code execution path sets. (2) Helping to improve the comprehensiveness of test coverage: The M code execution paths generated based on control flow nodes cover all possible logical branches from the entry point to the exit point. The triggering conditions and expected execution results associated with each path clearly indicate under what input conditions the program will enter the path and produce what results. This fine-grained path description enables subsequent steps to generate targeted test cases based on these specific paths, ensuring comprehensive coverage of complex business branches (such as abnormal processes and boundary conditions) and avoiding test omissions.

[0080] In one optional embodiment, the consistency verification module first parses the field constraint rules in the test metadata to obtain K atomic constraints, where K is a positive integer and each atomic constraint is a logical judgment unit of the smallest granularity. Then, the K atomic constraints are combined to obtain M combination results, and an expected execution path is generated based on each combination result, where each combination result includes at least one atomic constraint. Then, based on each combination result, a match is made in the code execution path set to obtain the code execution path corresponding to each combination result. Subsequently, a consistency verification is performed on the expected execution path and the code execution path corresponding to each combination result.

[0081] Optionally, K atomic constraints refer to the smallest logical judgment unit obtained after decomposing the field constraint rules. Each atomic constraint is an indivisible Boolean logical expression (such as username != null or role == 'TEACHER'); combination result refers to the set formed by combining the K atomic constraints according to logical relationships (such as logical AND and logical OR); expected execution path refers to the logical path that the program should execute according to the project documentation, derived from the combination result, representing "what functionality the documentation expects the source code to achieve".

[0082] Optionally, the technical effects that the consistency verification module can achieve through the above steps include: (1) realizing the decomposition and reorganization of constraint logic: by parsing the field constraint rules into K atomic constraint conditions, the problem that the composite constraints in the document are difficult to directly correspond to the code branches is solved. Atomization enables the system to independently process each basic logic judgment. By combining the K atomic constraint conditions to generate the combination result, and generating the expected execution path accordingly, the system can reconstruct the implicit and complete business logic branches in the document, thereby ensuring that the expected execution path can fully cover all legal and illegal business scenarios defined in the document, avoiding missed tests due to incomplete constraint decomposition; (2) realizing the discovery of differences between the document and the code: in the process of matching the code execution path corresponding to each combination result in the code execution path set, a mapping relationship from the document expectation to the code implementation is established. By performing consistency verification, it can automatically identify whether the expected execution path has a corresponding implementation in the code execution path set. If there is a missing one (i.e. the expected path cannot find the matching actual path), it means that there is a functional omission or logical deviation in the code implementation. This verification mechanism can actively discover the inconsistency between the design document and the code implementation, rather than relying on manual review, thereby intercepting potential code vulnerabilities before test cases are generated.

[0083] In one optional embodiment, after performing a consistency check on the expected execution path and the code execution path corresponding to each combination result, if the generation system does not match the code execution path corresponding to the i-th combination result in the code execution path set or if the expected execution path and the code execution path corresponding to the i-th combination result are inconsistent, a prompt message is generated based on the i-th combination result.

[0084] Optionally, the technical effects that the generation system can achieve through the above steps include: (1) Discovering functional omissions and logical deviations: By searching the path corresponding to the i-th combined result in the code execution path set, the missing processing branch in the code implementation can be accurately identified, solving the problem that it is difficult to find static defects such as "the code does not meet the document requirements" in traditional testing. By comparing the consistency of the paths, the system can capture the subtle differences between the code logic and the document design, such as exception handling errors and condition judgment deviations, so as to discover potential logical errors in advance before test execution; (2) Reducing repair costs: The system performs repairs in the test case generation stage. Consistency verification and generation of prompts move the problem discovery process forward to the development stage. At this time, developers can correct the code in the coding or unit testing stage based on the prompts, avoiding the defect from flowing into the subsequent integration testing or system testing stage, thereby reducing the cost and time cycle of defect repair; (3) Improve the accuracy and credibility of test case generation: The above-mentioned early warning mechanism ensures that the final test case will only be generated when the code implementation is consistent with the document constraints (or known deviations), preventing the generation of invalid test cases based on erroneous or incomplete code logic, thereby ensuring the output quality and credibility of the automated testing system.

[0085] In one optional embodiment, the test case generation module first determines P parameter factors based on test metadata and M code execution paths, where P is a positive integer and the P parameter factors are input variables that affect the program execution logic of the source code. Then, a test case matrix is ​​generated based on the P parameter factors, where each row of the test case matrix corresponds to a test scenario and each column of the test case matrix corresponds to all values ​​of a parameter factor. Finally, Q test cases for the financial software and the test script corresponding to each test case are generated based on the test case matrix, where Q is a positive integer.

[0086] Optionally, the P parameter factors refer to the input variables extracted from the test metadata and M code execution paths that directly affect the execution logic of the source code program. For example, in the login scenario, username, password, role, user.is_active, etc. are parameter factors. Parameter factors are key input items that determine the program's direction. The test case matrix refers to a two-dimensional data structure in which each row represents a specific combination of test scenarios, and each column corresponds to all possible values ​​of a parameter factor (including legal values, illegal values, boundary values, etc.). This matrix systematically arranges the value combinations of the P parameter factors through Cartesian product or orthogonal combination.

[0087] Optionally, the technical effects that the test case generation module can achieve through the above steps include: (1) achieving systematic coverage of test scenarios: by determining P parameter factors from test metadata and M code execution paths, the key variables affecting program logic are accurately identified. Then, the test case matrix is ​​used to combine all the values ​​of the P parameter factors, ensuring that the test scenario covers all possible input combinations and avoiding scenario omissions caused by limited thinking when manually writing test cases; (2) improving the efficiency of test case generation: Q test cases and test scripts are automatically generated based on the test case matrix, replacing the traditional manual writing method, thereby improving the efficiency of test preparation and enabling rapid response to changes and generation of the latest test set in the agile development mode of frequent iterations; (3) ensuring the consistency between test cases and code logic: since the P parameter factors come from test metadata and code execution paths that have undergone consistency verification, the generated test case matrix and its derived Q test cases match the actual logic branches of the code, so that the generated test cases can effectively trigger each code branch, improve code coverage, and avoid generating invalid test cases that cannot be executed or cannot cover key logic.

[0088] In one optional embodiment, after generating test cases for the financial software based on test metadata and M code execution paths, the system call test executor and self-healing module first executes the test script corresponding to each test case to obtain the test result of each test case. Then, if the test result of the j-th test case represents a test failure, it checks whether the source code has been updated. If the source code has been updated, a new test case is generated based on the updated source code.

[0089] Optionally, the technical effects that the test executor and self-repair module can achieve through the above steps include: (1) Implementing adaptive repair and maintenance of test cases: When the test script is executed and the j-th test case fails, the system does not simply mark it as failed, but further checks whether the source code has been updated. If the failure is caused by code changes (updates), new test cases are automatically regenerated based on the updated source code, thereby realizing automatic updates of test cases and eliminating the high maintenance cost of manually modifying or rewriting each test case after a large number of test cases fail due to code changes; (2) Ensuring the real-time performance and effectiveness of test coverage: New test cases are generated based on the updated source code, ensuring that the test cases are always consistent with the latest code logic. The newly generated test cases can cover the logic branches added or modified after the code update (such as the added defense layer and new business rules), thereby ensuring that automated testing can continuously and effectively verify the software quality and avoiding test blind spots caused by the lag of test cases.

[0090] Example 2

[0091] This application embodiment can also provide a test case generation device. It should be noted that the test case generation device of this application embodiment can be used to execute the test case generation method provided in this application embodiment. The test case generation device provided in this application embodiment will be described below.

[0092] According to an embodiment of this application, an apparatus for implementing the above-described test case generation method is also provided. Figure 5 This is a schematic diagram of an optional test case generation apparatus according to an embodiment of this application, such as... Figure 5 As shown, the device includes: a document parsing unit 501, a code parsing unit 502, a consistency verification unit 503, and a test case generation unit 504.

[0093] Optionally, the document parsing unit 501 is used to parse L project documents of the financial software to obtain test metadata, where L is a positive integer, the L project documents include program design specifications and data structure specifications, and the test metadata includes at least one field constraint rule, each field constraint rule is used to characterize the value range and logical constraints corresponding to each input field in the test scenario of the financial software; the code parsing unit 502 is used to parse the source code of the financial software to obtain a set of code execution paths, where the set of code execution paths includes M code execution paths, M is a positive integer; the consistency verification unit 503 is used to perform verification operations on the test metadata and the M code execution paths in the set of code execution paths; and the test case generation unit 504 is used to generate test cases for the financial software based on the test metadata and the M code execution paths if the test metadata and the M code execution paths pass the verification operation.

[0094] As described above, this device employs a linked approach of design document parsing, source code parsing, and test case generation. By parsing the contents of the program design specification and data structure specification, it extracts field constraint rules to generate test metadata. Simultaneously, it parses the source code to construct an abstract syntax tree to identify defensive code and logical branches, forming a set of code execution paths. The consistency of these two is then verified to uncover potential functional omissions. Subsequently, test cases are automatically generated based on the verified test metadata and code execution path set. This achieves the technical effect of improving the efficiency of test case generation and the coverage of code branches by test cases, thereby solving the technical problem of low testing efficiency caused by manually writing test cases based on project documents in existing technologies.

[0095] In one optional embodiment, the document parsing unit 501 includes: an entity recognition subunit, an extraction subunit, and a first generation subunit.

[0096] Optionally, the entity recognition subunit is used to perform entity recognition on L project documents using a preset natural language understanding model to obtain structured constraint data, wherein the structured constraint data includes at least one of the following: data type constraints, non-null constraints, uniqueness constraints, enumeration value constraints, regular expression constraints, and business logic constraints; the extraction subunit is used to extract boundary value description data from the L project documents using a preset regular expression engine, wherein the boundary value description data includes at least one of the following: null value boundaries, extreme value boundaries, invalid value boundaries, and enumeration value boundaries; and the first generation subunit is used to generate N field constraint rules based on the structured constraint data and boundary value description data, and to use the N field constraint rules as test metadata, wherein N is a positive integer.

[0097] In one alternative embodiment, the code parsing unit 502 includes: creating a sub-unit, traversing the sub-units, and generating a second sub-unit.

[0098] Optionally, a sub-unit is created to generate an abstract syntax tree based on the analysis results after lexical and syntactic analysis of the source code; a traversal sub-unit is created to traverse the nodes in the abstract syntax tree and identify control flow nodes, where control flow nodes are used to represent the program execution order and branching direction of the source code, and control flow nodes include entry nodes, branch nodes, merging nodes and exit nodes; a second generation sub-unit is created to generate M code execution paths from the set of code execution paths based on the control flow nodes, where each code execution path corresponds to a triggering condition and an expected execution result.

[0099] In one optional embodiment, the consistency verification unit 503 includes: a parsing subunit, a combining subunit, a matching subunit, and a verification subunit.

[0100] Optionally, the parsing subunit is used to parse the field constraint rules in the test metadata to obtain K atomic constraint conditions, where K is a positive integer, and each atomic constraint condition is a logical judgment unit of the smallest granularity; the combination subunit is used to combine the K atomic constraint conditions to obtain M combination results, and generate an expected execution path based on each combination result, where each combination result includes at least one atomic constraint condition; the matching subunit is used to match each combination result in the code execution path set to obtain the code execution path corresponding to each combination result; and the verification subunit is used to perform consistency verification on the expected execution path and the code execution path corresponding to each combination result.

[0101] In an optional embodiment, the test case generation apparatus further includes a prompting unit.

[0102] Optionally, the prompting unit is used to generate a prompt message based on the i-th combination result after performing a consistency check on the expected execution path and the code execution path corresponding to each combination result, in the case where no code execution path corresponding to the i-th combination result is matched in the code execution path set or the expected execution path and the code execution path corresponding to the i-th combination result are inconsistent.

[0103] In one optional embodiment, the test case generation unit 504 includes: a determination subunit, a third generation subunit, and a fourth generation subunit.

[0104] Optionally, a third generation subunit is used to determine P parameter factors based on test metadata and M code execution paths, where P is a positive integer and the P parameter factors are input variables that affect the program execution logic of the source code; a fourth generation subunit is used to generate a test case matrix based on the P parameter factors, where each row of the test case matrix corresponds to a test scenario and each column of the test case matrix corresponds to all values ​​of a parameter factor; and a fifth generation subunit is used to generate Q test cases for the financial software and the test script corresponding to each test case based on the test case matrix, where Q is a positive integer.

[0105] In one optional embodiment, the test case generation apparatus further includes a test execution unit and a self-healing unit.

[0106] Optionally, the test execution unit is used to execute the test script corresponding to each test case after generating test cases for financial software based on test metadata and M code execution paths, and obtain the test result of each test case; the self-repair unit is used to detect whether the source code has been updated when the test result of the j-th test case represents a test failure, and if the source code has been updated, generate new test cases based on the updated source code.

[0107] It should be noted that units 501 to 504 correspond to steps S201 to S204 in the method embodiments. The instances and application scenarios implemented by the units and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the modules or units may be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The modules may also be part of a device and run in the computer terminal 10 provided in the embodiments.

[0108] Example 3

[0109] Embodiments of this application can also provide an electronic device. Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 6 As shown, the electronic device includes: one or more ( Figure 6 (Only one is shown) Processor 602, memory 604, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0110] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and devices in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the above-mentioned test case generation method.

[0111] The memory may include high-speed random access memory (RAM), and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0112] The processor can access information and applications stored in memory via a transmission device to perform the following steps: Parsing L project documents of the financial software to obtain test metadata, where L is a positive integer; the L project documents include program design specifications and data structure specifications; the test metadata includes at least one field constraint rule, each field constraint rule characterizing the value range and logical constraints corresponding to each input field in the test scenario of the financial software; parsing the source code of the financial software to obtain a set of code execution paths, where the set of code execution paths includes M code execution paths, where M is a positive integer; performing verification operations on the test metadata and the M code execution paths in the set of code execution paths; and generating test cases for the financial software based on the test metadata and the M code execution paths, provided that the test metadata and the M code execution paths pass the verification operation.

[0113] This application provides a test case generation scheme. The scheme employs a linked approach of design document parsing, source code parsing, and test case generation. It extracts field constraint rules and generates test metadata by parsing the program design specification and data structure specification. Simultaneously, it parses the source code to construct an abstract syntax tree to identify defensive code and logical branches, forming a set of code execution paths. The two are then validated for consistency to identify potential functional omissions. Subsequently, test cases are automatically generated based on the validated test metadata and code execution path set. This improves the efficiency of test case generation and the coverage of code branches, thereby solving the problem of low testing efficiency caused by manually writing test cases based on project documents in existing technologies.

[0114] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, PDAs, mobile internet devices, PADs, and other terminal devices. Figure 6This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0115] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0116] Example 4

[0117] Embodiments of this application may also provide a storage medium.

[0118] Optionally, in this embodiment of the application, the storage medium can be used to store the program code executed by the test case generation method provided in the above method embodiment.

[0119] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0120] This application also provides a computer program product, which, when executed on a data processing device, is adapted to perform the steps of a test case generation method.

[0121] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0122] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0123] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0124] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0126] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0127] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating test cases, characterized in that, include: The test metadata is obtained by parsing L project documents of the financial software, where L is a positive integer. The L project documents include program design specifications and data structure specifications. The test metadata includes at least one field constraint rule. Each field constraint rule is used to characterize the value range and logical constraints corresponding to each input field in the test scenario of the financial software. The source code of the financial software is parsed to obtain a set of code execution paths, wherein the set of code execution paths includes M code execution paths, where M is a positive integer; Perform verification operations on the test metadata and the M code execution paths in the code execution path set; If the test metadata and the M code execution paths pass the verification operation, test cases for the financial software are generated based on the test metadata and the M code execution paths.

2. The test case generation method according to claim 1, characterized in that, The test metadata is obtained by parsing L project documents of the financial software, including: The L project documents are subjected to entity recognition by a preset natural language understanding model to obtain structured constraint data, wherein the structured constraint data includes at least one of the following: data type constraint, non-null constraint, uniqueness constraint, enumeration value constraint, regular expression constraint, and business logic constraint. Boundary value description data is extracted from the L project documents using a preset regular expression engine. The boundary value description data includes at least one of the following: null value boundary, extreme value boundary, invalid value boundary, and enumerated value boundary. Based on the structured constraint data and the boundary value description data, N field constraint rules are generated, and the N field constraint rules are used as the test metadata, where N is a positive integer.

3. The test case generation method according to claim 1, characterized in that, The source code of the financial software is parsed to obtain a set of code execution paths, including: After performing lexical and syntactic analysis on the source code, an abstract syntax tree is created based on the analysis results; The nodes in the abstract syntax tree are traversed to identify control flow nodes, wherein the control flow nodes are used to represent the program execution order and branching direction of the source code, and the control flow nodes include entry nodes, branch nodes, merging nodes and exit nodes. Based on the control flow node, M code execution paths are generated in the code execution path set, where each code execution path corresponds to a triggering condition and an expected execution result.

4. The test case generation method according to claim 1, characterized in that, Perform verification operations on the test metadata and the M code execution paths in the code execution path set, including: The field constraint rules in the test metadata are parsed to obtain K atomic constraint conditions, where K is a positive integer, and each atomic constraint condition is a logical judgment unit with the smallest granularity. The K atomic constraints are combined to obtain M combination results, and an expected execution path is generated based on each combination result, wherein each combination result includes at least one atomic constraint. Based on each combination result, a matching is performed in the code execution path set to obtain the code execution path corresponding to each combination result; Perform a consistency check on the expected execution path and the code execution path corresponding to each combination result.

5. The test case generation method according to claim 4, characterized in that, After performing consistency checks on the expected execution path and code execution path corresponding to each combined result, the method for generating test cases further includes: If no code execution path corresponding to the i-th combination result is matched in the set of code execution paths, or if the expected execution path corresponding to the i-th combination result is inconsistent with the code execution path, a prompt message is generated based on the i-th combination result.

6. The test case generation method according to claim 1, characterized in that, Based on the test metadata and the M code execution paths, test cases for the financial software are generated, including: Based on the test metadata and the M code execution paths, P parameter factors are determined, where P is a positive integer, and the P parameter factors are input variables that affect the program execution logic of the source code; A test case matrix is ​​generated based on the P parameter factors, wherein each row of the test case matrix corresponds to a test scenario, and each column of the test case matrix corresponds to all values ​​of a parameter factor. Based on the test case matrix, Q test cases and a corresponding test script for each test case are generated for the financial software, where Q is a positive integer.

7. The test case generation method according to claim 1, characterized in that, After generating test cases for the financial software based on the test metadata and the M code execution paths, the test case generation method further includes: Execute the test script corresponding to each test case to obtain the test results for each test case; If the test result of the j-th test case represents a test failure, check whether the source code has been updated; If the source code is updated, new test cases are generated based on the updated source code.

8. A test case generation device, characterized in that, include: The document parsing unit is used to parse L project documents of the financial software to obtain test metadata, where L is a positive integer. The L project documents include a program design specification and a data structure specification. The test metadata includes at least one field constraint rule. Each field constraint rule is used to characterize the value range and logical constraints corresponding to each input field in the test scenario of the financial software. The code parsing unit is used to parse the source code of the financial software to obtain a set of code execution paths, wherein the set of code execution paths includes M code execution paths, where M is a positive integer; A consistency verification unit is used to perform verification operations on the test metadata and the M code execution paths in the code execution path set. The test case generation unit is used to generate test cases for the financial software based on the test metadata and the M code execution paths, provided that the test metadata and the M code execution paths pass the verification operation.

9. A computer program product, characterized in that, The computer program product includes a computer program, wherein, when the computer program is executed, it controls the computer program product to perform the test case generation method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the test case generation method according to any one of claims 1 to 7.

Images