Test script generation method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a test script generation method and device, electronic equipment and a storage medium, and relates to the technical field of computers. The method comprises the steps of obtaining interface information of a target interface; based on the interface information, automatically generating a plurality of test cases and an initial test script corresponding to the target interface; the test case covers the positive scene and the negative scene; testing the target interface based on the initial test script to obtain an initial test response result; obtaining a baseline assertion for verifying the target interface according to a preset assertion rule and the initial test response result; writing the baseline assertion into the initial test script to obtain a target test script of the integrated baseline assertion corresponding to the target interface; the target test script is used for performing interface testing and generating a test report. The method and the device can be used in a test script generation process, and are used for solving the problems of low test script generation efficiency and insufficient scene applicability in the prior art.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and particularly relates to a test script generation method and device, electronic equipment and a storage medium. BACKGROUND

[0002] In the current situation of increasing popularity of service-oriented architecture, microservice architecture and cloud-native applications, a software system is usually composed of a large number of distributed services that complete data exchange and function calls through application programming interfaces (APIs). In the process of software development and delivery, interface testing is an important link to ensure the interaction quality and reliability of the external or internal modules of the software system. With the sharp increase in the number of interfaces, manually writing test cases and assertions is not only time-consuming and laborious, but also prone to omissions or inconsistencies. SUMMARY

[0003] The present application aims to provide a test script generation method and device, electronic equipment and a storage medium, and aims to solve the problem of how to improve the efficiency and application scenarios of API test script generation.

[0004] In a first aspect, a test script generation method is provided, which includes: obtaining interface information of a target interface; the interface information includes parameter types and parameter constraint information of interface parameters; the parameter constraint information includes necessity of interface parameters, parameter length limits and parameter value ranges; the necessity of interface parameters is used to indicate the necessity of interface parameters in an interface test scenario; based on the interface information, a plurality of test cases and an initial test script corresponding to the target interface are automatically generated; the test cases cover positive scenarios and negative scenarios; the target interface is tested based on the initial test script to obtain an initial test response result; a baseline assertion for verifying the target interface is obtained according to a preset assertion rule and the initial test response result; the baseline assertion is written into the initial test script to obtain a target test script corresponding to the target interface and integrated with the baseline assertion; and the target test script is used for interface testing and generating a test report.

[0005] The test script generation method provided in the application generates a plurality of test cases covering positive and negative scenarios and an initial test script corresponding to the target interface automatically based on the interface information. The interface information includes the parameter type and parameter constraint information of the interface parameters, and the parameter constraint information includes the necessity of the interface parameters, parameter length limit, and parameter value range. The necessity of the interface parameters indicates the necessity of the interface parameters in the interface test scenario. Subsequently, the initial test script is executed to test the target interface, and an initial test response result is obtained. Then, a baseline assertion for verifying the target interface is obtained according to the preset assertion rule and the initial test response result. Finally, the baseline assertion is written into the initial test script to obtain a target interface test script integrated with the baseline assertion. The script can directly perform interface testing and generate a test report. This method ensures the comprehensive coverage of the interface test scenarios by using the interface parameter constraints, ensures the accuracy and reliability of the test by generating the baseline assertion based on the real response result of the interface, and improves the generation efficiency of the test script through full-process automation.

[0006] In combination with the first aspect, in a possible implementation, based on the interface information, the plurality of test cases are automatically generated, including: constructing test data based on the interface information; and performing permutation and combination on the test data to generate the plurality of test cases covering the positive and negative scenarios.

[0007] In combination with the first aspect, in a possible implementation, the test cases of the positive scenario include positive test cases and first threshold combination test cases; the test cases of the negative scenario include parameter exception test cases and second threshold combination test cases; and the permutation and combination on the test data to generate the plurality of test cases covering the positive and negative scenarios includes: generating the first threshold combination test cases by using a Cartesian product algorithm according to the first parameter value range and the parameter length limit; generating the positive test cases according to the parameter mandatory attribute, the parameter length limit, and the default value of the interface parameters; generating the second threshold combination test cases by using the Cartesian product algorithm according to the second parameter value range and the parameter length limit; and generating the parameter exception test cases according to the parameter type, the parameter length limit, and the second parameter value range.

[0008] In combination with the first aspect, in a possible implementation, the baseline assertion for verifying the target interface is obtained according to the preset assertion rule and the initial test response result, including: performing filtering processing on the initial test response result according to a preconfigured noise reduction rule to obtain a filtered initial test response result; the noise reduction rule includes at least one of the following: ignoring a dynamic field satisfying a preset condition, and setting a comparison tolerance for a numerical field; and determining the baseline assertion of the target interface according to the preset assertion rule and the filtered initial test response result.

[0009] In a possible implementation manner of the first aspect, the baseline assertion is written into the initial test script to obtain the target test script corresponding to the integrated baseline assertion of the target interface, including: converting the baseline assertion into an assertion statement based on a programming language used by the initial test script; and embedding the assertion statement into the initial test script to obtain the target test script.

[0010] In a possible implementation manner of the first aspect, the method further includes: testing the target interface based on the target test script to obtain a target test response result; and automatically checking the target test response result by using the integrated baseline assertion in the target test script to obtain an interface test report; the test report includes a test case set and a test result.

[0011] In a possible implementation manner of the first aspect, the method further includes: in response to a business logic change instruction of the target interface, re-executing the target test script to obtain a new test response result; updating the baseline assertion of the target interface based on the new test response result; and updating the target test script based on the updated baseline assertion of the target interface.

[0012] In a possible implementation manner of the first aspect, the method further includes: in response to a business logic change instruction of the target interface, re-executing the target test script to obtain a new test response result; updating the baseline assertion of the target interface based on the new test response result; and updating the target test script based on the updated baseline assertion of the target interface.

