摘 要
软件测试是保证软件质量的重要方法。随着软件开发规模的增大、复杂程度的增加,以寻找软件中的错误为目的的测试工作就更加复杂和困难。因此,为了尽可能多地找出程序中的错误,生产出高质量的软件产品,加强对测试工作的组织和管理就显得尤为重要,而其中很重要的一个方面是进行软件测试过程的度量。软件测试过程度量对于改进软件测试过程,提高软件测试效率具有重要意义。本文从几个角度简单介绍软件测试过程度量的基本理论。
关键词:软件测试过程度量, 软件测试成熟度模型, 软件测试过程改进
1 软件测试过程度量的重要作用
随着软件生产规模的日益增大,保证软件产品质量的软件测试工作越来越得到人们的重视,为更好地保证软件产品质量、更有效地执行软件测试工作,迫切需要对软件测试过程进行有效管理并逐步改善。目前,软件生产过程的管理模式也经历了完全依据管理者的经验到以数据为依据的量化管理这样一个逐步转化的过程。要对软件测试过程进行有效的管理就需要有反映过程本质特性的过程数据,通过这些数据,测试过程的执行状况才能得到监控,测试过程改进的决策才能有的放矢。由于软件测试过程的不可见性,软件测试过程度量则成为对软件测试过程进行量化管理不可或缺的一个环节。
软件测试过程度量是这样一种技术,它提取软件测试过程中可计量的属性,在测试过程进行中以一定频度不断地采集这些属性的值,并采用一些恰当的分析方法对得到的这些数据进行分析,从而量化地评定测试过程的能力和性能,提高测试过程的可视性,帮助软件组织管理以及改进软件测试过程。
软件测试过程度量的作用主要体现在如下几个方面,如图1所示。
图1 软件测试过程度量的作用
发现:通过度量对过程、产品、资源和环境进行分析和理解,在此基础上建立过程基线。过程基线是进行过程评价和过程改进的基准。
评价:通过评价比较实际软件过程与标准或计划间的差异。过程评价是衡量过程好坏和过程改进效果的有效手段。
控制:通过度量所反映的产品状态信息、项目状态信息和过程状态信息,可以帮助制定合理的管理控制措施,使产品偏离度、项目偏离度和过程偏离度在可控制的范围内,使项目过程的性能表现稳定,并且项目过程性能满足需求。
预测:历史度量数据的积累能帮助预测当前项目的相关属性数据,有助于计划和决策的制定。
改进:度量并不能直接改进过程,但基于度量的理解和评价为过程改进提供了有效的线索。根据这些线索再结合度量所记录的过程场景信息分析过程偏差的原因,帮助过程改进制定有效的变更措施。过程改进既是度量的结果,又是度量的动因。
2 软件测试过程度量中的几个概念
Process:过程 ,指一组部分有序的活动[IEEE-STD-610]。计划和实施一个过程都是为了达到特定的目的,该定义表明过程是由活动组成,活动可以是串行的,可以是并行的,也可以是串并相结合的。其中活动的顺序可能是时间的先后次序,因果顺序,或条件顺序等。
Activity:活动,是过程中要执行的工作[CMM Version 1.1]。实施活动是要达到一定的目的,所以活动都有信息输入和信息输出,信息输入是活动的前提条件,信息输出是活动的目的结果。
Measure:度量(名词),是通过执行测量赋予一个实体属性的数值或类别[1]。数值是对软件产品、软件过程的特征的量化记数的结果,例如软件模块的规模是10K代码行;类别是特征的定性表示,例如软件风险,可以是高或低。
Measure:度量(动词),执行测量[1],是按照度量过程中的过程定义,对软件过程或软件产品实施度量,表示实际的动作。
Measurement:测量,是按照一定的尺度用度量(metric)给软件实体属性赋值(可能是数值或类别)的过程[2]。它强调对软件实体属性进行量化的过程性,是提取软件过程或软件产品属性的度量(measure,名词)的过程。它所蕴涵的内容是度量的过程。
Metric:度量,是已定义的测量方法和测量尺度[1]。在很多场合与Indicator交叉出现,但其内涵大于Indicator,Metric指软件环境中任何一个软件对象的属性的量化表现。
Indicator:指示器,是用于评价或预测其他度量(measure,名词)的度量(measure,名词)[1]。指示器是一个或多个度量(metric)的综合,是对软件产品或软件过程的某一方面特征的反映。不同的度量目的有不同的度量指示器。在具体的实施过程中,可操作的度量成千上万,选择最能反映当时度量环境的指标作为度量指示器。
软件测试过程:保证软件质量的过程,已经不再被视为是在软件开发之后的一个独立的过程,而是贯穿于整个软件生存周期中的重要过程,并分为若干个阶段。
软件测试过程度量:是对软件测试过程进行度量的定义、方法、活动和结果的集合。
3 软件测试过程度量的分类
对软件测试过程的度量是对软件测试过程特性的一种描述,不同的描述类型决定了不同的度量内容、度量的表达方式、度量数据的采集手段、度量数据的分析方法。根据不同的描述类型划分测试过程度量类型如下:
(1)客观度量和主观度量:客观度量是过程或产品的实际结果,主观度量是人的主观判断结果,也可以是在客观数据基础上的分析结果。实施主观度量的一个前提是要有经验丰富的软件工程和软件过程人员。客观度量在一定程度上减少了人为的主观影响,因为它多表现为量化的数据,且数据的来源和产生的背景信息又可以清楚定义,这就赋予了数据较强的说明能力,为软件组织对过程进行量化管理和优化管理打下基础。本文给出的度量定义和度量分析方式是以客观度量为主、主观度量为辅的。
(2)绝对度量和相对度量:绝对度量其度量值的取得没有参照物或没有其他属性之间的依赖关系,比如,一个被测的程序模块具有绝对的代码行数,其他代码模块的变化不影响该模块的大小。相对度量是指其度量值的取得具有参照物或与其他属性之间有依赖关系,比如生产效率依赖于过程时间和产品的规模。
(3)显式度量和隐式度量:显式度量是可直接得到数据的度量,隐式度量是对原始度量数据进行运算或结合多个度量分析得到的结果。例如测试时间是显式度量,测试人员工作效率是隐式度量。
(4)动态度量和静态度量:动态度量是二维以上的度量,用于动态监控过程信息随时间的更新情况。一般第一维表示数值或类别,第二维表示时间。时间可能是绝对的日期或时钟,也可能是测试项目进度或里程碑等表示过程的进程信息。静态度量是一维度量,例如过程的计划信息。
(5)预测度量和解释度量:预测度量是根据既有度量信息来预测过程的未来执行情况。解释度量是事后度量,对已经执行的活动进行度量。从过程迭代的角度来看,上一次的解释度量可能是下一次的预测度量。
(6)内部度量和外部度量:内部度量和外部度量的划分是从度量的信息源和结果应用的作用域而言的。有三种类型的作用域:软件测试组织内部和外部,项目组内部和外部,项目内各小组之间。
4 软件测试过程度量的关注点
软件测试过程度量有四个核心关注点:过程性能、过程稳定性、过程能力、过程一致性。对测试过程的考察及相关度量数据的采集和分析通常从这四个方面入手,具体内容如下。
4.1过程性能
过程性能表示遵循一个过程所达到的实际结果。我们通过对过程性能的度量来量化的评价一个过程满足客户和组织的在各关键方面的能力。
选择过程性能属性度量的标准包括:最相关的(质量、耗费的资源和时间等)、高信息量的、对变化敏感的、影响大的、便于收集和定义的以及有助于过程诊断的。
软件测试过程性能从以下两个方面来度量软件测试过程满足预算的能力、软件测试过程满足项目时间表的能力、测试过程使用户满意的能力、测试过程满足特定需求的能力、测试过程中的生产率及测试过程中的资源占用率等。
一是测试过程产品的属性,如产品的功能、规模、执行速度、是否易于使用以及稳定性和健壮性等。下面的例子就说明了测试过程中产生的测试用例、软件问题这些中间产品的规模:
软件测试过程中创建测试用例的总个数。
软件测试过程中提交软件问题报告的总个数。
二是测试过程本身的属性,例如测试过程花费的人力物力、完成某个测试活动的时间、所使用资源的特性和数量等。例如
软件测试过程的预期开始和结束时间。
某软件测试活动的实际开始和结束时间。
测试项目/各测试阶段中的人工消耗
测试过程的资金花费情况。
4.2过程稳定性
如果软件过程性能的度量值长时间无规律的变化,其值无法预测,则说明该过程是不稳定的。过程的稳定性是一个很重要的特性。只有一个过程是稳定的,才能根据过程现有的性能来预测其将来的可能发展趋势,或把它作为过程改进的基础。如果一个过程不稳定,说明有一些可归属的因素在影响过程的执行,消除了这些因素,不仅能保证过程稳定性,也能够提高过程的性能。
当涉及时间的度量时,过程和产品的所有特性都会显示出偏差。Shewhart对偏差源分类如下:
归因于现象的偏差:它对过程来说是自然和内在的,一个给定属性的所有度量,偏差结果是共同的,在一定的界限内,此类偏差不可消除,称为公共原因偏差。
有可归属的原因的偏差:此类偏差并不是所有度量值都具有的,是因为过程的某些时间点上的一些特殊原因造成的,因此是可以预防和消除的。
过程的偏差用公式表示为:
总偏差=公共原因偏差+可归属的原因偏差。
公共原因偏差是随机的,但在某个可预测的界限内变化,它有一个稳定的变化模式。对于软件测试过程来说,公共原因引起的过程性能的变化是可预测的,因此一个只有公共原因偏差的过程被认为是一个稳定的过程。在一个稳定的过程中,偏差都是由于过程本身的内在原因造成的。可归属原因的偏差要么已经从过程中排除,要么已经得到遏制,使其不会重现或成为过程的一个永久部分。
软件测试过程的稳定性决定了软件测试组织能否按计划生产产品的能力,对于软件测试过程的改进也是非常重要的。
没有稳定性以及不知道一个过程能够做什么,就无法把度量中的信号(Signal)从伴随他们的随机噪声(Noise)中分离出来。这样度量很容易导致不适当的行动。
不受控制的偏差随时都可能发生,如果没有稳定的性能的历史纪录,对未来性能的预测就没有合理的依据,从而使得制定的所有计划都是冒险的和没有实际根据的。
不了解性能的稳定水平,就没有依据来辨认提示过程改进机会的可归属原因。
没有稳定性,就没有可重复的过程作为过程改进的依据。改进的效果可能就无法与其它可归属的因素相区别。
由此可见,过程的稳定性是过程的一个非常重要的特性。在根据过程和产品的度量数据来预测未来的结果,以及把度量数据作为过程改进的依据时,过程的稳定性都是必须首先满足的条件。
4.3过程能力
过程能力描述了遵循一个软件测试过程可能达到的预期结果的范围。了解过程能力对于预测产品质量是十分关键的。组织的过程能力为组织承担新项目时能否达到期望结果提供了预测依据。一般使用过程能力基线(Process
Capability Baseline-PCB)来量化的描述过程能力,建立和分析过程能力基线需要用到统计过程控制方法。
4.4过程一致性
一个稳定的、可预测的过程必须一致的执行。当一个过程不稳定时,对可归属原因的调查通常由检查过程一致性开始。经验表明,过程一致性从三个方面影响过程性能:
执行过程的适宜性:对组织执行过程适宜性的了解有助于识别合适的行动,来纠正那种由于缺乏适合性而导致过程不稳定或不能满足客户需求的情况。
已定义过程的使用:过程稳定性依赖于对已定义过程一致的执行。通过度量已定义过程的利用程度,能够确定已定义过程何时没有得到切实的执行,以及可能的偏差原因,从而采取合适的行动。
过程的勘查、校准和评估:所有的过程都会受到熵作用影响。也就是说,如果放任不管,过程会偏离受控状态而进入混乱状态。可以通过定期过程状态评审、正式的过程评估和项目校准来维护过程。
5 软件测试成熟度模型(TMM)
软件测试成熟度模型(TMM)[3]是当前影响力最大的软件测试过程模型。作为一类等级递增模型,它体现了20世纪50年代到20世纪末的测试阶段划分和测试目标定义的发展历程。它来源于当前的工程实践总结,并充分利用了Beizer的测试人员思考模式的进化模型。它能够用于分析软件测试机构运作过程中最优秀或最混乱的区域,并辅助软件测试机构进行测试过程的评估与改进。
TMM制定了五个成熟度等级:初始级,阶段定义级,集成级,管理和度量级,优化、缺陷预防和质量控制级。各级成熟度水平包含了一组成熟度目标和子目标,以及支持它们的任务、职责和活动。
5.1第一级 初始级
TMM初始级软件测试过程的特点是测试过程无序,有时甚至是混乱的,几乎没有妥善的定义。初始级中软件的测试与调试常常被混为一谈,软件开发过程中缺乏测试资源,工具以及训练有素的测试人员。初始级的软件测试过程没有定义成熟度目标。
5.2第二级 阶段定义级
TMM的阶段定义级中,测试活动是按照计划进行的,测试己具备基本的测试技术和方法(如白盒测试和黑盒测试),软件的测试与调试己经明确地被区分开。这时,测试被定义为软件生命周期中的一个阶段,它紧随在编码阶段之后。但在定义级中,测试计划往往在编码之后才得以制订,这显然有背于软件工程的要求。
TMM的阶段定义级中需实现3个成熟度目标:制订测试与调试的目标和策略,启动测试计划过程,制度化基本的测试技术和方法。
5.3第三级 集成级
在集成级,测试不仅仅是跟随在编码阶段之后的一个阶段,它已被扩展成与软件生命周期融为一体的、一组已定义的活动。测试活动遵循软件生命周期的V字模型。测试人员在需求分析阶段便开始着手制订测试计划,并根据用户或客户需求建立测试目标,同时设计测试用例并制订测试通过准则。在集成级上,应成立软件测试机构,提供测试技术培训,关键的测试活动应有相应的测试工具予以支持。在该测试成熟度等级上,没有正式的评审程序,没有建立质量过程和产品属性的测试度量。集成级要实现4个成熟度目标,它们分别是:建立软件测试机构,制订技术培训计划,软件全寿命周期测试,控制和监督测试过程。
在TMM的定义级,测试过程中引入计划能力。在TMM的集成级,测试过程引入控制和监督活动。两者均为测试过程提供了可见性,为测试过程持续进行提供保证。
5.4第四级 管理和度量级
在管理和度量级,测试活动除测试被测程序外,还包括软件生命周期中各个阶段的评审,审查和追查,使测试活动涵盖了软件验证和软件确认活动。根据管理和度量级的要求,软件工作产品以及与测试相关的工作产品,如测试计划,测试设计和测试步骤都要经过评审。因为测试是一个可以量化并度量的过程。为了度量测试过程,测试人员应建立测试数据库,收集和记录各软件工程项目中使用的测试用例,记录缺陷并按缺陷的严重程度划分等级。此外,所建立的测试规程应能够支持软件组织最终对测试过程的控制和度量。管理和度量级有3个要实现的成熟度目标:建立组织范围内的评审程序,建立测试过程的度量程序和软件质量评价。
5.5第五级 优化、预防缺陷和质量控制级
由于本级的测试过程是可重复的、已定义的、已管理的和己度量的,因此软件组织能够优化调整和持续改进测试过程。测试过程的管理为持续改进产品质量和过程质量提供指导,并提供必要的基础设施。优化、预防缺陷和质量控制级有3个要实现的成熟度目标:应用过程数据预防缺陷,质量控制,测试过程优化。
参考文献
[1] ISO/IEC 14598-1: 1999, Information technology -
Software product evaluation-Part 1: General overview[J].
[2] McGarry J., Card D.N., Cheryl J., et al. Practical
Software Measurement: Objective Information for Decision
Makers[M]. Addison Wesley, 2002.
[3] Burnstein I., A Testing Maturity Model for Software
Test Process Assessment and Improvement. Software Quality
Professional, September 1999, Volume 1(4)
[4] Victor R. Basili, H. Dieter Rombach. The TAME
project: Towards improvement-oriented software environments[J]
. IEEE Transactions on Software engineering, 1988, 14(6):
758-773.
[5] Burnstein Ilene. Practical Software Testing: A
Process-oriented Approach. New York: Springer-Verlag,
Inc., 2002
[6] Humphrey W.A Discipline for software Engineering,
Addison-Wesley, Reading, MA, 1995
|