Test case generation method and device, equipment and medium

Abstract

The invention relates to the technical field of research and development management and the field of financial science and technology, and discloses a test case generation method, which comprises the following steps of: importing an interface document on a test platform, analyzing the interface document to extract request parameter information, identifying and marking necessary parameters, configuring a verification rule set according to the request parameter information and the necessary parameters, and generating a test case according to the verification rule set. And generating a plurality of test cases based on the request parameter information and the verification rule set, screening a target test case meeting a preset screening condition from the test cases, determining the priority of the target test case based on the business demand, marking the priority, and associating the marked target test case with the interface document. According to the method and the device, the request parameter information is extracted based on the interface document, the necessary parameters are automatically identified, the verification rules are configured, the test cases covering various rule combinations are generated, and the generated test cases are screened and subjected to priority marking in combination with the screening conditions, so that automatic generation and management of the test cases are realized; and the coverage rate and the efficiency of the test are improved.

Description

Technical Field

[0001] The present invention relates to the fields of research and development management technology and financial technology, and in particular to a test case generation method, device, equipment and storage medium. Background Art

[0002] In the bank's credit card channel products and equity business-related systems, the verification of interface rules is an important part of ensuring system stability and data accuracy. However, the interface verification rules of such systems are usually complex and diverse, and the cross-combination scenarios between different parameters are very rich. The traditional method of manually writing test cases is difficult to fully cover all possible rule combinations and business scenarios, and it is very easy to miss tests. In addition, the efficiency of manually writing cases is low and cannot adapt to the efficient iteration requirements of today's agile development, which seriously affects the system's testing effect and development efficiency.

[0003] At present, the popularity of software automated testing has alleviated the manual operation burden in testing work to a certain extent, but there are still significant deficiencies in the automation of rule verification. Existing automated testing technologies often focus on simple verification of single rules, lack in-depth analysis and combination processing of the cross-relationships between complex business rules, and are difficult to meet the large number of complex rule verification needs in banking business.

[0004] Especially in the interface verification related to bank credit card products and equity services, the parameter attributes and rule requirements of various interface messages are diverse, involving a large number of rule combinations and data verification. Therefore, it is difficult to achieve efficient full coverage testing by simply relying on the traditional single rule verification method, which may lead to undiscovered rule conflicts or data errors affecting the normal operation of the business. This requires a solution that can automatically combine and generate test cases for specific rules to improve rule coverage, optimize test efficiency, and reduce business risks.

[0005] In summary, the existing technology is still imperfect in the automation and combination processing of rule verification, and it is difficult to meet the needs of multi-rule verification in complex financial business scenarios. Therefore, an improved automated test case generation method is urgently needed to improve the coverage and efficiency of testing. Summary of the invention

[0006] The main purpose of the present invention is to provide a test case generation method, device, equipment and storage medium, aiming to solve the technical problem that the prior art cannot automatically generate test cases covering multiple rules and complex cross-combinations, making it difficult to fully cover business scenarios, resulting in low testing efficiency and easy omissions.

[0007] To achieve the above object, the present invention provides a test case generation method, comprising:

[0008] Import the interface document on the test platform;

[0009] Parsing the interface document and extracting request parameter information from the interface document;

[0010] Identify and mark the required parameters in the request parameter information;

[0011] According to the request parameter information and the required parameters, configure a corresponding verification rule set;

[0012] Based on the request parameter information and the verification rule set, generate multiple test cases;

[0013] Filter out target test cases that meet preset filtering conditions from the test cases;

[0014] Determining the priority of the target test case based on business requirements, and marking the target test case based on the priority;

[0015] The marked target test case is associated with the interface document.

[0016] Furthermore, to achieve the above object, the present invention provides a test case generating device, comprising:

[0017] Interface document import module, used to import interface documents on the test platform;

[0018] An interface document parsing module, used to parse the interface document and extract request parameter information from the interface document;

[0019] A mandatory parameter identification module, used to identify and mark the mandatory parameters in the request parameter information;

[0020] A verification rule configuration module, used to configure a corresponding verification rule set according to the request parameter information and the required parameters;

[0021] A test case generation module, used to generate multiple test cases based on the request parameter information and the verification rule set;

[0022] A test case screening module, used to screen out target test cases that meet preset screening conditions from the test cases;

[0023] A test case priority marking module, used to determine the priority of the target test case based on business requirements, and mark the target test case based on the priority;

[0024] The test case association module is used to associate the marked target test case with the interface document.

[0025] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a test case generation program stored in the memory and executable on the processor, and the test case generation program, when executed by the processor, implements the steps of the test case generation method as described above.

[0026] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a test case generation program is stored, and when the test case generation program is executed by a processor, the steps of the test case generation method described above are implemented.

[0027] Beneficial effects: The present invention relates to the technical field of R&D management and the field of financial technology, and discloses a test case generation method, which imports an interface document on a test platform, parses the interface document to extract request parameter information, identifies and marks required parameters, configures a verification rule set according to the request parameter information and the required parameters, generates multiple test cases based on the request parameter information and the verification rule set, screens target test cases that meet preset screening conditions from the test cases, determines the priority of the target test cases based on business needs and marks them, and associates the marked target test cases with the interface document. The present invention extracts request parameter information based on the interface document, automatically identifies required parameters and configures verification rules, generates test cases covering multiple rule combinations, and screens and marks the generated test cases in combination with preset screening conditions, thereby realizing automatic generation and management of test cases, significantly improving the coverage and efficiency of the test, reducing the risk of missed tests caused by manual operations, and meeting the needs of efficient testing in complex business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0029] Figure 1 A schematic diagram of an application environment of a test case generation method in an embodiment of the present invention;

[0030] Figure 2 A schematic diagram of a flow chart of an embodiment of a test case generation method of the present invention;

[0031] Figure 3 A schematic diagram of functional modules of a preferred embodiment of a test case generating device of the present invention;

[0032] Figure 4 A schematic diagram of the structure of a computer device in one embodiment of the present invention;

