Automatic regression testing method and device based on dynamic replacement and storage medium

Abstract

The invention relates to the technical field of software testing, and provides an automatic regression testing method based on dynamic replacement, and the method comprises the steps: obtaining a key field and a KV pair corresponding to the key field through extracting a JSON interface case; generating a reference JSON interface case template according to a preset rule; identifying and marking a key field in the reference JSON interface case template; according to the step index < < key field step index > > of the key field, performing dynamic replacement operation to obtain replaced JSON (JavaScript Object Notation) data; rendering the replaced JSON data to form a new test case; and executing a regression test by using the new test case, and verifying the validity and accuracy of the new test case. According to the technical scheme, it can be ensured that the execution efficiency of the test case is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to an automated regression testing method, device and storage medium based on dynamic replacement. Background Art

[0002] With the continuous deepening of software development, especially the widespread use of Web applications and API interfaces, the system interfaces usually use JSON (JavaScript Object Notation) format for data interaction. In this context, regression testing, as an important means to verify whether the software still meets the expected functions after changes, plays a vital role in ensuring software quality and stability.

[0003] However, traditional regression testing methods mainly rely on manual writing and maintenance of a large number of test cases. When faced with large-scale systems and changing interface data, manual methods are not only labor-intensive, but also prone to missing key test scenarios, resulting in insufficient test coverage and inaccurate test results. Summary of the invention

[0004] The present application provides an automated regression testing method, device and storage medium based on dynamic replacement to ensure improved test case execution efficiency.

[0005] On the one hand, the present application provides an automated regression testing method based on dynamic replacement, the method comprising:

[0006] By extracting the JSON interface use case, obtain the key fields and their corresponding KV pairs;

[0007] Generate a reference JSON interface use case template based on preset rules;

[0008] Identifying and marking the key fields in the reference JSON interface use case template;

[0009] According to the step index of the key field "key field_step_index", a dynamic replacement operation is performed to obtain the replaced JSON data;

[0010] Render the replaced JSON data to form a new test case;

[0011] Perform regression testing using the new test cases to verify the effectiveness and accuracy of the new test cases.

[0012] On the other hand, the present application provides an automated regression testing device based on dynamic replacement, the device comprising:

[0013] The acquisition module is used to obtain key fields and their corresponding KV pairs by extracting JSON interface use cases;

[0014] The generation module is used to generate a reference JSON interface use case template according to preset rules;

[0015] An identification module, used to identify and mark the key fields in the reference JSON interface use case template;

[0016] A replacement module, used to perform a dynamic replacement operation according to the step index of the key field "key field_step_index" to obtain the replaced JSON data;

[0017] A rendering module, used for rendering the replaced JSON data to form a new test case;

[0018] The testing module is used to perform regression testing using the new test cases to verify the effectiveness and accuracy of the new test cases.

[0019] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the technical solution of the above-mentioned automated regression testing method based on dynamic replacement when executing the computer program.

[0020] In a fourth aspect, the present application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the technical solution of the above-mentioned automated regression testing method based on dynamic replacement.

[0021] From the technical solution provided in the present application, it can be seen that, on the one hand, a customized JSON interface use case and a script template generation tool are integrated. During the test execution, the key field dependency reference description in the reference JSON interface use case template is used to render the data of the dependent fields and generate correct test data, thereby ensuring the improvement of the test case execution efficiency and reducing the testers' repeated modifications to the JSON interface use cases. On the other hand, the test case generation method is highly flexible and adaptable. Users can adjust the data replacement rules or interface templates according to different test requirements and interface changes to dynamically adapt to changes in the software system and maintain the effectiveness and pertinence of regression testing. Thirdly, due to the use of automated generation and dynamic replacement, the generated test cases can adapt to different versions of interfaces without the need for repeated manual writing, thereby improving the reusability and maintainability of the test cases. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0023] Figure 1 This is a flow chart of an automated regression testing method based on dynamic replacement provided in an embodiment of the present application:

[0024] Figure 2 It is a structural schematic diagram of an automated regression testing device based on dynamic replacement provided in an embodiment of the present application;

[0025] Figure 3 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0027] In this specification, adjectives such as first and second may be used only to distinguish one element or action from another element or action, without necessarily requiring or implying any actual such relationship or order. Where circumstances permit, reference to an element or component or step (etc.) should not be interpreted as being limited to only one of the elements, components, or steps, but may be one or more of the elements, components, or steps, etc.