[0013] In a possible implementation manner of the second aspect, the processing module is further configured to: in response to a business logic change instruction of the target interface, re-execute the target test script to obtain a new test response result; update the baseline assertion of the target interface based on the new test response result; and update the target test script based on the updated baseline assertion of the target interface.

[0014] With the second aspect above, in a possible implementation, the apparatus further includes an output module; the output module is configured to: perform testing on the target interface based on the target test script, to obtain a target test response result; automatically verify the target test response result based on the baseline assertion integrated in the target test script, to obtain an interface test report; and the test report includes a test case set and a test result.

[0015] In a third aspect, the present application provides an electronic device, including: a processor and a memory; the memory stores instructions executable by the processor; and the processor is configured to execute the instructions, so that the electronic device implements the method of the first aspect.

[0016] In a fourth aspect, the present application provides a computer-readable storage medium, including: computer software instructions; when the computer software instructions are run in an electronic device, the electronic device implements the method of the first aspect.

[0017] In a fifth aspect, the present application provides a computer program product, when the computer program product is run on a computer, the computer executes the steps of the related method described in the first aspect, to implement the method of the first aspect.

[0018] The beneficial effects of the second aspect to the fifth aspect can refer to the corresponding description of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0020] Figure 1 A schematic diagram of an API test script generation system provided by the embodiments of the present application;

[0021] Figure 2 A structural schematic diagram of an API test script application terminal provided by the embodiments of the present application;

[0022] Figure 3 A flowchart of a test script generation method provided by the embodiments of the present application;

[0023] Figure 4 A flowchart of a test script application method provided by the embodiments of the present application;

[0024] Figure 5 A flowchart of a test script update method provided by the embodiments of the present application;

[0025] Figure 6 An architecture diagram of a test script generation system provided for an embodiment of the present application is shown in FIG. 1.

[0026] Figure 7 A composition diagram of a test script generation apparatus provided for an embodiment of the present application is shown in FIG. 2.

[0027] Figure 8 A structure diagram of a test script generation apparatus provided for an embodiment of the present application is shown in FIG. 3. DETAILED DESCRIPTION

[0028] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort belong to the scope of protection of the present application.

[0029] It should be noted that, in the embodiments of the present application, the words such as “exemplarily” or “for example” are used to represent as an example, illustration or description. Any embodiment or design scheme described as “exemplarily” or “for example” in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. In fact, the words such as “exemplarily” or “for example” are used to present the related concept in a specific way.

[0030] In the embodiments of the present application, the terms “first”, “second”, “third”, “fourth”, “fifth”, and “sixth” are used only for descriptive purposes, and should not be construed as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features limited by “first”, “second”, “third”, “fourth”, “fifth”, and “sixth” can explicitly or implicitly include one or more of the features.

[0031] In the embodiments of the present application, the terms “include”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element limited by the statement “including one” does not exclude the presence of another identical element in the process, method, article or device including the element.

[0032] “A and / or B” includes the following three combinations: only A, only B, and the combination of A and B.

[0033] As described in the background, interface testing as a key link to verify the interface function, performance, security and stability, directly affects the overall quality of the system and user experience. However, with the expansion of the system, the number of interfaces grows exponentially, and the traditional interface testing method has been difficult to meet the rapid iteration, frequent change of development delivery requirements, mainly with the following defects:

[0034] 1. Insufficient response assertion for dynamic changes: The traditional assertion requires the developer or tester to write the expected field and value in advance, which cannot quickly adapt to the scenario where the response structure or field content changes.

[0035] 2. Insufficient parameter coverage: Traditional tools generate parameter test cases in a static combination way, which has insufficient parameter test coverage in some extreme scenarios.

[0036] Based on this, the embodiment of the present application provides a test script generation method, the method comprising: obtaining interface information of a target interface; the interface information comprising parameter types and parameter constraint information of interface parameters; the parameter constraint information comprising necessity of interface parameters, parameter length limit and parameter value range; the necessity of interface parameters is used to indicate the necessity of interface parameters in the interface test scene; based on the interface information, automatically generating a plurality of test cases and an initial test script corresponding to the target interface; the test cases cover positive scenarios and negative scenarios; based on the initial test script, testing the target interface to obtain an initial test response result; according to a preset assertion rule and the initial test response result, obtaining a baseline assertion for verifying the target interface; writing the baseline assertion into the initial test script to obtain a target test script corresponding to the target interface with integrated baseline assertion; the target test script is used for interface testing and generating a test report. The method ensures the comprehensive coverage of the interface test scene by using the interface parameter constraint, ensures the accuracy and reliability of the test by generating the baseline assertion based on the real response result of the interface, and improves the generation efficiency of the test script through the whole process automation.

[0037] Figure 1 A schematic diagram of an API test script generation system provided by the embodiment of the present application is shown in Figure 1 As shown, the API test script generation system 100 mainly consists of an API test script generation server 101 and an API test script application terminal 102, which are connected through wired or wireless network to complete the whole process from API document submission to API test script generation, execution and report output.

[0038] The API test script generation server 101 is the core part of the system, which undertakes the key tasks of API information processing, test case and script generation, script execution and subsequent processing.

[0039] In terms of API information processing, the server can receive the API document submitted by the API test script application terminal 102 and extract API information therefrom. The server can be configured with a special API document parsing module that can accurately identify and extract this information, laying a foundation for subsequent test case and script generation.

