Automated interface testing method and apparatus, electronic device and storage medium

Abstract

Provided are an automated interface testing method and apparatus, an electronic device and a storage medium, belonging to the technical field of computers. The method comprises: executing an automated testing case to test an interface under test, so as to obtain a response result returned by said interface; intercepting a request header of an interface request generated by executing the automated testing case; and, when the request header comprises a target request parameter, invoking a customized assertion check response result in respect of said interface, so as to obtain a test result of said interface, the target request parameter representing ignoring a general global assertion. The present application intercepts the request header and, if finding out from the request header the request parameter that represents ignoring the general global assertion, invokes a method that ignores the global assertion, so as to achieve the purpose of no longer checking the global assertion but checking the customized assertion of the interface, thus improving automated interface testing efficiency.

Description

Interface automated testing method, device, electronic device, and storage medium

[0001] Related applications

[0002] This application claims priority to the Chinese invention patent with patent application number 202410180067.1, application date February 18, 2024, and invention name “Interface automation testing method, device, electronic device and storage medium”. Technical Field

[0003] The present application relates to the field of computer technology, and in particular to an interface automation testing method, device, electronic device, and storage medium. Background Art

[0004] In today's internet industry, with increasingly fierce competition, improving testing efficiency and reducing testing costs have become a consensus. Automated testing, as a technical tool, can provide high-quality feedback and assurance for software, making it more stable and reliable. However, despite the numerous benefits of automated testing, writing automated scripts and use cases also carries significant costs. Therefore, reducing automated testing costs and improving testing efficiency has become a crucial consideration for every tester. Using the right tools and methods directly impacts the efficiency of test script writing.

[0005] Assertions are a well-known requirement for every script and are a core step in automated testing. Existing technologies often use global assertions to improve testing efficiency. Global assertions are assertions that can be shared and reused across the entire test suite, helping testers reduce the workload of repetitive assertion writing, thereby improving testing efficiency.

[0006] However, due to the differences in parameters returned by some interfaces, the use of global assertions is very ineffective, because assertions for hundreds of interfaces must be repeated for a few interfaces, greatly reducing test efficiency. Summary of the Invention

[0007] The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes an interface automation testing method, device, electronic device and storage medium to improve the efficiency of interface automation testing.

[0008] In a first aspect, the present application provides an interface automation testing method, comprising:

[0009] Run the automated test case to test the interface to be tested and obtain the response result returned by the interface to be tested;

[0010] Intercepting the request header in the interface request generated by running the automated test case;

[0011] In the case where the request header contains a target request parameter, a custom assertion for the interface to be tested is called to verify the response result to obtain a test result of the interface to be tested; wherein the target request parameter indicates ignoring a general global assertion.

[0012] According to the interface automation testing method of the present application, the interface to be tested is tested by running an automated test case to obtain a response result returned by the interface to be tested; the request header in the interface request generated by running the automated test case is intercepted; when the request header contains a target request parameter, the custom assertion for the interface to be tested is called to verify the response result to obtain a test result of the interface to be tested; wherein the target request parameter indicates ignoring a general global assertion. The embodiment of the present application intercepts the request header in the process of running an automated test case to test the interface. If a request parameter indicating ignoring a general global assertion is found in the request header, the method of ignoring the global assertion is called to achieve the purpose of no longer verifying the global assertion, but to verify the custom assertion of this interface, thereby avoiding the problem in the prior art that the use effect of the global assertion is very poor due to the differences in the parameters returned by some interfaces, thereby improving the efficiency of interface automation testing.

[0013] According to one embodiment of the present application, running the automated test case to test the interface to be tested and obtaining a response result returned by the interface to be tested includes:

[0014] Run automated use cases to generate interface requests;

[0015] The interface request is sent to the interface to be tested, and a response result returned by the interface to be tested based on the interface request is obtained.

[0016] This embodiment generates an interface request by running an automated use case, and sends the interface request to the interface to be tested to implement the test of the interface to be tested, and then can verify the response result returned by the interface to be tested based on the interface request, thereby implementing the test of the interface to be tested.

[0017] According to one embodiment of the present application, when the request header contains the target request parameter, calling the custom assertion for the interface to be tested to verify the response result and obtaining the test result of the interface to be tested includes:

[0018] In the case where the request header contains the target request parameter, the response result is set to pass the global assertion verification, and the custom assertion for the interface to be tested is called to verify the response result to obtain the test result of the interface to be tested.

