Apikit self-study diary: initiate document test-HTTP

HTTP

Function entry : API management application / select a project / API document menu / select an API document / click "Test" TAB

The API document test page can quickly test the interface described in the API document. The API document test page is divided into four parts: the address control bar, the request control area, the return display area, and the test aid area.

 

1. Address control bar

At the top of the test page is the address control bar. The interface protocol is fixed and cannot be changed, but the interface request method and interface address URL can be adjusted.

 

1. Interface test URL adjustment

Click Switch Environment in the upper right corner of this page , and the system will automatically fill in the domain name or IP to URL address prefix of the environment. Users can also directly fill in the domain name or IP in the address bar for testing.

2. Import or save as a test case

The first button next to the URL edit bar can quickly import old test cases or save them as new test cases.

Click this button to select an existing test case of the current interface to import with one click for testing, or save the currently debugged request data as a new test case.

3. Test the send button

On the right side of the test case quick action button is the send button of the current test, which is highlighted, and the button color follows the theme color. After clicking the send button, a request will be initiated to the interface based on the request data. After launching, the system will start to count down the seconds, showing that the test has elapsed time.

The send button can choose two test modes: server test and browser plug-in test .

If server test is selected , the test operation resource is the remote server resource of the eolink system. On Eolink's SaaS product, because multiple teams share a set of resources, the test request increases the limit. If the interface test takes more than 10 seconds, the test task will be terminated automatically, and the interface timeout information will be returned.

If the browser plug-in test is selected , the test running resource is the user's local machine. But to use this mode, you need to follow the instructions to install the browser plug-in. On the PC client, the plug-in itself has been integrated in the client framework, no need to download and install, just switch and use it directly.

4. Cookie management tool

During the test, multiple different cookies will be used, and the cookie management tool can quickly solve this problem. Users can click the cookie management tool button in the upper right corner of the test page to open the management window.

In the cookie management window, first add the corresponding domain name address, and then add multiple cookie values ​​to the domain name address. When performing an interface test, if the request is for the corresponding domain name address, the system will automatically attach all cookie values ​​under the domain name address to the request header.

 

2. Request control area

The content in the API document will be automatically synchronized to the request control area of ​​the test page, so the request control area is basically the same as the request parameter input area of ​​the API document edit page. There are request headers, request bodies, query parameters, REST parameters, permission verification, pre-scripts, and post-scripts. The API test page will add advanced settings for the test.

 

Therefore, for the basic operations of the request control area, please refer to the "Request Parameters" chapter in "Edit API Documentation" . The following only describes what needs to be paid attention to when testing.

1、Content-type

The system will automatically determine the value of the Content-type tag in the request header based on the content of the test request body. And fill in the Content-type field of the request header by default, and the judgment conditions are as follows:

Content-type value trigger rule
Custom (Auto) If the request header in the document has entered the Content-type tag, regardless of whether the tag has an example value (default value). In the test, the request headers are all displayed as the sample values ​​filled in the document, and if the sample values ​​are not filled in, they will be empty. The Content-type hint in the request body is Auto.
application/x-www-form-urlencoded Select the Form-data format for the document request body, and the default Content-type of the system is application/x-www-form-urlencoded.
multipart/form-data Select the Form-data format for the document request body and select file for the field type of any parameter. Then the system judges that the Content-type is multipart/form-data.
application/json Select the Json format for the document request body, and the system judges that the Content-type is application/json.
application/xml Select the XML format for the document request body, and the system judges that the Content-type is application/xml.
text/plain、text/xml、text/html、application/javascript Select the Raw format for the document request body, and during the test, the user can directly select the Content-type value on the left at the top of the Raw format input box. After selection, the system will automatically fill in the request header.

2. Request field optional box

In the Form-data format, JSON format, and XML format of the request body, as well as the field lists of Query parameters and REST parameters, there is a request field optional box before each field. The selected state of this optional box follows the option of whether the field in the document is required, that is, if the field is set to be required, then in the test, the field is checked by default and requires a request. If the field is set as non-required, it will be unchecked by default in the test as a request field.

The checked field on the test page will only exist when a test request is initiated, otherwise the request will not carry any information in this field.

3. Constructor

 

The constructor is a tool provided by the system to quickly generate request data during testing. It is generally used to quickly encrypt data and generate random values. The constructor operation can be selected on the right side of a field in the request parameter, and the parameter value of the field can be generated through the constructor. Constructors consist of two types of operations: setting initial data and multiple operations .

3.1 Initial data

 

There are three types of initial data: custom data, dynamically generated data, and generated random values.

  • custom data

  • After entering any data as the initial value, the initial value of custom data is generally used in scenarios where a certain fixed value needs to be encrypted.

  • random number

  • The user can fill in the maximum value and the minimum value, and the system will randomly output a certain value within the value range.

  • dynamically generate data

  • The system provides a capability similar to Mock requesting parameter values, and has a variety of dynamic data generation formulas built in, which basically cover most applicable scenarios. For details, please refer to the following table:

random value type example
timestamp 1605942119819
UUID f660865D-3cbe-5b65-52bd-9cD1b06Bef7f
Phone number 13007057081
Mainland China ID card 34810227240230674x
random natural number 123
random floating point number 1.2
Date (yyyy-MM-dd) 2003/4/1
24 hours time (HH:mm:ss) 12:02:54
Date and 24-hour time (yyyy-MM-dd HH:mm:ss) 1977/1/21 19:19
year (yyyy) 1996
month (MM) 12
day (dd) 15
24 hours (HH) 21
points (mm) 30
seconds (ss) 45
Chinese name Liu Haozhen
Chinese surname liu
Chinese name Hao Zhen
Chinese title nice weather
Chinese paragraph The scenery has reached the period of green and strong consumption, and the market has to be shut down for a thousand times...
English name David Moore
English name First Name Angela
English Last Name Anderson
english title Cxhwayor Uvecv Jnvpnqicoq Glcwiq
English paragraph Lvqhfftzp xfngicin qmuhc kpongups bnptrtvyb rqado fkyblwrnc vfexsvt lryp mlm…
Mail [email protected]
IP 59.192.237.172
Hex color #f27988
RGB color rgb(121, 172, 242)
RGBA color rgba(207, 242, 121, 0.06)
3.2 Multiple operations

 

After the initial value is input, various data operations can be performed on the initial value, and other data operations can be performed on the processed data after the data operation to meet multiple data operations, such as multiple encryption and other scenarios.

The currently provided data operation methods are as follows:

operation method explain
base64 Encrypt according to bace64 encoding
MD5 Encrypt according to MD5 encoding
upper 字母转成大写
lower 字母转成小写
length 取字段长度值
hmac 按照HAMC算法进行加密,需要另外输入密钥
sha 按照sha算法进行加密
string 设为字符串值,给数据增加双引号或单引号
substring[字符串截取] 字符串截取,截取数据中的某段内容
concat[字符串拼接] 字符串拼接,可在字符串末尾拼接某段内容
3.3 表达式和静态值

 

用户在进行构造器操作的同时,构造器弹窗底部会同步显示当前已设置数据操作步骤的动态公式,以及根据公式随机生成的静态值。数据操作步骤设置完毕后,用户可以选择把动态公式或当前随机静态值插入到测试请求的参数值中。

若选择插入的是动态公式且初始数据为动态数据或随机数,则每次测试系统均会根据公式的条件,随机生成符合公式的参数值。一般每次测试生成的随机值均不一样。

若选择插入的是静态值,则会把该值固定填入到对应的参数值字段内,每次测试请求时均请求同一个参数值。

4、测试设置

API文档测试的高级设置有6项,用于配置测试的特殊规则。具体逻辑如下:

 

  • 测试服务

  • 下拉单选,默认选中使用Eolink Apikit 远程服务器。可选使用浏览器插件进行测试。选中后系统会自动保存,选中其他接口测试时会沿用最近选种的测试服务方式。

  • 自动跟随请求重定向

  • 开关配置,默认开启。

  • 验证SSL证书

  • 开关配置,默认关闭。关闭后可不验证SSL证书,但仅针对服务器测试或客户端测试。若是浏览器测试,则该开关配置无效,均需要验证SSL证书。

  • 发送Eolink Token头部

  • 开关配置,默认开启。开启后请求头会增加Eolink Token信息,若关闭则不添加。

  • 发送 no-cache 头部

  • 开关配置,默认关闭。开启后请求头会自动增加一条以下参数信息:

  • cache-control:no-cache

  • 报文编码格式

  • 单选配置,默认选中UTF-8,可选项有UTF-8和GBK。

三、返回展示区

 

测试页底部是测试返回信息展示区。其中包含时间分析、返回结果、返回头部、请求内容、请求头部、测试历史等模块。

1、时间分析

时间分析模块可查看该接口请求的每一步耗时情况。可方便的了解在哪个环节耗时较长或导致的接口异常。

2、返回结果

用于展示该接口请求的返回结果和返回具体内容。若接口请求成功,返回200状态码,则会在该模块页顶部展示200。并在底部显示该接口的返回具体信息。

若接口返回异常,则会在该模块页顶部展示异常的状态码,并在底部显示具体的异常信息。

3、返回头部

接口请求成功后,除了会展示返回结果外,也会展示具体的返回头部。在该模块可查看返回头部的所有信息。

4、请求内容

无论请求是否成功,均可在请求内容中查看实际发送的请求体内容。可用于判断请求内容是否发送正确。

5、请求头部

展示该次请求的请求头部信息,包含了完整的请求头信息。如隐藏的eo-token,user-agent等均会正常展示。

6、测试历史

在API文档测试页对该接口进行的每一次测试均会被系统保存起来,成为测试历史。

点击某行测试历史,系统会自动填充该历史的所有数据到当前测试页中。包含当时的测试地址、请求内容以及返回结果。会用历史的数据覆盖当前的数据来进行历史测试状态的完整复现。

用户可点击单行测试历史右侧的删除按钮,删除对应的测试历史数据。或点击顶部的清空测试历史按钮,清空所有的测试历史记录。

 

四、测试辅助工具

在测试过程中,Eolink提供两种测试辅助工具:环境管理和cookie管理。另外还有评论和变更通知管理工具,这里不赘述。

1、环境管理工具

测试页面右上角的快捷环境管理工具主要用于切换测试环境。可选择应用级和项目级已创建好的环境进行测试。选中某个环境后,接口URL会自动补充该环境域名或IP作为前缀。

可点选仅展示当前账号创建的环境,方便在团队协作时快速找到自己的测试环境。

点击环境管理工具上的小眼睛图标,可以查看当前的全局变量和环境变量情况。需要注意的是当全局变量和环境变量均有同一变量参数,则读取环境变量的变量值。即环境变量优先级大于全局变量。用户也可以在当前的变量预览表中对变量值进行编辑。

2、 生成请求示例代码

On the right side of the test sending button is the Generate Code button, which can generate interface request codes in multiple mainstream programming languages ​​with one click based on the request data of the current test page. It is convenient for the user to reuse the request data in the program.

Guess you like

Origin blog.csdn.net/qq_42107247/article/details/131422001