[0040] In the test case and script generation link, the server can be configured with data and computing resources divided by API type, parameter attribute, test scenario, etc. to support distributed generation and elastic scaling of large-scale API test cases and scripts. For example, the server can be configured with parameter information libraries of various APIs, test case generation rule sets (including generation logic for positive and negative scenarios), executable test script templates, and other resources. Based on the extracted API information, the server can automatically generate multiple test cases and corresponding executable test scripts covering positive scenarios (such as normal call scenarios with parameters fully complying with constraints) and negative scenarios (such as abnormal call scenarios with missing parameters, length exceeding limits, and out-of-range values).

[0041] In one possible way, the API test script generation server 101 can also be configured with a unified service management module for providing basic service functions such as user authentication, script generation task monitoring, and load balancing. Through user authentication, it is ensured that only users with appropriate permissions can submit API documents and initiate API test script generation requests; the task monitoring function can track the progress and status of test case and script generation in real time, making it easy for users to understand the generation situation; load balancing can reasonably allocate server resources when facing a large number of script generation requests, avoiding overloading of individual nodes and ensuring the efficiency and stability of script generation.

[0042] In addition, the API test script generation server 101 is also responsible for the execution of test scripts and the subsequent baseline assertion generation and script integration. It will execute the generated test scripts, send requests to the target API and obtain the actual response results; then, according to the preset assertion rules and the actual response results, obtain the baseline assertion for verifying the target API; finally, write the baseline assertion into the executable test script to obtain the target API test script integrated with the baseline assertion, which can be used to execute API testing and generate test reports. At the same time, the server also supports version management, storage management, etc. of these test scripts, ensuring the orderly management and efficient reuse of script resources.

[0043] In one possible manner, the API test script generation server 101 can be configured with a database or connected to an external database. The database can be used to backup various types of data such as API document information, extracted API information, test cases, historical response results, baseline assertions, etc. that need to be called during the generation of API test scripts and the execution of tests. In principle, no additional operations unrelated to the core function of script generation are performed. When the database is an external system connected to the API test script generation server 101, the database can adopt a distributed storage architecture and be deployed in multiple availability zones to improve data loading efficiency and reduce service latency, thereby ensuring efficient data access in large-scale API testing scenarios.

[0044] The API test script application terminal 102 is a carrier for user interaction with the system and is mainly used for submitting API documents and subsequent operations such as viewing test results.

[0045] The user can upload API documents through the API test script application terminal 102 and initiate a request for target API test script generation. Then, the terminal can obtain the target API test script related information integrated with baseline assertions generated by the API test script generation server 101.

[0046] Optionally, the API test script application terminal 102 can be a mobile device, a tablet computer, a desktop computer, a notebook computer, a special terminal device, or any device capable of interacting with the API test script generation server 101 through a network. In addition, the API test script application terminal 102 can also support user interaction through multiple ways such as keyboard input, touch, voice, etc. to facilitate user operation of the API testing process according to actual needs. The specific form of the API test script application terminal 102 is not specially limited in the present disclosure.

[0047] In one possible manner, the API test script generation server 101 can be a standalone server or a server cluster composed of multiple server nodes. In some embodiments, the server cluster can adopt a distributed architecture to support cross-regional deployment. Such an architecture design helps to improve the processing capacity, stability and scalability of the server to cope with API test script generation and application requirements of different scales and different regions.

[0048] Optionally, in the API test script generation system 100 shown in the above figure, the API test script generation server 101 can be connected to at least one API test script application terminal 102. The number and type of API test script application terminals 102 are not limited in the present disclosure.

[0049] In combination with Figure 1 For example, Figure 2As shown in FIG. 1, a structure schematic diagram of an API test script application terminal provided by an embodiment of the present application is shown. The API test script application terminal 102 can be configured with an input module 21, a communication module 22 and a display module 23. The input module 21 can be a computer external input device such as a mouse and a keyboard, or can be a touch screen, and is mainly used to support the user to perform click operations and the like. The communication module 22 can be any kind of transceiver device, and is used for the API test script application terminal 102 to communicate with other devices (such as the document review background server 101) or a communication network. The display module 23 can be a liquid crystal display and the like, and can be used to display an API information uploading page, an API test script generation result page and the like.

[0050] The test script generation method provided by the embodiment of the present application will be described in detail below in combination with specific embodiments and the accompanying drawings of the specification.

[0051] Figure 3 A flowchart of the test script generation method provided by the embodiment of the present application is shown. Specifically, as shown in FIG. 2, the method comprises the following steps. Figure 3

[0052] S301, interface information of a target interface is acquired.

[0053] The interface information comprises a parameter type and parameter constraint information of an interface parameter, and the parameter constraint information comprises necessity of the interface parameter, parameter length limitation and parameter value range. The necessity of the interface parameter is used to indicate necessity of the interface parameter in an interface test scenario.

[0054] The core of the interface information comprises the parameter type and the parameter constraint information of the interface parameter. The parameter type is a data type attribute of the interface parameter, and is used to specify a data format specification of the parameter. The parameter constraint information comprises the following key contents: 1. parameter necessity, which is used to indicate whether the parameter is a necessary element to be provided in the interface test scenario, and is directly related to a determination of whether the parameter is required in the test case design; 2. parameter length limitation, which is a limitation range of a parameter character length or a data length; and 3. parameter value range, which specifies an effective value interval of a parameter allowed value, a character or an enumeration value. These interface information together constitute a basis for interface testing, development and interactive verification, and ensure the standardization and effectiveness of interface calling.

[0055] In an implementable manner, in combination with Figure 1 and Figure 2 When the test demand side needs to test the target interface, the test demand side can perform an editing operation through the input module 21 configured by the API test script application terminal 102 to edit an API description document of the target interface to be tested.

