Method, device, equipment, storage medium and program product for testing interface

Abstract

The present disclosure provides a method, device, electronic device, computer-readable storage medium and computer program product for testing an interface, and relates to the fields of artificial intelligence technology such as data processing, code testing and cloud platforms. A specific implementation of the method includes: obtaining an interface name and a code set provided by a user for the interface to be tested; based on the interface name, determining the target code associated with the interface to be tested from the code set; generating a test case for the interface to be tested according to the test parameters indicated by the target code; using the test case to test the interface to be tested, and generating an interface test result. This implementation can test the interface after generating a test case based on the code parsing result, so that the user only needs to provide the interface name of the interface to be tested and the related code set, so as to achieve the purpose of testing the interface to be tested that needs to be tested in the code set, simplifying the difficulty of the user's testing of the interface and improving the testing efficiency.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, specifically to the field of artificial intelligence technology such as data processing, code testing and cloud platforms, and especially to methods, devices, electronic devices, computer-readable storage media and computer program products for testing interfaces. Background Art

[0002] With the development of computer technology, different software applications are needed to provide support based on different user needs and to achieve different functions. On this basis, in order to ensure the availability and quality of software applications, a series of indicators such as the availability and stability of various interfaces associated with software functions need to be tested during the software development process. Interface testing can detect whether there are abnormalities in the data exchange, transmission and control management process at the interaction points between external systems and between internal subsystems, as well as the mutual logical dependencies between systems.

[0003] Usually, test cases can be used to simulate actual operating conditions and ideal operating scenarios to test the interfaces between system components. Therefore, how to perform interface testing with quality and efficiency is worthy of attention and urgent need. Summary of the invention

[0004] The embodiments of the present disclosure provide a method, an apparatus, an electronic device, a computer-readable storage medium, and a computer program product for testing an interface.

[0005] In the first aspect, an embodiment of the present disclosure proposes a method for testing an interface, including: obtaining an interface name and a code set provided by a user for the interface to be tested; based on the interface name, determining a target code associated with the interface to be tested from the code set; generating a test case for the interface to be tested according to the test parameters indicated by the target code; and testing the interface to be tested using the test case to generate an interface test result.

[0006] In the second aspect, an embodiment of the present disclosure proposes a device for testing an interface, comprising: a name and code acquisition unit, configured to acquire an interface name and a code set provided by a user for the interface to be tested; a target code determination unit, configured to determine, from the code set, the target code associated with the interface to be tested based on the interface name; a test case generation unit, configured to generate a test case for the interface to be tested according to the test parameters indicated by the target code; and a test result generation unit, configured to test the interface to be tested using the test case to generate an interface test result.

[0007] In a third aspect, an embodiment of the present disclosure provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can implement the method of testing the interface described in any implementation method in the first aspect when executing the instructions.

[0008] In a fourth aspect, an embodiment of the present disclosure provides a non-transitory computer-readable storage medium storing computer instructions, which are used to enable a computer to implement the method of testing an interface as described in any implementation manner in the first aspect when executed.

[0009] In a fifth aspect, an embodiment of the present disclosure provides a computer program product comprising a computer program, which, when executed by a processor, can implement the method for testing an interface as described in any implementation manner in the first aspect.

[0010] The method, device, electronic device, computer-readable storage medium, and computer program product for testing an interface provided by the embodiments of the present disclosure, after obtaining the interface name and code set provided by the user for the interface to be tested, determine the target code associated with the interface to be tested from the code set based on the interface name. Further, based on the test parameters indicated by the target code, generate a test case for the interface to be tested. Finally, use the test case to test the interface to be tested and generate an interface test result.

[0011] The present invention can test the interface after generating test cases based on the code analysis results, so that the user only needs to provide the interface name of the interface to be tested and the relevant code set to achieve the purpose of testing the interface to be tested in the code set, thereby simplifying the user's testing difficulty for the interface and improving testing efficiency.

[0012] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Other features, objects and advantages of the present disclosure will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0014] Figure 1 is an exemplary system architecture in which the present disclosure may be applied;

[0015] Figure 2 A flowchart of a method for testing an interface provided by an embodiment of the present disclosure;

[0016] Figure 3 A flowchart of a process for generating a test case provided by an embodiment of the present disclosure;

[0017] Figure 4 A flowchart of a method for testing an interface in an application scenario provided by an embodiment of the present disclosure;

[0018] Figure 5 A structural block diagram of a device for testing an interface provided in an embodiment of the present disclosure;

