用在社区看到的一个例子来阐述设计用例的关注点
假设我要验证发表朋友圈的 接口，它的工作流程如下：
- 上传图片，服务器返回这些图片的 url
- 发表朋友圈，包含朋友圈文字内容和各个图片 url 两个主要字段。服务器只会返回是否成功以及这条朋友圈的 id
我设计的正常发朋友圈的用例如下：
- 用上传图片接口上传图片，验证图片是否上传成功，各 url 对应文件的 md5 是否和我本地上传的图片的 md5 吻合。
- 用发本地圈接口发本地圈，其中图片 url 来自第一步的返回值
- 用查看本地圈接口查看发出的本地圈，检查它的内容、图片是否正确。
咋看之下好像没啥问题（相信做过 api 测试的童鞋已经看出问题了），但其实这个用例本身存在一个严重的问题： 接口成为了手段，验证点其实是功能。
我交流后得到的 api 测试用例主要应该有两类：
- 单一接口测试。调用一个接口就是一个用例
- 多接口的业务测试。会调用多个接口，且接口之间可能存在数据传递。
api 测试最简单，并且每个接口都应该至少有一个的用例应该就是使用 默认参数调用 单个接口。重点在这里：单个。像我上面这样的用例已经不是验证发朋友圈的接口了，而是验证 发朋友圈的功能。
那么发朋友圈的接口应该有什么用例呢？我按照现在的测试接口的思路重新想了一下，主要有这几个：
- 有图片、有文字，预期返回发布成功
- 无图片，有文字，预期返回发布成功
- 有图片，无文字，预期返回发布成功
- 无图片，无文字，预期返回发布失败
- 有图片、有文子，预期返回发布成功，同时数据库中的记录符合预期
每一个用例测试一个点，发布成功这个返回值是否正确由一个单独的用例来覆盖就足够了。
用例确定了，那么可以看出接口测试其实有很多可以重用的点。接口测试的本质是通过测试参数的排列组合验证返回值/数据库变更是否符合预期，从而确定接口相关代码是否正确。从业务角度考虑的意思是这些排列组合不是随便想出来，而是业务中有可能出现的排列组合。
这也是为什么不少接口测试用例采用 excel 表格来编写，因为参数的排列组合用表格呈现是最简单快捷的。
还有一个例子说明用例越简练越好。
例如列表接口有个翻页的功能。它有一个入参：lastTopicId ，返回值里有一个 isMore 的字段。lastTopicId 表示从哪个 topic 开始显示， isMore 表示是否存在下一页（1为有，0为无）。
针对这个接口的其中一个用例，需要验证 isMore 字段在最后一页时是否为0。我一开始的思路是像功能那样，不断翻页，直到达到一个很大的页数或者到达 isMore 为 0 的情况。由于页数不确定，因此就算这个很大的页数设得非常大也没有十足的把握绝对不会超出这个页数。所以思路本身有问题。
正确的思路应该是：
- 通过一个可信的途径（从服务器数据库直接计算，或者有一个端口告诉你最有一页的 lastTopicId 是什么），用一个步骤知道怎么一次性去到最后一页。
- 直接去到最后一页
- 验证 isMore 参数值