APP下载

基于TMMi三级的软件测试需求管理过程研究

2022-09-08沈云凌

电子元器件与信息技术 2022年6期
关键词:委托方软件测试共性

沈云凌

中国电子科技集团公司第七研究所,广东 广州,510310

0 引言

当前是“软件定义一切”[1]的智能时代,随着信息更新速度加快,软件更新交付周期缩短,用户需求变化层出不穷,对软件质量效能的要求也越来越高。软件测试是软件全生命周期中保障软件质量的关键实践[2],因此,作为以确保用户需求和期望得到满足为目标,决定软件测试结果有效性的关键组成,软件测试需求管理效能的提升已成为关注热点。随着对软件测试需求管理活动重视程度的提高,近几年陆续发布的软件和测试相关的能力成熟度标准均关注并细化了软件和测试需求管理活动的要求。测试需求管理活动主要在能力等级二级和三级中涵盖,能力等级三级的软件测试需求管理活动能发挥其更大的效能。同时,由于各类标准对软件测评实验室开展测试需求管理活动的实施和改进指导仍存在不足之处,因此,有必要研究一种基于TMMi三级的软件测试需求管理过程,为软件测评实验室开展测试需求管理活动提供具体的实施和改进指导,以提高软件测评质量与测试结果的有效性,从而促进软件测试效能的提高。

1 标准介绍与分析

能力成熟度模型集成(CMMI)V2.0于2018年3月发布,包括初始、已管理、已定义、已测量和优化五个成熟度等级[3]。CMMI2.0不但是过程改进模型,更是一个业务能力改进的模型[4]。CMMI2.0—DEV视图将“需求开发”、“需求管理”合并为“需求开发和管理”[3],同时将“验证”和“确认”合并为“验证和确认”[3],提高了对需求管理和测试活动的重视程度。CMMI2.0的需求管理活动主要涵盖在二级规范级和三级全面级两个等级共13个子实践域中。

GJB5000B于 2021年12月发布,是依据CMMI 2.0并结合软件工程实践经验编制的软件能力成熟度模型。GJB5000B适用于软件论证、研制、实验和维护能力的评价和过程改进,包括初始级、规范级、全面级、量化级、卓越级五个成熟度等级[5]。GJB5000B的需求管理活动涵盖在二级规范级和三级全面级两个等级共11个子实践域中,且每个子实践均给出了活动实例和工作产品实例,其精细化的管理和改进思想对软件需求管理活动的实施和改进指导更有意义。

相比CMMI和GJB5000B专注于组织级别、软件和系统工程的过程,测试成熟度模型集成(TMMi)则重点关注测试领域。TMMi是应测试行业过程改进需要而出现的测试能力成熟度的评估标准和实现方式集合。TMMi的组织架构与CMMI兼容,作为CMMI的补充模型与CMMI 配合使用,可有效解决CMMI对于测试关注度不够的问题[6]。TMMi的能力等级结构与CMMI一样有五个成熟度等级[6]。软件测试需求管理活动内容主要在TMMi的二级已管理和三级已定义两个等级的5个工程实践域中涵盖。但TMMi并未采用独立的实践域对测试需求管理活动进行说明,且只包括部分的需求管理活动实践和改进指导内容,因此,对软件测评实验室开展软件测试需求管理活动的实施和改进指导略有不足。TMMi是CMMI模型的补充模型,GJB5000B是CMMI针对软件过程的本地化改进模型,因此,TMMi也可以与GJB5000B配合使用。

表1[3-6]从需求管理活动主要涉及的内容、强项与不足等方面对TMMi、CMMI2.0和GJB5000B三项标准进行了对比和分析。经分析对比可知,上述三项标准对软件测评实验室开展软件测试需求管理活动的实践和改进指导均存在不足之处。且上述标准均采用了继承原则,即达到能力等级三级的软件测试需求管理要求时,其二级要求便已覆盖。能力等级三级的软件测试需求管理活动发挥的效能更大。因此,基于TMMi三级的软件测试需求管理实践,借鉴CMMI2.0和GJB5000B的需求管理思想强项,并结合工程实践经验,提出的软件测试需求管理过程,对软件测评实验室开展测试需求管理过程改进及业务能力改进,提高实验室的测试效能具有重要意义。

表1 标准的需求管理内容对比分析

2 基于TMMi三级的软件测试需求管理过程

