敏捷测试过程

敏捷测试过程（精选4篇）

敏捷测试过程 篇1

敏捷测试是属于一种根据客户需求进行及时调整的敏捷化测试。测试过程中,需要测试人员与开发人员的高效配合,为达到软件质量过关的统一标准而进行开发与测试。测试过程与结果需要通过表格或其他记录方式进行展示,避免发生同样错误。敏捷开发的软件检测不仅能够检测出软件的质量问题,也能够为软件的质量提升做出贡献。为达到敏捷测试的效果,需要与客户及时沟通,了解客户的需求后及时做出调整。

1 软件测试的方法

1.1 根据透明度分类

透明度分类是将软件按照不同的透明度归类为黑盒测试和白盒测试。黑盒测试是把软件当作已经放入到一个黑盒子中的一个东西进行测试,测试时无需了解软件的实现过程,是以用户使用的角度进行的测试。白盒测试则是把软件当作放在一个打开的盒子里的东西进行测试,因为盒子是打开的,测试时会对软件的实现与构造一目了然,是深入到软件内部的一种测试。

1.2 根据开发过程分类

1.2.1 单元测试

单元测试属于白盒测试的一种,以盒子打开的形式对软件的代码单元进行测试,在函数式语言中以函数为单元测试。测试的方法是对单元进行编写代码,利用编写的代码进行测试。

1.2.2 集成测试

集成测试属于灰盒测试。灰盒测试是介于黑盒测试与白盒测试之间,测试时同黑盒测试一样,不需要考虑内部实现,也不用像白盒测试那样深入到软件结构中进行测试,只需要测试模块间的接口与配合的关系即可。

1.2.3 系统测试

系统测试属于黑盒测试,不需要了解软件的实现方法,但需要根据软件的规格需求进行测试。软件测试实际是由系统测试演化而来的,系统测试是开发中必要的测试环节,而大多数软件在开发过程中对单元测试和集成测试的要求很少。

1.2.4 验收测试

验收测试是用来验收软件是否能够达到用户的满意度,属于黑盒测试。上文提到的Alpha测试是内部测试,是用户在开发环境或者模拟测试环境下的测试;Beta测试是外部测试,是由软件的一个或多个用户在实际使用环境下进行的测试。两种测试方法均可在验收测试中使用。

1.3 针对性测试

针对性测试是针对软件的某一个或几个质量特性进行测试,比如软件的可靠性、易用性、可维护性等等,是将上文提到的几种测试方法相融合。测试中可能还需要对软件的安全性、性能、内存做针对性测试,测试不仅跨越各个开发阶段,同时也具有白盒和黑盒测试的特质。

1.4 安全性测试

安全性测试主要针对软件的使用安全性,随着互联网的发展,应用软件更容易受到威胁,软件的安全测试就显得尤为重要。可以通过语法、故障注入、模型安全及模糊测试的方法对软件的安全性进行测试。

1.5 性能测试

性能测试是为了验证软件是否能够达到用户提出的性能指标,同时发现存在的瓶颈,起到优化软件的目的。性能测试一般通过自动化的工具完成,如LoadRunner等。,软件性能的好坏往往是决定软件能否赢得用户的重要因素。

1.6 内存测试

内存测试是测试软件运行时的内存是否越界,对于泄漏、缺陷等问题进行检测,能够有效的检测出软件中存在的安全隐患。

2 敏捷开发的定义

敏捷开发(agile development)的概念是在2004年产生的,它是一种以人为本、循序渐进的软件开发方法。敏捷开发中,软件项目被划分为多个子项目,各个子项目的功能通过测试后便可运行。

敏捷开发主要是针对中小企业,这类企业的发展需要团队具有高效工作、满足需求和顺应变化的条件,因此提出了敏捷软件开发的理念。敏捷开发的方法很多,包括Crystal、自适应软件开发(Adaptive Software Develoment,ADS)、特征驱动软件开发及极限编程(Extreme Programming,XP)。

3 敏捷测试人员的定位

敏捷开发近年来受到社会各界的重点关注,原因是它能够应对客户多变的需求并不断进行相应调整开发的一种高效开发模式。敏捷开发中的测试人员也可以叫做QA (质量保证)人员。因此软件从开始设计时就需要与QA人员达成一致,双方的目标都是注重质量,构建软件形成,达到零缺陷的软件开发过程。QA人员需要站在客户的角度去思考,辅助开发人员完成设计和软件的实现,并对软件整体进行掌握,及时提出架构上的问题。QA人员还需要对客户反馈的信息进行统计,以便团队更好的改进问题。此外也需要与开发人员紧密合作,双方形成互补,避免敏捷测试对软件开发无用以及测试不完整的问题出现。

4 敏捷开发的软件测试过程概述

敏捷开发的测试方法不同于传统的测试,在敏捷开发测试中,测试决定整个项目组的去向,明确指出问题所在和改正方向,促使项目组在敏捷测试信息中做出正确的决定,测试人员根据检测出的错误,辅助开发人员进行修正。

