有一次，当开发人员完成当前Sprint 任务的代码之后，测试人员与开发人员、产品经理一起来浏览产品、从头到尾走一边，产品经理发现了问题，认为需要对功能进行比较大的修改。这时开发人员估计 需要两天时间才能完成代码，但测试人员反对这样做，我们本来只有5天测试时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再 延迟两天，测试没法完成。产品经理说，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊！

    什么是敏捷测试呢？敏捷测试当然不能简单地理解测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说，只有敏捷开发，没有敏捷测试。

    1.下面我们就要讨论一下

    等等各种问题。 1. 什么是敏捷测试 假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应用的作用。敏捷测试应该是适应敏捷 方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有所不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、 开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动 化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地 说，敏捷测试就是持续地对软件质量问题进行及时地反馈，如图1所示。

     2. 敏捷测试流程的优化

     在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大 的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划 书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员(包括测试经理)讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起 草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点(包 括策略、特定方法、重点范围等)列出来就可以了。

    在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以 后再导入测试用例库(在线管理系统)中。在敏捷测试中，可能不需要测试用例，而是针对use case 或user story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为 软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如下图2所示。

    在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：

     l 测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论(包括带语言、视频的即时通讯)，仅仅通过邮件是不够的。

    参与代码复审(code review)，并适当辅助开发人员进行单元测试。

    在流程中增加一个环节“产品走查(Product work-through)”――测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。

    3. 新功能的测试和回归测试策略

     测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：

    不需要测试用例，直接基于用例、基于对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细(大颗粒度)。持续地进 行验证，一旦某块新代码完成(code drop), 就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。实施端到端(end-to-end)的测试，确保完整的业务流程 的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。基于经验， 可以实施更多的探索性测试、组合交互性(interoperation)测试和用户场景(user scenario)测试，更有效地发现埋藏较深的缺陷。

    回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没 变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些 办法可以帮助我们减少回归测试的范围，例如：

    通过执行code diff来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。基于风险和操作面分析来减少回 归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都 参与到日常的试用和测试中来

    4 自动化测试策略

     由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确 的策略来提高自动化测试的效益，如图30-3所示，并说明如下

    图3 自动化测试的策略

    4.1构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。

    4.2针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试。

    4.3集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。

    4.4在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面(UI)的自动化测试。

    4.5良好的IT基础设施，包括自动化构建软件包、自动化版本验证(BVT)、自动化部署、覆盖率自动产生等。

    5 敏捷测试工具

     自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。

    5.1 单元测试工具：TestNG、xUnit家族(如JUnit 、NUnit)、JMock、BizMock等。

    5.2 功能测试自动化：ThoughtWorks Twist。

    5.3 Web功能测试(frontend)：Selenium IDE/RC、WatiR、WatiN。

    5.4 Web service测试工具(backend)：soapUI 。

    5.5 性能测试：JMeter+BadBoy。

    5.6 验收测试框架：Fitnesse、Tellurium。

    5.7 敏捷测试过程管理工具：微软的Visual Studio 2010，包括TFS 2010、Scrum模板(MS VS Scrum 1.0)、Test Manager 2010、Coded UI Test等。

    5.8 业务智能(BI)应用的测试框架：Oraylis BI.Quality (+ NUnit)。

    5.9 其它一些协作工具等，如TestLink、BugZilla、BugFree、wiki、ant等。

    6 测试人员在敏捷方法中的价值

     在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？

    6.1 在需求和功能设计讨论上，测试人员可以站在客户角度上来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。

    6.2测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。

    6.3 测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测，确保单元测试达到80%以上覆盖率，确保开发出具有良好可测试性的代码。

    6.4在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统(模块或组件)，集成测试和端到端(end-to-end)测试显得更为重要，测试人员在这些测试上能发挥更大的作用。

    6.5 产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。

    6.6 一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。

    理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换，如在当前版本开发(/迭代周期)中担任测试人员角色，在下一个版本 开发(/迭代周期)中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。

    小结

     根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：

     l 敏捷测试就是持续测试、持续反馈，扮演“用户代表”角色，确保产品满足客户的需求。

    敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试) + 原有功能的自动化测试 (回归测试)

    敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。

    敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。

建议继续学习：

1. Xvfb+YSlow+ShowSlow搭建前端性能测试框架    (阅读：54187)
2. 安全测试与渗透测试区别    (阅读：23674)
3. 使用Fiddler对手机应用进行抓包测试    (阅读：6894)
4. 腾讯敏捷开发及快速迭代    (阅读：6500)
5. 服务器性能测试工具推荐    (阅读：6437)
6. 给Apache做压力测试时遇到的问题    (阅读：5891)
7. WEB性能测试工具推荐    (阅读：5628)
8. 可用性测试好助手——Morae软件的应用    (阅读：5456)
9. 12款很棒的浏览器兼容性测试工具推荐    (阅读：4844)
10. 可用性测试的权衡之道（二）    (阅读：4788)