做测试如何应对新的开发模式？

测试是为了保证软件产品的最终质量，质量不过关，价值也就没有了。近几年随着持续交付、敏捷开发等开发模式的出现，为传统软件测试方式带来了更大的时间压力。

测试人员接到项目后参与需求评审，然后根据需求文档写用例、准备脚本，等开发提测之后正式开始测试、提 Bug、回归，测试通过后就结束了，项目交给运维上线，之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么错，但有两大问题：

测试人员非常被动。当需求质量、开发质量较差的时候，测试人员只能被动接受。但同时，测试又被认为是质量的责任人。

这些问题，在新的开发模式下愈发严重。因为这些新的开发模式有一个共同点，就是要缩短产品的交付周期，对自动化的要求越来越高，能够专门留给传统竖井流程中测试环节的时间越来越短，自然更难保证质量。在持续部署的模式下，所有测试都是自动化的，已经完全没有留给测试人员专门进行手工测试的时间了。

在快速开发模式的挑战下，测试左移、测试右移就应运而生了。这些测试模式，能让测试人员拥有更多主动权，以及更多的时间进行测试。

什么是测试左移和测试右移？

测试左移和右移，就是把测试的范围从传统测试的节点中释放出来，向左和右扩展。

向左扩展，就是让测试介入代码提测之前的部分。测试右移，是让测试介入代码提测之后的部分。

测试左移的原则和实践

1、调整团队对测试的态度；

2、把测试添加到开发和产品需求步骤中；

3、频繁测试，快速测试。

为了能够顺利、频繁地运行测试，还要提升测试运行的速度。

测试提速的常见办法包括：

并行运行，比如把测试用例放到多台机器上运行，用资源换时间。

提高构建速度，比如使用精准构建，因为通常构建之后才能运行测试。

精准测试，也就是只运行跟改动最相关的测试。可以建立需求与代码的关系，以及需求与测试用例的关系，从而在代码改动时重点关注与之最相关的测试用例。

分层测试，即不同情况运行不同测试用例集合。

减少不必要的用例，比如，识别不稳定的用例，对其删除或者优化。