引言
随着互联网技术的发展，产品的快速迭代且能适应市场需求已经成为各大公司的痛点。而传统的开发模式已经不再适用于快速迭代的产品，在这种情况下，敏捷开发模式因其高度迭代、频繁交付以及适应变化的特点，已经在各个领域得到广泛应用。与此同时，敏捷开发的发展对软件测试也提出了更高的要求。因此，敏捷测试对提高测试效率进而提升产品交付质量具有重大意义。
敏捷开发的发展与特点
在2001年2月，Martin Fowler和他的同事提出了敏捷宣言，指出：
- 个体和交互胜过流程和工具;
- 可用的软件胜过完备的文档;
- 客户协作胜过合同谈判;
- 响应变化胜过遵循计划。
无论什么行业或产品，软件开发的最终目标就是为了能满足客户的需求，实现客户的根本利益。在互联网行业中，市场需求快速变化，这一特性比传统行业更为明显。如何能够根据客户提出的需求及时调整开发的内容和进度，从而减少在传统开发模式下所造成的不必要的浪费?这大概是所有互联网公司都在思考的问题。敏捷开发是一个不断累加、迭代增长及时响应的过程。因此，敏捷开发模式已经成为全球范围最受欢迎的软件开发模式。
在敏捷开发模式中，Scrum是其中一种增量迭代开发的框架，其以人为核心进行迭代和循序渐进的开发方法已经被广泛运用。利用这种Scrum敏捷方法，可以将整个开发周期划分成多个小的迭代周期(Sprint)，每个周期长度一般在2 到4 周之间。在Scrum 框架下，产品需求利用Backlog 进行管理。Backlog 是一个按照商业价值等原则进行排序的列表，根据用户故事(User Story)进行列表条目的体现。
利用Scrum 敏捷方法进行开发，一般会先开发对客户具有较高价值的需求。在每个迭代周期中，开发团队可以从产品中挑选最有价值的需求优先开发。在Sprint 计划会议上，开发团队会对需求进行分析讨论，并且估算得到一个待办列表。完成迭代后，Scrum团队则能够进行潜在可交付的产品增量的交付。
Scrum这种敏捷开发模式，其特点是在一个极短的发布周期内交付业务价值的一部分，并在开发周期内不断的迭代和循序渐进。敏捷开发模式不断接受需求更新，这样就能做到及时并持续的响应客户的反馈。
敏捷开发与测试的运用
软件测试贯穿于软件的整个生命周期，是保证软件质量的基础。测试团队通过选用合适的软件测试技术以及测试工具，来不断改善软件开发及测试流程。在敏捷开发模式得到迅速发展的同时，敏捷测试也成为了软件开发与测试团队共同关注的焦点。
敏捷测试通过持续对软件进行测试并及时反馈测试结果来提高软件质量，满足用户需求，其强调“持续测试”和“及时反馈”。因此，敏捷测试在一定程度上也可以被认为是遵循敏捷宣言的一种测试实践。
图一：敏捷开发与测试流程
从图一可以看到，在某个Sprint中整个敏捷开发与测试流程被分成了以下几个步骤：
待办列表
在待办列表中会列出所有此Sprint将要开发的功能，这些列表一般是以User Story的形式来进行功能描述，并可能会随着项目的迭代而更新。
拆分计划
对待办列表中的功能进行细化，产生各个子功能，并列明各子功能的具体需求。在拆分计划阶段，开发与测试都需要熟悉各个功能的要求。
迭代开发测试
图二：迭代开发测试流程
在这个阶段，如图二所示，开发人员对相应功能进行需求分析，制定开发迭代计划，并进行功能开发与自测。测试人员也要进行需求分析，并列明测试计划，同时进行测试用例与脚本的编写。开发人员完成功能开发以及自测后，会产生相应的可测版本。测试人员根据需求执行测试用例，产生的缺陷由开发进行修复，继而进行持续开发。
图三：开发与测试阶段流程
如图三所示，在开发与测试阶段，开发人员进行模块开发与单元测试，在TDD(后续章节会有简单介绍)的驱动下，对模块进行重构。在模块开发完成并集成后，由测试人员进行冒烟、验收测试，其中产生的bug，会继续由开发人员进行修复。
功能发布
在测试人员完成测试之后，进行测试小结，根据测试结果来评审是否可以交付某功能。
敏捷测试的主要方法及实践
测试驱动开发(TDD)
测试不仅是测试人员的责任，开发人员也必须通过不断的单元测试、模块功能测试等白盒测试来重构自己的代码，以此提高软件的交付质量。
TDD要求开发人员在写代码前，先写好测试用例，再编写代码，并且代码能够通过测试用例。随着不断地迭代和重构，测试用例的数量和覆盖点也会不断增加，程序所实现的功能也越来越复杂。开发人员需要不断提高单元测试的覆盖率，以此来增强代码的可用性。
不断地深入沟通
团队需要密切的沟通，不过多依赖文档。测试人员通过与不同角色进行沟通，在短时间内对项目的整体需求有充分的了解，才能设计出最适合的测试用例。为了保证产品质量符合客户预期，在产品不断的迭代中，测试人员需要不断地修改测试用例，以达到精益求精的程度。
- 测试人员与开发人员之间的沟通，可以通过阅读部分源代码，了解产品的架构，从技术角度探讨问题。
- 测试人员与用户的交流，使测试人员能够站在客户的角度去考虑一些问题，必要的时候，还需要对竞商的相同类型产品进行比较。
- 测试人员之间的交流，又是一个共享经验及传递问题的过程。通过这种交流，个人经验转变成了整个团队的经验。
模糊界限
在敏捷模式中，强调团队的高度协作，测试和开发的角色界限变得模糊。
开发人员不仅要确保开发任务的完成，还要运用单元测试等工作来保证代码质量。而作为敏捷测试人员，也需要了解项目中客户的需求、软件的设计框架、软件语言等。测试人员可以通过阅读或编写一部分产品代码来熟悉产品的内部逻辑。
在测试人员设计测试用例的过程中，团队的所有成员都有责任来共同设计符合客户环境以及使用情景的测试方案。在敏捷模式中，团队可以通过组织测试用例评审会来确保全员的参与。
自动化运用
在敏捷开发的过程中，项目不断地以短周期的形式迭代发布。那么，测试人员不仅要保证每次迭代中新功能点的完整实现，还要保证之前迭代版本的功能不受影响。这样就会造成测试工作量在不断的增加，而且存在严重的重复性。
在敏捷项目中，自动化测试的良好实施会使测试人员乃至整个项目提高效率。一般在项目前期迭代中，测试人员会筛选最基本且使用率较高的测试用例来实现自动化，并且在迭代过程中不断地完善与优化自动化脚本，增加功能测试的覆盖面。这样，在项目后期回归测试时，只需要将累积的自动化脚本执行一遍就可以基本覆盖大部分功能，从而缩短测试人员在回归测试中验证基本功能所消耗的时间。测试人员也可以将更多的时间投入到一些探索性测试中，以保证 更好的产品质量。
持续集成
在开发过程中，开发人员经常会合入新的代码。那么，如何检验新开发代码的质量?并保证新代码合入库之后不会影响老代码的功能呢?这就需要通过自动化的持续构建(包括编译，自动化测试)来保证。持续集成的主要目标是更快发现并解决缺陷，提高软件质量，并减少验证和发布软件更新所需的时间。
如图四所示，持续集成的过程大致有如下几个方面：
- 设定一定的触发条件，如定时、固定周期、手动启动等;
- 启动后，持续集成框架从版本管理工具中检查并下载最新代码，若没有则结束集成过程;
- 代码编译成功后启动自动化测试环境开始自动化测试;
- 自动生成测试报告，并通过邮件等形式发送给相应责任人。
图四：持续集成的过程
敏捷测试该如何开展
在某些项目上，一些团队已经基本能按照敏捷的方式来进行开发管理，但还是会有一些成员在心理上有一些抵触，不习惯这样的模式。就敏捷测试而言，在思想上，推动全员质量意识，项目团队的所有成员都应该为产品质量负责，保证产品质量不再只是测试人员的职责。开发人员需要通过单元测试的覆盖率来保证代码的正确性。
要保证软件的内建质量，在设计阶段就要对需求、设计逻辑等进行全面的分析，提高可测试性。在敏捷测试中，测试人员需要贯穿于软件的整个生命周期，并要尽早参与测试。在充分了解了计划中待实现功能的前提下，制定测试计划，采用迭代的方式完成测试任务。建立持续集成，结合自动化测试，在每次迭代中快速反馈测试结果。并不断地维护自动化测试框架，用于后期的回归测试和验收测试。
