• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

敏捷测试的方法和最佳实践

发布: 2011-2-28 09:48 | 作者: 朱少民 | 来源: 领测软件测试网采编 | 查看: 306次 | 进入软件测试论坛讨论

领测软件测试网

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

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

  l 究竟什么是敏捷测试?

  l 敏捷测试有哪些流程改进?

  l 测试人员如何面对敏捷测试的挑战?

  l 在敏捷测试中如何制定相应的自动化测试策略?

  等等各种问题。

  1. 什么是敏捷测试

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

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

  2. 敏捷测试流程的优化

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

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

  图2 敏捷测试流程简要图

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

  l 测试人员不仅要全程参与需求、产品功能设计等讨论,而且要面对面地、充分地讨论(包括带语言、视频的即时通讯),仅仅通过邮件是不够的。

  l 参与代码复审(code review),并适当辅助开发人员进行单元测试。

  l 在流程中增加一个环节“产品走查(Product work-through)”——测试人员和产品经理、开发人员等在一起,从头到尾将新功能看一遍,可直观、快速地发现问题。

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

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

  l 不需要测试用例,直接基于用例、基于对需求的理解来完成新功能的验证。即使要写测试用例,只要保证各个功能点被覆盖,不要过于详细(大颗粒度)。

  l 持续地进行验证,一旦某块新代码完成(code drop), 就开始验证,而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。

  l 实施端到端(end-to-end)的测试,确保完整的业务流程的实现,同时,也容易发现业务逻辑不够清晰、不够合理等各方面的问题。

  l 阅读代码来发现问题,可以和开发人员工作保持同步,消除测试周期的压力。

  l 基于经验,可以实施更多的探索性测试、组合交互性(interoperation)测试和用户场景(user scenario)测试,更有效地发现埋藏较深的缺陷

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

21/212>

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网