软件工程导论第八章-软件质量与质量保证

第八章软件质量与质量保证8.1软件质量的定义8.2影响软件质量的因素8.3软件质量保证策略8.4软件质量保证活动8.5软件评审 8.6软件质量保证的标准8.7结构化程序的测试8.8面向对象的软件测试8.9测试计划与测试分析报告8.10软件维护 8.1软件质量的定义8.1软件质量的定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。

软件质量是各种特性的复杂组合，随着应用的不同而异，随着用户提出的质量要求不同而不同。

8.2影响软件质量的因素8.2影响软件质量的因素1．影响软件质量的主要因素（1）正确性：系统满足规格说明和用户目标的程度，即在预定环境下能正确地完成预期功能的程度。（2）健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度。（3）效率：为了完成预定的功能，系统需要的计算资源的多少。（4）安全性：对未经授权的人使用软件或数据的企图，系统能够控制的程度。8.2影响软件质量的因素1．影响软件质量的主要因素（5）可用性：系统在完成预定应该完成的功能时令人满意的程度。（6）风险：按预定的成本和进度把系统开发出来，并且受用户所满意的概率。（7）可理解性：理解和使用该系统的容易程度。（8）可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小。（9）适应性：修改或改进正在运行的系统需要的工作量的多少。8.2影响软件质量的因素1．影响软件质量的主要因素（10）可测试性：软件容易测试的程度。（11）可移植性：把程序从一种硬件配置和软件系统环境转移到另一种配置和环境时，需要的工作量的多少。有一种定量度量的方法是：用原来程序设计和调试的成本除移植时需用的费用。（12）可再用性：在其他应用中该程序可以被再次使用的程度。（13）互运行性：把该系统和另一个系统结合起来的工作量的多少。8.2影响软件质量的因素2．软件质量评价应遵守的原则（1）应强调软件总体质量（低成本高质量），而不应片面强调软件正确性，忽略其可维护性与可靠性、可用性与效率等。（2）应在软件工程化生产的整个周期的各个阶段都注意软件的质量，而不能只在软件最终产品验收时注意质量。（3）应制定软件质量标准，定量地评价软件质量，使软件产品评价执行评测结合，以测为主的科学方法。

8.3软件质量保证策略8.3软件质量保证策略1．审查 审查就是在软件生命周期每个阶段结束之前，都正式使用结束标准对该阶段生产出的软件配置成分进行严格的技术审查。8.3软件质量保证策略审查过程的步骤如下：（1）计划：组织审查组，分发材料，安排日程等。（2）概貌介绍：当项目复杂庞大时，可由作者介绍概况。（3）准备：评审员阅读材料取得有关项目的知识。（4）评审会：目的是发现和记录错误。（5）返工：作者修正已经发现的问题。（6）复查：判断返工是否真正解决了问题。8.3软件质量保证策略2．复查和管理复审复查即是检查已有的材料，以确定某阶段的工作是否能够开始或继续。每个阶段开始时的复查，是为了肯定前一个阶段结束时的审查，已经具备了开始当前阶段工作所必需的材料。管理复审通常指向开发组织或使用部门的管理人员，提供有关项目的总体状况、成本和进度等方面的情况，以便从管理角度对开发工作进行审查。8.3软件质量保证策略3．测试 测试就是用已知的输入在已知环境中动态地运行系统或系统的部件。如果测试结果和预期的结果不一致，则表明系统中可能出现了错误。8.3软件质量保证策略测试过程中产生的基本文档如下：(1)测试计划：通常包括单元测试和集成测试，确定测试范围、方法和需要的资源等。(2)测试过程：详细描述和每个测试方案有关的测试步骤和数据，包括测试数据及预期的结果。(3)测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且通过调试解决所发现的问题。8.4软件质量保证活动8.4软件质量保证活动1.验证与确认 验证是为了确定开发时期中某一阶段的产品是否达到了阶段对它的需求，确认则是在整个开发结束时对所开发的软件能否满足软件需求的总评价。

8.4软件质量保证活动2.开发时期的配置管理虽然维护时期坚持配置管理十分重要。但事实上，对配置的控制从计划时期就开始了，一直延续到生存周期结束、软件停止使用后才终止。软件配置包括生存期中各个阶段产生的文档和程序。这些文档或程序是随着软件的开发进程逐步产生的，所以也称为阶段产品

8.5软件评审

8.5.1设计质量的评审内容

8.5.2程序质量的评审内容8.5软件评审

8.5.1设计质量的评审内容 设计质量的评审对象是在需求分析阶段产生的软件需求规格说明、数据要求规格说明，在软件概要设计阶段产生的软件概要设计说明等。8.5软件评审

8.5.1设计质量的评审内容1．软件的规格说明2．可靠性 可靠性措施应能失效发生

