Api test case generation method, apparatus, and medium

Abstract

The present disclosure relates to API test case generation methods, apparatuses, and media. An API test case generation method is provided, including: extracting parameter metadata of one or more API parameters from an API definition document; establishing a dependency relationship model between the one or more API parameters according to the API definition document, wherein the dependency relationship model includes one or more constraint rules, and a constraint rule in the one or more constraint rules is used to describe a constraint between values of a corresponding API parameter in the one or more API parameters; generating one or more value combinations of the one or more API parameters using a combinatorial test algorithm and weighted random sampling according to the dependency relationship model; and inputting the generated one or more value combinations into a predefined test template to generate one or more API test cases.

Description

Technical Field

[0001] This disclosure relates to the field of software testing technology, and more specifically, to methods, apparatus and media for generating API test cases. Background Technology

[0002] Current API testing primarily relies on manually written test scripts. However, with the increasing number and complexity of parameters, the sheer number of permutations and combinations leads to an explosive growth in test cases. Manual methods struggle to adequately cover parameter dependencies and exceptional scenarios, and maintenance costs are prohibitively high. While combinatorial testing methods such as orthogonal arrays can reduce the number of test cases, they cannot differentiate the importance of parameters and are ill-equipped to handle complex business constraints.

[0003] Therefore, a new method, apparatus, and medium for generating API test cases are needed. Summary of the Invention

[0004] The embodiments of this application provide an API test case generation method, apparatus, and medium, which can automatically and efficiently generate API test cases covering core functions and edge anomalies while meeting complex parameter constraints, significantly improving testing efficiency and coverage.

[0005] According to a first aspect of this application, an API test case generation method is provided, comprising: extracting parameter metadata of one or more API parameters from an API definition document, wherein the parameter metadata includes parameter name, data type, value range, and default value; establishing a dependency model between the one or more API parameters based on the API definition document, wherein the dependency model includes one or more constraint rules, wherein the constraint rules in the one or more constraint rules are used to describe the constraints between the values ​​of corresponding API parameters in the one or more API parameters; generating one or more combinations of values ​​of the one or more API parameters using a combinatorial testing algorithm and weighted random sampling based on the dependency model, wherein the weighted random sampling performs high-frequency sampling on the core parameters of the one or more API parameters, and the weighted random sampling injects random interference into the edge parameters of the one or more API parameters; and inputting the generated one or more combinations of values ​​into a predefined test template to generate one or more API test cases.

[0006] According to an embodiment of the first aspect of this application, the API definition document is in one of the following formats: OpenAPI, RAML, API Blueprint, GraphQL Schema, gRPC Proto, or PostmanCollection, and the extraction is performed by a parser corresponding to the format.

[0007] According to an embodiment of the first aspect of this application, the one or more constraint rules are in one of the following formats: logical expressions, decision tables, JSON rules, or domain-specific language (DSL), and the one or more constraint rules are stored in a constraint rule library.

[0008] According to an embodiment of the first aspect of this application, the one or more constraint rules include at least one of the following rules: mandatory condition rule, optional condition rule, mutual exclusion rule, inclusion relationship rule, numerical relationship rule, format dependency rule, or combined constraint rule.

[0009] According to an embodiment of the first aspect of this application, the combined testing algorithm is one of the following algorithms: orthogonal experiment method or pairing combination, and the combined testing algorithm is used to achieve the coverage of the value combination on the one or more API parameters.

[0010] According to an embodiment of the first aspect of this application, generating one or more combinations of values ​​for the one or more API parameters using a combinatorial testing algorithm and weighted random sampling based on the dependency model includes: assigning a weight to each of the one or more API parameters, wherein the weight of the core parameter is higher than the weight of the edge parameter; randomly selecting values ​​of the one or more API parameters within the value range of the one or more API parameters according to the weight of each of the one or more API parameters to form one or more candidate value combinations, wherein the number of values ​​of the core parameter with high weight is higher than the number of values ​​of the edge parameter with low weight; using a constraint engine to verify whether the candidate value combinations among the one or more candidate value combinations satisfy all constraint rules in the dependency model; if all constraint rules are satisfied, using the candidate value combination as the generated value combination; if all constraint rules are not satisfied, discarding the candidate value combination.

