Automatic compiling method and device of test case, electronic equipment and storage medium

Abstract

The invention discloses an automatic compiling method and device for a test case, electronic equipment and a storage medium, and relates to the technical field of computers, and the method comprises the steps: carrying out the structural analysis of a demand document for creative and creative transformation, and extracting the demand information of the demand document; the code warehouse is connected to obtain the source code and performs static analysis to generate code logic; establishing a semantic association mapping table of the demand information and the code logic, generating a test scene library according to the semantic association mapping table, and automatically generating a test case according to the parameter type and the constraint rule; and performing multi-dimensional verification on the generated test case to generate a verification result, and adjusting the priority of the test case according to the verification result. The method has the technical effects of improving marginal scene coverage depth and breadth, improving test case writing efficiency and accuracy, reducing manual dependence, and optimizing test case quality and execution pertinence.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for automating the writing of test cases. Background Technology

[0002] The transformation of domestically developed IT systems is a crucial measure to mitigate the risks of cyberattacks and supply chain disruptions. This complex process requires the modification of numerous existing systems. Test cases, as the core basis for verifying whether software functionality meets requirements, directly impact subsequent testing efficiency and software quality. The traditional method of manually writing test cases is no longer sufficient to meet current application needs. Traditional test cases largely rely on manual writing by testers, exhibiting significant technical shortcomings: Firstly, human boundary modeling capabilities are limited, often overlooking key verification points such as monetary boundary values ​​and special character validation. Typical production time verification scenarios are also prone to incomplete coverage, resulting in insufficient scenario coverage and logical combination vulnerabilities, leading to recurring issues. Secondly, the rate of automated test case generation is low, with many standard scenario test cases still requiring manual writing. Furthermore, the lack of an effective requirement-code association mechanism makes test case design heavily reliant on manual input, resulting in low efficiency, insufficient development effectiveness, and difficulty in ensuring test case accuracy. Additionally, manual writing can easily lead to logical conflicts and duplication between test cases, further affecting testing results and failing to meet the requirements of domestically developed IT systems for test case writing efficiency, coverage, and accuracy. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and storage medium for automating the writing of test cases. It can solve the problems in related technologies caused by manually writing test cases, such as insufficient scenario coverage, missed detection of logical combination vulnerabilities, low R&D efficiency, and logical conflicts or unreasonable priorities in test cases.

[0004] According to a first aspect of this application, a method for automating the writing of test cases is provided, comprising: The requirements document for information technology innovation transformation is structured and parsed to extract the requirements information. Connect to the code repository to obtain source code and perform static analysis to generate code logic; Establish a semantic relationship mapping table between requirement information and code logic, generate a test scenario library based on the semantic relationship mapping table, and automatically generate test cases based on parameter types and constraint rules; The generated test cases are validated from multiple dimensions to generate validation results, and the priority of the test cases is adjusted based on the validation results.

[0005] According to a second aspect of this application, an apparatus for automatically writing test cases is provided, comprising: The extraction module is configured to perform structured parsing of the requirements document for information technology innovation transformation and extract the requirements information from the document. The first generation module is configured to connect to the code repository to obtain source code and perform static analysis to generate code logic; The second generation module is configured to establish a semantic association mapping table between requirement information and code logic, generate a test scenario library based on the semantic relationship mapping table, and automatically generate test cases based on parameter types and constraint rules. The adjustment module is configured to perform multi-dimensional verification on the generated test cases, generate verification results, and adjust the priority of the test cases based on the verification results.

[0006] According to a third aspect of this application, an electronic device is provided, comprising: At least one processor; and memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by at least one processor, which are executed by at least one processor to enable at least one processor to execute the automated writing method of the test cases mentioned in the first aspect.

[0007] According to a fourth aspect of this application, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute the automated writing method of test cases of the aforementioned first aspect.

[0008] According to a fifth aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements an automated method for writing test cases as described in the first aspect above.

[0009] This application provides a method, apparatus, electronic device, and storage medium for automated test case writing, comprising: performing structured parsing of a requirement document for information technology innovation transformation and extracting requirement information from the requirement document; connecting to a code repository to obtain source code and performing static analysis to generate code logic; establishing a semantic association mapping table between requirement information and code logic, generating a test scenario library based on the semantic relationship mapping table, and automatically generating test cases based on parameter types and constraint rules; performing multi-dimensional verification on the generated test cases to generate verification results, and adjusting the priority of test cases based on the verification results. This application addresses several issues in related technologies. It enables structured parsing of requirement documents for IT innovation transformation, extraction of requirement information, access to code repositories to obtain source code, static analysis to generate code logic, and the establishment of a semantic mapping table between the two to generate a test scenario library. Furthermore, it automatically generates test cases based on parameter types and constraint rules, and performs multi-dimensional verification of the generated test cases, adjusting their priority according to the verification results. Therefore, it solves the problems of insufficient scenario coverage, missed detection of logical combination vulnerabilities, low R&D efficiency, logical conflicts in test cases, or unreasonable priority caused by manually written test cases. This achieves the technical effects of improving the depth and breadth of marginal scenario coverage, increasing the efficiency and accuracy of test case writing, reducing reliance on manual intervention, and optimizing the quality and execution relevance of test cases.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating an automated test case writing method provided in an embodiment of this application; Figure 2 A flowchart illustrating another method for automating the writing of test cases provided in an embodiment of this application; Figure 3 A flowchart illustrating another method for automating the writing of test cases provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an automated test case writing device provided in an embodiment of this application. Detailed Implementation

[0013] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0014] The following description, with reference to the accompanying drawings, describes an automated test case writing method, apparatus, electronic device, and storage medium according to embodiments of this application.

[0015] Figure 1 This is a flowchart illustrating an automated test case writing method provided in an embodiment of this application.

[0016] like Figure 1 As shown, the method includes the following steps: Step 101: Perform structured parsing of the requirements document for information technology innovation transformation and extract the requirements information from the document.