3保密措施实现4.操作特性实施5.性能实现6.可修改性7.可扩充性8.互换性 互换性是指当软件功能扩充之后，其已有功能还能照原样使用的特性。8.5软件评审

8.5.1设计质量的评审内容9.可移植性 可移植性是指当把软件移植到不同的运行环境时，不需改变其规格就能照原样工作的特性。10.可测试性 可测试性是为保证软件质量，有效地进行充分、全面的测试的特性。

11.复用性 复用性包含可移植性及功能上通用性等

12.互连性 与其他软件有共同的接口及该接口部分是模块化的，容易改变的。8.5软件评审

8.5.2程序质量的评审内容1.软件的结构(1)功能结构(2)功能的通用性(3)模块的层次(4)模块结构(5)处理过程的结构8.5软件评审

8.5.2程序质量的评审内容2.与运行环境的接口(1)与其他软件的接口(2)与硬件的接口(3)与用户的接口(4)运行环境变更时的影响范围8.6软件质量保证的标准8.6软件质量保证的标准1.ISO对质量保证系统的方法ISO9000质量保证模型将一个企业视为一个互联过程的网络。为了使质量系统符合ISO标准，这些过程必须与标准中给出的区域对应，并且必须按照描述进行文档化和实现。ISO9000以一般术语描述了一个质量保证系统的要素。这些要素包括用于实现质量计划、质量控制、质量保证和质量改进所需的组织结构、规程、过程和资源。8.6软件质量保证的标准2.ISO9001标准（1）管理责任（2）质量系统（3）合同复审（4）设计控制（5）文档和数据控制（6）采购（7）对客户提供的产品的控制8.6软件质量保证的标准2.ISO9001标准（8）产品标识和可跟踪性（9）过程控制（10）审查和测试（11）审查、度量和测试设备的控制（12）审查和测试状态（13）对不符合标准产品的控制（14）改正和预防行动8.6软件质量保证的标准2.ISO9001标准（15）处理、存储、包装、保存和交付（16）质量记录的控制（17）内部质量审计（18）培训（19）服务（20）统计技术8.7结构化程序的测试

8.7.1软件测试的目的

8.7.2软件测试的原则

8.7.3软件测试的对象

8.7.4软件测试的基本过程8.7结构化程序的测试

8.7.1软件测试的目的1．软件测试的目的（1）软件测试是确认软件的质量，其一方面是确认软件做了所期望的事情，另一方面是确认软件以正确的方式来做了这个事件。（2）软件测试是提供信息，比如提供给开发人员或项目经理的反馈信息，为风险评估所准备的信息。8.7结构化程序的测试

8.7.1软件测试的目的1．软件测试的目的（3）软件测试不仅是在测试软件产品本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，则说明此软件开发过程很可能是有缺陷的。因此这个目的是保证整个软件开发过程的高质量。8.7结构化程序的测试

8.7.1软件测试的目的2．软件质量（1）在正确的时间用正确的的方法把一个工作做正确。（2）符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。（3）质量本身就是软件达到了最开始所设定的要求，而代码设计的技巧并不代表软件的高质量。8.7结构化程序的测试

8.7.1软件测试的目的2．软件质量（4）质量也代表着它符合客户的需要。作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户如何使用这个产品，使用过程中将遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了。8.7结构化程序的测试

8.7.2软件测试的原则从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品；从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求。

8.7结构化程序的测试

8.7.2软件测试的原则1．应当尽早测试和不断的测试。2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况要制造极端状态和意外状态，例如网络异常中断、电源断电等情况。

4．一定要注意测试中的错误集中发生现象，这与程序员的编程水平和习惯有很大的关系。8.7结构化程序的测试

8.7.2软件测试的原则

5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现。

8．妥善保存测试过程文档有重要意义，因为测试的重现性往往要靠测试文档。8.7结构化程序的测试

8.7.3软件测试的对象

软件测试并不等同程序测试。软件测试应该贯穿于软件定义与开发的整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。

8.7结构化程序的测试

8.7.4软件测试的基本过程软件测试过程通常包括以下基本的测试活动

:1．拟定软件测试计划。2．编制软件测试大纲。3．设计和生成测试用例。4．实施测试。5．生成软件问题报告。8.7结构化程序的测试

8.7.5软件测试技术

1．静态分析技术 不执行被测软件，可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。8.7结构化程序的测试

8.7.5软件测试技术

1．静态分析技术(1)结构检查是手工分析技术，由一组人员对程序设计，需求分析，编码，测试工作进行评议，虚拟执行程序，评议中作错误检验。8.7结构化程序的测试

8.7.5软件测试技术

1．静态分析技术(2)流图分析是通过分析程序流程图的代码结构，来查程序的语法错误信息，语句中标识符引用状况，予程序和函数调用状况，变量是否赋初值，定义而未使用的变量，未说明或无用的标号，无法执行到的代码段。8.7结构化程序的测试