[0056] ​Then, after the test demand side completes the editing, the test demand side can upload the API description document of the target interface to be tested to the API test script generation server 101 through the API test script application terminal 102 configured communication module 22, so as to ensure that the API test script generation server 101 can obtain the API description document of the target interface, and then perform the subsequent operation of test script generation.

[0057] In another possible way, when the target interface is in a running state or a test environment, the actual request and response data of the target interface can be obtained through proxy interception or log analysis, and the key elements, that is, the interface information, are parsed and extracted.

[0058] S302, based on the interface information, automatically generating a plurality of test cases and an initial test script corresponding to the target interface.

[0059] Among them, the test case covers the positive scene and the negative scene.

[0060] For example, based on the analysis of the interface information, a plurality of test cases can be automatically generated according to a preset rule. The positive scene test case covers the case that the request parameter completely meets the requirement and normally triggers the core function of the interface, such as that the required parameter is complete and the value is in the valid range, and the optional parameter is configured according to the normal configuration. The negative scene test case includes the parameter abnormal scene, such as missing required parameter, parameter data type error, value exceeding the limited range, illegal request format, etc. At the same time, according to the interface calling protocol (such as HTTP, RPC) and the parameter configuration of the test case, the initial test script corresponding to the target interface is automatically generated, which includes the interface calling address, the request method, the parameter assignment logic, the response result receiving and preliminary judgment code, so as to ensure that the script can be directly used for preliminary interface test execution.

[0061] For example, the interface information is extracted by the interface document analysis module, which specifically includes the URL (if it is HTTP protocol) or service name and method name (if it is RPC protocol) of the interface, the field name, data type, value range, required parameter identification of the request parameter, and the field and data type of the return parameter. When generating the test case, the request parameter in the positive scene completely meets the requirement and can normally trigger the core function of the interface; in the negative scene, the request parameter is abnormal and cannot completely meet the interface requirement. The initial test script is generated in Python language, which includes the interface calling code of the requests library (or the corresponding protocol calling library), the parameter assignment is associated with the test case data, and the response status code judgment (such as 200 for normal) and the return parameter non-empty verification code are added.

[0062] S303, based on the initial test script, testing the target interface to obtain an initial test response result.

[0063] In a possible implementation, the test script generation method can deploy an initial test script to a preset test environment (such as an interface test dedicated server), which is network-interconnected and configured to match the deployment environment of the target interface (such as the same database version and dependent service state). The initial test script is executed, and the script sends a request (including a request header, a request parameter, and the like) to the target interface according to a preset logic, and receives the interface return data in real time. After the script execution is completed, the initial test response result is collected, which includes a response status code (such as 200, 400, 500, and the like) returned by the interface, response header information, response body data (such as a business return result and error prompt information), and key logs (such as request sending time, response receiving time, and whether a request timeout occurs) in the script execution process, to ensure that the response result can fully reflect the processing of the initial test request by the target interface and provide basic data for subsequent test result analysis.

[0064] S304, obtaining a baseline assertion for verifying the target interface according to the preset assertion rule and the initial test response result.

[0065] The preset assertion rule covers a response status code checking rule, a response body data checking rule, and a response time threshold rule. The response status code, the response body key field value, and the actual response time in the initial test response result are matched and compared with the standard values (such as a status code 200, a business code = 0, and a time consumption ≤ 1000 ms) of the corresponding preset assertion rule. If the initial response result conforms to the preset rule, the key checking items of the initial response result are taken as a basis to generate a baseline assertion for subsequent verification of the target interface.

[0066] S305, writing the baseline assertion into the initial test script to obtain a target test script corresponding to the integrated baseline assertion of the target interface.

[0067] The target test script is used for interface testing and generating a test report.

[0068] The baseline assertion content is analyzed to obtain the checking types (such as a status code matching, a field value checking, and a format verification), the target parameters, and the expected values of each assertion item. Based on the programming language (such as Python and Java) of the initial test script, the assertion function of the corresponding test framework is called to convert the baseline assertion into executable code item by item. The generated assertion code is inserted into the response result receiving link of the initial test script, so that the baseline assertion checking is automatically triggered after the script executes the interface request. The integrated script is subjected to syntax checking and logic verification to ensure that the assertion code does not conflict with the original script, and finally the target test script is formed. The script can perform interface testing, record the assertion result (pass or fail), and generate a test report including a test case, an assertion result, and response details according to a preset template.

[0069] Optionally, the test script in the present application can be implemented by various programming languages, for example, the test script can be implemented by Python language, and can also be implemented by Java language, and the present disclosure does not limit the specific code implementation of the test script.

[0070] In some embodiments, based on the interface information, a plurality of test cases are automatically generated, including: constructing test data based on the interface information, and arranging and combining the test data to generate a plurality of test cases covering positive scenarios and negative scenarios.

[0071] For example, first, the types, value ranges, necessity and other business constraint information of the request parameters are extracted by analyzing the interface information, and then test data is constructed based on the information. Subsequently, the test data is arranged and combined to generate a plurality of test cases covering positive scenarios and negative scenarios.

[0072] For example, taking the "user registration interface" as an example, three request parameters are obtained by analyzing the interface information: "phone" (string, 11 digits, required), "age" (integer, 0-100, required), and "nickname" (string, 1-20 characters, optional). The test data is constructed as follows: "phone: 13800138000, 1380013800 (10 digits), 1380013800a (containing letters)", "phone: missing", "age: 0, 50, 100, -1, 101", and "nickname: TestUser". The test data is arranged and combined to generate a plurality of test cases covering positive scenarios and negative scenarios.

