Automatic test case generation method based on interface change and related equipment

Abstract

The embodiment of the invention relates to an automatic test case generation method based on interface change and related equipment. The method comprises the following steps: acquiring a basic request parameter data structure of a changed interface and a supplemented parameter rule; forming a parameter data structure containing a change identifier based on the basic request parameter data structure, the supplemented parameter rule and the newly added and / or modified marked field; obtaining a cue word basic template, and generating a cue word based on the parameter data structure containing the change identifier, the cue word basic substrate, the business background and the use case generation constraint; inputting the cue word into the large language model to generate a test case; and verifying the test cases, and screening out effective test cases. The use case is automatically generated at the change point of the focusing interface, so that full redundancy is avoided, the efficiency of use case generation is greatly improved, and an interface high-frequency iteration scene is adapted.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, and in particular to a method, apparatus, electronic device, and computer-readable storage medium for automatically generating test cases based on interface changes. Background Technology

[0002] Interfaces are the core carriers for data interaction and functional verification between software systems. Interface testing needs to comprehensively cover core dimensions such as forward processes, abnormal scenarios, and boundary scenarios, and must adapt to the high-frequency iteration requirements of agile development models. In actual testing, there are many types of abnormal and boundary scenarios, and there are complex linkage constraints between parameters (such as specific enumeration values ​​corresponding to mandatory related parameters). Manually generating test cases is not only repetitive, tedious, and inefficient, but also prone to missing key test points. Especially after interface changes, manually adjusting test cases often lags behind the iteration rhythm, making it difficult to balance testing efficiency and coverage quality. Summary of the Invention

[0003] To solve or partially solve the above-mentioned technical problems, this invention provides a method and related equipment for automatically generating test cases based on interface changes. By focusing on the interface modification points to automatically generate test cases, full redundancy is avoided, the efficiency of test case generation is greatly improved, and it is adapted to high-frequency interface iteration scenarios.

[0004] In a first aspect, embodiments of the present invention provide a method for automatically generating test cases based on interface changes. The method includes:

[0005] Obtain the basic request parameter data structure of the changed interface, as well as the supplementary parameter rules; based on the basic request parameter data structure, the supplementary parameter rules, and the fields marked as added and / or modified, form a parameter data structure containing modification identifiers;

[0006] Obtain the basic template for prompt words, and generate prompt words based on the parameter data structure containing modification identifiers, the basic template for prompt words, the business background, and the test case generation constraints; the basic template for prompt words includes the test case generation format and the test case scenario coverage requirements; the prompt words include the limitation of generating only test cases related to the fields that are marked as newly added or modified;

[0007] Input the prompt words into the large language model to generate test cases;

[0008] Validate the test cases and select the valid ones.

[0009] In one implementation, the step of validating test cases and filtering out valid test cases includes:

[0010] Perform structure and rule checks on test cases to filter out invalid test cases and obtain valid test cases.

[0011] In one embodiment, the method further includes:

[0012] Valid test cases are stored in the database of the test management platform, and valid test cases are associated with corresponding interface change records.

[0013] Secondly, embodiments of the present invention provide an automated test case generation device based on interface changes. The device includes:

[0014] The parameter data structure forming module is used to obtain the basic request parameter data structure of the changed interface and the supplementary parameter rules; based on the basic request parameter data structure, the supplementary parameter rules, and the fields marked as added and / or modified, a parameter data structure containing modification identifiers is formed.

[0015] The prompt word generation module is used to obtain the prompt word base template, and generate prompt words based on the parameter data structure containing modification identifiers, the prompt word base template, the business background, and the test case generation constraints; the prompt word base template includes the test case generation format and the test case scenario coverage requirements; the prompt words include the limitation of generating only test cases related to the marked new or modified fields;

[0016] The test case generation module is used to input prompt words into a large language model and generate test cases;

[0017] The filtering module is used to validate test cases and filter out valid test cases.

[0018] In one implementation, the filtering module includes:

[0019] The validation submodule is used to perform structural and rule validation on test cases, filter out invalid test cases, and obtain valid test cases.

[0020] In one embodiment, the device further includes:

[0021] The database storage and association module is used to save valid test cases in the database of the test management platform and associate valid test cases with the corresponding interface change records.

[0022] Thirdly, the present invention provides an electronic device, the electronic device comprising:

[0023] At least one processor; and

[0024] A memory communicatively connected to the at least one processor; wherein,

[0025] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the above-described method for automatically generating test cases based on interface changes.

[0026] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a processor to execute the above-described method for automatically generating test cases based on interface changes.