8.7.5软件测试技术

1．静态分析技术(3)符号执行是一种符号化定义数据，并为程序每条路径给出符号表达式，对特定路径输入符号，经处理输出符号，从而判断程序行为是否错误，达到分析错误的目的。8.7结构化程序的测试

8.7.5软件测试技术2．动态测试技术 当把程序作为一个函数，输入的全体称为函数的定义域，输出的全体称为函数的值域，函数则描述了输入的定义域与输出值域的关系。

8.7结构化程序的测试

8.7.5软件测试技术2．动态测试技术动态测试的过程为：

(1)选取定义域中的有效值，或定义域外无效值。(2)对已选取值决定预期的结果。(3)用选取值执行程序。(4)观察程序行为，记录执行结果。(5)将(4)的结果与(2)的结果相比较，不相同则表明程序有错。8.7结构化程序的测试

8.7.5软件测试技术

3．黑盒测试和白盒测试(1）黑盒测试法：又称为功能测试。它把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程。(2）白盒测试法：它的前提是可以把程序看成装在一个透明的白盒子里，也就是完全了解程序的结构和处理过程。8.7结构化程序的测试

8.7.6设计测试方案概述设计测试方案是测试阶段的关键技术问题。测试方案包括预定要测试的功能、应该输入的测试数据和预期的结果，其中最困难的问题是设计测试用的输入数据，即测试用例。设计测试方案的基本目标是确定一组最可能发现某个错误或某类错误的测试数据。

8.7结构化程序的测试

8.7.6设计测试方案

1．白盒法(1)语句覆盖(2)判定覆盖(3)条件覆盖(4)判定／条件覆盖(5)条件组合覆盖(6)路径覆盖8.7结构化程序的测试

8.7.6设计测试方案

2．黑盒法(1)等价划分 使用等价划分法设计测试方案首先需要划分输入数据的等价类，为此需要研究程序的功能说明，从而确定输入数据的有效等价类和无效等价类。8.7结构化程序的测试

8.7.6设计测试方案

2．黑盒法(2)边界值分析 使用边界值分析方法设计测试方案首先应该确定边界情况，这需要经验和创造性，对于输入等价类和输出等价类的边界确定，就是应该着重测试的程序边界情况。

8.7结构化程序的测试

8.7.7测试的步骤

软件测试的步骤:（1）单元测试（2）集成测试（3）确认测试（4）系统测试（5）验收测试8.7结构化程序的测试

8.7.8软件纠错技术 根据测试出错误的外因分析找到内部原因并加以改正的代码执行与人工活动称为纠错。

8.7结构化程序的测试

8.7.8软件纠错技术1.纠错策略方法（1）强力法（2）跟踪法（3）演绎法（4）归纳法 （5）测试纠错法（6）试凑法（7）回归测试（8）对分查找法8.8面向对象的软件测试

8.8.1面向对象分析

和面向对象设计的模型测试

8.8.2面向对象的测试策略

8.8.3面向对象软件测试集设计8.8面向对象的软件测试

8.8.1面向对象分析和面向对象设计 的模型测试1.面向对象分析和设计模型的正确性 用于表示分析和设计模型的符号体系和语法将是与为项目选定的特定分析和设计方法联系的。因此，不仅考虑语法正确性和符号体系是否合适使用，而且对每个模型复审以保证保持合适的建模约定。8.8面向对象的软件测试

8.8.1面向对象分析和面向对象设计 的模型测试2．面向对象分析和设计模型的一致性 对OOA和OOD模型的一致性判断可以通过考虑模型中实体间的关系，不一致的模型在某一部分有表示，但未在模型的其他部分正确地反映。8.8面向对象的软件测试

8.8.2面向对象的测试策略1．面向对象的单元测试 对OO软件的类测试等价于传统软件的单元测试。和传统软件的单元测试不一样，OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的

8.8面向对象的软件测试

8.8.2面向对象的测试策略2．面向对象的组装测试 对OO软件的集成测试有两种不同策略，第一种称为基于线程的测试，集成对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副作用。8.8面向对象的软件测试

8.8.2面向对象的测试策略2．面向对象的组装测试 第二种称为基于使用的测试，通过测试那些几乎不使用服务器类的类（称为独立类）而开始构造系统，在独立类测试完成后，下一层使用独立类的类（称为依赖类）被测试。这个依赖类层次的测试序列一直持续到构造完整系统。8.8面向对象的软件测试

8.8.2面向对象的测试策略3．面向对象的确认测试传统的黑盒测试方法可被用于有效性测试，此外，测试集可以从对象/行为模型和作为OOA的一部分的事件流图中导出。传统的黑盒测试方法可被用于有效性测试，此外，测试集可以从对象/行为模型和作为OOA的一部分的事件流图中导出。8.8面向对象的软件测试

8.8.3面向对象软件测试集设计1．面向对象测试集设计的概念 OO测试集设计的方法如下：（1）每个测试集应该被惟一标识，并且和将被测试的类显式地相关联；（2）应该陈述测试的目的；（3）对每个测试应该开发一组测试步骤

8.8面向对象的软件测试

8.8.3面向对象软件测试集设计2．传统测试集设计方法的适用性白盒测试方法可用于对为类定义的操作的测试，基本路径、循环测试或数据流技术可以帮助保证已经测试了操作中的每一条语句，然而，很多类操作的简洁结构导致把用白盒测试的工作量用于类级别的测试会更好。黑盒测试方法就像对传统软件工程方法开发的系统和对OO系统同样适用的，测试集可以为黑盒及基于状态的测试设计提供有用的输入。8.8面向对象的软件测试

8.8.3面向对象软件测试集设计3.基于故障的测试 在OO系统中基于故障的测试的目标是设计最有可能发现似乎可能的故障的测试。由于产品或系统必须符合客户需求，因此，完成基于故障的测试所需的初步计划是从分析模型开始。测试员查找似乎可能的故障，为了确定是否存在这些故障，设计测试集以测试设计或代码。8.8面向对象的软件测试

8.8.3面向对象软件测试集设计4．面向对象编程对测试的影响（1）某些类型的故障变得几乎不可能（不值得去测试）（2）某些类型的故障变得更加可能（值得进行测试）（3）出现某些新的故障类型（4）当调用一个操作时，很难确切知道执行什么代码，即可能属于很多类之一。

8.8面向对象的软件测试

8.8.3面向对象软件测试集设计5．测试外部结构和内部结构（1）外部结构 外部结构指OO程序的外部可观察的结构，即对终端用户立即可见的结构。

（2）内部结构 内部结构指OO程序的内部技术细节，即通过检查设计和/或代码而理解的结构。

8.9测试计划与测试分析报告8.9测试计划与测试分析报告测试计划可细化为测试计划、测试设计说明、测试用例说明和测试规格说明；测试分析报告可细化为测试项传递报告、测试日志、测试事件报告和测试总结报告。8.10软件维护

8.10.1软件维护分类与特点

8.10.2软件维护步骤

8.10.3软件的可维护性

8.10.4软件维护的副作用

8.10.5逆向工程和再生工程8.10软件维护

8.10.1软件维护分类与特点1.软件维护的原因(1)改正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷。(2)在软件使用过程中因数据环境发生变化或处理环境发生变化，需要修改软件以适应这种变化。(3)用户和数据处理人员在使用时常提出改进现有功能、增加新的功能及改善总体性能的要求，为了满足这些要求，就需要修改软件并把这些要求纳入到软件之中。8.10软件维护

8.10.1软件维护分类与特点2.维护的分类按维护性质不同，软件维护可分为：改正性维护、适应性维护、完善性维护和预防性维护等。8.10软件维护

8.10.1软件维护分类与特点3.维护的特点(1)结构化维护与非结构化维护(2)维护的代价(3)维护的问题 与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法的缺点。

8.10软件维护

8.10.2软件维护步骤1．维护步骤（1）分析和理解程序（2）修改程序（3）详细地分析要修改的模块和数据结 构的内部细节，设计修改计划，标 明新逻辑及要改动的现有逻辑。（4）向用户提供回避措施。

（5）修改代码以适应变化

（6）重新验证程序8.10软件维护

8.10.2软件维护步骤2．维护组织 每个维护申请通过维护管理员转告给系统管理员，系统管理员一般都是对程序特别熟悉的技术人员，他们对维护申请及可能引起的软件修改进行评估，并向修改控制决策机构（一个或一组管理者）报告，由它最后确定是否采取行动。

8.10软件维护

8.10.3软件的可维护性

1．影响可维护性的因素（1）是否拥有一组训练有素的软件人员；（2）系统结构是否可理解；（3）是否使用标准的程序设计语言；（4）是否使用标准的操作系统；（5）文档的结构是否标准化；（6）测试用例是否合适；（7）是否已有嵌入系统的调试工具；（8）是否有一台计算机可用于维护。8.10软件维护

8.10.3软件的可维护性

2．量化的测度（1）发现问题所用的时间；（2）收集维护工具使用的时间；（3）分析问题所需时间；（4）形成修改说明书所用时间；（5）纠错（或修改）所用时间；（6）局部测试所用时间；（7）整体测试所用时间；（8）维护复审所用时间；（9）完全恢复所用时间。8.10软件维护

8.10.3软件的可维护性

3．保证可维护性的复审 在软件工程每一阶段的复审中，可维护性都是重要的指标。需求分析阶段的复审设计阶段的复审代码复审配置复审8.10软件维护

8.10.4软