本文要点
- 微服务架构对在线（远程）依赖项的依赖较多，而对进程内组件的依赖较少，您的测试策略和测试环境需要适应这种变化。
- 当使用现有技术（如服务虚拟化）测试单体应用时，您不必同时测试所有内容；相反，您可以分而治之，测试单个模块或一组关系密切的组件。
- 当使用微服务时，还有几个选项可供选择，因为微服务通常部署在容器（如Docker）环境中。
- 您需要管理相互依赖的组件，以便在测试微服务时可以有效地利用时间及控制成本。您可以在微服务测试中使用测试替身（Test Double）达到测试目的。
- 根据您的需要，您可以选用本文列出的其中一个选项或者多个选项的组合。
微服务架构和基于容器的基础设施的组合需要一个适合这个美丽新世界的测试策略。微服务架构对在线（远程）依赖项的依赖较多，而对进程内组件的依赖较少，您的测试策略和测试环境需要适应这种变化。
在线通信越多，测试微服务之间的连接和契约所需的精力就越多。此外，在迁移到基于容器的基础设施时，可以使用若干新的测试技术来处理采用微服务时经常出现的组件依赖。
从上市时间、成本和风险的角度选择测试技术。
当使用服务虚拟化等技术测试单体应用时，您不必同时测试所有内容。相反，您可以分而治之，测试单个模块或或一组关系密切的组件。您可以创建安全的隔离环境让开发人员测试他们的工作。在测试单体应用时，使用服务虚拟化让您可以将测试环境与相关组件解耦，并减少以下问题的影响：
- 难以准备或配置相关组件
- 测试数据准备成本高，耗时多
- 团队因为其他团队没有及时交付API而受阻
- 测试环境时间调度
当使用微服务时，您的选择更多，因为微服务通常部署在容器（如Docker）环境中。在微服务架构中，您的团队可能会使用更广泛的测试技术。此外，由于微服务更多地通过网络进行通信，所以需要更彻底地测试网络连接的影响。使用更适合新架构的工具和技术可以缩短上市时间，降低成本和风险。
许多IT部门使用或维护着采用单体架构开发和部署的系统。典型的单体架构具有以下特点：
- 从事应用程序相关工作的人员被组织成独立的专家团队：UI开发人员、中间件开发人员、后端开发人员、数据库管理员和系统管理员。
- 治理由架构师集中进行——例如，有一组用于代码质量、安全准则和测试方法的全局规则。
- 数据集中管理，因此，单体应用程序通常依赖于单个大型数据库。
- 自动化程度可能很低，有一些自动化测试，但是很少有基础设施自动化。
应用程序开发人员的组织结构经常会影响代码和测试环境的组织方式；这种效应被称为康威定律。通常，代码会被分成几个组件层，如UI、服务和存储库。每个层都是一个单体，它们将被部署到共享环境中，通常包括开发、QA和用户验收测试（UAT），参见图1。