本文提出的基于TMMi三级的软件测试需求管理过程包括获取和分析测试需求、获得对测试需求的理解和承诺、建立并维护测试需求双向追溯性、管理需求变更、建立并维护测试需求分析准则、分析和重用共性测试需求这六项活动。其中,前四项活动对应能力等级二级的要求,后两项活动对应能力等级三级的要求。该过程的主要活动如图1所示。

图1 软件测试需求管理的主要活动

按测试需求分析准则的要求获取和分析软件测试需求后,建立需求的双向跟踪矩阵,并通过评审及各种沟通方式与利益相关方对测试需求达成一致的理解和承诺。当委托方提供的需求发生变更或需求不一致须纠正时,触发测试需求变更流程,开展需求变更影响分析,变更测试需求并同步更新测试需求的双向跟踪矩阵,且与利益相关方达成一致的理解和承诺。在分析测试需求时,应根据已建立的重用准则进行重用分析,确认是否存在共性测试需求可使用重用库的可重用测试需求资产,或是否存在共性测试需求可按准则的要求提取为可重用测试需求资产并积累到重用库。持续改进测试需求分析准则和重用准则。

软件测试需求的利益相关方关系如图2所示。本文所指的利益相关方包括委托方和软件测评实验室的相关人员,委托方包括软件研制方、软件使用方、研制任务总体方、研制任务下达方和质量管理方。委托方提供软件需求及相关测试要求,所有利益相关方均参与软件测试需求的确认和变更评审活动。

图2 软件测试需求与利益相关方的关系

下面将从目标、角色及职责、时机/频度、入口准则、输入、活动要求、输出和出口准则这八个方面,详细阐述基于TMMi三级的软件测试需求管理过程的各项主要活动。

2.1 获取和分析测试需求

(1)目标。获取和分析测试需求的目标是依据测试合同、技术文档、利益相关方的需求、期望、测试要求等信息,分析、提取软件测试需求并将其转化为测试项,同时确定测试方法和充分性等测试内容。

(2)责任角色及职责。委托方提供测试需求,实验室获取和分析测试需求。

(3)时机/频度。测试需求分析、需求变更时。

(4)入口准则。测试项目已接收并启动。

(5)输入。测试合同、技术文档、利益相关方的需求、期望、测试要求等。

(6)活动要求。分析提取软件需求并挖掘隐含需求。根据测试合同、技术文档等信息,结合测试级别,分析软件的功能、性能、接口、质量特性、设计约束和数据等需求。若测试依据文档不够完善,则可借助启发式分析方法,从系统业务目标、结构、功能、数据、运行平台、操作等多方面综合分析[7],同时通过对利益相关方的访谈及观察、接口分析、用户界面分析、文档分析等方式[8],挖掘未明示的隐含需求。引出测试标准、规范等测试要求,并根据测试级别、测试标准及相关要求和软件需求内容,确定测试类型。结合测试类型,将已分析并获取的软件需求及隐含需求转化为测试项。测试项可由一种或多种测试类型覆盖,同一个测试对象应对应多个测试项,一个测试项可划分为多个测试子项。测试项中应包括唯一的名称和标识、优先级、测试方法(测试数据生成及注入方法、使用的测试工具等)、适用的测试场景与环境等内容[9]。确定测试的正常和异常终止的条件及情况。根据委托方的测试要求、软件的重要性和约束条件进行分析的测试充分性,确定测试范围及覆盖程度,并说明不覆盖的原因。最后,形成文档化的软件测试需求文档。将委托方提供并通过评审的测试输入项入库并建立测试需求基线。

(7)输出。软件测试计划/大纲、沟通记录、测试输入项评审记录、测试需求基线等。

(8)出口准则。测试需求的获取和分析活动符合充分性、正确性、完整性和协调性的原则,测试需求基线已纳入配置管理,产生的所有记录均已纳入数据管理。

2.2 获得对测试需求的理解和承诺

(1)目标。获得对测试需求的理解和承诺的目标是与委托方就测试需求达成共识,与利益相关方一起对测试需求(含变更)做出承诺。

(2)责任角色及职责。实验室组织软件测试计划/大纲的评审,委托方及其他利益相关方参与评审。

(3)时机/频度。测试需求分析、需求变更时。

(4)入口准则。软件测评项目已接收并启动。

