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

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