[0033] Figure 5 FIG. 4 is another schematic diagram of the structure of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0034] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0035] The test case generation method provided by the embodiment of the present invention can be applied in Figure 1 In an application environment, the user end communicates with the server end through a network. The server end can import an interface document on a test platform through the user end, parse the interface document to extract request parameter information, identify and mark mandatory parameters, configure a verification rule set according to the request parameter information and the mandatory parameters, generate multiple test cases based on the request parameter information and the verification rule set, filter target test cases that meet preset screening conditions from the test cases, determine the priority of the target test cases based on business needs and mark them, and associate the marked target test cases with the interface document. The present invention extracts request parameter information based on the interface document, automatically identifies mandatory parameters and configures verification rules, generates test cases covering multiple rule combinations, and filters and marks the generated test cases with priority in combination with preset screening conditions, thereby realizing automatic generation and management of test cases, significantly improving the coverage and efficiency of the test, reducing the risk of missed tests caused by manual operations, and meeting the requirements for efficient testing in complex business scenarios. Among them, the user end can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices. The server end can be implemented with an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0036] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a test case generation method provided by the present invention. It should be noted that although a logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0037] like Figure 2 As shown, the test case generation method proposed by the present invention includes the following steps:

[0038] S10, importing the interface document on the test platform;

[0039] In this embodiment, in order to import interface documents, the test platform needs to support a variety of common interface document formats, such as Swagger, OpenAPI, RAML, etc. This requires the platform to have the ability to identify and parse different document formats to ensure that documents can be imported from different sources and systems. In actual implementation, users can select the interface documents they want to import by providing an upload interface or a file selection box. At the same time, the platform deploys a corresponding document parsing engine in the background to parse the supported document formats.

[0040] The user can select the function of importing interface documents on the test platform to trigger the import operation of the platform. This operation includes uploading files, selecting file paths, or calling external interfaces. After receiving the documents imported by the user, the system immediately performs data verification to check the validity and integrity of the documents. The import operation can be implemented through the "Import Document" button provided on the user interface. After clicking this button, the front end will request the user to upload an interface document file or specify a document path. The background program receives the uploaded file and checks the file type, size, content integrity, etc. through the verification module.

[0041] When importing documents, the system will perform validity and integrity checks on the imported interface documents. This includes checking whether the document format is correct, whether the fields are complete, whether there is missing or incorrect data, etc. A document verification service can be implemented in the background to check the basic format, field integrity, keyword compliance, etc. of the document one by one. Documents that pass the verification will enter the next parsing step, otherwise the corresponding error prompt will be returned.

[0042] Example: In the banking business in the financial field, credit card channel products may involve data interaction and interface calls between multiple systems. By importing interface documents through the test platform, it is possible to automatically identify and process various interface document formats in the financial data system, thereby providing basic data support for automated test case generation. For example, a bank can import the OpenAPI document of its credit card management system into the test platform so that the platform can automatically parse and generate efficient test cases to ensure the accuracy and completeness of interface interactions.

[0043] Through the function of importing interface documents, the system can automatically receive and identify interface documents in different formats, reducing the workload of manual work in test preparation, ensuring the efficiency and accuracy of the interface document import process, and laying the foundation for subsequent interface document parsing and test case generation.

[0044] S20, parsing the interface document and extracting request parameter information from the interface document;

[0045] In this embodiment, after importing the interface document, the system first needs to read the interface document. This includes identifying the format of the document (such as OpenAPI, Swagger, RAML, etc.) and scanning the document content as a whole to determine the overall structure of the document. The document content can be read by the document parsing engine inside the system using the corresponding parser (such as JSON or YAML parser) according to the type of document. The read content includes basic information of the document, such as interface path, request method, request parameters, etc.

[0046] After reading the document content, it is necessary to focus on extracting the request parameter information of each interface. Request parameter information usually includes parameter name, parameter type, description, default value, required attributes, etc. Parameter information is the core basic data for subsequent configuration verification rules and test case generation. When the document parsing engine reads the "parameters" part of the document, it can identify and extract detailed information for each request parameter. During the parsing process, the name, type, description and other attributes of the request parameter are obtained through key-value pairs and stored in a data structure (such as a list or dictionary).

[0047] The extracted request parameter information needs to be stored in a structured form to facilitate subsequent operations and processing. This structured data usually includes the hierarchical relationship, nested information, data type, etc. of the parameters. The system can organize the request parameter information into a specific data structure (such as a tree structure, JSON object or table form) through the parsing engine so that it can be quickly accessed and processed in subsequent steps.

[0048] Example: In API interface testing in the financial field, the interface document of a bank credit card application system may contain multiple complex request parameters, such as customer information, credit limit, guarantor information, etc. By parsing the interface document, the system can automatically extract detailed information for each field, such as name, ID number, credit limit, etc., to ensure that subsequent verification and testing can accurately locate each field and achieve comprehensive test coverage.

[0049] By automatically parsing the interface document and extracting the request parameter information, the complexity and error rate of manual document processing can be effectively reduced, ensuring the completeness and accuracy of the parameter information. At the same time, the structured data storage method provides an efficient data foundation for subsequent verification rule configuration and test case generation.

[0050] S30, identifying and marking the required parameters in the request parameter information;

[0051] In this embodiment, after completing the extraction of the request parameter information, the system needs to further analyze these parameters to identify which are required parameters. Required parameters usually contain specific identification fields in the definition of the interface document (such as the "required" field in OpenAPI). The system scans the attribute information of each request parameter to find fields containing required identifiers. For example, for an interface document in JSON format, the parsing engine will locate the "required" attribute field and obtain the parameter names listed therein, identifying them as required parameters.

[0052] The mandatory parameters identified by the system need to be verified with the information of the request parameters to ensure that the identification results are consistent with the mandatory requirements defined in the interface document. This process helps to avoid incorrect identification. The system can check whether there are missing or conflicting mandatory parameters by comparing the list of identified mandatory parameters with the full list of request parameters. If necessary, the system can generate a verification report or warning prompt for the user to review.

[0053] After identifying the required parameters, they need to be marked for priority processing in subsequent steps. The purpose of marking is to ensure that these parameters can be correctly processed and tested when generating test cases later. The system can associate each required parameter with a "required" attribute through a data structure (such as a hash table or attribute field). Each marked required parameter will be stored in the system with a special identifier so that it can be quickly queried and processed in subsequent operations.

[0054] Example: In the API interface test of banking business, such as the credit card application interface, the customer's name, ID number, contact information, etc. are usually required parameters. The system automatically identifies these required parameters to ensure that these key fields will not be omitted or set to null values ​​during the test, avoiding impact on the business process.

