项目管理-4-软件质量及管理.ppt

软件工程软件质量及管理1目的o掌握质量的概念o了解质量管理和质量保证的内容和过程o掌握评审和审查的过程o了解和掌握风险管理的概念与过程2相关网站ohttp:/www.sei.cmu.edu/ohttp:/hissa.ncsl.nist.gov/ohttp:/www-sqi.cit.gu.edu.au/ohttp:/www.esi.es/ohttp:/210.79.226.16:81/cetin2/QRMS/index.htm31影响软件质量的因素o1.1质量的概念o质量定义：反映实体满足明确和隐含需要能力的特性综合o定义的说明：n明确需要：指合同中用户明确提出的要求与需要n隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要n特性：实体所特有的性质，反映了实体满足需要的能力41.2项目的质量o质量的类型：n质量，通常指产品的质量，广义的还包括工作的质量。产品质量是指产品的使用价值及其属性；n而工作质量则是产品质量的保证，它反映了与产品质量直接有关的工作对产品质量的保证程度。o项目的质量n从项目作为一次性的活动来看，项目质量体现在由WBS反映出的项目范围内所有的阶段、子项目、项目工作单元的质量所构成，也即项目的工作质量；n从项目作为一项最终产品来看，项目质量体现在其性能或者使用价值上，也即项目的产品质量。51.3影响软件质量的因素o人员n创造性地活动o过程n主要开发环节之间的关系o管理n不同角色关注的角度不同o技术n开发环境6产品质量过程质量开发技术人员因素成本时间、进度71.5过程中的角色过 程管理软件工程师严格的工作条例技术资产环境82国际标准和国家标准规定的软件质量特性1、软件质量特性o1、功能性o2、可靠性o3、易使用性o4、效率o5、可维护性o6、可移植性GB/T16269-1996信息技术软件产品评价质量特性及其使用指南.GB/T17544-1998,信息技术软件包质量要求和测试.9常用术语o功能functiono程序中的一个算法的实现，利用该实现，用户或程序可以完成某一工作任务的全部或部分内容。oGB/T17544199810性能performanceoa.计算机系统或子系统实现其功能的能力。ob.对计算机系统或子系统执行其功能的能力的度量。例如，响应时间、事务处理能力、可靠性等。oGB/T11457199511易用性practicabilityo与一组规定或潜在的用户为使用软件所需做的努力并且对这样的使用所作的评价有关的一组属性。oGB/T175441998o注：软件的易用性是指人们学习、操作、准备输入和解释程序输出（输出结果和出错信息）的便利程度。12可靠性reliabilityo与在规定的一段时间和条件下，软件维持其性质水平的能力有关的一组属性。oGB/T17544199813可扩展性scalabilityo是指软件系统可以在不同规模、不同档次的运行环境平台上运行的能力。oGB/T11457199514易理解性understandabilityo与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。oGB/T16260-1996152、软件质量评价定义质量需求选择质量度量定义等级定义评估准则软件开发度量评级评估规定的/隐含的需求本标准和其他技术信息产品或中间产品量度等级管理质量需求定义质量需求准备评价163软件质量保证o软件质量保证的目的是向管理者提供适当的对软件项目正使用的过程和正构造产品的可视性。o软件质量保证包括评审和审计软件产品和活动以验证它们符合适用的规程和标准，给项目和其它有关的经理提供这些评审和审计的结果。173.1软件质量保证的主要任务o1、用户要求定义o2、软件复用o3、掌握开发新软件的方法o4、组织外部力量协作o5、排除无效劳动o6、发挥每个开发者的主观能动性o7、提高软件开发的工程能力o8、提高计划和管理能力183.2、软件质量保证与检验o1、软件检验的作用n确保每个开发过程的质量，防止把软件差错传递到下一个环节。o2、检验的实施形式n实际运行检验、鉴定o2、软件检验的类型n供货检验n中间检验/阶段评审n验收检验n产品检验193.3软件质量保证体系o1、定义：为了顺利开展软件质量保证活动，事先明确部门间的质量保证业务，确立部门间的联合和协作的机制。203.4软件质量保证（SQA）是一种应用于整个软件过程的保护性活动。SQA包括：o一种质量管理方法o有效的软件工程技术（方法和工具）o在整个软件过程中采用的正式技术复审o一种多层次的测试策略o对软件文档及其修改的控制o保证遵从软件开发标准的规程o度量和报告机制21用户要求与开发方针设定质量目标1设定质量需求准则尺度2设定质量设计准则尺度各阶段度量对象研讨质量准则及实现方法1设定质量度量准则2研讨质量目标实现方法开发活动质量评价1质量度量2以得分和质量图示表示3判定目标达到否改进活动管理信息评测得分表质量图示目标计划实施检查行动224软件质量的度量和评价oo软件质量特性度量有两类：预测型和验收型。软件质量特性度量有两类：预测型和验收型。oo预测度量是利用定量或定性的方法，估算软件质量预测度量是利用定量或定性的方法，估算软件质量的评价值，以得到软件质量的比较精确的估算值。的评价值，以得到软件质量的比较精确的估算值。oo验收度量是在软件开发各阶段的检查点，对软件的验收度量是在软件开发各阶段的检查点，对软件的要求质量进行确认性检查的具体评价值，它是对开要求质量进行确认性检查的具体评价值，它是对开发过程中的预测进行评价。发过程中的预测进行评价。23o预测度量有两种。n第一种叫做尺度度量，这是一种定量度量。它适用于一些能够直接度量的特性，例如，出错率定义为：错误数KLOC单位时间。n第二种叫做二元度量，这是一种定性度量。它适用于一些只能间接度量的特性，例如，可使用性、灵活性等等。24尺度度量检查表25二元度量检查表26o通过对照检查项目，确定一种质量特性的有无。o例如，在设计和编码阶段的复杂性度量，利用尺度度量方法来做。对模块复杂性的度量采用McCabe环路度量。o对于二元度量，可针对检查表中每一项都应给以记分，指定信息存在时记“1”，否则记“0”。表中所有各项的分数相加，即得度量结果。27SQA的目标o目标1软件质量保证活动是有计划的。o目标2软件产品和活动遵守适用的标准、规程和需求的情况得到客观的验证。o目标3受影响的组和个人接到软件质量保证活动和结果的通知。o目标4高级管理者处理在软件项目内部不能解决的不符合问题。28SQA的独立性o存在负责协调和实施项目的SQA的组oSQA有一个向高级管理者报告的渠道，它独立于：项目经理，软件工程组，其它的有关组o组织机构支持那些要求独立性的活动，如SQAo独立性应该：n给担当SQA角色的个人提供组织上的自由度，使他们成为高级管理者在软件项目上的“耳目”。n使得担当SQA角色的个人免受他们正在评审的软件项目的管理者所作的性能评价的影响。n使高级管理者相信正在报告的有关项目过程和产品的信息是客观的。29SQA过程活动活动1按照已建档的规程为软件项目制订SQA计划活动2按照SQA计划进行SQA组的活动活动3SQA组参与准备和评审项目的软件开发计划、标准和规程活动4SQA组评审软件工程活动以验证符合性活动5SQA组审计指定的软件工作产品以验证符合性活动6SQA组定期向软件工程组报告其活动的结果活动7按照已文档化的规程对在软件活动和软件工作产品中所鉴别出的偏差建立文档并加以处理活动8SQA组与顾客的SQA人员一起对它的活动和发现进行定期评审30SQA计划的内容1.SQA组的职责和权力2.SQA组的资源要求3.项目的SQA组活动的进度表和投资4.SQA组参加制定项目的软件开发计划、标准和规程的情况5.将由SQA完成的评价6.将由SQA组进行的审计和评审7.将用作SQA组评审和审计的基础的项目的标准和规程8.用于对不符合性问题建立文档和进行跟踪直至结束的规程9.要求SQA组生成的文档10.就SQA活动给软件工程组和其它软件有关组提供反馈信息的方法和频率315、软件的技术评审Review&Inspectiono检验inspectionn通过观察和判断，必要时结合测量、试验所进行的符合性评价。o评审 reviewn为了确保主题事项的适宜性、充分性、有效性和效率，以达到规定的目标所进行的活动。n实例：管理评审、设计与开发（2.4.7）评审、顾客要求（2.1.2）评审和不合格（2.6.2）评审。32概论o在软件的研制过程中必须进行的一项重要工作，就是软件的验证与确认。o软件验证是确定软件开发周期中的一个给定阶段产品是否达到前阶段确立的需求的过程。它包括评审、审查、测试、检查、审计等项活动。o软件确认是在软件开发过程结束时对软件进行评价，以确认它和软件需求是否相一致的过程。也可以说，确认是“端到端”的验证。33什么是验证与确认o验证和确认是两项相辅相成的工作，但它们之间却极易混淆。o软件工程权威BarryW.Boehm曾巧妙地用两句形式相似但内容不同的话作过精辟的描述：oVerification:Arewebuildingtheproductright?oValidation:Arewebuildingtherightproduct?o验证：我们正正确地制造产品吗？o确认：我们正制造正确的产品吗？34为什么V&Vo不论项目大小如何，软件验证与确认很大程度地影响着软件的质量。o人总是会犯错误的，而没有经过验证的软件将难以正常工作。o有典型事例说明在开发期间每1000行代码中发现有20到50个错误，而即使是在系统测试之后每1000行代码中仍有1.5到4个错误。o软件验证与确认的目标是把错误减少到可以接受的水平。o软件的验证与确认工作占用整个项目的30%90%的资源。35验证与确认V形图o软件开发工作开始于图的左上角，沿左边的产生“软件规格”侧向下进行到“”的底端，其间要逐阶段进行验证；o之后沿右边的产生“软件产品”侧向上，之间对应着它们对“软件规格”的验证。o形图强调在左侧按照输入验证每个输出及在右侧根据“软件规格”验证软件产品。36系统需求软件需求概要设计详细设计单元测试组装测试编码确认测试系统联试详细设计概要设计软件需求系统需求型号任务编译后的单元测试后的单元组装后的软件测试后的软件交付软件验证验证验证验证验证验证验证与确认验证与确认37V形图验证与确认说明o根据系统需求验证软件需求o根据软件需求验证概要设计o根据概要设计验证详细设计o根据详细设计验证编码o用单元测试验证详细设计o用组装测试验证概要设计o用确认测试验证软件需求o用系统联试验证系统需求38通过评审进行V&Vo对软件的工作产品进行验证的一个重要方法是评审。o评审是把工作产品或工作产品集提交给项目人员、经理、用户、顾客或其它感兴趣各方进行评价或批准的过程或会议。o评审一般有技术评审、审查、走查、审计等多种形式。o检查阶段工作的管理评审称作阶段评审。39为什么要及早进行评审1)程序中的大部分错误是在编码之前造成的。据统计，设计及之前阶段产生的错误大约占63，而编码错误仅占37。2)错误的检测与改正时间越晚，所付出的代价也就越高。通过对一些大型软件项目的分析表明；如果在需求和设计阶段发现一个错误，改正所需费用为1；那么在测试前发现该错误，改正费用则为6.5；在测试时发现，改正费用为15；而在交付使用后再发现，改正费用则高达67。3)错误还会被“放大”。40阶段评审o评审的目的n阶段评审在软件研制的各个阶段完成了预定工作时进行，目的是检查该阶段工作是否完成，是否达到了规定的质量和技术要求，检查计划管理、质量管理、风险管理、配置管理的执行情况，决定是否可以转入下一个研制阶段。n各研制阶段结束时均应进行阶段评审。o评审组成员n评审由项目组上级主管机构组织，组长由上级主管领导担任。成员包括：n1）主管领导；n2）同行专家；n3）质量管理人员；n4）科研（计划）管理人员；n5）项目组成员；n6）交办方代表（必要时）。41阶段评审程序（1）o（1）评审前的准备n准备阶段评审汇报和被评审文件。汇报内容：o1）本阶段研制工作的主要内容和完成情况；o2）为保证产品质量所做的质量保证工作；o3）计划落实和配置管理情况；o4）本阶段出现的主要问题及解决情况；o5）结论及建议。o（2）确定评审人员和日期o（3）评审组分工o（4）评审组审阅评审文件n承办单位提前三天将评审文件提交评审组审阅42阶段评审程序（2）o（5）评审会议n1）软件研制项目组作阶段评审汇报；n2）评审组询问、讨论、审查各项工作，项目组答辩；n3）评审组作出评审结论并由组长宣布。o（6）填写评审总结报告o（7）评审后的工作n评审结论入配置管理、保存备案、交上级审批。n项目组针对修改意见和改进建议，经审批进行修改补充。n项目组根据评审意见，转入下一研制阶段。43阶段评审表o在每次阶段评审时，都必须履行正式手续，填写必要的评审表格，以利于项目管理和质量检查。o阶段评审表由三张子表组成n子表1是对评审中发现问题的记录n子表2是评审总结报告n子表3是评审小组成员登记与签字表o对于在评审中发现的软件问题，用软件问题报告单对问题进行详细的描述。44评审问题记录登记号评审日期年月日评审性质评审复审项目名子项目名代号编号问题摘要问题类型是否解决12345678910111213141545评审总结报告登记号评审日期年月日评审性质评审复审项目名子项目名代号阶段名系统需求需求分析概要设计详细设计软件实现组装测试确认测试系统联试项目组长姓名单位电话评审任务评审材料通过不需修改稍作修改不通过作重要修改要重新评审备注46评审小组成员职务姓名职称单位签字组长副组长成员成员成员成员成员成员成员47技术评审o以下技术评审过程是欧洲航空局最佳实践过程之一o目的n技术评审的目的是对具体的工作产品集（如文档、源代码）进行评价，并对管理提供以下信息：o它们符合前一阶段制定的软件规格；o它们已按照项目的标准和方法完成；o所有的更改都正确地得到完成，并只影响对更改规定的范围。48组织o技术评审过程由评审组来执行，评审组中有以下的角色：n负责人n秘书n成员49职责o负责人的责任包括：n提名评审组；n组织评审并通知所有参加者评审的时间、地点和日程；n会议前向所有参加者分发评审项并在必要时分配评审项；n必要时组织评审组开展准备工作；n主持评审会议；n发布技术评审报告。n必要时秘书应协助负责人，并负责记录评审组发现的问题、作出的决定和建议。50职责n各评审组成员检查评审项并参加评审会议。n如果被评审项规模大、复杂或需要各种专业的专家技能才能进行有效的评审，那么负责人可以在成员中分配评审项。51输入o适当时，对技术评审过程的输入包括：n评审会议日程；n对目的的陈述；n评审项（如被评审的软件需求规格说明、软件概要设计说明）；n评审项应符合的上阶段给出的软件规格（如评审软件详细设计说明时所对应的软件概要设计说明）；n评审项使用的计划、标准及指南；n与评审项有关的评审差异表、软件问题报告单，修改报告单；n软件质量保证人员的报告。52评审差异表编号日期提出人1文档标题：2文档代号：3文档发布/版本号：4问题位置：5问题说明：6建议解决方法：7作者答复：8评审决定：结束更改措施拒收（划出选择）53活动=准备+评审会议o准备n负责人起草日程表，并将其与目的、被评审项、规格、计划和指南一起散发给评审组。n评审组成员对评审项进行检查。通过完成评审差异表来对在检查中发现的每个问题进行记录。将评审差异表退还给秘书。n负责人将每张评审差异表按主要的、次要的或编辑上的进行分类n由秘书按被评审项中偏差的位置对评审差异表进行排序。54活动=准备+评审会议o评审会议n1)开始；n2)展示被评审项；n3)评审差异表的分类；n4)对主要的评审差异表的评审；n5)对其它的评审差异表的评审；n6)结论。55评审结论o典型的结论是：n授权进行下一步的工作，条件是完成更改工作和采取措施；n授权进行限定部分的工作；n执行决定的附加工作。o如未能对达成一致意见和得出结论，则：n在评审报告中记录非主流的不同观点；n由一名或多名成员在会议外寻找解决方法；n把问题移交给上一级管理部门。56输出o报告摘要；o成员名单；o被评审项的确定；o按照分类编组的带处置标志的评审差异表、软件问题报告单、软件修改报告单等；o措施清单，以及各措施的人员责任和预期完成日期；o结论。n输出可采取会议记录的形式，或采取独立报告的形式。n报告应足够详细，以便于管理部门判断发生了什么事。n如果在评审期间难以达成一致意见，可建议评审组成员对输出不签字。57软件审查o软件审查可用于编码前发现详细设计中的缺陷，在测试前发现代码的缺陷。软件审查也可以用于验证测试设计、测试用例和测试过程。o软件审查是有效的。通过审查，可以查出开发过程所带给项目的全部缺陷的50%。o软件审查是经济的，因为它可以大大减少缺陷的数量和降低消除缺陷的费用。在缺陷产生后尽可能短的时间内发现缺陷可以：n使软件开发者增强查找缺陷产生原因的意识，以便减少类似缺陷再出现的可能性；n使查找缺陷的工作量减少，因为不需要在许多可能的组成部分以外去诊断哪个组成部分有缺陷。58审查的目的o软件审查的目的是查出文档或代码中的缺陷。59软件审查的组织o主任：主任领导审查并主持审查会。主任应具备完成这项工作的技能，而不必要精通所审查的项目。他（她）必须是公平的、客观的。鉴于这些原因，主任常常从与项目无关的职员中选出。最好他们受过有关审查过程的培训。o秘书：秘书负责记录审查会的记录，特别是记录发现的每个缺陷的细节。o阅读员：阅读者引导审查组遍历被审查项。o审查员：审查员在审查时确定和描述被审查项的缺陷。选择的审查员应能代表各种观点（如：设计员、编码员和测试员）。o作者：作者是被审查项的编制人员。作者主要回答关于被审查项的问题，并负责所有的修改。o一个人可担任上述一种或多种角色。没有人既担任作者又担任其它角色。60软件审查的输入o被审查项（如源代码，或其它文档）o被审查项应符合的规格（如详细设计）o审查检查单o应用于被审查项的标准和指南o审查报告表o从上一次审查中获得的缺陷表61活动=综述、准备、审查会、修改、补充活动o综述是对被审查项进行介绍。o之后审查员对被审查项进行熟悉，作好参加审查会的准备。o然后，审查员在审查会上检查被审查项、确定缺陷并决定是否对缺陷进行纠正。o修改工作包括对故障的修复。o补充活动是指检查在审查会上作出的所有决定是否都得到了执行。62审查的时间和速度o代码审查的初始参考值：n准备：每小时125行非注释源代码；n审查会：每小时90行非注释源代码。n对伪码或PDL的审查，上述数字应加倍。o审查会不应超过两个小时。63软件审查活动o综述：综述的目的是向审查组介绍被审查项。主任介绍要审查的范围，然后详细介绍设计的具体的范围，再将输入分配给参加者。64软件审查活动o准备：主任、阅读员和审查员对输入进行熟悉。通过阅读下列资料来做好代码审查的准备：n要审查的代码设计规范；n编码标准；n含以前审查发现的普遍编码错误的代码审查检查单；n被审查的代码。o被审查项的缺陷要在评审差异表中记录，并在审查过程中合适的时候进行宣布。准备工作应单独进行，而不要在会议上进行。65软件审查活动-审查会o主任检查成员的准备工作，报告和记录各成员所花费的时间。o由阅读员引导会议遍历被评审项。对文件阅读员可总结某些部分的内容，并一行一行地读完所有内容。对代码阅读员应覆盖每个逻辑块，至少详细讨论每个分支一次。审查员利用检查单来发现普遍错误。o秘书对阅读中发现的缺陷立即进行记录。包括下列的内容：n严重性、技术分类、位置、描述o不记录确定的任何解决措施。审查组应避免寻找解决措施，而应集中精力发现缺陷。o在审查会结束前，审查组应作出下列中的一种决定：n当修改完成之后（如果有）接收该审查项；n当修改完成之后由主任负责接收该审查项；n重新审查整个被审查项（如果5%以上需要修改）。o秘书应在之前起草会议纪要，以便修改工作能及时地进行。66软件审查活动o修改n审查之后，软件作者纠正缺陷清单中列出的缺陷。o补充活动n修改之后，补充活动验证所有的缺陷都得到了正确的纠正，而无其它缺陷被引入。n主任负责补充活动。n其它补充活动是：o依据不同错误类型变化的频率修改检查单；o分析缺陷统计资料，也许会导致对软件验证与确认工作的改进。67软件审查的输出o缺陷单o缺陷统计o审查报告68技术评审和审查指南o事先必须建立技术评审和审查工作指南，分发给所有的评审（审查）人员共同遵守。一个不受控制的评审会常常出错，可能会比不评审更坏。69技术评审和审查指南的基本内容(1)评审产品，不评审生产者(2)建立一个议事日程并遵循它(3)限制争论和辩驳(4)说明问题的大小，但不要企图解决所有提出的问题(5)作记录(6)限制参与人数和坚持充分准备(7)为可能评审的产品准备一张检查表(8)为技术评审安排资源和时间表(9)对所有评审人员进行有意义的培训(10)评审你早期的评审706软件可靠性o1、软件生存期与软件寿命的关系软件生存期与软件寿命的关系n一切有生命的东西都有一个“寿命”n这个概念也可以延伸到对非生命产品的质量评价上来。例如一个电子产品的寿命就是指该产品从出厂直到丧失使用价值的持续时间。n从软件工程的角度来说，软件产品的寿命是指软件的整个生存期71o从软件用户的角度来看，更关心的是软件在交付使用后的情况如何。o希望用一个指标平均失效间隔时间MTBF(MeanTimeBetweenFailure)来表明，在规定的要求和条件下，能在多大的程度上依赖这个软件来完成任务。o我们把在使用期间软件能够正常工作的持续时间叫做软件的使用寿命。72o软件的使用寿命与输入环境有关。o例如，有一个存在缺陷的编译程序，当用于学生做简单练习时，MTBF可能很长。而做一个大的课题时，由于程序连续出错，MTBF就会变得很短。oMTBF可以看做是对软件可靠性做估计的样本数据，但不能看做是依据。73o“错误”这一术语。在没有特别加以说明的情况下，这是一个泛用的、模糊的概念。o它指的可能是bug(设计中的差错)、fault(故障)、error(错误)、failure(失效)、crash(重大事故)、problem(疑问)等。o在汉译中，这些术语的使用更加混乱。74在软件工程中常用的定义o故障(fault)：软件的内在缺陷。这些缺陷可在生存期各个阶段被引入。o错误(error)：故障在一定的环境条件下的暴露，导致系统在运行中出现了不正常、不正确、不按规范执行的状态，称为软件出错。o失效(failure)：对错误不做任何修正和恢复，导致系统的输出不满足用户要求，称为软件的一次失效。75o以上定义的故障、错误和失效，分别代表了广义的“错误”在不同的条件下所对应的术语。o它们可以理解为：设计者的失误导致系统中留有错误的设计缺陷或“故障”(fault)，这些故障导致系统的错误执行错误(error)，由于错误导致系统的错误输出失效(failure)。76o故障是物理地或静态地存在的o失误、错误和失效都是系统的一种动态的转瞬即逝的现象o软件发生失效标志着软件一次使用寿命的结束o发生过失效的软件通常仍然是可用的。只有当软件频繁失效，或者公认已经“过时”了的时侯，软件才被废弃，意味着当前这一版本软件使用寿命的终结。77软件故障产生原因o支持软件工作的基本条件(除硬件外的操作系统、数据库管理系统、编译程序、微代码等)的缺陷o软件设计不当o加入了允许范围之外的输入78软件可靠性的定义o软件可靠性是软件在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程序的概率。o环境条件指的是软件的使用环境。无论是什么软件，如果不对它的使用环境加以限制，都是会失效的。这种失效的数据，不能用来度量软件的可靠性。79o规定的时间在定义中，一般采用“运行时间”t作为时间的尺度。因o具体要处理的问题是多种多样的o其对应的输入环境是随机o程序中相应程序路径的选取也是随机的o软件的失效也是随机的o应当把运行时间t当作随机变量来考虑。80o规定的功能在考虑软件可靠性时，首先应当明确软件的功能是什么，哪些功能是主要的，哪些功能是次要的。一般从软件需求分析说明书和设计说明书中可以了解这些情况。n由于功能不同，失效带来的损失就不一样。因此，还要明确哪些失效是致命的，哪些失效是非致命的，哪些又是容易修复的。此外，还要明确，怎样才算是完成了一个规定的功能。81o成功地运行程序是指不仅程序能正确地运行，满足用户对它的功能要求，而且当程序一旦受到意外的伤害，或系统故障时，能尽快恢复，仍能正常地运行。82测试中的可靠性分析o在软件开发的过程中，利用测试的统计数据，估算软件的可靠性，以控制软件的质量是至关重要的。o推测错误的产生频度，即推测错误产生的时间间隔o推测残留在程序中的错误数o评价测试的精确度和覆盖率83推测错误的产生频度o估算错误产生频度的一种方法是估算平均失效等待时间MTTF(MeanTimeToFailure)oMTTF估算公式(Shooman模型)84故障累积指数曲线模型故障累积指数曲线模型85估算软件中故障总数ET 的方法利用Shooman模型估算程序中原来错误总量ET 瞬间估算86利用植入故障法估算程序中原有故障总数ET捕获再捕获抽样法捕获再捕获抽样法o设Ns是在测试前人为地向程序中植入的故障数(称播种故障)，ns是经过一段时间测试后发现的播种故障的数目，n是在测试中又发现的程序原有故障数。设测试用例发现植入故障和原有故障的能力相同，则程序中原有故障总数N(=ET)估算值为87Hyman分别测试法o由两个测试员同时互相独立地测试同一程序的两个副本，用t表示测试时间，记t0时，程序中原有故障总数是B0；tt1时，测试员甲发现的故障总数是B1；测试员乙发现的故障总数是B2；其中两人发现的相同故障数目是bc；两人发现的不同故障数目是bi。88o在大程序测试时，头几个月两个测试员测试的结果应当比较接近，bi 不是很大。这时有o如果bi比较显著，应当每隔一段时间，由两个测试员再进行分别测试，分析测试结果，估算B0。如果bi减小，或几次估算值的结果相差不多，则B0作为原有错误总数的估算值。89测试精确度和测试覆盖度的评价o在软件测试过程中累积发现的故障数，可用带有平均值函数 m(t)的非齐次泊松过程(NHPP)来描述：o其中，N是在测试中可能发现的故障总数，b是故障发现率。o当N一定时，b越大，在短期内发现的故障越多。9091oN可以认为是当测试时间无限延长时估计可能发现的故障总数。由于n测试的不完全，在某些很难发现的故障未发现前就可能结束测试n若程序中潜在的故障较少，则参数N的估计误差较大o因此，只用测试中累积发现的故障数来评价测试是不够的。需要从测试的量的方面和质的方面，全面地评价测试。92oSPQL(SoftwareProductQualityLevel)用如下公式度量：SPQLAcCvo其中，Ac(TestAccuracy)是测试的精确度，它反映了测试的质量；Cv(TestCoveragy)是测试的覆盖度，它反映了测试的数量。测试结束时软件产品质量水准93o测试质量的度量可以靠测试的故障捕捉率和遗漏率来衡量。o测试数量的度量指标是执行的测试用例数、确认的程序路径数等等；94测试精确度Aco表明在测试的过程中以多大的把握捕捉了软件中潜在的故障。o测定Ac，需要预先植入播种故障，然后通过测试，根据播种故障的捕捉率来推测原有故障的捕获率。95o用ns表示经过相当长时间测试可能发现的播种故障数，用Ns表示测试对象软件内预先埋设的播种故障总数,用平均值为m(t)的NHPP模型描述测试时发现播种故障的过程om(t)的收敛值m()No测试精确度Ac的推测值：96o若设测试过程中到时刻ti能发现的累积播种故障总数为yi，则在测试期间可得到一连串数据(t0,0),(t1,y1),(tm,ym)o可得到一组方程：o应用最小二乘法可得到参数N与b的估计值，并得到测试精确度Ac。97测试覆盖率Cvo表明在整个测试期间发现软件内潜在故障的可能性有多大。o可通过被测试对象软件内潜在的原有故障的捕捉率来测定的。98o测试过程中已发现原有故障总数为n0(实测值)，经过相当长时间测试后可能发现的原有故障总数为N0，o采用平均值函数m(t)的NHPP模型描述测试发现原有故障的过程om(t)的收敛值m()Nco测试覆盖率Cv的推测值：99o测试开始后，由于测试员对程序和测试环境不熟悉，造成拖期。o为描述这种情形，对原来NHPP的指数型平均值函数加以改造：o它是把原来的指数型平均值函数在时间轴上平移而得到的结果，是具有时间延迟的NHPP模型。100101o测试员从发现错误征兆到确认错误，需要反复执行程序，以再现错误，造成时间拖延。o因此，在使用测试结果进行软件质量评价时，只用指数型的NHPP的平均值曲线(A)是不够的。实测结果多是如(B)所示的S型曲线。102o实验表明：n对于一般功能单纯的小规模的程序模块，具有时间延迟的NHPP模型比较合适；n对于功能比较复杂的程序模块，S型NHPP模型比较合适；n对于80000行以上的程序，最基本的指数型NHPP模型比较合适。1037软件容错技术o1、定义o2、容错的一般方法n结构冗余n信息冗余n时间冗余n冗余附加技术1041、结构冗余o静态冗余o动态冗余o混合冗余o表决系统、错误的监、切换、重新启动1052、信息冗余o案例：通信传书中的校验码。1063、时间冗余o案例：程序滚回1074、冗余附加技术o以硬件错误屏蔽为目的的技术中n关键程序和数据的冗余存储和调用n检测、表决、切换、重构、纠错和复算的实现o以软件错误屏蔽为目的的技术中n各自独立设计的功能相同的冗余备份程序的存储和调用n实现错误监测和错误恢复的程序n为实现容错软件所需的固化程序108容错软件的设计过程建立需求说明设计结构错误分类确定容错范围确定容错措施修改结构评估冗余效果完成109软件的容错系统结构o1、最小冗余单元n功能可以明确定义的最小程序段o2、容错域110软件的容错系统结构举例o1、多版本程序结构o2、恢复块结构111