4.1 初期测试工作重点

测试人员需要从软件开发初期便进行检测,对开发软件的测试重点是文档的完整性、严密性和功能设计的可测性。测试人员在软件开发初期,需要对软件做好需求分析,对设计做好逻辑分析,将每一环节中的检测结果积极、迅速的反馈给设计和开发人员。

4.2 测试用例设计及评审

敏捷开发的过程中,开发人员可以和客户直接沟通,确定每个功能的优先级。测试人员根据已经通过审核的设计方案编制测试计划,再设计相应的测试用例。测试的主要依据是软件产品设计文档,而这些设计文档也需要项目经理和开发人员一同对其进行审核。

4.3 测试执行

为了方便衡量软件当前的质量和判断测试是否达到出口标准,可以每天对测试结果进行分析,提供问题走势图,将每天新发现的缺陷问题和已被解决的问题的数量制成图表展示。在测试执行的开始阶段,缺陷问题数量会呈上升趋势,到中后期被解决的问题数量会上升,新发现的缺陷数量下降,最终发现的问题数量曲线趋于稳定并向零值趋近。

在发布软件版本之前,测试人员还需要根据发布的版本情况进行说明,对版本的说明应至少包括三方面的内容:已经修复的上个版本中存在的错误、新的功能、此版本还存在哪些问题。

4.4 需求管理

所采用的敏捷开发模式中,客户的需求变更较为频繁,因此对客户的需求进行管理是非常重要的工作。在软件开发过程中,不断的有新变化的需求,这就意味着软件测试的重点和方向需要根据新需求的变化而不断地调整。对于新变化的需求需要进行相应的记录,将每次的变更需求整理记录到文档中,文档始终保持在更新的状态,与客户的需求变化保持一致,方便后期的管理和维护。在敏捷测试中,这项工作由测试人员执行更为合理有效,一方面方便测试人员及时理解需求的变更内容,快速完成用例设计,执行测试;另一方面也能有效的起到质量保证的作用,检查开发人员开发出的产品是否符合变更后的要求。4.5清理Bug

在软件敏捷开发接近尾声时,可以进行一次整体的软件Bug问题大清理,这样做的好处是可以利用测试以外的多方力量,全方位、多角度的发现软件的遗留问题。可以在项目的时间进度安排里预留一个时间段完成这项工作,参与测试的人员需要集中的进行一次检测。需要注意以下几点:(1)参加检测的人员不仅需要包括测试人员,还需要有项目经理和开发人员甚至高层管理人员的加入,便于对发现问题的及时了解,并且集思广益快速解决问题。(2)鼓励各部门之间进行交叉测试,通过不同的思路和视角发现更多的错误。(3)还可以将软件检测进行专题分类,比如安全性检测、用户体验检测、国际化或本地化检测等等。

5 结论

综上所述,为了适应客户对软件产品的要求不断变化而出现了敏捷开发模式,相应地产生了敏捷测试的概念。在敏捷开发的测试过程中,核心关键是快速的响应、完成测试并反馈结果,并与开发同步及时展开测试。。敏捷开发测试不仅是一种高效的检测模式,还能够提高软件质量并且对软件进行预防错误处理。对于敏捷开发测试的发展,社会各界一直持有高度关注,相信通过科学技术的不断探索前进,能够更好的带动敏捷开发测试的应用及发展。

参考文献

[1]徐炳.基于CARD/1的高智能化互通立交设计系统的研究与开发[D].电子科技大学,2013.

[2]宋易欣.基于看板管理方法的敏捷软件开发研究[D].北京邮电大学,2013.

[3]胡丹.基于关键链的敏捷软件开发项目进度管理研究[D].浙江工业大学,201 3.

[4]谢业亮,昊群飞,戴勇.浅谈敏捷软件开发在电力系统信息化建设中的应用与发展[A].中国电机工程学会电力信息化专业委员会.电力行业信息化优秀论文集2013[C].中国电机工程学会电力信息化专业委员会,201 3(07).

[5]齐山松.基于敏捷软件开发模型的研究与实践[J].电子科技,2 01 3,05(07):4 3-46.

敏捷中自动化测试策略 篇2

自动化测试是我们应用在敏捷中的类似万能的法宝。但是世界上没有万能的东西。这个就需要我们深刻理解自动化测试, 并且有好的测试策略来应用在自动化测试中。

1 自动化测试中人员的选配

我们的测试团队中, 人员的选配是, 有专门的测试人员, 但是开发人员也会在时间不够的情况下, 加入测试的队伍。在一个敏捷的团队中, 测试人员一般也是具有一定的编程能力的, 当与开发人员沟通一个BUG的时候, 能理解开发人员的话, 沟通更加顺畅。并且在项目需要的情况下, 也会加入开发的队伍中。

2 可以和不可以自动化的测试