[0055] By automatically identifying and marking mandatory parameters, the risk of missing or mis-marking mandatory parameters can be reduced, and the accuracy and comprehensiveness of parameter verification can be improved. The marked mandatory parameters can be processed first in subsequent test case generation and rule configuration to ensure the integrity and accuracy of key parameters.

[0056] S40, configuring a corresponding verification rule set according to the request parameter information and the required parameters;

[0057] In this embodiment, before configuring the validation rules, the system first needs to identify the type of each request parameter, such as string type, numeric type, Boolean type, enumeration type, etc. Different parameter types correspond to different validation rules. The system automatically identifies the type of each parameter by parsing the "type" field of the parameter, and records the type information in the parameter table or mapping table. For example, for an OpenAPI document, the "type" field of the parameter can be directly read to determine the parameter type.

[0058] The system needs to configure basic validation rules based on parameter types and required attributes. Basic rules usually include required validation, non-empty validation, data type validation, etc. to ensure that all required parameters receive the most basic validation. The system automatically generates basic validation rules. For example, for required parameters of string type, non-empty validation can be configured; for numeric types, type validation can be configured. The generation of validation rules can be automatically matched through predefined templates or rule libraries.

[0059] Configure specific validation rules for different types of parameters. For example, string type parameters can be configured with length restrictions and special character validation; numeric type parameters can be configured with minimum and maximum value validation; and enumeration type parameters can be configured with enumeration value validation. The system selects appropriate validation rules from the rule library based on parameter types and business rules, and generates a complete validation rule set. For example, for string type parameters, the system can generate corresponding validation rules based on the configured length restrictions or regular expressions.

[0060] Combine all basic validation rules and specific validation rules to generate a complete validation rule set. Finally, the system associates the generated validation rule set with each parameter information for use in subsequent test case generation. The system associates the basic validation rules and specific validation rules for each parameter and stores them in the validation rule module. The rule set information for each parameter is managed with the parameter ID or parameter name as the index.

[0061] Example: In banking business, such as the credit card limit adjustment interface, the system will automatically configure the minimum and maximum value verification rules according to the type of request parameter (such as amount), and the amount field is marked as required according to business requirements. In this way, the system can automatically check whether all credit card limit adjustment requests comply with business rules to ensure the legality and rationality of all requests.

[0062] By configuring the corresponding verification rule set according to the request parameter information and required parameters, the system can achieve comprehensive verification of parameters and improve the accuracy and consistency of data. The automatically generated rule set reduces the workload of manual configuration, avoids possible human errors, and ensures the standardization and consistency of parameter verification.

[0063] S50, generating multiple test cases based on the request parameter information and the verification rule set;

[0064] In this embodiment, before generating a test case, the system needs to determine the value range of each request parameter based on the request parameter information and the corresponding verification rule set. The value range can be determined based on the parameter type, required attributes, business logic, boundary values, and the requirements in the verification rule set. For parameters of numeric type, the system generates a set of value ranges based on the minimum value, maximum value, and boundary value; for parameters of string type, different string combinations are generated based on length restrictions and special character requirements; for parameters of enumeration type, the enumeration value is directly used as the value range.

[0065] After determining the value range, the system generates multiple value schemes based on different parameters. Each value scheme represents the possible values ​​of the request parameter in different scenarios, with the aim of ensuring that all scenarios and edge cases are covered by the test. You can use the rule generation algorithm to generate different value combinations according to the type and value range of each parameter. For example, for numeric type parameters, the system can generate value combinations such as minimum value, maximum value, normal value, and abnormal value; for string type parameters, you can generate string samples that meet the length limit and special character requirements.

[0066] The system needs to cross-combine all the different value schemes of all request parameters to generate a complete set of test cases. The purpose of cross-combination is to cover all possible combinations between different parameters to ensure the comprehensiveness of the test. Use the cross-combination algorithm to generate value combinations of all request parameters. For example, suppose there are two parameters A and B, each with three values ​​(A1, A2, A3 and B1, B2, B3), the system will generate all possible combinations (such as A1-B1, A1-B2, A2-B3, etc.).

[0067] After generating preliminary test cases, the system needs to verify these cases using the configured verification rule set and filter out cases that do not meet the rules to ensure the effectiveness and rationality of the final generated test cases. The system traverses the initially generated test cases and verifies each case one by one to check whether it meets all relevant verification rules. If a case does not meet any rules, it is marked as invalid and removed from the set.

[0068] Example: In financial services, such as a bank's loan approval system, the interface needs to verify multiple request parameters (such as customer income, loan amount, repayment period, etc.). By generating different test cases, the system can perform combined tests on different income levels, loan amounts, and repayment periods to ensure that the system can correctly handle all possible scenarios and boundary conditions. This comprehensive test case generation method helps improve the stability and accuracy of banking systems.

[0069] By generating multiple test cases based on request parameter information and verification rule sets, it is possible to cover all parameter values ​​and combinations, thus achieving comprehensive testing. The automatic generation and verification process improves test efficiency, reduces the workload of manual case writing, and reduces the risk of missed tests.

[0070] S60, screening out target test cases that meet preset screening conditions from the test cases;

[0071] In this embodiment, after generating multiple test cases, it is necessary to predefine screening conditions according to business requirements and test objectives. These screening conditions are used to determine which test cases can meet the coverage requirements and business verification requirements. The screening conditions may include parameter coverage, integrity of rule verification, boundary value verification, specific business logic, etc. A set of standard screening conditions can be preset in the system, such as: all required parameters must have valid values, each test case should cover certain boundary values, or the legality of parameter combinations. Users can also customize screening conditions and set specific screening rules through the configuration interface.

[0072] Before applying the screening conditions, a preliminary check is required for all generated test cases to identify the attribute information of each case and the degree to which the conditions are met. The preliminary check helps to provide accurate case basic data for subsequent screening operations. The system traverses all generated test cases, records the attributes of each case, and calculates the case coverage, boundary value, etc. In this way, basic attribute information and inspection records can be established for each case.

