测试需要花费成本
软件开发和交付正在从复杂、独体式应用程序朝更加分布式、以服务为中心的架构转变，前缀的许多依赖关系在编译时解析，而后者的依赖关系在运行时解析。大部分企业应用程序都是最初为比云更早的环境设计的现有应用程序（也称为记录系统）与在云中开发的新 “互动参与系统” 应用程序的组合。由于它们具有众多依赖关系，它们的架构可能很复杂，而且它们使用 API 来衔接现有记录系统和新的互动参与系统。它们利用 API 管理和云集成技术来实现集成，同时满足企业的安全需求。它们的工作负载可能跨多个环境运行：内部部署、私有云、公共云，这些环境组合在一起形成了一种也称为混合云的架构。
“持续集成使项目团队能够在需要时执行测试，而不是尽可能多地执行测试。”
混合云架构正变成启用了云的应用程序和云原生应用程序的标准。混合云提供了部署灵活性，使企业能够选择正确的平台来处理其工作负载（用于混合云的 DevOps：IBM 观点，2016 年 2 月）。据 IDC 预测，到 2017 年，80% 的 IT 公司会致力于建立混合云架构（IDC FutureScape：2016 年全球云预测 - 掌控数字转型原动力，2015 年 11 月）。
IBM 观点是，测试改进可为公司带来重大节省和竞争优势。测试是一个亟需更好流程的领域 - 因为预计到 2018 年，质量保障的平均花费占总 IT 预算的比例将会上升到 40%。事实上，许多企业在测试环境上花费了超过 1/3 的测试预算（2015-16 年全球质量报告：Capgemini、Sogeti 和 HP），这使得花费的成本变得更高。
ADT 最近举行的一次调查发现，目前，测试是导致生产部署延迟的首要原因（ADT 研究白皮书：企业越来越依靠持续部署来恢复活力）。IBM 通过使用分析和测试洞察，致力于优化测试和相关部署操作，以便能够将更多资源用于创新。
为什么要努力实现持续测试？
企业要快速向市场推出高质量的创新解决方案，整个交付团队需要鼓励和接受所有反馈。这些反馈渠道不仅需要出现在开发和运营团队之间，还需要出现在整个交付生态系统（包括业务分析师、开发人员、设计师、架构师、测试人员、版本经理、第三方供应商等）与业务利益相关者之间。业务利益相关者要求测试人员确保已定义的流程和事务将按预期运行。测试人员寻找途径来最小化测试活动的成本和影响。持续测试通过提供解决方案质量的即时反馈，加强了整个团队的信任。对于业务利益相关者，持续测试提高了对一次交付值得依赖和影响业务的风险极小的信心。对于项目交付团队，持续测试技术和工具最小化了测试的影响，这可能减少项目成本，实现更快的解决方案交付，而且最重要的是，可以确保提供高质量、可靠的解决方案。
对质量和速度的需求
业务利益相关者要求项目团队尽快地交付新应用程序、集成、迁移和更改。而项目团队要求其测试人员确认：
- 技术环境按要求运行
- 业务流程和事务按预期运行
- 解决方案可扩展来满足预期用途
- 应用程序是安全的，用户数据受到保护
无论涉及哪些行业或技术，都需要仔细平衡速度与质量。随着云技术的运用越来越广泛，软件团队手头拥有比以往更多的工具来提高其工作效率。但是，尽管软件和系统开发人员竭尽全力避免犯错，人为错误仍然无法避免，这正是我们执行测试的原因。不测试所带来的风险比执行少量测试的成本要高得多。
随着敏捷实践和 DevOps 实践被越来越多地采用，在每次迭代中重新执行手动测试成为了一种不可持续的模式。没有足够的时间，无法增加更多人执行手动回归测试，这些都会导致回报递减。更重要的是，对开发人员的反馈速度太慢，这会显著降低生产力。测试效力是跟上更快节奏的开发生命周期的一个关键。通过运行最少的测试来找出最多的问题，可以优化测试效力。甚至在更传统的开发生命周期（其中所有测试都在单个阶段中执行）中工作的团队也发现，他们无法在每次获得新编译版时都跟上回归测试的进度 - 将缺陷补丁、对现有特性的更改以及甚至新功能都捆绑到新编译版中。下图表明经过几次迭代后，新特性数量以及由此导致的测试数量已显著减少。
点击查看大图
跟上需要的回归测试节奏的唯一方式是自动化正确的测试集。为了达到这种平衡，成熟的 DevOps 团队采用了自动化测试与手动探索测试相结合的方式，两种测试都持续地运行。
查找正确的测试集
尝试自动化所有测试是不可能的，尝试这么做的成本最终会超过收益。对于任何相当复杂的应用程序，都无法测试经由系统的每条可能路径，因为即使应用程序中仅有一个循环，可能路径的数量也会变得无限多。如果再加入测试数据排列组合，您很快就会发现尝试测试所有功能是行不通的。关键在于识别最重要的测试子集 - 在这些测试中，您：
- 通常会发现问题
- 看到过性能退化
- 收到过客户抱怨
- 知道发生某一故障可能带来重大甚至灾难性的影响
对新代码更改的影响分析，是确定运行哪些回归测试的关键方面。但是，如果没有良好的更改集输入，代码更改数据和分析可能具有误导性。对哪些是要自动化的 正确测试的这种分析应涉及整个团队，从业务到开发，到测试，再到运营和支持。每个角色对于哪里可能出错和已经出错具有不同的视角，所以让每个人都参与进来很重要。
一些可应用测试自动化的例子包括：
- 数据驱动的测试，其中的数据集很复杂且涵盖一些关键方面
- 业务逻辑验证，用于确保获得正确结果
- 与第三方系统的集成，其中开发人员和测试人员可能没有第三方系统的完整访问权
- 低强度的性能测试。跨不同编译版进行小规模的压力、负载、卷或内存泄漏检查，以便在执行正式负载测试之前尽早识别性能降级
- 跨许多平台和操作系统来安装和升级客户安装的商用软件
- 扫描安全漏洞，尤其是在财务和个人信息处于风险中时
测试自动化实现具有各种各样的形式，一些重要示例包括：
- 单元测试
- 用户界面 (UI) 层的功能测试
- 通过 API 的功能测试
- 通过 UI 或 API 的性能测试
- 安全测试
此外，还有一些在手动执行时非常有价值的测试。通过测试自动化并行执行这些测试：
- 探索测试。未脚本化的测试，其中测试人员分析系统的不同方面，但没有规定的最终结果。这有助于找到存在缺陷但未涵盖在自动化测试的范围内的新场景。
- 可用性测试。要求最终用户测试系统的特定方面，并在测试过程中提供言语反馈。这使团队能够更好地了解用户使用系统时在想什么。
“提前” 智慧地进行测试
您是否层听说过 “更智慧而不是更艰难地测试”？不幸的是，虽然测试和开发经理经常将此理念传达给他们的团队。但是，他们没有为如何实现这种 智慧测试提供指导。团队忙于尝试跟上现有测试的节奏，而没有时间自行执行测试。
智慧测试的一个关键方面是在交付生命周期中更早或更频繁地测试，或者 提前测试。这样，团队可以尽早测试风险最大的元素，然后可以不断重用这些测试。尽早地直接向开发团队提供代码质量的迭代式反馈，以确保在生命周期的后期发现的问题更少（这时发现的问题的修复代价更高），这就是更智慧的方法。
想象一个正在运行的应用程序具有低质量和差评的情形。下面这个场景描述了项目团队如何在需要时而不是尽可能改进其测试能力和执行测试自动化。
首先，所有利益相关者（业务、开发、测试、运营等）协同理解生产后期的缺陷的根源。使用缺陷数据和分析，团队发现最重要的缺陷来自两个区域：
- 与其他系统的集成
- 响应时间延迟
团队确定他们需要在开发流程中的更早阶段测试高风险集成，而不是等到部署到生产之前才测试，所以他们合作并建立达成一致的接口和数据定义作为其系统架构的一部分。
他们还决定在一个编译版可用后立即执行一些低强度性能测试，以便可以更早地识别和修复关键性能问题。他们将在每个编译版中跟踪这些性能测试，所以能够立即获悉是否发生了任何性能降级。
基于这些接口，开发人员和测试人员联合为每个高风险接口创建虚拟服务或存根。接口存根模拟其他系统，允许开发人员和测试人员在开发流程中的更早阶段测试高风险区域 - 编写和编译代码后立即测试。
然后，团队自动化许多功能集成测试和关键响应时间测试，因为大部分重大生产缺陷都来自这些方面。
现在只要创建了一个新编译版，成功的编译过程就会触发如下所示的自动化活动：
- 新应用程序编译版会安装在自动配置的基于开发云的测试环境中。
- 启动缺少的依赖服务的存根。
- 触发并执行一个自动化集成测试套件，随后执行低强度性能测试。
- 捕获测试结果并将反馈提供给整个团队。团队分析结果中是否存在任何退化，尤其是性能方面的退化。
- 集成和性能测试通过后，会将开发测试环境中的一个应用程序快照部署到系统测试环境。
- 触发并在系统测试环境中执行基于测试套件的自动化用户界面。
- 再次捕获测试结果，提供反馈，处理缺陷，并创建新编译版。
依赖系统可用后，团队再次针对实际系统运行这些相同的自动化集成和性能测试，以确认其应用程序的行为仍符合预期。
此方案可应用于任何缺陷模式。它使整个团队不仅能协同在生命周期中更早开始测试，还能首先自动化最重要的测试，以便反复执行这些测试。这可确保测试很好地覆盖应用程序中风险最高的部分。
实现持续测试
建立持续测试文化需要投入人员、实践、工具和时间。下图显示了创建持续测试流程通常涉及的实践。
应用传统测试方法时，缺陷是测试人员和开发人员的初始沟通渠道。测试人员认为 “我找到了一个 bug ！”，开发人员随后会同意或不同意代码存在问题。许多时候，缺陷并不是代码自身的问题，而是需求、设计或者甚至测试的问题。有时，问题出在应用程序之外 - 在测试环境、测试数据、测试脚本本身或者这些方面的组合因素中。拥有一个协作式环境来记录和跟踪缺陷，这对任何软件开发生命周期都是不可或缺的，但谈到采用正确的实践集合，跟踪缺陷只是冰山一角。
测试团队通常采用的下一批实践之一是测试管理 - 规划测试工作，识别需要的测试，创建手动测试，收集现有测试，执行测试，并跟踪和报告测试进度。此测试管理实践可帮助团队和管理层大体了解测试通过、失败还是阻塞了。它也可以回答以下问题：测试工作按计划、延后还是提前完成？
当团队发现手动运行所有测试是低效的、无效的，而且在许多情况下完全不可能时，接下来通常就需要执行测试自动化实践。如果未当作一个软件开发项目来实施，成功地创建稳健且可维护的测试自动化框架可能很难。需要有共同的愿景、需求、架构、设计，甚至在某些情况下具有相同的代码，最终确认自动化实现了想要的结果。没有这些方面，测试自动化框架就可能很脆弱、难以维护且重构成本很高，而且常常被遗弃。
随着测试自动化的进行，测试分析和洞察实践会开始增多来回答以下问题：我们应在何时运行哪些测试？为什么运行它们？代码更改影响分析可能是一项困难的任务，尤其在开发人员对其代码更改集的要求不严格和不一致时。了解自上次编译以来发生了哪些变化，这对选择要运行的正确的测试集至关重要。如果缺少这种分析，过渡测试或重新测试所有功能是一个诱人但成本很高的解决办法。
测试的另一个关键方面是创建测试环境。配置自动化测试环境具有巨大的好处。自动化地创建和配置测试环境，可以将开始测试一个新编译版所花的时间从几小时或者甚至几天或几周缩短至几分钟。这种自动化也减少了由于测试环境问题、错误地安装的依赖软件，以及其他引入问题的手动流程所导致的虚假错误数量。在 IBM DevOps 案例中，测试自动化与自动化的部署是同时进行的。
结合测试执行和测试环境自动化、服务虚拟化或 存根，可以显著提高测试工作的效率。通过从已知且达成一致的接口创建虚拟服务，开发人员和测试人员可以为同一个接口编写代码和执行测试，甚至在依赖系统不可用时也能如此。通过对这些已知接口执行测试，测试可以更早地开始和更频繁地运行 - 对每个编译版都运行测试。服务虚拟化还支持测试可能不容易对真实系统测试的场景 - 例如：
- 异常和错误
- 缺少数据
- 响应时间延迟
- 大量数据或用户
通过将服务虚拟化整合到整体测试工作中，团队可以首先构建并有效地测试系统中风险最高的部分，而不是构建和测试系统中容易测试的部分。当您自动化对系统中这些风险最高的部分的测试，并在每个编译版上执行它们时，测试就能更好地覆盖这些部分。这可以确保在创建新编译版时快速识别退化。
一个典型的场景可能是，移动和 Web 开发团队开发云应用程序，而大型机团队开发内部部署应用程序。借助服务虚拟化，IBM 将这些混合云场景中的环境依赖关系分离开来。然后，团队可以按自己的速度构建和测试，并采用符合其文化的正确的 DevOps 方法。
另一个会提高测试效率的测试方面是拥有正确的测试数据集。使用尽可能接近生产数据的测试数据，这样可以更好地覆盖更多场景。从生产环境中提取数据并出于安全目的而进行屏蔽，可提供逼真的测试数据集。良好的测试数据集还使团队能够创建平时可能难以测试的异常或错误场景。
通过通力合作，一组有效的测试实践使整个团队（而不只是测试人员）能够改进质量，减少交付新功能所花费的时间。这些实践消除了依赖关系和瓶颈，支持在生命周期中更早执行测试和持续执行测试 - 而不需要传统测试环境通常要求的过多投资。
结束语
采用混合云战略的公司从未像现在这样渴望 “快速提高质量” - 一些项目在云中开发，一些项目在企业内部开发，所有项目都需要在部署后无缝地协同运行。
我们将测试自动化与服务虚拟化的组合称为 “持续测试”。在生命周期中更早和更频繁地执行测试（“提前测试”），使团队能够持续地编译、部署、测试和收集反馈。尽早地直接向开发团队提供代码质量的迭代式反馈，以确保生命周期的后期发现的问题更少，修复此时发现的问题的代价更高。在生产中发现问题时，不仅解决成本非常高，而且可能严重损害公司的声誉，甚至对客户忠诚度产生持久的影响。如果没有及时的测试和反馈，公司无法真正地快速提高质量。
本文转自：http://www.ibm.com/developerworks/cn/devops/d-continuous-testing-shift-left-trs/index.html
