第一步：理解需求，梳理出各种场景

习惯使用思维导图，梳理的同时可以把需求理解得更透彻

输出：需求思维导图

第二步：整理测试用例

把思维导图的内容整理成测试用例

输出：测试用例

第三步：把接口文档中的内容整理到postman等接口测试工具中

postman是chrome插件，适合开发和测试调用接口，易学、功能强大

输出：postman的collection文件

第四步：测试阶段

不只查看request和response，也需要关注数据库的数据是否随之更改

第五步：接口自动化测试

把测试用例提炼出适合自动化测试的部分，使用数据驱动的方式进行自动化测试。数据驱动可以选择使用xml文件或者excel文件或者其他方式保存数据，通过读取数据驱动自动化测试，同时也需要把response写入读取的文件中（以进行对比）。

目前实现的自动化是，读取excel表中事先准备的数据，一条条用例跑着，把每条用例的返回值写回excel表中。excel表中有一个字段是用来保存预期值的，把预期值与实际值进行比对，如果不相等，把该条用例拷贝到另一个Sheet中。

输出：excel数据文件

第六步：输出报告

输出：测试报告

接口测试的一些思路总结：

验证参数、返回值要仔细对照接口文档。

各个参数的拼写是否正确；

返回给前端的code是否统一；

request、response的参数类型（int、String……）是否正确；

get、post方法是否混乱（不只post可以带参数，get也可以带参数的！）；

response格式是否正确（在自动化阶段可以使用jsonSchema进行校验）

……

get无参数，通常是用来获取详情、列表的，这时候要仔细比对返回值，跟接口文档、需求文档、UI都要有比对，所以第一步的梳理产物很重要。看一份文档总比看三份文档不容易遗漏

get有参数，如果用来根据参数获取列表、详情，参数通常是id、nums这种；如果是使用给定的参数来校验(比如门票的使用、校验等），这时候还要加一个考虑-安全性。虽然各种接口没做好都会出现安全性的问题，但是不要太好破啊⊙﹏⊙

post，提交各项请求，对各个参数的合法性、不合法考虑，混搭配合，缺失考虑……你能考虑到的用例都加上来

接口测试不能忘了需求的各种场景，有的场景路径短，有的场景路径长（条条大路通罗马，目的只有一个）。没有界面的场景设置起来也是很耗脑力、体力的。

记几个场景：

1.比如我们下单的菜单，是由几个分类构成，每个分类下面有一堆的菜品，每种菜品又有不同的规格。这种时候接口不光要看能不能把菜都返回出来，还要看每个分类的排序、菜的排序、规格的排序、能不能把热销的菜单独拉一个分类。

我们都知道，超市各个区域物品的摆放是有一定的规则的，难道我们的菜单不需要经过一番研究吗。但是我们在录入资料的时候是不可能把所有菜品都先经过研究要怎么摆放再把结果录入的，如果这样，我有新品有下架的怎么办，排序就是一个解决方案。

记住了！

2.后台录入的资料是否正确同步到数据库，我们抓接口数据时是否获取到正确的数据。后台数据如果可以编辑、删除，要先判断会不会对接口数据产生影响，接口获取到的数据是否也可以随之编辑、删除。

比如，我们有一张门票已经产生了，有木有人买对这张门票的操作是很关键的。如果没有人买，当然操作门票没什么太大的影响，如果已经有人购买了，你再操作门票，买的人获取到的信息还正不正确就很重要了。

3.分页返回数据，是要返回符合要求的内容，还是返回分页后的第一页内容

4.门票使用计数。自己使用、赠送、过期对总数都是有影响的

5.门票归属，我不可能可以查询到别人的门票吧（比如别人分享了ta的链接，我竟然可以查看ta的门票--不得了了）

postman中配置环境

通常我们开始测试接口的时候，很多配置还没有配到线上。这时候就需要自己在本地配置。在postman中可以配置Cookie来获取认证。

在测试微信公众号的时候，刚开始还没有加微信oauth前，先让开发在代码中写死；如果加上oauth，则需要加上Cookie了。

开发要把我们自己的微信号加到公众号开发者中，本机安装微信web开发者工具，把调用接口返回的401那段地址粘贴到开发者工具的地址栏中，修改下斜杠，回车，查看返回是否正确

修改后是这样

把返回的信息中，request的Cookie信息粘贴到postman中的Headers中

返回信息

通常我会做成参数，也可以把其他号的信息加进来，很方便调用有木有

postman-headers

环境参数中列了一堆参数

postman环境参数

可以愉快的调用了