[0073] Based on the preset filtering conditions, the generated test cases are screened one by one to select the target test cases that meet the conditions. The application process of the filtering conditions needs to be completed by comparing the properties of each test case with the preset filtering criteria. The system uses an algorithm to evaluate each test case to check whether it meets all the preset filtering conditions. For cases that do not meet the conditions, the system excludes them from the target case set; cases that meet the conditions are marked as "target test cases".

[0074] After screening out the target test cases that meet the conditions, these cases need to be marked. The purpose of marking is to quickly locate and manage the target cases in subsequent tests. The target test cases can be specially marked through data structures (such as Boolean tags or labels) so that these cases can be distinguished and prioritized in the system's test case management module.

[0075] Example: In financial services, such as the loan approval interface test of a bank, the interface needs to verify multiple parameter combinations. The screening conditions may include the legal range of customer income, the boundary value verification of the loan amount, the rationality of the repayment period, etc. By defining these screening conditions, the system can automatically filter out test cases that meet the bank's business rules, ensuring that key test cases are verified first, thereby improving the reliability of the loan approval system.

[0076] By selecting target test cases that meet preset conditions from the generated test cases, the system can accurately locate cases that are critical to business logic and rule verification, avoid a large number of redundant and invalid test cases, and improve the accuracy and efficiency of testing. At the same time, marking target test cases can facilitate subsequent management and tracking.

[0077] S70, determining the priority of the target test case based on business requirements, and marking the target test case based on the priority;

[0078] In this embodiment, before the target test cases are prioritized, the business requirements and test objectives need to be clarified. Different business requirements determine which test cases are more critical, such as important business scenarios, frequently used functions, and operations with a large impact. System administrators or testers can pre-define the priority of business requirements, such as high, medium, and low levels. The system's built-in business rule library can automatically identify the priority of certain common business scenarios based on business characteristics.

[0079] Based on the identified business requirements and test objectives, the system needs to set priority criteria for each test case. Priority criteria can be based on factors such as business impact, risk level, execution frequency, or business importance. The system can allow users to set priority criteria through the configuration interface, or automatically assign priorities by analyzing the relevant attributes of the test case (such as business impact parameters). For example, test cases for core business operations will be set to high priority, while cases for marginal business will be set to low priority.

[0080] After determining the priority criteria, the system needs to calculate the priority of each target test case. The priority is calculated based on the weight of the business requirements and the attribute information of the test case. The system can use a weighted algorithm to assign a priority score based on the weight of each factor. The higher the score, the higher the priority. Finally, each target test case is classified and arranged by priority.

[0081] After the priority calculation is completed, each target test case is marked so that cases of different priorities can be quickly identified and processed in subsequent test management and execution. The system can use tags or fields to mark the priority of each target test case (such as high, medium, and low), and store the marking results in the test case management module for subsequent test management and scheduling.

[0082] Example: In banking business, such as interface testing of a credit card approval system, different approval operations may correspond to different priorities. The initial review of credit card applications and the adjustment of credit limits are key business scenarios, so the test cases for these operations are set to high priority. In this way, the system can prioritize the verification of important business operations when testing resources are limited, ensuring that the core functions of the banking system always run stably.

[0083] By prioritizing target test cases based on business needs and marking them, the system can reasonably schedule resources, prioritize testing of key business scenarios, improve test efficiency and coverage, and reduce business risks. Automatic marking of priorities helps to accurately execute subsequent tests and effectively track results.

[0084] S80, associating the marked target test case with the interface document.

[0085] In this embodiment, after completing the marking of the target test case, it is necessary to associate these marked target test cases with the corresponding interface documents. The establishment of the association relationship can be achieved through a data structure (such as a mapping table or a relationship table) so that the source of the test case and the corresponding interface can be quickly traced in subsequent operations. The system will generate a mapping table or an association relationship table based on the unique identification of each test case (such as a test case ID) and the mapping relationship between the request path, method, and parameters in the interface document. In this way, each test case will have a corresponding interface information.

[0086] During the association process, it is also necessary to record the metadata information between the test case and the interface document, such as the generation time of the test case, the interface path corresponding to the case, the request method, the test environment, etc. This allows for quick location of problems during subsequent testing and analysis. The system can add metadata fields to the association table to record detailed interface information and other related attributes (such as interface version number, generation time, etc.) corresponding to each test case. This helps provide complete context information during backtracking or analysis.

[0087] After the establishment of the association relationship and the recording of metadata are completed, this information needs to be stored in the system's database to facilitate subsequent test management, version control, and result tracking. The system stores the association relationship table and metadata records in a dedicated table of the database through the interface management module. The storage format can be the table structure of a relational database or the nested document structure of a document database.

[0088] After the associated data is stored, the system needs to provide query and update interfaces to support subsequent test management and document update operations. For example, when the interface document is updated or changed, the system should be able to automatically update or adjust the association relationship. The system can provide query and update functions through API or background management interface, and users or system administrators can view, modify or synchronize the association information between test cases and interface documents through these interfaces.

[0089] Example: In the API testing of financial services, such as the credit card approval interface testing of banks, by associating the generated test cases with the corresponding interface documents, it can help testers quickly locate the interface and business scenario to which each test case belongs. If the interface path or request method changes, the system can automatically identify and remind users to update the corresponding test cases to ensure that the test is always consistent with the document.

[0090] By associating the marked target test cases with the interface documents, a reliable document basis can be provided for test management and problem tracking. Establishing an association relationship helps to quickly locate and analyze the correspondence between the test cases and the interface documents, improve the traceability and maintainability of the test, and facilitate the rapid synchronization and update of the test cases when the interface changes.

[0091] The present invention relates to the technical field of R&D management and the field of financial technology, and discloses a test case generation method, which includes importing an interface document on a test platform, parsing the interface document to extract request parameter information, identifying and marking mandatory parameters, configuring a verification rule set according to the request parameter information and the mandatory parameters, generating multiple test cases based on the request parameter information and the verification rule set, screening target test cases that meet preset screening conditions from the test cases, determining the priority of the target test cases based on business needs and marking them, and associating the marked target test cases with the interface document. The present invention extracts request parameter information based on an interface document, automatically identifies mandatory parameters and configures verification rules, generates test cases covering a variety of rule combinations, and screens and marks the generated test cases in combination with preset screening conditions, thereby realizing automatic generation and management of test cases, significantly improving the coverage and efficiency of the test, reducing the risk of missed tests caused by manual operations, and meeting the requirements for efficient testing in complex business scenarios.