[0017] In some embodiments, the requirements document for domestic IT innovation transformation refers to various documents that clearly define the functional, performance, and operational requirements of the software system during the transformation process. These documents may be in formats such as Word, Excel, PDF, and Markdown, and their content covers key information such as the business objectives the software must achieve, specific operational procedures, and data interaction standards. They serve as the core basis for subsequent test case writing. Structured parsing refers to the use of Natural Language Processing (NLP) technology to systematically organize and analyze the potentially fragmented and unstructured or semi-structured text in the requirements document. Through lexical analysis, syntactic analysis, and named entity recognition, it breaks down the fragmented nature of information, transforming messy text into clearly categorized and logically rigorous structured data. The extraction of requirements information revolves around four core elements: Functional points, which are the specific functions or operations the software needs to implement, such as balance inquiries, information modifications, and permission verification in user account management; Input parameters, including the data types required for the function to run, such as text, numbers, and dates; threshold restrictions, such as the range of numerical values ​​and text length constraints; format requirements, such as the standard number of digits and character combinations for mobile phone numbers and the alphanumeric rules for user IDs; Output results, covering the expected output content or system status when the function executes normally, such as the amount and currency returned after a balance inquiry, and prompts in abnormal scenarios, such as error text when the input format is incorrect; and Constraints, including permission restrictions, such as only the user or administrators with specific permissions can operate the function, business rules such as the execution order of operations, and data dependencies such as key restrictions such as the need for a function to be associated with the user's bound identity information. Through the above structured analysis and information extraction process, the core test-related elements in the requirements document can be accurately captured, effectively avoiding information omissions and misunderstandings during manual extraction, significantly improving the efficiency and accuracy of requirements information extraction, and providing comprehensive and reliable basic data support for the generation of subsequent test cases.

[0018] Step 102: Connect to the code repository to obtain the source code and perform static analysis to generate code logic.

[0019] In some embodiments, a code repository is a professional storage system that centrally stores and manages project source code. Common types include Git and SVN. The source code stored within it carries the core functional implementation logic of the software system and serves as the core data foundation for subsequent code logic analysis. When connecting to a code repository, a connection can be established through an API interface adapted to the target repository. Specifically, the repository network address needs to be configured, the branch name of the source code to be retrieved needs to be specified, and a valid access token needs to be entered to complete identity verification, thereby enabling automatic retrieval of source code. It also supports receiving source code folders uploaded by users locally, ensuring the comprehensiveness and flexibility of source code acquisition channels. After obtaining the source code, static code analysis tools are used for analysis. Static code analysis refers to an analysis method that deeply analyzes the code structure through techniques such as syntax parsing and lexical analysis without running the source code. These tools can accurately identify characteristic keywords of different programming languages, such as `public` and `private` in Java, and `def` and `class` in Python. Based on these keywords, the definitions of classes and functions and their modules are located, and then the input parameters, output parameters, and internal branching conditions of functions are extracted, such as if-else statements, switch-case branches, and loop logic, as well as exception handling logic, such as try-catch blocks and throw statements. The code logic generated through this process clearly presents the functional implementation path, parameter passing rules, branch jump relationships, and exception handling mechanisms of the source code. This provides structured and accurate core data support for the subsequent matching of requirement information with code logic, avoiding logical omissions and misunderstandings caused by manual code analysis, and significantly improving the efficiency and accuracy of code logic extraction.

[0020] Step 103: Establish a semantic relationship mapping table between requirement information and code logic, generate a test scenario library based on the semantic relationship mapping table, and automatically generate test cases based on parameter types and constraint rules.

[0021] In some embodiments, the semantic association mapping table is a structured data carrier that establishes the correspondence between requirement information and code logic. Its construction is based on semantic matching technology, deeply associating and matching the previously extracted requirement information (including core elements such as function points, input parameters, output results, and constraints) with the parsed code logic (including function input / output parameters, branch judgment conditions, exception handling logic, and data dependencies). Specifically, by identifying the semantic correspondence between requirement elements and code logic—for example, the requirement for "input parameter format validation function" and the code's judgment branch for parameter format (specifically, a phone number format validation code segment); the requirement for "only the user can operate" constraint and the code's user identity validation logic statement; the requirement for "exception output prompt" and the code's try-catch block exception throwing logic, etc.—precise mapping relationships are established one by one, ultimately forming a semantic association mapping table with clear entries and explicit associations, providing a logical link for subsequent scenario construction and use case generation. The test scenario library is generated based on this semantic association mapping table. By logically expanding and combining each association in the mapping table, it comprehensively covers various scenarios required for software testing. These include normal scenarios, where both the requirement information and the code logic execute normally, such as input that meets the format requirements triggering a normal code branch and returning the expected result; edge scenarios, triggered by parameter thresholds or critical business conditions, such as boundary cases where the user ID length is 6 or 12 digits or time threshold scenarios for function execution; and abnormal scenarios, triggered by invalid input data, unmet permissions, or abnormal code branches, such as inputting a non-alphanumeric user ID or unauthorized user attempting to operate. This ensures that the scenario library can completely cover the association logic between requirements and code, avoiding scenario omissions. The automatic generation of test cases is centered on parameter types and constraint rules. Parameter types cover clearly defined data types such as text, numbers, and dates. Constraint rules include key conditions such as parameter length limits, format requirements, permission constraints, and business rule restrictions. Combined with preset test design rules, such as equivalence class partitioning, boundary value analysis, and business logic test rules, test data adapted to different scenarios is automatically generated. This includes valid data that conforms to constraint rules, invalid data that violates format or permission requirements, and edge data that touches boundary thresholds. The expected result for each data point is clearly defined. Then, following a preset template of "number, function point, input data, test steps, expected result," the scenario, data, and expected result are structurally integrated to automatically generate complete and executable test cases. This process achieves deep binding between requirements, code, and test cases, ensuring the relevance and comprehensiveness of test cases, significantly improving the automation and accuracy of test case generation, and reducing redundancy and omissions in manual design.