[0011] According to an embodiment of the first aspect of this application, generating one or more combinations of values ​​for the one or more API parameters using a combinatorial testing algorithm and weighted random sampling based on the dependency model further includes: updating the weight of each of the one or more API parameters based on the generated one or more combinations of values, wherein the weight of a parameter whose total number of values ​​in the generated one or more combinations of values ​​is higher than a first threshold is decreased, and the weight of a parameter whose total number of values ​​in the generated one or more combinations of values ​​is lower than a second threshold is increased.

[0012] According to an embodiment of the first aspect of this application, the weighted random sampling for random interference injection into edge parameters among the one or more API parameters includes: replacing the values ​​of the edge parameters with abnormal values ​​in a preset interference value set with a preset probability, wherein the abnormal values ​​include values ​​that are outside the range of values, null values, special characters, or values ​​with incorrect formatting.

[0013] According to an embodiment of the first aspect of this application, the predefined test template is a template file based on Python+pytest, Postman Collection, JMeter JMX, Java+RestAssured, or Shell scripts. The template file includes general code for request construction logic, assertion logic, and data cleanup logic, and is provided with placeholders for inserting the value combinations.

[0014] According to an embodiment of the first aspect of this application, the method further includes: executing one or more generated API test cases.

[0015] According to an embodiment of the first aspect of this application, the method further includes: using a constraint solver to detect whether there is a contradiction or circular dependency among the one or more constraint rules, and issuing a prompt when a contradiction or circular dependency is detected.

[0016] According to an embodiment of the first aspect of this application, the core parameters and the edge parameters are divided based on the degree of influence of the parameters on business logic, historical defect data, or user specification.

[0017] According to a second aspect of this application, an API test case generation apparatus is provided, comprising: a processor, and a memory storing instructions that, when executed by the processor, cause the processor to perform the method of the first aspect of this application.

[0018] According to a third aspect of this application, a computer-readable storage medium is provided having instructions stored thereon that, when executed by a computer, cause the computer to perform the method of the first aspect of this application.

[0019] The API test case generation method, apparatus, and medium according to embodiments of this application generate one or more API test cases by establishing a dependency model including one or more constraint rules, using a combinatorial testing algorithm and weighted random sampling based on the dependency model to generate one or more combinations of values ​​for one or more API parameters, and inputting the generated one or more combinations of values ​​into a predefined test template. Furthermore, weighted random sampling can perform high-frequency sampling on core parameters among the one or more API parameters and can inject random interference into edge parameters among the one or more API parameters. In this way, API test cases covering core functions and edge anomalies can be automatically and efficiently generated while satisfying complex parameter constraints, significantly improving testing efficiency and coverage. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application 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 the drawings without creative effort.

[0021] Figure 1 This is a flowchart of an API test case generation method according to an embodiment of this application;

[0022] Figure 2 This is a schematic diagram of the hardware structure of an API test case generation device according to an embodiment of this application. Detailed Implementation

[0023] The features and exemplary embodiments of various aspects of this application will now be described in detail. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only configured to explain this application and are not configured to limit this application. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples of this application.

[0024] 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. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0025] The features and exemplary embodiments of various aspects of this application will now be described in detail. Furthermore, the features, structures, or characteristics described below may be combined in any suitable manner in one or more embodiments.

[0026] With the rapid development of internet technology, application programming interfaces (APIs) have become the core bridge for interaction between software systems. In microservice architectures and front-end / back-end separation development models, the number and complexity of APIs have increased dramatically. Ensuring the quality and reliability of APIs has become a crucial issue in software testing. Currently, API testing mainly relies on testers manually writing test scripts based on the interface documentation. Testers need to analyze the parameter definitions, value ranges, and business rules of each API, then design test cases and write the corresponding test code.

[0027] However, this traditional manual testing method has significant drawbacks. As business logic becomes increasingly complex and the number of API parameters continues to grow, with each parameter potentially having multiple values, the possible parameter combinations increase exponentially—the so-called "combination explosion" problem. Manually writing test cases to cover all combinations becomes virtually impossible. Furthermore, parameters often have complex dependencies, such as "when the payment method is a credit card, the card number cannot be empty." Manual testing struggles to systematically consider these constraints, resulting in test cases that cannot fully cover the interaction scenarios between parameters, especially implicit boundary conditions and abnormal combinations. Simultaneously, API interfaces are constantly iterated and updated as business evolves. Manually maintaining a large number of test cases is time-consuming, labor-intensive, and prone to becoming outdated with the latest API versions.

