什么是接口
接口：服务端程序对外提供的一种统一的访问方式，通常采用 HTTP协议，通过 不同的url，不同的请求类型（GET、POST）， 不同的参数，来执行不同的业务逻辑。
客户端大多数的业务操作，都是需要 调用 服务端接口来获取一些数据， 或者触发某些业务，然后客户端拿到接口返回的数据后，会根据数据内容做不同的处理和展示。
为什么要做接口测试
A、在公司里，客户端和服务端通常是由不同的团队开发的，在项目开发过程中，客户端和服务端开发的进度不一致，比如服务端先开发完了，这个时候可以先对服务端进行接口测试，确保服务端逻辑和返 回数据是正确的，然后再测试客户端。或者是某些测试部门，专门测试服务端开发团队，因此，他们的 测试对象就是接口。
B、在测试某些业务时，不能仅仅通过前端来测试，比如用户注册，前端限制了用户名不能为空，但是有些人可能通过工具绕过前端直接调用服务端接口，如果服务端没有做相关的逻辑判断，就会造成数据 错误。包括接口数据传输过程中是否对关键信息加密等。所以必须 针对服务端接口单独做测试。
C、在开发提测后，可以先通过工具把服务端的接口测试跑一遍，确保接口测试用例都是通过的，快速判断服务端接口是否符合预期。然后 再通过UI界面进行测试。否则接口有bug，前端页面必定有bug。
接口测试的意义
按照分层测试模型，处于中间层的接口测试，在稳定性，效率，成本，技术，实施难度上综合来讲，是收益最大的。相较于传统的UI层次的测试，接口测试把测试提前了（时间上，架构上），并且能够覆盖到一些UI测试无法触及的功能点，提高了测试的覆盖率，对质量控制提升了信心。接口测试也更容易实现自动化持续集成，支持后端快速发版需求，利于CT（持续测试）的开展。
（分层测试模型 - 图片摘自 51testing 网站）
接口用例设计方法
接口测试用例设计的重点，在于功能性的业务逻辑检查和参数检查。
1.功能：检查接口基础功能，是否完成了业务逻辑要求。此处的用例设计方法，和普通的测试用例设计方法一样。可以把接口当作一个待测模块，分析接口功能需求，利用常规用例方法设计测试用例。可供参考的用例设计方法如下：
| 1 2 3 4 5 6 7 8 | 1.等价类划分法 2.边界值分析法 3.错误推测法 4.因果图法 5.判定表驱动法 6.正交试验法 7.功能图法 8.场景图法 |
2.数据：分析接口的输入参数，覆盖各种可能的场景。
（1）检查接口的输入，数据格式、数据类型、数据范围等
（2）检查接口的参数边界（传递的参数足够大或者为负、空值时）
（3）检查接口的参数的组合，可选、必选等
（4）检查接口的约束条件，不符合约束条件的，不需要设计用例
3.性能：接口是否造成性能瓶颈，能承受的压力范围
4. 安全：接口是否涉及安全性
接口用例设计举例
下面以一个web接口作为案例，接口说明文档如下：
| 1 2 3 4 5 | 接口名称：获取用户订单 请求URL：{$url}/getUserOrder 请求方式：POST 返回举例： 略 |
请求参数：
| 名称 | 必填 | 类型 | 说明 |
| uid | Y | String | 用户id |
| orderNum | N | Int | 订单数量 |
根据（1）业务流程（2）输入参数（3）输出返回（4）性能（5）安全 5块内容对接口进行用例设计。用例参考如下：
| 业务流程用例 | |
| 获取用户订单成功 | |
| 用户订单不存在 | |
| 用户不存在 | |
| 获取用户订单异常 | |
| 输入参数用例 | |
| uid不为空，orderNum不为空 | |
| uid为空，orderNum为空 | |
| uid为空，orderNum不为空 | |
| uid不为空，orderNum为空 | |
| uid正确，orderNum不为空 | |
| uid正确，orderNum为空 | |
| uid错误，orderNum不为空 | |
| uid错误，orderNum为空 | |
| orderNum=-1 | |
| orderNum=0 | |
| orderNum=1 | |
| orderNum=5 | |
| orderNum=100000 | |
| orderNum | |
| uid数据格式错误 | |
| orderNum数据格式错误 | |
| 输出结果用例 | |
| 返回空值 | |
| 返回有效订单 | |
| 返回错误信息 | |
| 返回超时信息 | |
| 性能用例 | |
| … | |
| 安全用例 | |
| … |
用例筛选：
此接口，接近30个用例，已经比较全面了，但实际上有点冗余。比如，如果调用接口的界面是个用户选择界面，那么参数上，会受到约束，uid/orderNum都从前端传入，是一些固定的值，那么就不会产生一些特殊情况。类似以下情况，就不会在实际中遇到，因此这些用例的价值趋于0，完全可以在用例文档中去除。
| uid为空，orderNum为空 |
| uid为空，orderNum为空 |
| orderNum=-1 |
| orderNum=0 |
| orderNum=100000 |
| orderNum数据格式错误 |
| uid数据格式错误 |
| uid错误，orderNum不为空 |
| uid错误，orderNum为空 |
设计的用例在考虑全面之后，需要再做一次减法，保证用例的实效性。对无法出现的场景设计出来的用例，毫无价值，只会增加我们的工作量，对产品质量提升没有帮助。因此，测试用例并不是越多越好，在于该用例是否能真正预防bug。
接口测试质量评估
接口测试用例在执行了一段时间后，需要对用例进行质量评估，即是对用例进行维护和优化。评估的内容可以参考如下几条：
（1）业务功能需求覆盖率；
（2）异常场景覆盖是否完整；
（3）代码覆盖率；
（4）用例的有效性，检查出bug的概率；
（5）用例的错误率，bug误报指数；
（6）测试数据维护成本，mock数据的准确性；
通过评估，可以得到接口测试的一些结果数据，对下一阶段接口测试的进行有参考意义，也有助于不断提高测试的质量和效益。
下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
最后： 可以在公众号：自动化测试老司机 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！
