《第五度量测试结果与缺陷管理.ppt》由会员分享，可在线阅读，更多相关《第五度量测试结果与缺陷管理.ppt（34页珍藏版）》请在三一文库上搜索。
1、第五章 度量测试结果与缺陷管理,第一节 监视测试覆盖率 第二节 缺陷管理*,理解测试信任程度的量度 明白何时进行测试和使用覆盖率 掌握如何进行缺陷管理,本章目标,良好的测试设计由若干个防范组成 在单元测试中，测试应设计为检验各个单元是否实现了该 单元的设计说明书中的所有设计判定 单元测试说明书由一系列单元测试用例组成 测试用例设计技术可以大体分成黑盒和白盒两个主要类别 缺陷猜测主要凭借测试设计者的经验,回 顾,不管计划和执行测试多么努力，并非所有软件缺陷发现 了就能修复，有的可能要在后续版本中修复 测试全貌：测试计划、实际测试和度量测试结果、写测试报告 度量是软件工程过程的一个关键要素 度量标
2、准用于理解所创建的模型的属性 度量用于评估工程产品或者已经建立的系统的质量,第一节 监视测试覆盖率,对于测试结果的评价，需要监视测试覆盖率 要减少要测试的条件的数量，可以将系统分成多个独立的 部分 这样可以为代码测试的各个部分分别生成不同的条件组合 从根本上说，用来度量覆盖率的属性：输入、输出 从传统上说，覆盖率通常是从输出角度来看待 当系统被更多集成到关系产品生命周期和关键任务的系统 中时，会增加对系统的期望,监视测试覆盖率,运行测试用例的时候，需要对已经测试的部分和尚未测试 的部分进行跟踪 可以在源代码中插入语句以收集程序的有关数据 覆盖率的数据是在测试过程中不断收集的 即使在一个软件发布
3、之后，覆盖率也可能发生改变，特别 是覆盖率可能会下降 画控制图可以用来分析程序以帮助我们决定在何处以及如 何对它们进行测试，如下图：,语句覆盖：选择足够的测试用例，使得程序中每一条可执 行语句至少被执行一次 判定覆盖：选择足够的测试用例，使得程序中每一个分支 判断的每一种可能结果(主要指switch-case情况)都至少 被执行一次。判定覆盖也叫分支覆盖 条件覆盖：选择足够的测试用例，使得程序中每一个分支 判断中的每一个条件的可能结果都至少被执行一次,逻辑覆盖测试方法,判定/条件覆盖：选择足够的测试用例，使得同时满足判定 覆盖和条件覆盖 条件组合覆盖：选择足够的测试用例，使得程序中每一个 分支
4、判断中的每一个条件的每一种可能组合结果都至少被 执行一次 路径覆盖：选择足够的测试用例，使得程序中所有的可能 路径都至少被执行一次,需要完成的各种测试包括： 单元测试、集成测试、系统测试、验收测试、回归测试 在验收和回归测试后，对于覆盖率测试达到一定标准后， 我们即发布软件 避免软件设计出现重大失误的最佳方法就是对每一处设 计都进行测试，并且在设计时就开始测试,测试覆盖率涉及的测试,几个有用的术语： 错误：人类会犯错误。接近的同义词过错。编写代码会 出现过错，这种过错叫做BUG 缺陷：错误的结果 更精确地说，缺陷是错误的表现，而表现是表示的模式， 例如叙述性文字、数据流框图、层次结构图、源代码
5、等 接近的同义词缺点 过错缺陷（如果所某些信息输入到不正确的表示中） 遗漏缺陷（如果没有输入正确信息）,第二节 缺陷管理,失效：当缺陷执行时会发生失效 失效只出现在可执行的表现中，通常是源代码 这种定义只与过错缺陷有关 如何处理遗漏缺陷对应的失效呢？如米开朗基罗病毒 事故：当出现失效时，可能会也可能不会呈现给用户 （或客户或测试人员）。事故说明出现了与失效类似的 情况，警告用户注意所出现的失效,测试：处理错误、缺陷、失效和事故 测试是采用测试用例执行软件的活动 测试的目标：找出失效、演示正确的执行 测试用例：有一个标识，并与程序行为有关。它有一组 输入和一个预期输出表 测试生命周期模型： 前三
6、个阶段是“引入程序错误” 测试阶段是“找出程序错误” 后三个阶段是“清除程序错误”,一个测试生命周期,测试步骤： 测试计划 测试用例开发 运行测试用例 评估测试结果,缺陷可以定义成： 没有实现预定的使用需求或合理期望 与规格说明书或标准存在偏差 在与标准的一致性方面导致客户不满的任何问题,什么是缺陷,客户期望以较少的时间/成本获得较高的质量 规格说明书在项目开发生命周期的后期往往会被修改 测试所发现的缺陷常常会招致大量的软件开发成本 新的开发方法、工具不断地实现 软件管理不能让测试成为瓶颈并减慢开发速度 测试需要快速、灵活和可靠 我们需要有关测试充分性的证据,为什么需要缺陷管理,缺陷的生命周期
7、,致命性缺陷（Critical）： 数据丢失，数据计算缺陷、系统崩溃和经常死机 严重功能性缺陷(Serious)： 规定的功能没有实现或不完整、设计不合理造成性能低下， 影响系统的运行 警告性缺陷(Moderate)： 不影响业务运行的功能问题 建议性缺陷(Suggestion,Cosmetic)： 软件设计和功能实现等不甚合理之处提出建议,缺陷管理Defect级别,高优先级 中优先级 低优先级,缺陷管理修改的优先级,缺陷管理缺陷描述,缺陷管理与缺陷跟踪有关项,项目管理者 测试管理者 被分配修改缺陷的人 组件代码的编写人 测试小组中的其他成员,缺陷管理缺陷分发对象,这些阶段如下所示： 缺陷标识
8、、记录和报告 缺陷的消除和跟踪 缺陷测量和根由分析 缺陷预防/过程改进 软件开发生命周期所有阶段的测试 安装测试工具,缺陷管理的实现阶段,缺陷管理问题包括： 缺陷遗漏 同类缺陷重复 数据库更新不完全 分类不严谨 - 每个缺陷都被划分为缺陷的类型 用来攻击项目分类的缺陷数据 很多不负责任的缺陷 重置是一个瓶颈 相同的缺陷重现,缺陷状态信息应该包含下列信息： 缺陷的当前状态和状态历史记录描述 状态历史记录，包括描述日期、操作、执行者、实际工作 量、结果状态和指定的下一个步骤的行 下一个步骤估计需要付出的努力 完成的期望日期 缺陷分析和度量 缺陷生命周期分布有助于深入了解缺陷结束所花天数、修 复缺陷
9、所需付出的努力和进度分析 对预计付出的努力相对于实际付出的努力的分析,缺陷状态信息,进行缺陷报告前执行的过程： 获取空白的缺陷表格 指定可用的信息 信息可用时不断更新 对缺陷信息进行分类，包括：一般信息、缺陷检测信息、 缺陷消除信息、状态信息 估计要投入的努力、预计日期、实际日期以及缺陷在其整 个生命周期中的变化,缺陷报告,所需的缺陷信息有： 有关缺陷性质、它的修复优先级等的基本信息 描述 - 简要的文字 优先级（紧急、普通、不急）您的优先级，客户的优先级 严重程度（主要、次要、不严重）您的优先级，客户的优 先级 原因关键字（用于进一步分析） 症状（数据库损坏、可视数据缺陷、界面缺陷、等等）
10、起源的阶段,找到的阶段 报告的数据 期望和实际的结束日期 描述 版本、日志、周期、过程、用例 - 发现缺陷的地方 报告者：（姓名、公司） 硬件操作系统 - 发现缺陷的平台 测试位置 附件/附加信息,缺陷报告,测试报告国际标准,测试事件报告的文档：编写在需要调查研究的测试过程期间 发生的任何事件（登记软件缺陷） 审查标准：提取当前已经掌握的软件缺陷报告信息，以及把 它们全部放在一起观察结果的好方法 标准定义的范围： 标识符：指定软件缺陷报告的唯一ID，用于定位和引用 总结：用简明的事实总结软件缺陷 事件描述：用下列信息详细描述软件缺陷P61 影响：严重性和优先级，以及测试计划、测试说明、测试程 序和测试案例的影响指示,软件缺陷报告的国际标准,ANSI/IEEE829给出的简单文档：P61 对于小的项目，书面表单可以胜任 对于中、大型项目，应该考虑应用数据库进行存储和管理 缺陷报告,总 结,度量是软件工程过程的一个关键要素 可以在源代码中插入语句以收集程序数据，例如计算每个 分支的每一侧被遍历了几次，或者每一段代码是否都被执 行过，执行了几次 测试覆盖率是对最后的测试结果提供度量的信任标准 理解缺陷的定义和测试过程中对缺陷管理的必要性 软件缺陷的生命周期：打开、解决和关闭 缺陷管理报告中应该包含对于整个缺陷涉及到的各种因素 进行管理,