[0092] In one embodiment, the above S40 includes:

[0093] S401, identifying the type of each request parameter in the request parameter information, where the type includes a string type, a numerical type, and an enumeration type;

[0094] S402, based on the type of each request parameter and whether the request parameter is a mandatory parameter, set basic verification rules including mandatory verification and non-empty verification;

[0095] S403, configuring length restriction and special character verification rules for the string type parameter;

[0096] S404, configuring minimum and maximum value checking rules for the parameters of the numerical type;

[0097] S405, configuring enumeration value verification rules for the parameters of the enumeration type;

[0098] S406, combining the basic verification rules, length limit and special character verification rules, minimum value and maximum value verification rules, and enumeration value verification rules to generate a verification rule set, and associating the verification rule set with the interface document.

[0099] In this embodiment, before configuring the verification rules, the system needs to analyze the information of each request parameter and identify the type of the parameter. The types of request parameters mainly include string type, numeric type, and enumeration type. The purpose of identifying parameter types is to configure corresponding verification rules for different types. By parsing the attribute fields of each parameter in the interface document, the system can automatically identify the type of each request parameter. For example, in the OpenAPI document, the specific data type of each parameter can be identified by reading the "type" attribute.

[0100] The system configures basic validation rules based on the type of each request parameter and whether it is a required parameter. Basic rules include required validation and non-empty validation, which are used to ensure that all required parameters have legal values. For parameters marked as required, the system automatically configures required validation rules, requiring these parameters to contain valid values ​​in all test cases. At the same time, for all types of parameters, the system configures non-empty validation rules by default to prevent parameter values ​​from being empty.

[0101] For string type parameters, the system needs to configure special validation rules, such as length restriction and special character validation. Length restriction is used to control the minimum and maximum number of characters in a parameter, while special character validation is used to detect whether the parameter contains illegal characters. The system automatically generates length restriction rules based on the attributes of string type parameters defined in the document, and sets the minimum and maximum allowed lengths. At the same time, through the predefined rule base, the system can configure special character validation rules to detect whether the string contains illegal characters.

[0102] For numeric parameters, the system needs to configure the value range validation rules to ensure that the parameter value is within a reasonable range. The minimum and maximum value validation rules are used to limit the value range of the parameter. The system automatically configures the minimum and maximum value validation rules based on the attributes of the numeric parameters in the document. For example, for numeric parameters, the system can determine the allowed value range by reading the "minimum" and "maximum" attributes.

[0103] For enumeration type parameters, the system needs to configure enumeration value verification rules to ensure that the parameter value is in the predefined enumeration value list. Enumeration value verification can prevent parameter values ​​from taking illegal values. The system extracts the "enum" attribute of the enumeration type parameter from the interface document and automatically generates enumeration value verification rules, requiring that the parameter value must be in the predefined enumeration list.

[0104] After configuring the basic validation rules, length restrictions, special character validation rules, numeric range validation rules, and enumeration value validation rules, the system needs to combine all the rules together to form a complete validation rule set. Finally, the generated rule set needs to be associated with the interface document for application in subsequent tests. The system merges the validation rules for each parameter and associates the rule set with the corresponding interface document for storage. A data structure (such as a hash table) can be used to establish a mapping relationship between the parameter ID and the rule set to ensure that the rule set is correctly applied in all request operations of the interface.

[0105] This embodiment automatically configures the verification rule set according to the request parameter information and the required parameters, so that the system can ensure that all parameters are reasonably and comprehensively verified, reduce the risk of errors in manual configuration, and ensure the standardization and consistency of the verification rules. The system can adapt to different types of parameters and automatically generate rules that meet business needs, thereby improving the accuracy and coverage of the test.

[0106] In one embodiment, the above S50 includes:

[0107] S501, identifying the type of each request parameter in the request parameter information, and determining a value range of each request parameter based on the type;

[0108] S502, generating a plurality of different values ​​for each request parameter according to the verification rule set and the value range of each request parameter;

[0109] S503, cross-combining different values ​​of all request parameters to generate a preliminary test case set;

[0110] S504: Use the verification rule set to verify the preliminary test case set to obtain verified test cases.

[0111] In this embodiment, before generating a test case, the system needs to identify the type of each request parameter based on the request parameter information. The types of request parameters include string type, numeric type, and enumeration type. The purpose of identifying the parameter type is to determine the value range of each parameter, such as the boundary value of the numeric value, the length range of the string, or the list of enumeration values. The system identifies the parameter type based on the "type" field in the interface document, and automatically determines the value range of each parameter by reading related attributes (such as minimum value, maximum value, enumeration list, etc.). For example, for parameters of numeric type, the value range can be determined by the "minimum" and "maximum" attributes; for parameters of enumeration type, the value range is determined by the predefined "enum" value.

[0112] The system generates multiple different values ​​for each request parameter based on the validation rule set and the value range of each request parameter. These values ​​need to cover all possible valid values, boundary values, abnormal values, etc. to ensure the comprehensiveness of the test. The system uses a rule generation algorithm to automatically generate different values ​​based on the type and value range of each request parameter. For example, for a numeric parameter, the system generates a set of values, including the minimum value, maximum value, normal value, and abnormal value that exceeds the range; for a string parameter, it generates strings of different lengths and special character combinations.

[0113] The system needs to cross-combine the different values ​​of all request parameters to generate a preliminary set of test cases. The purpose of cross-combination is to cover all possible parameter value combinations to test the changes in each scenario. The system uses a cross-combination algorithm to arrange and combine the different values ​​of each request parameter to generate all possible parameter combinations. For example, suppose there are two parameters A and B, each with three different values ​​(A1, A2, A3 and B1, B2, B3), the system will generate all possible combinations (such as A1-B1, A1-B2, A2-B3, etc.).

[0114] After generating preliminary test cases, you need to use the configured validation rule set to verify these test cases and filter out cases that do not meet the rules. The purpose of verification is to ensure that the generated test cases meet the requirements of the interface document and business rules. The system traverses each preliminary generated test case and applies the validation rule set to check them one by one. For cases that do not meet the rules, the system will mark them as invalid and remove them, and finally obtain verified valid test cases.