[0028] In this specification, for the convenience of description, the sizes of various parts shown in the drawings are not drawn according to the actual proportional relationship.

[0029] With the continuous deepening of software development, especially the widespread use of Web applications and API interfaces, the system interfaces usually use JSON (JavaScript Object Notation) format for data interaction. In this context, regression testing, as an important means to verify whether the software still meets the expected functions after changes, plays a vital role in ensuring software quality and stability. However, traditional regression testing methods mainly rely on manual writing and maintenance of a large number of test cases. When faced with large-scale systems and changing interface data, manual methods are not only labor-intensive, but also prone to missing key test scenarios, resulting in insufficient test coverage and inaccurate test results.

[0030] In view of the above problems in the prior art, this application proposes an automated regression testing method based on dynamic replacement, the flow chart of which is shown in the attached figure. Figure 1 As shown, it mainly includes steps S101 to S106, which are described in detail as follows:

[0031] Step S101: extract the JSON interface use case to obtain key fields and their corresponding KV pairs.

[0032] In an embodiment of the present application, a JSON interface use case may be to first obtain the API interface document of the service being tested, and then use an automated tool (such as Swagger Codegen or PpenAPI Generator, etc.) to extract standard request and response formats from the API interface document, and generate a basic JSON interface use case, including a request use case and a response use case, wherein the API interface document defines the request format, response format, parameter type, and data range of the API, etc. The request use case generates a basic request JSON based on the request parameters and data types in the API document. For example, the interface document may indicate that "username" is a string type, and "password" is another string. The response use case extracts a standard JSON response structure from the response example in the API interface document, including return fields and their types, formats, etc. For example, the returned data may include fields such as `status`, `message`, and `userId`, and the value type of each field (such as string, integer, Boolean, etc.) is generated according to the description in the document. It should be noted that if the API interface document supports changes in request parameters (such as changes in parameter range or data type), additional rules can be used to dynamically generate multiple variants of JSON interface use cases. For example, the username (`username`) field can be randomly generated by a rule or replaced by selecting a valid username from the database; the password (`password′) field can also generate passwords of different complexities through a generator.

[0033] In an embodiment of the present application, the value dependencies of the key fields obtained will be stored in the memory recursively to form a dependency tree of KV (Key-Value) pairs. These dependencies will be actually referenced in the subsequent formation of new test cases and the execution of regression tests. Here, key fields refer to those fields that are crucial to the test results, usually parameters in interface requests or responses, and the values ​​of these parameters may affect each other or have some kind of dependency in the test. For example, assuming that you are testing a user registration API, the interface request body may contain the following fields:

[0034]

[0035] In this request body, **userId** may be automatically generated by the system rather than provided directly by the user. Therefore, there is a dependency in the test: the value of `userId` is generated by the system, which may be related to other fields (such as `username`), or related to some business logic. Therefore, the value dependency of key fields refers to the mutual influence, constraints or generation rules between these field values. For example, the value of some fields may be based on the values ​​of other fields (such as `username` and `userId'), or dynamically generated by the result of the previous interface call (such as the system-generated `userId').

[0036] In the above embodiment, the "KV pair dependency tree" refers to a hierarchical structure tree formed by the dependency relationship between the key (Key) and value (Value) of the key field. Each node represents a field (Key), and its child nodes or associated nodes represent other fields that depend on the field. In this way, the "KV pair dependency tree" shows the dependency relationship between fields, helping the test framework to dynamically manage and reference field values. And "storing dependencies recursively" means gradually establishing the dependency relationship between fields in memory in a recursive manner. For example: during the test process, if the value of a field depends on another field, the test system will first record this dependency, and then continue to recursively search whether the field value has other dependencies; when all dependencies are recorded, the system forms a tree structure, and each field (Key) and its corresponding value (Value) will be stored as a KV pair in the node of the tree, and the nodes are connected by dependencies. Assume that there are the following fields:

[0037] `userId` depends on `usemame`

[0038] `email` depends on `userId`

[0039] `username` itself is provided by the user

[0040] Dependencies can be built up step by step recursively:

[0041] `username` as the root node (field provided by the user).

[0042] `userId' is a child node that depends on `username' and its value is generated by the system.

