持续测试

在我开始写这个文章之前，我一直以为持续测试就和持续集成、持续交付、持续部署一样，有明确的阶段性定义的一个概念，当我开始不断的查资料，我得到了无数个持续测试的定义。有的定义清晰，有的定义模糊，每个文章都有自己的定义，那么我将这些文章的内容的重叠部分尝试用简单的方式描述出来，希望能整理清楚持续测试是什么。

持续测试是什么

说到持续测试，我发现大部分网站中用的是 Tricentis 公司的 CMO 的 Wayne Ariola 在公司的博客中的 Continuous Testing: “Perfect” Software Is not the Goal 文章中给出的定义，“持续测试侧重于业务风险并提供有关软件是否可以被发布的决策基础。自动化测试对于连续测试至关重要，但它并非全部。自动化测试旨在生成一组与用户故事或应用需求相关的通过/失败数据检查点。而持续测试侧重于业务风险并提供有关软件是否可以被发布的决策基础。除了将测试用例自动化，持续测试还包括了诸如验证业务风险，应用服务虚拟化和状态化测试数据管理以稳定持续测试；在每个迭代中使用探索性测试来尽早发现阻碍性问题等实践。它不单是意味着使用更多的不同的工具。它要求的是包括技术在内的人和流程的深度转变。”除去这个定义，还有一些引用了 Thomas Hamilton 在 Continuous Testing in DevOps: What is, Definition, Benefit, Tools 中给出的“持续测试是 DevOps 中的一种软件测试类型，它主要是约束在软件开发生命周期任何一个阶段都有对应的测试活动，从而提早的进行频繁的测试，这也就实现了在持续交付过程中每一步都有了质量评价活动从而也就实现了持续测试”。除去这两个饮用比较广泛的，还有一些不是定义的定义，就不详细描述了，我稍微整理一下这些翻译，最中给出的持续测试。

持续测试是在软件交付生命周期过程中，以防控业务风险为目的，将每一个阶段都通过测试活动进行质量保障，尽最大可能自动化测试活动，并将测试结果不断的反馈给制品过程的测试实践活动。这也可以看出来，每一个质量活动环节都能够快速及时的反馈给正确的干系人才是持续测试的基础。

持续测试有什么

传统的测试和其他团队中的角色有明显的交付过程，交付也是传统 IT 团队最明显的合作方式，产品经理讲产品将交付给开发团队后，开发团队将开发调试成功的系统交付给测试，测试将通过测试的系统交付韵味。这种瀑布的交付就和当前要求快速交付，快速验证的思路有点像左。

持续测试也就意味的不断的测试、频繁的测试，这既包含了要不断的有需要测试的系统，也包含了制品过程中的每一步都要测试。

• 不断的有需要测试的系统，这也是持续测试给前序制品获得的要求，也就是不断的有系统交付给测试，这也就说明要实现持续测试的一个条件就是要实现持续交付。

• 制品过程中的每一步都要测试，是指需求部分的质量保障活动、开发阶段的测试活动以及 QA 部分的测试活动，乃至上线后的质量保障活动

持续测试怎么做

从上面的持续交付的定义可以看出来，只有团队实现了持续交付才有可能完成持续测试的一个部分的内容，这也就牵出了对于交付流水线的要求，每当开发人员 checkin 代码的时候，像 Jenkins 这样的流水线工具会线执行静态代码扫描、单元测试。 如果扫描结果、单元测试结果、测试代码覆盖度都满足了逾期要求，那么构建通过测试，则将其部署到 QA 环境中，然后调用单接口自动化测试、业务场景接口自动化测试、自动化 UI 测试完成自动化测试验证，通过后通知测试工程师进行探索测试。这个过程就是在持续交付基础之上的持续测试。这些都是需要 DevOps 流水线才能支持的。

在制品过程中的每一步都要有测试活动，这主要是包含了上面基于持续交付的测试活动，还包含了测试左移和测试右移。

测试左移

“测试左移”的概念最早出现在 Arthur Hicken 发表的文章中。Arthur Hicken 提出：为了弥补瀑布模型的不足以及避免测试工作成为系统交付前的最后且唯一的质量保障手段，测试应左移并贯穿于项目的整个研发生命周期。这也说明测试工程师在项目的需求分析阶段就应该参加相关活动，从而在需求分析阶段就站在测试角度补充各种 AC（Acceptance Criteria，验收准则）。从需求分析开始到测试业务分析，再到测试用例设计、测试执行以及测试结论总结，都应由同一名测试工程师完成。在此过程中，这名测试工程师可以不断地理解需求并帮助澄清需求。测试工程师通过在需求分析阶段就开始参与相关活动，能够更早地帮助发现系统在设计之初就存在的业务逻辑缺陷、使用缺陷及交互缺陷，从而将一些有可能出现在系统中的缺陷在系统开始开发之前就解决掉，避免团队投入的浪费，提高团队的投入产出比和交付效率。此外，当研发工程师开始开发系统时，测试工程师就可以同步完成测试用例的设计。在这里，测试用例的设计并不是像传统方式下那样按照系统的操作步骤设计测试用例，而是按照业务流程的梳理结果设计测试用例。这种更深入的参与和理解能促进测试工程师获得产品的完整知识，彻底想清楚各种场景，并根据软件行为设计实时场景。以上这些都能帮助团队在编码完成之前识别出一些缺陷。测试左移聚焦于使测试人员在最重要的项目阶段就参与进来，使测试人员把关注点从发现缺陷转移到风险预防，从而避免一些技术风险和业务风险，同时驱动实现项目的商业目标。当测试团队不断实践测试左移时，质量文化便会在整个团队中不断地建立并扩大，大家不会再将质量保障等同于在测试中发现缺陷，而是共同参与各个环节以防止业务风险和技术风险的发生，促使团队的所有成员都积极合作，在项目的初始阶段就为满足业务需求以及避免业务风险展开工作。测试工程师为建立有效的测试策略不断努力，并在测试策略的指导下避免业务风险和技术风险，使整个团队聚焦于产品的长期价值和可靠性。在实践测试左移时，提倡在需求进入迭代计划之前就讨论每一张需求卡片，参与每一个需求的 AC 讨论。研发工程师在开始实现需求之前，需要将自己的理解结合需求卡片的 AC 详细地讲解给测试工程师和产品经理，大家达成一致后，研发工程师进入编码阶段，测试工程师进入测试用例准备阶段。系统开发完之后，研发工程师再次将自己完成的系统按照需求卡片上的 AC 要求演示给测试工程师和产品经理，如果一切都不存在歧义，则进入测试阶段。测试工程师在根据一些常规的测试用例设计方法补充异常用例后，就可以开始测试了。在整个过程中，团队都以交付高质量的项目为中心，而不再使用缺陷数、测试用例数、代码行数等不科学、不客观的考核指标。

