微服务场景下的自动化测试

　　如果使用Spring，还可以通过profile来切换不同的数据库。比如下面这个例子中，默认的profile会连接数据库jigsaw，而integration的profile会连接jigsaw_test数据库：

　　组件测试会涉及到的组件包括：
　　· URL路由
　　· 序列化与反序列化
　　· 应用对领域层的访问
　　· 领域层对数据的访问
　　· 数据库访问层
　　· 前后端分离
　　除了后端的测试之外，在目前的前后端分离场景下，前端的应用越来越复杂，在这种情况下，前端的组件测试也是一个测试的重点。
　　一个前端应用至少包括了这样一些组件：
　　· 前端路由
　　· 模板
　　· 前端的MVVM
　　· 拦截器
　　· 事件的响应
　　要确保这些组件组合起来还能如预期的执行，相关测试必不可少。这篇文章详细讨论了前后端分离之后的测试及开发实践。
　　契约测试
　　在微服务场景中，服务之间会有很多依赖关系。根据消费者驱动契约，我们可以将服务分为消费者端和生产者端，通常消费者自己会定义需要的数据格式以及交互细节，并生成一个契约文件。然后生产者根据自己的契约来实现自己的逻辑，并在持续集成环境中持续验证。
　　Pact已经基本上是消费者驱动契约（Consumer Driven Contract）的事实标准了。它已经有多种语言的实现，Java平台的可以使用pact-jvm及相应的maven/gradle插件进行开发。
　　· pact/pact-jvm
　　· pact-broker

　　(图片来源：Why you should use Consumer-Driven Contracts for Microservice integration tests)
　　通常在工程实践上，当消费者根据需要生成了契约之后，我们会将契约上传至一个公共可访问的地址，然后生产者在执行时会访问这个地址，并获得新版本的契约，然后对着这些契约来执行相应的验证过程。
　　一个典型的契约的片段是这样的（使用pact）：

　　端到端测试
　　端到端测试是整个微服务测试中困难的，一个完整的环境的创建于维护可能需要花费很大的经历，特别是当有多个不同的团队在独立开发的场景下。
　　另一方面，从传统的测试金字塔来看，端到端测试应该覆盖那些业务价值高的Happy Path。也是说，端到端测试并不关注异常场景，甚至大部分的业务场景都不考虑。要做到这一点，需要在设计测试时，从终用户的角度来考虑，通过用户画像和User Journey来确定测试场景。
　　在端到端测试中，重要的反而不是测试本身，而是环境的自动化能力。比如可以通过一键可以将整个环境provision出来：
　　· 安装和配置相关依赖
　　· 自动将测试数据Feed到数据库
　　· 自动部署
　　· 服务的自动重启
　　随着容器技术和容器的编排技术的成熟，这部分工作已经可以比较好的自动化，依赖的工具包括：
　　· Docker
　　· Rancher
　　一个典型的流程是：
　　· 搭建持续发布流水线
　　· 应用代码的每一次提交都可以构建出docker镜像
　　· 将docker镜像发布在内部的docker-hub上
　　· 触发部署任务，通过rancher的upgrade命令将新的镜像发布
　　· 执行端到端测试套件
　　端到端测试还可以细分为两个不同的场景：
　　· 没有用户交互的场景，如一系列的微服务组成了一个业务API
　　· 有用户交互的场景
　　UI测试
　　顶层的UI测试跟传统方式的UI测试并无二致。我们可以使用BDD与实例化需求（Specification By Example）的概念，从用户使用的角度来描述需求，以及相关的验收条件。这里我们会使用WebDriver来驱动浏览器，并通过诸如Capybara等工具来模拟用户的操作。
　　· BDD工具：Cucumber
　　· Web应用验收测试工具：Capybara
　　· Page Object的DSL工具：Site_prism