[0019] Figure 6 A schematic diagram of the structure of an electronic device suitable for executing a method for testing an interface provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0020] The following is a description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. It should be noted that the embodiments in the present disclosure and the features in the embodiments may be combined with each other without conflict.

[0021] In addition, in the technical solutions involved in this disclosure, the acquisition, storage, use, processing, transportation, provision and disclosure of user personal information (such as the interface names and codes involved in this disclosure later) are in compliance with the relevant laws and regulations and do not violate public order and good morals.

[0022] Figure 1 An exemplary system architecture 100 is shown to which embodiments of the method, apparatus, electronic device, and computer-readable storage medium of the test interface of the present disclosure may be applied.

[0023] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, 103, a network 104 and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0024] Users can use terminal devices 101, 102, 103 to interact with server 105 through network 104 to receive or send messages, etc. Various applications for realizing information communication between the terminal devices 101, 102, 103 and server 105 can be installed, such as software development applications, cloud testing applications, instant messaging applications, etc.

[0025] Terminal devices 101, 102, 103 and server 105 can be hardware or software. When terminal devices 101, 102, 103 are hardware, they can be various electronic devices with display screens, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, etc.; when terminal devices 101, 102, 103 are software, they can be installed in the electronic devices listed above, which can be implemented as multiple software or software modules, or as a single software or software module, and no specific limitation is made here. When server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server; when the server is software, it can be implemented as multiple software or software modules, or as a single software or software module, and no specific limitation is made here.

[0026] The server 105 can provide various services through various built-in applications. Taking the software development application with interface testing function as an example, the server 105 can achieve the following effects when running the software development application: first, the interface name and code set provided by the user for the interface to be tested are obtained from the terminal devices 101, 102, and 103 through the network 104; then, based on the interface name, the server 105 determines the target code associated with the interface to be tested from the code set; then, the server 105 generates a test case for the interface to be tested according to the test parameters indicated by the target code; finally, the server 105 uses the test case to test the interface to be tested and generates an interface test result.

[0027] It should be noted that the interface name and code set provided by the user for the interface to be tested can be obtained from the terminal devices 101, 102, 103 through the network 104, or can be pre-stored in the server 105 in various ways. Therefore, when the server 105 detects that these data are already stored locally (for example, when starting to process the previously reserved interface test task), it can choose to directly obtain these data locally. In this case, the exemplary system architecture 100 may also not include the terminal devices 101, 102, 103 and the network 104.

[0028] Since storing codes and analyzing codes may require more computing resources and stronger computing power, the methods for testing interfaces provided in the subsequent embodiments of the present disclosure are generally executed by the server 105 with stronger computing power and more computing resources, and accordingly, the device for testing interfaces is generally also set in the server 105. However, it should also be pointed out that when the terminal devices 101, 102, and 103 also have computing power and computing resources that meet the requirements, the terminal devices 101, 102, and 103 can also complete the above-mentioned various operations that are handed over to the server 105 through the software development applications installed thereon, and then output the same results as the server 105. Especially in the case where there are multiple terminal devices with different computing powers at the same time, but when the software development application determines that the terminal device where it is located has stronger computing power and more remaining computing resources, it can allow the terminal device to perform the above-mentioned operations, thereby appropriately reducing the computing pressure of the server 105, and accordingly, the device for testing interfaces can also be set in the terminal devices 101, 102, and 103. In this case, the exemplary system architecture 100 may also not include the server 105 and the network 104.

[0029] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to the implementation requirements.

[0030] Please refer to Figure 2 , Figure 2 A flowchart of a method for testing an interface provided by an embodiment of the present disclosure, wherein process 200 includes the following steps:

[0031] Step 201: Obtain the interface name and code set provided by the user for the interface to be tested;

