全程软件测试(四十一):软件产品的质量度量—读书笔记

全程软件测试(四十一):软件产品的质量度量—读书笔记

软件产品的质量度量(软件度量)是根据一定的规则,将数字或符号赋予系统、构件、过程等实体的特定属性,从而让相关人员能清晰地理解该软件实体及其属性。简言之,软件度量就是对软件包含的各种属性进行量化表示。

软件度量可提供对软件产品和软件过程的衡量指标,使团队可以更好、更准确地做出决策以达到目标。软件度量的作用如下所示:

用数据指标表明验收标准;

监控项目进度和预见风险;

分配资源时进行量化均衡;

预计和控制产品的生产过程、成本和质量。

软件度量是用来衡量软件过程质量和进行软件过程改进的重要手段。但为了保持数据的可靠性、客观性和准确性,软件度量结果不可用于评价数据提供者的工作素质或绩效。

软件度量的内容和分类

软件度量的根本目的是通过量化的分析和总结来提高软件开发效率,降低软件缺陷率和开发成本,提高软件产品质量。具体来说,软件度量的根本目的包括4个方面,分别是收集信息、预测、评估、改进。

收集信息:通过分析获得过程、产品、资源、环境的信息,确定后期预测的基线和模型。收集信息是评估、预测、改进活动的基础。

预测:通过理解过程、产品各要素之间的关系建立模型,由已知的要素推算估计其他要素,以便合理分配资源,合理制订计划。

评估:分析活动与计划的符合程度,确定是否有偏差,以便控制其执行。可评估最终产品的质量、新技术的影响、过程改进对过程和产品的影响。

改进:根据得到的量化信息,帮助识别障碍物,查找问题的根源以及可提高产品质量和过程效率的其他方法,并与先前的量化信息比较,证实这些方法是否有效。

(1)软件度量的相关概念如下。

① 测量(Measurement)是对软件过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示。

② 度量(Metric)是对软件产品进行范围广泛的测度,它给出一个系统、构件或过程中某个给定属性的度的定量测量。

③ 指标(Indicator)是一个度量或一组度量的组合,即采用易于理解的形式,对软件过程、项目或产品质量提供更全面、更深入的评价,以利于过程和质量的分析。

(2)有效软件度量的属性如下。

① 简单且可计算。导出度量值应当是相对简单的,且其计算不应要求过多的工作量和时间。

② 经验和直觉上有说服力。度量应符合软件工程师对软件过程和产品的直觉概念,例如,测度模块内聚性的度量值应随内聚度的提高而提高。

③ 一致和客观。度量的结果不会产生二义性,任何独立的第三方使用该软件的相同信息可得到相同的度量值。

④ 在单位和维度的使用上一致。度量的数学计算应使用不会导致奇异单位组合的测度。例如,将项目队伍的人员数乘以程序中的编程语言的变量会引起一个直觉上没有说服力的单位组合。

⑤ 编程语言独立。度量应基于分析模型、设计模型或程序本身的结构,而不依赖于编程语言的语法。

⑥ 质量反馈的有效机制。度量会为软件开发效率、产品质量等提供积极的信息。

(3)软件度量的分类如下。

① 软件过程度量:用于过程的优化和改进。对软件开发过程本身的度量,目的是形成组织的各种模型,作为对项目、产品的度量基础,以便对软件开发过程进行持续改进,提高软件生产力。软件过程度量一般不直接进行,而是通过大量的项目度量分析、总结得到。软件能力成熟度模型中关键过程域的度量就是典型的过程度量。

② 软件项目度量:用于生产率评估和项目控制。对软件开发项目的特定度量,目的是评估项目开发过程的质量,预测项目进度、工作量等,辅助管理者进行质量控制和项目控制。

③ 产品质量度量:用于产品评估和决策。主要是针对项目开发结果——最终产品的度量。一般来说,产品度量指的是对产品质量的度量。

软件过程度量与软件项目度量的区别是:软件过程度量是战略性的,在组织范围内进行,是对大量项目实践的总结和模型化,对软件项目度量有指导意义;而软件项目度量是战术性的,针对具体的项目预测、评估、改进工作。

产品质量度量用于对产品质量的评估和预测。

(4)软件度量的内容如下。

