第19章：软件质量保证

第19章软件质量保证19.1软件质量与SQA19.2软件复审19.3正式的技术复审19.4基于统计的质量保证19.5软件可靠性19.6SQA计划19.7小结16.1软件质量与SQA16.1.1软件质量在ANSI/IEEE的729-1983号标准中定义软件质量为：“与软件产品满足规定和隐含需求的能力有关的全体特征(或特性)”。为满足软件的各项规定的或隐含的功能、性能需求，符合文档化开发标准，就需要相应地设计出一些质量特性及其组合——质量目标，作为在软件开发与维护中的重要考虑因素。如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品的质量就是高的。这些被定义出来的特性及其组合就称之为软件的“质量目标”。从上述软件质量的定义中，反映出了以下三个方面的问题。(1)软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。(2)软件人员必须遵循软件过程规范，用工程化的方法来开发软件。如果不遵守这些规程，软件质量就没有保证。(3)往往会有一些隐含的需求没有明确地提出来。如果软件只是满足那些规定的需求而不可能满足那些可能存在的隐含需求，软件质量也不能保证。软件质量是各种特性的复杂组合，它随着应用的不同而不同，随着用户提出的质量要求不同而不同。在计算机发展的早期(20世纪50和60年代)，软件质量保证工作曾经只由程序员来承担。20世纪70年代，美国军方在软件开发合同中首先提出了软件质量保证的标准，提出了软件质量保证活动的定义是为了保证软件质量而必须的“有计划的和系统化的行动模式”这一观点。这一定义的含义是要求在一个组织中应当由多个机构共同协作，承担保证软件质量的责任。包括软件工程师、项目管理者、客户、销售人员和SQA小组的人员。SQA小组是软件开发组织中独立于任何项目组的专职品质保证组织。他们以客户的观点来看待软件，通过自己的工作来回答软件是否满足各项质量指标、软件开发是否按照预先设定的标准进行、作为SQA活动一部分的技术规程是否恰当地发挥了作用等问题。换句话说，SQA针对工作过程与标准的符合性、工作产品与标准的符合性进行审核与审查。19.1.2SQA活动软件质量保证活动由各种任务构成。这些任务分别和从事技术工作的软件工程师和负责对质量保证活动进行计划、监督、记录、分析、报告工作的专职SQA小组成员相关。软件工程师通过采用可靠的技术方法和措施，进行正式的技术复审，执行计划周密的软件测试来考虑软件质量问题并保证软件质量；SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SEI推荐了一组有关软件质量保证活动中的计划、监督、记录分析及报告的SQA活动。这些活动由一个独立的SQA小组执行。按照SEI的建议，具体的SQA活动应当包括：(1)为项目准备SQA计划：该计划在制定项目开发计划时制订，由所有对质量感兴趣的相关部门复审。该计划将控制由软件工程小组和SQA小组执行的软件质量保证活动。在SQA计划中，应当包含：需要进行的评价；需要进行的审查和复审；项目可以采用的标准；错误报告和跟踪过程；由SQA小组产生的文档目录；为软件项目组提供的反馈数据种类。(2)参与开发该项目的软件过程：软件工程小组为将要进行的工作选择一个工程过程。SQA小组将复审过程说明，以保证该过程与组织政策、内部软件标准、外部标准以及软件开发计划的其他部分相符合。(3)复审各项软件工程活动：对工程活动是否符合定义好的软件工程过程进行核实。SQA小组识别、记录和跟踪实际工作与已定义过程之间的偏差，提出报告要求改正的地方并对是否已经改正进行跟踪与核实。(4)审查指定的软件工作产品，对其是否符合定义好的软件工程过程中的相应部分进行核实。SQA小组要对选出的产品进行复审，识别、记录和跟踪产品与过程规定的偏差，并对是否已经改正进行跟踪核实。定期地将工作结果向项目管理者报告。(5)确保软件工作及工作产品中的偏差已记录在案，并按照预定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。(6)记录所有的不符合部分，并报告给高级管理者，对不符合部分进行跟踪，直到问题得到解决。此外，SQA小组还要协调变更的控制和管理，并协助收集项目度量信息。16.2软件复审19.2.1软件复审软件复审是软件工程过程中滤除缺陷的“过滤器”。在软件项目开发过程中的多个不同的点上，软件复审活动能够起到及早发现错误进而引发排错活动的作用。软件复审的目的是尽可能多地发现被复审对象中的缺陷，起到“净化”工作产品的作用。由于我们发现别人生产的工作产品中的缺陷比发现自己的缺陷要容易，所以复审应当在不同的工程师之间进行。任何一次复审都是借助人的差异性来达到目标的活动，它的目标包括：(1)指出一个人或一个小组生产的产品所需进行的改进。(2)确定被审核产品中不需要或者不希望改进的部分。(3)得到与未复审时相比更加一致，至少更可预测的技术工作的质量，从而使得技术工作更可管理。复审的方式很多，包括非正式的复审、正式的同行评审、管理复审等等。19.2.2软件缺陷对成本的影响在软件工程活动中，“缺陷”是指在软件交付给最终用户后发现的质量问题；而“错误”描述在软件交付前由软件工程师发现的质量问题。很明显，缺陷带来的危害远大于“错误”带来的影响。因此，正式技术复审的主要目标就是在复审过程中发现错误，以便潜在的缺陷在交付之前变成“错误”并得到纠正。正式技术复审的明显优点就是能够较早发现错误，防止错误传播到软件过程的后继阶段。“尽早”发现错误是我们的追求，因为同样的错误对成本和工期产生的影响与发现错误、改正错误的时间是密切相关的。大量的研究表明，设计活动引入的错误占软件过程中出现的所有错误和最终缺陷数量的50%～70%。而近期的研究表明，正式的技术复审在发现设计错误方面有最高达到75%的有效性。由于能够通过复审检测和排除大量的设计错误，复审过程将可望极大地降低后继开发和维护阶段的工作成本。根据从多个大型项目中采集的数据表明，假如在设计阶段发现的一个错误的改正成本是1个货币单位，那么在测试之前发现的一个错误的改正成本就是6.5个货币单位，在测试时发现一个错误的改正成本变成15个货币单位，而在发布之后，改进一处缺陷的成本达到60～100个货币单位。因此，尽可能早地发现错误，是降低软件错误/缺陷对工程成本影响的有效途径。19.2.3缺陷的放大和消除可以用“缺陷放大模型”来说明及时的复审在软件工程中的作用(如图19.1所示)。图中，方块表示一个开发步骤，可能因疏忽而产生错误。复审过程可能没有完全发现来自此步骤之前的和新发生的所有错误。从而可能在本阶段“继承”了一些错误，并将一部分错误引入下一阶段。其中，一部分来自前一阶段的错误可能会误导本阶段的工作，导致在错误的基础上产生更多的错误，形成错误的“放大”效应。图19.1缺陷的放大模型图19.2是一个没有进行技术复审的软件开发过程中缺陷放大的例子。乐观地设想，在每一个测试步骤都能够发现并改正50%的输入错误，而又不引入新的错误。在图中明显地看到，最初在概要设计阶段产生的10个错误，到集成测试之前已经放大成为94个。12个隐藏的缺陷将随着软件的发布扩散到用户处。表16.1是无复审情况下缺陷放大数据及因此增加的成本数据。图19.2缺陷的放大——无复审表19.1无复审情况下软件缺陷对成本的影响错误发现时机缺陷数量成本单位成本总计测试之前226.5143测试期间82151230发布之后1267804缺陷总成本

