持续测试是在软件交付生命周期过程中，以防控业务风险为目的，将每一个业务交付阶段都辅以测试活动进行质量保障，并尽最大可能自动化，通过测试结果不断的反馈给制品过程的测试实践活动。随着持续测试实践的广泛应用，测试的左移和右移被越来越多的提及。
每一个测试工程师都知道我们要保障需求的质量，参与需求评审，从而实现测试左移实践。那么我们参与需求评审要干什么却很少人说清楚，测试左移到底应该怎么也是一个很模糊的内容。其实测试左移并不是一个非常新的概念，它最早是由Arthur Hichen提出出：为了弥补瀑布模型的不足以及避免测试工作成为系统交付前的最后且唯一的质量保障手段，测试应左移并贯穿于项目的整个研发生命周期。
测试工程师通过在需求分析阶段就开始参与相关活动，能够更早地帮助发现系统在设计之初就存在的业务逻辑缺陷、使用缺陷及交互缺陷，从而将一些有可能出现在系统中的缺陷在系统开始开发之前就解决掉，避免团队投入的浪费，提高团队的投入产出比和交付效率。
测试左移聚焦于使测试人员在最重要的项目阶段就参与进来，使测试人员把关注点从发现缺陷转移到风险预防，从而避免一些技术风险和业务风险，同时驱动实现项目的商业目标。目前测试左移有很多种做法，最为普遍的落地方法就是在需求澄清会上，测试工程师站在需求的业务合理性、系统的完整性、合规性以及需求的可测试性等方面对需求进行综合评价，提出自己的疑问，并要求将必要的内容添加到对应需求的AC（验收条件）里。
在迭代进行过程中，需要通过开卡、验卡实践完成测试左移的实践落地，团队中开发工程师准备实现一个故事卡片的时候，会将测试工程师、产品经理集合到一起，按照故事卡片上的验收条件详细讲解自己对故事的理解以及如何实现的，在这时如果产品经理发现故事卡片有遗漏的验收条件那么就需要及时补充，测试工程师站在自己对需求的理解、对系统全局的认识以及对上下游依赖的基础之上补充验收条件中缺失的内容，这种快速的集合讨论就是开卡动作（英文叫做KickOff，简称KO）。在研发完成开发后，同样需要将产品经理、测试工程师聚合到一起，按照故事的验收条件和已经实现的系统完成验收，产品经理站在是否实现了对应的故事角度，测试工程师站在是否完善的角度进行分析，通过后进入测试环节，这个动作叫做验卡（英文是DesckCheck，简称DC）。在这个过程中，验收条件就是这条需求的测试用例，测试工程师只需要补充一些非功能测试用例就可以了。这种验收条件和开卡、验卡的实践保证了交付的流畅度，是目前测试左移一种有效的实践方式。
测试右移是指相对于测试左移而言的，测试右移是制品发布到生产环境之后，进行的一些测试活动，但是这里的测试活动并不是常说的测试活动，而是通过一些环境监控、业务监控、APM等一些手段对服务的可用性、稳定性等的一些考量，从而实现一旦发现生产环境的问题，尽快将问题暴露给制品团队进行快速修复，给用户良好的体验。测试右移就是将测试移动到生产环境，这也就决定了在该部分的测试活动和常说的测试活动就有着很多的区别。在传统的测试角色分工中，生产环境的负责人是运维工程师，运维的核心工作理念是“稳”，这就和测试工程师的快速验证，快速修复的一些方法有些冲突了。测试的右移不是仅仅说的是去生产环境进行测试活动，当然也是有一些可以在生产环境的进行的测试实践的。测试右移不是和运维的冲突，而是利用了运维的一些技术平台给测试工程师一些判断的输入来源，然后再结合测试原有的一些技术沉淀，完成服务质量的保障工作，以早发现，早预防为主的一种技术手段，具体方法如下：
● 利用运维技术平台：可以充分利用运维工程师提供的监控平台、日志平台等数据，监控服务的状态，从而更早的发现生产环节的问题，并将对应问题的一些留痕数据（日志信息、监控数据等）记录到缺陷系统中，辅助解决对应生产缺陷（如果造成损失也可能是故障）
● 利用自动化测试：可以利用自动化测试手段为生产环节提供业务正确性的巡检功能，这样可以在运维工程师保障服务的基础之上，自动化测试模拟的业务逻辑又能保障业务的稳定性，这样也是监控分层的一种思绪。
测试左移和右移都是相对的概念，只是为了和传统瀑布交付模式中的测试中心模式相互区分的一种实践，通过这两种优秀的实践可以将质量保障工作贯穿于全部制品过程中，从而实现持续测试。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