[0043] `email`, as another child node, depends on `userId`, whose value may be based on `userId` or generated by the system. Ultimately, these dependencies will be represented as a tree structure:

[0044]

[0045] In memory, dependencies are stored as a recursive structure like this so that subsequent steps can dynamically reference the values ​​of related fields based on the dependencies.

[0046] Specifically, by extracting the JSON interface use case, obtaining the key field and its corresponding KV pair can be achieved through steps S1011 to S1013, as described in detail as follows:

[0047] Step S1011: extract input parameters and output results from the JSON interface use case.

[0048] Take a typical JSON interface use case as an example. Assume that the data returned by the interface is as follows:

[0049]

[0050]

[0051] The system will first identify the various fields in the JSON data, including input parameters (such as `userId', `userName', etc.) and output results (such as `age', `isAdmin', etc.).

[0052] Step S1012: Analyze the types and constraints of the extracted input parameters and output results.

[0053] For each field, the system will perform a type analysis. For example:

[0054] The `userId' field is a string type and should meet certain format constraints, such as a numeric string.

[0055] The `userName' field is of type string and should conform to a specific length range.

[0056] The `age` field is an integer and may have a valid range of values ​​(such as 18 to 100 years old).

[0057] The `isAdmin' field is of Boolean type and can only take the values ​​`true` or `false`.

[0058] At the same time, the system will model the constraints of each field, such as maximum value, minimum value, format requirements, etc., so as to facilitate verification and dynamic replacement in subsequent tests.

[0059] Step S1013: Based on the analysis results of the type and constraint condition analysis, each key field and its corresponding KV pair are generated.

[0060] In the embodiment of the present application, the analysis results of the field type and constraint condition analysis will affect the key fields and their corresponding KV pairs, which are reflected in the following aspects:

[0061] 1) According to the type of the field (such as integer, string, Boolean value, date, etc.), the system will generate data that conforms to the type. For string types (such as `userId', `userName') as an example, for `userId', the system knows that it should be a 6-digit string, so it will generate data like `″123456″`; for `userName`, the system knows that it should be a non-empty string with a length between 1 and 50 characters, so it can generate names like `″testUser″` or `″JohnDoe″`; for integer types (such as `age` ), for `age`, the system will generate a **legal integer value** according to its range (18 to 99), for example, it can generate '28` or `65`; taking the Boolean type (such as `isAdmin`) as an example, for `isAdmin`, the system knows that this field should be a Boolean value, so it can generate 'true` or `false`; taking the date type (such as `createdAt`) as an example, for `createdAt`, the system will generate a date string that conforms to the `YYYY-MM-DD` format, such as `″2024-11-15″`, and so on.

[0062] 2) The constraints of each field (such as maximum length, minimum value, required or not, etc.) will directly affect the generated value. For example, for `userId`, if it is required to be 6 digits, the system will automatically generate test data that meets this constraint (such as `"123456"`); for `userName`, if its length is required to be between 1 and 50 characters, the system will generate a random string within this range (such as `"JohnDoe"` or `"a"`); for `age`, if it is required to be between 18 and 99, the system will generate an integer that meets this range (such as `45`).

[0063] 3) If there is a dependency between fields (i.e. the value of one field may depend on the value of another field), the system needs to generate the value of the dependent field first, and then generate the related fields based on its value. For example: `userId` may be a unique identifier generated by the system based on `userName`. If `userName` is `″testUser"`, the system will generate an associated `userId`, such as `″12345"`; the `status` field may depend on other fields (such as `age`). If `age` is greater than a certain threshold, then `status` may be `″active"`, otherwise it may be `″inactive"`, and so on.

[0064] 4) Based on the type and constraint analysis, the system also needs to generate some boundary values ​​and special values ​​to ensure that the interface can work correctly in various scenarios. For example: age field (age): generate `18` (minimum value), `99` (maximum value), and some common values ​​(such as `25`, `50`) to verify the processing capability of the interface; username field (userName): generate legal usernames, such as `″testUser″`, as well as special character combinations, empty values, etc., to verify the fault tolerance of the system.

[0065] After generating each key field and its corresponding KV pair based on the analysis results of the field type and constraint analysis, the above embodiment also includes: verifying the value of each KV pair through rules to ensure that it meets the preset format requirements; adjusting the value range and type of the KV pair according to test requirements.

[0066] For example:

[0067] `userId: "12345"`

[0068] `userName: ″testUser″`

[0069] `age:28`

[0070] `isAdmin: true`

[0071] Step S102: Generate a reference JSON interface use case template according to preset rules.

[0072] In the embodiment of the present application, the reference JSON interface use case template is a predefined JSON format template used to describe the structure of the interface request and its field dependencies. The reference JSON interface use case template can contain static data (fixed values) and dynamic data (values ​​that need to be generated). For dynamic data, the template can contain some placeholders, indicating that the values ​​of these fields will be generated by referencing the values ​​of other fields or certain rules. For example, suppose there is a request template for a registration interface as follows:

[0073]

[0074]

[0075] Among them: `{{username}}`, `{{password}}`, `{{email}}`, etc. are **placeholders**, indicating that the values ​​of these fields will be dynamically replaced, and `{{generateUserId()}}` is a **function call**, indicating that the generation of `userId` needs to rely on some algorithm or system-generated logic. Each field may have different generation rules or dependencies. These dependencies are usually implemented in the following ways:

[0076] 1) Static replacement, that is, directly obtain values ​​from external data sources (such as databases, configuration files, other field values, etc.) and replace placeholders;

[0077] 2) Function generation, that is, some fields may need to be generated by custom generation rules, such as `generateUserId()`, which may generate new values ​​based on other parameters (for example, `username` or 'email`);

