软件测试知识帖(61-80

软件测试知识帖(61-80)

第61帖【2004－7－19】：软件估计

软件估计、测量、度量过程是软件开发过程的重要组成部分，是开发过程不断改进的原因所在。软件组织如果没有什么有效手段评估和测量开发过程，即使是依赖优秀的个人和开发团体成功的开发了多个产品或项目，也不能将经验和教训记录下来供以后的开发工作参考并用于改进开发过程。产品或项目的成功总是过多的依赖个人的努力而不是丰富的历史经验数据。

软件组织需要制订开发过程相关的软件估计、测量、度量活动规范、模板，并且把软件估计、测量等活动列入了日常的开发工作的一部分。并以阶段性数据形式进行数据估计和测量工作，这些将成为以后开发过程重要的参考资源。

软件估计过程主要包括规模、工作量、进度的估计。规模估计有许多已成为标准的估计方法，常见的有Wideband Delphi Technique、Pert Sizing、功能点、 类比法以及一些估计工具。

第62帖【2004－7－20】：CMM2级之需求管理

任何一个产品都应满足用户相应的需求。但是满足用户需求的同时会存在两个问题：一是需求在开发过程中会发生变化，如何控制与管理这些变化？二是从需求到产品要经过许多步骤，如系统设计、详细设计、具体实现等，如何保证这些步骤没有背离产品的需求？

需求管理关键过程域就是针对这两个问题提出相应的目标。软件需求可能是系统需求的一部分或是全部（纯粹的软件产品），无论是哪种情况，需求管理的第一个目标就是软件需求应能被控制，并可产生一个可用于软件工程过程和管理过程的基线。需求管理的第二个目标是确保软件项目计划、开发活动、产品与需求一致。需求管理的最终目的是在用户与实现用户需求的项目之间达成共识，需求管理活动就是为了建立并维护这种共识。

第63帖【2004－7－21】：CMM2级之软件项目计划

软件项目计划（SPP）常常不能按期完成，主要原因有两个方面：一是由于计划执行和管理的能力不足；二是计划本身是否合理和有效，计划的不合理性和无效性造成了大多数项目拖延，甚至失败。项目的跟踪与监督则是如何保证计划的执行和调整。

建立合理的开发计划的基础是对项目规模、资源要求和风险等要有一个合理的估算。这个估算过程应是规范的，而不是任意的。例如，如果提出一个项目计划需要40个软件工程师工作三个月的计划，那么就要问这些数据是如何得出的。用户提出的时间和费用的要求仅能作为项目计划的约束条件，而不能作为项目计划的基础。开发计划要包括所有项目活动和所有参加方面的责任，这些活动和责任需要文档化，以保证有效地将计划传达给项目的各个参加方。在项目开发计划执行前，各个项目参加方要认同所承担的项目责任，这种认同是项目计划有效性的一个基本保证。

第64帖【2004－7－22】：CMM2级之软件项目跟踪与监控

软件工程项目是否成功的主要因素在于项目管理，而项目是否能有效地进行管理的关键在于项目过程的可见性。由于软件项目过程是一个逻辑活动过程的组合，因此，它不具备一个物理过程那样的可见性。软件项目跟踪与监控的目的就是为项目实际过程提供充分的可见性，以保证当项目执行偏离项目计划时能采取有效的解决措施。

项目跟踪是基于计划的，对一个项目要设定适当的检查点。在检查点上要将执行结果、执行状态和项目开发计划进行比较。若发现较大的差异，则采取适当的步骤进行调整。在必要的情况下，也需要对项目计划本身进行修改和调整。若在修改计划时，改变了某些项目责任，那么这些改变必须得到有关责任方面的重新认同。

第65帖【2004－7－23】：CMM2级之子合同管理

由于CMM是美国国防部投资研究的项目，而美国军方有大量的子合同转包，因此子合同管理也成为了一个基本的KPA。子合同管理的目的就是选择合格的软件承包商，并可进行有效地管理。子承包商选择应由项目责任者负责，子承包商的选择是基于能力的，项目的责任者与子承包商对所承包的项目责任要有一致的认同，并保持不断地交流。项目责任者负责根据合同的责任跟踪子承包商的实际工作结果。

第66帖【2004－7－25】：CMM2级之软件质量保证

软件质量保证是项目管理提供的过程可见性的一个工具。由于用于开发软件系统或软件产品的过程是决定项目成功与否的关键因素，因此软件质量保证的工作是评审和审计软件活动与软件产品。评审和审计的依据是规定用于项目的步骤和相关标准。软件质量保证活动不能是随意的，必须经过充分的讨论和协商。相关的组织和个人要了解质量保证的活动和质量保证活动的结果。为了解决质量保证组织与开发组织对某些项目开发活动或开发出的产品的评价发生的争议和分歧，企业要定义更高层次的管理组织，负责解决这些争议和分歧。

第67帖【2004－7－26】：CMM2级之软件配置管理

产品从需求分析开始到最后提交产品要经历多个阶段，每个阶段的工作产品又会产生出不同的版本，如何在整个生存期内建立和维护产品的完整性是配置管理的目的。配置管理关键过程域的基本工作内容是：标识配置项、建立产品基线库、系统地控制对配置项的更改、产品配置状态报告和审核。同软件质量保证活动一样，配置管理活动必须制定计划，而不是随意的行为。相关的组织和个人要了解配置管理的活动及其结果，并且要认同在配置管理活动中所承担的责任。

第68帖【2004－7－27】：软件过程和项目的度量

测度对于任何工程学科而言都是基本的，软件工程也不例外。在过去十年中，软件工程界终于开始认可测度对于软件开发过程的重要性，但付出的代价也是昂贵的。

软件度量是指计算机软件中范围广泛的测度。测度可以应用于软件过程中，目的是在一个连续的基础上改进它。测度也可以用于整个软件项目中，辅助估算、质量控制、生产率评估及项目控制。最后，软件工程师使用测度帮助评估技术工作产品的质量，且在项目进行中辅助决策。

在软件项目管理中，我们主要关心生产率和质量的度量--根据投入的工作量和时间对软件开发“输出”的测度，对产生的工作产品的“适用性”的测度。为了达到计划及估算的目的，我们的主要兴趣是放在历史数据上：在过去的项目中软件开发生产率是怎样的呢？产生的软件的质量是怎样的？如何从过去的生产率及质量数据推断出现在的状况？过去的信息如何帮助我们更加准确地计划和估算呢？

第69帖【2004－7－28】：软件度量规则

软件过程度量对于一个组织提高其总体的过程成熟度能够提供很大的帮助。不过，就像其他所有度量一样，它们也可能被误用，产生比它们解决的问题更多的问题。基于此，需要建立软件度量规则，该规则可以用于管理者建立过程度量计划：

1、解释度量数据时使用通用的观念，并考虑组织的感受性

2、对收集测量和度量的个人及小组提供定期的反馈

3、不要使用度量去评价个人

4、与开发者和小组一起设定清晰的目标及达到这些目标的度量

5、不要用度量去威胁个人或组织

6、提出某个问题的度量数据不应该被看成是“否定的”含义，这些数据仅仅是过程改进的指标

7、不要被某个与其他重要度量不符合的度量迷惑

第70帖【2004－7－29】：软件故障分析

通过软件故障分析方法可以收集软件开发及使用中所遇到的错误及缺陷的信息。故障分析采用如下方式：

    1.根据来源分类所有的错误和缺陷（如规格说明中的错误，逻辑错误，与标准不符合的错误等）

    2.记录修改每个错误和缺陷的成本

    3.统计每一类错误和缺陷的数目，并按降序排列

    4.计算每一类错误和缺陷的总成本

    5.分析结果数据，找出造成组织最高成本的错误和缺陷类型

    6.产生修正过程的计划，目的是消除（或降低其出现的频率）成本最高的错误和缺陷类型

第71帖【2004－7－30】：SQA的职责

SQA的职责

1、组织和协调产品开发组内部的软件技术和开发标准、流程的培训和教育；

2、部门的和特定产品的软件开发过程度量（Metrics）以及软件产品质量的度量（Metrics）；

3、指出产品开发过程中应该遵循的有关软件开发的标准和流程，并监督开发过程对标准和流程的符合度；

4、软件质量管理，采用Inspection，Review和Audit技术；

5、通过软件开发流程及标准的推行以及对软件开发过程的不断总结和优化，使软件开发过程得到持续不断的优化和提高。

第72帖【2004－7－31】：验证与确认

在广义上，软件测试是验证和确认VERFICATION AND VALIDATION （V﹠V〕。验证指保证软件正确地实现了一特定功能的一系列活动。确认是指保证所生产的软件可追溯到用户需求的一系列活动。BOEHM对V﹠V的解释是：

VEIFICATION：“Are we building

the product right?"

VALIDATION:

" Are we building the right product?"

V&V的过程包含了许多内容和活动，如：

软件工程方法提供了质量建立的基础；

分析、设计和编码方法通过提供统一的技术和可预测的结果来提高质量；

正规检视和评审有助于保证软件工程各个阶段产品的质量；

度量和控制被应用到软件配置的每一个部件中；

标准和过程有助于保证开发的一致性；

一个正规的SQA过程加强整体质量。

测试是保证质量的最后一道措施。但是不能把测试看作一个安全网。质量是贯穿于软件过程的每一个阶段。因此尽管测试在V&V中起着非常重要的作用，但是许多其它活动也是必要的。为了提高软件的全员质量，应该重视V&V中的每一个活动。

第73帖【2004－8－2】：可测试性技术的产生

可测试性的概念最早产生于航空电子领域。较早的航空电子设备的测试过程通常采用以分析输入/输出端口为主的“黑箱”方式进行。随着电子设备功能和结构日益复杂，可靠性、维修性要求日益增高，“黑箱”方法已越来越难以满足需求。为此，要求测试人员以更积极的方式介入测试过程，不仅要承担传统测试中激励生成者和响应分析者的角色，而且要成为整个测试过程的主导者和设计者，通过改善被测试对象的设计使其更便于测试，即提高被测对象的可测试性。这种可测试性的思想和概念最早由F.Liour等人于1976年提出。随后，美国国防部相继颁布了MIL-STD-471A通告II--《设备或系统的机内测试、外部测试、故障隔离和可测试性特性要求的验证及评价》、MIL-STD-470A--《系统及设备维修性管理大纲》、MIL-STD-2165--《电子系统及设备的可测试性大纲》等一系列与可测试性相关的标准规范。其中，MIL-STD-2165可测试性大纲将可测试性作为与可靠性及维修性等同的设计要求，并规定可测试性分析、设计及验证的要求及实施方法，该标准的颁布标志着可测试性作为一门独立学科的确立。

可测试性概念提出后，相继用于电子产品诊断电路设计及研究等各个领域。可测试性技术不仅对维修性设计特性产生重大的影响，而且影响到系统的效能及全寿命周期费用。

第74帖【2004－8－3】：可测试性的内涵

1、可测试性描述了测试信息获取的难易程度

可测试性包括两方面的含义：一方面，便于对软件的内部状态进行控制，即所谓的可控性；另一方面，能够对软件的内部状态进行观测，即可观测性。实际上，可控性和可观测性所描述的就是对软件进行测试时信息获取的难易程度。传统的“黑箱”功能测试方法的根本缺陷就在于它难以获取有效表征被测对象内部状态的信息。

2、可测试性是软件本身的一种设计特性

同可靠性（reliability）一样，可测试性也是软件本身所固有的一种设计特性。软件的可测试性并不是可测试性设计所赋予的，软件一旦设计生产出，本身就具备了一定的可测试性。正如可靠性可以通过MTBF等可靠性指标度量一样，可测试性也可以通过可控性、可观测性指标来度量。要改善软件的可测试性指标，必须在软件设计阶段就进行良好的可测试性设计。

3、可测试性技术的最终目标是提高软件的质量和可靠性，降低全寿命周期费用

降低软件的费用，追求软件的高质量是工业界的永恒主题。目前，单纯合格与否的传统质量标准已转变为综合了性能指标、可靠性及可用性（availability）指标要求的“完整质量”概念，而传统的仅考虑软件设计和生产费用的产品费用则被“全寿命周期费用”的概念所替代。全寿命周期费用包括软件整个生命周期中从概念形成到报废处理全过程的费用。

可测试性技术的应用可以极大地提高软件的“完整质量”，降低其全寿命周期费用。一方面，在软件设计阶段，可以对软件设计原型进行虚拟测试，验证设计方案，排除可能的设计缺陷；在生产阶段，可以对软件进行全面的测试，排除软件的潜在故障，从而降低使用过程中的故障率，提高其质量和可靠性；另一方面，可测试性技术可以缩短软件研制、试验和评价的周期，降低软件的研制费用，提高软件的可用性指标，减少软件的维护和保障费用，从而降低软件的全寿命周期费用。

第75帖【2004－8－4】：可测试性度量

要提高产品的可测试性，首先要对产品的可测试性水平进行描述，也就是进行可测试性度量。可测试性度量方法需满足精确性和简单性两个要求。所谓精确性是指可测试性度量方法能准确地预计产品测试程序生成的困难，并且定位到产品的某一部分，从而便于对产品设计进行更改。而简单性要求则是指度量可测试性的计算量应小于测试程序生成的计算量，否则，可测试性度量方法就会失去实际的应用意义。

第76帖【2004－8－5】：可测试性机制的设计与优化

可测试性机制的设计与优化

可测试性设计的过程就是将某种能方便测试进行的可测试性机制引入到软件中，提供获取被测对象内部测试信息的渠道。显然，合理、有效的设计可测试性机制是成功提高软件可测试性水平的基础。可测试性机制的引入可以提高系统的可测试性指标，降低软件的全寿命周期费用，但同时也会在一定程度上提高软件的成本。因此，综合权衡可测试性机制的性能和费用，进行可测试性机制的优化设计是可测试性技术能否成功应用的另一个重要因素。

第77帖【2004－8－6】：测试信息的处理与故障诊断

为了实现提高软件质量和可靠性，降低系统全寿命周期费用的目标，要求可测试性技术能够方便、快捷地获取有关被测软件状态的信息，确定软件工作正常与否、性能是否良好、是否存在故障以及存在何种故障，以便于采取调整设计、排除故障、更换备件等后续行为。

在对复杂的对象进行测试时，难点往往不在于如何获取测试信息，而在于如何对所获取的大量信息进行处理。例如：对于一个具有N个测点的数字电路而言，所能获取的测试信息的总量为N*2N位，随着N的增大，测试信息总量呈指数增长。显然，能否对所获取的测试信息进行有效处理并对可能存在的故障进行精确诊断，是可测试性技术成功应用的关键。

第78帖【2004－8－9】：特定目标可测试性设计

第一代可测试设计技术：特定目标可测试性设计

第一代可测试性设计技术以外部测试和特定目标可测试性设计方法为基础。特定目标可测试性设计是指：针对特定功能和结构进行可测试性预计，判断其是否符合可测试性要求，若不满足，通过改善设计方案来提高其可测试性，直至满足要求。特定目标可测试性设计主要采用外部测试方法，测试向量的输入和测试响应的输出均通过被测设备的输入/输出端口进行操作，对被测对象内部节点的控制和观测则采用以在线（in-line）测试技术。其主要缺点如下：

(1) 设计同系统的具体功能和结构紧密相关，对较复杂的系统进行设计的难度大、周期长；

(2) 难以实现并行测试；

(3) 需要专用测试接口和测试工具，成本高；

(4) 随着系统的复杂，采用监控测试方法的适用范围日益减小。

目前，特定目标可测试性设计已逐渐被其他的可测试性技术所代替。尽管如此，对于复杂程度较低的而言，特定目标可测试性设计方法仍然是一种不可或缺的方法。

第79帖【2004－8－10】：基于扫描设计的结构化设计

第一代可测试设计技术：基于扫描设计的结构化设计

我们知道，要完成某种系统功能可以采用不同的结构实现。传统的设计思想是尽量选用较为紧凑和简化的结构。然而，由于可测试性同系统的的结构密切相关，上述方法在设计中没有充分考虑结构对系统可测试性的影响，所设计出的系统的可测试性往往较差，将极大地增加可测试性改善设计的难度，这正是特定目标可测试性设计方法的根本缺陷。

结构化可测试性设计是一种新的可测试性设计策略，其主要思想是：从可测试性的观点出发，对结构结构提出一定的设计规则，使得所设计的产品更容易测试。结构化可测试性设计通常采用扫描设计的方法进行，有多种具体的实施方法，包括：扫描设计、扫描通路、扫描置位，等等。它依然存在如下的缺点：

(1) 可测试性设计的过程仍较复杂，设计周期较长，成本较高；

(2) 主要采用外部测试的方法，自动化程度不够，成本仍然较高；

(3) 不同的产品设计厂家采用不同的设计方法，相互之间不兼容，产品的维修性较差。

第80帖【2004－8－11】：基于边界扫描机制的标准化设计

第三代可测试性设计技术：基于边界扫描机制的标准化设计

鉴于结构化可测试性设计方法的一些缺点，有必要开发一种更为简单的、标准化的可测试性设计方法。为此，从1986～1988年，以欧洲和北美会员为主的联合测试行动组织（JTAG：joint test action group）率先开展了边界扫描技术的研究，提出了一系列边界扫描标准草案。1990年，IEEE组织和JTAG组织共同推出了IEEE 1149.1边界扫描标准［18,19］。

IEEE 1149.1定义了一种标准的边界扫描结构及其测试接口，其主要思想是：通过在内部逻辑之间，即边界上增加边界扫描单元，实现对状态的串行设定和读取，从而提供芯片级、板级、系统级的标准测试框架。边界扫描机制可以实现下列目标：

(1) 测试不同单元之间的连接；

(2) 测试单元的功能；

(3) 应用边界扫描寄存器完成其他测试功能，如伪随机测试、特征分析、静态测试等；

边界扫描机制提供了一种完整的、标准化的可测试性设计方法。自从边界扫描标准出现以来，市场上支持边界扫描机制及设计开发软件与日俱增，其应用越来越广泛。需要指出的是，边界扫描机制适用于集成度比较高的单元，对于集成度较低的而言，采用结构化可测试性设计方法有可能会得到更为优化的设计结。