[0019] This embodiment intercepts the request header during the process of running the automated test case test interface. If the request header includes a request parameter indicating to ignore the general global assertion, the program will call the method of ignoring the global assertion when running to the global assertion, set the response result to pass the global assertion verification, and no longer execute the global assertion step. Instead, the custom assertion set for the interface to be tested is executed to verify the response result, thereby ignoring the global assertion and preventing the situation where the verification output result is a test failure due to the response result not meeting the global assertion rules.

[0020] According to an embodiment of the present application, when the request header does not include the target request parameter, the response result is verified against the global assertion to obtain the test result of the interface to be tested.

[0021] This embodiment intercepts the request header during the process of running an automated test case to test the interface. If the request header does not include a request parameter indicating that a general global assertion should be ignored, it indicates that the interface to be tested can use a general global assertion to verify the response result, avoiding the need to fully write assertions for each interface, thereby improving testing efficiency.

[0022] According to one embodiment of the present application, before running the automated test case to test the interface to be tested, the method further includes:

[0023] Acquire the response characteristics of the interface to be tested; the response characteristics represent the characteristics of the response results made by the interface to be tested to different interface requests;

[0024] In the case that the response characteristic does not conform to the rule of the global assertion, the target request parameter is added to the automated test case so that the request header of the interface request generated by running the automated test case includes the target request parameter.

[0025] This embodiment determines whether the assertion of the interface to be tested is applicable to the global assertion based on the response characteristics of the interface to be tested. If it is not applicable to the global assertion, continuing to use the global assertion will cause the test result to fail or the test error to occur. In the case that the assertion of the interface is not applicable to the global assertion, a target request parameter indicating that the general global assertion is ignored can be added to the automated test case. When running the automated test case, if the target request parameter is found, the general global assertion can be ignored, thereby avoiding the test failure caused by verifying the response result through the global assertion.

[0026] According to an embodiment of the present application, when the response characteristic does not comply with the rules of the global assertion, the custom assertion is generated based on the response characteristic to make the response characteristic comply with the rules of the custom assertion.

[0027] This embodiment sets a custom assertion that matches the response characteristics of the interface to be tested when it is determined that the assertion of the interface to be tested is not applicable to the global assertion based on the response characteristics of the test interface. This allows the interface to be tested to be verified through the custom assertion during the test process without passing the global assertion verification, thereby completing the interface test and further improving the efficiency of interface automation testing.

[0028] In a second aspect, the present application provides an interface automation testing device, comprising:

[0029] The running module is used to run the automated test case to test the interface to be tested and obtain the response result returned by the interface to be tested;

[0030] An interception module, used to intercept the request header in the interface request generated by running the automated test case;

[0031] The verification module is used to call the custom assertion for the interface to be tested to verify the response result when the request header contains the target request parameter, so as to obtain the test result of the interface to be tested; wherein, the target request parameter indicates ignoring the general global assertion.

[0032] According to the interface automation testing device of the present application, the interface to be tested is tested by running an automated test case to obtain a response result returned by the interface to be tested; the request header in the interface request generated by running the automated test case is intercepted; when the request header contains a target request parameter, the custom assertion for the interface to be tested is called to verify the response result, thereby obtaining a test result of the interface to be tested; wherein the target request parameter indicates ignoring a general global assertion. The embodiment of the present application intercepts the request header in the process of running an automated test case to test the interface. If a request parameter indicating ignoring a general global assertion is found in the request header, the method of ignoring the global assertion is called to achieve the purpose of no longer verifying the global assertion, but verifying the custom assertion of this interface, thereby avoiding the problem in the prior art that the use effect of the global assertion is very poor due to the differences in the parameters returned by some interfaces, thereby improving the efficiency of interface automation testing.

[0033] 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 when the processor executes the computer program, the interface automation testing method as described in the first aspect above is implemented.

[0034] In a fourth aspect, the present application provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the interface automation testing method as described in the first aspect above.

[0035] In a fifth aspect, the present application provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the interface automation testing method described in the first aspect above.

[0036] In a sixth aspect, the present application provides a computer program product, comprising a computer program, which, when executed by a processor, implements the interface automation testing method as described in the first aspect above.

[0037] The above one or more technical solutions in the embodiments of the present application have at least one of the following technical effects:

[0038] According to the interface automation testing method of the present application, the interface to be tested is tested by running an automated test case to obtain a response result returned by the interface to be tested; the request header in the interface request generated by running the automated test case is intercepted; when the request header contains a target request parameter, the custom assertion for the interface to be tested is called to verify the response result to obtain a test result of the interface to be tested; wherein the target request parameter indicates ignoring a general global assertion. The embodiment of the present application intercepts the request header in the process of running an automated test case to test the interface. If a request parameter indicating ignoring a general global assertion is found in the request header, the method of ignoring the global assertion is called to achieve the purpose of no longer verifying the global assertion, but to verify the custom assertion of this interface, thereby avoiding the problem in the prior art that the use effect of the global assertion is very poor due to the differences in the parameters returned by some interfaces, thereby improving the efficiency of interface automation testing.

[0039] Furthermore, in some embodiments, an interface request is generated by running an automated use case, and the interface request is sent to the interface to be tested to implement the testing of the interface to be tested, and then the response result returned by the interface to be tested based on the interface request can be verified, thereby implementing the testing of the interface to be tested.

[0040] Furthermore, in some embodiments, by intercepting the request header during the process of running the automated test case test interface, if the request header includes a request parameter indicating that the general global assertion is to be ignored, the program will call the method of ignoring the global assertion when it runs to the global assertion, set the response result to pass the global assertion verification, and no longer execute the global assertion step. Instead, it executes the custom assertion set for the interface to be tested to verify the response result, thereby ignoring the global assertion and preventing the situation where the verification output result is a test failure due to the response result not meeting the global assertion rules.

[0041] Furthermore, in some embodiments, by intercepting the request header during the process of running an automated test case to test the interface, if the request header does not include a request parameter indicating that the general global assertion should be ignored, it means that the interface to be tested can use the general global assertion to verify the response result, avoiding the need to fully write assertions for each interface, thereby improving testing efficiency.

[0042] Furthermore, in some embodiments, by judging whether the assertion of the interface to be tested is applicable to the global assertion based on the response characteristics of the interface to be tested, if it is not applicable to the global assertion, continuing to use the global assertion will cause the test result to fail or the test to fail. In the case that the assertion of the interface is not applicable to the global assertion, a target request parameter indicating that the general global assertion is ignored can be added to the automated test case, so that during the running of the automated test case, if the target request parameter is found, the general global assertion can be ignored, thereby avoiding the test failure caused by verifying the response result through the global assertion.

[0043] Furthermore, in some embodiments, when it is determined that the assertion of the interface to be tested is not applicable to the global assertion based on the response characteristics of the test interface, a custom assertion that is consistent with the response characteristics of the interface to be tested is set, so that the interface to be tested can be verified through the custom assertion during the testing process without passing the global assertion verification, so as to complete the interface test, thereby further improving the efficiency of interface automation testing.

[0044] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become obvious from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments with reference to the accompanying drawings, in which:

[0046] FIG1 is a flow chart of an interface automation testing method according to an embodiment of the present application;

[0047] FIG2 is a schematic diagram of setting a global assertion according to an embodiment of the present application;

[0048] FIG3 is a schematic diagram of an example scenario provided by an embodiment of the present application;

[0049] FIG4 is a schematic diagram of the structure of an interface automation testing device provided in an embodiment of the present application;

[0050] FIG5 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the embodiments described are 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 fall within the scope of protection of this application.

[0052] The terms "first," "second," and the like in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of this application can be implemented in an order other than that illustrated or described herein, and that the objects distinguished by "first," "second," and the like are generally of the same type, and do not limit the number of objects; for example, the first object can be one or more. In addition, the term "and / or" in the specification and claims refers to at least one of the connected objects, and the character " / " generally indicates that the objects connected are in an "or" relationship.

[0053] Writing automated test scripts is a significant investment, primarily due to the need for a deep understanding of the business logic and functionality of the software being tested, as well as the skills and tools required to write robust and reliable test scripts. Furthermore, the design and coverage of various test scenarios, along with maintenance and updates, all require significant time and effort.

[0054] Assertions are operations or statements used in automated testing to verify that expected results match actual results. They are a crucial step in automated testing, as they directly determine whether test cases can accurately detect software issues and defects. To reduce time and effort and improve testing efficiency, automated testing can be implemented using global assertions. Global assertions allow assertions to be shared and reused across the entire test suite, reducing the workload of testers writing repetitive assertions. However, due to the variability in the parameters returned by some interfaces, the effectiveness of global assertions is very poor, as assertions for just a few interfaces must be rewritten for hundreds of interfaces. This is because if the parameters returned by the interfaces vary, a different assertion must be written for each interface, preventing the reuse of global assertions. This increases the cost of writing and maintaining test scripts, reduces writing efficiency, and ultimately reduces testing efficiency.

