Interface testing method and device based on cloud platform and nonvolatile storage medium

Abstract

The invention discloses an interface testing method and device based on a cloud platform and a nonvolatile storage medium. The method comprises the steps of obtaining target interface test case data used for target interface test from interface test equipment of a cloud platform; sending a first request message to a server based on a target interface corresponding to the target interface test case data, the first request message being used for indicating an operation type executed by the server; receiving a first response message corresponding to the first request message, and extracting verification information used for verifying an interface test result in the first response message; and verifying the verification information, and determining that the interface corresponding to the interface test case data passes the test under the condition that the verification is passed. The technical problems that a traditional interface testing method generally depends on manual operation, and is low in testing efficiency, difficult to use and unstable are solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device and non-volatile storage medium for interface testing based on a cloud platform. Background Art

[0002] In today's rapidly developing software industry, ensuring the stability and functional integrity of software interfaces is an important part of software quality assurance. Interface testing has become an indispensable part of the software testing process. However, existing cloud-based interface testing methods and technologies have many limitations, which restrict testing efficiency, flexibility, maintainability, and adaptability.

[0003] First, for traditional interface testing methods, such as manual testing interfaces, although intuitive and adaptable, they are time-consuming and rely on manual operations of testers, which is prone to human errors. In addition, when faced with frequent changes in requirements, the workload of manually modifying test cases is huge and inefficient. Secondly, the method of writing test scripts, although it improves the degree of automation to a certain extent, requires high programming skills of testers, and the scripts are tightly coupled with test cases. Once the interface changes, the maintenance and update of the scripts will become complicated and time-consuming, and the testing efficiency is low.

[0004] In summary, traditional cloud platform-based interface testing methods usually rely more on manual operations, and have problems such as low efficiency, difficulty in use, and instability when performing interface testing.

[0005] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0006] The embodiments of the present application provide a method, device and non-volatile storage medium for interface testing based on a cloud platform, so as to at least solve the technical problems that traditional interface testing methods usually rely more on manual operation, are inefficient, difficult to use and unstable during testing.

[0007] According to one aspect of an embodiment of the present application, a cloud platform-based interface testing method is provided, including: obtaining target interface test case data for target interface testing from an interface testing device of the cloud platform; sending a first request message to a server based on a target interface corresponding to the target interface test case data, wherein the first request message is used to indicate the type of operation performed by the server; receiving a first response message corresponding to the first request message, and extracting verification information in the first response message for verifying the interface test result; verifying the verification information, and if the verification passes, determining that the interface corresponding to the interface test case data passes the test.

[0008] According to some embodiments of the present application, before obtaining target interface test case data for target interface testing, the method also includes: constructing test scenarios for all interfaces to be tested, wherein the test scenarios are determined based on the functions of the interfaces and preset test results, and the test scenarios are used to perform interface testing on the interfaces to be tested from multiple dimensions; constructing test case data for each test scenario, the test case data including at least: request method type, request parameters, preset test results, and access address information of the target interface, wherein the preset test results are test result standards determined based on the functions of the target interface, and are used to verify the verification information, and the request parameters are used to obtain the verification information in the first response message; storing all test scenarios and all test case data in a configuration file in YAML format, wherein the configuration file is used to manage all test case data participating in the interface test.

[0009] According to some embodiments of the present application, target interface test case data for target interface testing is obtained, including: obtaining target interface test case data for target interface testing from the memory of an interface testing device of a cloud platform; the target interface test case data is stored in the memory in the following manner: determining a target interface among the interfaces to be tested and a target test scenario corresponding to the target interface, wherein the target interface is any one of the interfaces to be tested; obtaining first test case data from a configuration file based on the target interface and the target test scenario corresponding to the target interface; using a first tool class to convert the data format of the first test case data to obtain target interface test case data, and storing the target interface test case data in the memory.

[0010] According to some embodiments of the present application, the request parameters of the test case data include parameter generation rules, and the request parameters are obtained in the following manner: obtaining the parameter generation rules, wherein the parameter generation rules include at least: data type, data range, and data format; calling the data generation function in the second tool class to generate test data based on the parameter generation rules, wherein the data generation function runs on the computing node of the cloud platform to generate a multidimensional data combination that conforms to the parameter generation rules as test data; and using the test data as request parameters.

[0011] According to some embodiments of the present application, a first request message is sent to a server based on a target interface corresponding to target interface test case data, including: constructing a first request message based on a request method type, request parameters, and access address information of the target interface in the target interface test case data, wherein the first request message includes at least: a request method type, access address information of the target interface, and request parameters; and sending the first request message to the server based on the access address information of the target interface in the first request message.