2.1 可以自动化的测试

当代码改变, 有新的代码迁入迁出的时候, 这个时候, 需要触发自动化构建。我们通常使用Jenkins这样的持续集成工具, 用于做重复的工作。

自动化单元测试, 我们通常应用junit的单元测试工具, 进行TDD (测试驱动开发) 。

在UI比较稳定的情况下, 做GUI测试。

在回归的时候, 做功能性测试。

在接口测试, 我们可以用Excel, 把测试数据放入其中, 并且跟实际数据进行比较。

负载测试, 我们就必须用自动化了。因为手工测试肯定不准确。我们可以找一些开源的工具来测试。

2.2 不可以自动化的测试

对于可用性测试和探索性测试, 我们需要手工去执行。

3 自动化测试应用的时机

3.1 自动化测试的应用的原因

手动测试的时间远远大于自动化测试。一些重复性的工作最好应用自动化测试。回归测试的时候需要自动化。自动化可以发现手动中一些发现不了的BUG, 比如内存泄露。

3.2 自动化测试的应用的不同部分

在一个敏捷的团队中, 测试可以有自动和手动测试, 比如功能测试。必须手动的测试, 比如探索性测试。必须自动化的测试, 比如单元测试, 性能和压力等。

3.3 自动化测试的应用不同时机

初始的投入, 对于自动化测试来说, 是很大的投资。我们首先评价我们已经已有的工具, 看其价值, 和应用的复杂度。一般来说一些开源工具, 也可以满足我们的需要。而且这样的投入一般是有意义的。

对于变化非常频繁的代码。我们可以根据功能和目的去组织代码。

如果开始自动化呢?并不是非要股买昂贵的商业工具。一般来说, 自动化开始于单元测试, 这样收益是很大的。接着开展可以用于自动化的测试, 我们可以选择一些开源工具。我们并且用一些自动化的构建工具, 比如JENKINS等。我们可以选择开源的功能性验证工具, 比如selenium等。

4 组织测试

在敏捷开发中, 高效的沟通同样也适用于自动化测试。因为在迭代开发中, 当我们用自动化工具发现昨天的测试用例, 今天的版本失败了。我们就必须立刻去找开发沟通。看是, 更改那些地方了, 需求是不是有变化了。以便, 我们的自动化测试, 适应迭代的变化。

在整个团队中, 开发会更多的考虑代码的可测性, 有的时候, 还会给测试人员提供一定的接口, 来实现自动化测试。

工具的选择很重要。在我们的测试团队, 我们有TC, 但是selenium对功能性的验证测试, 有很大的好处, 又比TC好学。就用selenium了。对于开源工具很多都是比较好上手。但是, 对于商业工具, 虽然感觉上很好。但是, 在我们实际的应用的时候, 发现, 难学, 代码维护繁杂。如果, 我们有商业工具的专家, 那么用商业工具, 更能保证项目的质量。

5 结束语

自动化测试策略的应用, 对于我们实现自动化, 是必须经历的过程。好的而自动化测试是质量保证的利器。

参考文献

[1]Sehwaber K, Beedle M.Agile Software Development With Scrum[M].[S.1.]:Prentice Hall, 2001.

[2]Jonathan Rasmusson.敏捷武士看敏捷高手交付卓越软件.李忠利, 译.人民邮电出版社.2012

[3]Lisa Crispin, Janet Gregory, 著.敏捷软件测试:测试人员与敏捷团队的时间指南.孙伟峰, 崔康, 译.清华大学出版社.2010

[4]Martin R G.敏捷软件开发一原则、模式与实践[M].邓辉, 译.北京:清华大学出版社, 2003.

[5]Kniberg H.硝烟中的Scrum和xP一我们如何实施Serum[M].李剑, 译.北京:清华大学出版社, 2011.

[6]Mike Cohn.用户故事及敏捷方法.清华大学出版社.2010

敏捷过程改进模型与方法 篇3

敏捷方法强调个体和交互, 但并不是不重视过程。敏捷开发拥抱变化和客户反馈会对整个软件的架构、开发、测试造成很大的波动。如果控制不好, 会使得项目失控, 造成严重的质量问题, 如Bug多, 架构不合理, 易用性不好, 性能不好等等。所以, 过程仍然发挥着十分重要的作用, 良好的过程控制与改进仍然是不可或缺的。

2 敏捷过程改进模型

如图1所示, 该模型以需求分析与满意度度量结果为依据, 根据实际需要, 选择合适时机, 把过程改进活动与迭代活动有序融合起来, 在不影响正常敏捷开发活动的基础上, 持续改进过程, 以保证敏捷开发不会失去控制, 达成预定的质量目标。

2.1 敏捷过程改进的时机

敏捷过程改进的时机选择可以相对灵活, 一般来说有以下三类。

2.1.1 需求发生变化时

当需求发生变化, 应对软件开发过程的各个要素如人员、方法、活动等多方面进行综合优化与调整, 这一改进活动是贯穿敏捷开发过程的始终。