[0055] This application considers that if reusable global assertions can be used for automated testing based on the similarity of parameters returned by some interfaces, and the reusable global assertions can be ignored for the differences in parameters returned by other interfaces, and customized assertions of these interfaces can be used for automated testing instead, it is expected to solve the problem in the prior art that the use of global assertions is very poor due to the differences in parameters returned by some interfaces.

[0056] The interface automation testing method, device, electronic device and storage medium provided in the embodiments of the present application are described in detail below with reference to the accompanying drawings through specific embodiments and their application scenarios.

[0057] The interface automation testing method may be applied to a terminal, and may be specifically executed by hardware or software in the terminal.

[0058] The terminal includes, but is not limited to, a portable communication device such as a mobile phone or tablet computer having a touch-sensitive surface (e.g., a touch screen display and / or a touch pad). It should also be understood that, in some embodiments, the terminal may not be a portable communication device, but a desktop computer having a touch-sensitive surface (e.g., a touch screen display and / or a touch pad).

[0059] In the following embodiments, a terminal including a display and a touch-sensitive surface is described. However, it should be understood that the terminal may include one or more other physical user interface devices such as a physical keyboard, a mouse, and a joystick.

[0060] The interface automation testing method provided in the embodiment of the present application can be executed by an electronic device or a functional module or functional entity in the electronic device that can implement the interface automation testing method. The electronic devices mentioned in the embodiment of the present application include but are not limited to mobile phones, tablet computers, computers, cameras and wearable devices, etc. The interface automation testing method provided in the embodiment of the present application is explained below using an electronic device as an example of the execution subject.

[0061] As shown in FIG1 , the interface automation testing method includes: step 110 , step 120 and step 130 .

[0062] Step 110: Run the automated test case to test the interface to be tested and obtain the response result returned by the interface to be tested.

[0063] An automated test case is a description of a series of test steps and expected results that are executed during the automation testing process. These test cases are usually written by testers to verify that the various functions and features of a software application work as expected.

[0064] A typical automated test case includes the following parts: Test name / ID: a name or number used to uniquely identify the test case; Preconditions: describes the conditions or environment settings that need to be met before executing the test case; Test steps: describes in detail the operation steps required to execute the test case, including input data, trigger operations, etc.; Expected results: describes the expected output or behavior of each test step for comparison with the actual results; Assertions: In automated testing, assertions are usually included to check whether the actual results meet the expected results; Cleanup operations: describes the cleanup operations that need to be performed after executing the test case, such as restoring the environment status.

[0065] The writing of automated test cases needs to consider comprehensive test coverage, including positive and negative test scenarios, boundary conditions, exceptions, etc. In addition, good automated test cases should be easy to maintain and extend, able to be executed in different environments and configurations, and able to provide detailed test reports and log information.

[0066] In an embodiment of the present application, an automated test case can be run on an automated testing tool to test the interface to be tested and obtain a response result returned by the interface to be tested. For example, an automated test case can be run on an automated testing tool such as JMeter, Postman, Selenium, Appium, RestAssured, etc. to test the interface to be tested.

[0067] When testing an interface to be tested, the automated testing tool sends an interface request to the interface to be tested. This request is usually an HTTP request, including the request method (such as GET, POST, PUT, DELETE, etc.), the request URL (the address of the interface), request parameters (if any), the request body (for POST and PUT requests), and other related information.

[0068] When the interface request is sent to the interface to be tested, the interface to be tested will process it according to the content of the request and the logic of the interface itself and return a response result. This response result is usually an HTTP response, including a status code, a response header, a response body, and other parts. Among them, the status code is a three-digit code used to indicate the result of the server's processing of the request. Common status codes include 200 (OK, request successful), 404 (Not Found, resource not found), 500 (Internal Server Error, server internal error), etc.; the response header contains some metadata, such as server type, content type, content length, etc. This information can help the client correctly process the server's response; the response body contains the specific data returned by the server, such as data in formats such as JSON, XML, HTML, etc. This part of the data is usually what the client really cares about and is used to verify the correctness and integrity of the interface.

[0069] Step 120: intercept the request header in the interface request generated by running the automated test case.

[0070] In the embodiments of this application, the request header is part of the interface request and is used to convey additional information to the requested server. The request header contains metadata such as user agent information, content type, and authorization information. In interface testing, the request header is typically used to convey necessary information such as authorization information, Accept, and Content-Type. This information helps the server correctly process the request and helps the client correctly parse the server's response.

[0071] During the automated testing of the test interface, the request header will be intercepted to obtain the information in the request header.