[0012] According to some embodiments of the present application, the verification information is verified, and when the verification passes, it is determined that the interface test corresponding to the interface test case data has passed, including: determining the target interface test case data corresponding to the first response message; obtaining the preset test results of the target interface test case data; when the verification information matches the preset test results, determining that the verification information has passed the verification, and when the verification information passes the verification, determining that the interface corresponding to the interface test case data has passed the test.

[0013] According to some embodiments of the present application, the method also includes: obtaining a test report in the following manner: determining the type of the test report; obtaining the test report based on the type of the test report obtained, wherein the type of the test report includes at least one of the following: interface test case data of a single or multiple verification information passing verification, interface test case data of a single or multiple verification information failing verification, and verification pass rate of a single or multiple target interfaces.

[0014] According to some embodiments of the present application, the method also includes: based on the execution mechanism, obtaining the test priority of the target interface test case, and testing the target interface test case in order from high to low test priority; the execution mechanism is determined in the following manner: obtaining historical interface test data; when the number of times the target interface test case fails verification in the historical interface test data is greater than a preset failure threshold, determining the test priority of the target interface test case as the first priority; when the number of times the target interface test case passes verification in the historical interface test data is greater than a preset success threshold, determining the test priority of the target interface test as the second priority, wherein the first priority is higher than the second priority.

[0015] According to another aspect of an embodiment of the present application, an interface testing device is also provided, including: an acquisition module for acquiring target interface test case data for target interface testing; a sending module for sending a first request message to a server based on a target interface corresponding to the target interface test case data, wherein the first request message is used to indicate the type of operation performed by the server; an extraction module for receiving a first response message corresponding to the first request message, and extracting verification information in the first response message for verifying the interface test result; a verification module for verifying the verification information, and if the verification passes, determining that the interface corresponding to the interface test case data has passed the test.

[0016] According to another aspect of an embodiment of the present application, a non-volatile storage medium is further provided, in which a program is stored, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the above-mentioned cloud platform-based interface testing method.

[0017] According to another aspect of an embodiment of the present application, an electronic device is also provided, including: a memory and a processor, the processor being used to run a program stored in the memory, wherein the above-mentioned cloud platform-based interface testing method is executed when the program is running.

[0018] According to another aspect of an embodiment of the present application, a computer program product is also provided, including computer instructions, which implement the above-mentioned cloud platform-based interface testing method when executed by a processor.

[0019] In an embodiment of the present application, the target interface test case data for the target interface test is obtained from the interface test device of the cloud platform; the first request message is sent to the server based on the target interface corresponding to the target interface test case data, wherein the first request message is used to indicate the type of operation performed by the server; the first response message corresponding to the first request message is received, and the verification information for verifying the interface test result in the first response message is extracted; the verification information is verified, and when the verification passes, the interface corresponding to the interface test case data is determined to pass the test. By obtaining the target interface test case data, the first request message is generated and sent to the server, so that the purpose of manually inputting request parameters or constructing requests is achieved without manual operation, and the test efficiency is greatly improved. After the server returns the first response message, the verification information is verified, and the verification information is automatically extracted for verification, and the purpose of manually checking the response content one by one is achieved, and the automation and execution speed of the test are further improved. Thus, the traditional interface testing method is usually more dependent on manual operation, and the problems of low efficiency, difficulty in use, and unstable technology when testing are solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0021] Figure 1 It is a hardware structure block diagram of a computer terminal for implementing an interface testing method based on a cloud platform according to an embodiment of the present application;

[0022] Figure 2 It is a flowchart of a cloud platform-based interface testing method provided according to an embodiment of the present application;

[0023] Figure 3 It is a system structure diagram of a cloud platform-based interface testing method provided according to an embodiment of the present application;

[0024] Figure 4 It is a structural diagram of a cloud platform-based interface testing device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0026] The information collected in the embodiments of the present application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or reject automated decision-making results; if the user chooses to reject, the expert decision-making process will be entered.

[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0028] In order to better understand the embodiments of the present application, the technical terms involved in the embodiments of the present application are explained as follows:

[0029] Python is a high-level, interpreted, and versatile programming language suitable for a variety of software development tasks, including automated testing. Its features include concise and easy-to-read syntax, powerful third-party library support, and extensive community support.

[0030] Pytest is a full-featured testing framework based on Python that supports multiple test types, including functional testing, unit testing, and interface testing. It provides a wealth of plug-ins and extensions to make test code writing and execution easier and more flexible.

[0031] In the related art, the traditional interface testing method, for example, the manual test interface, although intuitive and adaptable, is time-consuming and depends on the manual operation of the tester, which is easy to introduce human errors, and when faced with the needs of frequent changes, the workload of manually modifying the test case is huge and inefficient. Secondly, the method of writing test scripts, although it improves the degree of automation to a certain extent, has high requirements on the programming skills of the tester, and the script is tightly coupled with the test case. Once the interface changes, the maintenance and update of the script will become complicated and time-consuming, and the test efficiency is low. Therefore, there is a traditional interface testing method based on a cloud platform, which is usually more dependent on manual operation, and there are problems of low efficiency, difficulty in use, and instability when performing interface testing. In order to solve this problem, a relevant solution is provided in the embodiment of the present application.