[0032] This step is intended to be performed by the execution body of the test interface method (for example Figure 1 The server 105 shown in the figure obtains the interface name and code set provided by the user for the interface to be tested. For example, the user (e.g., software developer or tester) can use Figure 1The terminal devices 101, 102, and 103 are shown as user devices to communicate with the server 105, which is an example of an execution subject, and provide the execution subject with an interface name and a code set provided for the interface to be tested. The interface name can be the name of the interface to be tested. Taking the Python environment as an example, the interface in the Python environment can be understood as a convention or protocol to define which methods or attributes a class should implement. The interface does not provide an actual implementation, but only defines the signatures of which methods and attributes a class should have. The interface in Python is usually implemented through an abstract base class (Abstract Base Class, abbreviated as ABC). ABC is an abstract class that cannot be instantiated, but is used to define the public interface of other classes.

[0033] The code set is usually associated with at least the above-mentioned interface to be tested, or in other words, includes the code associated with the interface to be tested. In some scenarios, the interface name can also be called the service name. In this way, the user can indicate the interface to be tested and the code set (or code project) associated with the interface to be tested to the execution subject by communicating with the execution subject, thereby instructing the execution subject to perform the test of the interface to be tested that the user desires to test. In other words, the user can assign the task of testing the interface to be tested to the execution subject.

[0034] It should be understood that, in addition to the target code, the code set can also include any type of code, or in other words, the code set is not limited to including only the target code. Therefore, after the user specifies the project code and code set, the execution subject can "automatically" implement the interface test based on the analysis and extraction of the code set.

[0035] Alternatively or additionally, the user may provide interface names and corresponding code sets in batches, for example, in lists, Excel lists, etc., so that the user can efficiently indicate the interfaces that need to be tested to the execution entity and efficiently "dispatch the task of testing the interface" to the execution entity.

[0036] It should be noted that the code set can be obtained directly from a local storage device by the execution subject, or from a non-local storage device (such as Figure 1For example, in scenarios such as collaborative coding and cloud development, the code set may be stored in a storage device local to the execution subject. For example, the local storage device may be a data storage module provided in the execution subject, such as a server hard disk. In this case, the code set can be quickly read locally. The non-local storage device may also be any other electronic device configured to store data, such as some user terminals. In this case, the execution subject may obtain the required code set by sending an acquisition command to the electronic device.

[0037] Step 202: Based on the interface name, determine the target code associated with the interface to be tested from the code set;

[0038] On the basis of the above step 201, this step aims to extract the target code associated with the interface to be tested from the associated code set specified by the user after determining the interface to be tested that the user desires to test based on the interface name indicated by the user. For example, the execution subject can match the code that calls and involves the interface (interface name) from the code set based on the interface name and use it as the target code.

[0039] Step 203: Generate a test case for the interface to be tested according to the test parameters indicated by the target code;

[0040] On the basis of the above-mentioned step 202, this step is intended to determine the test parameters based on the analysis of the target code by the execution subject. Usually, the type and content of the test parameters are associated with the development environment and interface type of the code. For example, in the Python development environment, the test parameters can be the interface constants of the interface to be tested, the application programming interface (Application Programming Interface, API for short) function and the test case class abnormal test (TestAbnormal). For example, the interface constants of the interface to be tested can be constants indicated by, for example, a uniform resource locator (Uniform Resource Locator, URL for short) file (e.g., url_const.py) indicated by the target code. In some scenarios, based on the functions implemented, the uniform locator file, the application programming interface file and the test case testcase file can also be referred to alternatively as a uniform locator script, an application programming interface script and a test case testcase script.

[0041] Accordingly, after the execution subject determines the test parameters based on the target code, it can generate test cases for the interface to be tested based on these test parameters. For ease of understanding, the following explanation is given using the Python development environment. In the Python environment, the execution subject can determine the interface constants, application programming interface, and use case class exception tests of the interface to be tested, and then construct a unified locator file (url_const.py), an application programming interface file (api.py), and a target use case testcase file (testcases.py), thereby obtaining a test case by using a combination of url_const.py, api.py, and testcases.py.

[0042] Step 204: Use the test case to test the interface to be tested and generate an interface test result.

[0043] On the basis of the above step 203, this step aims to enable the execution subject to use the test case generated by the above step 203 to test the interface to be tested, and obtain and generate the interface test result based on the execution result of the test case of the interface to be tested, so as to complete the testing work for the interface to be tested.

[0044] It should be understood that after generating the interface test results, the execution entity can return the test results to the user device used by the user based on the user's previous configuration and request, or send and store the test results to a default path indicated by the user or pre-configured, so that the user can obtain the interface test results based on the user's indication or default path.

[0045] The method for testing an interface provided in the embodiment of the present disclosure can test the interface after generating a test case based on the code parsing result, so that the user only needs to provide the interface name of the interface to be tested and the related code set to achieve the purpose of testing the interface to be tested in the code set, thereby simplifying the difficulty of interface testing for users and improving testing efficiency.

[0046] In some optional implementations of this embodiment, the execution subject may also respond to receiving a storage request for a test case from a user by reading a test case storage address included in the storage request; and storing the test case at the test case storage address.

[0047] Specifically, in order to meet the needs of users to review test cases and reuse test cases, the user can instruct the execution subject to specify the location of the generated test cases to avoid the execution subject using random, default storage locations that the user does not know or is difficult to find to store the test cases, or avoid the execution subject mistakenly clearing the test cases due to lack of storage execution. Exemplarily, the user can provide the test case storage address by providing a storage request for the test case in the process of providing the interface name and code combination to the execution subject in the above step 201, so as to instruct and regulate the execution subject to store the test case in the test case storage address after generating the test case, so as to facilitate the user's subsequent call. It should be understood that the user can also choose to provide the test case storage address at any sending time independent of step 201, and the present disclosure is not intended to limit this. Accordingly, after generating the test case, the execution subject can store the test case to the test case storage address indicated by the user, so as to facilitate the user to retrieve and query based on demand later.

[0048] In some optional implementations of the present embodiment, when storing the test case, the execution subject can also store the identification information of the interface to be tested and the target test parameters for generating the test case in association with the test case, wherein the identification information is used to indicate the interface name of the interface to be tested for the test case. Specifically, when the execution subject stores the test case (for example, storing the test case to the storage address indicated by the user), the execution subject can also use the identification information to indicate the interface name of the interface to be tested for the test case and the target test parameters used when generating the test case (that is, the test parameters obtained when generating the test case). Thus, the interface to be tested and the target test parameters corresponding to the test case can be understood based on the identification information in the follow-up, so as to judge whether the quality of the test case generated by the execution subject meets the requirements, and determine whether the test case can be "reused" in other test processes.

[0049] In some embodiments, if it is allowed to call previously generated test cases in order to avoid repeated generation and improve test efficiency, in the scenarios and embodiments, the above-mentioned test cases for the interface to be tested are generated according to the test parameters indicated by the target code, including: detecting whether there are historical test cases that meet the test requirements according to the test parameters indicated by the target code, wherein the historical test cases are used to test the interface to be tested, and the similarity between the historical test parameters associated with the historical test cases and the test parameters is higher than a preset threshold; in response to the absence of historical test cases, a test case for the interface to be tested is generated.

[0050] Specifically, when the execution subject generates a test case for the interface to be tested according to the test parameters indicated by the target code, it can detect whether there is a historical test case that meets the test requirements for the interface to be tested after obtaining the test parameters indicated by the target code.

[0051] For example, the execution subject may obtain one or more test cases generated in the previous test process, and then determine whether there are historical test cases that meet the test requirements in the one or more test cases that have been generated previously, based on whether the similarity between the test parameters (or historical test parameters) for generating the one or more test cases and the test parameters obtained this time meets the requirements. For example, if the similarity between the historical test parameters corresponding to a test case that has been generated previously and the test parameters obtained this time meets the requirements, or the similarity is higher than a preset threshold (usually, the preset threshold can be pre-configured according to the "credibility" requirements), then the "one test case that has been generated previously" can be determined as a historical test case. If there is no historical test case that meets the requirements, the execution subject can respond to this and then choose to execute the process of generating test cases as described in the above process 200. Therefore, only when there is no historical test case that meets the requirements, the test case is selected to be generated to save computing resources.

[0052] Accordingly, in some optional implementations of this embodiment, if the execution subject determines that there is such a historical test case, it can choose to determine the historical test case as the test case for the interface to be tested, so as to execute the current test process and perform the test. Thus, when the user has repeated detection requirements, the test is performed based on the historical test case that meets the test requirements, without the need to generate new test cases, so as to save computing resources.

[0053] In some embodiments, obtaining the interface name and code set provided by a user for the interface to be tested includes: receiving a running function passed in by the user, wherein the running function at least indicates an access path of the code set and the interface name of the interface to be tested; and obtaining the interface name and code set based on the parsing result of the running function.

[0054] Specifically, in order to simplify the user's operating difficulty, the execution entity may allow the code collection and interface name to be provided in the form of a running function. An example of a running function is the run.py function. The user can at least use the values ​​of each parameter in the run.py function to indicate the access path of the code collection and the interface name of the interface to be tested. In some optional implementations of this embodiment, the running function may also include parameters for indicating the use case storage address. Exemplarily, in the run.py function, the repoPath value may be used to indicate the access path of the code collection, the urlList value may be used to indicate the interface name, and the caseDir value may be used to indicate the use case storage address. Thus, the user can conveniently provide the information required by the execution entity by running the function to reduce the user's operating difficulty and improve interaction efficiency.

[0055] As an alternative or in addition, in some scenarios, if the user needs to set custom code for an API function, the user can also use the value of a running function such as selfDefine to indicate it.

[0056] The following will describe in detail the details of generating test cases for the interface to be tested according to the test parameters indicated by the target code provided by the present disclosure. For easy understanding, please also refer to Figure 3 , Figure 3 A flowchart of a process 300 for generating a test case provided by an embodiment of the present disclosure. The process 300 can be used as the above Figure 2 In the illustrated embodiment, step 203 is replaced. Specifically, process 300 includes the following steps:

[0057] Step 301: construct a unified locator file name, an application programming interface file name and a test case file name based on the interface name;

[0058] Specifically, the execution entity can determine the uniform locator file name, application programming interface file name and use case testcase file name based on the interface name, or in other words, the execution entity can determine the names of the uniform locator file, application programming interface file and use case testcase file that can be associated with the "interface name" based on the interface name.

[0059] Step 302: Based on the uniform locator file name, the application programming interface file name, and the test case file name, it is detected whether a target uniform locator file corresponding to the uniform locator file name, a target application programming interface file corresponding to the application programming interface file name, and a target test case file corresponding to the test case file name are maintained locally;

[0060] Specifically, this step aims to use the unified locator file name, application programming interface file name and testcase file name generated in the above step 301, and then the execution subject searches locally whether the target unified locator file corresponding to the unified locator file name, the target application programming interface file corresponding to the application programming interface file name and the target testcase file corresponding to the testcase file name have been maintained. In other words, it is to detect whether at least one of the target unified locator file (e.g., url_const.py), the target application programming interface file (e.g., api.py) and the target testcase file (e.g., testcases.py) corresponding to the interface to be tested and used to test it is missing locally.

[0061] If the execution entity detects that at least one of the target unified locator file corresponding to the unified locator file name, the target application programming interface file corresponding to the application programming interface file name, and the target use case testcase file corresponding to the use case testcase file name is not maintained locally, or in other words, there is a missing item (that is, the item among the above three items that is not maintained locally on the execution entity), step 303 is executed to generate the missing item.

[0062] If the execution subject detects that the target unified locator file corresponding to the unified locator file name, the target application programming interface file corresponding to the application programming interface file name, and the target use case testcase file corresponding to the use case testcase file name are all maintained locally, or in other words, the execution subject detects that there are no missing items, then the execution subject can directly execute step 304 to generate a test case for the interface to be tested based on the target unified locator file, the target application programming interface file, and the target use case testcase file.

[0063] Step 303: Generate missing items based on the file names of the missing items;

[0064] For example, in the case where the target unified locator file is missing, the execution subject can generate the target unified locator file based on the unified locator file name determined above. In some embodiments, when the execution subject generates the file of the missing item, the execution subject can store the file generated to fill the missing item based on the pre-configured file storage address, which will not be repeated here.

[0065] Furthermore, after filling in the missing items, the execution subject can continue to select execution step 304 to generate a test case for the interface to be tested based on the target unified locator file, the target application programming interface file and the target test case testcase file. In this way, it can be ensured that the test case can be generated normally, avoiding system errors caused by missing files and the like.

[0066] Step 304: Generate a test case for the interface to be tested based on the target unified locator file, the target application programming interface file and the target test case testcase file.

[0067] In some embodiments, for the case where the test parameters include interface constants, application programming interface functions and use case class exception tests of the interface to be tested, a test case for the interface to be tested is generated based on the target unified locator file, the target application programming interface file and the target use case testcase file, including: adjusting the target unified locator file based on the interface constants, adjusting the target application programming interface file based on the application programming interface function and adjusting the target use case testcase file based on the use case class exception test; generating a test case for the interface to be tested based on the adjustment results of the target unified locator file, the adjustment results of the target application programming interface file and the adjustment results of the target use case testcase file.

[0068] Specifically, for the case where the test parameters include interface constants of the interface to be tested, application programming interface functions and use case class exception tests, if the target unified locator file, the target application programming interface file and the target use case testcase file all exist, the execution entity adjusts the target unified locator file based on the interface constants, adjusts the target application programming interface file based on the application programming interface functions and adjusts the target use case testcase file based on the use case class exception tests.

[0069] For example, for url_const.py, the execution subject can check whether the class where the interface constant (or the interface constant value) of the interface to be tested is located exists. If it exists, the execution subject can splice the definition of this interface constant to the last line of this class. Conversely, if the class where the interface constant value is located does not exist, the execution subject can create this class accordingly and add the definition of this interface constant to this class.

[0070] Exemplarily, for api.py, the execution body can check whether there is an application programming interface function (API function) of the interface to be tested in api.py. If so, skip generating the API function. If not, the execution body can check whether the class where the interface API to be tested is located exists. If not, create this class and add the API function to this class; if so, directly add the API function to the end of this class.

[0071] Exemplarily, for testcases.py, the executing entity can check whether the use case class abnormal test (TestAbnormal) of the API exists. If not, the executing entity can choose to create this class and generate abnormal tests (use cases) such as necessary parameters not being passed and parameter values ​​being incorrect; in some embodiments, the executing entity can also check whether the use case test (TestNormal) of the interface to be tested exists. If not, the executing entity can also generate positive use cases such as passing only required parameters, passing a combination of required parameters and a single required parameter, and passing all parameters after creating this class.

[0072] Accordingly, after completing the above adjustment, the execution subject generates a test case for the interface to be tested based on the adjustment results of the target unified locator file, the adjustment results of the target application programming interface file, and the adjustment results of the target test case testcase file. Thus, the execution subject can automatically complete the available test cases that can be used to test the interface to be tested based on the extraction results of the code set, simplifying the difficulty of the user to test the interface.

[0073] To deepen understanding, the present disclosure also provides a specific implementation solution in combination with a specific application scenario, see Figure 4 Flow 400 is shown.

[0074] In process 400, user 410 provides communication running function 420 to execution subject (e.g., server 105). Running function 411 can be used to indicate access path and use case storage path 421 of code set 431, interface name 422 of interface to be tested and use case storage address 423 for storing test case 433, for example.

[0075] After receiving the run function 420 , the server 105 may first obtain a code set 431 based on the access path and the use case storage path 421 .

[0076] Further, the server 105 may determine the target code 432 from the code set 431 based on the interface name 422 .

[0077] Furthermore, the execution subject may generate a test case 433 based on the test parameters indicated by the target code 432 and the test case storage address 423. Accordingly, the test case 433 generated by the server 105 may be stored in the test case storage address 423.

[0078] Finally, the server 105 may use the test 433 to test the interface to be tested (ie, the interface indicated by the interface name 422 ), and after generating the test result 434 , communicate and return the test result 434 to the user 410 , thereby completing the complete test process.

[0079] Therefore, the method for testing the interface provided in the embodiment of the present disclosure can test the interface after generating a test case based on the code parsing result, so that the user only needs to provide the interface name of the interface to be tested and the related code set to achieve the purpose of testing the interface to be tested in the code set, thereby simplifying the user's testing difficulty for the interface and improving testing efficiency.

[0080] Further references Figure 5 As an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of a device for testing an interface. Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0081] like Figure 5 As shown, the device 500 for testing an interface of this embodiment may include: a name and code acquisition unit 501, a target code determination unit 502, a test case generation unit 503, and a test result generation unit 504. The name and code acquisition unit 501 is configured to acquire an interface name and a code set provided by a user for the interface to be tested; the target code determination unit 502 is configured to determine the target code associated with the interface to be tested from the code set based on the interface name; the test case generation unit 503 is configured to generate a test case for the interface to be tested according to the test parameters indicated by the target code; and the test result generation unit 504 is configured to test the interface to be tested using the test case and generate an interface test result.

[0082] In the present embodiment, in the device 500 for testing the interface, the specific processing of the name and code acquisition unit 501, the target code determination unit 502, the test case generation unit 503 and the test result generation unit 504 and the technical effects thereof can be referred to in Figure 2 The relevant descriptions of steps 201 - 204 in the corresponding embodiment are not repeated here.

[0083] In some optional implementations of this embodiment, the test case generation unit 503 includes: a file name determination subunit, configured to construct a unified locator file name, an application programming interface file name and a use case testcase file name based on the interface name; a file integrity detection subunit, configured to detect whether a target unified locator file corresponding to the unified locator file name, a target application programming interface file corresponding to the application programming interface file name and a target use case testcase file corresponding to the use case testcase file name are maintained locally based on the unified locator file name, the application programming interface file name and the use case testcase file name; a missing file filling subunit, configured to generate a missing item based on the file name of the missing item in response to at least one of the target unified locator file, the target application programming interface file and the target use case testcase file being missing; a first test case generation subunit, configured to generate a test case for the interface to be tested based on the target unified locator file, the target application programming interface file and the target use case testcase file.

[0084] In some optional implementations of the present embodiment, the test parameters include interface constants, application programming interface functions and use case class exception tests of the interface to be tested, and the first test case generation subunit includes: a file adjustment module, configured to adjust the target unified locator file based on the interface constants, adjust the target application programming interface file based on the application programming interface function, and adjust the target use case testcase file based on the use case class exception test; a test case generation module, configured to generate a test case for the interface to be tested based on the adjustment results of the target unified locator file, the adjustment results of the target application programming interface file and the adjustment results of the target use case testcase file.

[0085] In some optional implementations of this embodiment, the device 500 also includes: a storage address reading unit, configured to read the use case storage address included in the storage request in response to receiving a storage request for a test case from a user; and a test case storage unit, configured to store the test case to the use case storage address.

[0086] In some optional implementations of this embodiment, the device 500 also includes: an additional information association unit, configured to store identification information of the interface to be tested in association with the test case, and target test parameters for generating the test case, wherein the identification information is used to indicate the interface name of the interface to be tested targeted by the test case.

[0087] In some optional implementations of the present embodiment, the test case generation unit 503 includes: a historical test case query subunit, configured to detect whether there are historical test cases that meet the test requirements based on the test parameters indicated by the target code, wherein the historical test cases are used to test the interface to be tested, and the similarity between the historical test parameters associated with the historical test cases and the test parameters is higher than a preset threshold; and a second test case generation subunit, configured to generate a test case for the interface to be tested in response to the absence of a historical test case.

[0088] In some optional implementations of this embodiment, the test case generating unit 503 further includes: a third test case generating subunit configured to, in response to the existence of historical test cases, determine the historical test cases as test cases for the interface to be tested.

[0089] In some optional implementations of this embodiment, the name and code acquisition unit 501 includes: a running function receiving subunit, configured to receive a running function passed in by a user, wherein the running function at least indicates an access path of a code set and an interface name of an interface to be tested; and a name and code acquisition subunit, configured to acquire an interface name and a code set based on a parsing result of the running function.

[0090] This embodiment exists as an apparatus embodiment corresponding to the above-mentioned method embodiment. The apparatus for testing the interface provided by this embodiment can test the interface after generating a test case based on the code parsing result, so that the user only needs to provide the interface name of the interface to be tested and the related code set to achieve the purpose of testing the interface to be tested in the code set, thereby simplifying the difficulty of interface testing for users and improving testing efficiency.

[0091] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium and a computer program product.

[0092] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement an embodiment of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.

[0093] like Figure 6As shown, the device 600 includes a computing unit 601, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the device 600 can also be stored. The computing unit 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0094] A number of components in the device 600 are connected to the I / O interface 605, including: an input unit 606, such as a keyboard, a mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a storage unit 608, such as a disk, an optical disk, etc.; and a communication unit 609, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0095] The computing unit 601 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 601 performs the various methods and processes described above, such as the method of testing the interface. For example, in some embodiments, the method of testing the interface may be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as a storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the method of testing the interface described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the method of testing the interface by any other appropriate means (e.g., by means of firmware).

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