(5)输入。软件测试计划/大纲、测试需求跟踪矩阵。

(6)活动要求。确定合适的委托方准则,明确产生需求的合适渠道或来源。制定评价和验收需求的准则可包括正确性、二义性、完整性、一致性、可实现性、可测试性、可追溯性、唯一标识等内容。与委托方充分沟通并达成共识的方式包括调研、访谈、评审、邮件等。实验室需对与利益相关方对达成一致的测试需求及更改做出承诺。

(7)输出。委托方、需求评价和验收的准则、针对需求(含变更)的审批确认记录、评审记录等。

(8)出口准则。所有评审问题均已关闭或得到妥善处理,软件测试计划/大纲已纳入配置管理,产生的所有记录均已纳入数据管理。

2.3 建立并维护测试需求双向追溯性

(1)目标。建立并维护测试需求双向追溯性的目标是建立并维护软件测试需求的双向可追溯性,保证测试项、用例、记录与软件需求一致。

(2)责任角色及职责。实验室建立和维护测试需求双向追踪关系。

(3)时机/频度。软件测试技术文档(软件测试计划/大纲、软件测试说明(含用例)、软件测试记录)建立/更改时。

(4)入口准则。软件测试输入项(测试依据、测试要求文件等)已通过评审并建立需求基线。

(5)输入。软件测试输入项、软件测试技术文档。

(6)活动要求。在测试的全生命周期内,建立并维护从委托方的软件需求到测试项、到测试用例、到测试记录及软件问题的双向跟踪关系。测试需求跟踪的内容需全面,包括功能、性能、接口、质量特性等所有委托方提供的软件需求及隐含需求。在测试生命周期内,监控并维护软件测试计划/大纲、软件测试说明(含用例)、软件测试记录(含问题)等软件测试技术文档与软件需求的一致性,当发生需求变更时,应做好充分的影响分析并同时变更受影响的测试需求及相关软件测试技术文档。在测试需求跟踪时,识别并标识不一致问题及其来源,必要时启动纠正措施。不一致主要包括未正确验证、有多余项、有缺漏项等。

(7)输出。测试需求跟踪矩阵、不一致的记录、评审记录等。

(8)出口准则。所有评审问题和不一致问题均已关闭或得到妥善处理,软件技术文档已纳入配置管理,产生的所有记录均已纳入数据管理。

2.4 管理需求变更

(1)目标。管理需求变更的目标是在测试全生命周期内,对测试需求变更进行管理。

(2)责任角色及职责。实验室组织软件测试需求变更影响分析和评审,审批、实施和验证测试需求变更。委托方及其他利益相关方评审变更。

(3)时机/频度。测试需求变更时。

(4)入口准则。软件测评需求基线已建立。

(5)输入。委托方提供的需求变更或测试需求不一致问题。

(6)活动要求。测试需求变更影响分析,评估测试需求变更的必要性、可行性及对测试技术文档和进度的影响。需求变更的来源包括委托方的需求产生变更、测试需求跟踪时发现不一致问题纠正。变更级别包括重要变更、一般变更和勘误性变更三类。重要变更是指涉及重要技术指标、影响互联互通或软件关键需求的变更;一般变更是指软件非关键需求内容的变更;勘误性变更是指文字描述或其他勘误性错误的需求变更。变更过程包括申请、影响分析、审批、实施和验证。所有涉及的利益相关方参与变更评审。变更后,更新并发布需求变更涉及的测试工作产品,若涉及需求基线,则应一并更新发布。测试需求变更记录纳入数据管理。

(7)输出。更改后的软件技术文档/需求基线、变更申请、审批和验证记录、配置管理记录、变更评审记录等。

(8)出口准则。所有评审问题均已关闭或得到妥善处理,变更涉及的工作产品已纳入配置管理,产生的所有记录均已纳入数据管理。

2.5 建立并维护测试需求分析准则

(1)目标。建立并维护测试需求分析准则的目标是实验室根据业务类型、测试标准建立测试需求分析准则,并依据准则进行测试需求分析。

(2)责任角色及职责。实验室建立和维护测试需求分析准则。

(3)时机/频度。测试需求分析准则建立、修订时。

(4)入口准则。测试需求分析准则建立和修订工作启动。

(5)输入。实验室的业务类型、测试标准。

