微服务模式下的Api测试

微服务模式下的Api测试

传统的 API 测试策略

由传统的单体架构到现在的微服务架构下，API 测试的最大挑战来自于庞大的测试用例数量，以及微服务之间的相互耦合。

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

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

基于消费者契约的 API 测试

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

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

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

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

契约测试带来的好处

降低服务集成的难度，把服务集成这个过程分解成了单元测试和接口测试来做，它从消费者的需求为出发点，把消费者的需求作为你的测试用例驱动出一份契约，然后验证提供者端的功能。
通过使用契约测试，接口调用双方协商接口后就可以并行开发，并且在开发过程中就利用契约进行预集成测试，不用等到联调再来集成调通接口，一旦成熟，在保证质量的前提下，联调的成本可以减低到几乎为0。

契约测试的价值体现场景

要最大化的体现契约测试异于集成测试的价值，一定是在”单个provider对应多个consumer”的架构下来说的。
因为，在只有一个provider和一个consumer的架构下，只存在一份契约，对该契约内容的任何修改，对这对provider和consumer来说，都是显而易见的，那么就不会出现契约破坏的情况。

契约测试，形式上测试的是provider，但价值上保证的却是consumer的业务。
如果consumer对自己都不上心，你还期望provider来时刻关注你的死活吗？别笑，在跨团队的微服务体系下，这些都是真切的痛点。

下图ServiceA是消费者，ServiceB是生产者，形式看似测试的是ServiceB，但价值上保证的是ServiceA的业务逻辑。
团队甲想保证ServiceA的业务逻辑，其实无需知道团队乙的ServiceB的业务逻辑，只要依照接口文档（契约）来测试即可。
但是对rpc接口的测试对测试工程师提出了更高的要求，因为无UI界面，那如何判断业务逻辑正确还是错误呢，此时就需要测试工程师跟开发了解这个rpc接口调用以及处理细节了。

阅读：
微服务模式下API测试要怎么做？ --作者：茹炳晟
契约测试最早由 Martin Fowler 提出，论文地址。中文
微服务下的契约测试(CDC)解读
契约测试之核心解惑
什么是契约测试？