2177从图19.3中可以看到，只要在每个工程阶段都进行复审工作，就能够有效地遏制缺陷放大的势头，从而减少缺陷对成本的影响。在概要设计阶段同样是10个错误，到集成测试时仅扩展为24个，最终输出到用户处的缺陷只有三个。表19.2是有复审情况下缺陷数据及因此增加的成本数据。从上例中能够清晰地看出，实行复审能够及早地发现大部分错误，极大地减少交付产品中的缺陷数，降低因修正缺陷带来的成本。当然，为了进行复审，开发人员也必须投入工作量，也就是说，组织必须为复审支付成本。但复审增加的成本和因进行了复审而降低的纠正错误和缺陷的成本相比，是相当低的。因此，软件开发组织应当在各个工作阶段上组织进行有效的复审，以便消除缺陷，减少缺陷成本，保证软件质量。图19.3缺陷的放大——有复审表19.2有复审情况下软件缺陷对成本的影响错误发现时机缺陷数量成本单位成本总计设计期间221.533测试之前366.5234测试期间1515315发布之后367201缺陷总成本

78319.3正式的技术复审正式技术复审(FTR)是一种由技术工程师进行的软件质量保证活动。FTR的目标是：(1)在软件的任何一种表示形式中发现功能、逻辑或实现上的错误。(2)证实经过复审的软件的确满足需求。(3)保证软件的表示符合预定义的标准。(4)得到一种以一致的方式开发的软件。(5)使项目更加容易管理。因为FTR的进行使大量人员对软件系统中原本并不熟悉的部分更加了解，因此，FTR还起到了提高项目连续性和培训后备人员的作用。FTR实际上是一类复审方式，包括“走查”(Walkthrough)、“审查”(Inspection)、“轮查”(RoundRobinReview)以及其他软件小组的技术评估。每次的FTR都以会议的形式进行，只有经过适当地计划、控制和相关人员的积极参与，FTR才能获得成功。19.3.1复审会议的组织从保证会议效果出发，不论进行什么形式的FTR活动，会议的规模都不宜过大，控制在3～5人较好；每个参会人员都要提前进行准备，但是复审准备工作占用的工作时间应当少于两小时；会议的时间不宜长，控制在两个小时之内。考虑到这样的约束，每次复审的对象显然应当只是整个软件中的某个较小的特定部分。不要试图一次复查整个设计，而要对每个模块或者一小组模块进行复审走查。经验证明，当一次FTR关注的范围较小时，发现错误的可能性更大一些。FTR的焦点是某个工作产品，比如一部分需求规约，一个模块的详细设计，一个模块的源代码清单等等。负责生产这个产品的人通知“复审责任人”产品已经完成，需要复审。复审责任人对工作产品的完成情况进行评估，当确认已经具备复审条件后，准备产品副本，发放给预定要参加复审的复审者。复审者花1～2小时进行准备。通常在第二天召开复审会议。复审会议由复审责任人主持，产品生产者和所有的复审者参加，并安排专门的记录员。产品生产者在会议上要“遍历”工作产品并进行讲解，复审者则根据各自的准备提出问题。当发现错误和问题时，记录员将逐一进行记录。在复审结束时，必须做出复审结论。结论只能是下列三种之一：(1)工作产品可以不经修改地被接收。(2)由于存在严重错误，产品被否决(错误改正后必须重新复审)。(3)暂时接收工作产品(发现了轻微错误需要改正，但改正后无需再次评审)。参与复审的所有人员，都必须在结论上签字以表示他们参加了本次FTR，并同意复审小组的结论。19.3.2复审报告和记录保存在FTR期间，一名复审者(记录员)主动记录所有被提出来的问题。在会议结束时对这些问题进行小结，并形成一份“复审问题列表”。此外还要形成一份简单的“复审总结报告”。复审总结报告中将阐明如下问题：复审对象是什么；有哪些人参与复审；发现了什么，结论是什么。复审报告是项目历史记录的一部分，可以分发给项目负责人和其他感兴趣的复审参与方。复审问题列表有两个作用，首先是标识产品中的问题区域，其次将被用作指导生产者对产品进行改进的“行动条目”。在复审总结报告中，复审问题列表应当作为附件。SQA人员必须参与复审。他们一方面观察复审过程的合理性，另一方面将会在今后对问题列表中各个问题的改正情况进行跟踪、检查并通报缺陷修改情况，直到复审通过或问题彻底解决。19.3.3复审指南不受控制的错误的复审，比没有复审更加糟糕。所以在进行正式的复审之前必须制定复审指南并分发给所有的复审参加者，得到大家的认可后，才能依照指南进行复审。正式技术复审指南的最小集合如下：(1)复审对象是产品，而不是产品生产者。复审会议的气氛应当是轻松的和建设性的，不要试图贬低或者羞辱别人。通常，有管理职权的成员不宜作为复审者参加会议。(2)制订并严格遵守议程。FTR会议必须保证按照计划进行，不要离题。(3)鼓励复审者提出问题，但限制争论和辩驳。有争议的问题记录在案，事后解决。(4)复审是以“发现问题”为宗旨的。问题的解决通常由生产者自己或者在别人的帮助下解决。所以不要试图在FTR会议上解决所有问题。(5)必须设置专门的记录员，做好会议记录。(6)为保证FTR有实效，坚持要求与会者事先做好准备，提交书面的评审意见，并要限制与会人数，将人数保持在最小的必须值上。(7)组织应当为每类要复审的产品(如各种计划、需求分析、设计、编码、测试用例)建立检查表，帮助复审主持者组织FTR会议，并帮助每个复审者都能够把注意力放在对具体产品来说最为关键的问题上。(8)为FTR分配足够的资源和时间，并且要为复审结果所必然导致的产品修改活动分配时间。(9)所有参与复审的人，都应当具备进行FTR的技能，接受过相关的培训。(10)复审以前所作的复审，总结复审工作经验，不断提高复审水平。19.4基于统计的质量保证有经验的业界人士都同意下面的观点：大多数真正麻烦的缺陷都可以追溯到数量相对有限的根本原因上。对一段较长时间内发现的软件缺陷进行收集、统计，并利用统计规律对大量的缺陷数据进行深入的分析，有助于我们逐渐发现导致大部分缺陷的根本原因，从而能够将它们分离出来，集中力量予以解决。这样，就可以在SQA活动中做到“将时间集中用在真正重要的地方”，有针对性地进行质量保证活动。这种方法称之为“基于统计的质量保证”。基于统计的SQA包括以下的步骤：(1)收集软件缺陷信息并进行分类。(2)尝试对每个缺陷的成因进行追溯。(3)通过追溯，将少数最重要的缺陷成因分离出来。(4)针对分离出的重要的缺陷成因，进行有针对性的改进活动。假如一个软件开发组织在一年内利用复审、测试、用户反馈等途径搜集到了有关自身产品的错误/缺陷信息，尽管发现的错误/缺陷数以百计，但是经过归类，所有的错误/缺陷的原因都可以归为下列原因中的一个或几个：IES：说明不完整或说明错误；MCC：与客户通信中产生误解；IDS：故意与说明偏离；VPS：违犯编程标准；EDR：数据表示错误；IMI：模块接口不一致；EDL：设计逻辑有错；IET：不完整的或错误的测试；IID：不准确或不完整的文档；PLT：将设计翻译成预定语言时的错误；HCI：不清晰或不一致的人机界面；MIS：杂项。设计一张表格，将各类错误/缺陷的统计数据和它们各自在所有错误/缺陷中所占的比例计算出来，以此数值为键值进行降序排序，造成所有错误/缺陷的重要原因就能够十分清晰地凸现出来。表16.3中显示IES、MCC和EDR是导致发生53%的错误/缺陷的“少数重要原因”。同时可以看出，如果我们将注意力集中到严重错误的成因上，那么应该将IES、EDR、PLT和EDL作为“少数重要原因”。一旦确定了“少数重要原因”，开发组织就可以采取改进行动。例如，为了改正MCC错误，开发者可以采用更便于理解的软件说明技术，提高和用户通信交流的质量。为了改正EDR导致的错误，可以使用CASE工具进行数据建模，并进行更加严格的数据设计复审。当导致错误和缺陷的少数重要原因被识别、纠正后，一些原来不那么重要的原因会成为统计数据表中新的“少数重要原因”。这样，SQA活动能够始终针对当前导致错误和缺陷的主要原因展开工作，取得事半功倍的效果。这也就是基于统计的质量保证活动价值之所在。表19.3统计SQA的数据收集与分类错误类别错误总计严重错误一般错误轻微错误数量百分比数量百分比数量百分比数量百分比IES20522%3427%6818%10324%MCC15617%129%6818%7617%IDS485%11%246%235%VPS253%00%154%102%EDR13014%2620%6818%368IMI586%97%185%317%EDL455%1411%123%194%IET9510%129%359%4811%IID364%22%205%143%PLT606%1512%195%266%HCI283%32%174%82%MIS566%00%154%419%统计值942100%128100%379100%435100%19.5软件可靠性19.5.1可靠性和可用性软件可靠性的含义是：“程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率”。在这个定义中包含的随机变量是“时间间隔”。显然随着运行时间的增加，运行时遇到程序故障的概率也将增加，即可靠性随着时间间隔的加大而减小。除可靠性之外，用户也非常关心软件系统可以使用的程度。一般来说，对于任何一个可以修复的系统，都应当同时使用可靠性和可用性来衡量它的优劣。软件可用性的一个定义是：“程序在给定的时间点，按照规格说明书的规定成功地运行的概率”。可靠性和可用性之间的主要差别在于：可靠性意味着在0～t这段时间间隔内系统没有失效；而可用性只是意味着在时刻t系统是正常运行的。因此，如果在时刻t系统是可用的，则包括下述种种可能：在0～t这段时间里，系统一直没有失效；在这段时间里失效了一次，但是又修复了；在这段时间里失效了两次、又修复了两次......如果在一段时间里，软件系统故障停机时间分别为td1，td2，td3......正常运行时间分别为tu1，tu2，tu3......则系统的稳态可用性为(19.1)其中，Tup=∑tui，Tdown=∑tdi。如果引进系统平均无故障时间MTTF和系统平均维修时间MTTR的概念，那么，软件系统的稳态可用性可以表示为平均维修时间MTTR是修复一个故障平均需要的时间，它取决于维护人员的技术水平和对系统的熟悉程度，也和系统的可维护性有重要关系。平均无故障时间MTTF是系统按照规格说明书的规定成功运行的平均时间，它主要取决于系统中潜伏的缺陷数目，因此和测试的关系十分密切。(19.2)为了直观地度量软件的可靠性，还可以采用“平均失效间隔时间”MTBF。MTBF=MTTF+MTTR(19.3)19.5.2平均无故障运行时间的估算软件的平均无故障运行时间MTTF是一个重要的质量指标，用户往往把MTTF作为对软件的一种性能需求提出来。为满足用户的需求，开发组织就应当在交付产品时估算出产品的MTTF值。为了估算MTTF，首先引入一组符号：Et ：测试之前程序中的缺陷总数；It ：用机器指令总数衡量的程序长度；τ ：测试(包括调试)时间；Ed(τ) ：在0～τ时间内发现的错误总数；Ec(τ) ：在0～τ时间内改正的错误总数；Er ：在0～τ时间后剩余的缺陷数。建立一组基本假定：(1)在类似的程序中，单位长度程序里的故障数Et/It近似为常数。根据美国的一些统计数据：0.5×10－2≤Et/It≤2×10－2，也就是说，在正常情况下，测试之前，1000条指令里大约有5～20个缺陷。(2)软件失效率正比于软件中潜藏的缺陷数，而MTTF和潜藏的缺陷数成反比。(3)假定发现的缺陷都及时得到了改正，所以，Ed(τ)=Ec(τ)。(4)剩余的缺陷数：Er(τ)=Et－Ec(τ)。(5)单位长度程序中剩余的缺陷数为：Et/It－Ec(τ)/It。估算平均无故障运行时间：经验表明，软件的平均无故障时间和单位长度程序中剩余的故障数成反比，即其中，K为常数，它的取值应当根据历史数据选取。美国的一些统计数据表明，K的典型值为200。按照上式，可以估算出MTTF值，在用户提出了MTTF指标的情况下，也可以据此判断发现多少个错误后才可以结束测试工作。(19.4)1.植入故障法在测试之前，由专人在程序中随机地植入一些错误，测试之后，根据测试小组发现的故障中原有的和植入的两种故障的比例，来估计程序中原有的总故障数Et。假设人为地植入了Ns个故障，经过一段时间的测试后，发现了ns个植入的故障，此外还发现了n个原有的故障。假定测试人员发现原有故障和植入故障的能力相同，那么能够在概率的意义上，估计出程序中原有的故障总数大约为(19.5)

