接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
按照分层测试模型，处于中间层的接口测试，在稳定性，效率，成本，技术，实施难度上综合来讲，是收益最大的。相较于传统的UI层次的测试，接口测试把测试提前了（时间上，架构上），并且能够覆盖到一些UI测试无法触及的功能点，提高了测试的覆盖率，对质量控制提升了信心。接口测试也更容易实现自动化持续集成，支持后端快速发版需求，利于CT（持续测试）的开展。
此处的用例设计方法，和普通的测试用例设计方法一样。可以把接口当作一个待测模块，分析接口功能需求，利用常规用例方法设计测试用例。可供参考的用例设计方法如下：
（1）检查接口的输入，数据格式、数据类型、数据范围等
（2）检查接口的参数边界（传递的参数足够大或者为负、空值时）
（3）检查接口的参数的组合，可选、必选等
（4）检查接口的约束条件，不符合约束条件的，不需要设计用例
接口名称：获取用户订单
请求URL：{$url}/getUserOrder
请求方式：POST
返回举例：
略
| 名称 | 必填 | Column | 类型 | 说明 |
|---|---|---|---|---|
| uid | Y | String | 用户id | |
| orderNum | N | Int | 订单数量 |
根据1业务流程2输入参数3输出返回4性能5安全内容对接口进行用例设计
| 业务流程 | |
|---|---|
| 获取用户订单成功 | |
| 用户订单不存在 | |
| 用户不存在 | |
| 获取用户订单异常 | |
| 输入参数用例 | |
| uid不为空，orderNum不为空 | |
| uid为空，orderNum为空 | |
| uid为空，orderNum不为空 | |
| uid不为空，orderNum为空 | |
| uid正确，orderNum不为空 | |
| uid正确，orderNum为空 | |
| uid错误，orderNum为空 | |
| uid错误，orderNum不为空 | |
| orderNum=1 | |
| orderNum=0 | |
| orderNum=5 | |
| orderNum=100000 | |
| orderNum | |
| uid数据格式错误 | |
| orderNum数据格式错误 | |
| 输出结果用例 | |
| 返回空值 | |
| 返回有效订单 | |
| 返回错误信息 | |
| 返回超时信息 | |
| 性能测试用例 | |
| 安全测试用例 |
此接口，接近30个用例，已经比较全面了，但实际上有点冗余。比如，如果调用接口的界面是个用户选择界面，那么参数上，会受到约束，uid/orderNum都从前端传入，是一些固定的值，那么就不会产生一些特殊情况。类似以下情况，就不会在实际中遇到，因此这些用例的价值趋于0，完全可以在用例文档中去除
设计的用例在考虑全面之后，需要再做一次减法，保证用例的实效性。对无法出现的场景设计出来的用例，毫无价值，只会增加我们的工作量，对产品质量提升没有帮助。因此，测试用例并不是越多越好，在于该用例是否能真正预防bug。（3）中灰底用例去除
接口测试用例在执行了一段时间后，需要对用例进行质量评估，即是对用例进行维护和优化。评估的内容可以参考如下几条：
（1）业务功能需求覆盖率；
（2）异常场景覆盖是否完整；
（3）代码覆盖率；
（4）用例的有效性，检查出bug的概率；
（5）用例的错误率，bug误报指数；
（6）测试数据维护成本，mock数据的准确性；
通过评估，可以得到接口测试的一些结果数据，对下一阶段接口测试的进行有参考意义，也有助于不断提高测试的质量和效益