[0022] Step 104: Perform multi-dimensional verification on the generated test cases to generate verification results, and adjust the priority of the test cases based on the verification results.

[0023] In some embodiments, multi-dimensional verification is a systematic inspection of automatically generated test cases from multiple key dimensions, such as logical consistency, requirement coverage completeness, and content redundancy. It aims to comprehensively identify potential quality issues in test cases and provide accurate basis for subsequent test case optimization. Specifically, logical conflict verification compares the input data of each test case with the corresponding expected results to identify situations where the same input parameter corresponds to different expected outputs, or logical contradictions exist within the same business scenario. For example, a conflict scenario where the same formatted user ID input is judged as valid and invalid in different test cases. Requirement coverage verification traces the relationship between test cases and requirement information, calculates the coverage ratio of test cases to core elements such as requirement functionalities and constraints, accurately identifies uncovered requirement points, and avoids omissions of key test scenarios. Redundancy verification uses text similarity calculation algorithms to compare the core content of each test case, such as functionalities, input data, and test steps, to identify redundant cases that are repetitive or have highly similar core logic, reducing the cost of invalid test execution. The verification result is a comprehensive evaluation information formed by integrating the above multi-dimensional detection data, clearly presenting the specific problems and severity of test cases in terms of logic, coverage, and redundancy. Test case priority adjustment is based on the verification result, combined with preset weight calculation rules. Specifically, it is calculated using the product formula of code defect probability and business impact. Code defect probability refers to the likelihood of a defect in the code logic corresponding to the test case, while business impact refers to the degree to which a problem in the function covered by the test case affects business operations. The product formula is Priority = P × Severity, where P corresponds to code defect probability and Severity corresponds to business impact. Test cases with high defect probability and high business impact are adjusted to high priority, while low-risk, low-impact test cases are set to low priority. This process ensures high-quality test cases, avoiding logical conflicts and redundancy that could affect test results. Furthermore, priority optimization concentrates test resources on key scenarios, significantly improving the targeting and efficiency of test execution and reducing the cost of ineffective testing.

[0024] Compared with related technologies, this embodiment addresses the issues of insufficient scenario coverage, missed detection of logical combination vulnerabilities, low R&D efficiency, logical conflicts in test cases, or unreasonable priority in test cases caused by manually written test cases in related technologies. It achieves the technical effects of improving the depth and breadth of marginal scenario coverage, increasing the efficiency and accuracy of test case writing, reducing reliance on manual intervention, and optimizing the quality and execution relevance of test cases. This approach involves: structurally parsing the requirement documents for information technology innovation and extracting requirement information from code repositories and performing static analysis to generate code logic; establishing a semantic relationship mapping table between requirement information and code logic; generating a test scenario library based on the semantic relationship mapping table; automatically generating test cases based on parameter types and constraint rules; performing multi-dimensional verification on the generated test cases to generate verification results; and adjusting the priority of test cases based on the verification results.

[0025] Figure 2 A flowchart illustrating another method for automating test case writing provided in this application embodiment includes the following steps: Step 201: Use a pre-trained natural language processing model to perform lexical analysis, syntactic analysis and named entity recognition on the requirement document to extract requirement elements.

[0026] In some embodiments, a pre-trained natural language processing model refers to a model that has been jointly trained with large-scale general text data and software testing-specific text data, possessing mature semantic understanding and information extraction capabilities. This model can accurately adapt to the textual features of the requirements document for domestic IT innovation transformation, and gradually completes the initial extraction of requirement elements through three core stages: lexical analysis, syntactic analysis, and named entity recognition. In the lexical analysis stage, the model breaks down the text content of the requirements document into independent lexical units, while simultaneously labeling the part of speech and domain attributes of each word, eliminating redundant words without actual testing relevance, and achieving the screening and classification of core words. The syntactic analysis stage focuses on sorting out the grammatical relationships and sentence structures between words. By identifying grammatical components such as subject-verb-object and modifier-complement, it clarifies the logical connections in the requirement description. For example, in the sentence "After the user enters their mobile phone number, the system returns the balance," a logical chain can be identified: "user" as the subject of the operation, "entering a mobile phone number" as the preceding action, and "the system returns the balance" as the core function, providing a basis for subsequent element classification. Named entity recognition is crucial for extracting core information from requirements. Based on a pre-trained domain entity library, the model accurately identifies key test-related entities in the requirements document, including function names, data types, numerical constraints, and prompts. These entities are marked as an initial set of requirement elements to be categorized, laying the foundation for subsequent structured organization. This process requires no manual intervention, efficiently handles various formats of domestic IT innovation transformation requirement documents, significantly improves the speed and accuracy of requirement element extraction, and avoids subjective bias and information omissions caused by manual extraction.

[0027] Step 202: Generate structured requirement information based on requirement elements, which include function points, input parameters, output results, and constraints.

[0028] In some embodiments, the process of generating structured requirement information is a process of systematically filtering, classifying, refining, and organizing the preliminary set of requirement elements extracted in step 201, ultimately forming structured data with clear categories and complete information. The presentation format of this structured data is adaptable to the requirements of subsequent code logic association and test case generation. For organizing functional points, it is necessary to select the specific business operations or core functions that the software needs to implement from the extracted requirement elements, clarifying the core role and scope of each functional point. For example, from the requirement description of "users can check their account balance after logging into the system," independent functional points such as "account balance query function," "login status verification function," and "input parameter format verification function" can be extracted, each corresponding to a clear test objective. The organization of input parameters should focus on the various types of data required for the function to operate, clearly defining the specific attributes of each parameter, including data type (such as text-based "User ID", numeric "Amount", and date-based "Operation Time"), format requirements (such as "Mobile number must conform to 11-digit format" and "User ID is a 6-12 alphanumeric combination"), input method (such as manual input, drop-down selection, and automatic system association), and threshold restrictions (such as "Query response time not exceeding 3 seconds" and "Input character length not less than 6 characters"), ensuring that the constraints of each input parameter are clearly identifiable. The organization of output results should distinguish between normal and abnormal output. Normal output clearly defines the expected content or system status when the function executes without error, such as "Returns the account's available balance and frozen amount, including numerical values ​​and currency units"; abnormal output clearly defines the system feedback in scenarios such as invalid parameters, insufficient permissions, or failure to meet preconditions, such as "Prompt 'Please log in first' when not logged in" and "Prompt 'Input parameter error, please check and try again' when input format is incorrect." The organization of constraints covers various rules restricting the operation of the function, including permission restrictions, business rules, data dependencies, etc., ensuring that all key constraints affecting the execution of the function are fully included. Through the above classification and organization, the originally scattered requirement elements are transformed into structured requirement information, which not only facilitates the establishment of precise associations with the code logic, but also provides a clear and standardized basis for the generation of test cases, improving the orderliness and efficiency of the entire testing process.

