软件测试中的微服务

软件测试中的微服务

问题

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

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

在大规模的微服务系统中，某些核心服务很多时候都是会被多个团队在共同调用，并且它可能也有多个依赖服务。而当一个服务的某个测试环境被多个团队(服务)共同使用的时候，主要会存在以下两个困难点。

2、同一测试数据可能被其他团队占用，所谓的占用就是一个测试数据一旦不小心被某个人使用了，他可能按自己的场景在进行使用，这个时候你去用它，很可能受到影响而得不到自己想要的结果。

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

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

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

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