2.1.2 进入下一迭代时

在进入下一迭代过程前, 依据客户的评价结果进行分析, 找出客户不满意或满意度不高的地方, 查明原因, 制定合理的改进措施和计划。

2.1.3 过程或子过程质量不足以满足要求时

对过程用户的满意度进行分析, 可以判断过程质量是否满足需要, 进而确定过程是否需要改进。

2.2 敏捷过程改进的重点

敏捷方法的过程改进, 除了关注质量、成本、进度的硬指标外, 还应重视沟通与协调、参与者的体验, 组织文化的建设, 价值观的锻造, 以及这种改进的可持续性等一系列人文的因素, 当然必要的规范也是必不可少的。

2.3 敏捷过程改进的基本方法

如图2所示。

2.3.1 确定过程改进时机

敏捷过程改进需要团队将过程改进活动看作内在需要, 主动的去推动, 不同层次, 不同过程, 不同的改进活动, 其改进时机也各有不同。

2.3.2 确定过程改进对象

不同层次的改进活动, 其改进对象是不同的, 改进的难度也有差别, 为避免改进失败, 或对软件开发活动造成难以预测的风险, 应综合衡量, 合理确定改进对象。

2.3.3 确定过程改进的内容和重点

综合考虑人员、工具、方法、管理等多方面的因素, 以及改进对象的过程质量以及用户满意度, 确定改进的内容和重点。

2.3.4 制定改进措施与计划

确定改进目标, 以及改进活动的具体计划, 明确具体方法与步骤, 明确评测改进效果的指标与方法。

2.3.5 实施过程改进计划

依据制定的计划, 逐步实施, 确保改进措施落实到位。

2.3.6 评测改进效果

结合预期目标、软件小交付、顾客满意度等综合衡量改进效果。

3 敏捷过程改进实例分析

P公司在运用敏捷方法开发某大型数据库系统, 但在第一次迭代开发完成形成小交付软件给客户, 客户满意度不高, 主要不满意的地方:一是软件功能不完全满足客户需要;二是客户认为现有软件功能不足在市场上形成有效竞争力。造成这一结果的原因主要在于第一次迭代前的需求分析结果不够理想。需要对需求分析过程进行改进。

3.1 确定改进时机

这里主要是在第二次迭代开发前, 对需求分析过程实施改进。

3.2 确定改进对象

因是对敏捷环境下的需求分析过程实施改进, 因此, 此处改进对象是第一次迭代开发中的需求分析过程。

3.3 确定改进重点与内容

对上一次需求分析过程进行分析, 发现影响需求分析结果的主要原因, 一是客户的参与度不高, 对该数据库系统的市场定位不清, 难以准确描述所要期望实现的功能;二是开发人员的参与度不够, 部分开发人员忽视参与需求分析的沟通与交流。

3.4 制定改进措施与计划

一是由商务分析师采用质量功能展开等工具帮助客户对市场现状以及客户所要达成的目标进行分析;二是在迭代开始前, 与开发人员、客户进行交流, 共同评估用户故事优先级, 并收集相关反馈信息;三是由商务分析师主持召开迭代计划会议, 在会议上向所有的程序员解释这个迭代要完成的用户故事, 代表客户做功能验收测试, 查看是否完成了预计的功能, 是否有程序员还没有想到的异常情况。

3.5 实施改进措施与计划

在第二次迭代开始前, 按前文制定的措施实施了改进措施, 进行了新的需求分析, 并根据新的需求分析结果, 开展第二次迭代开发, 形成小交付。

3.6 评测改进结果

以客户对小交付软件的满意度为依据, 来检验改进效果。改进前后, 客户满意度如表1所示。

从表1中结果来看, 改进活动是有效的, 成功的。因此, 在敏捷环境下, 选择合适时机, 采取有效方法, 将改进与敏捷开发过程有机结合起来, 有助于中小企业更快更好的运用敏捷方法开发出有竞争力软件。

摘要：本文通过持续的改进, 来实现计划、控制与灵活、主动间的平衡。本文分析了运用敏捷方法时, 持续改进过程的必要性, 构建了敏捷开发过程改进模型, 介绍了敏捷过程改进的时机、重点与基本方法, 并结合实例进行了简要分析。

关键词：敏捷方法,过程改进,需求分析

参考文献

[1]Agile Process.http://www.agilealliance.com.

[2]Robert C.Martin, Micah Martin.Agile principles, Patterns, and ractices in C#.[M].Posts&Telecom Press, 2010 (12) :4.

[3]李新.敏捷开发平台的设计[J].计算机工程与设计, 2012 (09) :3604.

[4]沈雷.沈备军敏捷方法的研究与实践[J].计算机工程, 2005 (04) :219.

[5]段琳琳, 王如龙.敏捷方法在软件项目需求管理中的研究与应用[J].项目管理技术, 2009, 6 (7) :P61.