[0073] In some embodiments, the test cases of the positive scenarios include positive cases and first threshold combination cases; the test cases of the negative scenarios include parameter exception cases and second threshold combination cases; the test data is arranged and combined to generate a plurality of test cases covering positive scenarios and negative scenarios, including: generating the first threshold combination cases by the Cartesian product algorithm according to the first parameter value range and the parameter length limit; generating the positive cases according to the parameter mandatory attribute, the parameter length limit and the default value of the interface parameter; generating the second threshold combination cases by the Cartesian product algorithm according to the second parameter value range and the parameter length limit; and generating the parameter exception cases according to the parameter type, the parameter length limit and the second parameter value range.

[0074] The first parameter value range is a parameter legal value interval or set specified in the interface information, and is a value constraint that the parameter must satisfy when the interface is normally running, and can be used to generate a first threshold combination use case of "verifying the compliance boundary value processing capability of the interface pair". The second parameter value range is a non-legal value interval or set opposite to the first parameter value range, and is a parameter value range that is explicitly prohibited in the interface document, and can be used to generate a second threshold combination use case of "verifying the fault tolerance capability of the interface pair to illegal values" and a parameter exception use case.

[0075] For example, the core attributes of the parameters in the interface information are extracted first, including the value range of each parameter (such as the integer parameter "amount" 0-10000), the length limit (such as the string parameter "mobile phone number" 11 digits), the necessity (marked as "required" or "optional"), and the default value (such as "payment method" default "balance payment"). When generating positive scenario test cases, on the one hand, for positive use cases, filter the required parameters and assign valid values, and configure optional parameters according to default values or valid values, to ensure that the parameters are normal and meet the basic requirements of the interface; on the other hand, for the first threshold combination use case, select the boundary values of the parameter value range (such as "amount" 0, 10000) and the critical values of the length limit (such as "mobile phone number" 11 digits), and combine the thresholds of different parameters through the Cartesian product algorithm to cover the positive limit scenarios of multiple parameter threshold coexistence. When generating negative scenario test cases, for the second threshold combination use case, select the boundary values outside the parameter value range (such as "amount" -1, 10001) and the critical values outside the length limit (such as "mobile phone number" 10 digits, 12 digits), and combine the negative scenario use cases of multiple parameter thresholds through the Cartesian product algorithm; for the parameter exception use case, generate type mismatch values (such as passing a string to an integer parameter) based on the parameter type (such as integer, string), and combine non-critical values outside the length limit (such as "mobile phone number" 5 digits) and non-critical values outside the value range (such as "amount" 20000) to construct single-parameter or multi-parameter non-threshold exception test cases, and finally form a test case set covering all scenarios.

[0076] For example, taking the "order submission interface" as an example, its parameters include "orderAmount" (integer, 0-10000, required), "phone" (string, 11 digits, required), and "payType" (string, taking values "balance", "wechat", and "alipay", optional, default "balance"). Generate positive use cases: configure "orderAmount: 5000 (0-10000), phone: 13800138000 (11 digits), payType: balance (default value)" and "orderAmount: 8000, phone: 13900139000, payType: wechat (valid value)", and ensure that the parameters are normal. Generate the first threshold combination use case: select "orderAmount" threshold 0, 10000, "phone" threshold 11 digits (such as 13700137000), and combine to get "orderAmount: 0, phone: 13700137000, payType: balance" and "orderAmount: 10000, phone: 13700137000, payType: alipay" by Cartesian product algorithm. Generate the second threshold combination use case: select "orderAmount" super threshold -1, 10001, "phone" super threshold 10 digits (1360013600), 12 digits (136001360000), and combine to get "orderAmount: -1, phone: 1360013600, payType: balance" and "orderAmount: 10001, phone: 136001360000, payType: wechat". Generate parameter exception use cases: generate "orderAmount: 'five' (string)" according to type mismatch, generate "phone: '135' (3 digits)" according to length exception, generate "orderAmount: 20000" and "payType: 'cash' (non-specified value)" according to value range exception, construct "orderAmount: 'five' + phone: 13800138000" and "phone: '135' + orderAmount: 6000" and other use cases, and complete the generation of full-scene test cases.

[0077] In some embodiments, the baseline assertion for verifying the target interface is obtained according to the preset assertion rule and the initial test response result, including: filtering the initial test response result according to a preconfigured noise reduction rule to obtain a filtered initial test response result; the noise reduction rule includes at least one of the following: ignoring a dynamic field satisfying a preset condition, setting a comparison tolerance for a numerical value type field; determining the baseline assertion of the target interface according to the preset assertion rule and the filtered initial test response result.

[0078] For example, by obtaining and analyzing the initial test response result, a dynamic field (such as a timestamp, a randomly generated serial number) and a numerical value type field (such as an amount, a time consumption) in the test response result are obtained. According to the preconfigured noise reduction rule, if there is a dynamic field (such as a field name containing "timestamp" or "serialNo") satisfying a preset condition, the field is ignored in subsequent assertion comparison; if a comparison tolerance is set for the numerical value type field (such as an amount field allowing an error of ±0.01 or a time consumption allowing a fluctuation of ±50 ms), the tolerance range is recorded. After filtering, the processed response result (containing the reserved fixed field, the numerical value type field with the tolerance) is compared with the preset assertion rule (such as a status code = 200, a business code = 0, a fixed field value matching), and if the rule is met, the filtered response result key information (containing the tolerance setting) is used as the basis to determine the baseline assertion of the target interface.

