1、到目前为止的做过的接口测试的总结
怎么说呢，我觉得我现在做的虽然也是接口测试，但我设计的用例更多的是具体功能。例如发表朋友圈，我会调用上传接口（顺带检查上传的文件 md5 对不对，顺序对不对，相关属性字段对不对），发圈子接口（基本就检查返回值就够了，但要有不同类型的文字，包括特殊符号、长度等），查看圈子接口（图片 md5、顺序、相关属性对不对、发布人对不对、回复和点赞方面的数据对不对）。
2、我的用例设计有问题
这个讲概念比较难说清楚，还是以上面提到的发表朋友圈作为例子。
假设我要验证发表朋友圈的 接口，它的工作流程如下：
1、上传图片，服务器返回这些图片的 url
2、发表朋友圈，包含朋友圈文字内容和各个图片 url 两个主要字段。服务器只会返回是否成功以及这条朋友圈的 id
我设计的正常发朋友圈的用例如下：
1、用上传图片接口上传图片，验证图片是否上传成功，各 url 对应文件的 md5 是否和我本地上传的图片的 md5 吻合。
2、用发本地圈接口发本地圈，其中图片 url 来自第一步的返回值
3、用查看本地圈接口查看发出的本地圈，检查它的内容、图片是否正确。
这样看好像没啥问题（相信做过 api 测试的童鞋已经看出问题了），但其实这个用例本身存在一个严重的问题： 接口成为了手段，验证点其实是功能。
3、我交流后得到的 api 测试用例主要应该有两类：
1、单一接口测试。 调用一个接口就是一个用例
2、多接口的业务测试。会调用多个接口，且接口之间可能存在数据传递。
api 测试最简单，并且每个接口都应该至少有一个的用例应该就是使用 默认参数调用单个接口。重点在这里：单个。像我上面这样的用例已经不是验证发朋友圈的接口了，而是验证 发朋友圈的功能。
那么发朋友圈的接口应该有什么用例呢？我按照现在的测试接口的思路重新想了一下，主要有这几个：
有图片、有文字，预期返回发布成功
无图片，有文字，预期返回发布成功
有图片，无文字，预期返回发布成功
无图片，无文字，预期返回发布失败
有图片、有文子，预期返回发布成功，同时数据库中的记录符合预期
每一个用例测试一个点，发布成功这个返回值是否正确由一个单独的用例来覆盖就足够了。
用例确定了，那么可以看出接口测试其实有很多可以重用的点。接口测试的本质是通过测试参数的排列组合验证返回值/数据库变更是否符合预期，从而确定接口相关代码是否正确。从业务角度考虑的意思是这些排列组合不是随便想出来，而是业务中有可能出现的排列组合。
这也是为什么不少接口测试用例采用 excel 表格来编写，因为参数的排列组合用表格呈现是最简单快捷的。
4、还有一个例子说明用例越简练越好
例如列表接口有个翻页的功能。它有一个入参：lastTopicId ，返回值里有一个 isMore 的字段。lastTopicId 表示从哪个 topic 开始显示， isMore 表示是否存在下一页（1为有，0为无）。
针对这个接口的其中一个用例，需要验证 isMore 字段在最后一页时是否为0。我一开始的思路是像功能那样，不断翻页，直到达到一个很大的页数或者到达 isMore 为 0 的情况。由于页数不确定，因此就算这个很大的页数设得非常大也没有十足的把握绝对不会超出这个页数。所以思路本身有问题。
和 Monkey 和我的同事交流后，他指出正确的思路应该是：
通过一个可信的途径，从服务器数据库直接计算，或者有一个端口告诉你最后一页的 lastTopicId 是多少
TIPS：有些东西开发可以很方便地给到我们，那么我们没有必要那么艰难地自己去计算出来，而是直接让开发增加一个接口让我们能直接获取到数据就好。让接口测试做得更好，开发的协助是分不开的。
