软件质量管理概览-质量管理-火龙果软件工程

软件质量(quality management)

概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。可划分为三组，分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）。

定义

1.性能(Performance)是指系统的响应能力，即要经过多长时间才能对某个事件作出响应，或者在某段时间内系统所能处理的事件个数；

2.可用性(Availability)是指系统能够正常运行的时间比例；

3.可靠性(Reliability)是指系统在应用或者错误面前，在意外或者错误使用的情况下维持软件系统功能特性的能力；

4.健壮性(Robustness)是指在处理或者环境中系统能够承受的压力或者变更能力；

5.安全性(Security)是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或者拒绝服务的能力；

6.可修改性(Modification)是指能够快速地以较高的性能价格比对系统进行变更的能力；

7.可变性(Changeability)是指体系结构扩充或者变更成为新体系结构的能力；

8.易用性(Usability)是衡量用户使用软件产品完成指定任务的难易程度；

9.可测试性(Testability)是指软件发现故障并隔离定位其故障的能力特性，在一定的时间或者成本前提下进行测试设计、测试执行能力；

10.功能性(Function ability)是指系统所能完成所期望工作的能力；

11.互操作性(Inter-Operation)是指系统与外界或系统与系统之间的相互作用能力。

软件质量因素

正确性是指软件按照需求正确执行任务的能力。 “正确性”的语义涵盖了“精确性”。正确性无疑是第一重要的软件质量属性。技术评审和测试的第一关都是检查工作成果的正确性。机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。

健壮性是指在异常情况下，软件能够正常运行的能力。正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。开发者往往把异常情况错当成正常情况而不作处理，结果降低了健壮性。用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。所以提高软件的健壮性也是开发者的义务。健壮性有两层含义：一是容错能力，二是恢复能力。

可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。可靠性本来是硬件领域的术语。比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”问题、“误差累积”问题等等。时隐时现的错误一般都属于可靠性问题，纠错的代价很高。

性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。人们总希望软件的运行速度高些，并且占用资源少些。性能优化的关键工作是找出限制性能的“瓶颈” 可以通过优化数据结构、算法和代码来提高软件的性能。

易用性是指用户使用软件的容易程度。现代人的生活节奏快，干啥事都想图个方便。所以把易用性作为重要的质量属性对待无可非议。导致软件易用性差的根本原因：理工科大学教育存在缺陷：没有开设人机工程学、美学、心理学这些必修课，大部分开发人员不知道如何设计易用的软件产品。开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也就会满意。软件的易用性要让用户来评价。当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“界面友好”、“方便易用”等词来评价软件产品。

清晰意味者所有的工作成果易读、易理解，可以提高团队开发效率，降低维护代价。开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。可理解的东西通常是简洁的。一个原始问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。如果软件系统臃肿不堪，它迟早会出问题。所以简洁是人们对工作“精益求精”的结果，而不是潦草应付的结果。千万不要把在学校里“造文章”的手法用于开发产品！

这里安全性是指信息安全，英文是Security而不是Safety。安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。 “道高一尺，魔高一丈” ，绝对安全的信息系统几乎不存在。开发商和客户愿意为提高安全性而投入的资金是有限的，他们要考虑值不值得。究竟什么样的安全性是令人满意的呢？一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、风险等因素）高于得到的好处，那么这样的系统可以认为是安全的。

可扩展性反映软件适应“变化”的能力。在软件开发过程中，“变化”是司空见惯的事情，如需求、设计的变化，算法的改进，程序的变化等等。由于软件是“软”的，是否它天生就容易修改以适应“变化”？关键要看软件的规模和复杂性。现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。可扩展性越来越重要。可扩展性是系统设计阶段重点考虑的质量属性。

兼容性是指两个或两个以上的软件相互交换信息的能力。兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。示例：中国联通和中国移动的手机互联互通问题金山软件公司的WPS与微软的Word之争可移植性。

可移植性是指软件运行于不同软硬件环境的能力编程语言越低级，其程序越难移植，反之则容易。软件设计时应该将“设备相关程序”与“设备无关程序”分开，将“功能模块”与“用户界面”分开。

软件质量评估

软件质量评估是“软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和”。根据软件质量国家标准GB-T8566--2001G，软件质量评估通常从对软件质量框架的分析开始。