[0079] For example, the initial test response result is {"code": 0, "msg": "success", "data": {"orderNo": "ORD20240520001", "amount": 100.00, "createTime": "2024-05-20 14:30:00", "responseTime": 200ms}}. The preconfigured noise reduction rules are: 1. Ignore dynamic fields with "createTime" and "orderNo" in the field name; 2. The numerical field "amount" has a tolerance of ±0.01, and the "responseTime" has a tolerance of ±50ms. After filtering processing, the "code", "msg", "amount" (with a tolerance of ±0.01), "responseTime" (with a tolerance of ±50ms) are retained. The preset assertion rules are: status code = 200, "code" = 0, "amount" = 100.00, and "responseTime" ≤ 250ms. After comparing the filtered results, the status code is 200, "code" = 0, "amount" 100.00 (within the tolerance), and "responseTime" 200ms (≤ 250ms), which meets the rules. Finally, the baseline assertion is determined as: status code = 200, "code" = 0, "amount" ∈ [99.99, 100.01], and "responseTime" ∈ [150ms, 250ms].

[0080] In some embodiments, the baseline assertion is written into the initial test script to obtain a target test script corresponding to the integrated baseline assertion of the target interface, including: converting the baseline assertion into an assertion statement based on the programming language adopted by the initial test script; embedding the assertion statement into the initial test script to obtain the target test script.

[0081] In a possible implementation, first, the programming language of the initial test script is identified, and according to the syntax rules of the test framework corresponding to the language, each check item (such as status code, field value, and tolerance range) of the baseline assertion is converted into an executable assertion statement, such as: for fixed value checking, an equal value judgment statement is generated; for tolerance range checking, an interval judgment statement is generated; and for field existence checking, a non-empty / existence judgment statement is generated. Subsequently, the embedding position of the assertion statement in the initial script is determined, such as after the interface request sending code and before the response result receiving code, to ensure that the script acquires the response first and then executes the assertion. The converted assertion statement is embedded in the position in logical order, and assertion result capturing code is added, which is used to record the assertion passing or failure state, to finally form the target test script of the integrated baseline assertion.

[0082] For example, taking the initial test script in Python language and unittest framework as an example, the baseline assertion contains 4 items: status code = 200, "code" = 0, "amount" ∈ [99.99, 100.01], and "responseTime" ≤ 250 ms. According to the unittest syntax, the assertion statements are converted to: self.assertEqual(response.status_code, 200), self.assertEqual(response.json()["code"], 0), self.assertTrue(99.99 ≤ response.json()["data"]["amount"] ≤ 100.01), and self.assertLessEqual(response.elapsed.total_seconds()*1000, 250). The "response = requests.post(url, json=params)" in the initial script is the response receiving code, and the above assertion statements are embedded after it, and a try: (assertion code block) except AssertionError as e: self.fail(f"assertion failed: {str(e)}") is added. After embedding, the script can execute the request, trigger the assertion, and capture the result, generating the target test script integrated with the baseline assertion.

[0083] In some embodiments, Figure 4 A flowchart of a test script application method is provided for the embodiments of the present application. Specifically, as shown in Figure 4 the flowchart includes the following:

[0084] S401, testing the target interface based on the target test script to obtain a target test response result.

[0085] S402, automatically verifying the target test response result by using the baseline assertion integrated in the target test script to obtain an interface test report.

[0086] The test report includes a test case set and a test result.

[0087] Exemplarily, the target test script can be deployed to a preset test environment, a test request is sent to the target interface by executing the script, and a target test response result (including a status code, a response body, a time consumption, etc.) is received and recorded. The script automatically calls integrated baseline assertions, and checks the response result item by item according to preset rules (such as status code matching and field value range verification). If the response meets the assertion rule, it is marked as “pass”; if it does not meet the rule, specific differences (such as actual status code deviation from the expected value) are recorded. After the checking is completed, the script summarizes the test data according to a preset template, and generates an interface test report. The report includes a test case set (including parameter configurations of positive / negative scene cases) and a test result (assertion pass status, failure reason, and response details of each case), supports storage in a structured format (such as HTML and JSON), and intuitively presents the functional compliance of the target interface.

[0088] In some embodiments, Figure 5 A flowchart of a test script updating method provided by an embodiment of the present application is shown in FIG. 5. Specifically, as shown in FIG. 5, the method includes the following steps. Figure 5

[0089] S501, in response to a business logic change instruction of a target interface, re-executing a target test script to obtain a new test response result.

[0090] S502, updating baseline assertions of the target interface based on the new test response result.

[0091] S503, updating the target test script based on the updated baseline assertions of the target interface.

[0092] ​For example, when receiving a service logic change instruction (such as adding a function, adjusting a parameter, or modifying a return format) of a target interface, the re-execution of the target test script is triggered. Under the configuration consistent with the original test environment (the same server and dependent service version), the target test script integrated with the baseline assertion is run, the request of all test cases is sent to the changed target interface, and the new test response result containing the new response status code, response body structure, and field value is obtained. Based on the new response result, the baseline assertion is updated: the differences between the original baseline assertion and the new response result are compared (such as the newly added field “discount” needs to be included in the assertion, and the value range of the original “amount” field is expanded), the applicable assertion items are retained (such as the status code 200), the invalid items are deleted (such as the “coupon” field verification unique to the old version), the assertion items adapted to the changes are added (such as “discount” is non-empty and ≥ 0), and the updated baseline assertion is formed. Finally, according to the original script programming language syntax, the updated baseline assertion is converted into a new assertion statement, the corresponding old assertion code block in the target test script is replaced, the parameter configuration of the test case in the script (such as the assignment of the newly added mandatory parameter “promoCode”) is updated synchronously, the update of the target test script is completed, and it is ensured that it matches the changed interface service logic.

