基于Scrum的敏捷测试探讨

2017-11-08 15:58范少芬
智能计算机与应用 2017年5期

范少芬

摘要:在用户需求多变的软件市场,如何快速响应并及时发布与用户需求相符的软件是当前软件开发所遇到的主要挑战。传统的软件开发模式和软件测试流程在当前用户需求经常变化的新形势中已不再适用。敏捷开发和敏捷测试应运而生。敏捷的核心思想是“拥抱变化”、“增量迭代”和“随时交付”。本文研究表明,基于Scrum的敏捷测试则是一种实用有效的技术设计研发方法。

关键词:敏捷测试; 敏捷开发; Scrum; 迭代

中图分类号: TP311.5

文献标志码: A

文章编号: 2095-2163(2017)05-0111-03

Abstract: With the market of user's requirement always changing time by time, how to response and release the new software to meet the user's requirements promptly is the key challenge. The traditional software development model and software test procedure are not applicable in the current environment. Hence, the agile development and agile test are came up. The core idea of agile theory are “hug the changes”, “sprint increment” and “release anytime”. The research shows that the agile test based on Scrum is a practical and effective technical design and development method.

Keywords: agile test; agile development; Scrum; sprint

0引言

隨着互联网技术的快速发展,软件市场中的最大的挑战是如何快速发布产品,使其及时响应市场的需求变化。传统的软件开发模式如瀑布模型要求用户需求在整个项目过程中尽可能保持不变,一旦在开发过程中出现需求变化,将导致整个项目进程推迟。为了要适应这种快速变化的市场需求,并及时响应快速推出相应软件产品,针对传统开发模型的不足,敏捷开发思想即获正式提出[1]。敏捷开发(Agile development)的核心思想是“增量迭代”、“拥抱变化”和“随时交付”。与传统的软件开发模型相比,敏捷开发引入了“迭代开发”的概念。其中,Scrum为目前企业中使用范围最广的敏捷开发模型之一。

1Scrum方法简介

Scrum将整个开发过程划分为若干个迭代周期(sprint),每个迭代本身又是一个小瀑布。在每个迭代周期开始之前,团队都需要和客户讨论并确认该迭代周期中的用户需求和期望达成的目标。在每次迭代开发过程中,该项目的所有成员每天早上都需要参加简短的“站立会议”,以便于对项目相关的最新进展进行沟通,并评估可能存在的潜在风险,所有项目成员均可快速了解项目所处的最新状态。通常将“站立会议”定为每天上班的第一项活动,时间尽量控制在15 min之内,汇报当前开发的最新进展以及遇到的困难和潜在的风险,并安排当天亟待开展的主要工作。每个迭代周期结束之后都可以生成一个可交付的、并且可增量迭代的软件版本。通过多次迭代之后,最终得到符合用户需求的软件/产品。Scrum方法的具体流程如图1所示。在Scrum的开发模型中,客户可随时提出新的需求。新需求提出之后,本次迭代仍按原计划进行,当本次迭代结束后,在下一个迭代周期中将把客户提出的最新需求加入开发需求。正因如此,敏捷开发才可对客户的需求实现快速响应,拥抱变化和随时交付的核心思想也得以体现。

2敏捷测试简介

2.1传统测试方法的弊端

传统的测试方法是适用于瀑布开发模型的研究设计,参照瀑布开发模型的项目需要严格按照:需求分析、概要设计、详细设计、编码、单元测试、集成测试和维护的流程执行。因此,传统的测试只能等到一定阶段之后、即单元测试结束之后才能开始集成测试,缺陷数量将在这个阶段呈爆发式的增长,整个项目的风险将集中出现在集成测试的后期。随着项目进展到了集成测试阶段,项目也因此需要耗费更多的成本,包括人力、物力和财力去弥补缺陷。分析可知,传统软件测试显现的弊端可表述如下:

1)集成软件测试介入项目的时间偏迟,造成项目进度和风险均难于控制。

2)整个项目要求需求稳定,但实际项目中却经常会遇到需求发生改变的情况。比如开发人员对需求理解出现偏差,客户后期又加入新的需求等等都将导致需求发生变更。一旦需求发生变化,在这种模型下项目出现延迟的风险较大,按原计划交付的可能性较小。

2.2敏捷测试概念及流程

敏捷测试[2],一般将其理解为“遵循敏捷核心思想和敏捷宣言”的测试实践活动,即基于增量迭代,“拥抱变化”,并对用户的需求变更能快速响应。基于Scrum的敏捷测试模型如图2所示。

在基于Scrum的敏捷测试模型中,一个项目可以划分为多次迭代(sprint),每个迭代可再细分为多个story。其中,story的制定需要参与项目的所有的团队成员包括项目经理、研发和测试人员共同讨论制定。这充分体现了在敏捷模型中测试人员提前介入的思想,避免了传统测试中的测试人员介入过晚的弊端。

