CN113886216B - Interface test and tool configuration method, device, electronic equipment and storage medium - Google Patents
- ️Tue Sep 17 2024
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the technical solutions of the present application, but not all embodiments. All other embodiments, based on the embodiments described in the present document, which can be obtained by a person skilled in the art without any creative effort, are within the scope of protection of the technical solutions of the present application.
Some of the concepts involved in the embodiments of the present application are described below.
Form: the webpage is mainly responsible for the data acquisition function. A form has three basic components: form label: this includes the URL of the CGI (Common GATEWAY INTERFACE ) program used to process the form data and the method of submitting the data to the server.
AC (Aho-Corasick automaton, multimode matching algorithm) automaton: the matching method is mainly used for solving the matching problem of the multi-mode strings, and is a variant of a dictionary tree (trie tree), a pseudo tree structure (a main body is tree-shaped, but a failure pointer is added, so that the tree structure becomes a directed graph); a trie diagram is a modification to an AC automaton such that each node in the diagram has MAXC bar edges (MAXC represents the character set size of the diagram), each node on the trie diagram represents a state, and is in one-to-one correspondence with the nodes of the AC automaton. The AC automaton is to add a fail pointer on the basis of a tree, and if the current point matching fails, the pointer is transferred to the place pointed by the fail pointer, so that trace back is not needed, and the path matching can be performed. 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 can be 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: 1. message: this type of status code, representing that the request has been accepted, requires continued processing. 2. Success: this type of status code represents that the request has been successfully received, understood, and accepted by the server. 3. Redirecting: such status codes represent the need for further actions by the client to complete the request. Typically, these status codes are used to redirect, with subsequent request addresses (redirect targets) indicated in the Location field of the current response. 4. Request errors: such status codes represent that the client may appear to have errors that prevent processing by the server. 5. Server error: the status codes (5, 6 headers) represent that the server has an error or abnormal status in the process of processing the request, and the server may realize 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.
Reuse: refers to the fact that the same thing is repeatedly used in different environments without modification or slight change. Reusability refers to the property of being reusable. The testing tool in the embodiment of the application has reusability, can be an applet with opening capability, and can directly access the tool testing page of the testing tool by scanning the two-dimensional code or based on links and the like to further test the target interface.
Tool configuration page: the interface is a user-oriented page for configuring the test tool, and through the interface, a user can edit various configuration information so as to debug and toolate the API. Wherein the configuration information includes tool configuration information, parameter configuration information, and the like. In embodiments of the present application, the tool configuration information may include a tool name, a category, a developer, a request URL (i.e., interface API), a use, a remark, etc.; the parameter configuration information is used for configuring parameter controls required by the interface request, and specifically comprises configuration of parameter names, parameter checking rules, control types, control names and the like, wherein the control types comprise text boxes, multi-row text boxes, single selection boxes, multi-selection boxes, drop-down boxes and the like.
Control edit page: the user-oriented page is used for configuring the parameter control, through which the user can preview various configuration information related to the parameter control, and edit and modify various configuration information, wherein the various configuration information comprises parameter names, parameter verification rules, control types, control names and the like.
Tool test page: the interface testing system is a user-oriented page for testing the interface, and the user can input various interface testing parameters through the page, and can generate an interface testing request for accessing the interface service based on various interface testing parameters input by the user and the pre-configured request related information. In addition, after the target interface is tested, the test result can be further displayed in the page. In the embodiment of the application, the test result can be divided into two parts: an http status code for representing the interface response situation and a target keyword for representing the interface call result.
A main key: a primary key (PRIMARY KEY) is one or more fields in the table whose value is used to uniquely identify a record in the table. In the relationship of two tables, a primary key is used to reference a particular record in one table from the other table. The primary key is a unique key, 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, respectively referred to as a single-field primary key or a multi-field primary key. Also known as the primary code. And it may uniquely identify a row of data in the table or may uniquely identify an entity.
The following briefly describes the design concept of the embodiment 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 conform to 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 interfaces include a chrome browser plug-in TALEND API TESTER, a chrome browser plug-in post man and the like. These test tools all use forms to fill out the parameters required by the API interface requests through the visual interface. For example, as shown in fig. 1, a schematic diagram of a test interface of the chrome browser plug-in TALEND API TESTER 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, selection of an http request method, for example, a POST request method (or a GET request method), is involved, and after a user inputs a request URL, a request Header, and a request BODY, clicking a Send button in fig. 1 can Send a request to an interface service and test the interface.
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 according to the returned information of the http state code on the interface, and the success and the failure of the request can not be flexibly judged by combining the returned information of the interface. For example, as shown in fig. 1, the http status code is "302 Found" indicating that the server is currently responding to requests from web pages in different locations, but the requestor should continue to use the original location for future requests.
Aiming at the testing tools in the related technology, the method only can debug the API, cannot check the validity of the request parameters of the API, cannot provide the open applet tool capability, can only display the http state code, and has single display result.
In view of this, the embodiments of the present application provide an interface testing and tool configuration method, apparatus, electronic device, and storage medium. The interface testing tool in the embodiment of the application can be a specific open capability applet, 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 validity of request parameters for the API interface and generate a tooled call link for the API interface. Specifically, based on API interface configuration information set by a tool developer, request related information and parameter control related to a target interface are configured in advance, corresponding parameter verification rules are configured in the parameter control, based on the test tool, a request can be initiated to the target interface, response conditions of the target interface are checked, target interface behaviors are verified, and in addition, based on a tool test page, visual target interface calling can be provided for a user, and a test method with higher safety, expansibility and reusability is provided.
The preferred embodiments of the present application will be described below with reference to the accompanying drawings of the specification, it being understood that the preferred embodiments described herein are for illustration and explanation only, and not for limitation of the present application, and embodiments of the present application and features of the embodiments may be combined with each other without conflict.
Fig. 2 is a schematic diagram of an application scenario according to an embodiment of the present application. The application scenario diagram includes two terminal devices 210 and a server 230, and the relevant page 220, such as a tool configuration page, a tool test page, etc. in the embodiment of the present application, can be logged in through the terminal devices 210. Communication between the terminal device 210 and the server 230 may be through a communication network. One user corresponding to each terminal device, in fig. 2, is taken as an example of one terminal device 210 corresponding to each of the user a and the user B, and the number of terminal devices is not limited in practice. In some cases, the terminal devices may communicate with each other via the server 230, direct communication may be established from terminal device to terminal device, and the manner in which the terminal devices communicate directly from terminal device to terminal device may be referred to as point-to-point communication, in which case some interaction between the terminal devices may not require the transfer of the server 230.
The client of the testing tool provided in the embodiment of the application can be installed in each terminal device. The client related to the embodiment of the application can be a preinstalled client, a client (such as an applet) embedded in a certain application, or a client of a webpage version, and the specific type of the client is not limited. When the terminal device 210 transmits the interface test request, that is, when it needs to communicate with the server 230 via the communication network, it also needs to communicate via the communication network when it receives the interface return information returned from the server 230.
In an alternative embodiment, the communication network is a wired network or a wireless network. The terminal 210 and the server 230 may be directly or indirectly connected through wired or wireless communication, and the present application is not limited thereto.
In the embodiment of the present application, the terminal device 210 is an electronic device used by a user, and the electronic device may be a computer device having a certain computing capability, such as a personal computer, a mobile phone, a tablet computer, a notebook, an electronic book reader, etc., and running instant messaging software and a website or social software and a website. Each terminal device 210 is connected to the server 230 through a wireless network, where the server 230 may be an independent physical server, or may be a server cluster or a distributed system formed by a plurality of physical servers, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network ), and basic cloud computing services such as big data and an artificial intelligent platform. The terminal may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the present application is not limited herein.
Referring to fig. 3, a flowchart of an implementation of an interface testing method according to an embodiment of the present application is shown, where the 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 and determined based on parameter controls in the tool test page, wherein each parameter control corresponds to one interface test parameter related to the test;
step S32: generating an interface test request based on preconfigured request related information and interface test parameters, and sending the interface test request to a target interface service side, wherein the request related information is preconfigured according to the acquired configuration information related to the test of the target interface after responding to tool configuration operation of the target interface triggered by a tool configuration page;
The target interface in the embodiment of the application can be an http/https API interface of a Web (World Wide Web) end, and the target interface service party can refer to a corresponding Web server.
Step S33: and acquiring interface return information returned by the target interface service side, 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 testing of the target interface and the parameter control in the tool test page are both preconfigured, and for the target interface, the test tool in the embodiment of the present application is a reusable and expandable test tool, and before implementing step S31, the test tool provided in the embodiment of the present application needs to be configured through a configuration stage first, after the configuration is completed, the user can use the test tool to test the target interface, and the test process is shown in steps S31 to S33. The following describes the interface test mode and the configuration method of the interface test tool in the embodiment of the present application in detail with reference to fig. 4A and fig. 4B:
Referring to fig. 4A and 4B, two alternative schematic diagrams of a system frame according to an embodiment of the present application are mainly divided into three stages: configuration phase, test phase and tool phase. The configuration stage specifically comprises a configuration module, a connectivity detection module and a verification module; the testing stage specifically comprises a request module, a verification module and a result processing module; the tool phase mainly includes a tool generation module.
The configuration phase is first described in detail below:
Specifically, the user can input configuration information for the target interface in the tool configuration page, and the terminal equipment responds to tool configuration operation for the target interface triggered by the tool configuration page to acquire configuration information related to testing of the target interface; further, the terminal device can configure the request related information and the parameter control according to the configuration information when testing, so as to realize specific opening capability and reusability.
In the embodiment of the application, each parameter control corresponds to an interface test parameter related to a test. 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, the method is mainly divided into two parts:
1. Acquiring and configuring request related information when testing a target interface according to tool configuration information set by a tool developer;
Specifically, the tool configuration information includes: the tool name, tool classification, developer, request URL (i.e. interface API), use, 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.
2. And acquiring parameter controls required by testing the target interface according to the parameter configuration information set by the tool developer, and configuring the parameter controls.
Specifically, the parameter configuration information is used for configuring parameter controls 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.
The control types include text boxes, multi-line text boxes, single boxes, multi-boxes, drop-down boxes, and the like.
Specifically, the text box may directly input text, the multi-line text box may input multi-line text, the drop-down box may display a list of drop-down selections, the single box indicates that only one item of the attribute values may be selected, i.e., only one item may be selected, and the multiple boxes indicate that multiple items of the attribute values may be selected, i.e., multiple items may be selected.
It should be noted that, the foregoing embodiments are only some of the control types, and virtually any control type is applicable to the embodiments of the present application, which is not limited herein.
In the embodiment of the application, the configuration process is realized based on a configuration module in a configuration stage, and configuration information required by an interface request can be configured and stored through the configuration module, wherein the configuration information comprises a request URL, a request header, a request parameter, a parameter verification rule and the like. 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, JS object numbered musical notation) configuration.
Fig. 5 is a schematic diagram of a tool configuration page according to an embodiment of the present application. In the page shown in fig. 5, the tool developer can directly input tool configuration information and parameter configuration information to be filled in the text box corresponding to each item of configuration information shown in fig. 5, and debug and tooled configuration is performed on the API. The tool configuration information and the parameter configuration information set by the tool developer are 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 merchant detailed information; correspondingly, the starting state of the tool can be further set, when the tool developer sets the starting state as 'in configuration', the state indicates that the test tool is still in the configuration stage at present and is not opened to the outside, and when the tool developer sets the starting state as 'in configuration', the test tool can be opened to the outside, and the state indicates that the tool is ready and can be provided for a user;
2) Tool classification: the configuration item can be filled in directly by a tool developer. In addition, configuration may not be performed, and "unclassified" is defaulted at this time;
3) The developer: the configuration item is directly filled by a tool developer;
4) Service side request URL: the configuration item is also directly filled by the tool developer, and represents the link corresponding to the target interface, as shown in fig. 5, the request URL filled by the tool developer is:
/mchaccount/tool/get_merchant_by_id。
in the testing stage, an interface testing request can be sent to a target interface service side based on the URL, and the target interface is tested. The request mode of the interface test request can be as follows: the GET request method or POST request method, here, may be configured by the tool developer, or may be selected autonomously by the user during the test phase.
5) Tool use: as can be seen from FIG. 5, the purpose of the test tool is to query merchant detailed information;
6) Tool remarks: as can be seen from FIG. 5, the remark of the testing tool is to call the WeChat payment merchant svrkit interface to query merchant detailed information. < br > < br > jumps to < ahref = ' http:// testaccountxxxxxxx/tool/detailFToolID = 10' blank ' > modify merchant relationship.
Wherein, based on the tool configuration information, it can be determined that, for this target interface for querying merchant detailed information, the request related information includes request URL (/ mchaccount/tool/get_ merchant _by_id), request header, and the like.
The parameter configuration information is used for configuring parameter controls, and specifically comprises control types, control configuration, whether a main key is used for configuring the control types, and a plurality of configuration items for operating the control types.
1) The control types include: a text box, a plurality of lines of text boxes, a single selection box, a plurality of selection boxes, a drop-down box, etc., and the tool developer can display other selectable control types by clicking the drop-down key shown in fig. 5, for example, as shown in fig. 6, the control type of the parameter control with the current serial number of 1 is the text box.
The selection of the control type is mainly based on the interface test parameters corresponding to the parameter control, for example, when the interface test parameters are merchant IDs, the user needs to fill in the interface test parameters by himself, and the control type of the corresponding parameter control is generally a text box; when the interface test parameter is still a merchant ID, but several optional candidate merchant IDs are preconfigured, the control type of the corresponding parameter control may be a single box, and so on.
2) Control configuration: the method mainly refers to detailed configuration information of parameter controls, including parameter names, parameter verification rules, control names and the like, and can be filled in by tool developers. For example, as shown in fig. 5, the parameter controls for a text box type with sequence number 1 filled in by the tool developer, and specific control configurations include:
{ "order" 1, "widget_type" text, "" widget_label "merchant ID," "widget_ remark" must fill, please enter merchant macid, example: 9xx "," param_name ":" merchant _id "," is_required ": 1", "do_check":1 "," check_regex ":"/[ 1-9] [0-9] $/"}.
Wherein, the control configuration column contains 8 configuration items in total, as follows:
"order" 1, the number is 1;
"widget_type": text ", indicating that the control type is text;
"Widget_label" means "merchant ID" indicating that the control tag is the merchant ID, that is, the Chinese name of the control is the merchant ID;
"widget_ remark" must fill, please enter merchant macid, example: 9xx ", indicating that the control remark is" must fill, "please enter merchant macid, example: 9xx ";
"param_name" means "merchant _id" indicating that the parameter name is merchant _id;
"is_required" 1, which indicates whether the necessary entry is 1, that is, the request test parameter corresponding to the parameter control, that is, the merchant ID is the necessary entry;
"do_check" 1, which indicates whether the check term is 1, that is to say, the request test parameter corresponding to the parameter control needs to be checked;
"check_regex": "/[ 1-9] [0-9] $/", indicating (parameter) check rules as follows: and/[ 1-9] [0-9] $/.
In the embodiment of the application, the interface test parameters generally have a value range, a field type and the like, and 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 verification of the interface test parameters can be realized based on the configuration of the parameter verification rules, and compared with the mode that the validity of the API request parameters cannot be verified in the related art, the safety and the reliability of the interface test can be effectively improved.
The parameter verification rules enumerated in the above embodiments are in the form of regular expressions for detecting whether the merchant ID meets the ID rules. In addition, the parameter verification rule may be set by means of code logic detection, third party interface detection, etc., which is not limited herein.
3) Whether the primary key: and indicating whether the interface test parameter corresponding to the parameter control is a primary key. When the tool is configured, an account primary key is required to be designated and used for recording which account is operated, and follow-up checking of account operation running water is also facilitated.
4) The operation is as follows: the tool developer may also configure the parameter control related operations based on the configuration item.
It should be noted that, all tool operations in the embodiments of the present application will be requested by the tool platform listed in the present application from the back end, and call the service interface to complete the account operation. The tool platform listed in the application records the operation of the user on the account. Furthermore, only system administrators and tool developers have the right to modify the tool configuration.
Optionally, after configuring the request related information and the parameter control required when testing the target interface based on the configuration information set by the user configuring the page through the tool, the configuration of the parameter control may be previewed and modified by clicking the 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 a control editing page containing parameter control configuration results.
For example, fig. 7 is a schematic diagram of a control editing page according to an embodiment of the present application. The configuration results in the parameter controls configured in the process are shown in detail in the figure, and specifically comprise the serial numbers of the parameter controls, the control types, the Chinese names of the controls, the remarks of the controls, the parameter names, whether filling is needed, whether checking is needed, the checking rules and the like.
As can be seen from fig. 7, the serial number is 1, the control type is text (text box), the chinese name of the control is merchant ID, and the remarks of the control are: must 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 necessary filling item, whether verification is needed, and the like can be further set, and if verification is needed, a corresponding verification rule is further set.
Wherein, the parameter to be filled of the parameter control with the serial number of 1 is the merchant ID, and the "whether to fill" item is 1 indicates that the parameter is a filling item (when 0, the parameter is a non-filling item); further, a "check or not" item of 1 indicates that the parameter needs to be checked (likewise, when 0, it indicates that the parameter does not need to be checked).
In the embodiment of the present application, the user can edit the page through the control shown in fig. 7 to further modify the parameter control previously configured according to the parameter configuration information. For example, the user is currently modifying the configuration item "control remark" in the "text box" type control, specifically, after clicking the configuration item "control remark" in the left side of fig. 7, the user may modify the configuration item by editing the content in the text box corresponding to the merchant ID in the right side part of fig. 7, and after the modification is completed, clicking the determination button shown in fig. 7 may trigger the configuration modification of the configuration item.
Specifically, the terminal device responds to the editing operation of the target parameter control triggered by the control editing page, and then can acquire control configuration information of the target parameter control, namely, configuration information obtained after the user passes through the right part in fig. 7 is based on the control configuration information, and the configuration of the target parameter control is modified based on the control configuration information. It should be noted that, in the embodiment of the present application, only the system administrator and the tool developer have the right to modify the tool configuration, each parameter control can be edited based on the control editing page, including setting a parameter name and a parameter verification rule, and the configuration items can be previewed and confirmed. After the editing is finished, the parameter control can be subjected to interface debugging.
Optionally, based on the connectivity detection module and the verification module in the configuration stage, the connectivity detection and the parameter verification are performed on the target interface server.
In the embodiment of the application, by testing the connectivity of the API interface, whether the interface service exists or not and whether the interface service is accessible or not is detected, and the interface service can be specifically realized by coding a request packet of a curl, python. After the target interface service side is determined to be accessible, the preset test parameters input by the tool developer are checked based on the preset parameter check rules, so that the accuracy of parameter check rule configuration is ensured.
After the configuration phase is finished, the test phase can be entered, and the specific implementation manner is shown in the step shown in fig. 3, in addition, in the test phase, before the interface test request is actually sent out, the connectivity of the target interface server can be tested again, the interface test parameters input by the user are checked, and the test phase can be implemented based on the check module shown in fig. 4A or fig. 4B, so that whether the preset parameter check rule is met or not is judged. If the target interface service side is not communicated or the interface test parameters input by the user do not meet the check rules, the user can be actively informed of errors and prompted.
Specifically, after the target interface service side is determined to be accessible, each interface test parameter is checked according to a parameter check rule in a parameter control corresponding to each interface test parameter, wherein the parameter check rule in the parameter control is pre-configured based on the process of the configuration stage, and if a tool developer updates the parameter check rule configured before through a control editing page, the parameter check rule in the parameter control is the latest parameter check rule.
In the embodiment of the application, when the interface test parameters are verified, the verification is mainly performed according to the parameter verification rules pre-configured among the interface test parameters. According to the above-listed embodiments, the following verification methods may be specifically mentioned: regular expressions, code logic detection, third party interface detection, and the like.
After verification, the interface test request can be generated, and can be realized based on the request module in the test stage. In the embodiment of the present application, the request related information specifically refers to a request header, a request URL, etc., and the interface test parameters are mainly merchant IDs, and when a 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 request related information configured in advance and the interface test parameters input by the user this time, and send the interface test request to the target interface service side. After the terminal device receives the interface return information returned by the target interface service side, the interface return information can be further processed to form a test result, the test result is displayed in a tool test page shown in fig. 8, and the test result can be executed based on a result processing module in a test stage.
Optionally, the test result includes two parts, one part is an http status code returned by the request, and the other part is an analysis result of response information, where in the embodiment of the present application, the analysis result of response information mainly refers to a target keyword used for representing an interface call result.
The http status code has a standard, generally 200 indicates that the request service is successful, and the http status code used for indicating the response condition of the interface in the interface return information can be identified by a regular expression analysis mode. In addition, the user can configure the keywords, and each target keyword (keyword text description) used for representing the interface calling result in the interface return information can be obtained through the method of matching and analyzing the keyword strings of the AC automaton; finally, the http state code and the target keyword are highlighted on the tool test page, namely, are highlighted and coarsely displayed as key information, and visual interface call is provided for a user.
The tool test page as shown in fig. 8, the detailed log part in the page is used for showing the test result, wherein: the successful tool execution result is determined based on the http state code, and the http state code 200 can also be directly displayed in fig. 8, and the query result is the text description of each target keyword obtained based on the matching of the keyword strings of the AC automaton.
Wherein, each target keyword in fig. 8 specifically includes: the merchant ID, the merchant number, the merchant name, the merchant remark, the employee system account ID, the menu template ID, ctf merchant number, wxAPPID, the wx notification group number, the company name, the company address, the company email, the company responsible person, the customer service phone, the contracted item name, the merchant country area code, the merchant security handset, the merchant type, the merchant attribute, the merchant status, the responsible BD, the responsible operation, the idempotent ID, verification mac (MEDIA ACCESS Control ), verification mac version, the merchant creation time, and the like. In addition, the tool test page shown in fig. 8 further shows tool uses and tool notes, so that the user can know the test tool conveniently.
After the test phase is completed, the tool phase can be entered, after the configuration of the test tool is completed, an applet with open capability can be generated based on the tool generation module of the tool phase,
Specifically, the testing tool in the embodiment of the application can automatically store the previous configuration information into the database, allocate an identification information, namely a unique ID, to the configuration information through the tool generation stage, and generate a tool access entry for accessing the testing page of the tool under a domain name based on the identification information, wherein the access entry can be in the form of a link or a two-dimensional code.
When a user scans a two-dimensional code or clicks a search link, the access operation can be triggered, and the terminal equipment responds to the access operation triggered by the tool access entrance aiming at the target interface and displays a tool test page.
Based on the implementation manner, the capability of the testing tool in the embodiment of the application can be opened, other users can directly reuse the testing tool, and the repeated labor of other people is reduced.
It should be noted that, in fig. 4A, compared to fig. 4B, the difference is that the relationship between the tool stage and the test stage is that the tool stage in fig. 4A may be implemented after the test stage, while the tool stage is independent from the test stage in fig. 4B, and may be implemented after the configuration stage is completed, in this embodiment of the present application, both the two ways may be implemented, and the tool test page in step S31 may be obtained by directly jumping after the configuration stage is completed, or may be entered through a scan access portal after the access portal is generated based on the tool stage, which is not limited specifically herein.
It should be noted that, the configuration module may be implemented by adopting various types of UI (User Interface) interactions and configuration files. The UI interaction forms include PC (Personal Computer ) software, cell phone side software, applet, H5 web, etc., and the configuration files include yaml configuration, general conf configuration. The request module may be implemented in a programming language capable of initiating a network request, including c++, java, php, etc., and is not specifically limited herein.
Referring to fig. 9, a flowchart of an implementation of an interface testing method according to an embodiment of the present application is shown, where the implementation flow of the method is as follows:
Step S91: responding to tool configuration operation for the target interface triggered by the tool configuration page, and acquiring configuration information related to testing of the target interface;
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 testing parameter related to testing.
Optionally, the configuration information at least includes: tool configuration information and parameter configuration information;
the method for configuring the request related information and the parameter control during testing according to the configuration information specifically comprises the following steps:
Acquiring and configuring related information of a request according to tool configuration information, and acquiring and configuring parameter controls required by testing a target interface according to parameter configuration information, wherein the parameter configuration information at least comprises parameter verification rules for verifying testing parameters of the interface.
Optionally, the method further comprises:
responding to a preview operation triggered by the tool configuration page, and displaying a control editing page containing configuration results of parameter controls;
responding to the editing operation for the target parameter control triggered by the control editing page, and acquiring control configuration information for the target parameter control;
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 in the test according to the configuration information, the method further includes:
And after determining that the target interface service party can access, checking the preset test parameters based on the parameter checking rule.
Optionally, the method further comprises:
storing configuration information and distributing an identification information for the configuration information;
a tool access entry for accessing the tool test page is generated based on the identification information.
In the above embodiment, the request related information and some parameter controls may be pre-configured based on the tool configuration information and the parameter configuration information, and by automatically storing these configuration information, a two-dimensional code or link is generated as an access entry, so that the test tool in the present application has an open capability, that is, after the tool developer completes configuration and debugging of an interface in the embodiment of the present application, the capability may be opened, so that the user may directly reuse the corresponding test tool, and reduce the repeated labor of others.
In addition, in the configuration process, a corresponding parameter verification rule is further configured in the parameter control, so that validity verification is conducted on the request test parameters input by the user, and the safety of interface test is guaranteed.
It should be noted that, the specific implementation of the above-mentioned several alternative interface tool configuration methods may be referred to the above-mentioned embodiments, and are not repeated here.
Referring to fig. 10, a flowchart of a complete method of interface testing is shown, which is applied to the terminal device 210 shown in fig. 2. The specific implementation flow of the method is as follows:
Step S101: responding to tool configuration operation for a target interface triggered by a tool configuration page, and configuring request related information and parameter controls when testing according to configuration information input by a tool developer;
step S102: responding to a preview operation triggered by a tool configuration interface, and displaying a control editing page containing parameter control configuration results;
Step S103: responding to the editing operation for 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 for the target parameter control input by the tool developer and the control configuration information;
Step S104: detecting connectivity of the target interface after configuration is completed;
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 preset parameter checking rule;
Step S106: responding to a test operation triggered by a tool test page for a target interface, and acquiring interface test parameters for the target interface, which are determined based on parameter controls in the tool test page;
step S107: performing connectivity detection and parameter verification on a target interface server;
Step S108: after the parameter is checked 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 service side;
step S109: and acquiring interface return information returned by the target interface service side, generating a test result based on the interface return information, and displaying the test result on the 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 application, the interface testing apparatus may include:
a first response unit 1101, configured to obtain, in response to a test operation triggered by a tool test page for a target interface, interface test parameters for the target interface determined based on parameter controls in the tool test page, where each parameter control corresponds to an 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 service side, where the request related information and the parameter control are preconfigured according to the acquired configuration information related to testing of the target interface after responding to a tool configuration operation for the target interface triggered by a tool configuration page;
and the display unit 1103 is configured to obtain the interface return information returned by the target interface server, and display the test result generated based on the interface return information in the tool test page.
Optionally, the apparatus further comprises:
The first verification unit 1104 is configured to verify each interface test parameter according to a parameter verification rule in a parameter control corresponding to each interface test parameter after determining that the target interface service is accessible before the request unit 1102 sends the interface test request to the target interface service, where the parameter verification rule in the parameter control is preconfigured according to parameter configuration information in the configuration information.
Optionally, the test result includes an http status code and a target keyword; the display unit 1103 is specifically configured to:
Extracting an http state code used for representing the interface response condition in the interface return information through regular expression analysis, and obtaining a target keyword used for representing the interface calling result in the interface return information through keyword matching analysis of the AC automaton;
And highlighting the http status code and the target keyword on the tool test page.
Optionally, the first response unit 1101 is further configured to:
in response to an access operation triggered by a tool access entry to the target interface, a tool test page is presented, wherein the tool access entry is generated based on identification information assigned for the configuration information.
In the embodiment, the interface test parameters input by the user can be checked, and the interface test state with the opening capability is provided, in addition, after the interface test is performed based on the device, the http state code returned by the interface and the detailed information of the interface response can be displayed, so that the display mode of the interface test is enriched, and the user can more intuitively and conveniently check the detailed information of the interface call.
Based on the same inventive concept, the embodiment of the application also provides an interface test tool configuration device. As shown in fig. 12, which is a schematic structural diagram of an interface test tool configuration apparatus 1200 according to an embodiment of the present application, the interface test tool configuration apparatus 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;
The configuration unit 1202 is configured to configure the request related information and the parameter controls when testing according to the configuration information, where each parameter control corresponds to an interface test parameter related to the test.
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;
The configuration unit 1202 is configured to configure the request related information and the parameter controls when testing according to the configuration information, where each parameter control corresponds to an interface test parameter related to the test.
Optionally, the configuration information at least includes: tool configuration information and parameter configuration information;
the configuration unit 1202 is specifically configured to:
Acquiring and configuring related information of a request according to tool configuration information, and acquiring and configuring parameter controls required by testing a target interface according to parameter configuration information, wherein the parameter configuration information at least comprises parameter verification rules for verifying testing parameters of the interface.
Optionally, the second response unit 1201 is further configured to:
responding to a preview operation triggered by the tool configuration page, and displaying a control editing page containing configuration results of parameter controls;
responding to the editing operation for the target parameter control triggered by the control editing page, and acquiring control configuration information for the target parameter control;
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:
The second checking unit 1203 is configured to, after the configuration unit 1202 configures the request related information and the parameter control during testing according to the configuration information, determine that the target interface service party can access, and check the preset test parameter based on the parameter checking rule.
Optionally, the apparatus further comprises:
A tool generating unit 1204, configured to store configuration information and allocate an identification information to the configuration information;
a tool access entry for accessing the tool test page is generated based on the identification information.
In the above embodiment, the request related information and some parameter controls may be pre-configured based on the tool configuration information and the parameter configuration information, and by automatically storing these configuration information, a two-dimensional code or link is generated as an access entry, so that the test tool in the present application has an open capability, that is, after the tool developer completes configuration and debugging of an interface in the embodiment of the present application, the capability may be opened, so that the user may directly reuse the corresponding test tool, and reduce the repeated labor of others.
In addition, in the configuration process, a corresponding parameter verification rule is further configured in the parameter control, so that validity verification is conducted on the request test parameters input by the user, and the safety of interface test is guaranteed.
For convenience of description, the above parts are described as being functionally divided into modules (or units) respectively. Of course, the functions of each module (or unit) may be implemented in the same piece or pieces of software or hardware when implementing the present application.
Having described the interface testing method and apparatus of an exemplary embodiment of the present application, next, an electronic device according to another exemplary embodiment of the present application is described.
Those skilled in the art will appreciate that the various aspects of the application may be implemented as a system, method, or program product. Accordingly, aspects of the application may be embodied in the following forms, namely: an entirely hardware embodiment, an entirely software embodiment (including firmware, micro-code, etc.) or an embodiment combining hardware and software aspects may 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 according to an exemplary embodiment, including:
a processor 1310;
a memory 1320 for storing executable program code for the processor 1310;
Wherein the processor 1310 is configured to execute program code to implement steps in the interface test method according to various exemplary embodiments of the present application or steps in the interface test tool configuration method according to various exemplary embodiments described in this specification. For example, the processor 1310 may perform steps as shown in fig. 3 or steps as shown in fig. 9.
In an exemplary embodiment, a storage medium is also provided, such as a memory 1320, including program code that is executable by the processor 1310 of the electronic device 1300 to perform the above-described methods.
Alternatively, the storage medium may be a non-transitory computer readable storage medium, for example, a ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like.
In some possible implementations, the present 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 from the computer-readable storage medium by a processor of a computer device, and executed by the processor, cause the computer device to perform the steps provided in various alternative implementations of any of the interface test methods or any of the interface test tool configuration methods described above, such as the steps shown in fig. 3 or 9.
In some possible embodiments, aspects of the interface test method or interface test tool configuration method provided by the present application may also be implemented in the form of a program product comprising program code for causing a computer device to perform the steps of the interface test method according to various exemplary embodiments of the present application as described herein above when the program product is run on the computer device, e.g. the computer device may perform the steps as shown in fig. 3 or 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. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk 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 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.
The readable signal medium may include a data signal propagated in baseband or as part of a carrier wave with readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. 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 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. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.