[6]张晓刚.面向软件过程改进的知识管理技术研究[D].北京:中国科学院研究生院博士学位论文:1.

[7]陈斌.基于CMMI的敏捷软件改进过程研.究[D].中国海洋大学研究生学位论文:12.

敏捷测试过程 篇4

敏捷宣言发布至今已近10年,随着敏捷开发逐渐成为主流开发,越来越多的企业开始尝试敏捷,拥抱敏捷。相对于传统的开发团队,成功的敏捷团队可以开发出更高质量的软件产品,能够以更快更低的成本满足用户的需求。作为敏捷开发中最受欢迎的一个流派,Scrum近几年越来越多被业界所广泛认同。Scrum能够使生产力显著提升和成本最大降低;能够更好地将产品推向市场并获得很高的客户满意度;能够提供更透明的开发过程,从而获得更高的预测能力。对IT企业来说,完全失控、永远无法完成的项目已经成为历史。

敏捷开发提倡以人为本,平等对待团队中的每一个成员,相信队友。他简单而直接的沟通能够让人有更多的主人翁意识。在这样的环境里工作成绩会更容易被大家看到并获得认可。敏捷开发强调团队,只是个人能力强而不懂得合作的人在团队里是无法取得成功的,在团队里“没有一个人的成功,也没有一个人的失败”[1]。

敏捷项目生命周期可以分为项目的初始阶段、中间阶段以及最终阶段。初始阶段主要是对交付产品进行高层计划;中间阶段是一系列的以可工作代码的方式体现的发布或者迭代;最终阶段进行系统发布,完成最后项目回顾以及其他结束前的处理。

Scrum只是敏捷管理中的一种实践框架,它是一种灵活的敏捷软件开发管理过程,提供了一种经验方法,帮助实现了递增的软件开发过程。Scrum开发过程管理贯穿于敏捷项目生命周期的每一个阶段,它通过需求管理、项目管理、变更与缺陷管理、测试管理、配置管理等方面将软件开发过程的各个阶段管理起来,以达到最大限度的保证软件产品的质量与提高软件开发过程的生产率。同时Scrum敏捷开发强调边开发边测试,因此如何协调各个阶段的管理工作,使其相互配合以达到整个软件项目的成功交付是关键问题。

本文以解决上述问题作为研究的基础,旨在对Scrum敏捷开发管理平台的搭建以及开源工具与Jazz平台之间的集成进行新的尝试,并解决相应的技术问题。

1 目前敏捷开发过程管理基本情况

Scrum的一个关键原则就是承认客户可以在项目过程中改变主意,变更他们的需求,而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。因此,对于那些功能需求可能经常发生变化的项目来说,Scrum是最为理想的选择之一。对于一个Scrum敏捷团队而言,工欲善其事,必先利其器,选择合适的Scrum工具是保证成功实施Scrum的关键一环。目前支持Scrum开发过程管理的工具大致分三类,它们分别是:基础工具、开源工具和厂商工具。表1分别对这三类的特征及优缺点进行了对比描述。

当敏捷团队扩展为大型团队、开发方式变成大型项目的主流开发方式时,这些自己临时组织起来的技术,如仅靠白板、电子表格和WIKI等将难以满足需求。

厂商工具对Scrum开发过程管理支持是最完善的,同时也是价格最昂贵的,对于刚刚处于起步阶段的企业来说,显然是无法承受的。

开源软件不是由统一的组织进行开发的,所以不同的软件之间难以进行协同工作。目前开源软件应用主要还是集中在各个领域的独立部分。例如项目管理、需求管理、变更缺陷管理、配置管理以及测试管理等。由于开源软件没有得到商业化企业的支持,难以开发出大规模的集成平台去支持整个软件开发过程的管理。因此,该局限性使得开源软件的应用无法满足实际用户的综合需要。

2 支持敏捷开发过程管理平台的开源工具

为了能够解决目前开源软件应用集中在各领域的独立部分,并充分体现Scrum开发过程管理平台对开发团队的有效支撑,同时展现平台的可扩展性、可通用性,这里对相应的开源工具进行了如下的选型工作,后续将进行工具与Jazz平台的集成,以满足软件交付生命周期中各个阶段的管理。

2.1 项目管理工具

Xplanner是一个开源的基于Web的XP团队计划和跟踪工具,对于Scrum也同样适用。Scrum的开发概念如iteration、user stories等,Xplanner都提供了相对应的支持,Xplanner支持敏捷开发流程,能够解决通过Scrum方法开发项目所碰到的问题[2]。该开源工具主要具有以下特性:

1)简单的模型规划

对于定制开发类项目,可以用实际项目名称作为Xplanner的项目名称。在项目下建立首次迭代,制定迭代起止时间。由顾客及开发人员定义发布计划;由顾客定义用户故事;由开发人员估计开发故事的代价。

2)完备的内建立人员