[0072] Step 130: When the request header contains the target request parameter, call the custom assertion verification response result for the interface to be tested to obtain the test result of the interface to be tested; wherein the target request parameter indicates ignoring the general global assertion.

[0073] Assertions are often included in automated testing to check whether actual results match expected results. For example, consider a test case for a login page. The test steps involve entering a username and password, clicking the login button, and then verifying whether a welcome message appears on the page after a successful login. In this test case, an assertion is needed to verify whether the welcome message appears on the page after a successful login. If it does, the assertion passes, and the test passes. If it does not, the assertion fails, and the test fails. This way, assertions can be used to determine the success of a test case and identify issues and defects in the software.

[0074] Global assertions are assertions that can be shared and reused across the entire test suite, helping testers reduce the workload of rewriting assertions and improving testing efficiency. For example, if many test cases need to verify that a welcome message is displayed on a page, this assertion can be written as a global assertion and then called in each test case. This eliminates the need to rewrite the same assertion code, improving the reusability and maintainability of the test script.

[0075] However, due to the differences in the parameters returned by some interfaces, the use effect of global assertions is very poor, because certain interfaces cause the assertions of hundreds of interfaces to be written repeatedly. Therefore, in an embodiment of the present application, when the tester is writing an automated test case, he or she determines whether the assertion of the interface to be tested is applicable to the global assertion by checking the response of the interface to be tested. If it is not applicable to the global assertion, a special identifier can be added to the request header of the interface request, that is, the target request parameter can be added so that the global assertion is ignored when the interface is executed. Then, a custom assertion can be added to the settings of the current interface to be tested, so that a specific assertion check can be performed for the interface without affecting the global assertion settings of other interfaces. This approach allows testers to control the behavior of assertions more flexibly, enabling them to customize the assertion settings according to the specific circumstances to ensure the accuracy and reliability of the test case.

[0076] In an embodiment of the present application, if the target request parameter is found in the request header, it means that the interface to be tested is not suitable for the global assertion. Therefore, the custom assertion set for the interface to be tested can be called to verify the response result. If the response result meets the expected result, the assertion passes and the test result obtained is the test passed; if the response result does not meet the expected result, the assertion fails and the test result obtained is the test failed.

[0077] According to the interface automation testing method of the present application, the interface to be tested is tested by running an automated test case to obtain a response result returned by the interface to be tested; the request header in the interface request generated by running the automated test case is intercepted; when the request header contains the target request parameter, the custom assertion verification response result for the interface to be tested is called to obtain the test result of the interface to be tested; wherein the target request parameter indicates ignoring the general global assertion. The embodiment of the present application intercepts the request header in the process of running the automated test case to test the interface. If a request parameter indicating ignoring the general global assertion is found in the request header, the method of ignoring the global assertion is called to achieve the purpose of no longer verifying the global assertion, but to verify the custom assertion of this interface, thereby avoiding the problem in the prior art that the use effect of the global assertion is very poor due to the differences in the parameters returned by some interfaces, thereby improving the efficiency of interface automation testing.

[0078] In some embodiments, running an automated test case to test the interface to be tested and obtaining a response result returned by the interface to be tested may include:

[0079] Run automated use cases to generate interface requests;

[0080] Send the interface request to the interface to be tested, and obtain the response result returned by the interface to be tested based on the interface request.

[0081] In this embodiment, an interface request can be generated by running an automated use case, and then the interface request is sent to the interface to be tested. The interface to be tested will process the request according to the content of the request and the logic of the interface itself and return a response result.

[0082] Let's take a simple example to illustrate. Suppose there is a user registration interface and you want to test the functionality of this interface. First, you will write an automated test case that describes the test steps, input data, and expected results of the registration interface. For example:

[0083] Test case 1:

[0084] Steps: Send a POST request to the registration interface

[0085] Input data: {"username":"testuser","password":"123456"}

[0086] Expected result: Receive status code 200 and the response body contains the message "Registration successful"

[0087] Next, you can use an automated testing tool (such as Postman, JMeter, RestAssured, etc.) to execute this test case. When the automated testing tool runs the test case, it will configure a POST request, fill in the interface URL and request body data, and then send the interface request to the corresponding interface.

[0088] Interface request:

[0089] Method: POST

[0090] URL: http: / / example.com / api / register

[0091] Request body: {"username":"testuser","password":"123456"}

[0092] After the interface request is sent, the automated testing tool will verify the interface response result and compare the actual response result with the expected result in the test case. If the actual response meets the expected result, the test will pass; if not, the test will fail.