[0029] Step 203: Configure the repository address, branch name, and access token to connect to the code repository API or receive code folders uploaded by users locally.

[0030] In some embodiments, API integration with the code repository is one of the core methods for the system to obtain source code. The key lies in establishing a legitimate and stable connection through precise configuration of three core parameters. The repository address is the network access path pointing to the target code repository, typically presented in HTTP / HTTPS or SSH protocol format. This allows the system to accurately locate the remote server storing the source code, ensuring the accuracy of data transmission. The branch name explicitly specifies the specific code branch from which the source code needs to be obtained, such as the development branch, test branch, or main branch commonly used in R&D. It can be flexibly selected based on the current R&D stage of the domestic IT transformation project to meet the code acquisition needs of different scenarios. The access token is the security verification credential for the system to access the code repository. It is pre-created and assigned by the code repository administrator and contains a specific access permission scope. The system completes identity verification by including this token in the API request, effectively preventing security risks such as source code leakage caused by unauthorized access. The system adapts to the interface specifications of mainstream code repositories such as Git and SVN, integrating the three configured parameters into a standardized API request. It establishes a connection with the code repository through network communication and automatically pulls the complete source code files from the corresponding branch, including source code files of various programming languages ​​and related configuration files. Meanwhile, to address special scenarios where code cannot be obtained via API integration, the system supports receiving locally uploaded code folders. Users can directly select their local source code storage directory for batch uploads. The system automatically performs integrity checks on the uploaded folders, identifying and highlighting missing critical code files to ensure the uploaded source code directory structure is complete and files are undamaged. These two source code acquisition methods are flexible and complementary, satisfying both automated retrieval needs in standard scenarios and local upload requirements in special cases. This ensures the stability and comprehensiveness of source code acquisition, providing complete and reliable data source support for subsequent code logic analysis.

[0031] Step 204: Use static code analysis tools to identify function input and output parameters, branch conditions, exception handling logic, and data dependencies, and establish the correspondence between exception handling logic and exception scenarios in the requirements document.

[0032] In some embodiments, static code analysis tools are the core tools for extracting code logic. These tools do not require running the source code; instead, they adapt to the syntax rules of various programming languages ​​such as Java and Python through built-in parsers and lexical analyzers, performing in-depth analysis of the acquired source code. When identifying function input and output parameters, the tool locates function definition statements by matching characteristic keywords of the programming language, such as the `public` keyword in Java and the `def` keyword in Python. It then extracts detailed information such as input parameter names, data types, default values, and required attributes from the function declaration. Simultaneously, it identifies output parameter-related content such as the function's return value type, return data format, and return value constraints, forming a clear list of function parameters. When identifying branch conditions, the tool scans logical judgment statements in the code, including if-else statements, switch-case branches, and for / while loops. It parses the conditional expressions, loop termination conditions, and branch jump logic of each branch, clarifying different execution paths and triggering conditions, and fully presenting the logical branch structure of the code. When identifying exception handling logic, the tool focuses on examining try-catch blocks and throw statements in the code, recording the exception type (e.g., null pointer exception, parameter mismatch exception, insufficient permissions exception), the specific conditions for triggering the exception, and the handling method after the exception occurs (e.g., returning an error message, logging the exception, terminating program execution). When identifying data dependencies, the tool analyzes function call relationships, the propagation paths of global and local variables, and the relationships between data storage and retrieval to determine whether the execution of a function depends on the return results of other functions, or whether it needs to read specific configuration data or database information. Based on this, the system matches the extracted exception handling logic with the exception scenarios described in the requirements document. For example, it correlates the "throw exception triggered by input parameter format validation failure" in the code with the exception scenario "error message when inputting invalid format" in the requirements document, and it associates the "exception triggered by failed identity verification" with the scenario "prompt login for unlogged users" in the requirements document, establishing a precise correspondence between exception handling logic and the exception scenarios in the requirements. This process achieves a deep integration of code logic and requirement information. It not only fully extracts the core logical elements in the code, but also provides targeted code-level support for subsequent test scenario construction and test case generation, ensuring that test cases can accurately cover key logic and abnormal situations in the code and improve the effectiveness of testing.

[0033] Step 205: Establish a semantic association mapping table between requirement elements and code logic, and realize cross-modal information association by matching requirement constraints and code branch judgments.