1 软件质量的有关概念

软件质量是“软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和”。根据软件质量国家标准GB-T8566--2001G，软件质量评估通常从对软件质量框架的分析开始。

1.1 软件质量框架模型

如图1所示，软件质量框架是一个“质量特征—质量子特征—度量因子”的三层结构模型。

在这个框架模型中，上层是面向管理的质量特征，每一个质量特征是用以描述和评价软件质量的一组属性，代表软件质量的一个方面。软件质量不仅从该软件外部表现出来的特征来确定，而且必须从其内部所具有的特征来确定。

第二层的质量子特征是上层质量特征的细化，一个特定的子特征可以对应若干个质量特征。软件质量子特征是管理人员和技术人员关于软件质量问题的通讯渠道。

最下面一层是软件质量度量因子（包括各种参数），用来度量质量特征。定量化的度量因子可以直接测量或统计得到，为最终得到软件质量子特征值和特征值提供依据。

1.2 软件质量特征

按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价：

a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。

b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。

c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。

d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。

e.可维护特征：与进行指定的修改所需的努力有关的一组属性。

f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。

其中每一个质量特征都分别与若干子特征相对应。

2 评估指标的选取原则

选择合适的指标体系并使其量化是软件测试与评估的关键。评估指标可以分为定性指标和定量指标两种。理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。

在选取评估指标时，应该把握如下原则：

a.针对性

即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。

b.可测性

即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。

c.简明性

即易于被各方理解和接受。

d.完备性

即选择的指标应覆盖分析目标所涉及的范围。

e.客观性

即客观反映软件本质特征，不能因人而异。

应该注意的是，选择的评估指标不是越多越好，关键在于指标在评估中所起的作用的大小。如果评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。

3 软件质量评估指标体系

通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。

3.1 功能性指标

功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。目前对软件的功能性评价主要采用定性评价方法。

a.完备性

完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。

b.正确性

正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。

对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。

目前，对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。

3.2 可靠性指标

根据相关的软件测试与评估要求，可靠性可以细化为成熟性、稳定性、易恢复性等。对于软件的可靠性评价主要采用定量评价方法。即选择合适的可靠性度量因子（可靠性参数），然后分析可靠性数据而得到参数具体值，最后进行评价。

经过对软件可靠性细化分解并参照研制任务书，可以得到软件的可靠性度量因子（可靠性参数）。

a.可用度

可用度指软件运行后在任一随机时刻需要执行规定任务或完成规定功能时，软件处于可使用状态的概率。可用度是对应用软件可靠性的综合（即综合各种运行环境以及完成各种任务和功能）度量。

b.初期故障率

初期故障率指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。一般以每100小时的故障数为单位。可以用它来评价交付使用的软件质量与预测什么时候软件可靠性基本稳定。初期故障率的大小取决于软件设计水平、检查项目数、软件规模、软件调试彻底与否等因素。

c.偶然故障率

指软件在偶然故障期（一般以软件交付给用户后的四个月以后为偶然故障期）内单位时间的故障数。一般以每1000小时的故障数为单位，它反映了软件处于稳定状态下的质量。

d.平均失效前时间（MTTF）

指软件在失效前正常工作的平均统计时间。

e.平均失效间隔时间（MTBF）

指软件在相继两次失效之间正常工作的平均统计时间。在实际使用时，MTBF通常是指当n很大时，系统第n次失效与第n+1次失效之间的平均统计时间。对于失效率为常数和系统恢复正常时间很短的情况下，MTBF与MTTF几乎是相等的。

国外一般民用软件的MTBF大体在1000小时左右。对于可靠性要求高的软件，则要求在1000~10000小时之间。

f.缺陷密度（FD）

指软件单位源代码中隐藏的缺陷数量。通常以每千行无注解源代码为一个单位。一般情况下，可以根据同类软件系统的早期版本估计FD的具体值。如果没有早期版本信息，也可以按照通常的统计结果来估计。“典型的统计表明，在开发阶段，平均每千行源代码有50~60个缺陷，交付后平均每千行源代码有15~18个缺陷”。

g.平均失效恢复时间（MTTR）