[0093] This embodiment generates an interface request by running an automated use case, and sends the interface request to the interface to be tested to implement the test of the interface to be tested, and then can verify the response result returned by the interface to be tested based on the interface request, thereby implementing the test of the interface to be tested.

[0094] In some embodiments, when the request header contains target request parameters, calling a custom assertion verification response result for the interface to be tested to obtain a test result of the interface to be tested may include:

[0095] When the request header contains the target request parameters, set the response result to pass the global assertion verification, and call the custom assertion verification response result for the interface to be tested to obtain the test result of the interface to be tested.

[0096] In this embodiment, if a target request parameter indicating that a general global assertion is ignored is found in the request header, it means that the interface to be tested is not applicable to the global assertion. Then, the response result can be set to pass the global assertion verification, and the custom assertion verification response result for the interface to be tested can be called. Specifically, as shown in Figure 2, the written assertion method beanshell script can be placed in the global assertion of the environment variable. When the interface to be tested is tested through an automated test case, the automated test tool will load the automated test case. When the script corresponding to the global assertion is run, the method in the script will intercept the request header of the interface request and then determine whether the request header includes a target request parameter indicating that a general global assertion is ignored. If so, the response result is set to pass the global assertion verification without executing the actual verification process of the global assertion. Then, the custom assertion verification response result for the interface to be tested is called to obtain the test result of the interface to be tested.

[0097] This embodiment intercepts the request header during the process of running the automated test case test interface. If the request header includes a target request parameter indicating that the general global assertion is to be ignored, the program will call the method of ignoring the global assertion when running to the global assertion, set the response result to pass the global assertion verification, and no longer execute the global assertion step. Instead, the custom assertion set for the interface to be tested is executed to verify the response result, thereby ignoring the global assertion and preventing the situation where the verification output result is a test failure due to the response result not meeting the global assertion rules.

[0098] In some embodiments, when the request header does not contain the target request parameter, a call is made to verify the response result of the global assertion to obtain the test result of the interface to be tested.

[0099] This embodiment intercepts the request header during the process of running an automated test case to test the interface. If the request header does not include a request parameter indicating that the general global assertion should be ignored, it indicates that the interface to be tested can use the general global assertion to verify the response result, avoiding the need to fully write assertions for each interface, thereby improving testing efficiency.

[0100] In some embodiments, before running the automated test case to test the interface to be tested, the method further includes:

[0101] Obtain the response characteristics of the interface to be tested; the response characteristics represent the characteristics of the response results made by the interface to be tested to different interface requests;

[0102] When the response characteristics do not meet the rules of the global assertion, the target request parameters are added to the automated test case so that the request header of the interface request generated by running the automated test case includes the target request parameters.

[0103] In this embodiment, when writing an automated test case, the response characteristics of the interface to be tested can be checked to determine whether the assertions of the interface to be tested are applicable to the global assertions. If not applicable to the global assertions, a target request parameter can be added to the automated test case so that the request header of the interface request generated by running the automated test case contains the target request parameter, so that the global assertions are ignored when executing the interface.

[0104] The response characteristic represents the characteristic of the response result of the interface to be tested to different interface requests. For example, the response characteristic may be that the response result fed back by the interface is to display the user's welcome message. Specifically, after the user enters the username and password, an interface request is generated. If the interface verifies that the username has been registered and the password is correct, the response result is to enter the login success page and display the user's welcome message. Entering different usernames and passwords will generate different interface requests. As long as the interface verifies that the username has been registered and the password is correct, the response result is to enter the login success page and display the user's welcome message, that is, the response characteristic of the interface is to display the user's welcome message. Of course, different interfaces have different response characteristics. The above description is only an example to illustrate the response characteristics and does not limit the response characteristics.

[0105] In this embodiment, it is possible to determine whether the assertion of the interface is applicable to the global assertion based on the response characteristics of the interface to be tested. Specifically, first, the settings of the global assertion can be checked to obtain the rules of the global assertion, which can usually be set in the configuration file of the automated testing framework or tool; then the response characteristics of the interface are analyzed, that is, the interface request is executed, and the response data of the interface to be tested is obtained, and the response data of the interface to be tested is analyzed, including the status code, the fields and content in the response body, etc., to obtain the response characteristics of the interface to be tested; then, the response characteristics of the interface to be tested are compared with the rules of the global assertion. If the response characteristics of the interface to be tested meet the rules of the global assertion, then it can be considered that the assertion of the interface is applicable to the global assertion. If not, it is necessary to add a target request parameter indicating that the global assertion is ignored in the automated test case, so that the request header in the interface request generated by running the automated test case includes the target request parameter, thereby ignoring the global assertion during the interface automated testing process.

