软件测试中的服务虚拟化（Service Virtualization）

最近几年虽然微服务十分火热，可是仍然有很多人不喜欢微服务，甚至抵制它。其中最主要的缘由就是其成本高，难度大。就困难而言，主要是遇到了一些不易解决的问题，其中包括如下三个与测试数据和测试环境有关的问题：测试面试宝典

1问题一：测试环境被多个团队共同使用

在大规模的微服务系统中，某些核心服务不少时候都是会被多个团队在共同调用，而且它可能也有多个依赖服务。而当一个服务的某个测试环境被多个团队（服务）共同使用的时候，主要会存在如下两个困难点。一、同一测试数据可能会被不一样的团队修改。有些团队经过建立多套测试环境来解决这个问题，可是这样的成本很高。对于不少技术强大的互联网公司，能够经过 Docker 等技术手段来下降一些成本，可是对于不少传统企业来说，高成本的多环境很难实施。二、同一测试数据可能被其余团队占用，所谓的占用就是一个测试数据一旦不当心被某我的使用了，他可能按本身的场景在进行使用，这个时候你去用它，极可能受到影响而得不到本身想要的结果。

2问题二：测试数据准备须要花费大量时间

当测试一些业务不是很复杂的系统时，准备测试数据也许不是一件困难的事情。可是在一些传统行业的复杂系统中，准备测试数据是一项很是困难的事情，好比在银行，保险，通讯等复杂系统中。我曾经测试过一个保险系统，要在测试环境中准备一套数据甚至须要几个小时，由于整个系统的业务很是复杂，数据库设计也很是复杂，并且仍是遗留系统，几乎没有人懂得直接操做数据库来准备数据。所以，数据的准备必须由系统建立。而系统自己是基于 MainFrame 的，并且 UI 所有是 Console 下的 UI，操做十分繁琐和复杂，致使建立一套测试数据须要花费很长时间。不少银行和保险公司的核心系统到如今也是保留这样的模式。因此在这样的传统行业中的遗留系统中，测试数据的准备是一个很是大的问题， 其次不少系统中，测试数据一旦使用了，状态就会改变，从而不能重复使用。因此再次测试就须要从新建立测试数据，这也是一个常见的严重的问题。

3问题三：服务部署或网络等问题致使的测试环境不稳定以及版本不匹配

这个也是常常会遇到的状况。对于一些稳定而没有什么变化的系统，也许这不是一个问题，可是对于一些正在开发过程当中，或者有大量修改或者自己不稳定的系统中，这个问题就十分常见。某些服务部署和网络问题，这个容易理解了，就是依赖的服务正在部署。其次是依赖服务的正在调试，而调试的过程当中，服务自己的一些状态可能在不停的改变。或者依赖服务存在 Bug，致使服务也存在问题。最终，用户可能只须要 1.0 版的依赖服务，但在测试环境中已经部署了 2.0 版的服务，所以用户没法使用服务。

解决方案：服务虚拟化可使用服务虚拟化（Service Virtualization）技术来解决以上这些问题。下图是服务虚拟化的简单示意图：

服务虚拟化看起来虽然简单，可是其实现已经作到很是丰富的功能，好比 Hoverfly 等，从而解决上面那一系列问题。

4Hoverfly

Hoverfly 是一个开源免费（Apache 2）的服务虚拟化的一个工具，其虚拟数据是能够复用的 Json 格式的 Simulation。它是基于 Go 开发的，轻巧，高效。同时支持 Python 和 Java 进行扩展，也提供 REST API 来对其进行控制。而且暂时提供模拟网络延迟，随机错误和限定速率。可是其支持的协议优先，暂时只支持 HTTP 和 HTTPS。可是其最重要的是其支持六种工做模型，它们分别是：Capture 模型，Simulate 模型，Spy 模型，Synthesize 模型，Modify 模型，Diff 模型。经过这六种模型，基本能够实现服务虚拟化的各类功能。首先，经过 Capture 模型能够获取到在手工测试和系统正常使用的状况下，各类服务的交互数据，而后再进行分析和修改，能够得到更多类型的数据。将这些数据经过 Spy、Synthesize、Modify 和 Simulate 模型进行不一样类型的服务虚拟。不一样的团队能够根据基础类型数据快速定制本身团队的私有虚拟数据集，而且还能够根据不一样版本的服务，定制不一样版本的虚拟数据集，从而隔离了不一样版本服务之间的数据，避免了不一样团队之间的的测试数据冲突。

下面就来逐个介绍一下这六个模型。