[0027] In this embodiment of the invention, the basic request parameter data structure of the changed interface and supplementary parameter rules are obtained; based on the basic request parameter data structure, supplementary parameter rules, and fields marked as added and / or modified, a parameter data structure containing modification identifiers is formed; a basic prompt word template is obtained, and prompt words are generated based on the parameter data structure containing modification identifiers, the basic prompt word template, business background, and test case generation constraints; the prompt words are input into a large language model to generate test cases; the test cases are validated, and valid test cases are selected. This method focuses on generating test cases based on interface changes, avoiding full redundancy, and ensures through validation that test cases do not deviate from the interface structure and business logic, significantly reducing the invalid test case rate.

[0028] No need for manual prompt writing, manual format conversion, or manual database entry, significantly reducing the time spent on mechanical work and shortening the test case generation cycle from hours to minutes, adapting to high-frequency interface iteration scenarios.

[0029] The generation of test cases improves coverage and effectiveness, reduces the risk of missing interface defects, and indirectly reduces the cost of software iteration and maintenance. Attached Figure Description

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

[0031] Figure 1 This is a flowchart of a method for automatically generating test cases based on interface changes, provided in Embodiment 1 of the present invention.

[0032] Figure 2 This is a schematic diagram of the structure of an automated test case generation device based on interface changes provided in Embodiment 2 of the present invention;

[0033] Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0035] Figure 1 This is a flowchart of a method for automatically generating test cases based on interface changes, provided in Embodiment 1 of the present invention. This embodiment can be applied to an automated test case generation device based on interface changes, such as... Figure 1 As shown, this embodiment may include the following steps:

[0036] Step 101: Obtain the basic request parameter data structure of the changed interface and the supplementary parameter rules; based on the basic request parameter data structure, the supplementary parameter rules, and the fields marked as added and / or modified, form a parameter data structure containing modification identifiers.

[0037] In scenarios involving product requirement iteration, technical optimization, and issue fixing, when an interface changes, and these changes render the original test cases' coverage scenarios, input parameters, or expected results invalid, or when new core scenarios requiring verification are added, test cases need to be regenerated for the changed interface. In this scenario, the automated test case generation device can obtain the basic request parameter data structure of the changed interface from the interface platform, such as the parameter hierarchy, field names, and basic types defined in JSON / Protobuf.

[0038] The basic request parameter data structure of an interface is a standardized organization that describes the interface input parameters. It defines the core attributes such as parameter name, type, constraint rules, and correlation, and serves as the common basis for interface design, development, and testing.

[0039] After obtaining the basic request parameter data structure of the interface, the user-supplemented parameter rules are obtained (users can input parameter descriptions, enumeration values, linkage rules, etc. through the input interface provided by the test case automation generation device). Then, based on the basic request parameter data structure, the supplemented parameter rules, and fields marked as added and / or modified, a parameter data structure containing modification identifiers is formed. For example:

[0040] Parameter description: The business meaning of each field (e.g., "targetLiveId: Target Live Room ID");

[0041] Enumerated values: The valid enumerated options for the field and their corresponding scenarios (e.g., "operation: 1 = initiate invitation, 2 = cancel invitation").

[0042] Linkage rules: Dependencies between fields (e.g., "when operation = 1, targetLiveId is required").

[0043] Based on the API platform's change logs, add change identifiers to the fields of the request parameter data structure:

[0044] New fields: Mark "New Identifier" (for new parameters added in the corresponding interface changes). If it is a new interface, all fields are marked "New Identifier".

[0045] Existing fields: Marked as "Unchanged" or "Constraint Modified" (corresponding to parameter constraint adjustments).

[0046] Step 102: Obtain the basic template for prompt words, and generate prompt words based on the parameter data structure containing modification identifiers, the basic template for prompt words, the business background, and the test case generation constraints; the basic template for prompt words includes the test case generation format and the test case scenario coverage requirements; the prompt words include the limitation of generating test cases only related to the fields that have been marked as newly added or modified.

[0047] The prompt word template is a pre-designed, structured, and reusable instruction framework for specific tasks (such as generating interface test cases). It clarifies the role positioning, input information, output requirements, and execution rules for Large Language Models (LLMs), ensuring that the model's output content meets the requirements, has a consistent format, and is of controllable quality, avoiding result deviations caused by ambiguous instructions.

[0048] For example:

[0049] # Role Positioning

[0050] You are a senior API testing engineer, proficient in designing test cases for positive, abnormal, and boundary scenarios, and familiar with API parameter linkage rules and business logic validation.

[0051] # Enter information

[0052] 1. **Interface Basic Information**

