基于 Scrum 方法的敏捷测试探讨

Posted IT项目管理界

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于 Scrum 方法的敏捷测试探讨相关的知识,希望对你有一定的参考价值。

摘要:近年来Scrum已经逐渐成为主流的敏捷开发方法被广泛采用,但测试环节却经常得不到有效的重视,软件质量无法得到保障。本文在Scrum方法的基础上,通过在每次迭代过程中加入单元测试流、系统测试流和QA控制流,从三个不同的维度对软件产品的质量进行验证与控制,并与每次迭代周期同步完成测试用例库的积累和完善。通过使用本方法可以有效的减少后续测试用例的编写投入成本,缩短软件产品的交付时间,并显著提高最终软件产品的质量。

关键词: 软件工程;过程改进;软件测试;敏捷;scrum

Scrum 敏捷开发方法经过多年的理论完善与市场验证, 逐渐发展为一套流程完备、过程清晰且具有高可操作性的软件开发方法体系。由于它可以快速适应用户的需求变更, 并且能够通过迭代的方式持续交付可运行的系统,因此非常适合当前对软件产品迅速变化、持续改进的市场需求, 被众多的软件开发组织接纳并采用[ 1 ] 。

但在使用Scrum 方法开发软件的过程中, 与其配合的测试环节却经常得不到足够的重视, 通常只由开发人员进行模块自测或测试工程师凭经验对系统功能进行测试。由于缺少传统软件工程中的测试用例和测试计划, 导致测试过程随意性较大, 同时也无法对增量产生的软件产品进行有效的回归测试, 造成软件质量无法得到保障[ 2 ] 。

本文针对以上问题, 通过对S c r um 方法进行改进, 提出了一种适合于Scrum 敏捷开发的测试模型。它将每次迭代周期与“单元测试流”、“系统测试流”和“Q A 控制流”紧密集成, 将开发人员和测试人员的工作量平均分配不同的流程节点, 并通过测试用例的“复用库”实现测试用例复用管理, 使用测试用例“回归库”完成对迭代增量软件产品的回归测试。通过本方法改进可以有效的规范敏捷测试流程,提高测试用例的复用程度和软件产品的质量。

1 .Scrum方法简介

Scrum 方法的核心思想是使用一种简单且有效的方法对软件开发过程进行管理, 它抛弃了传统软件过程中大量的文档和复杂的过程, 提倡团队成员之间密切配合, 快速响应用户的需求变化。Scrum 方法将软件开发过程划分为若干个迭代周期, 每个周期开始之前开发团队和客户一起规划本次应该完成的内容, 在随后的迭代周期中完成相应的软件开发[ 3 - 4 ] 。在开发过程中团队成员每天都要召开“站立会议”, 汇报前一天的开发进度和遇到的问题, 并安排当天的工作内容[ 5 ]。在一个迭代周期结束后, 团队向用户提交一个可以正常运行的软件系统, 作为本次迭代的交付物,经过多次这样迭代开发后产品最终满足用户的需求( 图1 ) 。Scrum 敏捷开发非常强调“人”的作用, 同时又不排斥过程管理, 并认为过程是将人的精力集中于结果的组织化结构, 反过来这种组织化结构将引导工作, 并影响产品和组织中人的关系发展[ 6 ]。

2. 敏捷测试方法及其改进

2.1 敏捷测试定义

敏捷测试在当前软件开发方法体系中并没有一个明确的定义, 通常认为敏捷测试是指与敏捷开发过程相配合, 能够快速拥抱变化并及时响应用户需求变更, 同时还要适应敏捷开发的价值观的测试过程的测试方法[ 7 - 8 ]。在测试执行过程中需要不停的进行迭代, 以便调整测试的重点和目标, 还要以用户价值为核心, 从使用者的角度对系统的功能需求与非功能需求进行验证, 最终为用户提供符合要求的软件产品。

2.2 基于Scrum方法的敏捷测试过程改进

本过程改进是在原有的Scrum 敏捷方法中增加了3 条以质量为核心的工作流, 分别从单元模块测试、系统集成测试和Q A 质量保障三个方面对每次迭代的产品进行质量验证, 保障本次发布给用户的最终产品满足规定的质量标准(图2)。

2.2.1 单元测试流

单元测试流需要项目开发人员参与, 主要工作集中在Scrum 迭代的开发环节。考虑到在敏捷开发过程中尽量控制项目的边界范围, 因此建议使用“测试驱动开发”( T D D )的方式进行操作。即在明确要开发某个功能的基础上, 根据用户的需求先编写出测试代码满足这些测试用例, 接下来再开发业务代码使这些测试用例能够顺利通过验证, 逐步完成软件的全部功能[ 9 - 1 1 ]。

