第3章 软件测试方法-- 软件度量

---

3.8 软件度量

  在软件开发中，软件质量度量的根本目的是为了管理的需要。利用度量来改进软件过程。人们是无法管理不能度量的事物。

  对于管理层人员来说：没有对软件过程的可见度就无法管理；而没有对见到的事物有适当的度量或适当的准则去判断、评估和决策，也无法进行优秀的管理。

  软件工程的方法论主要在提供可见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科。这就需要使用度量。度量是一种可用于决策的可比较的对象。度量已知事物是为了进行跟踪和评估。对于未知事物，度量则用于预测。

软件度量：
  度量是客观对象到数字对象的同态映射。同态映射包括所有关系和结构映射。换句话说就是，软件品质和软件度量成直对关系。这是度量和软件度量的根本理念。

软件度量的作用：

1. 通过软件度量增加理解；
2. 通过软件度量管理软件项目，主要是计划和估算、跟踪和确认；
3. 通过软件度量指导软件过程改善，主要是理解、评估和包装。软件度量对于不同的实施对象，具有不同的效用。

可度量性是学科是否高度成熟的一大标志，度量使软件开发逐渐趋向专业、标准和科学。

3.9 软件质量度量

软件质量，CMM的定义是：
一个系统、组件或过程符合特定需求的程度；
一个系统、组件或过程符合客户或用户的要求或期望的程度。

3.9.1 影响软件质量的因素

软件业通过多年的实践，总结出软件质量是人、过程和技术的函数，即Q={M，P，T}。其中，Q表示软件质量，M表示人，P表示过程，T表示技术。

3.9.2 质量保证模型

1. McCall模型
   正确性：一个程序满足她的需求规约和实现用户任务目标的程度。
   可靠性：一个程序满足一所需的精确度完成它的预期功能的程度
   效率：一个程序完成其功能所需的计算资源和代码的度量。
   完整性：对未授权人员访问软件或数据的可控制程度。
   可用性：学习、操作、准备输入和解释程序输出所需的工作量。
   可维护性：定位和修复程序中一个错误所需的工作量。
   灵活性：修改一个运行的程序所需的工作量。
   可测试性：测试一个程序以确保她完成所期望的功能所需的工作量。
   可移植性：把一个程序从一个硬件和或软件系统环境移植到另一个环境所需的工作量。
   可复用：性一个程序可以在另外一个应用程序中复用的程度
   互连性：连接一个系统和另一个系统所需的工作量。
   
2. Boehm模型
     Boehm模型着手于软件总体的功效，也就是说，对于一个软件系统而言，除了有用性以外，它的开发过程必定是一个时间，金钱和能量的消耗过程。考虑到系统交付时使用它的用户类型，Boehm模型从几个维来考虑软件的效用。
     总功效可以被分解成可移植性，有效性，可维护性。
     其中，有效性可以细分为可靠性，效率，运行工程可维护性可以细分为测试性，可理解性，可修改性。
   
3. FURPS模型

• 功能性：通过评价特征集和程序的能力、交付的函数的通用性和整体系统的安全性来评估。
• 可用性：通过考虑人的因素、整体美学、一致性和文档来评估。
• 可靠性：通过度量错误的频率和严重程度、输出结果的准确度、平均失效间隔时间、从失效恢复的能-力、程序的可预测性等来评估。
• 性能：通过侧度处理速度、响应时间、资源消耗、吞吐量和效率来评估。
• 支持度：包括扩展程序的能力可扩展性、可适应性和服务性这三个属性代表了一个更一般的概念—可维-护性、以及可测试性、兼容度、可配置性组织和控制软件配置的元素的能力、一个系统可以被安装的容易程度、问题可以被局部化的容易程度。