项目负责人:要负责Xplanner中项目、迭代、用户故事、任务的设置、编辑、删除;要及时督促项目研发人员添加、更新Xplanner上各角色负责的内容;要做到每日下班前打开Xplanner监控项目进行情况,以确保项目按时按质交付。

编辑者:为本项目的研发人员、软件测试人员。接受自己的任务列表,并按时完成任务。

跟踪者:跟踪迭代执行情况;及时和项目组沟通;配合督促项目相关人员添加、更新Xplanner上各角色负责的内容,做到每日下班前打开Xplanner监控项目进行情况。

客户:可以是本公司市场部门相关人员,也可以是客户本身。主要跟踪迭代执行情况。

3)iterations、user stories、tasks与工作记录的追踪

项目层级下设有迭代(iteration),基本上一个项目应该要有许多features或requirements。透过迭代,你可以安排要将哪些features放在哪个迭代,而将另一些feature放在另一个迭代。

迭代层级里面放置用户故事(user stories)。用户故事用来代表一个用户可了解的需求,应该是一组独立且不可分割的功能。

用户故事层级里放置任务(tasks)。如果把用户故事看作是需求,那任务就是完成某需求所要进行的工作。任务由开发人员撰写,它同时也可用来精估工时。

任务开始进行后,就可以追踪其工时。Xplanner会在迭代、故事,以及任务层级的页面,以进度条的方式来展示进度。

2.2 缺陷管理工具

缺陷管理贯穿于软件开发生命周期之中,是整个周期中不可缺少的环节。Mantis是基于Web的开源缺陷跟踪系统,采用PHP语言编写,安装方便,使用简单[3]。其主要特点如下:

1)个人可定制Email通知功能,每个用户可根据自身的工作特点来订阅相关缺陷状态邮件;

2)支持多项目、多语言;

3)权限设置灵活,不同角色有不同权限,每个项目可设为公开或私有状态,每个缺陷同样也可设为公开或私有状态,每个缺陷可以在不同项目间移动;

4)主页可发布项目相关新闻,方便信息共享;

5)方便的缺陷关联功能,除重复缺陷外,每个缺陷都可以链接到其他相关缺陷;

6)有各种缺陷趋势图和柱状图,为项目状态分析提供依据,如果不能满足要求,可以把数据输出到Excel中进一步分析;

7)缺陷报告可打印,支持可定制的报表输出,可定制用户输入域;

8)可以对历史缺陷进行检索。

2.3 测试管理工具

Testlink用于进行测试过程中的管理,通过使用Testlink提供的功能,可以将测试过程从测试需求、测试设计、再到测试执行完整的管理起来,同时,它还提供了多种测试结果的统计和分析,使我们能够简单的开始测试工作和分析测试结果。Testlink是sourceforge的开放源代码项目之一[4]。作为基于Web的测试管理系统,Testlink的主要功能包括:

1)根据不同的项目管理不同的测试计划,测试用例,测试构建相互之间独立;

2)可以基于关键字搜索测试用例;

3)能够将现有测试用例简单修改后复用;

4)设定执行测试的状态(通过,失败,锁定,尚未执行),失败的测试用例可以和Mantis中的bug关联,每个测试用例执行的时候,可以填写相关说明;

5)测试结果分析。可以实现按照需求、测试计划、测试用例状态、版本,统计测试结果;

6)支持将测试结果导出成Html,Word或是Excel格式;

7)测试用例和测试需求能够关联。测试可以根据优先级指派给测试员,定义里程碑;

可直接发送测试报告邮件。

2.4 配置管理工具

SVN是近年来崛起的版本管理工具,是CVS的接班人。目前,绝大多数开源软件都使用SVN作为代码版本管理软件。该工具是基于Web的开源源代码管理软件,采用PHP语言编写,能够有效解决软件开发过程中版本混乱、变更多、追溯难等问题[5]。其主要特点如下:

1)服务器保存了所有版本的代码,每个开发人员从服务器checkout出代码,修改代码完成某项工作后checkin修改的代码,在服务器中会记录一个新的软件版本;

2)支持多平台下的操作;

3)管理方便,逻辑明确,符合一般人思维习惯;

4)易于管理,集中式服务器更能保证安全性;

5)代码一致性非常高;

6)适合开发人数不多的项目开发。

3 敏捷开发过程管理平台的设计与实现

由于软件企业在软件产品开发过程中,经常发现开发团队在进度、质量等方面的控制能力无法满足业务需求,经常遇到开发滞后计划,软件未能及时交付使用,突发需求影响整个开发计划等现象。因此,构建一个支持敏捷开发的过程管理平台显得尤为重要。敏捷开发过程管理平台是用来实现软件交付生命周期的管理,并结合敏捷开发思想,进行软件开发过程中的项目管理、测试管理、缺陷及变更管理、配置管理等工作。本文提出的敏捷开发过程管理平台是针对Scrum敏捷开发方法,通过开源软件与Jazz平台的集成搭建轻量级的过程管理平台。