[0028] To address the aforementioned issues, the industry has proposed several combined testing techniques, such as orthogonal arrays and paired combination testing. Orthogonal arrays use orthogonal arrays to select a small number of test cases, ensuring that any combination of parameter values ​​is evenly covered; paired combination testing ensures that each pair of parameter values ​​occurs at least once. These methods reduce the number of test cases to some extent, but they still have limitations: they typically treat all parameters equally, failing to distinguish between core and peripheral parameters; they struggle to handle complex business constraints; and they lack the ability to proactively explore abnormal inputs.

[0029] Therefore, embodiments of this application provide an API test case generation method, apparatus, and medium that can automatically and efficiently generate API test cases covering core functions and edge anomalies while meeting complex parameter constraints, significantly improving testing efficiency and coverage.

[0030] Figure 1 This is a flowchart of an API test case generation method according to an embodiment of this application. Figure 1 As shown, the API test case generation method according to an embodiment of this application includes the following steps S110 to S140:

[0031] S110: Extract parameter metadata for one or more API parameters from the API definition document, wherein the parameter metadata includes parameter name, data type, value range, and default value;

[0032] S120: Establish a dependency model between one or more API parameters based on the API definition document. The dependency model includes one or more constraint rules, and the constraint rules in the one or more constraint rules are used to describe the constraints between the values ​​of the corresponding API parameters in one or more API parameters.

[0033] S130: Based on the dependency model, use a combinatorial testing algorithm and weighted random sampling to generate one or more combinations of values ​​for one or more API parameters, wherein weighted random sampling performs high-frequency sampling on the core parameters of one or more API parameters, and weighted random sampling injects random interference into the edge parameters of one or more API parameters.

[0034] S140: Input one or more combinations of generated values ​​into a predefined test template to generate one or more API test cases.

[0035] In one embodiment, the API definition document is in one of the following formats: OpenAPI, RAML, APIBlueprint, GraphQL Schema, gRPC Proto, or Postman Collection, and extraction is performed by a parser corresponding to the format. Other API definition document formats may also be used, and this application is not limited thereto.

[0036] For example, for each format, the implementation can employ a corresponding parser. For instance, for OpenAPI format, the Swagger Parser or OpenAPI4J parser can be used; for RAML, the raml-parser-2 parser can be used; for API Blueprint, the protagonist or snowcrash parser can be used; for GraphQL Schema, the graphql-java or graphene parser can be used; for gRPC Proto, the protobuf parser can be used; and for PostmanCollection, the postman-collection library can be used, or the parser can be converted using the postman2openapi tool before parsing. These parsers can read the API definition document, extract parameter information for each API, including parameter name, data type (e.g., string, integer, boolean, array, object), value range (e.g., enumerated value list, minimum / maximum value), default value, etc., and uniformly convert this information into internally structured parameter metadata, providing standardized input for subsequent constraint rule configuration and test case generation.

[0037] In one embodiment, one or more constraint rules take the form of one of the following formats: logical expression, decision table, JSON rule, or domain-specific language DSL, and one or more constraint rules are stored in a constraint rule library.

[0038] For example, constraint rules can be represented and stored in various formats to adapt to different business scenarios and user preferences. For instance, constraint rules can be expressed as logical expressions, such as "payment_method == 'credit_card' -> card_number != null", a form that is intuitive and easy to write and understand manually. They can also be presented as decision tables, showing the combination of conditions and their corresponding results in a tabular format, which is then converted into internal rules by a parser. Alternatively, JSON rule format can be used, defining rules as structured JSON objects containing condition and constraint fields for easier automated processing. Furthermore, domain-specific languages ​​(DSLs) can be designed to provide syntax closer to natural language, such as "if payment_method is 'credit_card' then card_number is required", lowering the configuration threshold for non-technical personnel. All constraint rules in all formats are ultimately stored in a unified constraint rule library, which can be implemented using a relational database (e.g., MySQL), a document-oriented database (e.g., MongoDB), or a simple file system (e.g., JSON files), with an index created for each rule for fast retrieval and retrieval by the constraint engine.