[0097] The program code for implementing the method of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0098] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

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

[0100] The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0101] A computer system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship between the client and the server is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or a cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and virtual private servers (VPS) services. The server can also be divided into a server of a distributed system, or a server combined with a blockchain.

[0102] According to the technical solution of the embodiment of the present disclosure, after generating test cases based on the code parsing results, the interface can be tested, so that the user only needs to provide the interface name of the interface to be tested and the relevant code set to achieve the purpose of testing the interface to be tested in the code set, thereby simplifying the user's testing difficulty for the interface and improving testing efficiency.

[0103] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solutions provided by this disclosure can be achieved, and this document does not limit this.

[0104] The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A method for testing an interface, comprising: Get the interface name and code set provided by the user for the interface to be tested; Based on the interface name, determining the target code associated with the interface to be tested from the code set; Generate a test case for the interface to be tested according to the test parameters indicated by the target code, including: constructing a unified locator file name, an application programming interface file name and a test case testcase file name based on the interface name; based on the unified locator file name, the application programming interface file name and the test case testcase file name, detecting whether a target unified locator file corresponding to the unified locator file name, a target application programming interface file corresponding to the application programming interface file name and a target test case testcase file corresponding to the test case testcase file name are maintained locally; in response to at least one of the target unified locator file, the target application programming interface file and the target test case testcase file being missing, generate the missing item based on the file name of the missing item; based on the target unified locator file, the target application programming interface file and the target test case testcase file, generate a test case for the interface to be tested; The test case is used to test the interface to be tested, and an interface test result is generated.