[0034] In some embodiments, the semantic association mapping table is the core carrier for breaking down cross-modal information barriers between requirement elements and code logic. Its core logic is to achieve a deep association between unstructured requirement text and structured code logic by accurately matching requirement constraints and code branch decisions. Requirement constraints cover key elements such as permission restrictions, business rules, data dependencies, and format requirements. Examples include permission constraints like "only the user or administrator can operate," format constraints like "user ID is a 6-12 alphanumeric combination," and business rule constraints like "login status verification is required." Code branch decisions include statement structures used for logical jumps in various programming languages, such as if-else statements and switch-case branches in Java, and conditional statements in Python. These branch decisions directly determine the code's execution path. During the matching process, the core logical keywords and constraint thresholds in the requirement constraints are first extracted using semantic analysis technology. For example, core information such as "login status verification" and "not logged in" are extracted from "login status verification is required; if not logged in, please log in first". Then, the branch judgment statements in the code are scanned to identify the judgment conditions and logical intentions. For example, the logic of "login status judgment" and "not logged in scenario" is extracted from "if(loginContext.isLogin()==false)". Then, the requirement constraints and code branch judgments are established in a one-to-one correspondence using a domain semantic dictionary and a logical correspondence algorithm. For example, "user ID format constraint" is matched with the branch judgment "if(userID.matches('[a-zA-Z0-9]{6,12}'))" in the code, and "permission constraint" is matched with the branch judgment "if(userRole=='admin'||userID==accountBindID)" in the code. Through this cross-modal information association method, the semantic association mapping table clearly presents the code execution logic corresponding to each requirement constraint, ensuring the logical consistency between requirements and code, and providing accurate association basis for comprehensive coverage of subsequent test scenarios.

[0035] Step 206: Perform semantic-level matching between the permission verification constraints in the requirement elements and the branch judgment logic in the code.

[0036] In some embodiments, the permission verification constraints in the requirement elements specifically include restrictions on the operating subject, permission level division, and operation scope definition. Examples include "Only the user can query their own account balance," "Administrators with account query permissions can query associated accounts," and "Unauthorized users are prohibited from operating." These constraints clearly define the boundaries of operation permissions corresponding to different user roles or identities. The branch judgment logic in the code is the specific implementation of the permission verification function, typically manifested as conditional judgment statements based on parameters such as user identity identifier, role type, and permission code. For example, by determining whether the ID of the currently logged-in user matches the bound ID of the target account, the permission verification of "Only the user can operate" is achieved; by determining whether the user role field is "admin" and contains the permission code "account_query," the administrator permission is verified; and by determining whether the user's login status and permission identifier are valid, the operation of unauthorized users is blocked. In the semantic-level matching process, the permission verification constraints are first semantically decomposed to extract core semantic dimensions such as "subject identity," "permission type," and "operation allowed / prohibited." Next, the code branch judgment logic is semantically parsed to clarify the parameter types, comparison logic, and execution results in the judgment conditions. Then, through semantic similarity calculation and domain permission logic mapping rules, a precise association is established between the two. For example, the semantics of "only this user can operate" are matched with the semantics of the code branch judgment "userID==targetAccountBindID," and the semantics of "administrator permission verification" are matched with the semantics of the code branch judgment "userRole=='admin'&&hasPermission('account_query')." This semantic-level matching can penetrate the modal differences between text and code, ensuring that the key requirements related to permission verification completely correspond to the code logic, providing reliable support for the generation of subsequent permission-related test scenarios.

[0037] Step 207: Generate a test scenario library covering normal, edge, and abnormal scenarios through logical combination analysis.

[0038] In some embodiments, the generation of the test scenario library is based on a semantic association mapping table. Logical combination analysis technology is used to comprehensively expand and systematically combine the relationships between requirement elements and code logic, ultimately achieving complete coverage of normal, edge, and abnormal scenarios. During the logical combination analysis, key related items in the semantic association mapping table are first extracted, including the correspondence between requirement constraints and code branch judgments, the matching relationship between parameter thresholds and code boundary judgments, and the association between exception triggering conditions and abnormal code branches. Then, based on these related items, a combination deduction is performed according to the logical chain of "parameter value - constraint satisfaction - code branch execution". The generation logic for normal scenarios involves selecting parameter values ​​that meet all requirement constraints and triggering the normal execution branch in the code. For example, inputting a user ID that meets the format requirements, verifying a valid login status and operation permissions, corresponds to the branch in the code that executes the normal query function. This type of scenario covers the regular usage flow of the software. The generation logic for edge scenarios involves selecting values ​​that touch the boundary of requirement parameters or the critical value of constraints and triggering the boundary judgment branch in the code. For example, the user ID length is 6 digits (lower limit) or 12 digits (upper limit), and the query response time is close to the critical value of 3 seconds. This corresponds to the judgment logic in the code for parameter boundaries or time thresholds. This type of scenario can cover critical usage cases that are easily overlooked. The generation logic for abnormal scenarios involves selecting parameter values ​​that violate requirement constraints or trigger the code's abnormal handling. For example, inputting a user ID that is not a combination of letters and numbers, initiating an operation while not logged in, or an unauthorized user attempting a query, corresponds to the format validation failure branch, the not-login interception branch, the permission validation failure branch, and the try-catch exception capture branch in the code. This type of scenario can cover various abnormal usage cases. Through the above logical combination analysis, the test scenario library achieves full-dimensional coverage of the logic related to requirements and code, ensuring the integrity of regular scenarios while making up for the shortcomings in coverage of marginal and abnormal scenarios, providing comprehensive and systematic scenario support for the generation of subsequent test cases.

[0039] Step 208: Generate test cases and expected results according to the preset template. The expected results field includes normal output content, abnormal prompts and permission verification feedback information.

