1.2　敏捷开发模式下的软件测试

就在软件测试日益成熟的同时，市场对软件产品又提出了新的要求：既要质量高，又要交付快，还要适应不断变化的用户需求。瀑布开发模式变得很难适应，常常让项目陷入困境，第二次软件危机爆发。敏捷开发模式应运而生，逐渐成为流行的研发模式。

敏捷开发模式的发展

2001年，17位敏捷运动发起者在美国犹他州签署了《敏捷软件开发宣言》（简称《敏捷宣言》）。随后二十年的时间里，敏捷开发模式在全球范围内发展，迭代、持续集成/交付、DevOps等逐渐成了新的工程标准，不断提升研发效能。

在《敏捷宣言》发布的同年，中国的敏捷先行者就开始尝试将敏捷开发模式引入中国。2008年，几个通信大厂（诺基亚、爱立信、华为、中兴）开始进行敏捷开发模式转型，互联网行业巨头BAT也开始推行敏捷实践，敏捷开发模式在中国开始快速传播。

敏捷开发模式对测试产生了深远的影响。

在瀑布开发模式下，很多公司都有独立的测试部门，到了测试阶段，开发人员会把集成了所有功能的版本一股脑儿提交给测试人员来测试。当然提交过程也不会那么顺利，开发人员把提交版本给测试人员，测试人员测试不通过，会把版本再次退给开发人员，来来回回“拉锯”好几轮，测试人员才能正式开始测试。那时普遍认为测试人员要对产品质量负责，好质量是测出来的，所以开发人员调通基本功能后，就会等着测试发现缺陷，通过缺陷来驱动代码的优化和重构。到了发布的时候，测试人员对“产品是否可以发布”有一票否决权，测试人员和开发人员经常为了缺陷的处理方式争吵，彼此就像隔着一道墙。而敏捷开发模式推翻了这道墙。

Lisa Crispin和Janet Gregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》一书中是这样定义敏捷测试人员的：

专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。他们具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索式测试。他们还希望了解用户在做什么，以更好地理解用户的软件需求。

在敏捷开发模式里，质量也不再是测试的事情，每个角色都要为自己那部分质量负责，每个开发人员都要自己去测试来确保自己的提交不会破坏系统，自己想办法去优化重构。开发人员和测试人员的关系，也从对立变成了合作，进而融合，测试、开发人员的比例从1∶2降到了1∶10，有些团队甚至不再设置专职测试工程师。

在瀑布开发模式下，产品发布周期通常是“大几个月”或是“年”，而敏捷开发模式要求“几周”就要发一个版本，这种增量式、小步快跑的版本发布节奏，让自动化测试变得非常重要，甚至成了影响敏捷开发模式成败的几个关键因素之一。

如果说敏捷开发模式推翻了开发和测试之间的墙，那么DevOps（开发即运维）又进一步打通了开发、测试和运维环节，通过持续集成（CI）、持续交付（CD）的自动化流水线，再次缩短了产品发布周期，可以做到每日发布或者每日多次发布。

在DevOps开发模式下，自动化测试也进一步发展为持续测试，这使得缺陷在产生的时候就会立即被发现。测试也从瀑布开发模式下的后端验证，发展为全流程下无所不在的测试，如图1-2所示。

图1-2　不同研发模式下的测试

敏捷开发模式聚焦为用户创造价值（Lean），希望践行者们具有如下价值观（Scrum）：承诺、专注、开放、尊重和勇气。

这使得敏捷团队中的测试人员，只要有想法、有能力就可做任何有利于用户或团队的事情，而不用担心测试的身份：

·测试人员可以直接和产品人员沟通交流，参与产品规划；

·测试人员可以直接和用户交流，收集需求，澄清问题；

·测试人员可以像开发人员一样去编码；

·测试人员可以做工具，做自动化；

·测试人员可以做流程，做质量改进；

……

这并非不务正业，测试本身就是一个需要系统思维和判断力的行业，局限在后端是做不好测试的。敏捷开发模式帮助测试人员打破了限制测试视野和发展的约束，但也给测试人员带来了新的问题和挑战。