2. The method according to claim 1, wherein: The test parameters include interface constants, application programming interface functions and use case class exception tests of the interface to be tested, and the generating of a test case for the interface to be tested based on the target unified locator file, the target application programming interface file and the target use case testcase file includes: Respectively adjusting the target unified locator file based on the interface constant, adjusting the target application programming interface file based on the application programming interface function, and adjusting the target use case testcase file based on the use case class exception test; Based on the adjustment result of the target unified locator file, the adjustment result of the target application programming interface file and the adjustment result of the target test case file, a test case for the interface to be tested is generated.

3. The method according to claim 1, further comprising: In response to receiving a storage request from the user for the test case, reading a storage address of the test case included in the storage request; The test case is stored in the test case storage address.

4. The method according to claim 3, further comprising: The identification information of the interface to be tested and the target test parameters for generating the test case are stored in association with the test case, wherein the identification information is used to indicate the interface name of the interface to be tested targeted by the test case.

5. The method according to claim 1, wherein: The step of generating a test case for the interface to be tested according to the test parameters indicated by the target code comprises: According to the test parameters indicated by the target code, detecting whether there is a historical test case that meets the test requirements, wherein the historical test case is used to test the interface to be tested, and the similarity between the historical test parameters associated with the historical test case and the test parameters is higher than a preset threshold; In response to the absence of the historical test case, a test case for the interface to be tested is generated.