[0040] In some embodiments, test case generation strictly follows a preset template, which includes core fields such as number, function point, input data, test steps, and expected results, ensuring the structured and executable nature of the test cases. The input data field is generated based on various scenarios in the test scenario library, combined with parameter types and constraint rules. This includes valid data that meets format requirements, edge data that reaches boundary thresholds, and invalid data that violates constraints. Examples include "11-digit valid mobile phone number" and "8-digit alphanumeric user ID" in normal scenarios, "5-character user ID" and "operation request in an unlogged-in state" in abnormal scenarios, and "6-character user ID" and "query request with a 3-second critical response time" in edge scenarios. The test step field clarifies the test execution flow according to the input data and scenario logic, following the order of operations. Examples include "1. Not logged into the system; 2. Enter the account center entry; 3. Enter a valid user ID; 4. Initiate a balance query request" and "1. Log in to the administrator account; 2. Enter the ID of an unrelated user; 3. Initiate a balance query request." The expected result field is a core component of test cases, specifically containing three types of information: normal output content corresponds to the functional execution result under normal scenarios, such as "returning the current account's available balance (e.g., 1000 RMB) and frozen amount (e.g., 0 RMB)"; exception prompt information corresponds to the scenario results of invalid input or triggering abnormal code branches, such as "Input parameters are incorrect, please check and try again" or "Please log in first"; and permission verification feedback information corresponds to the results of permission verification scenarios, such as "No account query permission, operation failed" or "Administrator permission verification passed, return target account balance information." During the generation process, the system automatically matches and fills in the three types of expected result information based on the scenario type corresponding to the input data and the code logic in the semantic association mapping table, ensuring that the expected results are completely consistent with the requirement description and code implementation. Test cases generated in this way have a standardized structure, clear logic, and comprehensive coverage. They can not only be directly used for test execution but also reduce the understanding and operation costs for testers. At the same time, the multi-dimensional coverage of expected results ensures the comprehensiveness of test verification, effectively improving the quality of test cases and the effectiveness of test execution.

[0041] Step 209: Perform multi-dimensional verification on the generated test cases to generate code defect rate and business impact rate. Multi-dimensional verification includes detecting logical conflicts between cases, calculating the coverage ratio of required functional points, and identifying redundant cases.

[0042] In some embodiments, multi-dimensional verification is a systematic quality check performed on automatically generated test cases. Its core objective is to comprehensively identify potential problems and generate code defect and business impact metrics that support priority adjustments. The logic conflict detection stage compares the input data of each test case with its corresponding expected results to accurately identify logically contradictory scenarios. For example, the same formatted user ID input may be judged as valid or invalid in different test cases, or the same operation may have different output results under the same preconditions. This ensures the logical consistency of test cases and avoids distorted test results due to conflicts. The requirement function point coverage ratio calculation stage traces the relationship between test cases and requirement information, traversing the core elements such as function points, constraints, and input / output requirements in the requirement document. It calculates the percentage of elements covered by the test cases and identifies uncovered requirement points, such as a permission verification constraint not corresponding to any test case, or a certain edge parameter threshold not included in the test scenario, providing a basis for subsequent supplementary cases. The redundant test case identification process utilizes text similarity algorithms to compare the core content of test cases, such as functional descriptions, input data characteristics, and test steps, identifying cases with highly similar or completely identical core logic. For example, if two test cases differ only in non-critical fields of input data, but the test objectives, execution steps, and expected results are completely consistent, such cases will be judged as redundant. After completing the above multi-dimensional verification, the system comprehensively analyzes the verification results to generate code defect score and business impact score: the code defect score assesses the likelihood of defects in the code logic corresponding to each test case based on factors such as the number of logical conflicts, the importance of code logic corresponding to omissions, and the risk of code modules associated with redundant cases; the business impact score combines factors such as the coreness of the function covered by the test case, the criticality level of the associated business process, and the frequency of user usage to determine the scope and severity of the impact on the overall business operation if a problem occurs in the function. This process comprehensively ensures the basic quality of test cases and provides a quantitative basis for subsequent priority adjustments, effectively avoiding invalid testing and omission of key scenarios.

[0043] Step 210: Adjust the priority of test cases based on the probability of code defects and the impact on business operations.

[0044] In some embodiments, the priority adjustment of test cases is based on the code defect rate and business impact rate generated in step 209, and the reasonable allocation of test resources is achieved through scientific quantitative calculation. The code defect rate is the probability that the code logic corresponding to the test case has a defect, and the business impact rate is the degree to which a problem in the function covered by the test case affects business operations; both are quantitative indicators obtained after multi-dimensional verification. The priority adjustment process strictly follows the preset weight calculation rules, specifically using the product formula Priority=P×Severity to calculate the execution weight of each test case, where P corresponds to the code defect rate and Severity corresponds to the business impact rate. The system sorts all test cases according to the calculated weight values, adjusting test cases with high code defect rate and high business impact rate to high priority, such as test cases covering the core function of account balance query with a high risk of code logic defects; setting test cases with low code defect rate and low business impact rate to low priority, such as test cases covering peripheral auxiliary functions with relatively stable code logic; and test cases with medium weight correspond to medium priority. This quantitative adjustment approach ensures that testing resources are prioritized for critical business scenarios and high-risk code modules, avoiding ineffective testing that consumes resources, significantly improving the targeting and efficiency of test execution, while guaranteeing the adequacy of core function testing and reducing business operation risks.

[0045] Figure 3 A flowchart illustrating another method for automating test case writing provided in this application embodiment includes the following steps: Step 301: Perform structured parsing of the requirements document for information technology innovation transformation and extract the requirements information from the document.

[0046] Step 302: Connect to the code repository to obtain the source code and perform static analysis to generate code logic.

[0047] Step 303: Establish a semantic relationship mapping table between requirement information and code logic, generate a test scenario library based on the semantic relationship mapping table, and automatically generate test cases based on parameter types and constraint rules.

[0048] Step 304: Perform multi-dimensional verification on the generated test cases to generate verification results, and adjust the priority of the test cases based on the verification results.

[0049] For a description of steps 301-304, please refer to the description of steps 101-104 in the above embodiment. This embodiment will not repeat them in detail.

[0050] Step 305: Deploy a requirements document change listener to capture requirement document update events in real time, and automatically trigger incremental updates of associated test cases based on the changes in the change events.

[0051] In some embodiments, a real-time response mechanism is built by deploying a requirement document change listener. The requirement document change listener is a dedicated monitoring component deployed in a document library storing requirement documents. It possesses core capabilities for continuous scanning, state awareness, and event capture, enabling real-time monitoring of various state changes in requirement documents, including content modifications, additions of functional descriptions, constraint adjustments, and changes in input / output parameters. The listener continuously detects key indicators such as version differences and content validation value changes in requirement documents within the document library according to a preset scanning cycle or triggered monitoring logic. Once an update to a requirement document is detected, it immediately captures complete change event information, including the change type (e.g., content modification, addition, deletion), the specific chapter or field changed, a comparison of the content before and after the change, the change timestamp, and the operation subject, ensuring that change information is collected without omission or bias.