① 规模度量:代码行数,以千行源代码为基准。它是工作量度量、进度度量的基础。

② 复杂度度量:软件结构复杂度指标,预测软件产品各部分的复杂性,以便选择最可靠的程序设计方法,确定测试策略。

③ 缺陷度量:帮助确定产品缺陷变化的状态,并标示修复缺陷活动所需的工作量;分析产品缺陷分布的情况,并指示需要加强何种研发活动,需要何种技术培训;预测产品的遗留缺陷情况;预测产品发布后缺陷的影响情况。

④ 工作量度量:把任务分解并结合人力资源水平来度量,合理地分配研发资源和人力,获得最高的效率。

⑤ 进度度量:通过任务分解、工作量度量、有效资源分配等做出计划,然后将实际结果与计划值进行对比来度量。

⑥ 生产率度量:产生代码行数/(人·月),测试用例数/(人·日)。

⑦ 风险度量:一般通过“风险发生的概率”和“风险发生后所带来的损失” 两个参数来评估风险。

⑧ 其他的项目动态度量:如需求更改、代码动态增长等。

目前各个方面的软件度量技术都开始走向成熟,规模度量、复杂度度量、缺陷度量、工作量度量等方面都有比较多的模型和方法可以利用。

软件度量的分工和过程

根据度量目标、内容和要求的不同,度量活动可能涉及一个项目的所有人员,也可能会包括各种活动数据的收集与分析。一个完整的度量活动涉及的角色包括度量工作小组、数据提供者、IT支持者等。

度量工作小组由专职的度量研究人员和项目协调人员组成。度量研究人员主要定义度量过程和指导进行度量活动,并对数据进行分析、反馈;项目协调人员是度量小组和项目组之间的联系人,其职责是为定义度量过程提供详细的需求信息,并负责度量过程在项目组的推行。

数据提供者通常是项目中的研发人员,有时还会包括用户服务人员和最终用户。数据提供者的工作主要是按照规定的格式向度量工作小组或IT支持者提供数据。

IT支持者主要根据度量工作小组的需要,确定数据提供的格式与数据存储方式,提供数据收集工具与数据存储设备。

根据数据统计,度量活动工作量不大,其中主要工作量由度量工作小组承担,IT支持者工作量为5%~10%,而软件工程师作为数据提供者,其工作量仅占2%~4%。随着度量过程体系、IT支持工具的逐步完善,软件研发人员在度量活动上花费的时间将越来越少。以度量活动的分析结果为基础,可提高劳动生产率和产品质量,其收益将远大于度量活动的成本。

为了说明软件度量的过程,此处以目标驱动的度量活动为例。目标驱动的软件度量活动主要包括5个阶段,分别是识别目标、定义度量过程、收集数据、数据分析与反馈、过程改进,具体内容如下。

(1)识别目标

根据管理者的不同要求,分析出度量的工作目标,并根据其优先级和可行性,得到度量活动的工作目标列表,并由管理者审核确认。

(2)定义度量过程

根据各个度量目标,分别定义其收集要素、收集过程、分析反馈过程、IT支持体系,为具体的收集活动、分析、反馈活动和IT设备、工具开发提供指导。具体的定义内容如下所示。

① 收集要素:定义收集活动和分析活动所需要的数据要素与收集表格。

② 收集过程:定义数据收集活动的形式、角色及数据的存储。

③ 分析反馈过程:定义对数据分析方法和分析报告的反馈形式。

④ IT支持体系:定义IT支持设备和工具,以协助数据收集、存储和分析。

(3)收集数据

根据度量过程的定义,数据提供者提供数据,IT 支持者应用 IT 支持工具进行数据收集工作,并按指定方式审查和存储。在规定的度量活动完成(或阶段性的度量活动完成)后,IT支持者输出数据收集结果给度量小组。

(4)数据分析与反馈

度量小组根据数据收集结果,按照已定义的分析方法进行数据分析,完成规定格式的图表,向相关的管理者和数据提供者进行反馈。

(5)过程改进

对于软件开发过程而言,根据度量的分析报告,管理者可基于度量数据做出决策。这些决策可能包括滚动计划、纠正活动或不做任何改变。上述(1)和(2)是保证成功收集数据和分析数据的先决条件,是度量过程最重要的阶段;(5)是度量的最终目的。

