颜乐鸣
(中国电子科技集团公司第七研究所,广州 510310)
0 引言
软件测试是保证软件质量保证的重要手段,J.Myers认为软件测试的目的是以最少人力、物力和时间投入,尽可能多地找出软件中潜在的各种错误和缺陷。统计资料表明,软件测试的工作量占软件开发总工作量的40%以上,软件测试的开销占总成本开销的30%~50%[1],而成功的软件测试离不开对测试的组织与过程的管理,一项软件测试工作,绝不是简单的测试活动,而应和软件开发一样,遵循软件工程原理[2]。近年来,人们对软件质量的要求越来越高,软件测试也越来越受到人们的重视,许多软件企业已成立独立的软件测试机构,但随着软件复杂度的日益增高和软件规模的不断增大,软件测试管理的难度和成本也随之加大,传统的软件过程模型和手工管理模式已无法适应现代软件开发模式的需要。
软件测试过程模型是用于指导软件测试实施的理论模型,模型的优劣直接影响软件测试的进度和质量,因此,软件测试过程模型是测试管理的重要参考依据,是保证测试质量和有效性的重要保证。工作流可解决在多个参与者之间利用计算机按某种预定规则实现自动传递文档、信息或任务,以达到任务目标,可实现部分业务过程在计算机支持下的全自动或半自动化。为了提高测试管理的效率,本文对典型的软件测试过程模型进行分析,在此基础上应用工作流技术,对测试管理的整个流程进行形式化和规范化的建模,从而有效地控制和管理参与到测试活动中各种测试要素,更好的达到测试管理的目的。
软件测试过程模型是在测试实践的基础上,有机结合相应的软件开发活动所总结和抽象出的一系列测试活动规律[1-5]。该模型是对测试过程的抽象,它和软件开发一样,用于定义软件测试的活动和流程,指导测试组织按照测试任务所要求的进度和质量实施测试活动。理想的软件测试过程模型应能对软件测试过程起到指导作用,在提高软件测试效率的同时降低测试成本。
1.2.1 V模型
图1 软件测试V模型Fig.1 Softw are testing V-model
V模型是最具有代表意义的测试模式,如图 1所示。V模型最早是Paul Rook于20世纪80年代提出,它是软件开发瀑布模型的扩展[4]。V模型从左到右描述了基本的开发过程和测试行为,反映了测试活动与分析设计的关系。其优点在于明确表明了软件测试的不同级别及其和开发过程各阶段的对应关系。但是,V模型把测试作为编码之后的阶段,产生软件是软件开发最后一项活动的误导,从而导致需求分析、软件设计等软件开发前期产生的软件问题随着过程的进展流转至最后的验收测试才被发现。该模型还认为软件测试等同于测试执行,并未明确划分软件测试各活动之间的关系。
1.2.2 W模型
W模型由Evolutif公司提出,是V模型的发展,其强调的是软件测试伴随着整个软件开发周期,并穿于整个软件周期,而且测试对象不仅仅是程序,需求、设计及相关的文档同样要测试[5]。相对于 V模型,图2所示的W模型更具可操作性,体现了测试与开发的同步性,从而有利于尽早发现软件问题。
但是,W模型也有一定的局限性,和V模型一样,它把软件开发和软件测试视为一种线性的前后关系,在如今需求不明确、变更频繁、开发周期短等软件开发特点下,W模型已无法支持迭代并快速响应变化。
1.3.3 H模型
为了解决 V模型和W模型的局限性,学者提出了H模型,如图3所示。它将测试活动完全独立出来,形成一个完全独立的流程,将测试准备活动和测试执行活动清晰的体现出来[6]。在H模型中,软件测试过程活动贯穿于整个产品的周期,与其他流程并发的进行,某个测试点准备就绪时,即只要测试条件成熟,测试准备活动完成,就可以从测试准备阶段进行到测试执行阶段。
与V模型和W模型相比,H模型的特点在于:
(1)软件测试不再是指测试的执行,还包括诸如软件测试需求分析、测试策划、测试设计、数据准备、环境搭建等其他活动;
(2)软件测试是一个独立的过程,它贯穿于整个软件生命周期,与其他开发阶段保持并行的关系,应尽早开始和准备;
(3)根据被测软件的特点,软件测试是分级分层开展的。不同级别的测试活动可以是顺序进行,也可迭代开展。
图2 软件测试W模型Fig.2 Softw are testing W-model
图3 软件测试H模型Fig.3 Softw are testing H-model
工作流技术是进入20世纪90年代以后计算机应用领域的一个新的研究热点,它为工作流程自动化和构建流程应用提供基础平台,实现了流程逻辑与业务逻辑的分离,支持业务流程的分析和规范化定义以及业务单元的自动组装,降低了复杂流程应用的开发难度,提高了应用系统的管理效率。
工作流管理联盟(WfMC:Workflow Management Coalition)为工作流提供了一个标准定义:工作流是指整个或部分业务过程在计算机支持下的全自动或半自动化[7]。
由工作流的定义可以看出,工作流的主体是过程,它使多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行,从而实现某个预期的业务目标或促使此目标实现。简而言之,工作流技术是在适当的时间将适当的信息传递给适当的人用并适当的工具进行处理。
工作流技术解决了人、组织、系统间的协作问题,通过工作流管理系统完成对工作流实例的执行。WfMC对工作流管理系统的定义为:工作流管理系统是一个完全定义、管理和执行工作流的系统,它通过计算机表示的工作流逻辑来驱动软件有序的进行[7]。
工作流管理系统是一个软件系统,它能够完成业务流程的定义和管理,按照预先定义的执行步骤和业务规则调度流程示例,在业务活动或任务之间合理的分配资源,通过管理工作活动序列,调用与各种活动步骤相关的人员、资源,对业务过程提供自动化处理[8~9],它最大优点是将应用逻辑与过程逻辑分离,在不修改具体功能的情况下,通过修改过程模型改变系统功能,完成对生产经营部分过程或全过程的集成管理,可有效地把人、信息和应用工具合理地组织在一起,发挥系统的最大效能。
图4所示为工作流参考模型,该模型中,工作流执行服务是整个工作流管理系统的核心,它为过程实例和活动提供运行环境,负责解释和激活过程定义,并与过程所需的外部资源进行交互。工作流执行服务周围的五个接口用以支持工作流管理的功能,通过交叉使用这五个接口,可以访问工作流系统的服务,还控制工作流控制软件与其他系统组件间的交互[10]。
工作流执行服务由一个或多个创建、管理和执行工作流实例化的工作流引擎(Workflow Engine)组成,通过工作流应用程序接口来访问这些服务。工作流引擎为工作流实例提供运行时期的执行环境,可以将其看作是一个状态变迁机器,过程或活动的实例在响应外部事件或工作流引擎的控制来改变状态。
图4 工作流参考模型Fig.4 W orkflow reference model
软件测试管理是指管理者按照与被测软件相适应的测试过程和测试方法,通过管理参与到测试活动中的对象来达到管理的目的,这些对象包括人员、测试工作产品、设施和环境条件等。在三种典型的软件测试过程模型中,H模型充分体现了尽早测试、全程测试、独立测试等原则,它提高了测试效率,并具有一定的灵活性,但是并没有提出具体的应用模型。本文基于软件测试过程H模型,结合工作流技术,建立基于工作流的软件测试过程模型,如图5所示。
基于图5所示的软件测试过程模型,在基于工作流的软件测试过程模型中,“任务分配”相当于工作流引擎,所有的测试任务通过工作流引擎进行分配。根据工作分解结构(WBS,Work Break Structure)的思想,测试任务被分解为不同的子任务,从而形成具有多层次的树状结构,既包含如需求分析、用例设计等技术层面的任务,也包含项目监控、配置管理等管理层面的任务,通过人员配置和进度控制完成工作流引擎的功能。基本的测试过程如下:
(1)测试申请:由软件开发人员或开发团队提出测试申请,同时提供测试依据;
(2)测试策划:由测试负责人组织进行测试策划(含测试需求分析)和测试设计,通过工作流引擎进行任务分配;
(3)测试设计:由测试负责人组织进行分解测试需求,开展测试设计并编写测试用例;
(4)测试执行:测试人员执行测试用例,若无缺陷,则进行测试总结,相关测试用例关闭;若发现缺陷,则由测试人员填写缺陷报告单;
(5)确认缺陷:缺陷报告经测试负责人和软件负责人确认后,重新回到工作流引擎,缺陷处理将作为一个新任务由工作流引擎再次进行分配;
(6)缺陷修复:由开发人员进行缺陷定位及分析,并修复缺陷;
(7)回归测试:经修复的缺陷进入回归测试流程,成为新任务被工作流引擎分配,重复步骤2),直至所有缺陷被正确有效的处理。
(8)资产库:在进行测试策划时,根据测试需求分析的结果,测试人员可使用资产库中的测试用例资产,进行测试用例的复用。
不管是何种级别的软件测试,在测试开始之前,都需要进行测试策划,以确定用于测试的资源要求,包括软硬件设备、环境条件、人员数量和技能要求等,并根据测试资源和测试项,确定进度,在此基础上进行人员安排和任务分派。伴随着测试的进展,不断演化的测试用例是测试人员设计和执行的主要工作,在工作流引擎中,测试策划、测试设计和测试执行是一个迭代的过程,通过测试负责人进行任务分配,在不影响测试任务目标的同时,实现快速响应变化,随时调整测试策略。
图5 基于工作流的软件测试过程模型Fig.5 Software testing management model based on workflow
在测试执行时,测试人员通过工作流引擎对测试过程产生的软件缺陷进行跟踪,使缺陷得到了有效的管理,缺陷状态的流转如图6所示,缺陷状态如下:
(1)新建:经确认的缺陷,等待开发人员处理;
(2)处理中:缺陷正在被开发人员修复处理;
(3)已处理:缺陷已被修复处理,等待向测试人员发布软件的新版本;
(4)发布:缺陷已修复处理,且软件新版本已向测试人员发布,等待回归测试;
(5)已修复:缺陷已被责任人修复处理,且通过回归测试;
(6)尚未修复:缺陷已被责任人修复处理,但未通过回归测试,等待重新处理。
(7)延期解决:开发人员判定不在当前版本进行修复的缺陷;
(8)无需解决:开发人员判定无需解决的缺陷;
(9)关闭:无需解决、或已修复并通过回归测试的缺陷。
图6 缺陷状态流转图Fig.6 Defect state flow diagram
基于工作流的软件测试过程模型以任务分配为核心,测试用例作为过程资产被存储在资产库中,可被反复分配到不同测试阶段或不同的任务中,从而实现测试用例的复用,进而节约了测试时间,降低了软件测试的成本,大大提高了软件测试的效率。
标准测试项目通常包括项目建立、测试需求分析、测试策划、测试设计、测试执行和测试总结六个阶段的工作内容,理想的测试过程应按测试的进展顺序开展各阶段的工作,但在工程实践中,软件测试的周期短,任务紧,测试依据文档不齐套或文实不一致等问题,导致测试质量降低,测试成功升高。基于工作流的软件测试过程模型建立测试管理系统,可提升如下测试管理工作的效率:
(1)测试项目建立:创建项目名称及标识、状态测试资源信息,确定与被测对象有关的信息,如被测软件规模、类型、编程语言、开发方等信息,便于测试负责人对测试项目的跟踪及测试质量评估;
(2)测试需求分析:确定测试需求及其标识、需求优先级、需求追踪关系等,执行测试需求评审流程;
(3)测试策划:确定测试策略、测试组成员、资源、进度、风险分析等,同时进行任务的人员配置,执行测试计划的评审流程;
(4)测试设计:设计测试用例并确定其标识,确定用例执行顺序,执行测试说明评审流程;
(5)测试执行:记录测试执行数据、缺陷数据,执行缺陷处理流程;
(6)测试总结:整理和分析测试数据,执行测试报告评审流程。
该模型同样适用于更改验证类型的项目,即当某一被测软件对于之前已结束测试的版本更改不大时进行的软件测试。可通过基于工作流的软件测试过程模型建立测试管理系统,在其资产库提取被测软件的项目数据和信息,同时可进行变更比对,为测试人员提供验证的测试用例。
在基于工作流的软件测试过程模型中,很好的解决了人、组织、系统间的协同关系,使得任务分配、测试人员配置、进度控制可协调的工作,从而更好的发挥人员的能动性,使测试工作更有效,测试工作质量更高。
本文对典型的软件测试过程模型进行分析,结合工作流技术,给出了一种基于工作流的软件测试过程模型,该模型以任务分配为核心,使测试过程更符合工程实践,在保证测试质量的同时缩短了测试周期,为深入探讨和改进软件测试过程的管理提供了基础研究。结合工作流技术,测试组织在使用工具进行测试管理时,可获得整个测试周期内任务执行的过程数据,从这些任务数据出发,不断分析当前过程执行的有效性和效率。对工作流数据进行挖掘,将分析结果用于指导模型的调整和改进,使模型更具可操作性和指导性,实现测试过程持续改进,是本文下一步研究重点。
[1] 夏世峰. 工作流软件测试技术的研究与实践[D]. 北京: 北京邮电大学, 2006.
[2] 蔡建平, 王安生, 修佳鹏. 软件测试方法与技术[M]. 北京:清华大学出版社, 2014.
[3] 余久久, 张佑生. 软件测试过程模型研究综述[J]. 人类工效学, 2012, 18(1): 91-95.
[4] 张俊萍, 朱小冬, 王毅刚, 等. 对软件测试过程模型的思考[J]. 微计算机信息, 2006, 27(3): 22-24.
[5] 胡玮. 软件测试过程模型的改进与应用[D]. 杭州: 浙江大学, 2006.
[6] 吴慧韫, 李卓群. 基于H模型的软件测试管理应用模型研究[J]. 计算机工程与设计, 2006. 27(11): 1993-1995.
[7] David Hollingsworth, TC00-1003-1995. The workflow reference model[S]. UK: Workflow Management Coalition,1995.
[8] 李妍, 方少波, 么强. 一种基于工作流的软件可靠性评估方法[J]. 计算机技术与发展, 2014. 24(3): 34-38.
[9] 陈亮, 高建民, 陈富民等. 基于工作流挖掘的质量管理过程改进研究[J]. 计算机集成制造系统, 2006, 12(4): 603-608.
[10] Wil van der Aalst, Kees van Hee. 工作流管理: 模型、方法和系统[M]. 王建民等译. 北京: 清华大学出版社, 2004.