敏捷测试的方法和实践经验分享

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

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

　　5 敏捷测试工具

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

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

　   功能测试自动化：ThoughtWorks Twist。

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

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

　　性能测试：JMeter+BadBoy。

　　验收测试框架：Fitnesse、Tellurium。

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

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

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

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

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

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

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

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

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

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

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

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

　　小结

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

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

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

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

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

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

　   持续测试的过程，只要有时间，进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。