基于风险和操作面分析来减少回归测试的范围,例如回归测试只是保证主要功能点没有问题,而忽视一些细节的问题。
持续测试的过程,只要有时间,就进行测试,包括开发人员、产品设计人员都参与到日常的试用和测试中来。
自动化测试策略
由于开发周期短,需求、设计等方面沟通也需要花费很多时间,没有足够时间开发自动化测试脚本,至少对新功能的测试很难实现自动化测试。这时候,就需要正确的策略来提高自动化测试的效益,如图3所示,并说明如下。
图3 自动化测试的策略
构建一个灵活的、开放的自动化测试框架,如基于关键字驱动的自动化框架,使测试脚本的开发简单易行,脚本维护也方便。
针对稳定的产品特性开发自动化测试脚本,也就是针对前期完成的已有功能开发自动化测试的脚本,而大部分新功能测试采用手工测试
集中精力在单元层次上实现自动化测试,主要由开发人员实施,测试人员提供单元测试框架,并辅助完成一些所需的基础工作。
在产品设计、编程时就很好地考虑了自动化测试的需求,使全面的、自动化的底层测试、接口测试成为可能,尽量避免用户界面(UI)的自动化测试。
良好的IT基础设施,包括自动化构建软件包、自动化版本验证(BVT)、自动化部署、覆盖率自动产生等。
敏捷测试工具
自动化测试依赖于测试工具,所幸的是,目前已有很多敏捷测试工具。由于篇幅所限,这里只是简单地列出一些常用的敏捷测试工具,不再深入讨论了。
单元测试工具:TestNG、xUnit家族(如JUnit、NUnit)、JMock、BizMock等。
功能测试自动化:ThoughtWorks Twist。
Web功能测试(frontend):Selenium IDE/RC、WatiR、WatiN。
Web service测试工具(backend):soapUI。
验收测试框架: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等。
测试人员在敏捷方法中的价值
在敏捷方法中,开发人员的主导作用更明显,系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上,测试人员容易被边缘化。那么,在敏捷方法中,测试人员的价值又如何体现呢?
在需求和功能设计讨论上,测试人员可以站在客户角度来阐述自己的观点,扮演“用户代表”角色,强调用户体验,真正体现测试人员和开发人员的互补作用。
测试人员不仅扮演“用户代表”角色,而且通过需求讨论、代码复审等各种活动及时地提供质量反馈,包括代码质量、接口一致性等,保证在产品构造的整个过程中质量受到足够的关注,以提高质量改进的持续性和可视性。
测试人员应积极参与单元测试,即使不参加单元测试,也应督促开发人员进行单元测试,确保单元测试达到80% 以上覆盖率,确保开发出具有良好可测试性的代码。
在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块或组件),集成测试和端到端(End-to-End)测试显得更为重要,测试人员在这些测试上能发挥更大的作用。
产品发布前,验收测试和回归测试依然不可缺少,这更是测试人员的用武之地。
一个迭代周期结束后,对缺陷根本原因进行分析、总结规律,帮助开发人员建立良好的习惯,预防缺陷,从根本上提高产品质量。
理想情况下,测试人员掌握设计模式、具有很好的编程能力,可以和开发人员进行角色互换,如在当前版本开发中担任测试人员角色,在下一个版本开发中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识,消除沟通的障碍,开发的效率和质量会有进一步的提高。
总结
根据上面的讨论和我们的实践,最后针对敏捷测试进行一个简单的总结,就是:
敏捷测试就是持续测试、持续反馈,扮演“用户代表”角色,确保产品满足客户的需求。
敏捷功能测试 = 新特性的手工测试(Use Case验证和探索性测试) + 原有功能的自动化测试 (回归测试)。
敏捷测试人员和开发人员的区别越来越小,理想情况下,敏捷方法中,测试人员和开发人员在不同的迭代周期可以互换。
敏捷测试流程依据不同的团队特点、不同产品的特点而不同,因地制宜,适合才是最好。
作者朱少民,网迅(中国)软件有限公司资深QA总监。中国科技大学软件学院教学指导委员会委员,中国软件测试认证委员会(CSTQB)资深专家。在软件工程 领域颇有建树,先后获得多项科技进步奖、出版十多部著作和高校精品教材,如《全程软件测试》、《软件测试方法和技术》等。
原文转自:http://www.wangyuxiong.com/archives/51277