[0106] This embodiment determines whether the assertion of the interface to be tested is applicable to the global assertion based on the response characteristics of the interface to be tested. If it is not applicable to the global assertion, continuing to use the global assertion will cause the test result to fail or the test error to occur. In the case that the assertion of the interface is not applicable to the global assertion, a target request parameter indicating that the general global assertion is ignored can be added to the automated test case. When running the automated test case, if the target request parameter is found, the general global assertion can be ignored, thereby avoiding the test failure caused by verifying the response result through the global assertion.

[0107] In some embodiments, if the response characteristics do not comply with the rules of the global assertion, a custom assertion is generated based on the response characteristics to make the response characteristics comply with the rules of the custom assertion.

[0108] This embodiment sets a custom assertion that matches the response characteristics of the interface to be tested when it is determined that the assertion of the interface to be tested is not applicable to the global assertion based on the response characteristics of the test interface. This allows the interface to be tested to be verified through the custom assertion during the test process without passing the global assertion verification, thereby completing the interface test and further improving the efficiency of interface automation testing.

[0109] This application also provides a scenario example to illustrate the application process of the interface automation testing method provided in the embodiment of this application. As shown in Figure 3, this scenario example includes steps Step 1 to Step 4.

[0110] Step 1: Run the automation script use case through the interface automation platform to obtain the response result returned by the interface;

[0111] Step 2: Intercept the request header;

[0112] Step 3: Determine whether there are request parameters in the request header that ignore the global assertion. If so, execute Step 4; otherwise, execute Step 5.

[0113] Step 4: Only verify the custom assertions in the current script and generate assertion results;

[0114] Step 5: Run global assertions and generate assertion results;

[0115] Step 6: Check the assertion results.

[0116] The interface automation testing method provided in the embodiment of the present application can be executed by an interface automation testing device. In the embodiment of the present application, the interface automation testing device is used as an example to illustrate the interface automation testing method provided in the embodiment of the present application.

[0117] An embodiment of the present application also provides an interface automation testing device.

[0118] As shown in Figure 4, the interface automation test device includes:

[0119] The running module 410 is used to run the automated test case to test the interface to be tested and obtain the response result returned by the interface to be tested;

[0120] Interception module 420, for intercepting the request header in the interface request generated by running the automated test case;

[0121] The verification module 430 is used to call the custom assertion verification response result for the interface to be tested when the request header contains the target request parameter to obtain the test result of the interface to be tested; wherein the target request parameter indicates ignoring the general global assertion.

[0122] According to the interface automation testing device of the present application, the interface to be tested is tested by running an automated test case to obtain a response result returned by the interface to be tested; the request header in the interface request generated by running the automated test case is intercepted; when the request header contains a target request parameter, the custom assertion verification response result for the interface to be tested is called to obtain a test result of the interface to be tested; wherein the target request parameter indicates ignoring a general global assertion. The embodiment of the present application intercepts the request header in the process of running an automated test case to test the interface. If a request parameter indicating ignoring a general global assertion is found in the request header, the method of ignoring the global assertion is called to achieve the purpose of no longer verifying the global assertion, but verifying the custom assertion of this interface, thereby avoiding the problem in the prior art that the use effect of the global assertion is very poor due to the differences in the parameters returned by some interfaces, thereby improving the efficiency of interface automation testing.

[0123] In some embodiments, the execution module 410 is further configured to:

[0124] Run automated use cases to generate interface requests;

[0125] Send the interface request to the interface to be tested, and obtain the response result returned by the interface to be tested based on the interface request.

[0126] In some embodiments, the verification module 430 is further configured to:

[0127] When the request header contains the target request parameters, set the response result to pass the global assertion verification, and call the custom assertion verification response result for the interface to be tested to obtain the test result of the interface to be tested.

[0128] In some embodiments, the verification module 430 is further configured to:

[0129] When the request header does not contain the target request parameters, the global assertion verification response result is called to obtain the test result of the interface to be tested.

[0130] In some embodiments, the interface automation testing device further includes:

[0131] The acquisition module is used to obtain the response characteristics of the interface to be tested; the response characteristics represent the characteristics of the response results made by the interface to be tested to different interface requests;

[0132] A module is added to add target request parameters to the automated test case when the response characteristics do not meet the rules of the global assertion, so that the request header in the interface request generated by running the automated test case includes the target request parameters.

