技术分享 | 微服务模式下如何高效进行API测试

导读：微服务架构下，API 测试的最大挑战来自于庞大的测试用例数量，以及微服务之间的相互耦合。基于这种挑战，如何进行高效的API测试，选择什么样的方式就比较重要，此文主要是采用契约测试的方法来对微服务模式下的API测试做简要的阐述。

一、背景

集成开放平台由1个云端管理中心+N个后台服务组成（连接中心、接口中心等），云端管理中心与后台服务存在1对多的API调用关系，而服务与服务间也存在多对多的API调用关系。如何高效精准的保障这些接口调用稳定，结合行业内接口测试方法和微服务模式下的接口测试，我们总结了一套集成开放平台的API测试方法：契约测试。

二、契约测试与传统API测试的不同

2.1 传统的 API 测试策略

在传统的 API 测试中，我们的测试策略通常是：

1. 根据被测 API 输入参数的各种组合调用 API，并验证相关结果的正确性；
2. 衡量上述测试过程的代码覆盖率；
3. 根据代码覆盖率进一步找出遗漏的测试用例；
4. 以代码覆盖率达标作为 API 测试成功完成的标志。

2.2 基于消费者契约的 API 测试（后面简称契约测试）

而服务拆分之后，API 接口数量将成倍增加，此时需要找到一种既能保证 API 质量，又能减少测试用例数量的测试策略。即基于消费者契约的 API 测试。
如下图，基于消费者契约的 API 测试的核心思想是：只测试那些真正被实际使用到的 API 调用，如果没有被使用到的，就不去测试。

看上图大家可能对契约测试还是比较模糊，下面我举个实例进行详细讲解。

案例：连接中心提供了创建连接的API给云端管理中心，我们需要对创建连接的API进行接口测试。

传统的接口用例设计如下：

2.3 契约测试的用例设计如下：

从上面两幅图可以清晰的看出，契约测试抛弃了异常场景的验证，契约模式下，传参可定是合法的。

从上面两幅图可以清晰的看出。契约测试做了如下改变：

1.抛弃了异常场景的验证，契约下，传参肯定是合法的。不需要额外进行验证。

2.对接口提供方的业务逻辑做了场景合并处理，不关注里面的业务逻辑，重在验证契约的功能是否正常。

2.4 契约测试、单元测试、接口测试区别

API测试和单元测试，更强调的是覆盖API内部逻辑。

契约测试，更强调是组件之间连接的正确性，除了保证组件内部，还要保证组件间的调用是正确的，也就是服务API之间的调用。

单元测试	单元测试针对代码单元（通常是类）的测试，单元测试的价值在于能提供最快的反馈。另外好的单元测试还可以帮助你改善设计，在你的团队掌握TDD的前提下，单元测试能辅助重构，帮助改善代码整洁度。
API测试	API测试是针对业务接口进行的测试，主要测内部接口功能实现是否完整，比如说内部逻辑是不是正常，异常处理是不是正确。
契约测试	契约测试其实是为了测试服务之间连接或者说接口调用的正确性，为了验证服务提供者的功能是不是真正能够满足消费者的需求。它其实体现了测试前移的思想，把本来要通过集成测试才能验证的工作化作单元测试和接口测试，用更轻量的方式快速进行验证。关注点是consumer是否可以正确的消费provider的API，这里的"消费"包括调用接口和解析数据。它的被测对象，注意，一定是consumer。
集成测试	它从用户的角度验证整个功能的正确性，测的是端到端的流程，并且加入用户场景和数据，验证整个过程是不是OK，它的价值业务价值最高，是验证一个完整的流程。

2.5 契约测试带来的好处

降低服务集成的难度，把服务集成这个过程分解成了单元测试和接口测试来做，它从消费者的需求为出发点，把消费者的需求作为你的测试用例驱动出一份契约，然后验证提供者端的功能。

通过使用契约测试，接口调用双方协商接口后就可以并行开发，并且在开发过程中就利用契约进行预集成测试，不用等到联调再来集成调通接口，一旦成熟，在保证质量的前提下，联调的成本可以减低到几乎为0。

三、总结及适用场景

契约测试相对传统接口测试来说，很大程度上缩减了测试场景，使测试更聚焦于客户实际应用场景。但是缺点也很明显，一旦消费者毁坏契约进行非法的参数调用时，就会导致生产者出现不可预知的异常，甚至会导致宕机的发生。为此我梳理一下适用的场景，请慎重选择。

场景描述	是否适用
1.微服务内部接口，不对外开放	√
2.微服务前后端调用接口，有指定身份认证	√
3.微服务间相互调用接口，不对外开放	√
4.微服务对外指定接口，有指定身份认证	√
5.微服务对外公开接口	×
6.微服务对外指定接口，涉及核心业务场景	×