[0078] 3) Dependent fields, that is, there may be dependencies between fields, for example, `age` may depend on `birthdate`, and `email` may be associated with `username`.

[0079] As an embodiment of the present application, according to the preset rules, generating a reference JSON interface use case template may be implemented through steps S1021 and S1022, which are described in detail as follows:

[0080] Step S1021, constructing a preliminary structure of a reference JSON interface use case template according to the types and constraints of input parameters and output results.

[0081] For example, the system puts the extracted `userId`, `userName`, `age`, `isAdmin` fields into the template and uses placeholders to represent these fields:

[0082]

[0083]

[0084] In this template, field values ​​are replaced by placeholders, indicating that these fields need to be filled in subsequent dynamic replacements.

[0085] Step S1022, defining dynamic replacement rules for key fields in the reference JSON interface use case template, wherein the dynamic replacement rules include rules of <<key field step index>>.

[0086] For each field, the system will define its replacement method according to the preset rules. For example:

[0087] The replacement rule for `userId' may be to randomly select from a predefined data set, or fill in a specific value based on the current test requirements.

[0088] `userName` may be generated according to a certain pattern, such as generating different user names by concatenating strings and numbers.

[0089] The `age` field can be randomly replaced according to the legal range to ensure test diversity.

[0090] Step S103: Identify and mark key fields in the reference JSON interface use case template.

[0091] Specifically, by scanning the reference JSON interface use case template, you can identify all the field placeholders enclosed in curly braces (such as `{userId}`, `{userName}`, etc.), and then classify and mark the fields according to the field type and constraints. For example, `userId` may be marked as a "numeric field", `userName' as a "string field", `age` as an "integer field", `isAdmin' as a "Boolean type field", and so on.

[0092] Step S104: Perform a dynamic replacement operation according to the step index of the key field <<key field step index>> to obtain the replaced JSON data.

[0093] In the embodiments of the present application, "key fields" refer to fields that may change between different versions, while "steps" and "indexes" are used to identify specific test steps and field locations. The dependencies of these fields are saved in the reference JSON interface use case template generated by the aforementioned embodiments, which defines dynamic reference rules between fields.

[0094] Specifically, according to the step index of the key field <<key field step index>>, a dynamic replacement operation is performed to obtain the replaced JSON data through step 1041 and step S1042, which are described in detail as follows:

[0095] Step 1041: Identify the location of key fields in the JSON interface use case.

[0096] Specifically, appropriate data can be selected for replacement based on the step index. For example, for the 'userId' field, the system may select a new user ID from an ID pool for replacement. For the 'isAdmin' field, the system will select 'true' or 'false' as the replacement value.

[0097] Step 1042: According to the step index <<key field step index>>, select appropriate test data for dynamic replacement to obtain replaced JSON data.

[0098] Specifically, the replaced data can be rule-verified; different replacement strategies and appropriate test data can be selected for dynamic replacement according to different test scenarios and data types, and each placeholder is replaced with a new data value in the order of the step index to obtain the replaced JSON data. For example, the replaced JSON data may be as follows:

[0099]

[0100] In the above embodiment, the “replacement strategy” is to traverse all key fields in the reference JSON interface use case template in a recursive or iterative manner, and replace the placeholders of the key fields one by one according to the dependencies and rules of the key fields. Specifically, the replacement strategies include the following:

[0101] 1) Direct replacement, that is, if the value of the key field is fixed data from the outside or data entered by the user, directly replace the placeholder in the template with these values;

[0102] 2) Function generation, that is, if the value of the field needs to be generated through some calculation or generation rules, the corresponding generation function (such as `generateUserId()`) will be called to generate data and replace it;

[0103] 3) Recursive replacement, that is, if the field value depends on the value of other fields, recursive replacement is required. For example, `userId` depends on `username`, the system will first generate `username` and then use it to generate `userId`.

[0104] Step S105: Render the replaced JSON data to form a new test case.

[0105] Specifically, the replaced JSON data can be formatted and normalized to ensure that it meets the standardized interface requirements; check the dependencies in the rendering results to ensure that the dependency logic between the fields is correctly implemented. When the replaced JSON data meets the standardized interface requirements, for example, the replaced JSON data conforms to the correct syntax, the field order, case, data type, etc. conform to the expected format of the interface, the field conforms to the business rules of the interface (such as whether the field is required, whether there is a valid value range, etc.), and the logical dependencies between the fields in the replaced JSON data are correctly handled (for example, whether the value of a field correctly references other fields, or whether it is generated as expected, etc.), these replaced JSON data can be used as new test cases.

[0106] Step S106: Use the new test case to perform regression testing to verify the effectiveness and accuracy of the newly generated test case.

[0107] It should be noted that in the above-mentioned embodiment, after extracting the JSON interface use case, a test script can also be generated according to the JSON interface use case, in combination with a general framework and a test script template, that is, based on the JSON interface use case extracted from the API interface document or the actual API, and in combination with the test script template, a test script for execution is automatically generated. In the above-mentioned embodiment, the test script template includes the structure of the test case, verification logic (such as assertion, status code verification, etc.), request sending method (such as HTTP request, POST, GET, etc.), and how to extract information from the interface response. These automatically generated test scripts will be filled according to dynamically replaced data (such as user name, password, timestamp, etc.), which come from the test data generated by the dynamic generation rules in the previous step. For example, a test script for logging into an API may generate different test script instances according to different user names and passwords, and perform multiple tests.

[0108] During the regression testing phase, the system will automatically execute the newly generated test cases, send requests to the interface and verify the response results. The system will check whether the behavior of the interface under different data conditions is as expected, and generate a regression test report, listing the test results and problems found. Use the new test cases to perform regression testing to verify the validity and accuracy of the newly generated test cases. Specifically, the test framework (such as JUnit, TestNG, etc.) runs the test script, sends API requests and checks whether the response is as expected, that is, the test framework automatically fills in the parameters in the request (such as username, password), executes requests in multiple scenarios, and verifies the correctness of the interface. The execution results of these scripts (success, failure) will generate reports through the test framework so that developers or testers can promptly discover and fix problems in the interface. During specific execution, the test script uses the data in the newly generated test case to interact with the interface (send requests and receive responses), and asserts based on the results of the response (such as HTTP status code, returned data structure) to verify whether the interface functions correctly.

[0109] From the above attached Figure 1 It can be seen from the example of the automated regression testing method based on dynamic replacement that, on the one hand, it integrates customized JSON interface use cases and script template generation tools. During the test execution, the key field dependency reference descriptions in the reference JSON interface use case template are used to render the data of the dependent fields and generate correct test data, thereby ensuring the improvement of the test case execution efficiency and reducing the testers' repeated modifications to the JSON interface use cases. On the other hand, the test case generation method is highly flexible and adaptable. Users can adjust the data replacement rules or interface templates according to different test requirements and interface changes to dynamically adapt to changes in the software system and maintain the effectiveness and pertinence of the regression test. Thirdly, due to the use of automated generation and dynamic replacement, the generated test cases can adapt to different versions of interfaces without the need for repeated manual writing, thereby improving the reusability and maintainability of the test cases.

[0110] Please see attached Figure 2 , is an automated regression testing device based on dynamic replacement provided by an embodiment of the present application, the device may include an acquisition module 201, a generation module 202, an identification module 203, a replacement module 204, a rendering module 205 and a testing module 206, which are described in detail as follows:

[0111] The acquisition module 201 is used to acquire key fields and their corresponding KV pairs by extracting JSON interface use cases;

[0112] A generation module 202 is used to generate a reference JSON interface use case template according to a preset rule;

[0113] An identification module 203, used to identify and mark key fields in a reference JSON interface use case template;

[0114] A replacement module 204, used to perform a dynamic replacement operation according to the step index of the key field <<key field step index>> to obtain the replaced JSON data;

[0115] The rendering module 205 is used to render the replaced JSON data to form a new test case;

[0116] The testing module 206 is used to perform regression testing using new test cases to verify the effectiveness and accuracy of the new test cases.

[0117] From the above attached Figure 2 It can be seen from the example of the automated regression testing device based on dynamic replacement that, on the one hand, it integrates customized JSON interface use cases and script template generation tools. During the test execution, the key field dependency reference descriptions in the reference JSON interface use case template are used to render the data of the dependent fields and generate correct test data, thereby ensuring the improvement of the test case execution efficiency and reducing the testers' repeated modifications to the JSON interface use cases. On the other hand, the test case generation method is highly flexible and adaptable. Users can adjust the data replacement rules or interface templates according to different test requirements and interface changes to dynamically adapt to changes in the software system and maintain the effectiveness and pertinence of the regression test. Thirdly, due to the use of automated generation and dynamic replacement, the generated test cases can adapt to different versions of interfaces without the need for repeated manual writing, thereby improving the reusability and maintainability of the test cases.

[0118] Figure 3 Schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Figure 3 As shown, the electronic device 3 of this embodiment mainly includes: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program of an automated regression testing method based on dynamic replacement. When the processor 30 executes the computer program 32, the steps in the above-mentioned automated regression testing method embodiment based on dynamic replacement are implemented, such as Figure 1 Alternatively, when the processor 30 executes the computer program 32, the functions of each module / unit in the above-mentioned device embodiments are implemented, for example Figure 2 The functions of the image acquisition module 201, the generation module 202, the recognition module 203, the replacement module 204, the rendering module 205 and the testing module 206 are shown.

[0119] Exemplarily, the computer program 32 of the automated regression testing method based on dynamic replacement mainly includes: extracting JSON interface use cases to obtain key fields and their corresponding KV pairs; generating a reference JSON interface use case template according to preset rules; identifying and marking key fields in the reference JSON interface use case template; performing dynamic replacement operations according to the step index of the key field "key field_step_index" to obtain the replaced JSON data; rendering the replaced JSON data to form a new test case; using the new test case to perform regression testing to verify the validity and accuracy of the new test case. The computer program 32 can be divided into one or more modules / units, one or more modules / units are stored in the memory 31, and are executed by the processor 30 to complete the present application. One or more modules / units can be a series of computer program instruction segments that can complete specific functions, and the instruction segments are used to describe the execution process of the computer program 32 in the electronic device 3. For example, the computer program 32 can be divided into the functions of an image acquisition module 201, a generation module 202, an identification module 203, a replacement module 204, a rendering module 205 and a test module 206 (modules in the virtual device), and the specific functions of each module are as follows: an acquisition module 201 is used to obtain key fields and their corresponding KV pairs by extracting JSON interface use cases; a generation module 202 is used to generate a reference JSON interface use case template according to preset rules; an identification module 203 is used to identify and mark key fields in the reference JSON interface use case template; a replacement module 204 is used to perform a dynamic replacement operation according to the step index of the key field <<key field step index>> to obtain the replaced JSON data; a rendering module 205 is used to render the replaced JSON data to form a new test case; a test module 206 is used to perform regression testing using the new test case to verify the validity and accuracy of the new test case.

[0120] The electronic device 3 may include but is not limited to a processor 30 and a memory 31. Those skilled in the art will appreciate that Figure 3 It is only an example of the electronic device 3 and does not constitute a limitation of the electronic device 3. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0121] The processor 30 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0122] The memory 31 may be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 31 may also be an external storage device of the electronic device 3, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device 3. Further, the memory 31 may also include both an internal storage unit of the electronic device 3 and an external storage device. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 may also be used to temporarily store data that has been output or is to be output.