[0053] - Interface Name: [Enter the interface name, such as: Live PK Operation Interface]

[0054] - Interface version: [Enter the version number, such as: v1.1]

[0055] - Request method: [Enter the request method, such as: POST]

[0056] - Parameter data structure (including constraint rules):

[0057] [Paste the parameter structure in JSON Schema / Markdown table format, including field names, types, required fields, enumerated values, value ranges, and linkage rules, etc.]

[0058] 2. **Interface Change Information (Optional, ignore if no changes)**

[0059] - Change type: [Add / Modify / Delete parameter]

[0060] - Modified fields and rules: [Annotate newly added fields, modified enumeration values / value ranges / linkage rules]

[0061] 3. **Test Scenario Requirements**

[0062] - Must cover: positive scenarios, abnormal scenarios, and boundary scenarios

[0063] - Positive scenario: Verifying parameter compliance and normal business logic, covering all core parameter combinations.

[0064] - Abnormal scenarios: missing validation parameters, incorrect data types, out-of-bounds enumeration values, violation of linkage rules, etc.

[0065] - Boundary scenarios: Verify the critical values ​​of parameters (such as minimum value, maximum value, null value, excessively long string, etc.)

[0066] # Output Requirements

[0067] 1. **Test Case Format** (Output according to the following structure, each test case is independent):

[0068] | Test Case Name | Test Scenario | Input Parameters (Key-Value Pairs) | Expected Result |

[0069] 2. **Test Case Quality Requirements**

[0070] - No repetition, no redundancy; each test case corresponds to a unique test point.

[0071] - The expected results are clear and verifiable (including response codes, key response fields, error messages, etc.).

[0072] - Prioritize scenarios that cover changed fields

[0073] # Execute command

[0074] Based on the above information, generate test cases that meet the requirements, ensuring coverage of all specified scenarios, and directly output the final test case table without any additional explanation.

[0075] After obtaining the basic template for the prompt words, prompt words are generated based on the parameter data structure containing modification identifiers, the basic template for prompt words, the business background, and the use case generation constraints.

[0076] Specifically, 1. Adapt and assemble the core components according to the modified identifiers:

[0077] If it is a new interface (all fields are marked with "new identifier"): the complete parameter data structure (including description, enumeration, and linkage rules) will be fully injected into the prompt word base template;

[0078] If the interface is modified: inject the complete parameter data structure into the prompt word base template, and explicitly require that "only test cases related to the fields marked as added or modified be generated".

[0079] 2. Add personalized optimization information:

[0080] Business Background: Add custom industry rules and business constraints (such as "Live room IDs cannot be duplicated, and live PK requires both parties to be from different live rooms").

[0081] Test case generation constraints: Invalid test cases will not be generated when there is insufficient positive parameter data (such as no valid enumeration values); test cases must cover positive scenarios / abnormal scenarios / boundary scenarios; and test case names should reflect scenario details.

[0082] The above content is assembled in a fixed format to form a customized Prompt (including complete parameter data structure fragments, modification identification descriptions, business background, and test case generation constraints).

[0083] Step 103: Input the prompt words into the large language model to generate test cases.

[0084] Large Language Models (LLMs) are large-scale models based on deep learning, with the Transformer architecture (the mainstream large language model). After pre-training on massive amounts of text, they possess natural language understanding, generation, and reasoning capabilities. Inputting the prompt words generated in step 102 into the large language model yields test cases, such as:

[0085] Positive use cases: Only include the fields "Add Identifier" and "Constraint Modification Identifier", and conform to the linkage rules and business background (such as "When operation=1, targetLiveId, timeId, and liveId are all valid").

[0086] Exceptional use cases: scenarios such as missing fields, incorrect types, and violations of linkage rules (e.g., "the newly added field targetLiveId is missing", "targetLiveId was not passed when operation=1").

[0087] Boundary use cases: enumeration boundaries of the marked field, numerical extreme values ​​(such as "targetLiveId=0", "operation=9 (out of enumeration range)").

[0088] Step 104: Verify the test cases and select valid test cases.

[0089] After generating test cases from the large language model, a standardized verification process is required to comprehensively review the generated test cases and select those that are executable and effective. The specific verification process includes two core steps: structural verification and rule verification. Finally, based on the verification results, invalid test cases are filtered out, and a set of valid test cases that meet the testing requirements is retained.

[0090] The core of structural validation is to ensure that the parameter information of the test cases completely matches the basic request parameter data structure of the interface, with no format or type deviations. Specific validation content may include:

[0091] The field names of the test case input parameters are completely consistent with the field names of the basic request parameter data structure of the interface, with no typos or omissions;