指软件失效后恢复正常工作所需的平均统计时间。对于软件，其失效恢复时间为排除故障或系统重新启动所用的时间，而不是对软件本身进行修改的时间（因软件已经固化在机器内，修改软件势必涉及重新固化问题，而这个过程的时间是无法确定的）。

3.3 易用性指标

易用性可以细化为易理解性、易学习性和易操作性等。这三个特征主要是针对用户而言的。对软件的易用性评价主要采用定性评价方法。

a.易理解性

易理解性是与用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性。该特征要求软件研制过程中形成的所有文档语言简练、前后一致、易于理解以及语句无歧义。

b.易学习性

易学习性是与用户为学习软件应用（例如运行控制、输入、输出）所花的努力有关的软件属性。该特征要求研制方提供的用户文档（主要是《计算机系统操作员手册》、《软件用户手册》和《软件程序员手册》）内容详细、结构清晰以及语言准确。

c.易操作性

易操作性是与用户为操作和运行控制所花的努力有关的软件属性。该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。

3.4 效率特征指标

效率特征可以细化成时间特征和资源特征。对软件的效率特征评价采用定量方法。

a.输出结果更新周期

输出结果更新周期是软件相邻两次输出结果的间隔时间。为了整个系统能够协调工作，软件的输出结果更新周期应该与系统的信息更新周期相同。

b.处理时间

处理时间是软件完成某项功能（辅助计算或辅助决策）所用的处理时间（注意：不应包含人机交互的时间）。

c.吞吐率

吞吐率是单位时间软件的信息处理能力（即各种目标的处理批数）。未来的社会情况复杂、信息众多，软件必须具有处理海量数据的能力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批。

d.代码规模

代码规模是软件源程序的行数（不包括注释），属于软件的静态属性。软件的代码规模过大不仅要占用过多的硬盘存储空间，而且显得程序不简洁、结构不清晰，容易存在缺陷。

因为这些参数属于软件的内部表现，所以需要用专门的测试工具和特殊的途径才可以获得。将测试数据与研制任务书中的指标进行比较，得到的结果可以作为效率特征评价的依据。

4 结束语

随着计算机技术、数据融合技术、网络技术和通信技术的飞速发展，对软件功能提出的要求也越来越高，如何评估软件质量已成为一个迫切需要解决的课题。选择合适的指标体系并使其量化是做好软件质量评估的关键。当然，由于软件的评估具有其特有的规范和要求，其评估指标涉及面广、不确定性因素较多、量化困难，至今还没有统一的标准。

标准

(1)软件需求是度量软件质量的基础，与需求不一致就是质量不高。

(2)指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。

(3)通常，有一组没有显式描述的隐含需求（如期望软件是容易维护的）。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。

QA和QC

QA即英文QUALITY ASSURANCE 的简称，中文意思是质量保证；

QC即英文QUALITY CONTROL的简称，中文意义是质量控制。

QC和QA的主要区别前者是保证产品质量符合规定,后者是建立体系并确保体系按要求运作,以提供内外部的信任.同时QC和QA又有相同点:即QC和QA都要进行验证,如QC按标准检测产品就是验证产品是否符合规定要求,QA进行内审就是验证体系运作是否符合标准要求,又如QA进行出货稽核和可靠性检测,就是验证产品是否已按规定进行各项活动,是否能满足规定要求,以确保工厂交付的产品都是合格和符合相关规定的。

两者基本职责

QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；

QA：审计过程的质量，保证过程被正确执行；是过程质量审计者；

注意区别检查和审计的不同

检查：就是我们常说的找茬，是挑毛病的；

审计：来确认项目按照要求进行的证据；仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的；对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。

对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。

在这样的分工原则下， QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。

如果企业原来具有 QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。

质量控制--QC

QC可以是英文QUALITY CONTROL的简称，中文意义是质量控制，其在ISO9000:2005的定义是“质量管理的一部分，致力于满足质量要求”。同时也是Quality Center 的简称。

“QC工具”是开展主题活动必要的手段，主要是针对特定的工作失误或品质不良运用QC工具展开分析讨论，并将结果整理在大家容易看到的地方，以提醒防止发生这样的问题，而且大家随时可以提出新的建议并进行讨论修订。一般适合于工作比较单一的情况，或特定的课题活动，并不是每个小课题都这样。

