[Test]敏捷测试的方法和实践

九 7th, 2011

       以前做开发的时候,我们尝试过敏捷,现在回过来想想,当时我们的测试人员比开发更加迷茫,常常会不知道如何开始自己的工作。现在,回到测试的岗位,重新思考这个问题,发现还是很难定义敏捷过程中测试的一些定义,下面是朱少民在程序员杂志上发表的一篇文章,我觉得很有用处,分享之:


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

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

  • 究竟什么是敏捷测试?
  • 敏捷测试有哪些流程改进?
  • 测试人员如何面对敏捷测试的挑战?
  • 在敏捷测试中如何制定相应的自动化测试策略?

什么是敏捷测试

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

图1  敏捷测试定义的形象描述

图1 敏捷测试定义的形象描述

敏捷测试流程的优化

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

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

图2  敏捷测试流程简要图

图2 敏捷测试流程简要图

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

  • 测试人员不仅要全程参与需求、产品功能设计等讨论,而且要面对面地、充分地讨论(包括带语言、视频的即时通讯),仅仅通过邮件是不够的。
  • 参与代码复审(Code Review),并适当辅助开发人员进行单元测试。
  • 在流程中增加一个环节“产品走查(Product Walk-through)”——测试人员和产品经理、开发人员等在一起,从头到尾将新功能看一遍,可直观、快速地发现问题。

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

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

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

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

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

自动化测试策略

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

图3  自动化测试的策略

图3 自动化测试的策略

  • 构建一个灵活的、开放的自动化测试框架,如基于关键字驱动的自动化框架,使测试脚本的开发简单易行,脚本维护也方便。
  • 针对稳定的产品特性开发自动化测试脚本,也就是针对前期完成的已有功能开发自动化测试的脚本,而大部分新功能测试采用手工测试
  • 集中精力在单元层次上实现自动化测试,主要由开发人员实施,测试人员提供单元测试框架,并辅助完成一些所需的基础工作。
  • 在产品设计、编程时就很好地考虑了自动化测试的需求,使全面的、自动化的底层测试、接口测试成为可能,尽量避免用户界面(UI)的自动化测试。
  • 良好的IT基础设施,包括自动化构建软件包、自动化版本验证(BVT)、自动化部署、覆盖率自动产生等。

敏捷测试工具

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

  • 单元测试工具: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等。

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

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

  • 在需求和功能设计讨论上,测试人员可以站在客户角度来阐述自己的观点,扮演“用户代表”角色,强调用户体验,真正体现测试人员和开发人员的互补作用。
  • 测试人员不仅扮演“用户代表”角色,而且通过需求讨论、代码复审等各种活动及时地提供质量反馈,包括代码质量、接口一致性等,保证在产品构造的整个过程中质量受到足够的关注,以提高质量改进的持续性和可视性。
  • 测试人员应积极参与单元测试,即使不参加单元测试,也应督促开发人员进行单元测试,确保单元测试达到80% 以上覆盖率,确保开发出具有良好可测试性的代码。
  • 在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块或组件),集成测试和端到端(End-to-End)测试显得更为重要,测试人员在这些测试上能发挥更大的作用。
  • 产品发布前,验收测试和回归测试依然不可缺少,这更是测试人员的用武之地。
  • 一个迭代周期结束后,对缺陷根本原因进行分析、总结规律,帮助开发人员建立良好的习惯,预防缺陷,从根本上提高产品质量。

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

总结

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

  • 敏捷测试就是持续测试、持续反馈,扮演“用户代表”角色,确保产品满足客户的需求。
  • 敏捷功能测试 = 新特性的手工测试(Use Case验证和探索性测试) + 原有功能的自动化测试 (回归测试)。
  • 敏捷测试人员和开发人员的区别越来越小,理想情况下,敏捷方法中,测试人员和开发人员在不同的迭代周期可以互换。
  • 敏捷测试流程依据不同的团队特点、不同产品的特点而不同,因地制宜,适合才是最好。

作者朱少民,网迅(中国)软件有限公司资深QA总监。中国科技大学软件学院教学指导委员会委员,中国软件测试认证委员会(CSTQB)资深专家。在软件工程 领域颇有建树,先后获得多项科技进步奖、出版十多部著作和高校精品教材,如《全程软件测试》、《软件测试方法和技术》等。





除非注明,本站文章均为原创。本文基于 BY-NC-SA 协议进行授权,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 metaboy(包含链接).

本文链接地址: http://blog.wangyuxiong.com/archives/51277

订阅本站:http://www.wangyuxiong.com/feed

分类: 思考讨论 测试技术         标签: , ,
目前还没有任何评论.

无觅相关文章插件,快速提升流量