在改进过程中,度量过程自身的完备性也会得到评估。度量核心小组根据本次度量活动所发现的问题,将对度量过程进行改造,以提高度量活动的效率或使其更加符合组织的商业目标。

有前瞻性的公司会在软件开发的各个领域内广泛开展软件度量活动,其对工作量的估计可精确到每人每天,对缺陷的预测可精确到各个模块的缺陷密度。通过采用包括软件度量在内的各种软件工程技术,这些公司的生产力水平和产品质量水平得到了极大的提高。

软件质量模型

软件质量是指软件产品满足规定、隐含的需求的能力和相关特征与特性的集合,即所有描述软件优秀程度的特性组合。应用软件的质量依赖于问题需求的描述、解决方案的建模设计、可执行程序的编码及测试。为了更好地评价软件产品的质量,需要将软件质量的特性组合转化为物理或数学模型。

1976年,贝姆(Boehm)第一次提出了软件质量度量的层次模型;1978年,麦考尔(McCall)等人提出了从软件质量要素、准则到度量的三层模型;1985年,国际标准化组织建议软件质量模型(ISO9126)由三层组成,其中第三层由用户定义。

软件质量模型(ISO 9126)中三层的具体内容如下。

高层:软件质量需求评价准则(SQRC)。

中层:软件质量设计评价准则(SQDC)。

低层:软件质量度量评价准则(SQMC)。

ISO 9126软件质量模型如图所示。

全程软件测试(四十一):软件产品的质量度量—读书笔记

ISO 9126软件质量模型

在国家标准GB/T 17544—1998、GB/T 16260—1996中,对ISO 9126软件质量模型中定义的质量标准有详细描述,概括如下。

(1)功能性(Functionality):与现有的一组功能及其指定性质有关的一组属性,此处的功能是指满足明确或隐含需求的功能。

(2)可靠性(Reliability):与在规定的一段时间和条件下软件维持其性质水平的能力有关的一组属性。

(3)可用性(Usability):与一组规定或潜在用户为使用软件所须做的努力及对这样使用所做评价有关的一组属性。

(4)效率(Efficiency):与在规定的条件下软件的性质水平和所使用资源量之间的关系有关的一组属性。

(5)可维护性(Maintainability):与进行规定的修改所需的努力有关的一组属性。

(6)可移植性(Portability):与软件从某一环境转移到另一环境的能力有关的一组属性,其中每一个质量特征都分别与若干自特征相对应。

软件质量的度量

软件需求是度量软件质量的基础,不符合需求的软件质量自然不达标。定量的软件评估基于上述原则通过数学模型来实现,即尺度度量(Metrics Measurement)方法。上述定量度量适用于可以直接度量的特性,包括软件可靠性度量、复杂度度量、缺陷度量和规模度量。例如,程序出错率可定义为每一千行代码(Kilometer Lines of Code,KLOC)所含有的缺陷数量。为了进行软件测试和质量的度量,需要根据质量模型(麦考尔质量模型、贝姆质量模型或ISO 9126)来准备足够的数据,然后进行测试覆盖率、产品质量的量化评估分析。

(1)明确性(无二义性)、正确性、完全性、可理解性、可验证性、一致(内部和外部)性、简洁性、可完成性、可追踪性、可修改性、精确性和可复用性的数据。上述数据可用来评价、分析和模型相应的质量表现特征。

(2)公开的可能缺陷数与报告总缺陷数的对比可用来评价测试精确度和测试覆盖率,同时也可用来预测项目的发布时间。

(3)产品发布前清除的缺陷数在总缺陷数中所占的百分比可用于评估产品的质量。

(4)按严重缺陷、子系统缺陷来划分,分类统计出平均修复时间,这样将有助于规划修复缺陷的工作。

(5)利用测试的统计数据,估算可维护性、可靠性、可用性和原有故障总数等数据。

上述数据有助于评估应用软件的稳定程度和可能产生的失败。根据质量模型和上述观点,可用下列带加权因子的回归公式来度量质量。

Mi=c1×f1+c2×f2+…+cn ×fn

Mi是软件质量因素,如SQRC层各项待计算值;

