杜以团,赵 林,杨小娟
(中国电子科技集团公司第三十研究所,四川 成都 610041)
随着软件质量越来越为大家所重视,软件测试逐步发展为一个独立于软件开发的一系列活动,就每一个软件测试的细节而言,都有一个独立的操作流程. 软件测试模型是指软件测试活动全部的过程、活动和任务的结构框架. 软件测试模型是对软件测试活动的抽象,它来源于软件测试实践,同时用于指导软件测试活动的开展和过程控制管理,同软件开发模型一样,都遵循软件工程和管理学原理[1]. 软件测试模型对指导测试工作开展具有十分重要的意义,软件测试根据不同的测试对象、测试背景、被测对象质量要求、项目进度要求等,可以采用不同的测试模型实施测试活动,指导软件测试活动安排.
传统军工科研院所项目大多采用瀑布式的开发模型,开发测试基本按照V模型和W模型开展. 在军工科研院所转制、军民融合发展的背景下,军品项目竞标常态化、军转民项目逐步落地,传统的开发测试模型无法满足部分项目开发测试周期和市场竞争要求. 近年来,敏捷开发已成为主流的开发方式,军工科研院所一方面多数项目采用重量级的软件工程化的开发方式; 一方面部分项目为了适应市场形式的变化和满足快速的产品交付要求,积极开展轻量级的敏捷开发实践. 同时,传统的测试模型无法有效指导敏捷测试项目或项目局部敏捷测试工作的开展,而且敏捷开发方式目前也没有建立一个行之有效的测试模型,这就使得测试人员在开展测试工作时面临诸多困惑.
自20世纪80年代后期由Paul Rook提出最具代表性的软件测试模型之一V模型[2]后,国外软件测试模型研究先后经历了W模型、X模型、H模型、前置测试模型等发展演变[3],这几种测试模型也发展成为世界上主流测试模型. 国内软件工程化和测试技术基本引进学习国外主流技术、经验,对软件开发测试基础技术研究不够且起步较晚,对软件测试模型的研究大多是基于主流测试模型如V模型、X模型的项目应用实践和主流模型的适应性改进. 2000年以来,国内研究学者也提出了一些测试模型,但由于缺乏鲜明的特色、不具备普适性和国内基础技术研究环境等各方面因素,没有形成具备一定行业知名度和影响力的测试模型.
随着近几年敏捷开发模式已成为主流开发模式,国内除遵循军工质量管理体系标准的企业主要采用V模型、W模型外,其他多数企业转向敏捷开发模式. 在敏捷开发模式中,开发和测试高度融合,不存在传统测试模型中单元测试、集成测试、系统测试等明确的测试阶段划分,强调测试驱动开发,对测试人员和整个项目团队都提出了更高的要求. 然而,基于敏捷开发模式的测试尚未形成一个主流的测试模型.
目前,主流传统测试模型有V模型、W模型、X模型、H模型、前置测试模型,下面对这5种测试模型原理、优势和局限性进行对比介绍,如表 1 所示.
表 1 软件测试模型对比Tab.1 Comparison of software test models
V模型清楚地表明了软件开发中的各个测试阶段,但没有明确应对软件的需求、设计进行测试. W模型对此进行了补充,并明确提前开展测试计划、测试设计,但同样是重过程、重文档的开发模式,每一个阶段工作都对上一个阶段工作有严格的要求. V模型和W模型清晰地体现了开发和测试的线性关系,对严格遵守军工质量管理体系标准(如GJB5000A、GJB/Z 141等)要求的项目具有很强的指导性. H模型主要体现软件测试的独立性,对具体测试过程活动指导意义不大. X模型体现了编码和单元测试、集成测试的频繁交互关系,并定义了探索性测试. 前置测试模型将测试和开发紧密结合,将技术测试和验收测试独立开来,验收测试不再是完成技术测试之后的过程活动.
传统软件测试模型各有其价值和优势,总体来说,体现了软件测试的一些基本原则: 软件测试要尽早进行; 软件测试不仅是对代码的测试,还包括需求、设计等技术文档; 软件测试要进行测试计划和测试设计,测试设计要有较强的复用性.
敏捷测试一般将其理解为遵循敏捷核心思想和敏捷宣言的测试实践活动[8],敏捷宣言强调敏捷开发的4个核心价值观: 个体与交互高于流程和工具; 可用的软件高于详尽的文档; 客户协作高于合同谈判; 响应变化高于遵循计划.
传统软件测试模型不适合快速迭代的敏捷开发模式,不能适应频繁的需求变更[9]. 当项目需求频繁变更、项目周期紧迫的情况下,传统测试模型无法有效应对项目交付周期风险; 采用迭代的开发测试模式,能够降低增量开支,降低产品无法按既定进度进入市场的风险,更容易适应需求的变化. 前置测试模型是开发和测试的紧密结合,敏捷测试则是开发和测试的融合.
在敏捷测试中,测试人员不再依赖设计文档,不存在明显的测试阶段划分,测试用例作用减弱,测试人员与开发人员保持紧密沟通,更多采用思维导图、探索性测试,强调自由度,测试设计和测试执行同时进行,边设计边测试,根据测试结果不断调整测试计划.
传统的测试模型有明确的测试阶段划分、测试准入条件和测试回归、测试判定准则,而在敏捷测试中这些都不再有明确的标准,频繁的软件状态变化和版本交付发布已成为常态,因此,习惯于传统测试模式的测试人员在参与敏捷项目时会面临诸多困惑: 应该在什么时机介入开展测试?在测试执行过程中开发已经迭代一个版本甚至多个版本怎么办?当前版本未测试完成对已修复的缺陷要不要先进行回归测试?在敏捷测试中如何判定版本是否达到交付要求?
为了解决在敏捷开发项目中测试人员存在的困惑,能够顺利的开展软件测试活动,本文结合敏捷开发理念和项目实践经验,设计了一种适用于敏捷开发模式的软件测试模型——阶梯模型,如图 1 所示.
在阶梯测试模型中,不再像传统测试模型有单元测试、集成测试、系统测试等明确的阶段区分; 吸收H模型中的指导思想,一旦测试就绪,具备测试条件就立即开展测试; 尽早开展测试,同开发需求分析和设计同步开展测试需求分析和测试设计,并根据需求变化随时调整测试需求和测试设计; 对版本进行小规模快速增量迭代,直到达到版本发布要求,然后进入下一个发布版本的增量迭代过程; 吸收前置测试模型中技术测试和验收测试相对独立的思想,达到发布要求的版本提交用户进行验收测试,同时进入下一个版本的技术测试.
阶梯模型的核心思想体现在版本的增量迭代过程,在某个版本测试过程中,可以随时响应下一个版本的迭代,体现了拥抱变化的敏捷开发理念,使得软件需求和技术状态的变化不再是测试执行过程让人“惧怕”的因素. 因小版本的快速增量迭代过程像阶梯般的推进,故该模型命名为“阶梯模型”.
图 1 阶梯模型Fig.1 Ladder model
下面对阶梯模型具体工作内容要求和流程准则等进行详细阐述.
在项目需求阶段,由产品经理、项目经理等角色同用户沟通,清晰地了解用户需求,并和客户协商确定版本发布迭代规模及用户需求优先级. 团队内部对用户需求开展讨论,在技术决策范畴内,开发人员和测试人员协商决定发布周期内的小版本迭代规模.
在参与项目需求讨论的同时,测试人员分析并确定测试需求,根据测试需求开展测试方案、用例等设计,并确定测试用例执行优先级. 团队内部保持紧密沟通,一旦需求发生变化和调整,就及时同步调整测试需求和测试设计,包括在原来基础上进行的更改调整和增量调整.
在测试执行阶段,按已开展的测试设计和测试用例优先级执行测试,在测试执行过程中将输出的bug实时提交到团队缺陷管理系统; 在当前测试版本已执行部分测试但尚未完成全部测试的情况下,开发人员提交下一个迭代版本,测试人员更换新版本进行测试; 对开发人员提交的迭代版本,首先进行已修复bug的回归测试,然后按原测试用例顺序继续执行测试,按照最可能出现问题的部分最先测试的原则[10],优先测试未执行过的测试用例和新增开发代码功能. 经过多次小规模迭代,直至达到图1中版本n经过一轮完整测试且无bug输出,或输出的bug经团队评估不影响版本发布,版本n完成技术测试发布并提交用户进行验收测试.
对开发人员提交迭代的版本,需要同开发人员协商确定准入准则,如开发人员已经完成了一定规模的增量开发,达到了前期商定的迭代规模,或者已经修复了某些致命、高优先级的bug. 测试人员和开发人员根据迭代测试情况对迭代规模进行动态调整,使版本测试周期与迭代周期能够相对保持同步.
阶梯模型是在敏捷理念基础上结合项目实践经验提出的. 在某型通信控制设备竞标样机项目中,要进行大规模的嵌入式软件开发测试,存在项目周期短且可能面临招标方随时通知交标的情况. 在该项目中,项目团队采用小规模迭代的开发测试方式,基本上3天左右迭代一个版本,测试人员按阶梯模型中阐述的测试方式开展快速迭代测试,经过反复迭代,每个已开发功能都进行了多轮测试,保证了软件的稳定性、可靠性,并且在全部需求开发完成后很短的周期内即完成了版本测试发布. 在该项目多个投标单位样机竞标比测中,取得了满分第一的成绩. 可以想象,如果按照开发、测试串行的方式在完成所有需求开发后再进行全面测试,版本发布周期会大大加长,并且没有足够的时间保证软件质量. 在一些短周期交付项目中,由于采用传统开发测试模型,导致没有足够的时间进行充分测试,为了保证交付进度,往往牺牲在测试上的时间投入,软件必然无法保证高质量的交付.
本文在敏捷理念基础上,吸收传统测试模型的一些优点,并结合项目实践经验提出了一种基于敏捷开发模式的软件测试模型——阶梯模型,该模型充分体现了软件的具体迭代过程,对测试人员执行测试具有很强的指导性. 项目实际应用结果表明,阶梯模式在敏捷项目开发中能够有效缩短开发测试周期,提高软件开发质量.