[0039] In one embodiment, one or more constraint rules include at least one of the following rules: mandatory condition rule, optional condition rule, mutual exclusion rule, inclusion relationship rule, numerical relationship rule, format dependency rule, or combined constraint rule.

[0040] For example, constraint rules can cover various dependency types to meet the testing needs of complex business scenarios. For instance, a mandatory condition rule can be expressed as "When the payment method is credit card, the card number field cannot be empty"; an optional condition rule can be expressed as "When the user role is administrator, the department field is optional, but if provided, its length must be at least 2 characters"; a mutual exclusion rule can be expressed as "Fixed discounts and percentage discounts cannot exist simultaneously"; an inclusion relationship rule can be expressed as "When the user role is financial manager, the assigned permission set must include approval and reimbursement permissions"; a numerical relationship rule can be expressed as "The start date must be earlier than the end date" or "The unit price multiplied by the quantity must equal the total price"; a format dependency rule can be expressed as "When the time display preference is set to 24-hour format, the returned time field format must be HH:MM:SS; when the time display preference is set to 12-hour format, the returned time field format must be HH:MM:SS AM / PM"; and a combined constraint rule can involve three or more parameters, such as "When the user type is student and the age is less than 18, the student ID number is optional; otherwise, it is mandatory." These rules are configured through the aforementioned logical expressions, decision tables, JSON or DSL formats, and stored in the rule base. The constraint engine calls and verifies these rules when generating test cases to ensure that the generated value combinations conform to the business logic. They can also be used to generate negative test cases that intentionally violate the rules.

[0041] In one embodiment, the combinatorial testing algorithm is one of the following algorithms: orthogonal experimentation or pairwise combinatorial testing, and the combinatorial testing algorithm is used to achieve coverage of one or more API parameters by the combination of values.

[0042] For example, orthogonal arrays are used to select test cases. For instance, for an API with 3 parameters, each with 2 possible values, L4(2) arrays can be used. 3 An orthogonal array can generate four test cases, ensuring that each of the four possible combinations of values ​​for any two parameters (e.g., A=1, B=1; A=1, B=2; A=2, B=1; A=2, B=2) appears once, achieving uniform coverage. The pairing combination algorithm ensures that each pair of parameter values ​​appears at least once in one test case, and can be implemented using tools such as PICT or algorithms such as IPOGO. In this embodiment, these combination testing algorithms are combined with a constraint engine. First, candidate combinations are generated based on parameter metadata. Then, dependencies in the constraint rule base are used for filtering, retaining only legal combinations that satisfy all business rules. This ensures sufficient coverage of key parameter interactions while controlling the number of test cases.

[0043] In one embodiment, generating one or more combinations of values ​​for one or more API parameters using a combinatorial testing algorithm and weighted random sampling based on a dependency model includes: assigning weights to each of the one or more API parameters, wherein core parameters have higher weights than marginal parameters; randomly selecting values ​​for one or more API parameters from the range of values ​​for the one or more API parameters based on the weights of each of the one or more API parameters to form one or more candidate value combinations, wherein the number of values ​​for core parameters with high weights is higher than the number of values ​​for marginal parameters with low weights; using a constraint engine to verify whether the candidate value combinations among the one or more candidate value combinations satisfy all constraint rules in the dependency model; if all constraint rules are satisfied, using the candidate value combinations as the generated value combinations; if all constraint rules are not satisfied, discarding the candidate value combinations.

[0044] For example, initial weights can be assigned to each API parameter, with core parameters (e.g., payment method, order amount) given higher weights (e.g., weight 10) and marginal parameters (e.g., the remarks field) given lower weights (e.g., weight 2). During sampling, one or more values ​​are randomly selected independently for each parameter based on the current weights, forming one or more candidate value combinations. For example, the core parameter "payment method" has a higher weight, so its number of values ​​(e.g., three values: "credit card", "cash", "Alipay") is higher than the number of values ​​for the marginal parameter "remarks" (e.g., one value: "none"). Subsequently, the constraint engine can be invoked to match and verify one or more candidate value combinations against all constraint rules in the dependency model (e.g., "the card number cannot be empty when the payment method is credit card"). If all rules are satisfied, the value combination is added to the result set as a valid value combination; if any rule is violated, the value combination is discarded.

