什么是接口

接口：服务端程序对外提供的一种统一的访问方式，通常采用 HTTP协议，通过 不同的url，不同的请求类型（GET、POST）， 不同的参数，来执行不同的业务逻辑。

客户端大多数的业务操作，都是需要 调用 服务端接口来获取一些数据， 或者触发某些业务，然后客户端拿到接口返回的数据后，会根据数据内容做不同的处理和展示。

为什么要做接口测试

A、在公司里，客户端和服务端通常是由不同的团队开发的，在项目开发过程中，客户端和服务端开发的进度不一致，比如服务端先开发完了，这个时候可以先对服务端进行接口测试，确保服务端逻辑和返 回数据是正确的，然后再测试客户端。或者是某些测试部门，专门测试服务端开发团队，因此，他们的 测试对象就是接口。

B、在测试某些业务时，不能仅仅通过前端来测试，比如用户注册，前端限制了用户名不能为空，但是有些人可能通过工具绕过前端直接调用服务端接口，如果服务端没有做相关的逻辑判断，就会造成数据 错误。包括接口数据传输过程中是否对关键信息加密等。所以必须 针对服务端接口单独做测试。

C、在开发提测后，可以先通过工具把服务端的接口测试跑一遍，确保接口测试用例都是通过的，快速判断服务端接口是否符合预期。然后 再通过UI界面进行测试。否则接口有bug，前端页面必定有bug。

接口测试的意义

按照分层测试模型，处于中间层的接口测试，在稳定性，效率，成本，技术，实施难度上综合来讲，是收益最大的。相较于传统的UI层次的测试，接口测试把测试提前了（时间上，架构上），并且能够覆盖到一些UI测试无法触及的功能点，提高了测试的覆盖率，对质量控制提升了信心。接口测试也更容易实现自动化持续集成，支持后端快速发版需求，利于CT（持续测试）的开展。

（分层测试模型 - 图片摘自 51testing 网站）

接口用例设计方法

接口测试用例设计的重点，在于功能性的业务逻辑检查和参数检查。

1.功能：检查接口基础功能，是否完成了业务逻辑要求。此处的用例设计方法，和普通的测试用例设计方法一样。可以把接口当作一个待测模块，分析接口功能需求，利用常规用例方法设计测试用例。可供参考的用例设计方法如下：

2.数据：分析接口的输入参数，覆盖各种可能的场景。

（1）检查接口的输入，数据格式、数据类型、数据范围等

（2）检查接口的参数边界（传递的参数足够大或者为负、空值时）

（3）检查接口的参数的组合，可选、必选等

（4）检查接口的约束条件，不符合约束条件的，不需要设计用例

3.性能：接口是否造成性能瓶颈，能承受的压力范围

4. 安全：接口是否涉及安全性

接口用例设计举例

下面以一个web接口作为案例，接口说明文档如下：

请求参数：

根据（1）业务流程（2）输入参数（3）输出返回（4）性能（5）安全 5块内容对接口进行用例设计。用例参考如下：

用例筛选：

此接口，接近30个用例，已经比较全面了，但实际上有点冗余。比如，如果调用接口的界面是个用户选择界面，那么参数上，会受到约束，uid/orderNum都从前端传入，是一些固定的值，那么就不会产生一些特殊情况。类似以下情况，就不会在实际中遇到，因此这些用例的价值趋于0，完全可以在用例文档中去除。

设计的用例在考虑全面之后，需要再做一次减法，保证用例的实效性。对无法出现的场景设计出来的用例，毫无价值，只会增加我们的工作量，对产品质量提升没有帮助。因此，测试用例并不是越多越好，在于该用例是否能真正预防bug。

接口测试质量评估

接口测试用例在执行了一段时间后，需要对用例进行质量评估，即是对用例进行维护和优化。评估的内容可以参考如下几条：

（1）业务功能需求覆盖率；

（2）异常场景覆盖是否完整；

（3）代码覆盖率；

（4）用例的有效性，检查出bug的概率；

（5）用例的错误率，bug误报指数；

（6）测试数据维护成本，mock数据的准确性；

通过评估，可以得到接口测试的一些结果数据，对下一阶段接口测试的进行有参考意义，也有助于不断提高测试的质量和效益。

下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！