[0052] After capturing a change event, the system automatically initiates a correlation analysis and incremental update process: First, it precisely compares the changed content with the established "requirement-code" correlation mapping table to identify the corresponding requirement elements, such as whether the change involves constraints of a functional point, format requirements of input parameters, or prompts in the output results; next, it uses the correlation mapping table to locate the code logic segments and corresponding test case sets associated with these requirement elements, clarifying the test scope affected by the change; subsequently, it adopts a differentiated incremental update strategy based on the degree of impact of the change. If the change is a small-scale adjustment (such as adjusting the length constraint of a parameter from 6-12 bits to 8-16 bits), the system will update the incremental update strategy accordingly. If the change involves optimizing fields and exception message text, only the fields affected by the change in the associated test cases are modified. For example, the format requirements of input data are updated, and the prompt information in the expected results is adjusted. Unaffected test steps and input data are retained, avoiding redundancy caused by full regeneration. If the change is a core function or a large-scale adjustment (such as adding new functions, refactoring core business rules, or changing permission verification logic), the relevant test cases are regenerated based on the updated requirement information and corresponding code logic to ensure that the test cases can fully cover the changed functional logic. The entire process requires no manual intervention, realizing real-time linkage between requirement changes and test case updates. This effectively solves the problems of delayed response to requirement changes and inconsistencies between test cases and requirements in the traditional model, reduces manual maintenance costs, ensures the timeliness and accuracy of test cases during the information technology innovation transformation process, ensures that regression testing can accurately cover the scope of change impact, and improves the effectiveness and reliability of testing.

[0053] Step 306: Generate a change log based on the changed content, including the reason for the change, the scope of impact, and the operation result.

[0054] In some embodiments, a change log is a structured document that records the entire process of requirement changes and test case maintenance. It generates changes based on the requirement document and the updated execution results of test cases. Its core purpose is to form a complete and auditable change tracking chain, providing a basis for subsequent test process tracing, problem investigation, and compliance verification. The "Reason for Change" field must accurately describe the specific type and background of the requirement document change, clearly identifying the triggering factors. Examples include: "Due to business scenario expansion, the user ID format constraint for the 'User Account Balance Inquiry Function' in the requirement document has been adjusted from a 6-12 alphanumeric combination to 8-16 characters"; "To optimize user experience, the prompt text for unlogged users in the requirement has been changed from 'Please log in first' to 'Please log in first before operating'"; "A new 'Administrator Batch Inquiry of Account Balance' function has been added, supplementing the corresponding permission constraints and operation process descriptions," etc., ensuring that the original intention and specific content of the change are clearly traceable. The scope of impact field needs to be combined with the "requirement-code" association mapping table and the test case update analysis results to fully define the core scope affected by the change, including the associated requirement elements (such as input parameters, constraints, function points, etc.), the corresponding code logic segments (such as parameter validation branches, permission judgment statements, etc.), and the affected test case information (such as the range of test case numbers, the functional modules covered, and the scenario types). For example, "the input parameter format constraints and output result prompt information in the requirement elements are affected, the if branch of userID format validation and the throw statement of non-login exception handling in the corresponding code are involved, and the test cases TC003-TC008 are involved, covering input validation and permission verification modules in normal and abnormal scenarios." The operation result field must clearly specify the update execution status of the test cases, including the update method (incremental modification or regeneration), update completion status, and verification results. For example, "Incremental modification was performed on the input data format requirements and expected result prompt text of test cases TC003-TC008, updating a total of 6 test cases; after the update, all test cases passed the logic conflict detection and requirement coverage verification, with no redundancy or duplication, and the status is 'valid and available'." "12 test cases were regenerated for the newly added functional points, covering scenarios such as normal batch queries, insufficient permissions interception, and abnormal data dependencies. All newly generated test cases were matched with the code logic and met the test execution requirements." After the change log is generated, it will be stored in order of timestamp and supports retrieval by dimensions such as change reason, scope of impact, and operation time. This not only achieves full traceability of the change process but also provides a clear information synchronization carrier for the testing team, R&D team, and auditors, ensuring the standardization and controllability of the information technology innovation transformation testing process.

[0055] Figure 4 This is a schematic diagram of the structure of an automated test case writing device provided in an embodiment of this application, as shown below. Figure 4As shown, it includes: extraction module 401, first generation module 402, second generation module 403, and adjustment module 404.

[0056] Extraction module 401 is configured to perform structured parsing of the requirements document for information technology innovation transformation and extract the requirements information from the requirements document; The first generation module 402 is configured to connect to the code repository to obtain source code and perform static analysis to generate code logic; The second generation module 403 is configured to establish a semantic association mapping table between requirement information and code logic, generate a test scenario library based on the semantic relationship mapping table, and automatically generate test cases based on parameter types and constraint rules. Adjustment module 404 is configured to perform multi-dimensional verification on the generated test cases, generate verification results, and adjust the priority of the test cases based on the verification results.

[0057] In some examples of this embodiment, the extraction module 401 is specifically configured to use a pre-trained natural language processing model to perform lexical analysis, syntactic analysis, and named entity recognition on the requirement document to extract requirement elements; and generate structured requirement information based on the requirement elements, which include function points, input parameters, output results, and constraints.

[0058] In some examples of this embodiment, the first generation module 402 is specifically configured to implement API integration with the code repository by configuring the repository address, branch name and access token, or to receive the code folder uploaded by the user locally; and to use static code analysis tools to identify function input and output parameters, branch conditions, exception handling logic and data dependencies, and to establish the correspondence between exception handling logic and exception scenarios in the requirements document.