[0045] In one embodiment, generating one or more combinations of values ​​for one or more API parameters using a combination testing algorithm and weighted random sampling based on a dependency model further includes: updating the weight of each of the one or more API parameters based on the generated one or more combinations of values, wherein the weight of a parameter whose total number of values ​​in the generated one or more combinations of values ​​is higher than a first threshold is decreased, and the weight of a parameter whose total number of values ​​in the generated one or more combinations of values ​​is lower than a second threshold is increased.

[0046] For example, weights can be updated: for parameters with a high total number of values ​​(e.g., 3 or more), their weights can be reduced (e.g., multiplied by a decay factor of 0.9); for parameters with a low total number of values ​​(e.g., 1 or less), their weights can be gradually increased (e.g., increased by 0.1 each time). By combining weighted random sampling with constraint verification, this approach can efficiently generate test case sets that cover core functions while also handling edge anomalies, while satisfying complex business logic.

[0047] In one embodiment, weighted random sampling to inject random interference into edge parameters of one or more API parameters includes: replacing the values ​​of the edge parameters with abnormal values ​​from a preset set of interference values ​​with a preset probability. The abnormal values ​​include values ​​that are outside the range of values, null values, special characters, or values ​​with incorrect formats.

[0048] For example, a set of interference values ​​can be preset for each edge parameter. This set contains various abnormal inputs, such as: values ​​outside the range (e.g., integer parameters taking values ​​of -1 or 10000, while the normal range is 1-100), null values ​​(e.g., null or empty strings), special characters (e.g., @, #, $, %, ^, &, *, etc.), and incorrectly formatted values ​​(e.g., email addresses missing the @ symbol, date formatted as "2021-13-45"), etc. When sampling to generate candidate value combinations, a preset probability p (e.g., 5%) is used to determine whether to trigger interference injection: if triggered, a random edge parameter is selected, and its current value is replaced with an abnormal value from the interference value set; if not triggered, sampling is performed according to normal weights. In this way, the generated test cases include both normal combinations that conform to business rules and abnormal combinations that simulate client errors or malicious inputs in the real world, thereby effectively testing the API's fault tolerance and error handling mechanisms and discovering hidden edge defects.

[0049] In one embodiment, the predefined test template is a template file based on Python+pytest, PostmanCollection, JMeter JMX, Java+RestAssured, or Shell scripts. The template file includes generic code for request construction logic, assertion logic, and data cleanup logic, and is provided with placeholders for inserting value combinations.

[0050] For example, predefined test templates can be configured in various formats based on the target testing framework, such as Python + pytest script templates, Postman Collection JSON templates, JMeter JMX XML templates, Java + RestAssured code templates, or Shell script templates. Taking the Python + pytest template as an example, its content can include the following structure: importing the requests and pytest libraries, defining test functions, which can contain request construction logic such as URL construction, request header setting, parameter passing, and request sending; assertion logic such as status code assertions and response body field validation; and data cleanup logic for pre- and post-test data preparation and cleanup. The template includes multiple placeholders, such as {{url}}, {{method}}, {{headers}}, {{data}}, {{expected_status}}, and {{expected_json}}, for inserting specific parameter value combinations later. During the generation phase, the system reads the parameter combinations for each test case, uses the template engine to replace the placeholders with actual values, and generates a complete test script file. The generated scripts can be executed directly in a CI / CD environment (e.g., by running the pytest command), automatically sending requests to the target API and verifying the responses, thus achieving a fully automated transformation from parameter combinations to executable test cases. This template-based generation method eliminates the need for testers to manually write code for each test case, significantly improving testing efficiency.

[0051] In one embodiment, the method further includes executing one or more generated API test cases.

[0052] For example, after generating test scripts, the corresponding execution engine (e.g., pytest, Newman, or JMeter) can be called to run these scripts, send requests to the target API and receive responses, automatically verify the results according to the assertion logic in the template, and finally collect test reports and integrate them into the CI / CD pipeline to achieve automated test execution and rapid feedback.

[0053] In one embodiment, the method further includes: using a constraint solver to detect whether there are contradictions or circular dependencies among one or more constraint rules, and issuing a prompt when a contradiction or circular dependency is detected.

[0054] For example, all constraint rules in the rule base can be converted into logical expressions recognizable by constraint solvers (such as Z3, Choco, or Google OR-Tools), and the constraint solver can be invoked to detect whether these rules contain contradictions or circular dependencies. For instance, the constraint solver will attempt to find a set of parameter values ​​that satisfy all constraint rules. If no feasible solution is found, the rule is considered contradictory. If a circular dependency like "A=1→B>10" and "B>10→A=1" is detected but a feasible solution exists (e.g., A=1 and B=20), it is considered a satisfyable circular dependency; otherwise, it is considered a contradiction. When a contradiction or an unsolvable circular dependency is detected, the system can prompt the user, locate the specific conflicting rule, and suggest manual correction of the rule configuration to avoid generating a large number of invalid attempts or unexecutable test cases in the subsequent sampling and generation phase.

[0055] In one embodiment, core parameters and edge parameters are distinguished based on the degree of impact of the parameters on business logic, historical defect data, or user specifications.

[0056] For example, the distinction between core and marginal parameters can be flexibly determined based on various strategies to ensure the relevance and effectiveness of weighted random sampling. For instance, three classification methods can be supported: First, based on the degree of impact on business logic, key parameters are identified by analyzing the API's business scenarios. For example, in a payment interface, `payment_method` and `amount` directly affect the core transaction process and are marked as core parameters, while `notes` do not affect the main functionality and are classified as marginal parameters. Second, based on historical defect data. For example, a defect management platform can be integrated to statistically analyze the frequency with which each parameter causes defects in historical tests or online failures, automatically elevating parameters with high defect rates to core parameters. For example, if `coupon_code` has repeatedly caused problems due to inadequate format validation, it can be adjusted to a core parameter to enhance test coverage. Third, based on user specification, testers can manually mark core parameters through configuration files or a graphical interface. For example, `role` can be forcibly set as a core parameter based on business needs. For example, the classification results can be stored in metadata as parameter importance tags for use during subsequent weight initialization, thereby ensuring that the sampling strategy matches business risks.

[0057] The API test case generation method, apparatus, and medium according to embodiments of this application generate one or more API test cases by establishing a dependency model including one or more constraint rules, using a combinatorial testing algorithm and weighted random sampling based on the dependency model to generate one or more combinations of values ​​for one or more API parameters, and inputting the generated one or more combinations of values ​​into a predefined test template. Furthermore, weighted random sampling can perform high-frequency sampling on core parameters among the one or more API parameters and can inject random interference into edge parameters among the one or more API parameters. In this way, API test cases covering core functions and edge anomalies can be automatically and efficiently generated while satisfying complex parameter constraints, significantly improving testing efficiency and coverage.

[0058] This application also provides an API test case generation apparatus, including: a processor and a memory storing instructions, which, when executed by the processor, cause the processor to perform the above-described API test case generation method.

[0059] Figure 2 This is a schematic diagram of the hardware structure of an API test case generation device according to an embodiment of this application. Figure 2 The API test case generation device shown may include a processor 21 and a memory 22 storing computer program instructions.

[0060] Specifically, the processor 21 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application. Furthermore, the processor 21 may also include an accelerator such as a graphics processing unit (GPU) or a tensor processor (TPU).

[0061] Memory 22 may include a large-capacity memory for data or instructions. Where appropriate, memory 22 may include removable or non-removable (or fixed) media. In a particular embodiment, memory 22 is a non-volatile solid-state memory. Memory 22 may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Thus, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the API test case generation method described above.

[0062] The processor 21 implements the API test case generation method in the above embodiments by reading and executing computer program instructions stored in the memory 22.

[0063] In one example, the API test case generation device may also include a communication interface 23 and a bus 24. For example, Figure 2 As shown, the processor 21, memory 22, and communication interface 23 are connected through bus 24 and complete communication with each other.

[0064] Bus 24 includes hardware, software, or both, that couples components of the API test case generation device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 24 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0065] This application also provides a computer-readable storage medium storing instructions thereon, which, when executed by a computer, cause the computer to perform the above-described API test case generation method.

