Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments, but not all embodiments, of the technical solutions of the present application. All other embodiments obtained by a person skilled in the art without any inventive step based on the embodiments described in the present application are within the scope of the protection of the present application.
Some concepts related to the embodiments of the present application are described below.
Form: the webpage is mainly responsible for data acquisition functions. A form has three basic components: form label: included are the URLs of CGI (Common Gateway Interface) programs used to process form data and the methods by which the data is submitted to the server.
AC (Aho-coral automation, multi-mode matching algorithm) automaton: the method is mainly used for solving the matching problem of the multi-mode strings, and is a variation of a dictionary tree (trie tree), namely a pseudo tree structure (a main body is tree-shaped, but a failure pointer is added, so that the main body becomes a directed graph); the trie graph is a modification of the AC automaton, so that each node in the graph has MAXC out edges (MAXC represents the size of the character set of the graph), each node on the trie graph represents a state and corresponds to the node of the AC automaton in a one-to-one mode. The AC automaton is that a fail pointer is added on the basis of a tie tree, and if the current point fails to be matched, the pointer is transferred to the position pointed by the fail pointer, so that the path matching can be continued without backtracking. In the embodiment of the application, keyword string matching can be performed through the AC automaton, and interface return information returned by the target interface is further analyzed.
http (HyperText Transfer Protocol) status code: is a 3-bit digital code used to represent the http response status of the web server. The following categories are classified: firstly, message: this type of status code, representing that the request has been accepted, requires continued processing. II, success: this type of status code, represents that the request has been successfully received, understood, and accepted by the server. Thirdly, redirection: such status codes represent the need for further action by the client to complete the request. Typically, these status codes are used for redirection, and the subsequent request address (redirection target) is indicated in the Location field of the present response. Fourthly, request error: such a status code represents that the client may appear to be in error, preventing processing by the server. Fifthly, server error: the status codes (5, 6 headers) represent that the server has an error or abnormal status during the process of processing the request, and it is possible that the server realizes that the processing of the request cannot be completed by the current software and hardware resources. These status codes are applicable to any response method.
Reusing: the same thing is repeatedly used in different environments without modification or slight change. Reusability refers to the property of being reusable. The test tool in the embodiment of the application has reusability, and can be an applet with open capability, and the target interface can be further tested by scanning the two-dimensional code or directly accessing a tool test page of the test tool based on links and the like.
Tool configuration page: the API interface is a user-oriented page used for configuring the test tool, and the user can edit various configuration information through the interface, so that the API can be debugged and configured in a tool mode. The configuration information includes tool configuration information, parameter configuration information, and the like. In the embodiment of the present application, the tool configuration information may include tool name, category, developer, request URL (i.e. interface API), usage, remark, and the like; the parameter configuration information is used for configuring parameter controls required by the interface request, and specifically includes configuration of parameter names, parameter verification rules, control types, control names and the like, wherein the control types include text boxes, multi-line text boxes, radio boxes, multi-choice boxes, drop-down boxes and the like.
And (3) control editing page: the user-oriented page is used for configuring the parameter control, and through the page, the user can preview various configuration information related to the parameter control, and can further edit and modify the various configuration information, wherein the various configuration information comprises a parameter name, a parameter verification rule, a control type, a control name and the like.
Tool test page: the interface test method is a user-oriented page for testing the interface, through which a user can input various interface test parameters, and based on various interface test parameters input by the user and previously configured request related information, an interface test request for accessing the interface service can be generated. In addition, after the target interface is tested, the test result can be further displayed in the page. In the embodiment of the present application, the test result can be specifically divided into two parts: http status code for representing the interface response condition and target keywords for representing the interface calling result.
A main key: a primary key (primary key) is one or more fields in a table whose value is used to uniquely identify a record in the table. In a two table relationship, the primary key is used to reference a particular record in one table from the other table. The primary key is a unique key that is part of the table definition. A table has only one primary key. The primary key may be composed of one field or a plurality of fields, and is respectively called a single-field primary key or a multi-field primary key. Also known as a master code. And it may uniquely identify a row of data in the table or may uniquely identify an entity.
The following briefly introduces the design concept of the embodiments of the present application:
with the development of computer technology, people acquire various information through the internet, http is the most widely applied network protocol on the internet, all WWW files must comply with the standard, and before a webpage is released, an http interface can be tested by sending a webpage http request.
In the related art, tools capable of calling and debugging the interface include a chrome browser plug-in Talend api Tester, a chrome browser plug-in post man and the like. The testing tools fill in parameters required by API interface requests in a form through a visual interface. For example, as shown in fig. 1, it is a schematic diagram of a test interface of a chrome browser plug-in Talend api Tester, which is mainly divided into two parts, one part is a request part, and the other part is an interface response result.
Regarding the request part, mainly referring to the selection of the http request method, for example, the POST request method (or the GET request method), after the user inputs the request URL, the request Header, and the request BODY, the Send button in fig. 1 is clicked, so that the request can be sent to the interface service, and the interface is tested.
The Response part is mainly used for displaying the result returned by the request, and in the related technology, the result returned by the request is mainly used for displaying the http state code, so that the request result can be judged only by returning information to the interface according to the http state code, and the success and failure of the request can not be flexibly judged by combining the information returned by the interface. For example, as shown in fig. 1, the http status code is "302 Found", which indicates that the server is currently responding to a request from a web page in a different location, but the requester should continue to use the original location for subsequent requests.
Aiming at a test tool in the related technology, only an API can be debugged, the legality of API request parameters cannot be verified, the open applet tool capability cannot be provided, only http state codes can be displayed, and the display result is single.
In view of this, embodiments of the present application provide an interface testing and tool configuration method and apparatus, an electronic device, and a storage medium. The interface testing tool in the embodiment of the application can be a small program with specific open capability, tests the http/https interface by using a parameterized configuration method, and can also generate real-time graphical preview for the configuration information of the API interface, debug the API interface in real time, check the legality of request parameters of the API interface and generate a instrumental call link for the API interface. Specifically, based on API interface configuration information set by a tool developer, request related information and parameter controls related to a target interface are configured in advance, and corresponding parameter verification rules are also configured in the parameter controls.
The preferred embodiments of the present application will be described below with reference to the accompanying drawings of the specification, it should be understood that the preferred embodiments described herein are merely for illustrating and explaining the present application, and are not intended to limit the present application, and that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.
Fig. 2 is a schematic view of an application scenario according to an embodiment of the present application. The application scenario diagram includes twoterminal devices 210 and aserver 230, and theterminal devices 210 can log in arelated page 220, such as a tool configuration page and a tool test page in the embodiment of the present application. Theterminal device 210 and theserver 230 can communicate with each other through a communication network. In fig. 2, the user a and the user B each correspond to oneterminal device 210 as an example, and the number of terminal devices is not limited in practice. In some cases, the terminal devices may communicate with each other through theserver 230 first, direct communication may be established between the terminal devices, and a manner of direct communication between the terminal devices may be referred to as point-to-point communication.
Each terminal device may be installed with a client of the testing tool provided in the embodiment of the present application. The client related to the embodiment of the present application may be a pre-installed client, may also be a client embedded in a certain application (for example, an applet), and may also be a web page version client, without limiting the specific type of the client. When transmitting the interface test request, theterminal device 210 needs to communicate with theserver 230 via the communication network, and when receiving the interface return information or the like returned from theserver 230, needs to communicate via the communication network.
In an alternative embodiment, the communication network is a wired network or a wireless network. The terminal 210 and theserver 230 may be directly or indirectly connected through wired or wireless communication, and the present application is not limited thereto.
In this embodiment, theterminal device 210 is an electronic device used by a user, and the electronic device may be a computer device having a certain computing capability and running instant messaging software and a website or social contact software and a website, such as a personal computer, a mobile phone, a tablet computer, a notebook, an e-book reader, and the like. Eachterminal device 210 is connected to theserver 230 through a wireless Network, and theserver 230 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a Network service, cloud communication, middleware service, a domain name service, a security service, a CDN (Content Delivery Network), and a big data and artificial intelligence platform. The terminal may be, but is not limited to, a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, and the like. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein.
Referring to fig. 3, it is a flowchart illustrating an implementation of the interface testing method according to the embodiment of the present application, and the specific implementation flow of the method is as follows:
step S31: responding to a test operation triggered by a tool test page aiming at a target interface, and acquiring interface test parameters aiming at the target interface determined based on parameter controls in the tool test page, wherein each parameter control corresponds to an interface test parameter relevant to the test;
step S32: generating an interface test request based on the preconfigured request related information and the interface test parameters, and sending the interface test request to a target interface server, wherein the request related information is preconfigured according to the acquired configuration information related to the test of the target interface after responding to the tool configuration operation which is triggered by a tool configuration page and is aimed at the target interface;
the target interface in the embodiment of the present application may be an http/https API interface at a World Wide Web (World Wide Web) end, and the target interface server may refer to a corresponding Web server.
Step S33: and acquiring interface return information returned by the target interface server, and displaying a test result generated based on the interface return information in a tool test page.
It should be noted that, the request related information related to the test performed on the target interface and the parameter control in the tool test page are both configured in advance, and for the target interface, the test tool in the embodiment of the present application is a reusable and extensible test tool, before implementing step S31, the test tool provided in the embodiment of the present application needs to be configured through a configuration stage first, and after the configuration is completed, the user can use the test tool to test the target interface, at this time, the test process is as shown in steps S31 to S33. The following describes in detail an interface test method and an interface test tool configuration method in the embodiment of the present application with reference to fig. 4A and 4B:
referring to fig. 4A and 4B, two alternative schematic diagrams of a system framework provided by the embodiment of the present application are mainly divided into three stages: a configuration phase, a test phase, and a tool phase. The configuration stage specifically comprises a configuration module, a connectivity detection module and a verification module; the test stage specifically comprises a request module, a verification module and a result processing module; the tool phase mainly comprises a tool generation module.
The configuration phase is first described in detail below:
specifically, a user can input configuration information for a target interface in a tool configuration page, and the terminal device obtains configuration information related to testing of the target interface in response to tool configuration operation for the target interface triggered by the tool configuration page; furthermore, the terminal device can configure the request related information and the parameter control during testing according to the configuration information, so as to realize specific openness and reusable effects.
In the embodiment of the application, each parameter control corresponds to an interface test parameter related to the test. Wherein the configuration information at least comprises tool configuration information and parameter configuration information. When the request related information and the parameter control are configured according to the configuration information during testing, the method is mainly divided into two parts:
acquiring request related information when testing a target interface according to tool configuration information set by a tool developer and configuring the request related information;
specifically, the tool configuration information includes: the tool name, the tool classification, the developer, the request URL (i.e. interface API), the usage, the remark, etc. based on the tool configuration information set by the tool developer, the request related information related to the target interface test can be determined and configured.
And secondly, acquiring a parameter control required when the target interface is tested according to the parameter configuration information set by the tool developer, and configuring.
Specifically, the parameter configuration information is used to configure the parameter control required by the interface request, and specifically includes a control type, a control serial number, a control name, a control remark, a parameter name, a parameter verification rule, and the like.
Wherein the control types include a text box, a multi-line text box, a radio box, a multi-choice box, a drop-down box, and the like.
Specifically, the text box can directly input characters, the multi-line text box can input multi-line characters, the drop-down box can display a list of drop-down selections, the radio box represents that only one item in the attribute values can be selected, namely only single selection is performed, and the multi-selection box represents that multiple items in the attribute values can be selected, namely multiple selection is performed.
It should be noted that, the examples in the foregoing embodiments are only some control types, and actually any control type is applicable to the embodiments of the present application, and is not limited specifically herein.
In the embodiment of the present application, the configuration process is implemented based on a configuration module in a configuration phase, and configuration information required by an interface request, including a request URL, a request header, a request parameter and a parameter check rule, may be configured and stored by the configuration module. Specifically, the configuration module is implemented through front-end interaction, acquires configuration information input by a tool developer, and composes the acquired configuration information into a structured json (JavaScript Object Notation) configuration.
Fig. 5 is a schematic view of a tool configuration page according to an embodiment of the present application. In the page shown in fig. 5, a tool developer may directly input tool configuration information and parameter configuration information to be filled in a text box corresponding to each item of configuration information shown in fig. 5, and perform debugging and tool configuration on the API. The tool configuration information and the parameter configuration information set by the tool developer are respectively described in detail below with reference to fig. 5:
the tool configuration information specifically includes the following configuration items:
1) the tool name is: inquiring detailed information of the merchant; correspondingly, the enabling state of the tool can be further set, when the tool developer sets the enabling state to be in the configuration stage, the testing tool is not opened to the outside, and when the tool developer sets the enabling state to be in the enabling state, the testing tool can be opened to the outside, the testing tool is ready and can be provided for the user;
2) tool classification: the configuration item can be filled in directly by a tool developer. Further, it may not be configured, in which case "unclassified" is defaulted;
3) the developer: the configuration item is directly filled by a tool developer;
4) the service side requests URL: the configuration item is also directly filled in by the tool developer, and represents a link corresponding to the target interface, as shown in fig. 5, a request URL filled in by the tool developer is:
/mchaccount/tool/get_merchant_by_id。
in the testing stage, an interface testing request can be sent to the target interface server based on the URL, and the target interface is tested. The request mode of the interface test request may be: the GET request method or the POST request method may be configured by a tool developer or may be selected autonomously by a user during a testing phase.
5) Tool use: as can be seen from FIG. 5, the purpose of the test tool is to query merchant details;
6) and (4) remarking tools: as can be seen from fig. 5, the remark of the test tool is to invoke the WeChat payment merchant svrkit interface to query the merchant detailed information. < br > < br > jump to < ahref? And the FToolID is 10 'blank' > modifies the merchant relationship.
Based on the tool configuration information, it can be determined that, for the target interface for querying the merchant detailed information, the request related information includes request URL (/ mchaccount/tool/get _ merchant _ by _ id), request header information, and the like.
The parameter configuration information is used for configuring the parameter control, and specifically includes a control type, a control configuration, whether a primary key is used and several configuration items for operation.
1) The control types include: a text box, a multi-line text box, a radio box, a multi-choice box, a drop-down box, etc., and the tool developer may display other selectable control types by clicking a drop-down key shown in fig. 5, for example, as shown in fig. 6, the control type of the parameter control with the current sequence number of 1 is a text box.
The selection of the control type is mainly determined according to interface test parameters corresponding to the parameter control, for example, when the interface test parameters are merchant IDs, the interface test parameters need to be filled by a user, and the control type of the corresponding parameter control is generally a text box; when the interface test parameter is still the merchant ID, but several selectable candidate merchant IDs are preconfigured, the control type of the corresponding parameter control may be a radio box, and so on.
2) And (3) control configuration: the method mainly refers to detailed configuration information of the parameter control, including parameter names, parameter verification rules, control names and the like, and can be filled by a tool developer. For example, as shown in fig. 5, a parameter control for a text box type with a sequence number of 1 is filled by a tool developer, and a specific control configuration includes:
{ "order":1, "widget _ type": text "," widget _ label ": merchant ID", "widget _ mark": must fill, please enter merchant map, example: 9xx "," param _ name ": merchant _ id", "is _ required":1 "," do _ check ": 1", "check _ regex": "/[ 1-9] [0-9] $/" }.
The control configuration column contains 8 configuration items in total, and the method comprises the following steps:
1 in order, the serial number is 1;
"widget _ type": text ", which indicates that the control type is text;
the widget _ label and the merchant ID represent that the control label is the merchant ID, namely the control is named as the merchant ID in Chinese;
"Widget _ Remark": Please input Merchant map, example: 9xx ", indicating that the control remark is" must fill, please enter merchant's madid, example: 9xx ";
"parameter _ name": merchant _ id "indicates that the parameter name is merchant _ id;
1, which indicates whether the required item is 1, that is, the request test parameter corresponding to the parameter control, that is, the merchant ID is the required item;
1, which indicates whether the check item is 1, that is, the requested test parameter corresponding to the parameter control needs to be checked;
"check _ regex": "/[ 1-9] [0-9] $/", which means that the (parameter) check rule is: /[ 1-9] [0-9] $/.
In the embodiment of the application, considering that the interface test parameters generally have a value range, a field type and the like, the special interface test parameters also have special formats, such as an identity card number and a bank card number, and have specified lengths and rules, so that the interface test parameters can be verified based on the configuration of the parameter verification rules.
The parameter verification rule listed in the above embodiment is in the form of a regular expression, and is used to detect whether the merchant ID conforms to the ID rule. In addition, the parameter verification rule may be set through code logic detection, third-party interface detection, and the like, which is not specifically limited herein.
3) Whether the primary key: and indicating whether the interface test parameter corresponding to the parameter control is a primary key word. When the tool is configured, the primary key of the account needs to be appointed for recording which account is operated, and the subsequent operation flow of the account is convenient to view.
4) The operation is as follows: the tool developer can also configure the operation related to the parameter control based on the configuration item.
It should be noted that all tool operations in the embodiment of the present application are initiated by the tool platform listed in the present application from the back end, and the service-side interface is called to complete the account operation. The tool platform enumerated in the application records the operation of the user on the account. In addition, only system administrators and tool developers have access to modify the tool configuration.
Optionally, after configuring the request related information and the parameter control required in testing the target interface based on the configuration information set by the user through the tool configuration page, the configuration of the parameter control may be previewed and modified by clicking a page preview button shown in fig. 5. At this time, the terminal device responds to the preview operation triggered by the tool developer through the tool configuration page, and displays the control editing page containing the parameter control configuration result.
For example, fig. 7 is a schematic diagram of a control editing page provided in an embodiment of the present application. The configuration result of the parameter control configured in the above process is shown in detail in the figure, and specifically includes the serial number to which the parameter control belongs, the control type, the Chinese name of the control, the remark of the control, the parameter name, whether the parameter control needs to be filled, whether the parameter control needs to be checked, the check rule, and the like.
As can be seen from fig. 7, the serial number is 1, the control type is text (text box), the control chinese name is merchant ID, and the control remarks are: to fill, please enter merchant mchid, example: 9xx, the parameter name is merchant _ id, and in addition, whether the interface test parameter corresponding to the parameter control is a mandatory item or not, whether verification is needed or not, and the like can be further set, and if verification is needed, a corresponding verification rule is further set.
The parameter to be filled in by the parameter control with the sequence number of 1 is the merchant ID, wherein the item "whether to fill in" is 1, which indicates that the parameter is an indispensable item (when 0, indicates that the parameter is an indispensable item); in addition, the "check-not" term of 1 indicates that the parameter needs to be checked (similarly, when 0, it indicates that the parameter does not need to be checked).
In this embodiment of the application, the user may further modify the parameter control previously configured according to the parameter configuration information through the control editing page shown in fig. 7. For example, the user is currently modifying the configuration item "control note" in the "textbox" type control, specifically, after the user clicks the configuration item "control note" in the left side in fig. 7, the right side part in fig. 7 may modify the configuration item by editing the content in the textbox corresponding to the merchant ID, and after the modification is completed, the configuration modification of the configuration item may be triggered by clicking the determination button shown in fig. 7.
Specifically, the terminal device may obtain the control configuration information for the target parameter control in response to the editing operation for the target parameter control triggered by the control editing page, that is, based on the configuration information obtained after the user modifies the right portion in fig. 7, and modify the previous configuration of the target parameter control based on the control configuration information. It should be noted that, in the embodiment of the present application, only a system administrator and a tool developer have rights to modify tool configurations, and each parameter control can be edited based on a control editing page, including setting a parameter name, a parameter verification rule, and previewing and confirming a configuration item. After the editing is finished, the interface debugging can be carried out on the parameter control.
Optionally, based on the connectivity detection module and the verification module in the configuration stage, connectivity detection and parameter verification are performed on the target interface server.
In the embodiment of the application, whether the interface service exists or is accessible is detected by testing the connectivity of the API interface, and the interface service can be specifically encoded by a request packet of curl, python. After the target interface service party is determined to be accessible, the preset test parameters input by the tool developer are verified based on the pre-configured parameter verification rule, so that the accuracy of parameter verification rule configuration is ensured.
After the configuration phase is completed, the testing phase may be entered, and the specific implementation manner is the steps shown in fig. 3, in addition, in the testing phase, before the interface test request is actually sent, the connectivity of the target interface service party may be tested again, and the interface test parameters input by the user are verified, which may be implemented based on the verification module in the testing phase shown in fig. 4A or fig. 4B, and whether the preset parameter verification rule is met is determined. If the target interface service party is not connected or the interface test parameters input by the user do not meet the check rule, an error can be actively reported to the user, and the user is prompted.
Specifically, after the target interface service party is determined to be accessible, the interface test parameters are verified according to the parameter verification rules in the parameter control corresponding to the interface test parameters, wherein the parameter verification rules in the parameter control are pre-configured based on the configuration stage, and if the tool developer updates the previously configured parameter verification rules through the control editing page, the parameter verification rules in the parameter control are the latest parameter verification rules.
In the embodiment of the application, when the interface test parameters are verified, the verification is mainly performed according to the parameter verification rules configured in advance between the interface test parameters and the interface test parameters. According to the above-mentioned exemplary embodiments, the following verification methods can be specifically used: regular expressions, code logic detection, third party interface detection, and the like.
After the interface is verified to be correct, an interface test request can be generated and can be realized based on a request module in a test stage. In this embodiment of the present application, the request related information specifically refers to a request header, a request URL, and the like, and the interface test parameter is mainly a merchant ID, and when the user inputs a certain merchant ID and clicks and submits according to the tool test page shown in fig. 8, the terminal device may generate an interface test request for the target interface according to the previously preconfigured request related information and the interface test parameter input by the user this time, and send the interface test request to the target interface service provider. After the terminal device receives the interface return information returned by the target interface service party, the interface return information may be further processed to form a test result, which is displayed in the tool test page shown in fig. 8, and this portion may be executed based on the result processing module in the test stage.
Optionally, the test result includes two parts, one part is an http status code requested to be returned, and the other part is an analysis result of response information.
The http state code has a standard, generally 200 indicates that the request service is successful, and the http state code used for indicating the interface response condition in the interface return information can be identified through regular expression analysis. In addition, the user can also configure the keywords, and each target keyword (key text description) used for expressing the interface calling result in the interface return information can be obtained in an AC automaton keyword string matching and analyzing mode; and finally, highlighting the http state code and the target keyword on a tool test page, namely, for example, highlighting the http state code and the target keyword as key information, and providing visual interface calling for a user.
The tool test page shown in fig. 8, the detailed log part of the page is used to show the test result, wherein: the tool execution result is successful, which is determined based on the http status code, and the http status code 200 may also be directly shown in fig. 8, and the query result is a text description of each target keyword obtained based on the matching of the keyword string of the AC automaton.
Each target keyword in fig. 8 specifically includes: merchant ID, merchant number, merchant name, merchant notes, employee system account ID, menu template ID, ctf merchant number, wxAPPID, wx notification group number, company name, company address, company email, company leader, customer service phone, contracted project name, merchant country area code, merchant privacy phone, merchant type, merchant attributes, merchant status, responsible BD, responsible operation, idempotent ID, verification mac (Media Access Control ), verification mac version, merchant creation time, and the like. In addition, the tool test page shown in fig. 8 further shows the tool usage and the tool notes, so that the user can know the test tool conveniently.
After the testing stage is finished, the tool stage can be entered, and after the configuration of the testing tool is finished, an applet with opening capability can be generated based on the tool generation module of the tool stage,
specifically, the testing tool in the embodiment of the present application may automatically store the previous configuration information in the database, assign an identification information, that is, a unique ID, to the configuration information through the tool generation stage, and generate a tool access entry for accessing a tool testing page under a domain name based on the identification information, where the access entry may be in the form of a link or a two-dimensional code.
When a user scans the two-dimensional code or clicks a search link, access operation can be triggered, and the terminal device responds to the access operation triggered by the tool access entry aiming at the target interface to display a tool test page.
Based on the implementation mode, the capability of the test tool in the embodiment of the application can be opened, other users can directly reuse the test tool, and repeated labor of other people is reduced.
It should be noted that, compared with fig. 4B, fig. 4A is different in the relationship between a tool phase and a test phase, the tool phase in fig. 4A may be implemented after the test phase, and the tool phase in fig. 4B is independent from the test phase and may be implemented after the configuration phase is completed.
It should be noted that the configuration module may be implemented by using various types of UI (User Interface) interaction and configuration files. The UI interaction forms include PC (Personal Computer) software, mobile phone side software, applet, H5 web, etc., and the configuration files include yaml configuration, general conf configuration. The request module may be implemented by using a programming language capable of initiating a network request, including C + +, java, php, and the like, which is not specifically limited herein.
Referring to fig. 9, it is a flowchart illustrating an implementation of the interface testing method according to the embodiment of the present application, and the specific implementation flow of the method is as follows:
step S91: acquiring configuration information related to the test of the target interface in response to tool configuration operation aiming at the target interface triggered by the tool configuration page;
step S92: and configuring request related information and parameter controls during testing according to the configuration information, wherein each parameter control corresponds to an interface test parameter related to the testing.
Optionally, the configuration information at least includes: tool configuration information and parameter configuration information;
configuring request related information and parameter controls during testing according to configuration information, specifically comprising:
acquiring request related information according to the tool configuration information, configuring the request related information, acquiring a parameter control required when a target interface is tested according to the parameter configuration information, and configuring the parameter control, wherein the parameter configuration information at least comprises a parameter verification rule used for verifying interface test parameters.
Optionally, the method further comprises:
responding to a preview operation triggered by a tool configuration page, and displaying a control editing page containing a configuration result of a parameter control;
acquiring control configuration information aiming at the target parameter control in response to the editing operation aiming at the target parameter control triggered by the control editing page;
and modifying the configuration of the target parameter control according to the control configuration information.
Optionally, after configuring the request related information and the parameter control during the test according to the configuration information, the method further includes:
and after the target interface server is determined to be accessible, checking the preset test parameters based on the parameter checking rule.
Optionally, the method further comprises:
storing the configuration information and distributing an identification information for the configuration information;
and generating a tool access entry for accessing the tool test page based on the identification information.
In the above embodiment, request-related information and some parameter controls may be preconfigured based on tool configuration information and parameter configuration information, and a two-dimensional code or a link, etc. is generated as an access entry by automatically storing the configuration information, so that the test tool in the present application has an open capability, that is, after a tool developer in the embodiment of the present application completes configuration and debugging of an interface, the capability may be opened, so that a user may directly reuse a corresponding test tool, thereby reducing the repeated labor of others.
In addition, in the configuration process, a corresponding parameter verification rule is further configured in the parameter control so as to verify the legality of the test request parameter input by the user, and the safety of the interface test is ensured.
It should be noted that, the specific implementation processes of the several alternative interface tool configuration methods can be referred to the above embodiments, and the limitations are not repeated here.
Referring to fig. 10, a flowchart of a complete method for testing an interface is shown, which is applied to theterminal device 210 shown in fig. 2. The specific implementation flow of the method is as follows:
step S101: responding to tool configuration operation aiming at a target interface triggered by a tool configuration page, and configuring request related information and parameter controls during testing according to configuration information input by a tool developer;
step S102: responding to preview operation triggered by a tool configuration interface, and displaying a control editing page containing a parameter control configuration result;
step S103: responding to the editing operation aiming at the target parameter control triggered by the control editing page, and modifying the configuration of the target parameter control according to the control configuration information aiming at the target parameter control and input by a tool developer;
step S104: after the configuration is finished, performing connectivity detection on a target interface;
step S105: after the target interface service party is determined to be communicated, checking preset test parameters input by a tool developer according to a pre-configured parameter checking rule;
step S106: responding to a test operation triggered by a tool test page aiming at a target interface, and acquiring interface test parameters aiming at the target interface determined based on a parameter control in the tool test page;
step S107: performing connectivity detection and parameter verification on a target interface server;
step S108: after the parameters are verified to be correct, generating an interface test request based on the pre-configured request related information and the interface test parameters, and sending the interface test request to a target interface server;
step S109: and acquiring interface return information returned by the target interface server, generating a test result based on the interface return information, and displaying the test result on a tool test page.
Based on the same inventive concept, the embodiment of the application also provides an interface testing device. As shown in fig. 11, which is a schematic structural diagram of an interface testing apparatus 1100 according to an embodiment of the present disclosure, the interface testing apparatus may include:
a first response unit 1101, configured to, in response to a test operation triggered by a tool test page for a target interface, obtain interface test parameters for the target interface determined based on parameter controls in the tool test page, where each parameter control corresponds to one interface test parameter related to a test;
the request unit 1102 is configured to generate an interface test request based on preconfigured request-related information and interface test parameters, and send the interface test request to a target interface server, where the request-related information and parameter control is preconfigured according to acquired configuration information related to the test of the target interface after responding to a tool configuration operation for the target interface triggered by a tool configuration page;
the displaying unit 1103 is configured to obtain interface return information returned by the target interface service provider, and display a test result generated based on the interface return information in a tool test page.
Optionally, the apparatus further comprises:
a first verifying unit 1104, configured to verify, before the requesting unit 1102 sends the interface test request to the target interface service party, after it is determined that the target interface service party is accessible, each interface test parameter according to a parameter verification rule in a parameter control corresponding to each interface test parameter, where the parameter verification rule in the parameter control is preconfigured according to the parameter configuration information in the configuration information.
Optionally, the test result includes an http status code and a target keyword; the presentation unit 1103 is specifically configured to:
analyzing and extracting an http state code used for representing an interface response condition in the interface return information through a regular expression, and performing keyword matching analysis through an AC automaton to obtain a target keyword used for representing an interface calling result in the interface return information;
and highlighting the http state code and the target keyword on a tool test page.
Optionally, the first response unit 1101 is further configured to:
and presenting the tool test page in response to an access operation triggered by a tool access entry aiming at the target interface, wherein the tool access entry is generated based on the identification information allocated for the configuration information.
In the above embodiment, an interface test state with an open capability is provided, and after the device performs an interface test, an http status code returned by the interface and detailed information of an interface response can be displayed, so that a display mode of the interface test is enriched, and a user can view the detailed information called by the interface more intuitively and conveniently.
Based on the same inventive concept, the embodiment of the application also provides an interface test tool configuration device. As shown in fig. 12, a schematic structural diagram of an interface testtool configuration apparatus 1200 according to an embodiment of the present disclosure may include:
a second response unit 1201, configured to obtain configuration information related to a test of the target interface in response to a tool configuration operation for the target interface triggered by the tool configuration page;
a configuration unit 1202, configured to configure, according to the configuration information, request-related information and parameter controls during testing, where each parameter control corresponds to an interface test parameter related to the testing.
A second response unit 1201, configured to obtain configuration information related to a test of the target interface in response to a tool configuration operation for the target interface triggered by the tool configuration page;
a configuration unit 1202, configured to configure, according to the configuration information, request-related information and parameter controls during testing, where each parameter control corresponds to an interface test parameter related to the testing.
Optionally, the configuration information at least includes: tool configuration information and parameter configuration information;
the configuration unit 1202 is specifically configured to:
acquiring request related information according to the tool configuration information, configuring the request related information, acquiring a parameter control required when a target interface is tested according to the parameter configuration information, and configuring the parameter control, wherein the parameter configuration information at least comprises a parameter verification rule used for verifying interface test parameters.
Optionally, the second responding unit 1201 is further configured to:
responding to a preview operation triggered by a tool configuration page, and displaying a control editing page containing a configuration result of a parameter control;
acquiring control configuration information aiming at the target parameter control in response to the editing operation aiming at the target parameter control triggered by the control editing page;
the configuration unit 1202 is further configured to:
and modifying the configuration of the target parameter control according to the control configuration information.
Optionally, the apparatus further comprises:
and a second checking unit 1203, configured to check the preset test parameters based on the parameter checking rule after the configuration unit 1202 configures the request related information and the parameter control during the test according to the configuration information and determines that the target interface server is accessible.
Optionally, the apparatus further comprises:
a tool generating unit 1204, configured to store the configuration information and assign an identification information to the configuration information;
and generating a tool access entry for accessing the tool test page based on the identification information.
In the above embodiment, request-related information and some parameter controls may be preconfigured based on tool configuration information and parameter configuration information, and a two-dimensional code or a link, etc. is generated as an access entry by automatically storing the configuration information, so that the test tool in the present application has an open capability, that is, after a tool developer in the embodiment of the present application completes configuration and debugging of an interface, the capability may be opened, so that a user may directly reuse a corresponding test tool, thereby reducing the repeated labor of others.
In addition, in the configuration process, a corresponding parameter verification rule is further configured in the parameter control so as to verify the legality of the test request parameter input by the user, and the safety of the interface test is ensured.
For convenience of description, the above parts are separately described as modules (or units) according to functional division. Of course, the functionality of the various modules (or units) may be implemented in the same one or more pieces of software or hardware when implementing the present application.
Having described the interface testing method and apparatus of the exemplary embodiments of the present application, an electronic device according to another exemplary embodiment of the present application is next described.
As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method or program product. Accordingly, various aspects of the present application may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.
Based on the same inventive concept, an embodiment of the present application further provides an electronic device, and fig. 13 is a block diagram of an electronic device 1300 shown according to an exemplary embodiment, including:
aprocessor 1310;
amemory 1320 for storing program code executable by theprocessor 1310;
wherein theprocessor 1310 is configured to execute the program code to implement the steps in the interface test method according to various exemplary embodiments of the present application or the steps in the interface test tool configuration method according to various exemplary embodiments described in the present specification. For example,processor 1310 may perform the steps as shown in fig. 3 or the steps shown in fig. 9.
In an exemplary embodiment, a storage medium comprising program code, such as thememory 1320 comprising program code, executable by theprocessor 1310 of the electronic device 1300 to perform the above-described method is also provided.
Alternatively, the storage medium may be a non-transitory computer readable storage medium, for example, the non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.
In some possible implementations, the present application embodiments also provide a computer program product or a computer program comprising computer instructions stored in a computer-readable storage medium. The computer instructions are read by a processor of a computer device from a computer-readable storage medium, and the computer instructions are executed by the processor to cause the computer device to perform the steps provided in any of the above-described interface test methods or any of the various alternative implementations of the interface test tool configuration method, such as the steps shown in fig. 3 or fig. 9.
In some possible embodiments, the various aspects of the interface testing method or the interface testing tool configuration method provided in the present application may also be implemented in the form of a program product including program code for causing a computer device to perform the steps in the interface testing method according to various exemplary embodiments of the present application described above in this specification when the program product is run on the computer device, for example, the computer device may perform the steps as shown in fig. 3 or fig. 9.
The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
The program product of embodiments of the present application may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a computing device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with a command execution system, apparatus, or device.
A readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with a command execution system, apparatus, or device.
Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.