[0115] This embodiment generates multiple test cases based on request parameter information and verification rule sets, and the system can ensure that the test cases cover all possible value combinations and business rules. The automatic generation and verification process can reduce the risk of manual configuration errors, improve the comprehensiveness and accuracy of the test, and improve the test efficiency.

[0116] In one embodiment, after the above S80, the method further includes:

[0117] S901, counting the value of each request parameter in the target test case and the applied verification rule;

[0118] S902, analyzing the coverage of each request parameter in the target test case according to the statistical results;

[0119] S903, based on the analysis result of the coverage degree, identifying insufficiently covered request parameters and verification rules;

[0120] S904, generating supplementary test cases for the insufficiently covered request parameters and verification rules.

[0121] In this embodiment, after the target test case is associated with the interface document, it is necessary to count the values ​​of all request parameters and the verification rules applied in each target test case. The statistical content includes the value of each parameter, the number of times the value is taken, and the specific verification rules applied. The purpose of this step is to provide basic data for subsequent coverage analysis. The system can extract the values ​​of each request parameter in each case by parsing and traversing all target test cases, and record the number and range of these values. At the same time, the verification rules applied for each parameter are counted, including basic verification rules, specific types of verification rules, etc. All statistical results are stored in a data table or database table.

[0122] Based on the statistical values ​​and verification rules, the system needs to analyze the coverage of each request parameter in the target test case. The coverage analysis includes checking whether the value of each parameter completely covers all possible valid value ranges and whether the verification rules are fully applied to all relevant parameters. The system uses analysis tools to calculate the value data of each request parameter, such as the coverage of the boundary value of the statistical parameter and the coverage of the valid value range. For the analysis of the verification rules, the application frequency of each rule and the number of applicable parameters can be checked.

[0123] Based on the analysis results of the coverage, the system needs to identify the request parameters and verification rules that are insufficiently covered. Insufficient coverage may mean that some parameters are not fully tested or some verification rules are not fully verified. The purpose of identifying parameters and rules with insufficient coverage is to focus on them when generating supplementary test cases later. The system can set a preset coverage threshold. When the coverage of a parameter or verification rule is lower than the threshold, the system will mark it as "insufficient coverage". All identified deficiency information will be recorded in a separate supplementary list.

[0124] After identifying the insufficiently covered request parameters and verification rules, you need to generate supplementary test cases to improve the coverage of these parameters and rules. The process of generating supplementary test cases includes re-combining values ​​for the insufficiently covered parts and generating new test cases. Based on the information in the supplementary list, the system generates new value ranges and parameter combinations, focusing on covering the insufficiently covered request parameters and verification rules. In this way, you can fill in the gaps in coverage in the previous test cases and improve the overall comprehensiveness of the test.

[0125] In this embodiment, by counting and analyzing the target test cases, the system can automatically identify the request parameters and verification rules that are insufficiently covered, and generate supplementary test cases. This process can improve the coverage of test cases, reduce the risk of missing scenarios or rule verification, and ensure the comprehensiveness and accuracy of the test.

[0126] In one embodiment, the above S30 includes:

[0127] S301, parsing the request parameter information, and obtaining attribute information of each request parameter in the request parameter information;

[0128] S302, analyzing the attribute information of the request parameters, and identifying the request parameters including the required flag in the attribute information;

[0129] S303: Mark the identified request parameters as required parameters.

[0130] In this embodiment, before identifying the required parameters, the system needs to parse the request parameter information extracted from the interface document. The purpose of the parsing is to obtain the attribute information of each request parameter, which usually includes the parameter name, data type, description, whether it is required, default value, etc. The system can extract the detailed properties of each parameter by traversing the structured data of the request parameter information (such as JSON or YAML format). A common method is to read and parse the attribute information of each parameter one by one according to the standard interface document structure (such as the "properties" field of OpenAPI).

[0131] After obtaining the attribute information of each request parameter, the system needs to analyze the attribute information and focus on identifying the parameters that contain the "required flag". The required flag is usually a field or attribute in the interface document (such as the "required" field). During the analysis process, the system checks whether each request parameter is marked as required in the "required" field or similar fields. By comparing the parameter name with the entries in the required flag field, it automatically identifies which parameters are required.

[0132] After identifying request parameters that contain mandatory flags, the system needs to mark these parameters as "required parameters" so that they can be specially handled during subsequent rule configuration and test case generation. The purpose of marking is to ensure that these parameters are not omitted in all test scenarios. The system can mark the identified mandatory parameters by adding a Boolean "required" field or using a tag. For example, you can add an "isRequired" field to the parameter data table and set the value of the mandatory parameter to "true".

[0133] This embodiment can reduce the workload of manual configuration by parsing the request parameter information, automatically identifying and marking the required parameters, ensuring that the required parameters are not omitted or incorrectly marked, and improving the integrity and accuracy of the test data. The system can quickly identify and process a large number of parameters, improving configuration efficiency.

[0134] In one embodiment, after the above S20, the method further includes:

[0135] S201, analyzing the request parameter information to determine the hierarchical relationship between the request parameters;

[0136] S202, generating nested association information between request parameters according to the hierarchical relationship;

[0137] S203: Generate a tree structure for displaying the hierarchical structure of the request parameters based on the nested association information.

[0138] In this embodiment, after extracting the request parameter information, the system needs to analyze these parameters to determine the hierarchical relationship between them. Hierarchical relationships generally refer to parent-child relationships or nested relationships between parameters. For example, a parameter may be a sub-parameter of another complex parameter. This analysis helps the system maintain the structure and relevance of parameters in subsequent operations. The system can check whether there is a nested relationship by parsing the attribute information of each request parameter. For example, in an OpenAPI document, if a parameter of an object type contains multiple sub-parameters, there is a hierarchical relationship between these sub-parameters. The system determines their hierarchical relationship based on the "type", "properties" or other relevant attributes of the parameters.

[0139] After determining the hierarchical relationship, the system needs to generate nested association information between request parameters. Nested association information is used to describe the parent-child relationship and nested structure between each request parameter. This information is essential for display and subsequent processing. The system can use a nested tree structure or graph structure to record this association information. Each parent parameter node establishes a link relationship with its child parameter node to generate a parameter nested graph or tree data structure. Data structures such as tree dictionaries or JSON nested formats can be used to represent this information.

