持续测试其实就是一种新的测试实践，是在软件交付生命周期过程中，以防控业务风险为目的，将每一个业务交付阶段都辅以测试活动进行质量保障，并尽最大可能自动化，通过测试结果不断的反馈给制品过程的测试实践活动。持续测试主要包含测试左移、测试、测试右移三部分。

1.测试左移

早期，测试左移的概念在阿瑟·希肯（Arthur Hicken）发表的文章中被提出来。他提出：为了弥补瀑布模型的不足以及避免测试工作成为系统交付前的最后且唯一的质量保障手段，测试应左移贯穿于项目的整个研发生命周期。这也说明测试工程师在项目的需求分析阶段就应该参加相关活动，从而在需求分析阶段就站在测试角度补充各种验收条件。从需求分析开始到测试业务分析，再到测试用例设计、测试执行以及测试结论总结，都应由同一名测试工程师完成。在此过程中，这名测试工程师可以不断地理解需求并帮助澄清需求。

测试工程师通过在需求分析阶段就开始参与相关活动，能够更早地帮助发现系统在设计之初就存在的业务逻辑缺陷、使用缺陷及交互缺陷，从而将一些有可能出现在系统中的缺陷在系统开始开发之前就解决掉，避免团队投入的浪费，提高团队的投入产出比和交付效率。

此外，当研发工程师开始开发系统时，测试工程师就可以同步完成测试用例的设计。在这里，测试用例的设计并不是像传统方式下那样按照系统的操作步骤设计测试用例，而是按照业务流程的梳理结果设计测试用例。这种更深入的参与和理解能促进测试工程师获得产品的完整知识，彻底想清楚各种场景，并根据软件行为设计实时场景。以上这些都能帮助团队在编码完成之前识别出一些缺陷。测试左移聚焦于使测试人员在需求阶段就参与进来，使测试人员把关注点从发现缺陷转移到风险预防，从而避免一些技术风险和业务风险，同时驱动实现项目的商业目标。

当测试团队不断实践测试左移时，质量文化便会在整个团队中不断地建立并扩大，大家不会再将质量保障等同于在测试中发现缺陷，而是共同参与各个环节以防止业务风险和技术风险的发生，促使团队的所有成员都积极合作，在项目的初始阶段就为满足业务需求以及避免业务风险展开工作。测试工程师为建立有效的测试策略不断努力，并在测试策略的指导下避免业务风险和技术风险，使整个团队聚焦于产品的长期价值和可靠性。

伴随着测试左移的思路的发展，更加提倡测试工程师在需求阶段就开始有质量保障的输出，因此开卡、验卡的实践越来越受到各种DevOps实践团队的推崇。团队中开发工程师准备实现一个故事卡片的时候，会将测试工程师、产品经理集合到一起，按照故事卡片上的验收条件详细讲解自己对故事的理解以及如何实现的。在这时，如果产品经理发现故事卡片有遗漏的验收条件那么就需要及时补充，测试工程师站在自己对需求的理解、对系统全局的认识以及对上下游依赖的基础之上补充验收条件中缺失的内容，这种快速的集合讨论就是开卡动作（Kick Off，简称KO）。在研发完成开发后，同样需要将产品经理、测试工程师聚合到一起，按照故事的验收条件和已经实现的系统完成验收，产品经理站在是否实现了对应的故事角度，测试工程师站在是否完善的角度进行分析，通过后进入测试环节，这个动作叫做验卡（Desk Check，简称DC）。在这个过程中，验收条件就是这条需求的测试用例，测试工程师只需要补充一些非功能测试用例就可以了。这种验收条件和开卡、验卡的实践保证了交付的流畅度，是目前测试左移一种有效的实践方式。

2. 测试

在这部分，就是最为常规测试部分，很多团队会引入精益的理念来促进该部分质量保障的工作，因此有些团队也会将该部分直接称作精益测试。但是无论是什么样的方法论在指导这部分的工作，都不会脱离静态测试和动态测试这两类。

静态测试是指不运行被测程序本身，通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。静态测试主要包括各阶段的评审、代码检查、程序分析、软件质量度量等，用于对被测程序进行特性分析。

其中代码检查是静态测试中的关键一步，代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。代码检查的代表性工具就是SonarQube。