[0066] Examples of computer-readable storage media include non-transitory computer-readable storage media such as portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, etc.

[0067] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0068] The above description is merely a specific embodiment of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for generating API test cases, characterized in that, include: Extract parameter metadata of one or more API parameters from the API definition document, wherein the parameter metadata includes parameter name, data type, value range, and default value; A dependency model between the one or more API parameters is established based on the API definition document. The dependency model includes one or more constraint rules, which describe the constraints between the values ​​of the corresponding API parameters in the one or more API parameters. Based on the dependency model, a combinatorial testing algorithm and weighted random sampling are used to generate one or more combinations of values ​​for the one or more API parameters. Specifically, the weighted random sampling performs high-frequency sampling on the core parameters of the one or more API parameters, and injects random interference into the edge parameters of the one or more API parameters. Assign a weight to each of the one or more API parameters, wherein the weight of the core parameter is higher than the weight of the edge parameter; Based on the weight of each of the one or more API parameters, the values ​​of the one or more API parameters are randomly selected from the value range of the one or more API parameters to form one or more candidate value combinations, wherein the number of values ​​of the core parameters with high weights is higher than the number of values ​​of the edge parameters with low weights. The constraint engine is used to verify whether the candidate value combinations among the one or more candidate value combinations satisfy all the constraint rules in the dependency model; If all constraint rules are satisfied, the candidate value combination is taken as the generated value combination; If none of the constraint rules are met, discard the candidate value combination; and The weight of each of the one or more API parameters is updated based on the generated one or more combinations of values, wherein the weight of a parameter whose total number of values ​​in the generated one or more combinations of values ​​exceeds a first threshold is decreased, and the weight of a parameter whose total number of values ​​in the generated one or more combinations of values ​​is less than a second threshold is increased; and One or more combinations of generated values ​​are input into a predefined test template to generate one or more API test cases.

