4 自动化测试策略
由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的策略来提高自动化测试的效益，如图30-3所示，并说明如下。
图3 自动化测试的策略
l 构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。
l 针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试。
l 集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。
l 在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面（UI）的自动化测试。
l 良好的IT基础设施，包括自动化构建软件包、自动化版本验证（BVT）、自动化部署、覆盖率自动产生等。
5 敏捷测试工具
自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。
l 单元测试工具：TestNG、xUnit家族（如JUnit 、NUnit）、JMock、BizMock等。
l 功能测试自动化：ThoughtWorks Twist。
l Web功能测试（frontend）：Selenium IDE/RC、WatiR、WatiN。
l Web service测试工具（backend）：soapUI 。
l 性能测试：JMeter+BadBoy。
l 验收测试框架：Fitnesse、Tellurium。
l 敏捷测试过程管理工具：微软的Visual Studio 2010，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
l 业务智能（BI）应用的测试框架：Oraylis BI.Quality (+ NUnit)。
l 其它一些协作工具等，如TestLink、BugZilla、BugFree、wiki、ant等。
6 测试人员在敏捷方法中的价值
在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？
l 在需求和功能设计讨论上，测试人员可以站在客户角度上来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。
l 测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。
l 测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测，确保单元测试达到80%以上覆盖率，确保开发出具有良好可测试性的代码。
l 在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（end-to-end）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。
l 产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。
l 一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。
理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换，如在当前版本开发（/迭代周期）中担任测试人员角色，在下一个版本开发（/迭代周期）中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。
小结
根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：
l 敏捷测试就是持续测试、持续反馈，扮演“用户代表”角色，确保产品满足客户的需求。
l 敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试) + 原有功能的自动化测试 (回归测试)
l 敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。
l 敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