3.1 基于Jazz平台的编程模型

Jazz平台是IBM Rational面向软件交付技术的下一代协作创新平台,该平台开源并通过社区驱动开发。Jazz平台是一个用于整个软件生命周期的团队协作平台,旨在支持软件生命周期各个阶段任务的无缝集成。Jazz平台的客户端和服务器端都具备扩展性,可以从小的团队扩展到大的企业环境。集成端到端的工具可以帮助团队更有效地构建软件,并使得软件开发活动更加令人愉快。

Jazz平台内核是必需的组件集,包括两个组件为:Repository和Team Process。Repository组件提供可扩展的存储库,其功能对所有客户端和服务器配置中的其他组件可用。Team Process组件提供了Jazz的流程支持基础,其功能也对所有客户端和服务器配置中的其他组件可用[6]。通过Web服务方式可以将开源工具集成到Jazz平台,由Jazz平台统一管理,协同工作。

基于Jazz平台的开发与基于众多主流的J2EE框架开发类似,都采用MVC的分层模型,该模型如图1所示。Jazz提供了各种不同形式的服务,例如Restful服务、RPC服务等。因此它为不同种类的客户端接入提供了相对统一的基于service接口,无论是基于Ajax的Web UI还是基于RCP的Eclipse UI都可以统一使用同一套后端提供的服务,无需做任何修改,它为不同类型的UI接入提供了内在的支持。

在典型的Web应用中,一个Jazz构件包含以下几个部分:

Model:用于数据模型和服务接口的定义,类似于MVC的Model层

Service:用于服务的实现,类似于MVC的Controller层

Clients:用于用户界面的实现,类似于MVC的View层

因此Jazz把一个典型的Web开发转化成了Eclipse插件的开发,应用程序通过对不同扩展点进行扩展实现相应的功能并具有很强的重用性和扩展性。一个Jazz构件可以依赖其它Jazz构件,并调用被依赖构件提供的服务。而应用程序只需要关注对不同服务的调用,服务的实例化和维护由Jazz平台进行提供,简化应用程序开发。

3.2 敏捷开发过程管理平台的架构

本平台架构设计分为两大部分,分别为Jazz Server基础服务和Jazz Server Extension扩展服务,平台架构模型如图2所示。在底层,Jazz基础服务和工具服务器扩展都会以一个或多个OSGi组件方式实现。

1)核心部分

平台架构的核心部分是Jazz Server,它支持该平台的基础服务和一定数量的工具服务器扩展。Jazz Server基础服务包括用户管理、协作、查询、存储、工具互通互联等公共能力。它提供了软件交付生命周期服务组件共同需要的一些基本服务。

2)扩展部分

平台架构的扩展部分是Jazz Server Extension,它提供了平台的服务器扩展,通过使用基础服务实现某个领域的特定服务,例如项目管理、缺陷管理、测试管理、配置管理等。从而使不同的工具组合成为一个逻辑的整体进行工作,实现软件交付生命周期的管理。企业也可根据已使用工具的情况以及开发流程的特点替换选用不同的工具,本文仅以上文中选好的开源工具作为扩展服务。

3.3 开源软件与Jazz平台的集成

传统的Web服务通过SOAP(简单对象访问协议)来进行消息的交换,它是一种用于单向通信的消息格式,将消息组合成XML文档,描述消息的传输,其主要是通过HTTP协议。HTTP协议有最基本的GET、PUT、POST、DELETE四个动作,它们被称作是HTTP的统一接口,但SOAP仅使用其中的POST方法,享受不到REST的优点,而且对HTTP的响应代码很少使用。SOAP对于所有的操作都是通过对单个的URI做POST操作完成的。所有的操作,不管是读取或者修改信息,均没有用到GET和PUT,而是将操作放在POST信息里面[7]。

为彻底解决传统Web服务存在的问题,本文采用REST技术实现Web服务。解决办法是,首先将每个开源软件根据其功能划分为多个不同的服务,再将扩展服务划分为资源,让URI体现更多的信息,用不同的URIs标识服务里的每个对象。没有必要通过POST方法进行所有的操作。对于不同类型的对象,用统一的接口实现。

在REST中可以显式地使用HTTP方法,对系统资源进行创建、读取、更新和删除操作:

●使用POST方法在服务器上创建资源

●使用GET方法从服务器检索某个资源或者资源集合

●使用PUT方法对服务器的现有资源进行更新

●使用DELETE方法删除服务器的某个资源

REST从资源的角度来观察整个网络,分布在各处的资源由URI确定,而客户端的应用通过URI来获取资源的表形[8]。通过REST服务接口,Jazz的客户端可以通过标准的HTTP协议访问服务器端组件的服务,从而实现了组件间的协作。

4 基于开源软件的敏捷开发过程管理平台的应用

