第12章 软件质量保证.docx
《第12章 软件质量保证.docx》由会员分享，可在线阅读，更多相关《第12章 软件质量保证.docx（42页珍藏版）》请在冰豆网上搜索。
第12章软件质量保证
第十二章软件质量保证
12.1软件质量概述
产生软件危机的根源是多方面的，如软件生产率低下、软件需求急剧增长，但是，软件质量难以控制和提高也是一个重要的原因。
计算机科学与技术的迅速发展和应用范围日益广泛，计算机软件的重要性与日俱增。
人们对软件质量要求越来越高，对软件的质量控制和质量管理越来越重视。
软件产业的迅猛发展急需软件工程方法、技术的支持，软件工程的理论也随着软件产业的实践而逐渐丰富。
软件工程思想的应用，将使软件产业呈现工程化、专业化、系列化、产品化和标准化等特征。
随之而来的是如何更科学地对软件质量的控制、评价。
软件质量是降低软件开发成本的基本保障。
提高软件质量是软件企业竞争的需要，是软件企业生存的基础，也是其进入国际市场的基本条件。
软件产品质量保证是软件工程学科的一部分。
软件质量评价和故障分析是软件工程中较为困难的研究领域，系统地处理软件质量问题、客观地评价软件产品质量不论对软件产品用户，还是对软件开发商都是十分重要的。
不过，由于软件本身的复杂性和软件技术发展迅速等原因，如何系统地、科学地评价和控制软件的质量是几十年来一直困扰着人们的难题。
12.1.1软件质量的定义
按照ANSI/IEEE1983年的标准，软件质量定义为“与软件产品满足需求所规定的和隐含的能力有关的特征和特性的全体”。
具体包括：
软件产品中所能满足用户给定需求的全部特性的集合；
软件具有所期望的各种属性组合的程度；
用户主观得出的软件是否满足其综合期望的程度；
决定所用软件在使用中将满足其综合期望程度的软件合成特性。
这一定义重点强调了软件的特性或特征，强调了这些特性或特征与软件需求的吻合程度以及对它们的综合评价值。
一般而言，不同性质和用途的软件，会有不同的特征集合和质量要求。
如实时控制软件和大型联机事务处理软件对于软件的可靠性要求很高。
而常规的办公事务软件及管理信息系统对于易用性和可移植性要求则比较高。
但从各类软件综合起来看，可以列出下列7个主要特征：
功能性：
指软件所实现的功能达到或满足用户需求和设计规范的程度。
这里所要强调的是，用户需求不仅包括显性陈述的需求内容，还应包括隐含的需求。
可靠性：
指软件在指定条件下和特定时间段内，维持其正常性能水准的能力的程度。
易使用性：
指用户为使用一个软件产品所付出的学习努力以及其它代价的程度。
效率：
指在规定的条件下，软件功能与所占用资源之间的比值关系。
可维护性：
当发现错误、运行环境改变或客户需求改变时，程序可被修改的难易程度。
可移植性：
指将软件从一种环境移植到另一种环境的难易程度。
质量管理：
指在整个软件生命周期中，实施质量监督和质量控制的配套程度。
从用户角度来评价软件质量，他们主要关心的是：
所需求的功能在软件中是否已经被实现？
软件是否可靠？
软件的效率如何？
软件是否方便使用？
将软件移植到另一个环境中去是否方便？
改变或增添软件功能是否方便？
从软件开发者角度来考察软件质量，他们所关心的重点和用户的目标一致，但在轻重缓急上也有一定的差别。
为了保障软件产品的质量，提高软件产品的生产效率，软件开发者一般会更关心软件的结构和软件的可维护性，关心在开发的不同阶段对软件中间结果检测和结果分析是否方便。
从管理者角度来看，他们通常更注重软件的整体质量，而不是某一个具体的质量特征。
他们会根据软件应用的类型和商务需要为不同的特征分配权值，同时还要考虑成本、资源消耗、开发周期的限制等等，在个各个管理要素和质量改进需求之间寻求平衡。
软件质量、投资回报和开发时间的组合作用决定了软件生产率。
12.1.2软件质量评价
就一般意义而言，“质量”为“事物的一个特性或属性”。
作为一个物品的属性，质量涉及到一些可测量的特性，即在某些方面能够与已知标准进行比较的属性。
例如长度、颜色、电特性、延展性等。
但是，软件作为一种智力产品和逻辑系统，对其属性的刻画要困难得多。
程序有一些性质是可以测量的。
这些性质包括诸如回路复杂性、内聚性、功能点数、代码行数等众多的其它性质。
当我们基于可测量特性检查一个事物时，会遇到两种质量问题：
设计质量和一致性质量。
设计质量涉及到设计者所指明的产品特性。
材料、公差和性能规范的级别都与设计质量有关。
如果产品根据指明的规范制造，如高级别的材料用紧密公差和高性能规范指明时，它的设计质量就得以提高。
一致性质量是指设计规范在以后的生产制造过程中被遵守的程度。
一致性程度越高，一致性质量就越高。
在软件开发中设计质量包括需求分析、规范说明和系统设计。
一致性质量主要集中在实现上。
如果实现遵从设计，并且结果系统满足它的需求和性能目标，就可以获得较高的一致性质量。
对软件质量的评价不仅包括设计质量，也包括一致性质量。
12.1.3软件开发中的质量控制
质量控制是指软件开发周期内所进行的一系列审查、评价、测量等活动，其目的是使每个过程产品能够满足所提出的要求。
质量控制包括对产品创造过程的反馈循环。
当产品不满足它们的规范说明时，测量和反馈的结合使得我们能调整产品的创造过程。
质量控制活动的形式大致可以分为自动、手工和自动工具与人工交互相结合三种。
关于质量控制的一个关键概念是，所有的过程产品具有可定义的、可测量的规范说明。
根据这个规范说明，可以通过比较、计算等方法产生每个过程产品的有关质量控制的输出信息，并将输出信息反馈给有关的过程。
这种反馈循环对于缺陷的最小化来说是基本的保证。
12.2软件质量保证
软件质量保证（SQA）是一个复杂的系统，它根据一系列的标准，采用一定的方法、技术和工具，处理和调整软件产品各个特性之间的相互关系，以确保软件产品达到其应该达到的质量水平。
软件质量保证应用于整个软件过程的保护活动，包括：
1）质量管理方法；2）有效的软件工程技术（方法和工具）；3）应用于整个软件过程的形式化技术评论；4）多等级测试策略；5）软件文档以及对软件进行改变和维护的控制和约束；6）确保遵照软件开发标准的过程；7）测量和报告机制。
软件质量保证包括管理的审核和报告功能。
质量保证的目的是以有关产品质量的基本数据为依据进行质量管理，从而保证产品质量不断地朝着其质量目标迈进。
质量保证活动提供大量有关质量的基本数据，不过，根据这些数据所指出的质量问题必须通过质量管理来解决。
软件质量保证的任务：
1）确保需求定义的正确性、一致性、有效性和完整性。
2）应用先进的开发技术、方法和工具，提高软件开发的工程能力。
3）充分利用和提高软件复用。
4）重视对软件开发各个环节的有效组织和协调。
5）充分发挥个人的开发和协作能力，以提高整个团队的开发能力。
6）提高软件工程项目的管理能力。
为了更好地协调好软件质量与软件生产率、软件开发成本之间的关系，保证软件达到一定的质量水准，必须遵守一定的软件质量保证原则。
软件质量保证原则：
1）在开始制定项目计划时，充分考虑用户（或客户）的要求，确定实用的质量特征。
2）详细制定质量计划。
3）在对开发过程进行质量评估的基础上，检查质量测试的结果以发现与质量计划的偏差，确定适当的修正方案。
4）对阶段性成果进行各种质量检查、校对等评审活动。
5）不断地优化和完善质量计划。
6）尽早发现并及时改正错误和缺陷。
7）由独立的测试小组进行质量测试。
12.2.1SQA计划
软件质量保证计划是一套计划和检查质量保证的方法，是一种用以质量控制的书面保证，包括为一个软件项目所选择的所有质量保证措施。
在IEEE标准730-1984中，给出了一个国际公认的关于软件质量保证计划的详细要求，涉及到11个方面的内容：
1）软件质量保证计划的用途。
2）参考文献。
3）软件质量保证计划的管理。
4）软件质量文档。
5）适用的标准、规范和约定。
6）评审和审计。
7）软件配置管理。
8）存在的问题和修高报告。
9）软件工程。
10）编码控制。
11）其它内容。
以上每个方面又包括一些具体的项目。
1）软件质量保证计划的用途
质量计划所涉及的软件产品。
软件的用途。
软件应用的重要性。
为何要建立软件质量保证计划。
内部和外部需求是否是计划所需要的。
软件质量保证计划的基础是什么？
如所采用的标准、内部和外部文档等。
可能产生的基本偏差及其原因和说明。
2）参考文件
包括所有相关的参考文档，需要表明这些文档的出处和负责人。
3）软件质量保证计划的管理
这一部分用以说明开发过程的组织、任务和责任。
其中组织结构最好使用带有附加注释的组织结构流程图表示。
具体内容包括：
对负责执行软件质量保证任务的每个小组的说明。
职权分配
负责检测产品交付的小组
负责检查质量保证计划的小组
解决各小组之间冲突的措施
质量保证组织的规模和数量
与以往的质量政策之间的差别，或与质量保证措施和标准之间的误差
4）软件质量文档
软件质量文档至少包括：
软件需求分析说明
软件设计说明
软件测试计划
软件测试报告
用户文档
5）适用的标准、规范和约定
这一部分确定所有适用的标准、规范和约定，规定负责实施的部门，并表明对标准、规范和约定的检测和维护措施。
6）评审和审计
软件需求评审
总体设计评审
详细设计评审
软件测试计划、测试方案评审
系统功能评审（对照需求测试编码）
开发过程审计
对质量保证计划执行情况的评审
用户文档评审
7）软件配置管理
为控制和执行修改，确定软件的配置，说明所使用的确认软件单元的方法和手段。
8）存在的问题和修高报告
对存在的问题提出报告、进行跟踪，对解决问题的过程进行说明，同时规定了负责执行这些过程的人员。
9）软件工程
建议采用的工程技术、方法和工具，并说明理由，提供参考资料和开发手册等。
10）编码控制
规定为维护和保管已经确认和鉴定的软件版本的方法和工具。
11）其它内容
12.2.2软件质量代价
质量代价是指为提高产品质量或实现质量目标而进行的一系列活动所需花费的总和。
质量代价为研究质量的当前花费提供了基准，为降低质量花费提供藉以比较的标准。
一旦有了质量代价的标准，就有了确定何时何处可能进行软件开发中过程改进的依据。
质量代价可以分为预防性代价、评价性代价和故障性代价。
预防性代价包括：
1）质量计划；2）形式技术评论；3）测试设备；4）培训。
评价性代价指每个过程产品首次得到确认而必须进行的一系列检查、测试等活动所须的花费。
评价性代价包括：
过程内和过程间检查；设备标度和管理；测试。
故障性代价是在产品销售给客户前后，发现产品缺陷并予以纠正所付出的代价。
故障性代价可以分为内部缺陷代价和外部缺陷代价。
内部缺陷代价是在产品之投放前发现产品的缺陷并予以纠正所付出的代价，它包括：
返工；修理；故障模型分析。
外部缺陷代价是在产品投放市场后发现产品缺陷并予以纠正所付出的代价，它们是：
对产品故障的处理；产品返回和更换；在线帮助支持；担保工作。
从预防到发现、从内部到外部，找出和修正一个缺陷的相应花费急剧上升。
一般，在软件的整个开发过程中，变化和修正是随时发生的。
对于某个变化或修正，如果在需求定义时就予以及时地实现所付出的代价为1，那么，推迟到开发阶段进行所付出的代价是1.5—6；而在产品投放市场后的代价会巨增到60—100。
根据Kaplan等提供的数据报道，针对IBM公司的Rochester开发程序，检查2000,000行代码，花费了7053小时。
这些代码有潜藏的缺陷3112个。
假设程序员每小时的代价为40美元，则预防3112个缺陷总共需要282120美元，即每个缺陷约91.66美元。
假设出厂时每1000行代码中只隐藏一个缺陷（优于工业平均水平），这就意味着仍有200个缺陷。
每定位一个缺陷估计需要25,000美元，大约总共需要有5百万美元，是开发中排除错误花费的18倍。
这个例子也说明了软件开发中“推迟实现”观点的正确性。
12.2.3软件工程与软件质量保证
软件工程的根本目的就是提高软件生产率和保证软件质量。
这两者既对立又统一。
表面看来，要得到高质量的软件，必须花费更多的时间和需要更多的资金投入。
显然，在确定的观念、方法、技术和开发环境等条件下，这种观点是正确的。
但是，软件工程的目的是同时追求高生产率和高质量，因此，它必须在软件生产观念、方法、技术、开发环境等诸多方面进行变革。
也就是说，软件工程必须体现这些方面的变革。
特别是在观念上，人们对软件及其生产规律必须有更客观的认识。
程序设计不是所谓的艺术活动（这种说法曾经流行一时），而是一门科学技术。
这可以说是观念上的一次根本改变。
艺术和科学的根本区别在于：
1）艺术是人的灵感的体现，而科学则是客观规律的表现；2）艺术没有精确的评价标准，而科学有精确的验证标准；3）艺术没有数学基础，科学是以数学为基础的。
程序设计是遵循客观规律的，有严格的验证标准，建立在数学基础之上，因此，它是科学而不是艺术。
正是由于有了这一改变，人们才开始研究软件开发的客观规律和建立相应的方法与技术。
软件产品可以而且应当利用工程的方法生产。
属于科学范畴的人造物品可以而且应当利用工程的方法生产。
所谓工程就是用科学理论为指导，以严格的标准、工厂的形式，采用合适的工具，组织群体，协同工作，以高效率、低消耗，生产高质量的产品。
这是建立软件工程学的基础。
软件工程区别于其它工程，例如机械工程、建筑工程。
软件需求的不明确性、软件生产的高智力性、软件的高复杂性、易修改性和修改的脆弱性，是软件工程必须区别于其它工程的主要原因。
对于任何工匠来说，例如机械师、木匠或软件工程师，最好的生产车间都具有三个主要特征：
1）一组有助于每个产品制造过程的工具；2）一个能使工具快速建立和有效使用的组织规划；3）一个懂得如何有效使用这些工具的技工。
软件工程师的这种车间称为集成项目支撑环境，而这组工具称为计算机辅助软件工程（CASE）。
CASE为工程师提供使手工活动自动化和改进工程师洞察力的能力。
像其它领域的计算机辅助工程一样，CASE工具有助于在产品建造之前保证设计质量。
实现软件开发的工程化是软件质量的根本保障。
12.3软件质量度量模型
如何评价一个软件的质量？
这是几十年来一直困扰着人们的难题。
事实上，在软件发展的不同时期，软件质量的评价标准也有所不同。
在软件发展的初期，计算机的内存容量有限，执行速度不高，人们设计软件时除了强调正确性之外，特别强调程序的效率和设计技巧。
随着计算机硬件的发展和软件规模与复杂性的增加，人们对软件质量的评价开始由正确性和效率为主的评价转向对软件可靠性、易理解性、可维护性和效率等多方面的评价，即“从效率第一到清晰第一”，形成了软件质量度量（SQM）的概念。
软件质量度量（SQM）就是从整体上评价软件质量，以便在软件开发过程中对软件质量进行控制，并对最终软件产品进行评价和验收。
12.3.1有关定义
由于模型描述的需要，给出有关术语的定义：
测量（measure）：
为产品或过程的某些属性提供量化指示，例如范围、数量、维数、能力或尺寸。
度量（metric）：
对系统、部件或过程的某一特性所具有的程度进行的量化测量。
测试（test）：
对系统的某一动态特性进行的系统运行测量。
评估（assessment）：
对系统、部件或过程的某一属性所具有的程度进行的主观分析和评定，得到量化结果。
评价（evaluation）：
为了确定软件模块、包或产品的接受或分发，对特定软件模块、包或产品应用特定的文档化的评估标准的活动。
特征（feature）：
特征是软件产品的确定的性质，它与质量特性相关。
测量活动（measurement）：
对特定软件产品应用软件质量度量的活动。
软件产品（softwareproduct）：
为了分发给用户而设计的软件实体。
软件质量（softwarequality）：
软件产品的特征和特性的全体，它们涉及到产品的满足规定和隐含需要的能力。
软件质量评价标准（softwarequalityassessmentcriteria）：
一组定义和文档化的规则和条件，它们被用来决定特定软件产品的整体质量是否是可接受的或者是不可接受的。
软件质量特性（Softwarequalitycharacteristics）：
软件产品的一组属性，用以反映、描述和评价软件产品的质量内容。
一个软件特性可以分解为不同层次的一个或多个子特性。
软件质量要素（Softwarequalityfactor）：
软件质量特性的别名。
12.3.2质量度量模型
1976年，B.Boehm等人提出了定量地评价软件质量的概念，给出了60个质量度量公式，以及用于评价软件质量的方法,并且首次提出了软件质量度量的层次模型。
Boehm等人认为，软件产品的质量基本上可从下列三个方面来考虑：
（1）软件的运行性能；
（2）软件的维护性能；（3）软件的移植性能。
从Boehm的模型可知，软件的运行性能可以从可靠性（reliability）、效率（efficiency）、正确性correctness）、使用性（usability）、完整性（integrity）五个侧面（二级特征）进行测量；软件的维护性能可以从可测试性（testability）、可理解性（understandability）、可修改性modifiability）三个侧面进行测量，即高可维护性意味着高可测试性、高可理解性和高可修改性；移植性能可以从可移植性（portability）、可重用性（reusability）、交互操作性（interoperability）三个侧面进行测量。
1978年McCall等提出了从软件质量要素（factor）、准则（criteria）到度量（metric）的三层次软件质量度量模型（图12.1），并且定义了11个软件质量要素，给出了各要素的关系，在要素下面定义了23个评价准则。
McCall等人认为，要素是软件质量的反映，而软件属性可用作评价准则，定量化地度量软件属性，从而反映软件质量的优劣。
McCall定义的11个质量要素，分别为：
正确性（correctness）、可靠性（reliability）、效率（efficiency）、完整性（integrity）、可使用性（usability）、可维护性（maintainability）、可测试性（testability）、灵活性（flexibility）、可移植性（portability）、重复使用性（reusability）、连接性（interoperability）。
ISO于1985年提出的软件质量度量模型由三层组成。
高层（toplevel）:
软件质量需求评价准则（SQRC）
中层（midlevel）:
软件质量设计评价准则（SQDC）
低层（lowlevel）:
软件质量度量评价准则（SQMC）
ISO的三层次模型与McCall等人的模型相似，ISO的高层、中层和低层分别与McCall等模型中的要素、评价准则和度量相对应。
根据ISO的观点，高层和中层应建立国际标准以便在国际范围内推广应用SQM技术，而低层可由各公司单位视实际情况制定。
ISO/IEC9126[ISO91]给出了六个软件质量特性，它们的定义如下：
功能性（Functionality）：
一组属性，是一系列功能以及其特定性质的体现。
这里的功能包括需求说明显式指定和隐含的功能。
可靠性（Reliability）：
一组属性，是指在特定的条件下和特定的时间段内软件维持它的性能水平的能力。
可用性（Usability）：
一组属性，是指用户为了掌握和使用一个软件产品所做出的努力和投入的成本的程度。
效率（Efficiency）：
一组属性，是指在指定条件下软件的性能水平和资源使用量之间的关系。
可维护性（Maintainability）：
一组属性，是指进行特定修改所需要的努力。
可移植性（Portability）：
一组属性，是指软件从一个环境转移到另一个环境的能力。
在ISO/IEC9126的附录中定义了21个子特性。
IEEEStd1061-1992指定了软件质量度量方法学标准。
它建立了一个框架，该框架类似于McCall的三层模型，但是框架中的要素和子要素允许增加、删除和修改。
其中，第一层是建立质量需求，定义质量属性，将质量要素分配给质量属性。
如果需要，还要分配子要素给每一个要素。
要素是面向管理者和用户的。
第二层是描述子要素的。
子要素通过将每个要素分解为可测量的软件属性而得到。
子要素是独立的软件属性，因此，一个子要素可以对应于多个要素。
在第三层中，子要素被分解为能够用以测量系统产品和过程的度量指标。
软件质量度量方法学被分为五个步骤：
1）建立软件质量需求；2）确定软件质量度量；3）实现软件质量度量；4）分析软件质量度量结果；5）确认软件质量度量。
它的附录A中的六个要素，与ISO/IEC9126的六个质量特性的定义几乎一字不差，但子要素与ISO/IEC9126中的有一些区别。
12.3.3三种度量模型的比较
Boehm模型的第二层划分是合理的，把质量分为两个侧面：
可用性和可维护性，一个是面向用户的，反映用户的满意程度；一个是面向开发公司内部的，反映公司本身的满意程度。
可移植性被列为第三层，但由第一层直属，说明可移植性不构成软件质量的一个侧面，软件的可移植性不是软件的必备特性。
在70代。
软件移植得以重视，因为当时的硬件系统尚不成熟，主流系统还不明显。
而在80年代之后，由于主流硬件系统已经基本形成，软件移植已不再如以前那样重要了，而代之的是软件的重用性。
软件重用性应当成为软件质量的一个侧面，因为它是软件价值的反映，是未来的开发者对该软件的满意程度。
Boehm的模型的第三层有部分的合理性。
可使用性分为可靠性、效率和人工工程三个方面。
但其中忽略了功能性。
功能性是用户第一关心的，因此也是开发者第一关心的，它不可能包含在其它的第三层属性中。
人工工程实际上反映软件是否容易使用，因此以易使用性表述更合适。
另外，软件的使用还应当有可配置性。
可配置性关系到软件在类似环境中的灵活适应程度。
由于大量的软件都是适应于一类类似的环境的，各个环境之间有所区别，而且用户的环境还会随时间而改变，这种改变是经常性的，但一般变化幅度不大，软件是否适应这些区别和变化，可以从软件的可配置性反映出来。
Boehm模型的第四层定义是薄弱的。
其中的23个特性定义大多数是不明确的，与第三层的关联不合理，与直接的度量或评估之间的关系也不清楚。
McCall模型实质上与Boehm模型类似，也是把质量分为三个侧面：
运行性、可修正性、转移性，但在定义上两者之间是有差距的。
运行性包含了正确性、可靠性、效率、可使用性和完整性。
这样就把运行性与使用性的关系倒置了。
运行是为了使用，可使用性应当包含运行性。
软件的正确性是很难证明的，如果弱化正确性的概念，则可以包含在可靠性中。
其中的完整性也是一个不确切的概念，但它弥补了Boehm模型缺乏功能性特征的不足，有了功能性的含义。
McCall模型大体上与Boahm模型类似。
但是，在McCall模型中对三个侧面的作用削弱了，仅仅起了分类的作用，而不作为模型的一层。
ISO1985模型在上述两个模型的基础上做了改进，将要素减少到8个，去除了可测试性、可移植性、重复使用性。
将完整性改为安全性，将可靠性改为可容性。
ISO/IEC9126又将要素减少到六个，更名为软件质量特性，而且定义更准确一些。
这个标准把子要素列在附录中，以为标准的实施留有充分的余地。
IEEEStd1061-1992只是定义了一个框架，允许用户增、删和修改要素定义。
由此，反映出质量评价模型的不成熟。
我国软件行业协会上海分会于1989年制定的SSC模型将要素减少到6个，去除了安全性、灵活性和连接性，增加了可移植性，将正确性改为功能性，可使用性改为易使用性。
这在名词使用上更确切了，例如功能性就比正确性更明确一些，易使用性就比可使用性更准确。
Dromey认为，软件本身并不直接表明其质量属性，而是展
升级会员 