修改部分对其它部分有无不良影响(副作用)? 对软件进行修改,常常会引发别的问题,因此有必要检查修改的影响范围 ②计算机确认 在充分进行了以上确认的基础上,要用计算机对修改程序进行确认测试: 确认测试顺序:先对修改部分进行测试,然后隔离修改部分,测试程序的未修改部分, 最后再把它们集成起来进行测试。这种测试称为回归测试 准备标准的测试用例 充分利用软件工具帮助重新验证过程。 在重新确认过程中,需邀请用户参加。 ③维护后的验收—在交付新软件之前,维护主管部门要检验: 全部文档是否完备,并已更新 ·所有测试用例和测试结果已经正确记载 记录软件配置所有副本的工作已经完成 维护工序和责任已经确定。 从维护角度来看所需测试种类如: ◆对修改事务的测试 ◆对修改程序的测试 操作过程的测试 ◆应用系统运用过程的测试 ◆使用过程的测试 ◇系统各部分之间接口的测试 ◆作业控制语言的测试 ◇与系统软件接口的测试 ◇软件系统之间接口的测试:◆安全性测试 ◆后备/恢复过程的测试 5.软件可维护性 (1)软件可维护性的定义 所谓软件可维护性,是指纠正软件系统出现的错误和缺陷,以及为满足新的要求进行修 改、扩充或压缩的容易程度。可维护性、可使用性、可靠性是衡量软件质量的几个主要质量 特性,也是用户十分关心的几个方面。可惜的是影响软件质量的这些重要因素,目前尚没有 对它们定量度量的普遍适用的方法。但是就它们的概念和内涵来说则是很明确的。 软件的可维护性是软件开发阶段各个时期的关键目标 目前广泛使用的是用如下的七个特性来衡量程序的可维护性。而且对于不同类型的维 护,这七种特性的侧重点也不相同。表72显示了在各类维护中应侧重哪些特性。图中的“O” 表示需要的特性。 表72在各类维护中的侧重点 改正性维护 适应性维护 可理解性 可测试性 可修改性 可靠性 √√√ 可移植性 上面所列举的这些质量特性通常体现在软件产品的许多方面,为使每一个质量特性都达
11 ▪ 修改部分对其它部分有无不良影响(副作用)? 对软件进行修改，常常会引发别的问题，因此有必要检查修改的影响范围。 ② 计算机确认 在充分进行了以上确认的基础上，要用计算机对修改程序进行确认测试： ▪ 确认测试顺序：先对修改部分进行测试，然后隔离修改部分，测试程序的未修改部分， 最后再把它们集成起来进行测试。这种测试称为回归测试。 ▪ 准备标准的测试用例。 ▪ 充分利用软件工具帮助重新验证过程。 ▪ 在重新确认过程中，需邀请用户参加。 ③ 维护后的验收──在交付新软件之前，维护主管部门要检验： ▪ 全部文档是否完备，并已更新； ▪ 所有测试用例和测试结果已经正确记载； ▪ 记录软件配置所有副本的工作已经完成； ▪ 维护工序和责任已经确定。 从维护角度来看所需测试种类如： 对修改事务的测试； 对修改程序的测试； 操作过程的测试； 应用系统运用过程的测试； 使用过程的测试； 系统各部分之间接口的测试； 作业控制语言的测试； 与系统软件接口的测试； 软件系统之间接口的测试； 安全性测试； 后备／恢复过程的测试。 5. 软件可维护性 (1) 软件可维护性的定义 所谓软件可维护性，是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修 改、扩充或压缩的容易程度。可维护性、可使用性、可靠性是衡量软件质量的几个主要质量 特性，也是用户十分关心的几个方面。可惜的是影响软件质量的这些重要因素，目前尚没有 对它们定量度量的普遍适用的方法。但是就它们的概念和内涵来说则是很明确的。 软件的可维护性是软件开发阶段各个时期的关键目标。 目前广泛使用的是用如下的七个特性来衡量程序的可维护性。而且对于不同类型的维 护，这七种特性的侧重点也不相同。表 7.2 显示了在各类维护中应侧重哪些特性。图中的“ ” 表示需要的特性。 表 7.2 在各类维护中的侧重点 改正性维护 适应性维护 完善性维护 可理解性 可测试性 可修改性 可 靠 性 可移植性 可使用性 效 率 上面所列举的这些质量特性通常体现在软件产品的许多方面，为使每一个质量特性都达
到预定的要求,需要在软件开发的各个阶段采取相应的措施加以保证。因此,软件的可维护 性是产品投入运行以前各阶段面向上述各质量特性要求进行开发的最终结果 (2)可维护性的度量 人们一直期望对软件的可维护性做出定量度量,但要做到这一点并不容易。许多研究工 作集中在这个方面,形成了一个引人注目的学科—软件度量学。下面我们介绍度量一个可 维护的程序的七种特性时常用的方法。这就是质量检查表、质量测试、质量标准。 质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。评价者针对检查表上 的每一个问题,依据自己的定性判断,回答“Yes”或者“No”。质量测试与质量标准则用于 定量分析和评价程序的质量。由于许多质量特性是相互抵触的,要考虑几种不同的度量标准 相应地去度量不同的质量特性 ①可理解性 可理解性表明人们通过阅读源代码和相关文档,了解程序功能及其如何运行的容易程 度。一个可理解的程序主要应具备以下一些特性:模块化(模块结构良好、功能完整、简明) 风格一致性(代码风格及设计风格的一致性),不使用令人捉摸不定或含糊不清的代码,使用 有意义的数据名和过程名,结构化,完整性(对输入数据进行完整性检查)等。 用于可理解性度量的检查表的内容有:程序是否模块化?结构是否良好?每个模块是否 有注释块,说明程序的功能、主要变量的用途及取值、所有调用它的模块、以及它调用的所 有模块?在模块中是否有其它有用的注释内容,包括输入输出、精确度检査、限制范围和约 束条件、假设、错误信息、程序履历等?在整个程序中缩进和间隔的使用风格是否一致?在 程序中每一个变量,过程是否具有单一的有意义的名字?程序是否体现了设计思想?程序是 否限制使用一般系统中没有的内部函数过程与子程序?是否能通过建立公共模块或子程序来 避免多余的代码?所有变量是否是必不可少的?是否避免了把程序分解成过多的模块、函数 或子程序?程序是否避免了很难理解的、非标准的语言特性? 对于可理解性,可以使用一种叫做“90-10测试”的方法来衡量。即把一份被测试的源 程序清单拿给一位有经验的程序员阅读10分钟,然后把这个源程序清单拿开,让这位程序员 凭自己的理解和记忆,写出该程序的90%。如果程序员真的写出来了,则认为这个程序具有 可理解性,否则这个要重新编写 ②可靠性 可靠性表明一个程序按照用户的要求和设计目标,在给定的一段时间内正确执行的概 率。关于可靠性,度量的标准主要有:平均失效间隔时间MTTF( Mean time to failure)、平 均修复时间MIIR( Mean Time To Repair error)、有效性A(=MIBD/(MIBD+MDT))。 度量可靠性的方法,主要有两类: ■根据程序错误统计数字,进行可靠性预测。常用方法是利用一些可靠性模型,根据程 序测试时发现并排除的错误数预测平均失效间隔时间MITF ■根据程序复杂性,预测软件可靠性。用程序复杂性预测可靠性,前提条件是可靠性与 复杂性有关。因此可用复杂性预测出错率。程序复杂性度量标准可用于预测哪些模块最可能 发生错误,以及可能出现的错误类型。了解了错误类型及它们在哪里可能出现,就能更快地 查出和纠正更多的错误,提高可靠性。 用于可靠性度量的检查表的内容有:程序中对可能出现的没有定义的数学运算是否做了 检查?如除以“0”。循环终止和多重转换变址参数的范围,是否在使用前做了测试?下标的 范围是否在使用前测试过?是否包括错误恢复和再启动过程?所有数值方法是否足够准确? 输入的数据是否检査过?测试结果是否令人满意?大多数执行路径在测试过程中是否都已执 行过?对最复杂的模块和最复杂的模块接口,在测试过程中是否集中做过测试?测试是否包 括正常的、特殊的和非正常的测试用例?程序测试中除了假设数据外,是否还用了实际数据?
12 到预定的要求，需要在软件开发的各个阶段采取相应的措施加以保证。因此，软件的可维护 性是产品投入运行以前各阶段面向上述各质量特性要求进行开发的最终结果。 (2) 可维护性的度量 人们一直期望对软件的可维护性做出定量度量，但要做到这一点并不容易。许多研究工 作集中在这个方面，形成了一个引人注目的学科──软件度量学。下面我们介绍度量一个可 维护的程序的七种特性时常用的方法。这就是质量检查表、质量测试、质量标准。 质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。评价者针对检查表上 的每一个问题，依据自己的定性判断，回答“Yes”或者“No”。质量测试与质量标准则用于 定量分析和评价程序的质量。由于许多质量特性是相互抵触的，要考虑几种不同的度量标准， 相应地去度量不同的质量特性。 ① 可理解性 可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程 度。一个可理解的程序主要应具备以下一些特性：模块化(模块结构良好、功能完整、简明)， 风格一致性(代码风格及设计风格的一致性)，不使用令人捉摸不定或含糊不清的代码，使用 有意义的数据名和过程名，结构化，完整性(对输入数据进行完整性检查)等。 用于可理解性度量的检查表的内容有：程序是否模块化? 结构是否良好？每个模块是否 有注释块，说明程序的功能、主要变量的用途及取值、所有调用它的模块、以及它调用的所 有模块？在模块中是否有其它有用的注释内容，包括输入输出、精确度检查、限制范围和约 束条件、假设、错误信息、程序履历等？在整个程序中缩进和间隔的使用风格是否一致？在 程序中每一个变量，过程是否具有单一的有意义的名字？程序是否体现了设计思想？程序是 否限制使用一般系统中没有的内部函数过程与子程序？是否能通过建立公共模块或子程序来 避免多余的代码？所有变量是否是必不可少的？是否避免了把程序分解成过多的模块、函数 或子程序？程序是否避免了很难理解的、非标准的语言特性？ 对于可理解性，可以使用一种叫做“90－10 测试”的方法来衡量。即把一份被测试的源 程序清单拿给一位有经验的程序员阅读 10 分钟，然后把这个源程序清单拿开，让这位程序员 凭自己的理解和记忆，写出该程序的 90％。如果程序员真的写出来了，则认为这个程序具有 可理解性，否则这个要重新编写。 ② 可靠性 可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概 率。关于可靠性，度量的标准主要有：平均失效间隔时间 MTTF(Mean Time To Failure）、平 均修复时间 MTTR(Mean Time To Repair error)、有效性 A( = MTBD∕(MTBD+MDT))。 度量可靠性的方法，主要有两类： ▪ 根据程序错误统计数字，进行可靠性预测。常用方法是利用一些可靠性模型，根据程 序测试时发现并排除的错误数预测平均失效间隔时间 MTTF。 ▪ 根据程序复杂性，预测软件可靠性。用程序复杂性预测可靠性，前提条件是可靠性与 复杂性有关。因此可用复杂性预测出错率。程序复杂性度量标准可用于预测哪些模块最可能 发生错误，以及可能出现的错误类型。了解了错误类型及它们在哪里可能出现，就能更快地 查出和纠正更多的错误，提高可靠性。 用于可靠性度量的检查表的内容有：程序中对可能出现的没有定义的数学运算是否做了 检查？如除以“0”。循环终止和多重转换变址参数的范围，是否在使用前做了测试？下标的 范围是否在使用前测试过？是否包括错误恢复和再启动过程？所有数值方法是否足够准确？ 输入的数据是否检查过？测试结果是否令人满意？大多数执行路径在测试过程中是否都已执 行过？对最复杂的模块和最复杂的模块接口，在测试过程中是否集中做过测试？测试是否包 括正常的、特殊的和非正常的测试用例？程序测试中除了假设数据外，是否还用了实际数据？