持续集成（CI）解决测试环境难题

集成测试是用来验证所提交的系统的地方，也是企业可以实际查看应用程序并确认已构建的开发是否是其所需要的开发的地方。随着软件系统变得越来越组件化，而且由越来越多的服务组成，从代码更改到集成测试的延迟时间成为了产品投入市场和开发人员生产力的一个关键指标。

理想的过程很简单。每次开发人员更改代码，就快速运行所有测试，并将反馈提交给开发人员。发生更改的组件被构建、单元测试、部署到一个集成环境，所有集成测试只需几分钟即可运行完。

不幸的是，对于许多团队而言，理想过程是不现实的。自动化测试要么进行的次数太少或进行的时间太长，可能无法实现持续集成。复杂应用程序的自动化部署可能需要特殊的工具。

目前，我们对如何解决这些难题已经有了很好的了解。应该使用大量的 API 测试来自动化测试。建立一个连续自动构建流程很简单，所以没有理由不创建这样的流程。现在，让我们来了解一些部署自动化工具。

然而，许多组织面临一个越来越常见的挑战，那就是缺乏集成测试环境。这些集成测试环境可能是不完整的，或者可能是不一致的。只了解这些可能是不够的。本文将考察为什么存在这些问题，以及如何处理它们。

环境方面的限制

了解如何获得更多、更高质量的测试环境来加速反馈，您需要了解环境方面的一些约束条件。以下这些知识可以帮助您解决问题。

• 有限的硬件：运行测试环境所需的资源。这些资源并不是免费的。
• 昂贵的设置费用：建立一个新的测试环境需要配置服务器、配置中间件并让应用程序运行。这些任务需要做相当多的工作。
• 昂贵的维护费用：需要努力维护配置、补丁水平等，与此同时，测试环境的数量也在增加。
• 不一致的利用率：有时一个团队需要多个环境，有时他们需要几个环境。
• 昂贵的组件：一些应用程序组件在用于测试时非常昂贵，这限制了您使用它们进行测试的频率。按照事务、主机组件和设备应用进行收费的第三方 Web 服务事务也是制约因素。
• 缺失的组件：有时另一个团队拥有一个您需要测试的服务，但他们还没有交付该服务。这使得您拥有了一个不完整的解决方案。
• 被破坏的组件：当许多组件可能经常发生更改的时候，给定组件遭到破坏的可行性很高。

通常，这些集成测试环境特征是相辅相成的。例如，对于长期存在的环境，昂贵的环境设置费用是可以容忍的，但是，由于不一致的利用率，对环境的需要可能是短暂的。维护那些一直受到维护的环境会容易一些。不幸的是，由于硬件成本，合理的做法是在不使用它们时关闭它们。

解决瓶颈的技术

有三种技术可用来消除集成测试环境中的问题并提高它们的可用性：环境预留（environment reservation）、环境即服务和服务虚拟化。每项技术负责解决问题的不同部分。

环境预留

最简单的策略是积极安排和管理环境。这通常是发布经理（release manager）的责任。集成环境被视为宝贵资源，集成环境是根据发布优先级和距离发布日期的时间被分配用于版本测试的。现代版本管理工具（比如 IBM UrbanCode Release）可以提供正式的环境跟踪、调度和冲突检测，但电子表格仍被经常使用。

优势

清楚地描述哪些版本可以使用某个环境，何时为开发和测试团队提供所需的可预见性，并从有限的资源中获得最大的价值。

局限性

虽然环境预留有助于确保有限的资源得到很好的使用，但它并不会提供更多的环境或导致环境不一致。

环境即服务

请求一个适合您的应用程序的测试环境并在几分钟内配给好它的能力是非常强大的。将云技术（公共云或私有云）与环境模式引擎（比如 UrbanCode Deploy with Patterns 相结合，使用它们来搭建环境、配置环境并在需要的时候退出环境。

优势

使用环境即服务解决方案可以大大减少搭建测试环境需要做的工作。这些解决方案还适当地更新了配置，以便有效地控制维护费用，同时改进生成环境。总而言之，团队可以在需要的时候得到他们所需的集成环境。环境即服务技术应该是您的集成测试策略的基石。

局限性

以较低的成本创造环境往往会鼓励创建更多的环境。硬件费用可能是一个问题，特别是在非常大的集成环境中。使用相对廉价的云资源来构建环境有助于降低环境搭建成本。因为环境易于创建和退出，所以人们经常使用环境。相反，您可以在不使用资源的时候回收资源，并在需要的时候执行环境备份。

因为这个策略是建立在云计算和虚拟化之上，许多 “珍贵” 的组件无法作为一种服务策略巧妙地融合到环境中。它们需要由多个已配置好的环境进行共享，或者需要虚拟化。

来自其他团队的遭到破坏的组件可能是一个问题，但是，如果各大团队都有自己的集成环境，而且使用了其他组件的惟一已知良好版本的自动化部署，那么他们可以使用环境即服务（environments as a service）来实现隔离的环境作为一种服务。

虚拟化服务

服务虚拟化使用 “存根（Stub）” 或 “模拟物（mocks）” 替换了系统中的一些组件。模拟是我们已经使用了很长一段时间的一种方法。开发人员编写了一个功能类似于完整服务的一项服务，并对它进行了测试。例如，如果一个股票报价服务提供了每笔交易的第三方费用，那么开发人员就可以创建一个替代服务，该服务将会提供相同的 API，但总是返回相同的值来进行测试。服务虚拟化工具类似于 IBM Rational Test Workbench 中的那些工具，简化了创建存根的过程，并对运行它们的地方和执行它们的方式进行管理。

优势

服务虚拟化提供了一个简便方法来处理这些 “珍贵” 组件。存根可以替代那些按使用进行收费的组件，或者替代那些独一无二的组件（主机、昂贵的中间件或设备）。

