持续测试是 DevOps 开发流程中的重要一环。在很多已经在尝试进行 DevOps 开发的团队中，开发人员往往会将测试自动化等同于实施了持续测试，这种观念其实是错的。
事实上，测试自动化只是持续测试众多要素中的一部分。实施完整的持续测试，需要一个多维度的测试策略，这些策略涵盖开发过程中所有需要的测试类型 —— 包括单元、集成、功能、探索性和自动化。持续测试还必须有一个完整的战略，将测试纳入整个 CI/CD （持续集成/持续交付）的流程。
DevOps 本质上来说是一系列软件开发实践的模型，强调开发人员（Dev）和运维人员（Ops）之间的沟通合作，通过自动化流程，使得软件构建、测试、交付更加快捷、频繁和可靠。这种开发模式的特点是可以把产品的每个迭代，或者每修复一个线上缺陷就立即部署到生产环境，这样一来，开发者就能够迅速从用户处获得反馈并快速做出响应。企业开发团队转向 DevOps，必须在不牺牲软件产品质量的情况下，最大限度地提高交付速度来增加价值和改善用户体验，这些都需要在 DevOps 流程中通过实施 CI/CD 流程来实现，而持续测试在这其中发挥着重要的作用。
总而言之，持续测试不仅仅是在整个软件交付流程中执行自动化测试，还需要持续的业务和技术风险分析，以及整个持续集成过程的流程改进和自动化。从本质上来说，持续测试还是伴随 DevOps 发展出来的一种文化，它要求开发团队中的每个成员都把产品质量当作是共同的责任。此外，持续测试也是一种管理风险的方法，它可以通过提高测试流程的有效性和效率来消除测试瓶颈。
下面是由业内专家总结的持续测试策略四大关键步骤：
1. 简化测试流程
简化测试流程包含三部分内容：关注业务风险、解决测试瓶颈以及优化测试。
业务风险
DevOps 以及持续测试的最终目标都是降低业务风险，而所谓的业务风险实际上是来自于客户和组织两方面的风险组成。
客户风险涉及了解应用程序工作流程中哪个环节对客户来说最为重要，并相应地规划基于这些环节可能出现风险的测试覆盖率。
组织风险涉及了解商业环境以及产品本身的复杂性。例如，是为了抢占市场而让产品率先上市重要，还是产品本身的健康度或安全性更重要？
一旦准确评估了整体业务风险，开发团队应该将需求、应用程序组件和测试映射到这些风险中。
解决瓶颈
在开发测试流程中，识别和缓解可能出现的瓶颈至关重要，这些瓶颈通常是阻碍最终交付产品质量和交付速度最重要的因素。这一过程通常贯穿产品需求到生产上线后的整个软件开发生命周期。
举几个例子，比如在某项待办事项中缺乏测试人员，没有在这一环节建立验收标准，没有及时解决缺陷，导致项目上线延期；比如某自动化测试套件运行时间过长，以及手动完成后期生产检查，导致效率低下。
这一步通常需要开发团队使用一些自动化工具来解决。自动化测试工具是测试人员用来提高测试效率的辅助工具。
就比如在业界家喻户晓的Selenium ，它被认为是 Web 应用程序用户界面自动化测试的行业标准。根据"测试自动化挑战调查"显示，十分之九的测试人员在其项目中使用或曾经使用过 Selenium。但为了有效地使用 Selenium，用户必须具备高级编程技能，并且需要花费大量时间来构建自动化所需的自动化框架和库，这是 Selenium 的主要缺点，虽然可以通过 Katalon Studio 等集成工具解决，但其依然对测试人员的能力提出了较高的要求。
对于测试人员并不充足的团队，也可以使用一些自动化测试平台来解决测试瓶颈。例如由飞算独立研发的飞算 SoFlu 全自动软件工程平台，其全自动测试平台提供了测试生命周期管理、测试数据管理和精准回归测试等一站式自动化测试功能。依托平台的测试用例自动生成等特性，可以让测试人员无需编写脚本，即可快速完成自动化测试工作，提升项目上线效率。
优化测试
如果说依靠自动化测试工具可以解决团队在 DevOps 流程中遇到的效率瓶颈，那么测试优化则是在持续测试流程中实施自动化策略的基础，它要求测试团队选择正确的测试方法，这些测试以最少的测试用例提供团队所需的测试覆盖率，即从策略层面提升测试的效率。
这是一个动态的、持续的过程，尤其是作为连续测试框架的一部分应用时。测试优化应该在自动化之前进行，并且必须在整个连续测试过程中持续进行。第一步通常是通过了解关键用户工作流程中涉及的所有集成来优化测试范围——包括这些应用程序中采用的技术（网络、移动、消息/API 层等）。
一旦团队对测试范围有了清晰的了解，下一步就是优化测试用例。这不仅包括分析测试用例的质量和详细程度，还包括选择提供最高测试覆盖率的测试。团队的测试套件应设计为以最少的测试用例提供最大的覆盖量，以提高质量和速度。前文提到的飞算 SoFlu 全自动测试平台就可以通过录制工具把测试人员的操作过程记录下来，并能够自动识别相关的接口并创建相应的测试用例场景，实现自动优化测试用例。
一些团队默认「每次运行所有的测试」来保证代码覆盖率。这不但浪费资源还延长了测试周期，而且没有真正保证代码覆盖率。测试那些需要测试的部分，以节省时间和资源。可视化模型可以让各种路径被探索优化，以便只用少量的测试用例就能提供最大化的覆盖率。
2. 在整个 CI 流程中实现自动化测试
持续测试需要在整个交付流程中实现测试自动化。测试自动化提高了部署速度并降低了持续交付中固有的风险。
但持续测试框架内的自动化不仅仅是开发和维护自动化回归测试组件。事实上，很多不间断运行自动化回归测试组件会在持续部署过程中造成瓶颈。持续测试需要一个测试自动化策略来增强而不是阻碍持续交付过程。
例如飞算 SoFlu 全自动测试平台提供的精准回归测试功能，该功能在项目测试时能够自动识别所有变动的接口，自动查找接口关联的所有测试用例进行精准回归测试。
自动化测试策略必须在构建过程的每一步都包含自动检查点。首先是验证单个代码片段的单元测试和验证关键特性的组件测试。基于风险的回归测试套件应根据开发者当前正在实施的功能进行定制。
在项目上线到生产环境中时，持续测试要求团队通过部署健康检查系统来确保应用正常运行，生产监控应在客户发现之前发现产品的功能和性能问题。
总而言之，在持续测试策略中，测试自动化必须设计为高效运行（可利用自动化工具），同时提供可靠、一致、可重复的结果。
3. 左移原则
传统测试主要集中在软件开发周期的最后，即产品发布之前的集中测试。为了迎合不断加快的交付频率，越来越多团队的测试活动开始向左右两侧移动。一般问题修复成本较高和面向企业收费的软件，一旦生产环境中出现了问题会造成比较大的损失，通常采取测试左移的方式；对于具有展示功能的软件产品，更容易在生产环境中发现问题，通常采取测试右移的方式。
测试左移是 DevOps 流程中常见的模式，指的是测试人员更早地参与到软件项目前期的各项活动中，在功能开发之前定义好相关的测试用例，提前发现质量问题。早期引入测试过程有助于防止缺陷，并为开发人员提供在整个开发阶段应用动态变更的灵活性。
4. 对质量负责
这一步是持续测试策略的基础，它要求团队中的所有成员（包括开发、测试和运维）都需要为项目的质量负责。
业内专家认为，DevOps 中质量保证不再是测试人员的专属责任，而是全体人员都要为之努力的方向。持续测试的成功实施离不开团队内部及跨团队的协作。测试人员需提前介入到开发工作中，与开发人员一起制定测试计划；开发人员可以参与配置部署；运维人员可以向自动化测试用例库填写测试用例；测试人员随时将自动化测试用例配置到持续交付链中，所有成员的共同目的都是交付高效、高质量的产品。
这种趋势也催生了很多自动化开发、测试和运维工具以降低这些领域的技术门槛。同样以飞算 SoFlu 全自动软件工程平台为例，该平台提供了全自动开发、全自动测试和全自动运维工具，可以管理从需求、研发、测试、部署、上线到运维的整个软件生命周期，真正实现了软件工程开发、测试、运维全流程自动化。这种新兴的全自动工具降低了开发、测试和运维门槛，能够帮助任何一家企业快速构建一支 DevOps 开发团队。
DevOps 打破了开发和运维之间的障碍，缩短了开发周期。其中，持续集成、持续测试、持续交付都是提高质量的关键催化剂，而持续测试则更具挑战性。掌握 DevOps 生命周期的持续测试，对于我们充分理解 DevOps 起着至关重要的作用。