[0133] In some embodiments, the interface automation testing device further includes:

[0134] The generation module is used for generating a custom assertion based on the response characteristics when the response characteristics do not meet the rules of the global assertion, so as to make the response characteristics meet the rules of the custom assertion.

[0135] The interface automation test device in the embodiment of the present application can be an electronic device, or a component in an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal, or other devices other than a terminal. Exemplary, the electronic device can be a mobile phone, a tablet computer, a laptop computer, a palmtop computer, a vehicle-mounted electronic device, a mobile Internet device (Mobile Internet Device, MID), augmented reality (augmented reality, AR) / virtual reality (virtual reality, VR) equipment, a robot, a wearable device, a super mobile personal computer (ultra-mobile personal computer, UMPC), a netbook or a personal digital assistant (personal digital assistant, PDA), etc., and can also be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (personal computer, PC), a television (television, TV), a teller machine or a self-service machine, etc., and the embodiment of the present application is not specifically limited.

[0136] The interface automation test device in the embodiment of the present application can be a device having an operating system. The operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0137] In some embodiments, as shown in Figure 5, an embodiment of the present application also provides an electronic device 500, including a processor 501, a memory 502, and a computer program stored on the memory 502 and capable of running on the processor 501. When the program is executed by the processor 501, each process of the above-mentioned interface automation testing method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0138] It should be noted that the electronic devices in the embodiments of the present application include the above-mentioned mobile electronic devices and non-mobile electronic devices.

[0139] An embodiment of the present application also provides a non-transitory computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the various processes of the above-mentioned interface automation testing method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0140] The processor is the processor in the electronic device in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0141] An embodiment of the present application also provides a computer program product, including a computer program, which implements the above-mentioned interface automation testing method when executed by a processor.

[0142] The processor is the processor in the electronic device in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0143] An embodiment of the present application further provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned interface automation testing method embodiment and achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0144] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0145] It should be noted that, in this article, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In addition, it should be noted that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in the opposite order according to the functions involved. For example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0146] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0147] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this application.

[0148] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0149] Although the embodiments of the present application have been shown and described, those skilled in the art will appreciate that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and intent of the present application, and that the scope of the present application is defined by the claims and their equivalents.

Claims

1. An interface automation testing method, characterized in that: include: Run the automated test case to test the interface to be tested and obtain the response result returned by the interface to be tested; Intercepting the request header in the interface request generated by running the automated test case; In the case where the request header contains a target request parameter, a custom assertion for the interface to be tested is called to verify the response result to obtain a test result of the interface to be tested; wherein the target request parameter indicates ignoring a general global assertion.

2. The method according to claim 1, characterized in that The step of running the automated test case to test the interface to be tested and obtaining a response result returned by the interface to be tested includes: Run automated use cases to generate interface requests; The interface request is sent to the interface to be tested, and a response result returned by the interface to be tested based on the interface request is obtained.

3. The method according to claim 1, characterized in that When the request header contains the target request parameter, calling the custom assertion for the interface to be tested to verify the response result and obtaining the test result of the interface to be tested includes: In the case where the request header contains the target request parameter, the response result is set to pass the global assertion verification, and the custom assertion for the interface to be tested is called to verify the response result to obtain the test result of the interface to be tested.

4. The method according to claim 1, wherein The method further comprises: In the case that the request header does not include the target request parameter, the response result is verified against the global assertion to obtain the test result of the interface to be tested.

5. The method according to claim 1, wherein Before running the automated test case to test the interface to be tested, the method further includes: Acquire the response characteristics of the interface to be tested; the response characteristics represent the characteristics of the response results made by the interface to be tested to different interface requests; In the case that the response characteristic does not conform to the rule of the global assertion, the target request parameter is added to the automated test case so that the request header of the interface request generated by running the automated test case includes the target request parameter.

6. The method according to claim 5, characterized in that The method further comprises: In a case where the response characteristic does not conform to the rule of the global assertion, the custom assertion is generated based on the response characteristic to make the response characteristic conform to the rule of the custom assertion.

7. An interface automation testing device, characterized in that: include: The running module is used to run the automated test case to test the interface to be tested and obtain the response result returned by the interface to be tested; An interception module, used to intercept the request header in the interface request generated by running the automated test case; The verification module is used to call the custom assertion for the interface to be tested to verify the response result when the request header contains the target request parameter, so as to obtain the test result of the interface to be tested; wherein, the target request parameter indicates ignoring the general global assertion.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images