6. The method according to claim 5, further comprising: In response to the existence of the historical test case, the historical test case is determined as a test case for the interface to be tested.

7. The method according to any one of claims 1 to 6, wherein: The step of obtaining the interface name and code set provided by the user for the interface to be tested includes: Receive a running function passed in by a user, wherein the running function at least indicates an access path of a code set and an interface name of an interface to be tested; Based on the parsing result of the running function, the interface name and the code set are obtained.

8. A device for testing an interface, comprising: A name and code acquisition unit, configured to acquire an interface name and a code set provided by a user for an interface to be tested; a target code determination unit, configured to determine, based on the interface name, from the code set, a target code associated with the interface to be tested; A test case generating unit, configured to generate a test case for the interface to be tested according to the test parameters indicated by the target code, including: a file name determining subunit, configured to construct a unified locator file name, an application programming interface file name and a test case testcase file name based on the interface name; a file integrity detecting subunit, configured to detect whether a target unified locator file corresponding to the unified locator file name, a target application programming interface file corresponding to the application programming interface file name and a target test case testcase file corresponding to the test case testcase file name are maintained locally based on the unified locator file name, the application programming interface file name and the test case testcase file name; a missing file filling subunit, configured to generate the missing item based on the file name of the missing item in response to at least one of the target unified locator file, the target application programming interface file and the target test case testcase file being missing; a first test case generating subunit, configured to generate a test case for the interface to be tested based on the target unified locator file, the target application programming interface file and the target test case testcase file; The test result generating unit is configured to test the interface to be tested by using the test case to generate an interface test result.

