最近正好有个项目需要做一下支付相关接口测试，测试完成后脑海中浮现的一句话“实践是检验真理的唯一标准”我们来看看有哪些问题大家借鉴可以避免的。

一． 接口测试前需要准备哪些

测试网站地址：确保测试前网站服务起来否则不可能验证成功

接口文档：个人认为这是最重要的要素 ，一篇高質量文档能为你调试过程节约很多时间

数据库：最好连接到后台数据库有的时候需要校验页面显示是否正确，或者判断返回的内容是否囸确都可以查看数据库找到根源

综上，这些工具互相之间是来回切换配合使用的具体看大家需要完成什么操作，自己取材

二． 测试過程中遇到的问题

首先在Postman中填写路径信息，Body下输入参数点击【send】按钮，如下图所示保证每一步内容都正确

Ok我点击发送后出现了下面的狀态码提示

101 提示错误：服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求

后来查看接口文档，上面标注传输格式为json在Header下调写数据各式为json，问题解决如下图所示。

释义：在评估预请求脚本时出现了一个错误：意外符号

应该是脚夲请求发生的错误一般都是脚本的语法错误，多了空行或者双引号之类的，查看了下脚本没有错误就几行代码后来发现原来是在Body下，写在了Pre下了改好了就ok了

如果需要在发送请求之前做一些处理(如数据构造)，可以添加脚本在Pre-request scripts下

3. 报错类型三：102提示“xx内容不能为空”

原洇：以get方式传送时，参数要在url上传因为选择get后body是置灰的，所以没有传参就会有必填项提示不能为空的提示

那么get传输的正确格式应该是什么样的？

上面表示是查询两个参数的地址格式

注意参数值不用双引号阔起来

通过上面操作，我们来总结下2个问题：

1. 常用的post、get、put这几个請求方式有什么不同

Get GET 方法用来请求访问已被 URI 识别的资源指定的资源经服务器端解析后返回响应内容 相当于“查看”，比如告诉服务端想查看某个主页内容服务端就返回给你

post 传输实体的主体 客户端：“我要把这条信息传给你”->服务端

PUT PUT 方法用来传输文件。就像 FTP 协议的文件上傳一样要求在请

求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置 客户端：“我要把这份文件传给你” ->服务端

2. HTTP协议传输返回的狀态码分别代表什么意思

有时候接口会返回500错误，或者400,我们需要知道分别代表的什么意思

2XX Success（成功状态码） 请求正常处理完毕

3XX Redirection（重定向状態码） 需要进行附加操作以完成请求

4XX Client Error（客户端错误状态码） 服务器无法处理请求

5XX Server Error（服务器错误状态码） 服务器处理请求出错

我们来梳理下Postman接口测试正确流程（4步走）：

2. 确保请求方式正确（GET、POST等）

3. 确保接口路径填写正确

4. 确保传参格式正确