Scrum是一种灵活的敏捷软件开发管理过程,对于那些功能需求可能经常发生变化的项目来说,Scrum是最为理想的选择之一。因此,以Scrum软件交付过程为例,展示该交付项目管理过程是如何在此平台上进行的。Scrum软件交付项目管理过程如图3所示。

1)项目启动

在一个采用Scrum的项目中,首先要将所有需要完成的工作列在一个Product Backlog中,项目开发过程中需求的改变也要写进去。通过Xplanner工作项管理功能,项目经理能够方便地完成项目需求定义和收集,为团队提供统一的需求列表或产品订单。

2)项目规划

利用Xplanner项目规划能力,项目经理能够快速完成项目级的整体项目计划或发布规划,以及迭代级的详细迭代计划。

3)项目执行

迭代计划中的每个任务都是一个工作项,项目经理可以基于预定义的工作流,将其分配给指定的团队成员,实现工作任务的自动流转。开发人员基于Xplanner各种工作项进行开发活动,生成的代码和文档可以直接通过内置的配置管理功能存入SVN,实现完整的配置变更管理;测试人员基于Testlink工具进行测试活动,生成的Bug可以直接导入到Mantis,实现完整的缺陷管理;版本构建人员基于SVN进行版本配置管理;质量保证人员基于Mantis进行缺陷及变更管理。通过开源软件在Jazz平台上的集成,敏捷开发过程能够在该平台上动态执行,Jazz平台类似中央协调员,进行人员的统一管理,指挥整个项目团队的密切协作,高效工作。

4)项目监控

通过Web访问,项目经理和团队中的每位成员都能够非常方便地了解整个开发团队的组织结构,了解团队中每个人的角色和职责分工,实时了解团队的工作进度和工作状况。

5)项目收尾

软件交付团队可以把团队经验和教训反映到项目管理的过程定义中,同时,通过将其导出成为新的模板,供其他项目团队使用,实现经验教训的固化和重用。项目经理可直接从实际工作中总结出来项目健康信息,自动捕获项目数据,自动生成所需项目报告。

5 结论

基于开源软件的敏捷开发过程管理平台的设计与实现,是对软件交付生命周期管理的有力支持。通过对不同功能的开源工具间的整合,实现了同一平台下针对Scrum敏捷开发流程的完整生命周期管理的解决方案,以覆盖整个软件的交付过程,包括:项目管理、需求分析、分析设计、开发、测试、配置管理、缺陷及变更管理等诸多环节。此外,基于开源软件的敏捷开发过程管理平台研究的不仅是一个过程管理工具,也提供了一种开源软件间集成的新思路,企业能够根据实际开发方法、已有工具的情况来进行新的裁剪或扩充。同时,也实现了开源软件的价值。本文对开源软件的集成以及综合应用进行了有益尝试,并且取得了一定的进展。

摘要：当前备受企业青睐的敏捷开发过程管理工具存在成本高、可替换性差等问题,为帮助中小企业解决以上问题,并且根据企业自身开发特点进行开发过程管理,提出了基于开源软件的敏捷开发过程管理平台的设计与应用。通过开源软件对敏捷开发过程中各阶段管理活动提供支持,并根据主流Scrum敏捷开发方法,建立了一个基于开源软件的可裁剪的敏捷开发过程管理平台。该平台基于Jazz架构实现敏捷开发过程管理的基本功能,采用REST技术,结合OSGi思想,实现开源软件工具与Jazz平台之间的集成。从而实现中小软件企业敏捷开发过程的统一管理,大大降低了企业的开发管理成本,并可根据企业的实际管理情况对此平台进行扩充和裁剪。

关键词：开发过程管理,Jazz平台,REST技术,开源软件,Scrum

参考文献

[1]贾子河,段永刚,蒋博等.轻松Scrum之旅——敏捷开发故事[M].北京:电子工业出版社,2009.37-43.JIA Z H,DUAN G,JIANG B,et al.Easy trip-agile Scrum development story[M].Beijing:electronic industry press,2009.37-43.(in Chinese)

[2]Xplanner.http://sourceforge.net/projects/Xplanner/

[3]Mantis.http://www.mantisbt.org/

[4]Testlink.http://Testlink.sourceforge.net/docs/Testlink.php

[5]SVN.http://subversion.apache.org/

[6]宁德军,朱育雄,孙昕.凑响软件交付的爵士乐——Jazz平台实践者之路[M].北京:清华大学出版社,2009.22-26.NING D J,ZHU Y X,SUN X.Make loud Jazz music——the Jazz platform practitioners of software delivery way[M].Beijing:tsinghua university press,2009.22-26.(in Chinese)

[7]许卓明,栗明,董逸生.基于RPC和基于REST的Web服务交互模型比较分析[J].计算机工程,2008.16-17.XU Z M,LI M,DONG Y S.Comparative analysis based on the RPC and rest-based Web services interaction model[J].Computer engineering,2008.16-17.(in Chinese)