[0059] In some examples of this embodiment, the second generation module 403 is specifically configured to establish a semantic association mapping table between requirement elements and code logic, realize cross-modal information association by matching requirement constraints with code branch judgments; perform semantic-level matching of permission verification constraints in requirement elements with branch judgment logic in code; generate a test scenario library covering normal scenarios, edge scenarios and abnormal scenarios through logical combination analysis; and generate test cases and expected results according to preset templates, wherein the expected result field includes normal output content, abnormal prompt information and permission verification feedback information.

[0060] In some examples of this embodiment, the adjustment module 404 is specifically configured to perform multi-dimensional verification on the generated test cases to generate code defect rate and business impact rate. The multi-dimensional verification includes detecting logical conflicts between cases, calculating the coverage ratio of required functional points, and identifying redundant cases; and adjusting the priority of test cases according to the code defect probability and business impact rate.

[0061] It should be noted that other corresponding descriptions of the functional units involved in the automated test case writing device provided in this embodiment can be found in [reference needed]. Figure 1 , Figure 2 and Figure 3 The corresponding descriptions in [the document] will not be repeated here.

[0062] Based on the above, Figure 1 , Figure 2 and Figure 3 The embodiment illustrates an automated test case writing method. Correspondingly, this embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method. Figure 1 , Figure 2 and Figure 3 This illustrates a method for automating the writing of test cases.

[0063] Based on the above, Figure 1 , Figure 2 and Figure 3 This embodiment illustrates an automated test case writing method. Correspondingly, it also provides a computer program product storing a computer program that, when executed by a processor, implements the above-described method. Figure 1 , Figure 2 and Figure 3 This illustrates a method for automating the writing of test cases.

[0064] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0065] Based on the above, Figure 1 , Figure 2 and Figure 3 This illustrates a method for automating test case writing, and Figure 4 To achieve the above objectives, the present application also provides an electronic device, such as a personal computer or a server, in the illustrated virtual device embodiment. This device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to implement the above-described virtual device. Figure 1 , Figure 2 and Figure 3 This illustrates a method for automating the writing of test cases.

[0066] In some embodiments, the aforementioned physical device may further include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, an input unit such as a keyboard, etc., and optionally, a USB interface, a card reader interface, etc. In some embodiments, the network interface may include a standard wired interface, a wireless interface (such as a Wi-Fi interface), etc.

[0067] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0068] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0069] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for automating the writing of test cases, characterized in that, include: The requirements document for information technology innovation transformation is structured and parsed to extract the requirements information from the document; Connect to the code repository to obtain source code and perform static analysis to generate code logic; Establish a semantic association mapping table between the requirement information and the code logic, generate a test scenario library based on the semantic relationship mapping table, and automatically generate test cases based on parameter types and constraint rules; The generated test cases are validated in multiple dimensions to generate validation results, and the priority of the test cases is adjusted based on the validation results.

2. The method for automatically writing test cases according to claim 1, characterized in that, The process of structuring and parsing the requirement document for information technology innovation transformation and extracting the requirement elements from the document includes: A pre-trained natural language processing model is used to perform lexical analysis, syntactic analysis, and named entity recognition on the requirement document to extract requirement elements; Structured requirement information is generated based on the required elements, which include function points, input parameters, output results, and constraints.

3. The method for automatically writing test cases according to claim 1, characterized in that, The process of obtaining source code from the interfaced code repository and performing static analysis to generate code logic includes: By configuring the repository address, branch name, and access token, the code repository can be integrated with the API, or the code folder uploaded by the user can be received locally. Static code analysis tools are used to identify function input and output parameters, branch conditions, exception handling logic, and data dependencies, and to establish the correspondence between exception handling logic and exception scenarios in the requirements document.

4. The method for automatically writing test cases according to claim 1, characterized in that, The process of establishing a semantic association mapping table between the requirement information and the code logic, generating a test scenario library based on the semantic relationship mapping table, and automatically generating test cases based on parameter types and constraint rules includes: Establish a semantic association mapping table between requirement elements and the code logic, and realize cross-modal information association by matching requirement constraints and code branch judgments; Perform semantic-level matching between the permission verification constraints in the requirement elements and the branch judgment logic in the code; The test scenario library, covering normal, edge, and abnormal scenarios, is generated through logical combination analysis. The test cases and expected results are generated according to the preset template. The expected result field includes normal output content, abnormal prompt information and permission verification feedback information.

5. The method for automatically writing test cases according to claim 1, characterized in that, The step of performing multi-dimensional verification on the generated test cases to generate verification results, and adjusting the priority of the test cases based on the verification results, includes: The generated test cases are subjected to multi-dimensional verification to generate code defect rate and business impact rate. The multi-dimensional verification includes detecting logical conflicts between cases, calculating the coverage ratio of required functional points, and identifying redundant cases. The priority of the test cases is adjusted based on the probability of code defects and the impact on business operations.

6. The method for automatically writing test cases according to claim 1, characterized in that, Also includes: The deployment requirement document change listener captures update events of the requirement document in real time and automatically triggers incremental updates of associated test cases based on the changes in the change events. Based on the changes, a change log is generated that includes the reason for the change, the scope of impact, and the result of the operation.

7. An automated test case writing device, characterized in that, include: The extraction module is configured to perform structured parsing of the requirements document for information technology innovation transformation and extract the requirements information from the requirements document; The first generation module is configured to connect to the code repository to obtain source code and perform static analysis to generate code logic; The second generation module is configured to establish a semantic association mapping table between the requirement information and the code logic, generate a test scenario library based on the semantic relationship mapping table, and automatically generate test cases based on parameter types and constraint rules. The adjustment module is configured to perform multi-dimensional verification on the generated test cases, generate verification results, and adjust the priority of the test cases based on the verification results.

8. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the automated test case writing method according to any one of claims 1-6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the automated test case writing method according to any one of claims 1-6.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method for automating the writing of test cases according to any one of claims 1-6.

Images