9. The device according to claim 8, wherein: The test parameters include interface constants, application programming interface functions and use case class exception tests of the interface to be tested, and the first test case generation subunit includes: A file adjustment module is configured to adjust the target unified locator file based on the interface constant, adjust the target application programming interface file based on the application programming interface function, and adjust the target use case testcase file based on the use case class exception test; The test case generation module is configured to generate a test case for the interface to be tested based on the adjustment result of the target unified locator file, the adjustment result of the target application programming interface file and the adjustment result of the target test case file.

10. The apparatus according to claim 8, further comprising: A storage address reading unit, configured to, in response to receiving a storage request from the user for the test case, read the test case storage address included in the storage request; The test case storage unit is configured to store the test case to the test case storage address.

11. The apparatus according to claim 10, further comprising: The additional information associating unit is configured to store the identification information of the interface to be tested and the target test parameters for generating the test case in association with the test case, wherein the identification information is used to indicate the interface name of the interface to be tested targeted by the test case.

12. The device according to claim 8, wherein: The test case generating unit comprises: A historical test case query subunit is configured to detect whether there is a historical test case that meets the test requirements according to the test parameters indicated by the target code, wherein the historical test case is used to test the interface to be tested, and the similarity between the historical test parameters associated with the historical test case and the test parameters is higher than a preset threshold; The second test case generating subunit is configured to generate a test case for the interface to be tested in response to the absence of the historical test case.

13. The device according to claim 12, wherein the test case generating unit further comprises: The third test case generating subunit is configured to, in response to the existence of the historical test case, determine the historical test case as a test case for the interface to be tested.

14. The device according to any one of claims 8 to 13, wherein: The name and code acquisition unit includes: The running function receiving subunit is configured to receive a running function input by a user, wherein the running function at least indicates an access path of a code set and an interface name of an interface to be tested; The name and code acquisition subunit is configured to acquire the interface name and the code set based on the parsing result of the running function.

15. An electronic device, comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the test interface method according to any one of claims 1 to 7.

16. A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute the method for testing an interface according to any one of claims 1 to 7.

17. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the method for testing an interface according to any one of claims 1 to 7.

Images