[0140] Based on the generated nested association information, the system can generate a tree structure to display the hierarchical relationship of the request parameters. The display of the tree structure helps users to intuitively view and manage the hierarchy and nested relationship of the request parameters in a graphical interface. The system can generate an interactive tree diagram through the front-end interface to display each request parameter node and its nested relationship. The front-end can use common tree diagram drawing tools or libraries, such as D3.js, TreeView, etc. Each node represents a request parameter, and users can expand and collapse nodes to view their sub-parameters.

[0141] By generating nested association information and a tree structure between request parameters, the system can better display and manage complex request parameters, allowing users to intuitively understand the hierarchical relationship of parameters. The nested association information helps maintain the integrity and consistency of parameters in subsequent test case generation and rule configuration.

[0142] In one embodiment, the above S60 includes:

[0143] S601, analyze business requirements and test objectives, and determine the coverage and verification requirements for test cases;

[0144] S602, based on the coverage and verification requirements, defining screening conditions including parameter coverage, boundary value verification, completeness of rule verification and / or parameter dependency;

[0145] S603: Filter out target test cases that meet the screening condition from the test cases according to the screening condition.

[0146] In this embodiment, in order to filter out target test cases that meet preset conditions from test cases, it is first necessary to clarify business requirements and test objectives. The purpose of this step is to determine the coverage and verification requirements of test cases based on specific business functions or requirements. The coverage may include the breadth of parameter values, verification of special scenarios, integrity of business logic, etc. Based on a pre-defined list of business requirements and combined with the user's business knowledge, the system can analyze which scenarios or functions require higher test coverage. At the same time, the system will define the verification requirements for each parameter or rule, such as boundary values ​​and special values ​​that need to be verified, in combination with business functions and test objectives.

[0147] Based on the coverage and verification requirements, filter conditions need to be defined. Filter conditions are used to measure whether the test cases can meet the preset test standards and business requirements. These filter conditions may include: parameter coverage, boundary value verification, completeness of rule verification, parameter dependency, etc. The definition of filter conditions can cover various requirements for all relevant test cases. The system can use algorithms or rule libraries to predefine different types of filter conditions. For example, parameter coverage filter conditions can require that all parameters need to be tested within different value ranges; boundary value verification conditions can require testing of extreme values ​​of each parameter (such as maximum and minimum values); parameter dependency conditions can ensure that certain parameters must have specific values ​​or combinations under certain circumstances.

[0148] After defining the screening conditions, the system needs to filter out the target test cases that meet the requirements from all the generated test cases based on these conditions. The screening process requires checking each test case one by one to see if it meets all the screening conditions. The system can evaluate each test case one by one through the logic or algorithm of conditional judgment to check whether it meets the defined screening conditions. If a test case meets all the conditions, it will be marked as a "target test case". Cases that do not meet the conditions will be excluded or screened again.

[0149] This embodiment defines screening conditions according to coverage and verification requirements, and screens target test cases according to these conditions, so as to ensure that all test scenarios and key parameters are fully verified. The screened target test cases can cover the core scenarios of business requirements and ensure the correctness of system functions and logic.

[0150] In one embodiment, a test case generation device is provided, and the test case generation device corresponds one-to-one to the test case generation method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the test case generation device of the present invention. Interface document import module 10, interface document parsing module 20, required parameter identification module 30, verification rule configuration module 40, test case generation module 50, test case screening module 60, test case priority marking module 70 and test case association module 80. The functional modules are described in detail as follows:

[0151] The interface document import module 10 is used to import the interface document on the test platform;

[0152] An interface document parsing module 20, used to parse the interface document and extract request parameter information from the interface document;

[0153] A mandatory parameter identification module 30, used to identify and mark mandatory parameters in the request parameter information;

[0154] A verification rule configuration module 40, configured to configure a corresponding verification rule set according to the request parameter information and the required parameters;

[0155] A test case generation module 50, configured to generate a plurality of test cases based on the request parameter information and the verification rule set;

[0156] A test case screening module 60 is used to screen out target test cases that meet preset screening conditions from the test cases;

[0157] A test case priority marking module 70, configured to determine the priority of the target test case based on business requirements, and mark the target test case based on the priority;

[0158] The test case associating module 80 is used to associate the marked target test case with the interface document.

[0159] In one embodiment, the verification rule configuration module 40 is specifically used to:

[0160] Identify the type of each request parameter in the request parameter information, where the type includes a string type, a numerical type, and an enumeration type;

[0161] Based on the type of each request parameter and whether the request parameter is a mandatory parameter, set basic validation rules including mandatory validation and non-empty validation;

[0162] Configure length restrictions and special character validation rules for the string type parameters;

[0163] Configure minimum and maximum value validation rules for the parameters of the numerical type;

[0164] Configure enumeration value verification rules for the parameters of the enumeration type;

[0165] The basic validation rules, the length restriction and special character validation rules, the minimum value and maximum value validation rules, and the enumeration value validation rules are combined to generate a validation rule set, and the validation rule set is associated with the interface document.

[0166] In one embodiment, the test case generation module 50 is specifically configured to:

[0167] Identifying the type of each request parameter in the request parameter information, and determining a value range of each request parameter based on the type;

[0168] Generating a plurality of different values ​​for each request parameter according to the verification rule set and the value range of each request parameter;

[0169] Cross-combine different values ​​of all request parameters to generate a preliminary set of test cases;

[0170] The preliminary test case set is verified using the verification rule set to obtain the verified test cases.

[0171] In one embodiment, the test case association module 80 is specifically configured to:

[0172] Counting the value of each request parameter and the applied verification rules in the target test case;

[0173] Based on the statistical results, analyze the coverage of each request parameter in the target test case;

[0174] Based on the analysis result of the coverage degree, identifying the request parameters and verification rules with insufficient coverage;

[0175] Supplementary test cases are generated for the insufficiently covered request parameters and verification rules.

[0176] In one embodiment, the mandatory parameter identification module 30 is specifically used to:

[0177] Parsing the request parameter information to obtain attribute information of each request parameter in the request parameter information;

[0178] Analyze the attribute information of the request parameter, and identify the request parameter including a required mark in the attribute information;

[0179] Marks the identified request parameters as required.