[0093] For example, upon receiving a business logic change instruction to "add discount function to the order interface," this instruction involves adding a required parameter "promoCode" (string, 6 characters), adding a "discount" field (numeric, 0-50) to the return body, and adjusting the value range of the "amount" field to 50-20000. Re-execute the target test script: run the original script in the JMeter environment, adding the parameter "promoCode:ABC123" to the test cases, send a request to the changed interface, and obtain the new response result (including "discount:20" and "amount:180"). Update the baseline assertions: retain "status code = 200" and "code = 0," delete the original "amount∈[99.99,100.01]," and add "promoCode format is 6 alphanumeric characters," "discount∈[0,50]," and "amount∈[50,20000]." Update the target test script: In the Python script, replace the original amount assertion statement with "self.assertTrue(50≤response.json()["data"]["amount"]≤20000)", add "self.assert Regex(response.json()["data"]["promoCode"],r"^[A-Z0-9]{6}$")", and "self.assertTrue(0≤response.json()["data"]["discount"]≤50)", and add "promoCode":"ABC 123" to the request parameters. Complete the script update to adapt to the interface change.

[0094] In summary, in some embodiments, Figure 6 This is an architecture diagram of a test script generation system provided in an embodiment of this application. Figure 6 As shown, the test script generation system covers several core layers, including a data processing layer, a business layer, an automated testing framework, and an automated testing management platform. Each layer works together through different functional modules to achieve full-process automation from API documentation acquisition to test case and script generation, and then to test execution and management.

[0095] In the data processing layer, the acquisition module first comes into play. The core task of this module is to acquire API documents. API documents contain API definition information and request examples, and are the basis for subsequent interface testing work. They provide a basis for accurately parsing interface parameters and generating test content that fits the interface function. After acquiring the API documents, the parameter parsing module begins to operate and parses the API documents to extract parameter attributes. Parameter attributes involve the type of parameter, whether it is required, value range, and other key information. These information is crucial for generating accurate test cases, ensuring that test cases can effectively test the interface parameters.

[0096] The business layer is mainly composed of the use case generation module. This module generates Python scripts and parameter combinations based on parameter information. Specifically, it takes the parameter information parsed by the data processing layer as input and generates Python scripts and corresponding parameter combinations based on this information. The generated Python scripts are executable test script prototypes, while the parameter combinations cover various possible calling scenarios of the interface, including legal parameter combination scenarios and illegal parameter combination scenarios, thus laying the foundation for comprehensive testing of interface functions and ensuring that the interface can be effectively verified under different parameter input conditions.

[0097] The automated testing framework includes a request sending module and an assertion processing module. The request sending module uses the automated testing framework to debug the generated test cases. During the debugging process, it sends requests to the target interface to simulate actual interface calling scenarios, in order to verify whether the interface response meets expectations. After the target interface returns a response message, the assertion processing module establishes a baseline assertion based on the response message. The baseline assertion is a standard for judging whether the interface response is compliant. By comparing the actual response result with the baseline assertion, it can be determined whether the interface performance in this test meets the requirements, achieving automated verification of interface functions.

[0098] Finally, the automated testing management platform, which is the core function of saving generated scripts and test cases to the test management database. The scripts and test cases related to testing are stored and managed uniformly. On the one hand, it is convenient for subsequent retrieval and calling of these testing resources, facilitating repeated interface testing or updating and iteration of test content. On the other hand, it also helps to trace and manage the testing process and results, providing effective resource management and historical record support for the entire interface testing work, making interface testing work more standardized and efficient, and improving the manageability and sustainability of interface testing.

[0099] The test script generation method provided in this application includes: obtaining interface information of a target interface; the interface information includes parameter types and parameter constraint information of interface parameters; the parameter constraint information includes the necessity of interface parameters, parameter length limits, and parameter value ranges; the necessity of interface parameters is used to indicate the necessity of interface parameters in the interface test scenario; based on the interface information, automatically generating multiple test cases and an initial test script corresponding to the target interface; the test cases cover positive and negative scenarios; testing the target interface based on the initial test script to obtain initial test response results; obtaining baseline assertions for verifying the target interface according to preset assertion rules and the initial test response results; writing the baseline assertions into the initial test script to obtain a target test script with integrated baseline assertions corresponding to the target interface; the target test script is used to execute interface tests and generate a test report. This method ensures comprehensive scenario coverage for interface testing by utilizing interface parameter constraints, ensures the accuracy and reliability of testing by generating baseline assertions based on the actual response results of the interface, and improves the efficiency of test script generation through full-process automation.

[0100] In an exemplary embodiment, Figure 7 This is a schematic diagram illustrating the composition of a test script generation device provided in an embodiment of this application. Figure 7 As shown, the test script generation device includes an acquisition module 701 and a processing module 702. The acquisition module 701 acquires interface information of the target interface. This interface information includes parameter types and constraint information for the interface parameters. The constraint information includes the necessity of the interface parameters, parameter length limits, and parameter value ranges. The necessity of the interface parameters indicates their necessity in the interface test scenario. The processing module 702 automatically generates multiple test cases and an initial test script corresponding to the target interface based on the interface information. The test cases cover both positive and negative scenarios. The processing module 702 also tests the target interface based on the initial test script to obtain initial test response results. Furthermore, the processing module 702 obtains baseline assertions for verifying the target interface based on preset assertion rules and the initial test response results. Finally, the processing module 702 writes the baseline assertions into the initial test script to obtain a target test script with integrated baseline assertions for the target interface. The target test script is used to perform interface testing and generate a test report.

[0101] In some embodiments, the processing module 702 is further configured to: re-execute the target test script to obtain a new test response result in response to a business logic change instruction of the target interface; update the baseline assertion of the target interface based on the new test response result; and update the target test script based on the updated baseline assertion of the target interface.