依赖SonarQube完成第一步代码扫描，这是一个有效提高提测代码质量的方法。SonarQube是按照设计好的代码规范来检查被测系统的源代码的规则符合性的。在团队中应用SonarQube需要与团队的技术负责人、架构师一起确定团队需要遵从的代码规范，这一般都是技术负责人来主导的，但是有很多时候测试工程师为了保护自己，会作为技术落地推广的主力而存在。大部分团队都会选择一些开源规范（例如P3C规范）作为起点，然后在不断的工程实践中修正和完善，注重维护一套符合自己公司要求的代码规范。

动态测试是通过运行被测程序来检查运行结果与预期结果的差异，并分析运行效率和健壮性等指标。从而可以查看出动态测试包含了单元测试、接口测试和UI自动化测试。

自动化分层测试模型是在不断发展和进步的，并不是一成不变的。在如图5-23中最左侧是最经典的分层测试模型，习惯叫金字塔模型。在金字塔模型中，每一种颜色的面积代表测试投入的成本大小，所以在单元测试投入最多，然后是接口自动化测试，最后是界面自动化测试。单元测试投入大是“越早的开始测试，修复缺陷的成本越小”这条理念的最直接落地，金字塔模型是一个相对理想的模型，对于开发工程师、测试工程师的能力要求很高。

因此，随着自动化测试的不断探索，测试工程师在接口自动化测试方面投入越来越多，开发工程师在单元自动化测试上投入越来越少。项目在单元自动化测试上投入相对较少，在接口自动化测试上投入较多，界面自动化测试投入相对较少，界面自动化目前投入较少也是因为界面自动化的投入产出比较低决定的。
但是，无论是哪部分的投入变化，分层测试中的层次却依旧保持存在的。这是因为分层自动化模型中每一个层次的实践都有一定的无法被测试的边界条件和逻辑边界，我们将其称之为测试间隙。

3. 测试右移

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

测试右移就是将测试移动到生产环境，这也就决定了在该部分的测试活动和常说的测试活动就有着很多的区别。在传统的测试角色分工中，生产环境的负责人是运维工程师，运维的核心工作理念是“稳”，这就和测试工程师的快速验证、快速修复的一些方法有些冲突了。

测试右移不是仅仅说的是在生产环境进行测试活动，当然也是有一些可以在生产环境的进行的测试实践的。测试右移不是和运维的冲突，而是利用了运维的一些技术平台给测试工程师一些判断的输入来源，然后再结合测试原有的一些技术沉淀，完成服务质量的保障工作，以早发现、早预防为主的一种技术手段，具体方法如下。
（1）利用运维技术平台：可以充分利用运维工程师提供的监控平台、日志平台等数据，监控服务的状态，从而更早的发现生产环节的问题，并将对应问题的一些留痕数据（日志信息、监控数据等）记录到缺陷系统中，辅助解决对应生产缺陷（如果造成损失也可能是故障）。
（2）利用自动化测试：可以利用自动化测试手段为生产环节提供业务正确性的巡检功能，这样可以在运维工程师保障服务的基础之上，自动化测试模拟的业务逻辑又能保障业务的稳定性，这样也是监控分层的一种思绪。

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

当然，如果要实现这种实践，必须要实现真正的敏捷测试，而不是仅仅是穿着敏捷外衣的伪敏捷实践。虽然生产环境是以稳定为前提的，但是也是有测试技术手段可以在稳定前提下可以实施的。
（1）全链路测试：全链路测试是通过流量录制回放技术，再生产环境完成的测试技术。当然要实施生产环境的全链路测试并不是测试工程师就可以完成的事情，这需要对被测系统做全套的技术改造。
（2）灰度环境：有了灰度环境就有了可以在部分环境先上线，然后进行一些测试活动或者实验活动。

（3）A/B测试：A/B测试有可能在用户增长领域比测试用的更多，但它也是一种生产环节的测试验证活动。

来源：《敏捷之道》——敏捷中的测试实践：持续测试--文/陈磊

【每日一学 20260804】敏捷之道——敏捷中的测试实践：持续测试

1.测试左移

2. 测试

3. 测试右移

联系我们

融实践库

微信公众号

微信视频号

社区微信群