怎样做接口测试才能有效提升软件质量？

今天我要分享的是关于接口测试的内容，相信测试人员对接口测试都是不陌生的。在软件的开发过程中，大部分开发由于种种原因，放弃了单元测试，那么单接口测试就可以在一定程度上接近于单元测试，来弥补单元测试的不足，并且接口测试在一定程度上保障了产品的后端服务质量。

目前有很多的测试人员在做接口测试的时候，只是使用Postman等接口测试工具来验证单接口的返回是否符合预期，但事实上，完成单接口测试是远远不够的。除了验证单接口的正确性之外，我们还需要通过多接口测试去验证SUT（被测系统）的业务逻辑正确性。

接口测试为什么重要 

当测试人员在测试一个产品时，没有做接口测试或者只做了单接口测试的情况下，产品的后端服务质量是无法把控的。因为界面测试是前端的，只有接口测试和单元测试才是保障后端服务质量的测试，但是如果开发没有去做单元测试的情况下，测试人员一定要加大接口测试的比重，来尽量弥补缺少单元测试的情况。

如果不去做接口测试，我们不能保证用户在使用产品时发起的每一次请求都会返回用户想要的信息。理论上来讲，界面测试中的bug也许只是出现在某一客户端或某一浏览器的bug，但是后端的bug是会体现在所有用户的客户端上的，其影响范围比前端bug要严重地多。

接口测试是在测什么

接口测试通常包含两部分，单接口测试和多接口测试。那么什么是单接口测试和多接口测试？
以买咖啡为例，客户在前台点单，并传输需要的咖啡参数，例如：
- 咖啡：冰美式
- 杯型：超大杯
- 备注：无
当输入这些信息给店员后，店员会反馈点单成功的信息，这就是单接口的返回符合预期的情况。

多接口串联测试是什么呢？以同样的买咖啡为例：
接口1：客户将这些信息传递给店员点单后，店员反馈点单成功。
接口2：点单店员将订单信息传输给咖啡师，咖啡师确认收到订单信息。
接口3：咖啡师开始按照收到的订单信息制作该咖啡，完成后将咖啡交给取餐区的店员。
接口4：取餐区的店员收到咖啡后，发出取餐提醒。
接口5：客户收到取餐提醒，拿到相应的咖啡。

在接口测试中，单接口测试和多接口测试缺一不可，它们所关注的点也是不一样的。单接口测试关注单个接口的正确性，而多接口关注的是业务流程是否是通顺的。

为什么接口测试可以保障后端服务质量

我在多本软件测试的书中都曾看到一个观点：“一个产品越早介入测试越好”。因为通常情况下，越早发现Bug，修复的成本就越低。而接口测试就可以使测试人员更早地对产品介入测试。

比起前端页面，后端总是更早开发完成。那么比起前端的界面测试，我们总是可以更先一步的去做接口测试。接口测试是直接测试后端服务，那测试人员就更容易发现底层Bug。越底层的Bug，影响范围是越广的。

接口测试是一个技术知识和业务知识相结合的工作，除了测试技术之外，我们需要了解业务，因为只有了解业务，我们才能验证针对业务流程的多接口串联测试。

在开始接口测试前，测试人员会拿到产品提供的需求文档和开发提供的接口文档。接口文档详细描述了接口的访问方式和参数。有了这些信息，我们可以开展单接口测试，来验证单个接口的正确性。还是以买咖啡为例：
- 当客户向店员传输“超大杯冰美式咖啡”，店员会反馈点单成功
- 当客户向店员传输“大杯珍珠奶茶”，店员会反馈点单失败，并会告知本店没有此饮品
也就是说，单接口测试我们不仅要验证输入正确参数时，点单成功，也要验证输入错误参数时，点单失败。

当测试人员验证完单个接口的正确性后，就需要验证SUT业务逻辑是否符合预期。首先测试人员需要将接口文档和需求文档结合起来，设计符合业务逻辑的接口测试用例，这次例子我们换成线上点单咖啡，已知业务逻辑是“客户App下单咖啡，咖啡师收到订单并制作咖啡放至取餐区，客户取餐”，根据这个业务逻辑，可能会有以下流程：
- 客户下单咖啡成功，咖啡师收到订单并制作咖啡放至取餐区，客户取餐成功
- 客户下单咖啡成功，咖啡师收到订单并制作咖啡放至取餐区，客户误取餐
- 客户下单咖啡成功，咖啡师收到订单并制作咖啡放至取餐区，客户未取餐
- 。。。。。

一定会有小伙伴好奇，为什么不同情况只在客户取餐环节，中间的异常情况呢？比如说客户下单咖啡失败？客户下单咖啡成功但是咖啡师未收到订单？等等，这些情况在单接口测试的时候应该已经验证过了。

SUT的业务逻辑性验证的前提，是单接口测试的返回值全部都是符合预期的。只有这样，我们才能串联多个接口去验证SUT的业务逻辑。

以上就是今天我要分享的内容。