4.1****Capture 模型

Capture 模型是标准的录制功能。这个时候 Hoverfly 就是一个标准的 Proxy 服务。把它架设在被测的服务和外部服务之间，均可以把全部的交互数据录制成特定的 Json 文件，称之为 Simulation。而后就能够根据不一样的需求更改 Simulation，并用到其余模型里面。

4.2****Simulate 模型

Simulate 是标准的 Stub 模型。能够将经过 Capture 模型录制到的 Simulation 或者手动编写的 Simulation 直接加载进 Hoverfly，而后全部知足 Simulation 里面的匹配规则的 Request 就会返回 Simulation 里面的虚拟 Response，否则就不会返回任何正确的 Response。

4.3****Spy 模型

Spy 模型是一个最为特殊的模型，也是我在正式项目中最经常使用的一种模型。它最特殊的功能就是可让部分请求得到虚拟的 Response，而其余部分请求得到真实的 Response。

所以，经过改变测试数据自己，能够肯定使用的是实际依赖系统仍是虚拟依赖活动。而这种状况下，在传统已有的这种 Stub 工具里面多是须要本身手工去实现的，至少它默认不支持。可是 Hoverfly 是默认就支持，因此只须要把规则加到 Hoverfly 的这个虚拟文件里面，它就能实现这个功能。

其次有些时候在同一个测试环境里面，我既须要虚拟的数据，又要真实数据的状况下，Spy 模型是最佳解决方案。由于只有这样才能以最低的成本，来实现了既能够测真实的数据，又能够测虚拟的数据。

为何会须要这个模型？由于很多时候测试环境不稳定，大规模的回归测试不能依赖于外部服务，因此其须要依赖于虚拟的数据。可是依然要测一些外部的真实服务，为何呢？由于担忧外部服务的升级怎么办呢？那可能升级以后，服务的 Request 和 Response 的 Schema 改了，就会产生一个 Bug。现实中会把一些所谓的重要的场景，依然是跑真实的外部服务，这样就算它的外部服务的 Schema 更改了，测试就能够在第一时间发现这个更改。

因此，这是一个最为经典和实用的模型。

4.4****Synthesize 模型

Synthesize 模型最主要解决的一个需求是根据不一样的状况返回动态的 Response 数据。

因此，这个时候实际上是 Hoverfly 提供一种中间插件的功能，能够在开发一个基于 Python 或者 Java 的中间插件，当某个 Request 收到以后，能够对这个 Request 进行加密解密，进行一个特定的判断，以后再返回一个特定的 Response。

能够对 Request 进行判断、处理，对 Response 进行一些特定的组合，并非一个固定的值，或者说固定的某一到两个值。

4.5****Modify 模型

Modify 模型要等待真正的 Request 收到后，才能将 Request 转换为特定的内容，并发送给外部依赖，而外部依赖返回到 Response，再返回到特定的模式，以实现特定状态的虚拟。

好比须要模拟一个 Request 里面被加了某些东西，或者是作一些混淆，产生一些特定的用例，或者更改真实的 Response 中的某些数据等。

4.6****Diff 模型

Diff 模型至关于一个变异版的契约测试方案。首先当被测系统的 API 的时候，它会将依赖服务的返回数据保存起来。当下一次执行相同的测试用例的时候，它会把上一次的和本一次的依赖服务返回的数据的进行比较。

若是下一次的和第一次存储的的 Schema 有不同的，那这个时候 Hoverfly 会报警，并显示出来两次不同的内容。这个就至关于就作了一部分被测系统和依赖系统之间的一种被动的契约的检查，虽然它不属于一个完整契约测试方案，可是至少作了单边的契约检查。

为何要选择 Hoverfly？

首先服务虚拟中心化，它是基于 Proxy 模型的，因此在它只要加一台机器搭建一个服务就能够了。其次它是非侵入式的，它是不须要改动被测系统的代码或者配置的，而只须要改动 JVM 本身的 property 或者是操做系统的 Proxy 配置。而后其灵活性很高，它支持各类模型，使用很是方便。最后它是开源软件，因此若是有特定的定制化需求，能够本身修改后供本身使用。

5总结

随着传统 Stub 和 Mock 服务技术的发展，以及微服务系统开发中对于服务测试的各类问题和需求，服务虚拟化孕育而生。服务虚拟化是对 Stub 以及 Mock 技术的提高和系统化，功能更为强大，从而能够更加容易使用和定制化，以便知足服务测试的各类新需求，解决各类新出现的问题。测试面试宝典