[0102] In some embodiments, the apparatus further comprises an output module; the output module is configured to test the target interface based on the target test script, and obtain a target test response result. The target test response result is automatically verified by using the baseline assertion integrated in the target test script, and an interface test report is obtained. The test report comprises a test case set and a test result.

[0103] In an exemplary embodiment, the embodiments of the present application further provide an electronic device, which can be a test script generation apparatus in the method embodiments. Figure 8 A structural schematic diagram of a test script generation apparatus provided by the embodiments of the present application is shown in FIG. 1. As shown in the figure, the test script generation apparatus can comprise a processor 801 and a memory 802; the memory 802 stores instructions executable by the processor 801; and the processor 801 is configured to execute the instructions, so that the electronic device or the network device or the manager implements the system functions as described in the foregoing method embodiments. Figure 8

[0104] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the apparatus is divided into different functional modules to complete all or part of the functions described above.

[0105] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. For example, the apparatus embodiments described above are only schematic, for example, the division of the modules or units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another apparatus, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, apparatuses or units, and can be electrical, mechanical or other forms.

[0106] The units described as separate components can or can not be physically separate, and the components shown as units can be one physical unit or multiple physical units, that is, can be located in one place, or can be distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0107] ​In addition, each function unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software function unit.

[0108] When the integrated unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application essentially or the parts that make contributions to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The software product is stored in a storage medium, including a plurality of instructions to make a device (which can be a single-chip microcomputer, a chip, etc.) or a processor execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk, and various storage program codes.

[0109] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any change or replacement within the technical scope disclosed in the present application should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for generating test scripts, characterized in that, The method includes: Obtain the interface information of the target interface; the interface information includes the parameter type and parameter constraint information of the interface parameters; the parameter constraint information includes the necessity of the interface parameters, parameter length limits, and parameter value ranges; the necessity of the interface parameters is used to indicate the necessity of the interface parameters in the interface testing scenario; Based on the interface information, multiple test cases and initial test scripts corresponding to the target interface are automatically generated; the test cases cover positive and negative scenarios. The target interface is tested based on the initial test script to obtain the initial test response results; Based on the preset assertion rules and the initial test response results, a baseline assertion for verifying the target interface is obtained; The baseline assertion is written into the initial test script to obtain the target test script for the integrated baseline assertion corresponding to the target interface; the target test script is used to perform interface testing and generate a test report.

2. The method according to claim 1, characterized in that, Based on the interface information, multiple test cases are automatically generated, including: Test data is constructed based on the interface information; The test data is arranged and combined to generate multiple test cases covering positive and negative scenarios.

3. The method according to claim 2, characterized in that, The test cases for the positive scenario include positive test cases and test cases combining the first threshold; the test cases for the negative scenario include test cases for parameter anomalies and test cases combining the second threshold; the process of arranging and combining the test data to generate multiple test cases covering both positive and negative scenarios includes: Based on the range of values ​​for the first parameter and the length limitation of the parameter, a first threshold combination example is generated using the Cartesian product algorithm; Generate positive test cases based on the required parameter attributes, the parameter length limit, and the default values ​​of the interface parameters; Based on the range of values ​​for the second parameter and the parameter length limitation, a second threshold combination use case is generated using the Cartesian product algorithm; Parameter exception test cases are generated based on the parameter type, the parameter length limit, and the value range of the second parameter.

4. The method according to claim 1, characterized in that, The step of obtaining a baseline assertion for verifying the target interface based on preset assertion rules and the initial test response results includes: The initial test response result is filtered according to the pre-configured noise reduction rules to obtain the filtered initial test response result; the noise reduction rules include at least one of the following: ignoring dynamic fields that meet preset conditions, and setting a comparison tolerance for numerical fields; Based on the preset assertion rules and the initial test response results after filtering, the baseline assertion of the target interface is determined.

5. The method according to claim 1, characterized in that, The step of writing the baseline assertion into the initial test script to obtain the target test script for the integrated baseline assertion corresponding to the target interface includes: Based on the programming language used in the initial test script, the baseline assertions are converted into assertion statements; The assertion statement is embedded into the initial test script to obtain the target test script.

6. The method according to claim 1, characterized in that, The method further includes: The target interface is tested based on the target test script to obtain the target test response result; The baseline assertions integrated in the target test script are used to automatically verify the target test response results, resulting in an interface test report; the test report includes a test case set and test results.

7. The method according to claim 6, characterized in that, The method further includes: In response to the business logic change instruction of the target interface, the target test script is re-executed to obtain a new test response result; Update the baseline assertion of the target interface based on the new test response results; The target test script is updated based on the updated baseline assertions of the target interface.

8. A test script generation device, characterized in that, The device includes: an acquisition module and a processing module; The acquisition module is used to acquire interface information of the target interface; the interface information includes the parameter type and parameter constraint information of the interface parameters; the parameter constraint information includes the necessity of the interface parameters, parameter length limit, and parameter value range; the necessity is used to indicate the necessity of the interface parameters in the interface testing scenario; The processing module is used to automatically generate multiple test cases and initial test scripts corresponding to the target interface based on the interface information; the test cases cover positive and negative scenarios; The processing module is also used to test the target interface based on the initial test script to obtain the initial test response result; The processing module is further configured to obtain a baseline assertion for verifying the target interface based on the preset assertion rules and the initial test response results; The processing module is further configured to write the baseline assertion into the initial test script to obtain the target test script for the integrated baseline assertion corresponding to the target interface; the target test script is used to execute interface tests and generate a test report.

9. An electronic device, characterized in that, The controller includes: a processor and a memory; The memory stores instructions that the processor can execute; When the processor is configured to execute the instructions, the controller causes the controller to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes: computer software instructions; When the computer software instructions are executed in an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-7.

Images