[0032] According to an embodiment of the present application, a method embodiment of a cloud platform-based interface testing method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0033] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal for implementing the interface testing method based on a cloud platform is shown. Figure 1 As shown, the computer terminal 10 may include one or more (102a, 102b, ..., 102n are used to illustrate) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0034] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10. As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0035] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the interface testing method based on the cloud platform in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, realizing the above-mentioned interface testing method based on the cloud platform. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0036] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0037] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 .

[0038] In the above operating environment, the present application embodiment provides a flow chart of an interface testing method based on a cloud platform, such as Figure 2 As shown, the method comprises the following steps:

[0039] Step S202: acquiring target interface test case data for target interface testing from the interface testing device of the cloud platform.

[0040] In the technical solution provided in step S202, before obtaining the target interface test case data for the target interface test, it is also necessary to construct test case data for all interfaces to be tested. There are many ways to construct test case data for all interfaces to be tested, for example: construct a test scenario for all interfaces to be tested, wherein the test scenario is determined based on the function of the interface and the preset test result, and the test scenario is used to perform interface testing on the interface to be tested from multiple dimensions; construct test case data for each test scenario, and the test case data at least includes: request method type, request parameters, preset test results, and access address information of the target interface, wherein the preset test result is a test result standard determined based on the function of the target interface, which is used to verify the verification information, and the request parameter is used to obtain the verification information in the first response message; all test scenarios and all test case data are in YAML format ((YAML Ain't Markup YAML (Java Scripting Language) is a human-readable data serialization format that is very suitable for configuration files and data exchange. In the interface automation testing framework, YAML files are used to store relevant information of interface test cases, such as interface uniform resource locators (URLs), request methods, request parameters, expected results, etc. ) are stored in configuration files, where the configuration files are used to manage all test case data involved in interface testing. This method can not only fully cover the functional testing of the interface, but also quickly determine the correctness of the interface through preset test results. It is particularly suitable for software projects that require frequent updates and maintenance, and can effectively reduce testing costs and improve the comprehensiveness and accuracy of testing. Using configuration files in YAML format, the data of interface test cases can be clearly managed, including request URLs, request methods, request parameters, expected results, etc. This format is easy to understand and edit, and is flexible enough to quickly adjust and expand test cases to adapt to project changes or the needs of new features.

[0041] There are many ways to obtain target interface test case data for target interface testing, for example: obtain target interface test case data for target interface testing from the memory of the interface testing device of the cloud platform; the target interface test case data is stored in the memory in the following ways: determine the target interface in the interface to be tested and the target test scenario corresponding to the target interface, wherein the target interface is any one of the interfaces to be tested; obtain the first test case data from the configuration file based on the target interface and the target test scenario corresponding to the target interface; use the first tool class to convert the data format of the first test case data to obtain the target interface test case data, and store the target interface test case data in the memory. Storing test case data in memory can improve the data reading speed and speed up the test process, especially in a high-concurrency test environment, which can significantly improve the test efficiency and reduce waiting time.

[0042] It should be noted that the test case can dynamically generate request parameters when it is executed without any manual operation, thereby increasing the randomness and coverage of the test. Therefore, in the above steps, the request parameters of the test case data include parameter generation rules, and the request parameters are obtained in the following ways: obtaining parameter generation rules, wherein the parameter generation rules at least include: data type, data range, and data format; calling the data generation function in the second tool class to generate test data based on the parameter generation rules, wherein the data generation function runs on the computing node of the cloud platform to generate a multidimensional data combination that conforms to the parameter generation rules as test data; using the test data as the request parameter. The cloud platform provides elastic computing resources and can dynamically expand computing nodes under high load, which means that the data generation function can automatically allocate more processing power according to the test requirements, especially when a large amount of test data needs to be generated or complex data generation rules need to be executed. The computing power of the cloud platform can ensure the efficiency and timeliness of data generation. And the cloud platform supports parallel computing, and can run data generation functions on multiple computing nodes at the same time to generate different test data sets. This greatly improves the speed of data generation, especially in large-scale interface testing scenarios, and can quickly generate test data covering multiple dimensions, improving the comprehensiveness and efficiency of the test. This method of dynamically generating test parameters can effectively cover various possible input situations, improve the comprehensiveness and depth of the test, and is particularly suitable for testing complex interfaces, and can discover more potential interface problems.

[0043] For example, the following is a specific embodiment:

[0044] First, design multiple test scenarios based on the documentation and functional description of the interface to be tested. Each test scenario should cover a key function of the interface, taking into account normal operation, boundary conditions, and abnormal situations. For each test scenario, write specific test case data. Define the test case data in YAML format, including the request method type, request parameters, preset test results, and access address information of the target interface and store them in the configuration file. The request parameters include parameter generation rules, which include at least: data type, data range, and data format. For example, the data type can be a string, integer, etc.; the data range can be the minimum and maximum value of the value; the data format can be a date format, an email format, etc. These rules ensure that the generated data meets specific test requirements. Using the cloud platform-based test framework in this application (for example, a yaml_util tool class in a Pytest test framework (the above-mentioned first tool class, a tool class for processing YAML format files, used to load, parse, and generate YAML files, and realize unified management of test data and configuration information.) When reading test case data, automatically identify parameters marked as dynamically generated, and extract their corresponding parameter generation rules (such as data type, data range, data format, etc.) to prepare for subsequent data generation. This action ensures that the framework can understand and handle the needs of dynamic data generation. The framework can call the data generation function (located in the model_util tool class (used to define tool classes or data structures related to business models, with For managing test cases, test data, etc.) or in the yaml_util tool class (i.e., the second tool class mentioned above), for example, the data generation function may include: a function for generating a random username that complies with the naming rules, a function for generating a random password of a specified length, which is required to contain uppercase and lowercase letters and numbers, etc.), taking the test case data as input, and generating test data that meets the requirements according to the rules extracted from the YAML configuration file. The generated data is then filled into the request parameters of the test case as request parameters for sending an HTTP request (i.e., the first request mentioned above). This action is the core of dynamic data generation, which realizes the automatic filling of data and ensures that the test case can cover a wider range of data combinations. The above request parameters can contain a variety of different value combinations.

[0045] A test scenario is a series of test steps and conditions designed based on the functions of the interface (target interface) and preset test results to simulate various usage scenarios and boundary conditions to ensure that the interface works as expected in various possible input and usage environments. The request method type refers to the type of operation requested to be completed by the server, which determines the interaction mode and data transmission mode of the interface (for example, the specific type of HTTP or HTTPS request, such as GET (used to obtain data from the server), POST (used to send data to the server), PUT (used to update resources on the server), DELETE (used to delete resources on the server), etc.). Request parameters refer to the test data passed to the server for testing when the interface is called, which is used to specify the specific content and context of the interface operation. The preset test results are test result standards set based on the functions and expected behaviors of the interface (target interface), which are used to determine whether the actual response meets expectations, including but not limited to the response status code, response time, structure and content of the response data, etc. The access address information of the target interface is the uniform resource locator (URL) and port information of the interface, which determines the specific location of the interface and is necessary information for sending a test request (the first request mentioned above). After the server receives the first request, it first determines the interaction mode and data transmission mode of the interface based on the request method type in the first request, then obtains the request parameters for interface testing and generates a first response message.

[0046] Assume there is a login interface whose function is to authenticate the user through username and password. The constructed test scenario may include the following:

[0047] Test scenario 1: Normal login scenario: The username and password are correct, and the expected result is to return user information and a successful status code. Test case data 1: Request method type: POST, request parameters: name: user1, password: 111, preset test result: login successful, target interface access address information: xxxx1.

[0048] Test scenario 2: Password error scenario: Password error, the expected result is to return error information and error status code. Test case data 1: Request method type: POST, request parameters: Name: user2, Password: 112, preset test results: Login failed, password error, target interface access address information: xxxx1.

[0049] Test scenario 3: Username does not exist Scenario: Username does not exist, the expected result is to return an error message and error status code. Test case data 1: Request method type: POST, request parameters: Name: user3, Password: 112, preset test result: Login failed, username does not exist, target interface access address information: xxxx1.

[0050] Load and parse the YAML configuration file (i.e. the above configuration file), and load the test case data into memory in the form of a dictionary or object. YamlUtil is a class or method in the yaml_util tool class, which encapsulates the logic of reading and parsing YAML files. Use the yaml.safe_load function (used to safely parse a string or file in YAML format into a Python data structure.) Call the loading method of YamlUtil and pass in the path of the YAML file. The yaml.safe_load function will parse the contents of the YAML configuration file into a Python data type such as a dictionary or list. Since test case data is usually organized in the form of dictionaries, each dictionary represents a test case. Therefore, the parsed result is usually a list of dictionaries, each of which contains detailed information about the test case, such as the request URL, request method, request parameters, and expected response results. Then, the parsed test case data dictionary list will be loaded into memory and stored in an easily accessible data structure, such as a global variable or class attribute. In this way, the subsequent test execution process can read and operate the test case data directly from the memory without reading and parsing the configuration file again, which improves the efficiency of test execution.

[0051] Step S204: Send a first request message to the server based on the target interface corresponding to the target interface test case data, wherein the first request message is used to indicate the type of operation performed by the server.

[0052] In the technical solution provided in step S204, there are multiple ways to send a first request message to a server based on the target interface corresponding to the target interface test case data, for example: construct a first request message based on the request method type, request parameters, and access address information of the target interface in the target interface test case data, wherein the first request message includes at least: request method type, access address information of the target interface, and request parameters; send the first request message to the server based on the access address information of the target interface in the first request message. Through a standardized request construction process, it can be ensured that the request message format of each test is correct, avoiding test failures due to incorrect request formats, and is suitable for interface testing in various network environments, improving the stability and reliability of the test.

[0053] For example, the following is a specific embodiment:

[0054] Read and parse the test case data of the target interface from the YAML configuration file, obtain the request method type (such as GET, POST), request parameters, and the access address information of the target interface (for example, URL); construct a request message (i.e., the first request message) according to the request method type. For example, for a POST request, the request parameters need to be serialized into JSON format as part of the request body. Use the requests_util tool class (a tool class used to encapsulate HTTP requests, including functions such as sending requests, processing responses, and handling exceptions) to send the constructed request message to the server specified by the access address information of the target interface. When sending a request, considering the uncertainty of the network environment, you can also set a timeout. For example, if there is no response in 50 seconds, the request is considered to have failed to avoid test stagnation caused by waiting for a long time for a response. Exception handling is also performed and detailed exception information is recorded, including the requested URL, request parameters, the type and description of the exception, to ensure the robustness of the test process and the accuracy of the test results.

[0055] Step S206, receiving the first response message corresponding to the first request message, and extracting the verification information in the first response message for verifying the interface test result. For example, use the extract_util tool class (a tool class for extracting specific information from the interface response, supporting the extraction of fields or values ​​from responses in JSON or XML format.) Extract verification information from the first response message, the verification information refers to the data points or key information extracted from the first response message returned by the server for asserting and verifying the test results, including but not limited to the response status code, response time, and specific field values ​​in the response body, extracting the fields dynamically generated in the first response message, etc. For example, the verification threshold of the response time can be dynamically adjusted based on historical test data to ensure that the judgment of the verification information is still accurate and effective under different network conditions and server loads. For example, the range of normal response time is predicted by a machine learning algorithm, and this range is used as the response time threshold in the verification information.

[0056] Step S208, verifying the verification information, and if the verification passes, determining that the interface corresponding to the interface test case data passes the test.

[0057] In the technical solution provided in step S208, the verification information is verified, and when the verification passes, determining that the interface test corresponding to the interface test case data passes can be achieved in the following manner: determining the target interface test case data corresponding to the first response message; obtaining the preset test result of the target interface test case data; when the verification information matches the preset test result, determining that the verification information passes the verification, and when the verification information passes the verification, determining that the interface corresponding to the interface test case data passes the test. This verification method based on preset test results can quickly and accurately determine the correctness of the interface, and is particularly suitable for scenarios that require rapid feedback of test results, such as continuous integration testing, and can promptly discover and fix interface problems, thereby improving software development efficiency.

[0058] For example, the following is a specific embodiment:

[0059] The assert_util tool class (used to encapsulate assertion functions (i.e., the above-mentioned verification of verification information) of the test framework based on the cloud platform of the present application, including connecting to the database, executing SQL statements, and asserting and verifying the interface response) receives the first response message of the server, and determines the target interface test case data corresponding to the first response message from the test case data dictionary loaded in the configuration file by a unique identifier (such as a test case ID) or the test case index currently in progress. This step is to ensure that the response information can be accurately associated with the correct test case data. In the target interface test case data, the preset test result is predefined and is used to determine whether the actual response meets the expected content. These preset test results may include, but are not limited to, response status code, response time, specific field values ​​in the response body, etc. Using the verification method in the assert_util tool class, the verification information extracted from the first response message is compared with the preset test result. The verification method may include simple equivalence checks, regular expression matching, complex data structure comparisons, etc., depending on the type of preset test results and test requirements. If the verification information completely matches the preset test result, it is determined that the test case passes.

[0060] After completing step S208, the test report can also be obtained in the following ways: determine the type of the test report; obtain the test report according to the type of the test report obtained, wherein the type of the test report includes at least one of the following: interface test case data with single or multiple verification information passed, interface test case data with single or multiple verification information not passed, and verification pass rate of single or multiple target interfaces. The generation of the test report can intuitively display the test results, making it easier for testers and developers to quickly understand the test status of the interface. It is particularly suitable for projects that require regular interface testing, and can effectively monitor the stability and performance of the interface, providing data support for the continuous optimization of the software.

[0061] The following is a specific embodiment:

[0062] The test framework of this application based on the cloud platform needs to determine which type of test report will be generated. This is usually configured by the tester or developer before the test starts, which can be a use case report of the test, a use case report of the failed test, a verification pass rate report of the interface, or a combination thereof. During the test execution process, the main_util tool class (the main tool class of the framework, used to manage the entire test process, including starting the test, generating reports, managing test cases, etc.) or the relevant test execution management tool class needs to collect the execution results of all test cases. The execution results include recording the status (pass or fail) of each test case, response time, specific verification information and other detailed data, and the test situation of each interface. According to the type of test report, the test report is generated using the corresponding report generation method. For example, the verification pass rate report of the interface, the report will count and display the test pass rate of each target interface, that is, the proportion of the test case data passed by the test to the total test case data, and indicators such as the average response time. The generated test report can be output in a variety of ways, such as saving it as an HTML file, PDF file or printing it directly on the console. In addition, the logger can provide detailed test execution logs, including the execution status, response time and returned data content of each test case. Before and after the execution of each test case, logs are recorded, including key information such as the start of execution, execution status, response time, and returned data content.

[0063] In order to avoid the waste of resources caused by repeated testing, adapt to different testing needs and scenarios, and provide more personalized and intelligent testing services, the test priority of the target interface test case can also be obtained based on the execution mechanism, and the target interface test case can be tested in order of test priority from high to low; for example, the execution mechanism is determined in the following ways: obtaining historical interface test data; when the number of times the target interface test case fails to pass the verification in the historical interface test data is greater than the preset failure threshold, the test priority of the target interface test case is determined as the first priority; when the number of times the target interface test case passes the verification in the historical interface test data is greater than the preset success threshold, the test priority of the target interface test is determined as the second priority, where the first priority is higher than the second priority. By dynamically adjusting the test priority, the test process can be optimized to ensure the stability and reliability of key interfaces. It is particularly suitable for scenarios where a large number of interface tests need to be completed within a limited time, such as comprehensive testing before the release of a software version. It can effectively improve the test efficiency, give priority to high-risk interfaces, and reduce the failure rate after the software is launched.

[0064] The following is a specific embodiment:

[0065] Obtain historical interface test data: First, the cloud platform-based testing framework of this application needs to access historical interface test result data. This data is usually stored in a test database or configuration file, recording the results of multiple past executions of each interface test case, for example, including the number of passes, the number of failures, the average response time, etc.

[0066] Determine test priority: Analyze historical interface test data and determine the test priority of each target interface test case. Specifically, if the number of failures of a certain test case data in the historical interface test data exceeds the preset failure threshold (e.g., 90%), set its test priority to the first priority (high priority). On the contrary, if the number of successes of the test case data in the historical interface test data exceeds the preset success threshold (e.g., 90%), set its priority to the second priority (low priority). The first priority is higher than the second priority, ensuring that high-risk test case data can perform interface testing first. This ensures that key interface test cases that often fail in historical records are executed and diagnosed first, effectively improving test efficiency.

[0067] In the embodiment of the present application, the test framework can use the cloud storage service to load and store test case data and test results, use the computing resources of the cloud platform to dynamically execute tests, and send and receive test requests and responses through the network services of the cloud platform. Interface testing based on the cloud platform can give full play to the elasticity and flexibility of cloud computing, which not only improves the efficiency and comprehensiveness of testing, but also reduces testing costs, providing strong support for software development. This testing method is particularly suitable for applications that require frequent testing, process large-scale data, or support global users, and is an indispensable part of the modern software testing process.

[0068] Through the above steps S202-S208, by automatically executing test cases and generating test reports, the efficiency of testing is greatly improved, and human resources and time costs are saved. This can solve the problem of low efficiency of traditional manual testing and script testing methods. The YAML configuration file is used to manage test cases and test data, making the maintenance and management of test cases simpler and more flexible; through flexible configuration files and the function of automatically generating test cases, more test scenarios and boundary conditions can be covered, and the comprehensiveness and accuracy of the test are improved. The test framework (for example, a Pytest test framework, which supports parallel test execution, rich assertion libraries and other functions, can significantly improve the writing efficiency and execution efficiency of test codes. It can automatically generate a detailed test report, including an overall overview of test execution, pass rate, detailed information of failed cases, execution time statistics, etc. This automatic report generation function makes the test result display more intuitive and readable, which helps the test team to quickly locate and solve problems) adopts multiple tool classes, such as assert_util, extract_util, etc., each of which focuses on a specific functional area, such as assertion verification, data extraction, etc. This modular design makes the framework structure clear and easy to maintain and expand. The team can add new tool classes or expand existing functionality as needed without affecting the stability of the overall framework.

[0069] By automatically constructing test scenarios and test case data, the automation and intelligence of interface testing is realized, which greatly improves the efficiency and accuracy of interface testing. Especially when dealing with a large number of interface tests, unified management of test case data through configuration files can avoid duplication of work and reduce human errors. At the same time, by dynamically adjusting the test priority, it is possible to more effectively identify and locate the problem interface, optimize the test process, ensure the stability and reliability of key interfaces, and provide strong support for software development and maintenance. In addition, this method and device can also adapt to different testing requirements, such as functional testing, performance testing, security testing, etc., which provides the possibility for the overall improvement of software quality. It is particularly suitable for complex software systems that require multi-dimensional testing, and can effectively improve the overall quality of the software and user experience.

[0070] The present application also provides a schematic diagram of a system structure of an interface testing method based on a cloud platform. Figure 3 As shown, through the test case management module:

[0071] Load the yaml configuration file, determine the file format, read the test case data, store the test case data, and provide the test case; then, through the interface execution module: send an HTTP request and obtain an interface response; through the data extraction module: extract data from the response and return the extracted data; finally, through the assertion module: assert the response data and return the assertion result (i.e., the above-mentioned verification of the verification information); through the test result output module: output the test result. The specific implementation method has been described in the above embodiments and will not be repeated here.

[0072] The present application embodiment provides an interface testing device, such as Figure 4 As shown, including:

[0073] The acquisition module 402 is used to acquire target interface test case data for target interface testing from the interface testing device of the cloud platform.

[0074] The acquisition module 402 is also used to determine the target interface in the interface to be tested and the target test scenario corresponding to the target interface, wherein the target interface is any one of the interfaces to be tested; obtain the first test case data from the configuration file based on the target interface and the target test scenario corresponding to the target interface; use the first tool class to convert the data format of the first test case data to obtain the target interface test case data, and store the target interface test case data in the memory.

[0075] The sending module 404 is used to send a first request message to the server based on the target interface corresponding to the target interface test case data, wherein the first request message is used to indicate the type of operation performed by the server.

[0076] The sending module 404 is also used to construct a first request message based on the request method type, request parameters, and access address information of the target interface in the target interface test case data, wherein the first request message includes at least: the request method type, the access address information of the target interface, and request parameters; and send the first request message to the server based on the access address information of the target interface in the first request message.

[0077] The extraction module 406 is used to receive a first response message corresponding to the first request message, and extract verification information in the first response message for verifying the interface test result.

[0078] The verification module 408 is used to verify the verification information, and if the verification passes, determine that the interface corresponding to the interface test case data passes the test.

[0079] The verification module 408 is also used to determine the target interface test case data corresponding to the first response message; obtain the preset test results of the target interface test case data; when the verification information matches the preset test results, determine that the verification information passes the verification, and when the verification information passes the verification, determine that the interface corresponding to the interface test case data passes the test.

[0080] It should be noted that the various modules in the above-mentioned interface testing device can be program modules (for example, a set of program instructions that implement a certain specific function) or hardware modules. For the latter, it can be expressed in the following forms, but is not limited to this: the expression form of each of the above-mentioned modules is a processor, or the functions of each of the above-mentioned modules are implemented by a processor.

[0081] The embodiment of the present application also provides a non-volatile storage medium, the non-volatile storage medium includes a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the above-mentioned cloud platform-based interface testing method. For example, from the interface testing device of the cloud platform, the target interface test case data for the target interface test is obtained; based on the target interface corresponding to the target interface test case data, a first request message is sent to the server, wherein the first request message is used to indicate the type of operation performed by the server; a first response message corresponding to the first request message is received, and verification information used to verify the interface test result is extracted from the first response message; the verification information is verified, and if the verification passes, it is determined that the interface corresponding to the interface test case data has passed the test.

[0082] The embodiment of the present application also provides an electronic device, the electronic device includes a processor, the processor is used to run a program, wherein the above-mentioned cloud platform-based interface testing method is executed when the program is running. For example, from the interface testing device of the cloud platform, the target interface test case data for the target interface test is obtained; based on the target interface corresponding to the target interface test case data, a first request message is sent to the server, wherein the first request message is used to indicate the type of operation performed by the server; a first response message corresponding to the first request message is received, and verification information for verifying the interface test result is extracted from the first response message; the verification information is verified, and if the verification passes, it is determined that the interface corresponding to the interface test case data has passed the test.

[0083] According to another aspect of the embodiment of the present application, a computer program product is also provided, including a computer program, which implements the above-mentioned cloud platform-based interface testing method when executed by a processor. For example, from the interface testing device of the cloud platform, target interface test case data for target interface testing is obtained; a first request message is sent to a server based on the target interface corresponding to the target interface test case data, wherein the first request message is used to indicate the type of operation performed by the server; a first response message corresponding to the first request message is received, and verification information for verifying the interface test result is extracted from the first response message; the verification information is verified, and if the verification passes, it is determined that the interface corresponding to the interface test case data passes the test.

[0084] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0085] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

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

[0088] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology or all or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk, etc. Various media that can store program codes.

[0089] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A cloud platform-based interface testing method, characterized in that: include: Obtain target interface test case data for target interface testing from the interface test device of the cloud platform; Sending a first request message to a server based on a target interface corresponding to the target interface test case data, wherein the first request message is used to indicate a type of operation performed by the server; Receiving a first response message corresponding to the first request message, and extracting verification information in the first response message for verifying the interface test result; The verification information is verified, and if the verification passes, it is determined that the interface corresponding to the interface test case data passes the test.

2. The method according to claim 1, characterized in that Before acquiring the target interface test case data for the target interface test, the method further includes: For all interfaces to be tested, a test scenario is constructed, wherein the test scenario is determined based on the function of the interface and a preset test result, and the test scenario is used to perform interface testing on the interfaces to be tested from multiple dimensions; Constructing test case data for each of the test scenarios, the test case data including at least: request method type, request parameters, preset test results, and access address information of the target interface, wherein the preset test results are test result standards determined based on the function of the target interface and are used to verify the verification information, and the request parameters are used to obtain the verification information in the first response message; All the test scenarios and all the test case data are stored in a configuration file in YAML format, wherein the configuration file is used to manage all the test case data involved in the interface test.

3. The method according to claim 2, characterized in that Obtain target interface test case data for target interface testing, including: Acquire the target interface test case data for target interface testing from the memory of the interface test device of the cloud platform; The target interface test case data is stored in the memory in the following manner: Determine a target interface among the interfaces to be tested and a target test scenario corresponding to the target interface, wherein the target interface is any one of the interfaces to be tested; Acquire first test case data from the configuration file based on the target interface and a target test scenario corresponding to the target interface; Use a first tool class to convert the data format of the first test case data to obtain the target interface test case data, and store the target interface test case data in a memory.

4. The method according to claim 2, characterized in that: The request parameters of the test case data include parameter generation rules, and the request parameters are obtained in the following manner: Acquire the parameter generation rule, wherein the parameter generation rule at least includes: data type, data range, and data format; Calling a data generation function in the second tool class to generate test data based on the parameter generation rule, wherein the data generation function runs on a computing node of the cloud platform to generate a multidimensional data combination that conforms to the parameter generation rule as test data; The test data is used as the request parameter.

5. The method according to claim 1, characterized in that: Sending a first request message to a server based on a target interface corresponding to the target interface test case data includes: Constructing a first request message based on the request method type, request parameters, and access address information of the target interface in the target interface test case data, wherein the first request message at least includes: the request method type, the access address information of the target interface, and the request parameters; The first request message is sent to a server based on the access address information of the target interface in the first request message.

6. The method according to claim 2, characterized in that Verifying the verification information, and if the verification passes, determining that the interface test corresponding to the interface test case data passes, includes: Determine the target interface test case data corresponding to the first response message; Obtaining preset test results of the target interface test case data; In the case where the verification information matches the preset test result, it is determined that the verification information passes the verification, and in the case where the verification information passes the verification, it is determined that the interface corresponding to the interface test case data passes the test.

7. The method according to claim 1, characterized in that The method further comprises: Get the test report by: Determine the type of test report; Obtain a test report based on the type of the test report obtained, wherein the type of the test report includes at least one of the following: single or multiple interface test case data of the verification information passing the verification, single or multiple interface test case data of the verification information failing the verification, and verification pass rate of single or multiple target interfaces.

8. The method according to claim 1, characterized in that: The method further comprises: Based on the execution mechanism, the test priority of the target interface test case is obtained, and the target interface test case is tested in descending order of the test priority; The execution mechanism is determined by: Get historical interface test data; When the number of times that the target interface test case fails verification in the historical interface test data is greater than a preset failure threshold, the test priority of the target interface test case is determined as the first priority; When the target interface test case has been verified to pass a number of times in the historical interface test data that is greater than a preset success threshold, the test priority of the target interface test is determined to be a second priority, wherein the first priority is higher than the second priority.

9. An interface testing device based on a cloud platform, characterized in that: include: An acquisition module is used to acquire target interface test case data for target interface testing from an interface test device of the cloud platform; A sending module, used to send a first request message to a server based on a target interface corresponding to the target interface test case data, wherein the first request message is used to indicate a type of operation performed by the server; An extraction module, used to receive a first response message corresponding to the first request message, and extract verification information in the first response message for verifying the interface test result; The verification module is used to verify the verification information, and if the verification passes, determine that the interface corresponding to the interface test case data passes the test.

10. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the cloud platform-based interface testing method described in any one of claims 1 to 8.

11. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program, when running, executes the cloud platform-based interface testing method described in any one of claims 1 to 8.

12. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by the processor, the cloud platform-based interface testing method described in any one of claims 1 to 8 is implemented.

Images