“阅读本文大概需要5分钟。
你好,我是测试蔡坨坨。
今天,我们来聊一聊测试左移和测试右移。
在探讨测试左移和测试右移之前,我们先来聊一下传统的软件测试流程(瀑布模型)和目前很多公司在用的测试流程(敏捷模型)的区别。
软件测试作为软件研发的一部分,有什么样的开发模式,就有与之对应测试模式。因此就有了适合传统瀑布开发模式的传统测试和适合敏捷开发模式的敏捷测试。
从两者的区别,我们可以看出传统测试最明显的弊端就是介入晚以及没有持续测试。
所以,为了从根本上解决这类问题,于是开始推广并实践测试左移和测试右移。
测试左移,顾名思义就是测试要在提测之前介入软件研发流程,及时发现错误,避免将许多本可以规避的问题带到测试阶段才发现,导致修复成本过高,甚至导致项目延期无法按时交付。提倡预防缺陷胜于发现缺陷,需要把质量构建推向源头,也就是产品需求,因为最严重的错误不外乎是系统不能满足用户需求。
测试左移通过持续对产品需求和设计进行评审,在需求评审时不只是简单了解需求,而是要去评估需求的质量,分析需求的完整性以及合理性,及时发现需求和设计中的问题,从而可以更好地避免由于产品文档不完善导致需求不明确的问题。
测试左移还包括代码评审,以及让开发做更多的测试,加强单元测试,开发自测,持续集成等。在开发阶段参与设计方案的设计,了解开发的实现方式和代码框架,从而可以更好地评估改动范围、需要回归的内容以及是否有遗漏的模块和系统。测试还可以通过提供测试用例或自动化测试脚本的方式给开发,让开发在设计时考虑更全面,同时方便开发自测,有助于提高产品质量,避免在收到提测包时冒烟测试主流程都没通过,导致测试效率低下。
测试还需要不断培养产品、开发同学的质量意识,提倡团队对质量负责,同时提供必要的技术支持,协助产品、开发更好地进行测试,比如:公共测试用例、测试工具、测试脚本等。
这样一来,你会发现提测的质量会大大提高,原本要花一天时间冒烟的功能很快就能通过。
测试右移指的是在软件发布之后关注线上环境,持续监控软件的线上质量,以验证产品在用户的实际环境、数据、场景下,功能和性能是否符合用户预期,而不是项目发布完成就万事大吉了。
比如以下测试右移的活动:
不得不承认测试左移和测试右移的提出,对于测试角色来说,无疑是一个很大的进步。
但是,这也反映出了一些问题。测试左移在一定程度上代表着测试人员对即将拿到一个什么样的半成品充满了担忧,所以我们迫不及待想做些什么,于是我们拼命地往左边挤,力求尽快发现一些错误,将这些问题扼杀在摇篮里,避免自己接到一手烂摊子而焦头烂额。测试右移在一定程度上是测试人员对自己测试的不自信,因为有时候我们绞尽脑汁设计测试用例,通过多轮反复验证,满怀期待的上线,但是用户总会以某个不可思议的角度狠狠地敲你一棒子,于是我们通过测试右移,持续测试,关注线上环境,赶在客户发飙之前悄悄地把缺陷解决。
同时也反映了测试人员对质量的影响是很小的,单纯在测试阶段执行测试是不够的,所以我们不得不“上下求索”,以求一份安心,不应该把提测认为测试活动的开始,把上线认为是测试活动的结束,更不要认为质量只是测试人员需要关注的,因为质量不是被测试出来的而是被设计出来的,应该伴随整个软件的生命周期。
以上,完。
脚踏实地,仰望星空,和坨坨一起学习软件测试,升职加薪!