[0092] The data types of the test case input parameters strictly match the interface definition.

[0093] If the structure validation fails, it is directly determined as an invalid use case and does not need to proceed to subsequent rule validation.

[0094] The core of rule validation is to ensure that test cases fully comply with the constraints of interface parameters, business logic, and generated constraints, thus possessing practical testing value. Specific validation content may include:

[0095] In accordance with parameter linkage rules, such as when initiating a PK invitation (operation=1), both the user's live stream ID (liveId) and the target live stream ID (targetLiveId) must be passed simultaneously.

[0096] The parameter value must conform to the constraint rules. For example, the "operation" field of the validation object must be within the enumeration range defined in the interface (e.g., 1 = initiate invitation, 2 = cancel invitation). Values ​​outside the enumeration are not allowed (e.g., 0, 3, etc., unless explicitly added in the interface documentation). Valid examples: "operation=1" (initiate invitation), "operation=2" (cancel invitation). Valid examples: "operation=0" (no corresponding operation type).

[0097] The validation must comply with core business constraints, such as the relationship between "liveId" (your own) and "targetLiveId" (the target). The criteria are: the two parties in the live stream PK must be from different live stream rooms, i.e., "liveId ≠ targetLiveId"; live stream room IDs cannot be duplicated, and both "liveId" and "targetLiveId" must be valid and unique live stream room IDs. An example of an invalid live stream room is: "liveId=1000, targetLiveId=1000" (both IDs are the same, violating the business context).

[0098] The generated test cases must meet the constraints, such as the validation object: a new field "targetLiveId" is added. The criterion is that the generated test cases must cover the core scenarios associated with "targetLiveId" (such as mandatory field validation and boundary value validation). This field is a new identifier and is the focus of this test. Key coverage scenarios:

[0099] 1. Positive scenario: Pass in a valid "targetLiveId" (such as 1001, 999999);

[0100] 2. Abnormal scenarios: Passing in invalid "targetLiveId" such as null values, negative numbers, or excessively large values.

[0101] The method may further include:

[0102] Step 105: Save the valid test cases in the database of the test management platform and associate the valid test cases with the corresponding interface change records.

[0103] In this step, the large language model can directly generate test cases that conform to the interface specifications of the test management platform, thus allowing valid test cases to be directly saved in the test management platform's database. Furthermore, the test management platform tagged these test cases with "associated interface change records," such as "interface ID, change record ID, creator," to ensure the traceability of test cases.

[0104] Ultimately, a complete work loop is formed, consisting of "interface change → AI-generated use cases → automated database entry → correlation and traceability".

[0105] In this embodiment, the basic request parameter data structure of the changed interface and supplementary parameter rules are obtained. Based on the basic request parameter data structure, supplementary parameter rules, and fields marked as added and / or modified, a parameter data structure containing modification identifiers is formed. A basic prompt word template is obtained, and prompt words are generated based on the parameter data structure containing modification identifiers, the basic prompt word template, business background, and test case generation constraints. The prompt words are input into a large language model to generate test cases. The test cases are validated, and valid test cases are selected. This method focuses on generating test cases based on interface changes, avoiding full redundancy. At the same time, through structure validation and rule validation, it ensures that the test cases do not deviate from the interface structure and business logic, significantly reducing the invalid test case rate. It eliminates the need for manual prompt writing, manual format conversion, and manual database entry, greatly reducing the time spent on mechanical work. It can shorten the test case generation cycle from hours to minutes, adapting to high-frequency interface iteration scenarios. The coverage and effectiveness of generated test cases are improved, reducing the risk of interface defects being missed, and indirectly reducing software iteration and maintenance costs.

[0106] Corresponding to the method for automatically generating test cases based on interface changes in this invention, this invention also provides a system for automatically generating test cases based on interface changes. Figure 2 This is a schematic diagram of a device for automatically generating test cases based on interface changes. Figure 2 As shown, the automated test case generation device based on interface changes includes:

[0107] The parameter data structure forming module 201 is used to obtain the basic request parameter data structure of the changed interface and the supplementary parameter rules; based on the basic request parameter data structure, the supplementary parameter rules, and the fields marked as added and / or modified, a parameter data structure containing modification identifiers is formed.

[0108] The prompt word generation module 202 is used to obtain the prompt word base template, and generate prompt words based on the parameter data structure containing modification identifiers, the prompt word base template, the business background, and the test case generation constraints; the prompt word base template includes the test case generation format and the test case scenario coverage requirements; the prompt words include the limitation of generating only test cases related to the marked newly added or modified fields;