存根还可以替代那些来自其他团队的组件。存根有三个主要优势：

• 一定程度的隔离。您有一个很有用的集成测试环境，甚至在另一个团队破坏了他们的组件的时候也很有用。
• 资源的使用。不再需要那些用来运行其他组件所需的服务器容量。
• 存根可以替代那些尚未完成的组件，让您在生命周期的早期就能访问集成的测试场景。

局限性

在测试真实的东西而不是存根的时候，测试是更加相关的。隔离功能可以防止另一个团队破坏您的工作，但也会推迟整个集成系统的测试。推迟测试会带来一定的成本，因为它减缓了反馈。服务虚拟化无法帮助管理已经存在的组件环境。
在这里想大家推荐一个资料分享群：175317069

汇总了一些技巧的一个现实场景

一个被称为 Marketplace 的主系统的虚拟示例展示了如何组合使用这些工具。Marketplace 由许多部件组成。

• 60 个紧密耦合的 Web 服务。四个团队，每个团队拥有 15 项服务。
• 主机组件促成了 20% 的交易；这些组件很少发生更改，而且属于另一个团队。
• 前端网站（位于服务的前端）是属于网站团队的。
• 使用了来自两个第三方的数据提要（通过 Web 服务）。一个是按交易进行计算的，另一个不是。

Marketplace 版本团队有一个大型的集成测试环境 (INT) 和一个性能测试环境 (PERF)。每六个团队拥有一个小型的测试实验室，在该实验室里，他们可以测试一些组件，但是他们不能测试任何集成场景。集成测试是按照版本发布时间表进行的，而版本管理控制了对 INT 和性能环境的访问。

团队级集成环境

为了提高开发人员的生产力，Marketplace 组织决定确保每个开发团队都有自己的集成测试环境，如果他们想要测试额外的代码行或者想要达到更高的发展高峰，他们能够获得额外的环境。

• 环境即服务 (EaaS)：EaaS 工具提供了使用公司内部云应用的一份副本。使用了获得开发团队的服务所需的足够多的虚拟机器，以及最新的 UI 工作副本。
• 服务虚拟化：来自其他 Web 服务团队的服务和主机被虚拟化。已计量的第三方服务被虚拟化，但其他服务是被实时使用的。
• 环境预留：为了获得可见性，让 Release Management 工具中的预留系统知道在哪个环境中托管了版本发布工作。不过，由于不缺少环境，所以团队级别的环境没有被保留。

最后，每个开发团队都有一些大量使用了服务虚拟化的小型的、廉价的环境。尽管他们能够在更大的系统中测试他们的组件，但他们是独立于其他团队的。其他团队可能破坏了自己的组件，或者担心自己会破坏其他团队的组件。然而，大量利用虚拟化意味着跨服务的集成问题不会立即被发现。

版本级别的集成环境

每个版本的系统集成测试环境都已配置好。这些环境大部分都是完整的，而且只使用了最低限度的服务虚拟化。要进入该环境，必须在团队级别环境中成功地将更改传递给一组可靠的自动化测试。

• 环境即服务：EaaS 可以提供许多可能长期存在的环境：
  • 一个测试环境，用于为当前版本提供补丁
  • 一个大量使用的环境，用于即将发布的版本
  • 一个偶然使用的环境，用于稍后执行的大量开发工作EaaS 主要负责让环境与正确的基础架构相一致。
• 服务虚拟化：只有主机和已计量的 Web 服务被虚拟化。
• 环境预留：这些环境都是大型环境，所以硬件都比较昂贵。在需要额外的环境时，可能会使用环境预留来观察实例，尽可能地减少对额外环境的使用。与团队环境类似，此系统主要用于确保每个人都对正确的版本使用了正确的环境。

因为大量的集成测试都是在团队级别环境中执行的，所以在这个环境中，干扰测试的更改非常少。对于手动测试者，这些环境可能会花费他们的时间，他们可以从高可用性的组合中受益，而且总是采用最新的好代码。

性能测试

性能测试基本上没什么大的变化，仍然是最大的环境。服务虚拟化对 Web 服务和主机均可用。对于主机和计量服务，在执行事务数量较多的测试过程中偶尔会使用虚拟化。在其他性能测试场景中，用于两个第三方 Web 服务的存根均被设置为缓慢回应请求，以便在第三方供应商遇到麻烦时验证应用程序的行为。

最终的集成测试

集成测试环境被用于最终的集成验证。因为它提供了对一些稀有资源（比如计量服务的实时版本和主机组件）的访问。环境预留系统仍用于将此资源分配给所期望的版本。

模式

上述示例中经过检查的模式是一种非常常用的模式。开发人员更喜欢使用小型的、高度虚拟化的环境。因为他们可能经常使用和关闭环境，并积极地利用环境配置。在这种环境中，环境配置被用于构建更完整的集成环境，而服务虚拟化提供了更少的东西。在后期的测试环境中，以前的资源被安排并分配给版本。在最能发挥每种方法的作用的地方使用它们，用其他方法的优势来弥补每种方法的局限性。通过这种方式，团队可以从资源调度、服务虚拟化和环境即服务的组合使用中获得最大的好处。

当真正开始学习的时候频繁踩坑，最终浪费大量时间，所以有一套实用的视频资料用来跟着学习是非常有必要的。

这套视频资料详细讲解了（自动化编程，mysql调优，自动化框架rf使用）。

那么，这套视频我们应该怎么获取呢？

对以上测试资料，测试技术 感兴趣的朋友，欢迎加QQ群：175317069，一起学习，相互讨论。

群内已经有小伙伴将知识体系整理好（笔记，学习视频，面试题），欢迎加群免费取。