看测试老鸟如何把API 测试玩弄在鼓掌之间（下）

草帽路飞UU

       六、Response 结果发生变化时的自动识别
　　在实际的工程项目中，开发了大量的基于代码的 API测试用例后，你会发现一个让人很纠结的问题：到底应该验证 API 返回结果中的哪些字段？
　　因为你不可能对返回结果中的每一个字段都写 assert，通常情况下:你只会针对关注的几个字段写 assert，而那些没写 assert 的字段也就无法被关注了。
　　但对 API 测试来说，有一个很重要的概念是后向兼容性（backward compatibility）。API 的后向兼容性是指，发布的新 API 版本应该能够兼容老版本的 API。后向兼容性除了要求 API 的调用参数不能发生变化外，还要求不能删减或者修改返回的 response 中的字段。因为这些返回的 response 会被下游的代码使用，如果字段被删减、改名或者字段值发生了非预期的变化，那么下游的代码就可能因为无法找到原本的字段，或者因为字段值的变化而发生问题，从而破坏 API 的后向兼容性。
　　所以，我们迫切需要找到一个方法，既可以不对所有的 response 字段都去写 assert，又可以监测到 response 的结构以及没有写 assert 的字段值的变化。
　　在这样的背景下，诞生了“Response 结果变化时的自动识别”技术。也就是说，即使我们没有针对每个 response 字段都去写 assert，我们仍然可以识别出哪些 response 字段发生了变化。
　　具体实现的思路是，在 API 测试框架里引入一个内建数据库，推荐采用非关系型数据库（比如 MongoDB），然后用这个数据库记录每次调用的 request 和 response 的组合，当下次发送相同 request 时，API 测试框架就会自动和上次的 response 做差异检测，对于有变化的字段给出告警。
　　你可能会说这种做法也有问题，因为有些字段的值每次 API 调用都是不同的，比如 token 值、session ID、时间戳等，这样每次的调用就都会有告警。
　　但是这个问题很好解决，现在的解决办法是通过规则配置设立一个“白名单列表”，把那些动态值的字段排除在外。
　　七、微服务模式下API测试要怎么做？
　　今天，我将更进一步，带你去了解当下最热门的技术领域的 API 测试，即微服务模式下的 API 测试。微服务架构下，API 测试的最大挑战来自于庞大的测试用例数量，以及微服务之间的相互耦合。所以，我今天分享这个主题的目的就是，帮你理解这两个问题的本质，以及如何基于消费者契约的方法来应对这两个难题。
　　而为了掌握微服务模式下的 API 测试，你需要先了解微服务架构（Microservice Architecture）的特点、测试挑战；而要了解微服务架构，你又需要先了解一些单体架构（Monolithic Architecture）的知识。所以，今天的话题我将逐层展开，目的就是希望你可以真正理解，并快速掌握微服务模式下的 API 测试。
　　单体架构（Monolithic Architecture）
　　单体架构是早期的架构模式，并且存在了很长时间。单体架构是将所有的业务场景的表示层、业务逻辑层和数据访问层放在同一个工程中，最终经过编译、打包，并部署在服务器上。比如，经典的 J2EE 工程，它就是将表示层的 JSP、业务逻辑层的 Service、Controller 和数据访问层的 DAO（Data Access Objects），打包成 war 文件，然后部署在 Tomcat、Jetty 或者其他 Servlet 容器中运行。
　　显然单体架构具有发布简单、方便调试、架构复杂性低等优点，所以长期以来一直被大量使用，并广泛应用于传统企业级软件。
　　但是，随着互联网产品的普及，应用所承载的流量越来越庞大，单体架构的问题也被逐渐暴露并不断放大，主要的问题有以下几点：
　　1.灵活性差：无论是多小的修改，哪怕只修改了一行代码，也要打包发布整个应用。更糟的是，由于所有模块代码都在一起，所以每次编译打包都要花费很长时间。
　　2.可扩展性差：在高并发场景下，无法以模块为单位灵活扩展容量，不利于应用的横向扩展。
　　3.稳定性差：当单体应用中任何一个模块有问题时，都可能会造成应用整体的不可用，缺乏容错机制。
　　4.可维护性差：随着业务复杂性的提升，代码的复杂性也是直线上升，当业务规模比较庞大时，整体项目的可维护性会大打折扣
　　正是因为面对互联网应用时，单体架构有这一系列无法逾越的鸿沟，所以催生了微服务架构。
　　其实，微服务架构也不是一蹴而就的，也经历了很长时间的演化发展，中间还经历了著名的 SOA 架构。但是这个由单体架构到 SOA 架构再到微服务架构的演进过程，并不是本文的重点，所以我就不再详细展开了，如果你感兴趣的话，可以自行去查阅一些相关资料。
　　微服务架构（Microservice Architecture）
　　微服务是一种架构风格。在微服务架构下，一个大型复杂软件系统不再由一个单体组成，而是由一系列相互独立的微服务组成。其中，各个微服务运行在自己的进程中，开发和部署都没有依赖。
　　不同服务之间通过一些轻量级交互机制进行通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，只需要关注并很好地完成一件任务就可以了，不同的服务可以根据业务需求实现的便利性而采用不同的编程语言来实现，由独立的团队来维护。
　　微服务架构具有以下特点：
　　·每个服务运行在其独立的进程中，开发采用的技术栈也是独立的；
　　· 服务间采用轻量级通信机制进行沟通，通常是基于 HTTP 协议的 RESTful API；
　　· 每个服务都围绕着具体的业务进行构建，并且能够被独立开发、独立部署、独立发布；
　　· 对运维提出了非常高的要求，促进了 CI/CD 的发展与落地。
　　八、微服务架构下的测试挑战
　　由于微服务架构下，一个应用是由很多相互独立的微服务组成，每个微服务都会对外暴露接口，同时这些微服务之间存在级联调用关系，也就是说一个微服务通常还会去调用其他微服务，鉴于以上特点，微服务架构下的测试挑战主要来自于以下两个方面：
　　1.过于庞大的测试用例数量；
　　2.微服务之间的耦合关系。
　　接下来，我会针对这两项挑战分别展开，包括它们从何而来，以及如何应对这些挑战，最终完成测试。
　　第一，过于庞大的测试用例数量
　　1.在传统的 API 测试中，我们的测试策略通常是：
　　根据被测 API 输入参数的各种组合调用API，并验证相关结果的正确性；
　　2.衡量上述测试过程的代码覆盖率；
　　3.根据代码覆盖率进一步找出遗漏的测试用例；
　　4.以代码覆盖率达标作为 API 测试成功完成的标志。
　　这也是单体架构时代主流的 API 测试策略。为了让你更好地理解这种测试策略，我来举一个实际的例子。
　　假设我们采用单体架构开发了一个系统，这个系统对外提供了 3 个 Restful API 接口，那么我们的测试策略应该是：
　　针对这 3 个 API 接口，分别基于边界值和等价类方法设计测试用例并执行；
　　2.在测试执行过程中，启用代码覆盖率统计；
　　3.假设测试完成后代码行覆盖率是 80%，那么我们就需要找到那些还没有被执行到的 20% 的代码行。比如图 2 中代码的第 242 行就是没有被执行到，分析代码逻辑后发现，我们需要构造“expected!=actual”才能覆盖这个未能执行的代码行；
　　3.最终我们要保证代码覆盖率达到既定的要求，比如行覆盖率达到 100%，完成 API 测试。
　　而当我们采用微服务架构时，原本的单体应用会被拆分成多个独立模块，也就是很多个独立的 service，原本单体应用的全局功能将会由这些拆分得到的 API 共同协作完成。
　　比如，对于上面这个例子，没有微服务化之前，一共有 3 个 API 接口，假定现在采用微服务架构，该系统被拆分成了 10 个独立的 service，如果每个 service 平均对外暴露 3 个 API 接口，那么总共需要测试的 API 接口数量就多达 30 个。
　　如果我还按照传统的 API 测试策略来测试这些 API，那么测试用例的数量就会非常多，过多的测试用例往往就需要耗费大量的测试执行时间和资源。
　　但是，在互联网模式下，产品发布的周期往往是以“天”甚至是以“小时”为单位的，留给测试的执行时间非常有限，所以微服务化后 API 测试用例数量的显著增长就对测试发起了巨大的挑战。
　　这时，我们迫切需要找到一种既能保证 API 质量，又能减少测试用例数量的测试策略，这也就是我接下来要分享的基于消费者契约的 API 测试。
　　第二，微服务之间的耦合关系
　　微服务化后，服务与服务间的依赖也可能会给测试带来不小的挑战。
　　如图 3 所示，假定我们的被测对象是 Service T，但是 Service T 的内部又调用了 Service X 和 Service Y。此时，如果 Service X 和 Service Y 由于各种原因处于不可用的状态，那么此时就无法对 Service T 进行完整的测试。