为了能够让单元测试用例尽可能复用, 减少编写重复用例带来的资源浪费, 需要为这些测试用例建立一个“复用TD D用例库”[1 2-13 ]。在确定用例时首先需要在复用库中查找是否存在可以复用的资源, 如果存在这样的资源则直接在复用库中取出使用, 或根据实际情况对被复用用例进行微调后再使用。如果不存在能够被复用的测试用例资源,则需要开发人员编写一个新的用例, 并将这个用例使用在单元测试过程中。对于新编写的用例需要在本次迭代过程中进行评审, 以确定是否具有复用性。评审人员通常由开发团队的程序员、设计人员和项目技术负责人共同组成,从用例的功能、用途、适用性、通用性等几个方面对其进行评审。对于复用性较高的单元测试用例, 需要将期加入到“复用T D D 用例库”以备未来迭代过程中重复使用, 如果用例复用性不高, 则只在本次测试中使用。

除了复用用例库外, 还需要为项目建立一个“回归T D D用例库”。每次测试使用的测试用例都需要加入到回归库中, 方便在后续迭代过程中对系统进行回归测试, 确保每次增加的功能不会对已有代码产生不良的影响[ 1 4 ] 。

2.2.2 系统测试流

系统测试是在功能层面上对软件进行测试, 主要验证系统的功能特性与非功能特性是否符合要求。在系统测试流中需要软件测试团队的人员参与, 由他们负责编写测试用例并对系统进行验证。参与时机为每次迭代过程中制定本次开发周期的“产品功能列表”工作节点, 这时周期性的软件功能已经明确, 测试人员即可以着手规划本次的功能测试用例。

根据Scrum 开发的特点, 也要尽可能的提高功能测试用例的可复用性, 因此需要建立“复用功能测试用例库”。具体操作流程与单元测试近似, 测试人员在编写功能测试用例时首先到复用库中查找用例, 如果存在可以使用的测试用例则直接取出后使用, 如果不存在则需要手动编写新的测试用例。新编写的测试用例需要在本次迭代过程中,由测试人员、测试负责人共同进行评审, 如果用例具备较高的可复用性, 则可加入“复用功能测试用例库”以备后续的迭代过程中重复使用。

功能测试层面同样需要进行回归测试, 因此还需要为系统测试流建立一个“回归功能测试”用例库。每次迭代过程中的测试用例都需要加入到此库, 在后续的开发过程中进行回归测试, 确保代码不会受到不良影响。

2.2.3 QA控制流

Q A 人员在软件开发团队中主要负责质量保证工作, 包括建立保障制度体系、过程改进、指导项目实施、项目活动评审、审核工作产品、进行缺陷预防、实现质量目标等一系列的工作[15 ]。在Sc rum敏捷开发过程中“QA控制流”是一条贯穿整个迭代过程的质量控制流程, 这个过程需要Q A 质量保证部门的人员参与, 根据组织对软件产品的质量定义使用过程监控、过程改进等手段对开发过程进行影响与干预, 保证软件产品的质量。

在每次迭代完成后, Q A 部门会对本次开发过程进行评审, 其中主要包括开发和测试两部分。如开发过程的合规性、代码规范性、是否按照组织的要求对程序进行注释, 是否包括“序言性”注释等, 除此之外还需要对测试流程、用例入库评审过程、回归测试执行时机和结果等方面进行评价。

以上3 个测试流分别从实现层、功能层、过程层三个维度对Scrum 开发模型进行质量验证和控制, 从一次迭代周期的功能确定, 到代码开发和最后的产品交付, 每个环节都有相应的质量验证的方法相配合。不同角色的人员也被分配的相应的节点, 工作内容相互衔接与配合, 形成一套完整、独立的质量保证机制。

2.3 过程改进后的优势

2.3.1 测试环节快速响应需求变更

在使用Scrum 敏捷方法开发软件的过程中, 通常会以4周时间为一个迭代周期, 在这期间团队成员会针对已明确定义的软件功能进行开发, 迭代结束后再考虑下一个周期需要开发的内容。这时用户需求发生变化的概率非常大,每个迭代周期都有可能加入新的需求, 甚至会被要求修改已开发完成的软件功能。改进后的测试工作能够在每次迭代时进行适应性调整, 以满足不断变化的软件需求[ 1 6 ] 。

2.3.2 能够增量完善测试用例库