2.分别测试法植入故障法的基本假定是所用的测试方案发现植入错误和原有错误的概率相同。但是这种假设并不总是成立，因此有时计算结果有较大的偏差。设想由两个测试人员同时测试一个软件程序的两个副本。用T表示测试时间。在T=0时，故障总数为B0；T=T1时，测试员甲发现的故障数为B1；T=T1时，测试员乙发现的故障数为B2；T=T1时，测试员甲、乙发现的相同故障数为Bc；则在统计的角度上，测试之前的故障总数：为进一步求精，可以每隔一段时间进行一次并行测试，如果几次估算的结果相差不多，则可取其均值作为Et的结果估算值。(19.6)19.6SQA计划为了有序地开展软件质量保证活动，必须制定专项的SQA计划来指导全部的SQA活动，并作为项目开发计划的一个组成部分。SQA计划应当由SQA小组和项目组共同制定，并进行评审。IEEE组织推荐了一份SQA计划大纲(如表19.4所示)，开发组织可以结合项目的实际情况对大纲进行裁减、充实后，制定项目的SQA计划。计划的开始部分描述制订SQA计划的目的和涉及到的文档范围，并指出SQA活动所覆盖的软件过程活动。所有在SQA计划中将要提到的文档都要列出来，所有可应用的标准都专门注明。计划中的“管理”部分描述SQA组在组织结构中的位置、SQA任务和活动及它们在整个软件过程中的位置，以及与产品质量有关的角色和责任。文档一节描述的是软件过程各个部分所产生的各种工作产品。包括：项目文档(例如项目计划)、工程过程模型、技术文档、用户文档等等。表19.4SQA计划大纲1．计划目的2．参考文献3．管理3.1组织3.2任务3.3责任4．文档4.1目的4.2所需的软件工程文档4.3其他文档5．标准、实践和约定5.1目的5.2约定6．复审和审核6.1目的6.2复审需求a.软件需求复审b.设计复审c.软件验证和确认复审d.功能审核e.物理审核f.过程内部审核g.管理复审7．测试8．问题报告和改正行动9．SQA工具、技术和方法学10．代码控制11．媒体控制