01

敏捷测试的方法和实践

作者: baiyuzhong 分类:选题策划, 高端视点   阅读:36,148 次 添加评论

文 / 朱少民

有一次,当开发人员完成当前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)资深专家。在软件工程 领域颇有建树,先后获得多项科技进步奖、出版十多部著作和高校精品教材,如《全程软件测试》、《软件测试方法和技术》等。

本文选自《程序员》杂志2010年10期,更多精彩内容敬请关注10期杂志

《程序员》杂志订阅火热进行中

转播到腾讯微博

----->立刻申请加入《程序员》杂志读者俱乐部,与杂志编辑直接交流,参与选题,优先投稿

11 Responses to “敏捷测试的方法和实践”

  1. [...] 敏捷测试的方法和实践 八 [...]

  2. [...] (7)如何实现自组织团队 (8)忘记敏捷 (9)要有一个软件 (10)敏捷测试的方法和实践 (11)精益九问 [...]

  3. kui 说道:

    测试一下!!

  4. 是不是第9期 说道:

    本文选自《程序员》杂志2010年10期,更多精彩内容敬请关注10期杂志
    是不是第9期?

  5. The new route was named “La Classica Moderna” (the Modern Classic). Barmasse stated, “The ascent resembled the ethics and philosophy of Walter Bonatti who, in 1959, was the first person to climb on the monoliths of this side of Mont Blanc. I would define the style as modern-classic; a style that mirrors those of the pioneers, who, to get back home, had to reach the top of Mont Blanc, hence the name La Classica Moderna.”

  6. 小葵 说道:

    有机会试一试这套方法论
    顺带宣传下小妹的创意分享小站:品趣轩,每日分享一款能买到的创意,欢迎大家有事没事儿来溜溜,今日分享:tea-fishing泡茶工具 http://www.pinquxuan.com/2011/09/tea-fishing%E9%92%93%E8%8C%B6%E8%80%85%E8%8C%B6%E5%8C%85%E7%BB%B3%E6%9E%B6-%E5%9E%82%E9%92%93%E8%80%85%E8%8C%B6%E5%8C%85%E7%BB%B3%E6%9E%B6-%E6%B3%A1%E8%8C%B6%E5%B7%A5%E5%85%B7/

  7. 程序员 说道:

    不错 转载了http://www.chengxuyuans.com/
    呵呵

  8. 表示软件工程上面讲的什么测试啊什么的,感情蛮轻松的,真正做起来,一个头两个大。。。。。。。

  9. [...] 2010年为《程序员》杂志写了一篇《敏捷测试的方法和实践》,我们可以回过头来,看看过去的一年,敏捷测试发生了哪些变化。首先,我做了一个实验,分别打开2010年和2011年的“STAREAST Conference at-a-Glance”,输入Agile,2010年显示10个结果,而2011年显示17个结果,有一个很大的增长,说明敏捷测试越来越引起大家的关注。这只是一个表面的现象,我们还需要真正了解发生了哪些实质性的变化。 [...]

  10. Jiang 说道:

    说实话,这篇文章介绍的已经是很具有实践性的东西了。

  11. [...] 2010年为《程序员》杂志写了一篇《敏捷测试的方法和实践》,我们可以回过头来,看看过去的一年,敏捷测试发生了哪些变化。首先,我做了一个实验,分别打开2010年和2011年的“STAREAST Conference at-a-Glance”,输入Agile,2010年显示10个结果,而2011年显示17个结果,有一个很大的增长,说明敏捷测试越来越引起大家的关注。这只是一个表面的现象,我们还需要真正了解发生了哪些实质性的变化。 [...]

请评论

preload preload preload
京ICP备06065162