测试是为了保证软件产品的最终质量,质量不过关,价值也就没有了。近几年随着持续交付、敏捷开发等开发模式的出现,为传统软件测试方式带来了更大的时间压力。
测试人员接到项目后参与需求评审,然后根据需求文档写用例、准备脚本,等开发提测之后正式开始测试、提 Bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。
这样的流程看似没什么错,但有两大问题:
测试人员非常被动。当需求质量、开发质量较差的时候,测试人员只能被动接受。但同时,测试又被认为是质量的责任人。
这些问题,在新的开发模式下愈发严重。因为这些新的开发模式有一个共同点,就是要缩短产品的交付周期,对自动化的要求越来越高,能够专门留给传统竖井流程中测试环节的时间越来越短,自然更难保证质量。在持续部署的模式下,所有测试都是自动化的,已经完全没有留给测试人员专门进行手工测试的时间了。
在快速开发模式的挑战下,测试左移、测试右移就应运而生了。这些测试模式,能让测试人员拥有更多主动权,以及更多的时间进行测试。
什么是测试左移和测试右移?
测试左移和右移,就是把测试的范围从传统测试的节点中释放出来,向左和右扩展。
向左扩展,就是让测试介入代码提测之前的部分。测试右移,是让测试介入代码提测之后的部分。
测试左移的原则和实践
1、调整团队对测试的态度;
2、把测试添加到开发和产品需求步骤中;
3、频繁测试,快速测试。
为了能够顺利、频繁地运行测试,还要提升测试运行的速度。
测试提速的常见办法包括:
并行运行,比如把测试用例放到多台机器上运行,用资源换时间。
提高构建速度,比如使用精准构建,因为通常构建之后才能运行测试。
精准测试,也就是只运行跟改动最相关的测试。可以建立需求与代码的关系,以及需求与测试用例的关系,从而在代码改动时重点关注与之最相关的测试用例。
分层测试,即不同情况运行不同测试用例集合。
减少不必要的用例,比如,识别不稳定的用例,对其删除或者优化。