我们迫切需要一种方法可以将 Service T 的测试与 Service X 和 Service Y 解耦
　　解耦的方式通常就是实现 Mock Service 来代替被依赖的真实 Service。实现这个 Mock Service 的关键点就是要能够模拟真实 Service 的 Request 和 Response。当我介绍完基于消费者契约的 API 测试后，你会发现这个问题也就迎刃而解了。

草帽路飞UU

　九、基于消费者契约的 API 测试
　　那到底什么是基于消费者契约的 API 测试呢？直接从概念的角度解释，会有些难以理解。所以我打算换个方法来帮助你从本质上真正理解什么是基于消费者契约的 API 测试。接下来，就跟着我的思路走吧。
　　首先，我们来看图 4，假设图 4 中的 Service A、Service B 和 Service T 是微服务拆分后的三个 Service，其中 Service T 是被测试对象，进一步假定 Service T 的消费者（也就是使用者）一共有两个，分别是 Service A 和 Service B。
　　按照传统的 API 测试策略，当我们需要测试 Service T 时，需要找到所有可能的参数组合依次对 Service T 进行调用，同时结合 Service T 的代码覆盖率进一步补充遗漏的测试用例。
　　这种思路本身没有任何问题，但是测试用例的数量会非常多。那我们就需要思考，如何既能保证 Service T 的质量，又不需要覆盖全部可能的测试用例。
　　静下心来想一下，你会发现 Service T 的使用者是确定的，只有 Service A 和 Service B，如果可以把 Service A 和 Service B 对 Service T 所有可能的调用方式都测试到，那么就一定可以保证 Service T 的质量。即使存在某些 Service T 的其他调用方式有出错的可能性，那也不会影响整个系统的功能，因为这个系统中并没有其他 Service 会以这种可能出错的方式来调用 Service T。 现在，问题就转化成了如何找到 Service A 和 Service B 对 Service T 所有可能的调用方式。如果能够找出这样的调用集合，并以此作为 Service T 的测试用例，那么只要这些测试用例 100% 通过，Service T 的质量也就不在话下了。 本质上来讲，这样的测试用例集合其实就是，Service T 可以对外提供的服务的契约，所以我们把这个测试用例的集合称为“基于消费者契约的 API 测试”。 那么接下来，我们要解决的问题就是：如何才能找到 Service A 和 Service B 对 Service T 的所有可能调用了。其实这也很简单，在逻辑结构上，我们只要在 Service T 前放置一个代理，所有进出 Service T 的 Request 和 Response 都会经过这个代理，并被记录成 JSON 文件，也就构成了 Service T 的契约。
　　在实际项目中，我们不可能在每个 Service 前去放置这样一个代理。但是，微服务架构中往往会存在一个叫作 API Gateway 的组件，用于记录所有 API 之间相互调用关系的日志，我们可以通过解析 API Gateway 的日志分析得到每个 Service 的契约。
　　至此，我们已经清楚地知道了如何获取 Service 的契约，并由此来构成 Service 的契约测试用例。接下来，就是如何解决微服务之间耦合关系带来的问题了。
　　十、微服务测试的依赖解耦和 Mock Service
　　实现 Mock Service 的关键，就是要能够模拟被替代 Service 的 Request 和 Response。
　　时我们已经拿到了契约，契约的本质就是 Request 和 Response 的组合，具体的表现形式往往是 JSON 文件，此时我们就可以用该契约的 JSON 文件作为 Mock Service 的依据，也就是在收到什么 Request 的时候应该回复什么 Response。
　　下面的图 6 就解释了这一关系，当用 Service X 的契约启动 Mock Service X 后，原本真实的 Service X 将被 Mock Service X 替代，也就解耦了服务之间的依赖，图 6 中的 Service Y 也是一样的道理。