测试右移

测试右移是指相对于测试左移而言的，测试右移是制品发布到生产环境之后，进行的一些测试活动，但是这里的测试活动并不是我们常说的测试活动，而是通过一些环境监控、业务监控、APM 等一些手段对服务的可用性、稳定性等的一些考量，从而实现一旦发现生产环境的问题，尽快将问题暴露给制品团队进行快速修复，给用户良好的体验。

在 Ops 的交叉

右移，就是移动到生产环境，这也就决定了在该部分的测试活动和我们常说的测试活动就有着很多的区别。那么在生产环节的测试活动和我们实际的测试活动就会有很多区别了。在传统的测试角色分工中，生产环境的负责人是我们的 Ops 同学，Ops 的核心工作理念是“稳”，这就和我们测试中的快速验证，快速修复的一些方法有些冲突了。既让有一些差异，又如何右移呢？

测试的右移不是仅仅说的是去生产环境进行测试活动，当然也是又一些可以在生产环境的测试活动的，我们一会再文中也会详细说明。测试右移不是和 Ops 同学的冲突，而是利用了 Ops 的一些技术平台给我们一些判断的输入来源，然后再结合测试原有的一些技术沉淀，完成服务质量的保障工作。

• 利用运维技术平台：可以充分利用 Ops 同学提供的监控平台、日志平台等数据，监控数据的 live 状态，从而更早的发现生产环节的问题，并将对应问题的一些留痕数据（日志信息、监控数据等）记录到缺陷系统中，辅助解决对应生产缺陷（如果造成损失也可能是故障）

• 利用自动化测试：可以利用自动化测试手段为生产环节提供业务正确性的巡检功能，这样可以在 Ops 保障服务 Live 的基础之上，自动化测试模拟的业务逻辑又能保障业务的 live，这样也是监控分层的一种思绪。

PS：任何的层级解决方案，都是为了弥补层级之间的一些间隙而设计的。

通过生产数据反哺测试左移

用户使用系统的行为有可能并不是按照这个我们预期的方法来进行的，因此我们需要在右移的环节中，通过一些前端埋点等技术，留痕真实用户的使用方法、喜好等从而可以在测试左移的时候反哺业务需求，这样就可以将很多右移中获得的有价值的内容，在左移过程中落地实现，从而最大化保障从业务到需求的环节。

当然如果要实现反哺测试右移，必须要实现真正的敏捷测试，而不是仅仅是穿着敏捷外衣的伪敏捷实践。

生产环境的测试

虽然生产环境是以稳定为前提的，但是也是有测试技术手段可以在稳定前提下可以实施的。

• 全链路测试：全链路测试是通过流量录制回放技术，再生产环境完成的测试技术。当然要实施生产环境的全链路测试并不是测试工程师的事情，这需要对 SUT 做全套的技术改造，具体可以详细学习一下全链路测试的文章。

• 灰度环境：有了灰度环境就有了可以在部分环境先上线，然后进行一些测试活动或者实验活动。

• AB 测试：AB 测试有可能在用户增长领域比测试用的更多，但它也是一种生产环节的测试验证活动，因此我们也把他放到这里。

测试右移的重点落地还是 QA，那么这个 QA 既是质量保障（Quality Assurance），也有质量分析（Quality Analysis），更有质量倡导（Quality Advocate）。

持续测试的收益

• 加速软件交付

• 提高纸品的质量

• 它有助于评估准确的业务风险覆盖率。

• 和 DevOps 流水线一起保持即快又好的完成业务交付

• 有助于在数小时内创建敏可靠的流程。

• 通过持续反馈机制加快产品上市时间。

• 消除产品、开发、测试和运维之间的脱节。

• 测试自动化为所有相关测试维护相同实现一致性。

• 强调业务价值交付

• 随用随取的测试环境管理和统一的测试数据管理平台

参考资料

1、Continuous Testing: “Perfect” Software Is not the Goal https://www.tricentis.com/blog/continuous-testing-perfect-software-is-not-the-goal/2、Continuous Testing in DevOps: What is, Definition, Benefit, Toolshttps://www.guru99.com/continuous-testing.html