产品经过检验后再出货是质量管理最基本的要求。质量控制是为了通过监视质量形成过程，消除质量环上所有阶段引起不合格或不满意效果的因素。

有些推行ISO9000的组织会设置这样一个部门或岗位，负责ISO9000标准所要求的有关质量控制的职能。

QC的工作主要是产成品，原辅材料等的检验，QA是对整个公司的一个质量保证，包括成品，原辅料等的放行，质量管理体系正常运行等。在质量管理发展史上先出现了“QC”，产品经过检验后再出货是质量管理最基本的要求。QC职能为生产加工过程中的管控及制程数据的统计\分析，并将相关信息提供给其它部门。

质量保证--QA

QA的基本目标

目标 1: 软件质量保证[1] 工作是有计划进行的。

目标 2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。

目标 3: 将软件质量保证工作及结果通知给相关组别和个人。

目标 4: 高级管理层接触到在项目内部不能解决的不符合类问题。

目标 5: 软件质量需要全面的测试工作来保证。

QA的由来

我们知道，国外很多的大公司，QA的职责就是测试（主要是系统测试），比如IBM、CA、PeopleSoft等。其实在最初，几乎所有的公司都是这样的。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少（注：我以前做的一个项目，项目经理就明确告诉我系统测试就1天，没得商量）。另外，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，事先预防的QA职能就应运而生。

事先预防其实是借鉴了TQM的思想，而且也符合软件工程“缺陷越早发现越早修改越经济”的原则。这些思想的渊源还可以追溯到中国古代的典故中，比如曲突徙薪、扁鹊论医术等。

QA的现状

实施CMM的企业越来越多了，CMM模型就要求建立QA角色。这里的QA类似于过程警察，主要职责是，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。在这些企业中，一般还要求QA独立于项目组，以保障评价的客观性。从国内来看，多数的QA没有技术背景，检查出的偏差多为鸡毛蒜皮，再加上自己没有令人信服的背景，领导也不支持，当然做起来就很困难了。

缺乏信任和支持只是一个方面，QA工作本身就很具挑战性。它要求QA具有软件工程的知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理的知识等等。

我们常常遇到这样的问题，改进到一定程度就很难突破，感觉心有余而力不足了，就开始郁闷了。后来通过学习、培训、交流，思想和技能得到升华，又发现了木桶中最短的那块，然后又开始改进，然后又遇到了玻璃天花板，然后……就这样处于郁闷的循环中。

假使我们掌握了所有的知识，能突破所有的玻璃天花板，那是不是QA就可以一帆风顺了。答案是否定的。QA角色定义本身就有很大的局限性。QA充当的是过程警察的角色，无论是否有意义，都专横地强制过程的执行，容易在项目组中造成敌对的关系，受到排挤，而且这种警察的姿态也破坏了团队精神。如此一来，QA工作还需要的是人际关系技能，就如我以前写的《质量平衡》和《QA应该独立于项目组吗？》一样，艺术化地处理这种关系。

QA的未来

从某种程度上说，独立的QA审查机制是瀑布模型的产物。随着现代软件开发技术的演变，螺旋模型和迭代模型的兴起，QA机制正在悄然发生变化。这种变化就是从独立专职的QA向贯穿过程的兼职QA演变。在CMMI模型中，这种兼职的QA也是被允许的。为什么会发生这种改变呢？无论是XP、RUP还是其它先进的方法论，都是先产生架构，然后再增量开发，直到完成。这种模式中，需求和设计缺陷在各个迭代周期被所尽早发现和修复，质量也内建于架构和过程中，项目的成本和进度也得到保障。

到那时，是不是独立的QA就不复存在了呢？有些成熟度较低的企业还是需要的，主要是保证过程执行的有效性和评价的客观性。

软件开发

需求分析

确保客户所要求的系统是可行的。

确保客户指定的需求确实能够满足他的真正要求。

避免开发者和客户之间的误解。

向用户提供为满足他所提出的需求而实际构建的适当软件系统。

软件规格说明

通过建立需求跟踪文档，确保规格说明书与系统需求保持一致。

确保规格说明书能适当地改进系统的灵活性、可维护性以及性能。

确保已建立了测试策略。

确保已建立了现实的开发进度表，包括预定的评审。