[0123] 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 for illustration. In actual applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned device can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0124] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0125] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0126] In the embodiments provided in the present application, it should be understood that the disclosed devices / equipment and methods can be implemented in other ways. For example, the device / equipment embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0128] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0129] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program of the automatic regression testing method based on dynamic replacement can be stored in a storage medium. When the computer program is executed by the processor, it can implement the steps of each of the above-mentioned method embodiments, that is, by extracting the JSON interface use case, obtaining the key fields and their corresponding KV pairs; generating a reference JSON interface use case template according to preset rules; identifying and marking the key fields in the reference JSON interface use case template; performing dynamic replacement operations according to the step index of the key field <<key field step index>> to obtain the replaced JSON data; rendering the replaced JSON data to form a new test case; using the new test case to perform regression testing to verify the validity and accuracy of the new test case. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. Storage media may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, mobile hard disks, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in the storage medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, storage media do not include electric carrier signals and telecommunication signals.

[0130] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application is described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some of the technical features therein by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. The specific implementation methods described above further describe the purpose, technical solutions and beneficial effects of the present application in detail. It should be understood that the above description is only the specific implementation method of the present application, and is not used to limit the protection scope of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the protection scope of the present invention.

Claims

1. An automated regression testing method based on dynamic replacement, characterized in that: The method comprises: By extracting the JSON interface use case, obtain the key fields and their corresponding KV pairs; Generate a reference JSON interface use case template based on preset rules; Identifying and marking the key fields in the reference JSON interface use case template; According to the step index <<key field_step_index>> of the key field, a dynamic replacement operation is performed to obtain the replaced JSON data; Render the replaced JSON data to form a new test case; Perform regression testing using the new test cases to verify the effectiveness and accuracy of the new test cases.

2. The automated regression testing method based on dynamic replacement as claimed in claim 1, characterized in that: The key fields and their corresponding KV pairs are obtained by extracting the JSON interface use case, including: Extract input parameters and output results from the JSON interface use case; Analyzing the types and constraints of the extracted input parameters and output results; Based on the analysis results of the type and constraint analysis, each key field and its corresponding KV pair are generated.

3. The automated regression testing method based on dynamic replacement as claimed in claim 2, characterized in that: The method further comprises: Verify the value of each KV pair through rules to ensure that it meets the preset format requirements; Adjust the value range and type of the KV pair according to test requirements.

4. The automated regression testing method based on dynamic replacement as claimed in claim 2, characterized in that: The reference JSON interface use case template is generated according to the preset rules, including: Construct a preliminary structure of a reference JSON interface use case template based on the types and constraints of the input parameters and output results; Dynamic replacement rules are defined for key fields in the reference JSON interface use case template, and the dynamic replacement rules include the rule of <<key field_step_index>>.

5. The automated regression testing method based on dynamic replacement as claimed in claim 1, characterized in that: The step index <<key field_step_index>> of the key field is used to dynamically replace the data to obtain the replaced JSON data, including: Identify the location of the key field in the JSON interface use case; According to the step index <<key field_step_index>>, appropriate test data is selected for dynamic replacement to obtain the replaced JSON data.

6. The automated regression testing method based on dynamic replacement as claimed in claim 5, characterized in that: The step of selecting appropriate test data for dynamic replacement according to the step index <<key field_step_index>> to obtain the replaced JSON data includes: Performing rule verification on the replaced data; According to different test scenarios and data types, different replacement strategies and appropriate test data are selected for dynamic replacement to obtain the replaced JSON data.

7. The automated regression testing method based on dynamic replacement as claimed in claim 1, characterized in that: Rendering the replaced JSON data to form a new test case includes: Formatting and normalizing the replaced JSON data to ensure that it complies with standardized interface requirements; Check the dependencies in the rendered results to ensure that the dependency logic between fields is implemented correctly.

8. An automated regression testing device based on dynamic replacement, characterized in that: The device comprises: The acquisition module is used to obtain key fields and their corresponding KV pairs by extracting JSON interface use cases; The generation module is used to generate a reference JSON interface use case template according to preset rules; An identification module, used to identify and mark the key fields in the reference JSON interface use case template; A replacement module, used to perform a dynamic replacement operation according to the step index <<key field_step_index>> of the key field to obtain the replaced JSON data; A rendering module, used for rendering the replaced JSON data to form a new test case; The testing module is used to perform regression testing using the new test cases to verify the effectiveness and accuracy of the new test cases.

9. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images