2. The method according to claim 1, characterized in that, The API definition document is in one of the following formats: OpenAPI, RAML, API Blueprint, GraphQL Schema, gRPC Proto, or Postman Collection, and the extraction is performed by a parser corresponding to the format.

3. The method according to claim 1, characterized in that, The one or more constraint rules are in one of the following formats: logical expression, decision table, JSON rule, or domain-specific language DSL, and the one or more constraint rules are stored in a constraint rule library.

4. The method according to claim 1, characterized in that, The one or more constraint rules include at least one of the following rules: Rules that require conditions, rules that allow optional conditions, rules that allow mutual exclusion, rules that allow inclusion, rules that allow numerical relationships, rules that allow format dependency, or rules that allow combination of constraints.

5. The method according to claim 1, characterized in that, The combined testing algorithm is one of the following algorithms: orthogonal experimentation or pairwise combination, and the combined testing algorithm is used to achieve coverage of the one or more API parameters by the value combination.

6. The method according to claim 1, characterized in that, The weighted random sampling involves injecting random interference into the edge parameters of the one or more API parameters, including: The edge parameter values ​​are replaced with abnormal values ​​from a preset set of interference values ​​with a preset probability. The abnormal values ​​include values ​​that are outside the range, empty values, special characters, or values ​​with incorrect formatting.

7. The method according to claim 1, characterized in that, The predefined test template is a template file based on Python+pytest, Postman Collection, JMeter JMX, Java+RestAssured, or Shell scripts. The template file includes general code for request construction logic, assertion logic, and data cleanup logic, and is provided with placeholders for inserting value combinations.

8. The method according to claim 1, characterized in that, Also includes: The constraint solver is used to detect whether there are contradictions or circular dependencies among one or more constraint rules, and a prompt is issued when a contradiction or circular dependency is detected.

9. The method according to claim 1, characterized in that, The core parameters and the edge parameters are divided based on the degree of impact of the parameters on business logic, historical defect data, or user specifications.

10. An API test case generation device, characterized in that, The device includes: processor, and A memory storing instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-9.

11. A computer-readable storage medium storing instructions, characterized in that, When executed by a computer, the instructions cause the computer to perform the method according to any one of claims 1-9.

Images