(6)活动要求。建立并维护用于指导和检查测试需求分析的测试需求分析准则,如软件测试需求分析指南、规范等。按测试类型、测试标准建立并维护专项需求分析准则,如功能类测试需求分析准则、性能类测试需求分析准则、接口类测试需求分析准则、专项类测试需求分析准则、民用软件测试方法需求分析准则等。所有分析准则均需通过评审并持续改进。

(7)输出。测试需求分析准则、评审记录、改进记录等。

(8)出口准则。所有评审问题均已关闭或得到妥善处理,测试需求分析已纳入体系管理,产生的所有记录均已纳入数据管理。

2.6 分析和重用共性测试需求

(1)目标。分析和重用共性测试需求的目标是实验室建立共性测试需求和重用准则,并依据准则建立共性测试需求,项目依据准则重用共性测试需求。

(2)责任角色及职责。实验室编制重用准则、实施共性需求分析和重用、组织重用分析准则的评审,委托方及其他利益相关方参与评审。

(3)时机/频度。共用准则建立/修订工作启动时,测试需求分析和重用时。

(4)入口准则。软件测评项目启动/重用改进工作启动。

(5)输入。共性测试需求。

(6)活动要求。建立和维护共性测试需求的建立及重用准则。建立准则一般规定共性测试需求的提取、评审与确定要求和改进维护要求等,重用准则一般明确共性测试需求在项目中的重用条件、重用方式、评审与确定要求和问题反馈机制等。依据共性测试需求建立准则,采用领域分析(自上而下)与逆向提取(自下而上)相结合的方法建立共性测试需求,基于通用功能需求实现其测试需求的可扩展性、可配置项,形成共性测试项并文档化。评审共性测试需求并将通过评审的共性测试需确定为可重用测试需求纳入组织资产(重用库)进行管理。在项目的测试需求分析阶段开展测试需求重用分析时,结合项目的任务要求和测试类型,从功能、性能、接口、质量特性等方面分析测试项目是否可以重用组织资产中的共性测试需求,并标识项目中重用的共性测试需求。在项目的收尾阶段,分析项目是否存在可提取为可重用测试需求的共性测试需求,并按重用准则的要求提取、评审并确定为可重用测试需求并纳入重用库中。

(7)输出。共性测试需求的建立和重用准则、共性测试需求描述文档、共性测试需求的重用分析记录、评审记录等。

(8)出口准则。所有评审问题均已关闭或得到妥善处理,共性测试需求的建立和重用准则、共性测试需求说明文档已纳入组织资产,产生的所有记录均已纳入数据管理。

3 应用验证效果

基于TMMi三级的软件测试需求管理过程已在该实验室中开展初步应用和验证。初步验证结果表明,该管理过程的应用有效指导和规范软件测评实验室的软件测试需求管理活动,减少软件测试需求管理活动的不符合,稳步提升测试质量和效率,提高客户满意度。其中,测试需求分析准则的使用和共性测试需求资产的建立和重用,对软件测试需求质量的促进效果明显。随着后续的应用和持续改进,软件测试质量和效能将持续提高。

4 结论

软件测试需求管理活动贯穿整个软件测试生命周期,是软件需求满足、软件测试结果有效的重要保证[10]。本文分析对比了CMMI、GJB5000B和TMMi三项标准在软件测试需求管理活动实施和改进指导的强项与不足,针对上述标准在软件测评实验室开展测试需求管理活动方面的不足,在基于TMMi的软件测试需求管理实践,并借鉴CMMI和GJB5000B的需求管理强项思想的基础上,结合工程实践经验,提出了基于TMMi三级的软件测试需求管理过程。旨在指导和规范软件测评实验室开展的测试需求管理活动的实施和改进工作,促使其软件测试需求管理活动达到测试成熟度模型三级的要求,提高软件测评过程质量和软件测试结果有效性,达到提高软件测试效能的目的。

猜你喜欢

委托方软件测试共性
延安精神和三线精神的共性特性与继承弘扬
软件测试方向人才培养“1+X”融合研究
大数据背景下软件测试技术的发展
共性
现代企业审计中委托方诚信建设的重要性
基于委托方视角的提高咨询单位审计质量的研究
基于委托方视角的提高咨询单位审计质量的研究
受托加工业务会计核算探析
关于 Web 应用系统的软件测试的研究
委托代销方式下销售业务会计处理探析