fn是影响质量因素的度量值,如SQDC层各项估计值;

cn是加权因子。部分度量值可获得统计数据结果,部分度量值难以得到准确的量化值,需要主观测度,例如,通过检查表的形式,对这些特定属性进行评分。

质量度量的统计方法

质量度量统计方法是对质量评估量化的一种比较常用的方法,其使用有不断增长的趋势。质量度量统计方法包含的步骤如下。

(1)收集和分类软件缺陷信息。

(2)找出导致每个缺陷的原因。例如,不符合规格说明书、代码错误、设计错误、对客户需求误解、数据处理错误、违背标准、界面不友好等。

(3)使用二八定律。80%的缺陷由20%的主要因素造成,20%的缺陷由另外80%的次要因素造成,通过二八定律将20%的主要因素分离出来。

(4)一旦标出少数的主要因素,就可较为容易地解决引起缺陷的问题。

为了说明这一过程,假定软件开发组织收集了一年的缺陷信息,有些错误是在软件开发过程中发现的,其他错误则是在软件交付给最终用户之后发现的。尽管发现了数以百计的不同类型的错误,但所有错误都可追溯其出现的原因,具体原因种类有IES(说明不完整或说明错误)、MCC(与客户交流不够所产生的误解)、IDS(故意与说明偏离)、VPS(违反编程标准)、EDR (数据表示有错)、IMI(模块接口不一致)、EDL(设计逻辑有错)、IET(不完整或错误的测试)、IID(不准确或不完整的文档)、PLT(将设计翻译成程序设计语言中的错误)、HCI(不清晰或不一致的人机界面)、MIS(杂项)。

将上述各项数据收集完成之后,才可使用质量度量的统计方法。上述数据具体如下表所示,其中IES、MCC、EDR和IET占总错误的近62%,是影响软件质量的主要原因,但如果只考虑严重影响软件质量的因素,少数的主要原因就变为 IES、EDR、EDL 和 PLT。一旦确定少数的主要原因(IES、EDR等),软件开发人员就可集中在这些领域采取改进措施,改善质量的效果会非常明显。例如,为了减少与客户交流不够所产生的误解(MCC),在产品规格设计说明书中尽量不使用专业术语,若使用了专业术语,也需要定义清楚,以提高与客户的通信及说明的质量。为了改正EDR,不仅要采用CASE工具进行数据建模,而且要对数据字典、数据设计实行严格的复审制度。

全程软件测试(四十一):软件产品的质量度量—读书笔记

表 质量度量的统计数据收集

当质量度量与缺陷跟踪数据库结合使用时,可以为软件开发周期的每个阶段计算“错误指标”。针对需求分析、设计、编码、测试和发布各个阶段,可收集到的数据如下所示。

Ei= 在软件工程过程中的第i步中发现的错误总数

Si= 严重错误数

Mi= 一般错误数

Ti= 微小错误数

Pi= 第i步的产品规模(代码行数、设计说明页数、文档页数)

Ws、Wm、Wt分别是严重、一般、微小错误的加权因子,一般推荐取值为Ws=10、Wm=3和Wt=1,此处建议取值为Ws=0.6、Wm=0.3 和Wt=0.1(构成 100%)。每个阶段的错误度量值可以表示为PIi:

PIi=Ws(Si/Ei)+Wm(Mi/Ei)+Wt(Ti/Ei)

最终的错误指标EP通过计算各个PIi的加权效果得到。考虑到软件测试过程中越到后面发现的错误权值越高,简单用1,2,3,…序列表示,则EP为:

EP=∑(i×PIi)/PS   其中 PS=∑Pi

错误指标与上表中收集的信息相结合,可以得出软件质量的整体改进指标。

由质量度量的统计方法可知:想要将时间集中用于解决主要问题,首先就应找出导致主要问题的主要因素,而这些主要因素可通过数据收集、统计方法等分离出来,从而实现真正有效地提高产品质量。实际上,大多数严重的缺陷都可以追溯到少数的主要原因,通常与大部分人的直觉相近,但很少有人会花时间去收集数据来验证直觉。

来源:阳哥做IT笔记

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2021年9月7日
下一篇 2021年9月7日

相关推荐