[0109] The test case generation module 203 is used to input prompt words into the large language model and generate test cases.

[0110] The filtering module 204 is used to verify test cases and filter out valid test cases.

[0111] In one embodiment, the filtering module 204 includes:

[0112] The validation submodule is used to perform structural and rule validation on test cases, filter out invalid test cases, and obtain valid test cases.

[0113] In one embodiment, the device further includes:

[0114] The database storage and association module is used to save valid test cases in the database of the test management platform and associate valid test cases with the corresponding interface change records.

[0115] The test case automated generation device based on interface change provided in this embodiment of the invention can execute the test case automated generation method based on interface change provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0116] Figure 3 A schematic diagram of an electronic device 30 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0117] like Figure 3 As shown, the electronic device 30 includes at least one processor 31 and a memory, such as a read-only memory (ROM) 32 or a random access memory (RAM) 33, communicatively connected to the at least one processor 31. The memory stores computer programs executable by the at least one processor. The processor 31 can perform various appropriate actions and processes based on the computer program stored in the ROM 32 or loaded from storage unit 38 into the RAM 33. The RAM 33 can also store various programs and data required for the operation of the electronic device 30. The processor 31, ROM 32, and RAM 33 are interconnected via a bus 34. An input / output (I / O) interface 35 is also connected to the bus 34.

[0118] Multiple components in electronic device 30 are connected to I / O interface 35, including: input unit 36, such as keyboard, mouse, etc.; output unit 37, such as various types of monitors, speakers, etc.; storage unit 38, such as disk, optical disk, etc.; and communication unit 39, such as network card, modem, wireless transceiver, etc. Communication unit 39 allows electronic device 30 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0119] Processor 31 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 31 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 31 performs the various methods and processes described above, such as the automated generation method of test cases based on interface changes.

[0120] In some embodiments, the method for automating test case generation based on interface changes can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 38. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 30 via ROM 32 and / or communication unit 39. When the computer program is loaded into RAM 33 and executed by processor 31, one or more steps of the method for automating test case generation based on interface changes described above can be performed. Alternatively, in other embodiments, processor 31 can be configured to perform the method for automating test case generation based on interface changes by any other suitable means (e.g., by means of firmware).

[0121] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0122] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0123] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0124] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0125] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0126] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0127] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0128] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for automatically generating test cases based on interface changes, characterized in that, The method includes: Obtain the basic request parameter data structure of the changed interface, as well as the supplementary parameter rules; based on the basic request parameter data structure, the supplementary parameter rules, and the fields marked as added and / or modified, form a parameter data structure containing modification identifiers; Obtain the basic template for prompt words, and generate prompt words based on the parameter data structure containing modification identifiers, the basic template for prompt words, the business background, and the test case generation constraints; the basic template for prompt words includes the test case generation format and the test case scenario coverage requirements; the prompt words include the limitation of generating only test cases related to the fields that are marked as newly added or modified; Input the prompt words into the large language model to generate test cases; Validate the test cases and select the valid ones.

2. The method according to claim 1, characterized in that, The process of validating test cases and selecting valid test cases includes: Perform structure and rule validation on test cases, filter out invalid test cases, and obtain valid test cases.

3. The method according to claim 1 or 2, characterized in that, Also includes: Valid test cases are stored in the database of the test management platform, and valid test cases are associated with corresponding interface change records.

4. An automated test case generation device based on interface changes, characterized in that, include: The parameter data structure forming module is used to obtain the basic request parameter data structure of the changed interface and the supplementary parameter rules; based on the basic request parameter data structure, the supplementary parameter rules, and the fields marked as added and / or modified, a parameter data structure containing modification identifiers is formed. The prompt word generation module is used to obtain the prompt word base template, and generate prompt words based on the parameter data structure containing modification identifiers, the prompt word base template, the business background, and the test case generation constraints; the prompt word base template includes the test case generation format and the test case scenario coverage requirements; the prompt words include the limitation of generating only test cases related to the marked new or modified fields; The test case generation module is used to input prompt words into a large language model and generate test cases; The filtering module is used to validate test cases and filter out valid test cases.

5. The apparatus according to claim 4, characterized in that, The filtering module includes: The validation submodule is used to perform structural and rule validation on test cases, filter out invalid test cases, and obtain valid test cases.

6. The apparatus according to claim 4 or 5, characterized in that, Also includes: The database storage and association module is used to save valid test cases in the database of the test management platform and associate valid test cases with the corresponding interface change records.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the automated test case generation method based on interface changes according to any one of claims 1-3.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the automated test case generation method based on interface changes as described in any one of claims 1-3.

Images