[0180] In one embodiment, the interface document parsing module 20 is specifically used to:

[0181] Analyze the request parameter information to determine the hierarchical relationship between the request parameters;

[0182] Generate nested association information between request parameters according to the hierarchical relationship;

[0183] Based on the nested association information, a tree structure for displaying the hierarchical structure of the request parameters is generated.

[0184] In one embodiment, the test case screening module 60 is specifically used to:

[0185] Analyze business requirements and test objectives, and determine the coverage and verification requirements for test cases;

[0186] Based on the coverage and verification requirements, define screening criteria including parameter coverage, boundary value verification, completeness of rule verification and / or parameter dependency;

[0187] According to the screening condition, target test cases meeting the screening condition are screened out from the test cases.

[0188] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a test case generation method server side.

[0189] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a test case generation method

[0190] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the following steps are implemented:

[0191] Import the interface document on the test platform;

[0192] Parsing the interface document and extracting request parameter information from the interface document;

[0193] Identify and mark the required parameters in the request parameter information;

[0194] According to the request parameter information and the required parameters, configure a corresponding verification rule set;

[0195] Based on the request parameter information and the verification rule set, generate multiple test cases;

[0196] Filter out target test cases that meet preset filtering conditions from the test cases;

[0197] Determining the priority of the target test case based on business requirements, and marking the target test case based on the priority;

[0198] The marked target test case is associated with the interface document.

[0199] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0200] Import the interface document on the test platform;

[0201] Parsing the interface document and extracting request parameter information from the interface document;

[0202] Identify and mark the required parameters in the request parameter information;

[0203] According to the request parameter information and the required parameters, configure a corresponding verification rule set;

[0204] Based on the request parameter information and the verification rule set, generate multiple test cases;

[0205] Filter out target test cases that meet preset filtering conditions from the test cases;

[0206] Determining the priority of the target test case based on business requirements, and marking the target test case based on the priority;

[0207] The marked target test case is associated with the interface document.

[0208] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0209] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0210] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0211] It should be noted that if software tools or components other than those of the Company appear in the embodiments of the present application, they are only used for illustration and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the above-mentioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents; and these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A test case generation method, characterized in that: The following steps are involved: Import the interface document on the test platform; Parsing the interface document and extracting request parameter information from the interface document; Identify and mark the required parameters in the request parameter information; According to the request parameter information and the required parameters, configure a corresponding verification rule set; Based on the request parameter information and the verification rule set, generate multiple test cases; Filter out target test cases that meet preset filtering conditions from the test cases; Determining the priority of the target test case based on business requirements, and marking the target test case based on the priority; The marked target test case is associated with the interface document.

2. The test case generation method according to claim 1, characterized in that: According to the request parameter information and the required parameters, a corresponding verification rule set is configured, including: Identify the type of each request parameter in the request parameter information, where the type includes a string type, a numerical type, and an enumeration type; Based on the type of each request parameter and whether the request parameter is a mandatory parameter, set basic validation rules including mandatory validation and non-empty validation; Configure length restrictions and special character validation rules for the string type parameters; Configure minimum and maximum value validation rules for the parameters of the numerical type; Configure enumeration value verification rules for the parameters of the enumeration type; The basic validation rules, the length restriction and special character validation rules, the minimum value and maximum value validation rules, and the enumeration value validation rules are combined to generate a validation rule set, and the validation rule set is associated with the interface document.

3. The test case generation method according to claim 1, characterized in that: Based on the request parameter information and the verification rule set, multiple test cases are generated, including: Identifying the type of each request parameter in the request parameter information, and determining a value range of each request parameter based on the type; Generating a plurality of different values ​​for each request parameter according to the verification rule set and the value range of each request parameter; Cross-combine different values ​​of all request parameters to generate a preliminary set of test cases; The preliminary test case set is verified using the verification rule set to obtain the verified test cases.

4. The test case generation method according to claim 1, characterized in that: After associating the marked target test case with the interface document, the following further includes: Counting the value of each request parameter and the applied verification rules in the target test case; Based on the statistical results, analyze the coverage of each request parameter in the target test case; Based on the analysis result of the coverage degree, identifying the request parameters and verification rules with insufficient coverage; Supplementary test cases are generated for the insufficiently covered request parameters and verification rules.

5. The test case generation method according to claim 1, characterized in that: Identify and mark the required parameters in the request parameter information, including: Parsing the request parameter information to obtain attribute information of each request parameter in the request parameter information; Analyze the attribute information of the request parameter, and identify the request parameter including a required mark in the attribute information; Marks the identified request parameters as required.

6. The test case generation method according to claim 1, characterized in that: After parsing the interface document and extracting request parameter information from the interface document, the method further includes: Analyze the request parameter information to determine the hierarchical relationship between the request parameters; Generate nested association information between request parameters according to the hierarchical relationship; Based on the nested association information, a tree structure for displaying the hierarchical structure of the request parameters is generated.

7. The test case generation method as claimed in claim 1, characterized in that: Filtering target test cases that meet preset screening conditions from the test cases includes: Analyze business requirements and test objectives, and determine the coverage and verification requirements for test cases; Based on the coverage and verification requirements, define screening criteria including parameter coverage, boundary value verification, completeness of rule verification and / or parameter dependency; According to the screening condition, target test cases meeting the screening condition are screened out from the test cases.

8. A test case generating device, characterized in that: The test case generating device comprises: Interface document import module, used to import interface documents on the test platform; An interface document parsing module, used to parse the interface document and extract request parameter information from the interface document; A mandatory parameter identification module, used to identify and mark the mandatory parameters in the request parameter information; A verification rule configuration module, used to configure a corresponding verification rule set according to the request parameter information and the required parameters; A test case generation module, used to generate multiple test cases based on the request parameter information and the verification rule set; A test case screening module, used to screen out target test cases that meet preset screening conditions from the test cases; A test case priority marking module, used to determine the priority of the target test case based on business requirements, and mark the target test case based on the priority; The test case association module is used to associate the marked target test case with the interface document.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a test case generation program stored in the memory and executable on the processor. When the test case generation program is executed by the processor, the steps of the test case generation method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The storage medium stores a test case generation program, and when the test case generation program is executed by the processor, the steps of the test case generation method according to any one of claims 1 to 7 are implemented.

Images