Version 3.0
第 五 章度量测试结果与缺陷管理回顾
良好的测试设计由若干个防范组成。
在单元测试中，测试应设计为检验各个单元是否实现了该单元的设计说明书中的所有设计 判定 。
单元测试说明书由一系列单元测试用例组成。
测试用例设计技术可以大体分成黑盒和白盒两个主要类别。
缺陷猜测主要凭借测试设计者的经验。
本章目标
对测试本身信任程度的量度
明白何时进行测试和使用覆盖率
进行缺陷管理简介
测试全貌：测试计划、实际测试和写测试报告
度量是软件工程过程的一个关键要素。
度量标准用于理解所创建的模型的属性。
监视测试覆盖率
对于测试结果的评价，需要监视测试覆盖率。
要减少要测试的条件的数量，可以将系统分成多个独立的部分。
这样可以为代码测试的各个部分分别生成不同的条件组合。
逻辑覆盖测试方法 4-1
语句覆盖选择足够的测试用例，使得程序中每一条可执行语句至少被执行一次。
判定覆盖选择足够的测试用例，使得程序中每一个分支判断的每一种可能结果 (主要指 switch-case
情况 )都至少被执行一次。判定覆盖也叫分支覆盖。
条件覆盖选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的可能结果都至少被执行一次。
逻辑覆盖测试方法 4-2
判定 /条件覆盖选择足够的测试用例，使得同时满足判定覆盖和条件覆盖。
条件组合覆盖选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的每一种可能组合结果都至少被执行一次。
路径覆盖选择足够的测试用例，使得程序中所有的可能路径都至少被执行一次。
逻辑覆盖测试方法 4-3
语句覆盖判定覆盖 条件覆盖判定 /条件覆盖条件组合覆盖路径覆盖逻辑覆盖测试方法 4-4
需要完成的各种测试包括,
– 单元测试
– 集成测试
– 系统测试
– 验收测试
– 回归测试
在验收和回归测试后，对于覆盖率测试达到一定标准后，我们即发布软件。
测试覆盖率涉及的测试什么是缺陷？
缺陷可以定义成：
– 没有实现预定的使用需求或合理期望
– 与规格说明书或标准存在偏差
– 在与标准的一致性方面导致客户不满的任何问题为什么需要缺陷管理？
客户期望以较少的时间 /成本获得较高的质量。
规格说明书在项目开发生命周期的后期往往会被修改。
测试所发现的缺陷常常会招致大量的软件开发成本。
新的开发方法、工具不断地实现。
软件管理不能让测试成为瓶颈并减慢开发速度。
测试需要快速、灵活和可靠。
我们需要有关测试充分性的证据。
缺陷的生命周期缺陷管理 ——Defect级别
致命性缺陷（ Critical）
数据丢失，数据计算缺陷、系统崩溃和非常死机
严重功能性缺陷 (Serious)
规定的功能没有实现或不完整、设计不合理造成性能低下，影响系统的运营
警告性缺陷 (Moderate)
不影响业务运营的功能问题
建议性缺陷 (Suggestion,Cosmetic)
软件设计和功能实现等不甚合理之处提出建议缺陷管理 ——修改的优先级
高优先级
中优先级
低优先级缺陷管理 ——缺陷描述
1 分配给缺陷的 ID号 2 提交缺陷的时间
3 缺陷提交人 4 版本号发生缺陷的子系统或模块
5 缺陷发生的条件 6 对缺陷的详细描述
7 所使用的测试用例号 8 缺陷被发现的数据库
9 使用的机器号 10 缺陷的重要性
11 缺陷的改正优先级 12发生缺陷的子系统或模块及相关的模块
13 缺陷是否易再现 14 其他缺陷管理 ——与缺陷跟踪有关项
1 缺陷负责人 6 缺陷改正后需要重新做 的测试
2 严重性 7 改正缺陷所影响的组件
3 优先级 8 目前缺陷的状态
4 估计改正缺陷的日期 9 缺陷类别
5 估计改正缺陷所要花费的时间 10 解决办法缺陷管理 ——缺陷分发对象
项目管理者
测试管理者
被分配修改缺陷的人
组件代码的编写人
测试小组中的其他成员缺陷管理的实现阶段 2-1
这些阶段如下所示：
– 缺陷标识、记录和报告
– 缺陷的消除和跟踪
– 缺陷测量和根由分析
– 缺陷预防 /过程改进
– 软件开发生命周期所有阶段的测试
– 安装测试工具缺陷管理的实现阶段 2-2
– 缺陷管理问题包括：
缺陷遗漏同类缺陷重复精力分散
– 效率低
– 数据库更新不完全
– 分类不严谨 - 每个缺陷都被划分为缺陷的类型
– 用来攻击项目分类的缺陷数据
– 很多不负责任的缺陷
– 重臵是一个瓶颈
– 相同的缺陷卷土重来缺陷状态信息
缺陷状态信息应该包含下列信息：
– 缺陷的当前状态和状态历史记录描述
– 状态历史记录，包括描述日期、操作、执行者、
实际工作量、结果状态和指定的下一个步骤的行。
– 下一个步骤估计需要付出的努力
– 完成的期望日期
– 缺陷分析和度量
– 缺陷生命周期分布有助于深入了解缺陷结束所花天数、修复缺陷所需付出的努力和进度分析
– 对预计付出的努力相对于实际付出的努力的分析缺陷报告 3-1
进行缺陷报告前执行的过程,
– 获取空白的缺陷表格
– 指定可用的信息
– 信息可用时不断更新
– 对缺陷信息进行分类，包括一般信息缺陷检测信息缺陷消除信息状态信息
– 估计要投入的努力、预计日期、实际日期以及缺陷在其整个生命周期中的变化。
所需的缺陷信息有：
– 有关缺陷性质、它的修复优先级等的基本信息；
– 描述 - 简要的文字
– 优先级（紧急、普通、不急） [您的优先级，客户的优先级 ]
– 严重程度（主要、次要、不严重） [您的优先级，
客户的优先级 ]
– 原因关键字（用于进一步分析）
– 症状（数据库损坏、可视数据缺陷、
界面缺陷、等等）
缺陷报告 3-2
– 起源的阶段
– 找到的阶段
– 报告的数据
– 期望和实际的结束日期
– 描述
– 版本、日志、周期、过程、用例 - 发现缺陷的地方
– 报告者：（姓名、公司）
– 硬件操作系统 - 发现缺陷的平台
– 测试位臵
– 附件 /附加信息缺陷报告 3-3
缺陷报告（印）
总结 2-1
度量是软件工程过程的一个关键要素。
可以在源代码中插入语句以收集程序数据，
例如计算每个分支的每一侧被遍历了几次，
或者每一段代码是否都被执行过，执行了几次。
测试覆盖率是对最后的测试结果提供度量的信任标准。
理解缺陷的定义和测试过程中对缺陷管理的必要性总结 2-2
软件缺陷的生命周期：打开、解决和关闭。
缺陷管理报告中应该包含对于整个缺陷涉及到的各种因素进行管理。
第 五 章度量测试结果与缺陷管理回顾
良好的测试设计由若干个防范组成。
在单元测试中，测试应设计为检验各个单元是否实现了该单元的设计说明书中的所有设计 判定 。
单元测试说明书由一系列单元测试用例组成。
测试用例设计技术可以大体分成黑盒和白盒两个主要类别。
缺陷猜测主要凭借测试设计者的经验。
本章目标
对测试本身信任程度的量度
明白何时进行测试和使用覆盖率
进行缺陷管理简介
测试全貌：测试计划、实际测试和写测试报告
度量是软件工程过程的一个关键要素。
度量标准用于理解所创建的模型的属性。
监视测试覆盖率
对于测试结果的评价，需要监视测试覆盖率。
要减少要测试的条件的数量，可以将系统分成多个独立的部分。
这样可以为代码测试的各个部分分别生成不同的条件组合。
逻辑覆盖测试方法 4-1
语句覆盖选择足够的测试用例，使得程序中每一条可执行语句至少被执行一次。
判定覆盖选择足够的测试用例，使得程序中每一个分支判断的每一种可能结果 (主要指 switch-case
情况 )都至少被执行一次。判定覆盖也叫分支覆盖。
条件覆盖选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的可能结果都至少被执行一次。
逻辑覆盖测试方法 4-2
判定 /条件覆盖选择足够的测试用例，使得同时满足判定覆盖和条件覆盖。
条件组合覆盖选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的每一种可能组合结果都至少被执行一次。
路径覆盖选择足够的测试用例，使得程序中所有的可能路径都至少被执行一次。
逻辑覆盖测试方法 4-3
语句覆盖判定覆盖 条件覆盖判定 /条件覆盖条件组合覆盖路径覆盖逻辑覆盖测试方法 4-4
需要完成的各种测试包括,
– 单元测试
– 集成测试
– 系统测试
– 验收测试
– 回归测试
在验收和回归测试后，对于覆盖率测试达到一定标准后，我们即发布软件。
测试覆盖率涉及的测试什么是缺陷？
缺陷可以定义成：
– 没有实现预定的使用需求或合理期望
– 与规格说明书或标准存在偏差
– 在与标准的一致性方面导致客户不满的任何问题为什么需要缺陷管理？
客户期望以较少的时间 /成本获得较高的质量。
规格说明书在项目开发生命周期的后期往往会被修改。
测试所发现的缺陷常常会招致大量的软件开发成本。
新的开发方法、工具不断地实现。
软件管理不能让测试成为瓶颈并减慢开发速度。
测试需要快速、灵活和可靠。
我们需要有关测试充分性的证据。
缺陷的生命周期缺陷管理 ——Defect级别
致命性缺陷（ Critical）
数据丢失，数据计算缺陷、系统崩溃和非常死机
严重功能性缺陷 (Serious)
规定的功能没有实现或不完整、设计不合理造成性能低下，影响系统的运营
警告性缺陷 (Moderate)
不影响业务运营的功能问题
建议性缺陷 (Suggestion,Cosmetic)
软件设计和功能实现等不甚合理之处提出建议缺陷管理 ——修改的优先级
高优先级
中优先级
低优先级缺陷管理 ——缺陷描述
1 分配给缺陷的 ID号 2 提交缺陷的时间
3 缺陷提交人 4 版本号发生缺陷的子系统或模块
5 缺陷发生的条件 6 对缺陷的详细描述
7 所使用的测试用例号 8 缺陷被发现的数据库
9 使用的机器号 10 缺陷的重要性
11 缺陷的改正优先级 12发生缺陷的子系统或模块及相关的模块
13 缺陷是否易再现 14 其他缺陷管理 ——与缺陷跟踪有关项
1 缺陷负责人 6 缺陷改正后需要重新做 的测试
2 严重性 7 改正缺陷所影响的组件
3 优先级 8 目前缺陷的状态
4 估计改正缺陷的日期 9 缺陷类别
5 估计改正缺陷所要花费的时间 10 解决办法缺陷管理 ——缺陷分发对象
项目管理者
测试管理者
被分配修改缺陷的人
组件代码的编写人
测试小组中的其他成员缺陷管理的实现阶段 2-1
这些阶段如下所示：
– 缺陷标识、记录和报告
– 缺陷的消除和跟踪
– 缺陷测量和根由分析
– 缺陷预防 /过程改进
– 软件开发生命周期所有阶段的测试
– 安装测试工具缺陷管理的实现阶段 2-2
– 缺陷管理问题包括：
缺陷遗漏同类缺陷重复精力分散
– 效率低
– 数据库更新不完全
– 分类不严谨 - 每个缺陷都被划分为缺陷的类型
– 用来攻击项目分类的缺陷数据
– 很多不负责任的缺陷
– 重臵是一个瓶颈
– 相同的缺陷卷土重来缺陷状态信息
缺陷状态信息应该包含下列信息：
– 缺陷的当前状态和状态历史记录描述
– 状态历史记录，包括描述日期、操作、执行者、
实际工作量、结果状态和指定的下一个步骤的行。
– 下一个步骤估计需要付出的努力
– 完成的期望日期
– 缺陷分析和度量
– 缺陷生命周期分布有助于深入了解缺陷结束所花天数、修复缺陷所需付出的努力和进度分析
– 对预计付出的努力相对于实际付出的努力的分析缺陷报告 3-1
进行缺陷报告前执行的过程,
– 获取空白的缺陷表格
– 指定可用的信息
– 信息可用时不断更新
– 对缺陷信息进行分类，包括一般信息缺陷检测信息缺陷消除信息状态信息
– 估计要投入的努力、预计日期、实际日期以及缺陷在其整个生命周期中的变化。
所需的缺陷信息有：
– 有关缺陷性质、它的修复优先级等的基本信息；
– 描述 - 简要的文字
– 优先级（紧急、普通、不急） [您的优先级，客户的优先级 ]
– 严重程度（主要、次要、不严重） [您的优先级，
客户的优先级 ]
– 原因关键字（用于进一步分析）
– 症状（数据库损坏、可视数据缺陷、
界面缺陷、等等）
缺陷报告 3-2
– 起源的阶段
– 找到的阶段
– 报告的数据
– 期望和实际的结束日期
– 描述
– 版本、日志、周期、过程、用例 - 发现缺陷的地方
– 报告者：（姓名、公司）
– 硬件操作系统 - 发现缺陷的平台
– 测试位臵
– 附件 /附加信息缺陷报告 3-3
缺陷报告（印）
总结 2-1
度量是软件工程过程的一个关键要素。
可以在源代码中插入语句以收集程序数据，
例如计算每个分支的每一侧被遍历了几次，
或者每一段代码是否都被执行过，执行了几次。
测试覆盖率是对最后的测试结果提供度量的信任标准。
理解缺陷的定义和测试过程中对缺陷管理的必要性总结 2-2
软件缺陷的生命周期：打开、解决和关闭。
缺陷管理报告中应该包含对于整个缺陷涉及到的各种因素进行管理。