3.9.4 缺陷排除效率

  缺陷排除效率（Defect Removal Efficiency，DRE）:在项目级和过程级都能提供有益的质量度量。

  本质上，DRE是对质量保证及控制活动的过滤能力的一个测量，这些活动贯穿于整个过程框架活动。

  当把一个项目作为一个整体来考虑时，DRE按如下方式定义：DRE=E/（E＋D）；其中E=软件交付给最终用户之前所发现的错误数；D=软件交付之后所发现的缺陷数。

3.10 软件过程度量

3.10.1 软件过程度量概念

  软件过程度量是对软件过程进行度量的定义、方法、活动和结果的集合。它不是单一的活动而是一组活动的集合，它本身也是一个系统的过程。

  与任何系统的过程一样，它包括确定需求、制定计划、执行和结果分析等一系列完整的步骤。

  软件过程度量通常包括如下的活动：选择和定义度量、制定度量计划、收集数据、执行度量分析、评估过程性能、根据评估结果采取相应措施等。

3.10.2 软件过程度量常见问题

• 度量的太多、太频繁
• 度量的太少、太迟
• 度量了不正确的事物或属性
• 度量的定义不精确
• 收集了数据却没有利用
• 错误的解释度量数据
• 自动化工具欠缺

3.10.3 基于目标的软件过程度量方法

  GQM模型是一种层次状结构，最上层，是一个目标，对该目标细化就得到几个问题，构成问题层。
这几个问题，将关注的方面分解为几个部分。

目标主要受几个因素的控制：

• ISSUES（侧重点）：度量对象的质量重点。
• VIEWPOINT（立场）：信息使用者。
• OBJECT（对象）：要度量对象。
• PURPOSES（目的）：一般是理解、控制和改进要度量的对象。

问题：对于目标的陈述对象，抓住量化特征。结合侧重点，对特征进行描述。

度量项：尽量利用现有数据，实在没有相关数据积累或者现有数据的可靠性太差，也要少选、精选需要进行采集的数据项。

例子：

3.11 软件配置管理（SCM）

3.11.1 软件配置管理的目标

  软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。

基本目标包括：

• 软件配置管理的各项工作是有计划进行的。
• 被选择的项目产品得到识别，控制并且可以被相关人员获取。
• 已识别出的项目产品的更改得到控制。
• 使相关组别和个人及时了解软件基准的状态和内容。

3.11.2 软件配置管理角色

• 项目经理（Project Manager，PM）
• 配置控制委员会（Configuration Control Board，CCB）
• 配置管理员（Configuration Management Officer，CMO）
• 系统集成员（System Integration Officer，SIO）
• 开发人员（Developer，DEV）

3.11.3 软件配置管理过程描述

项目计划阶段：

• CCB根据项目的开发计划确定各个里程碑和开发策略；
• CMO根据CCB的规划，制定详细的配置管理计划，交CCB审核；
• CCB通过配置管理计划后交项目经理批准，发布实施。

项目开发维护阶段：:

• 主要由CMO完成的管理和维护工作；
• 由SIO和DEV具体执行软件配置管理策略；
• 变更流程。

软件配置管理基本流程：

3.11.4 软件配置管理的关键活动

任何关于SCM的讨论均涉及一系列复杂问题，比如：

• 一个组织如何标识和管理程序（及其文档）的很多现存版本，以使得变化可以高效地进行？
• 一个组织如何在软件被发布给客户之前和之后控制变化？
• 谁负责批准变化，并给变化确定优先级？
• 我们如何保证变化已经被恰当地进行？
• 采用什么机制去告知其他人员已经实行的变化？

SCM任务：

• 配置项识别
• 工作空间管理
• 版本控制
• 变更控制
• 配置审计
• 状态报告

小结：
  测量使得管理者和开发者能够改善软件过程；辅助软件项目的计划、跟踪及控制；评估产生的产品（软件）的质量。
  过程度量使得一个组织能够从战略级洞悉一个软件过程的功效。
  软件配置管理覆盖了整个软件的开发过程，因此是改进我们的软件过程、提高过程能力成熟度的理想的切入点。