使用Scrum 方法开发软件时, 需求是一个逐渐增加的过程, 任何一次迭代都不能表现出系统的功能全貌。改进后的测试流程可以适应这种增量模式, 在每一个迭代周期中都要产生相应的测试用例, 并在每个开发周期结束后将其合并到回归测试用例库。产品交付前需要对软件进行回归测试以确保本次迭代开发没有破坏已有的系统功能, 此时增量积累的测试用例库即可做为回归测试的依据, 不仅提高了测试的准确度也可以显著减少测试人员的工作强度。

2.3.3 全员参与测试过程,加强质量观念

在敏捷测试过程, 不仅要求测试团队参与测试过程,开发人员也需要对自己完成的功能进行单元测试。每个功能开发完成后, 首先由开发人员对本功能模块从程序逻辑、代码路径覆盖、环路复杂度、模块接口、参数传递等多个层面完成单元测试, 通过测试后再交由测试团队使用“黑盒测试”的方法由功能层面对模块进行测试。使用这种方法能够让软件的开发人员和测试人员密切配合, 共同参与到产品质量保证过程中, 实现了全员参与测试、全员关注质量的管理目标。改进后的测试流程在敏捷测试的每个工作节点都有相应的测试验证环节, 并合理的将不同角色分配到这些节点, 使团队中的每位成员都能够参与质量保证过程。

2.3.4 为自动化测试工具提供数据支持

由于Scrum 敏捷开发方法周期较短, 要求在最快的时间里为用户提供可以运行的软件产品, 因此不能在测试环节上耗费太多的时间。通过对测试过程的改进, 能够逐步积累回归测试用例, 此时可以配合使用自动化工具来提高软件测试的效率和质量, 同时还可以有效的降低测试人的员的工作强度。

3. 结语

本方法改进是在Scrum 敏捷开发的基础上, 通过引入单元测试流、系统测试流和Q A 控制流, 从三个不同的维度对产品质量进行测试和保障。这种改进方式在保持敏捷开发特性的前提下提高了交付软件产品的质量, 并通过多次迭代过程逐渐积累和完善复用测试用例库, 减少后续测试用例的编写成本, 缩短软件产品的交付时间, 提高用户的满意度。

参考文献

[1]刘雪萍,段学东.敏捷开发与CMMI融合探讨[J].硅谷,2012(7):3-4.

[2]刘慧玲,王申申,陈晓军.Scrum敏捷方法在快速开发中的实践及改进[J].电脑知识与技术,2012,08(21):5168-5169.

[3]陈莹.瀑布式开发流程与 SCRUM 开发流程的分析与优化[J].信息与电脑,2016,11:123-124.

[4]张孟.敏捷开发中原则与过程的分析与研究[J].科技传播,2013(2):197-198.

[5]张思凯.结合 CMMI 的 Scrum 敏捷软件开发研究[J].电子技术与软件工程,2015(9):66-66.

[6]杜敏成.基于 Scrum 敏捷开发思想的软件开发过程管理[J].软件导刊,2015,14(10):12-14.

[7]李逆, 吴艳阳. 敏捷开发中的软件测试研究[J ]. 软件导刊,2016,15(4):16-19.

[8]刘梦飞,徐伟.运用敏捷思想改进软件测评流程[J].软件导刊,2014(11):10-12.

[9]张晓静.敏捷测试在移动 App 开发中的研究与应用[J].电子科学技术,2015,2(2):211-213.

[10]陈希,徐明昆.测试驱动开发在软件开发中的研究与实践[J].软件,2012,33(12):177-181.

[11]彭振龙.测试驱动开发与软件质量保证探析[J].泉州师范学院学报,2013,31(6):90-93.

[12]陈迪舸.刍议测试驱动开发在软件开发中的作用[J].电子技术与软件工程,2016(7):60-60.

[13]芮素娟.可复用测试用例研究[J].电脑知识与技术.2013,9(14):3308-3310.

[14]刘沅斌.基于共性分析的软件测试用例复用技术研究[J].中国管理信息化.2016,19(13):177-180.

[15]成亚玲,李健,彭湘华.回归测试用例优化选择研究综述[J].湖南工业职业技术学院学报.2015(2):13-20.

[16]计平,王文涛.GJB5000A 体系下的软件 QA研究[J].信息技术与信息化,2016(5):123-125.

本文2017年发表于《数字技术与应用》

以上是关于基于 Scrum 方法的敏捷测试探讨的主要内容,如果未能解决你的问题,请参考以下文章

Nokia Scrum Test:这是一个判断团队是不是敏捷的测试方法

Nokia Scrum Test:这是一个判断团队是不是敏捷的测试方法

敏捷测试模式之Scrum及其实践

敏捷测试模式之Scrum及其实践

基于JIRA的Scrum敏捷开发的项目管理

基于JIRA的Scrum敏捷开发的项目管理