story的澄清是为了让测试人员能深入地了解各个story的内部系统设计。一个优秀的测试人员会站在最终用户的角度,多以怀疑的态度去考察每个story的内部设计,这样可以让测试人员尽早发现问题,及时识别项目中潜在的风险。这一阶段后,团队应制定项目验收测试标准,并对测试用例进行评审和验收。endprint

在单元测试与模块重构阶段中,最常用到的就是测试驱动开发的方法(TDD,Test Drive Develop)。TDD的基本思想:开发人员依据项目的需求先撰写测试代码,此后再根据测试代码来编写开发代码,即通过测试来驱动开发。先思考如何对预期目标功能进行测试和验证,与之同时构写测试代码,然后根据测试代码编写满足且仅仅满足的这些测试用例的功能代码,直到测试通过[3]。至此,还将依次展开2种测试。测试内容可总述如下:

1)冒烟测试。在完成了story的代码和模块集成之后,需要把所有story的模块聚合在一起进行冒烟测试,也称联调测试。冒烟测试通常使用自动化测试,测试的主要目的是在最短时间里检查系统能否正常运行。仅仅是检查最基本的系统运行情况,并不深入检查模块内部功能的细节,因此只需要执行最基础功能的自动化测试用例。

2)迭代驗收测试。主要是根据项目初期制定的测试标准进行迭代验收测试。迭代验收测试通过后,即可提交一个可执行的小版本。本次迭代结束,可进入下一个迭代周期,但测试的工作并没有结束。如果客户要求提前发布临时版本,该小版本可随时提交给客户。

2.3敏捷测试的优秀实践

相比传统的测试模型,敏捷测试[4]具有如下分类的优秀实践,研究阐释内容如下。

1)持续集成。持续集成(CI, Continuous Integration),是采用开源工具对新代码进行检查。具体设计流程如图3所示。每次对本轮迭代的新代码都需要提交到系统进行检测,仅有经由系统持续集成测试通过的新代码才能最终整合到之前的老代码中,从而保证了新代码的加入不会破坏老代码的功能[5]。

2)敏捷测试减少了对各种测试文档的严格要求,强调一页纸办公。传统的测试对各种测试文档具有非常严格的要求,要求各种测试文档和文件都尽可能详尽,造成人力和时间成本的大量的浪费。但敏捷测试摒弃了文档方面的苛刻要求,更强调团队之间的沟通与协作[6]。

3)敏捷测试强调使用自动化测试[7],且测试用例库应尽可能地可被复用。对冒烟测试和回归测试这2个阶段如果使用手工测试将耗费大量的时间和人力,在敏捷开发模型中是行不通的,因此必须采用自动化测试[8]。在第一次测试时可以采用手工测试,本轮迭代测试结束后,即需将测试用例转化为自动化测试脚本,以备下轮迭代的回归测试可使用自动化测试。编写测试用例时,应尽可能地编写可重复使用的测试用例,并将可复用的测试用例加入可复用的测试用例库,后续编写测试用例时应先查探复用库,如复用库中已有相关的测试用例,则可节省大量的重复劳动,提高工作效率[9]。

4)必须尽早开展测试,研发和测试人员的职能的区别已不再那么明显,研发人员也必须参与测试;测试人员不再只是专职主攻测试,需要尽早参与到需求分析、单元测试中的讨论中[10]。

3结束语

当前企业中软件开发和测试已经普遍使用敏捷思想。敏捷开发和敏捷测试模式相对于传统的软件开发模型和软件测试而言,更强调团队之间的沟通,接受用户随时提出的需求变更,引入迭代的概念,从而随时都可交付小版本的软件。

参考文献

MARTIN R C. Agile software development, principles, patterns, and practices[M]. NJ, USA:Prentice Hall,2002.

[2] 王璇. 敏捷测试理论与实践[J]. 软件导刊,2009,8(1):38-39.

[3] 唐亚男,王振一. 敏捷测试综述[J]. 硅谷,2011(5):133-134.

[4] KERN J. 敏捷的测试[J]. 程序员(技术版),2006(10):120-121.

[5] 邹波. 基于敏捷开发模式下的软件测试的改进和应用[D]. 成都:电子科技大学,2010.

[6] 叶俊民. 软件工程[M]. 2版. 北京:清华大学出版社,2010.

[7] KREBS J. Agile portfolio management[M]. 陈宗斌,等译. 北京:机械工业出版社, 2010.

[8] CRISPIN L, GREGORY J. Agile testing: A practical guide for testers and agile teams[M]. Canada:Addison-Wesley Professional, 2009.

[9] 蔡才霞,刘建平,刘娟娟. 基于敏捷测试的自动化技术分析与实践[J]. 工业控制计算机,2011,24(10):59-60.

[10]李季. 敏捷测试实践与相关问题研究[D]. 北京:北京交通大学,2010.endprint