软件测试技术_第三章软件测试管理
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
(4) 测试有效性度量
1．缺陷消除率
测试期间发现的缺陷数量 DRE= 测试期间发现的缺陷数量＋未发现的缺陷数量
2．缺陷损耗
损耗＝ 缺陷数量 发现的阶段潜伏期尺度 缺陷总量
Software Testing
（5）缺陷管理工具
IBM-Rational ClearQuest Bugzilla
Software Testing
缺陷严重程度Software Testing
缺陷严重等级
描述
严重缺陷 不能执行正常工作功能或重要功能，使系统 （Critical） 崩溃或资源不足；或者危及人身安全。
较大缺陷 （Major）
严重地影响系统要求或基本功能的实现，且 没有办法更正。
一般缺陷 严重地影响系统要求或基本功能的实现，但 （Average） 存在合理的更正办法。
Software Testing
测试计划解决的问题
(1) 测试的目标和范围：包括产品的特性、
质量目标、各测试阶段的测试对象、目标、 范围和约束条件；
(2) 测试工期估算、进度安排和资源配置。 (3) 测试风险评估。 (4) 确定不同测试阶段的过渡条件。 (5) 测试版本的管理。
Software Testing
功能错误 功能遗漏 超出需求的部分 性能不符合要求
Software Testing
缺 陷 存 在 放 大 趋 势
问题发现越早，解决问题的代价就越小。
缺陷的处理 Software Testing
郎中治病的故事
在中国古代，有一家三兄弟全是郎中。其中老 三是名医，人们问他：“你们兄弟三人谁的医术 最高？”
次要缺陷 （Minor）
使操作者不方便或遇到麻烦，但它不影响执 行工作功能或重要功能。
改进型缺陷 系统使用的友好性存在问题 （Enhancement）
Software Testing
缺陷解决的优先级
解决优先级
描述
立即解决
(Resolve Immediately)
正常排队
(Normal Queue)
5.软件测试管理工具
HP-Mercury Test Director IBM-Rational Test Manager Bugzilla Test Runner
作业
试描述缺陷的管理流程
Software Testing
在编码阶段发现的缺陷
测试
Test
在测试阶段发现的缺陷
缺陷来源 Software Testing
缺陷状态
描述
需求
由于需求的问题引起的缺陷
Requriement
架构
由于架构的问题引起的缺陷
Architecture
设计
Design
由于设计的问题引起的缺陷
代码
Code
由于编码的问题引起的缺陷
集成
由于集成的问题引起的缺陷
修正
缺陷被开发人员修复，等待测试人员
（Fixed） 验证
已关闭
（Closed）
确认被修复的缺陷，将其关闭
缺陷起源 Software Testing
缺陷状态
描述
需求
在需求阶段发现的缺陷
Requriement
架构
在架构阶段发现的缺陷
Architecture
设计
Design
在设计阶段发现的缺陷
代码
Code
简单公式：测试用例=输入+输出+环境 具体：测试用例必须给出测试目标、测试对象、
测试环境、前提条件、输入数据、测试步骤和预 期结果
Software Testing
2.软件缺陷的管理
缺陷的定义 缺陷的管理 缺陷的管理流程 缺陷的有效性度量 缺陷的管理工具
Software Testing
（1）缺陷的定义
他回答说：“我常用猛药给病危者医治，偶尔 有些病危者被我救活，于是我的医术远近闻名并 成了名医。我二哥通常在人们刚刚生病的时候马 上就治愈他们，临近村庄的人说他是好郎中。我 大哥不外出治病，他深知人们生病的原因，所以 能够预防家里人生病，他的医术只有我们家里才 知道。”
Software Testing
3.测试团队建设与管理
测试团队的建设； 测试经理 测试小组
Software Testing
测试团队的建设
有效的软件测试项目团队具有以下特征：
对软件项目的测试目标有清晰的理解； 对每位测试工程师的角色和职责有明确的期望； 以目标为导向； 高度的互助合作； 高度的信任；
Software Testing
缺陷产生的原因
软件本身的复杂性 开发人员的问题,对代码规范、文档不重视 需求的变化 进度压力 沟通不畅 ，导致偏差的累积
Software Testing
Software Testing
Software Testing
（2）缺陷的管理
为了更好地分析缺陷，需要对缺陷在严
重程度、优先级以及状态上加以区分。 缺陷严重程度（Severity）； 缺陷优先级（Priority）； 缺陷状态（Status）； 缺陷起源（Origin）； 缺陷来源（Source）；
Software Testing
软件测试管理
南通大学杏林学院
Software Testing
软件测试管理
本章内容
基本概念 软件缺陷管理 测试团队建设与管理 测试计划
Software Testing
1.基本概念
测试用例(Test Case)
测试用例是为特定的目的而设计的一组测试输入、
执行条件和预期的结果。
(3) 开发人员对标记为Open状态的缺陷进行确认，若不是缺
陷，状态修改为Declined，若是则进行修复，并修改状态为 Fixed。对于不能解决的缺陷，提交到项目组会议评审，以 做出延期或进行修改等决策。
(4) 缺陷修复并由测试人员验证后，确认已修复，才能关闭。
Software Testing
缺陷必须被立即解决。
缺陷需要正常排队等待修复 或列入软件发布清单。
不紧急
(Not Urgent)
缺陷可以在方便时被纠正。
缺陷状态 Software Testing
缺陷状态
描述
新缺陷
（New）
测试中发现的新缺陷
打开
（Open）
被确认并分配给开发人员处理
拒绝
拒绝“提交的缺陷”，不需要修复或
（Declined） 不是缺陷
Integration
Software Testing
（3）缺陷的管理流程
(1) 测试人员发现软件缺陷，提交新Bug入库，缺陷状态为
New。
(2) 软件测试经理或高级测试经理，若确认是缺陷，分配给
相应的开发人员，设置为Open状态，若不是缺陷(或缺陷描 述不清楚)，则拒绝，设置为Declined状态
为什么缺陷很难被找出？
软件的特殊性决定了缺陷不易看到,即”
看不到”;
发现了缺陷,但不易找到问题发生的原
因所在,即“看到但是抓不到”。
软件缺陷产生的来源
Software Testing
编写代码 15%
其他 4%
设计 26%
编制说明书 设计 编写代码 其他
编制说明书 55%
Software Testing
测试小组
在不同的软件企业，开发团队的组织模式有
差别，按测试小组的独立性来划分可分为：
非独立测试小组 相对独立测试小组 独立测试小组
Software Testing
测试经理
项目经理的基本职责：
测试项目的计划 组织 控制
Software Testing
4.软件测试计划
测试计划解决的问题 测试计划跟踪和控制
典型定义：
Bug是未曾预料到的系统行为 Bug是程序与规格说明之间的不匹配
IEEE(1983)标准定义：
从产品内部看，软件缺陷是软件产品开发或维护
过程中所存在的错误、毛病等各种问题。
从产品外部看，软件缺陷是系统所需实现的某种
功能的失效或违背。
Software Testing
一般认为符合以下条件的都为缺陷
测试计划跟踪和控制
制定测试基准计划 (进度、预算等)
等待，直到下 一个报告期
开始测试 每个报告期内
收集实际进程数据 (进度、成本等)
将变化列入测试பைடு நூலகம்划 (范围、进度、预算等)
计算出更新的测试进度、 预算和预测等
分析当前状况并与计划 比较(进度、预算等)
N
需采取措施吗
Y
采取措施和协调 相关变化
Software Testing
1．缺陷消除率
测试期间发现的缺陷数量 DRE= 测试期间发现的缺陷数量＋未发现的缺陷数量
2．缺陷损耗
损耗＝ 缺陷数量 发现的阶段潜伏期尺度 缺陷总量
Software Testing
（5）缺陷管理工具
IBM-Rational ClearQuest Bugzilla
Software Testing
缺陷严重程度Software Testing
缺陷严重等级
描述
严重缺陷 不能执行正常工作功能或重要功能，使系统 （Critical） 崩溃或资源不足；或者危及人身安全。
较大缺陷 （Major）
严重地影响系统要求或基本功能的实现，且 没有办法更正。
一般缺陷 严重地影响系统要求或基本功能的实现，但 （Average） 存在合理的更正办法。
Software Testing
测试计划解决的问题
(1) 测试的目标和范围：包括产品的特性、
质量目标、各测试阶段的测试对象、目标、 范围和约束条件；
(2) 测试工期估算、进度安排和资源配置。 (3) 测试风险评估。 (4) 确定不同测试阶段的过渡条件。 (5) 测试版本的管理。
Software Testing
功能错误 功能遗漏 超出需求的部分 性能不符合要求
Software Testing
缺 陷 存 在 放 大 趋 势
问题发现越早，解决问题的代价就越小。
缺陷的处理 Software Testing
郎中治病的故事
在中国古代，有一家三兄弟全是郎中。其中老 三是名医，人们问他：“你们兄弟三人谁的医术 最高？”
次要缺陷 （Minor）
使操作者不方便或遇到麻烦，但它不影响执 行工作功能或重要功能。
改进型缺陷 系统使用的友好性存在问题 （Enhancement）
Software Testing
缺陷解决的优先级
解决优先级
描述
立即解决
(Resolve Immediately)
正常排队
(Normal Queue)
5.软件测试管理工具
HP-Mercury Test Director IBM-Rational Test Manager Bugzilla Test Runner
作业
试描述缺陷的管理流程
Software Testing
在编码阶段发现的缺陷
测试
Test
在测试阶段发现的缺陷
缺陷来源 Software Testing
缺陷状态
描述
需求
由于需求的问题引起的缺陷
Requriement
架构
由于架构的问题引起的缺陷
Architecture
设计
Design
由于设计的问题引起的缺陷
代码
Code
由于编码的问题引起的缺陷
集成
由于集成的问题引起的缺陷
修正
缺陷被开发人员修复，等待测试人员
（Fixed） 验证
已关闭
（Closed）
确认被修复的缺陷，将其关闭
缺陷起源 Software Testing
缺陷状态
描述
需求
在需求阶段发现的缺陷
Requriement
架构
在架构阶段发现的缺陷
Architecture
设计
Design
在设计阶段发现的缺陷
代码
Code
简单公式：测试用例=输入+输出+环境 具体：测试用例必须给出测试目标、测试对象、
测试环境、前提条件、输入数据、测试步骤和预 期结果
Software Testing
2.软件缺陷的管理
缺陷的定义 缺陷的管理 缺陷的管理流程 缺陷的有效性度量 缺陷的管理工具
Software Testing
（1）缺陷的定义
他回答说：“我常用猛药给病危者医治，偶尔 有些病危者被我救活，于是我的医术远近闻名并 成了名医。我二哥通常在人们刚刚生病的时候马 上就治愈他们，临近村庄的人说他是好郎中。我 大哥不外出治病，他深知人们生病的原因，所以 能够预防家里人生病，他的医术只有我们家里才 知道。”
Software Testing
3.测试团队建设与管理
测试团队的建设； 测试经理 测试小组
Software Testing
测试团队的建设
有效的软件测试项目团队具有以下特征：
对软件项目的测试目标有清晰的理解； 对每位测试工程师的角色和职责有明确的期望； 以目标为导向； 高度的互助合作； 高度的信任；
Software Testing
缺陷产生的原因
软件本身的复杂性 开发人员的问题,对代码规范、文档不重视 需求的变化 进度压力 沟通不畅 ，导致偏差的累积
Software Testing
Software Testing
Software Testing
（2）缺陷的管理
为了更好地分析缺陷，需要对缺陷在严
重程度、优先级以及状态上加以区分。 缺陷严重程度（Severity）； 缺陷优先级（Priority）； 缺陷状态（Status）； 缺陷起源（Origin）； 缺陷来源（Source）；
Software Testing
软件测试管理
南通大学杏林学院
Software Testing
软件测试管理
本章内容
基本概念 软件缺陷管理 测试团队建设与管理 测试计划
Software Testing
1.基本概念
测试用例(Test Case)
测试用例是为特定的目的而设计的一组测试输入、
执行条件和预期的结果。
(3) 开发人员对标记为Open状态的缺陷进行确认，若不是缺
陷，状态修改为Declined，若是则进行修复，并修改状态为 Fixed。对于不能解决的缺陷，提交到项目组会议评审，以 做出延期或进行修改等决策。
(4) 缺陷修复并由测试人员验证后，确认已修复，才能关闭。
Software Testing
缺陷必须被立即解决。
缺陷需要正常排队等待修复 或列入软件发布清单。
不紧急
(Not Urgent)
缺陷可以在方便时被纠正。
缺陷状态 Software Testing
缺陷状态
描述
新缺陷
（New）
测试中发现的新缺陷
打开
（Open）
被确认并分配给开发人员处理
拒绝
拒绝“提交的缺陷”，不需要修复或
（Declined） 不是缺陷
Integration
Software Testing
（3）缺陷的管理流程
(1) 测试人员发现软件缺陷，提交新Bug入库，缺陷状态为
New。
(2) 软件测试经理或高级测试经理，若确认是缺陷，分配给
相应的开发人员，设置为Open状态，若不是缺陷(或缺陷描 述不清楚)，则拒绝，设置为Declined状态
为什么缺陷很难被找出？
软件的特殊性决定了缺陷不易看到,即”
看不到”;
发现了缺陷,但不易找到问题发生的原
因所在,即“看到但是抓不到”。
软件缺陷产生的来源
Software Testing
编写代码 15%
其他 4%
设计 26%
编制说明书 设计 编写代码 其他
编制说明书 55%
Software Testing
测试小组
在不同的软件企业，开发团队的组织模式有
差别，按测试小组的独立性来划分可分为：
非独立测试小组 相对独立测试小组 独立测试小组
Software Testing
测试经理
项目经理的基本职责：
测试项目的计划 组织 控制
Software Testing
4.软件测试计划
测试计划解决的问题 测试计划跟踪和控制
典型定义：
Bug是未曾预料到的系统行为 Bug是程序与规格说明之间的不匹配
IEEE(1983)标准定义：
从产品内部看，软件缺陷是软件产品开发或维护
过程中所存在的错误、毛病等各种问题。
从产品外部看，软件缺陷是系统所需实现的某种
功能的失效或违背。
Software Testing
一般认为符合以下条件的都为缺陷
测试计划跟踪和控制
制定测试基准计划 (进度、预算等)
等待，直到下 一个报告期
开始测试 每个报告期内
收集实际进程数据 (进度、成本等)
将变化列入测试பைடு நூலகம்划 (范围、进度、预算等)
计算出更新的测试进度、 预算和预测等
分析当前状况并与计划 比较(进度、预算等)
N
需采取措施吗
Y
采取措施和协调 相关变化
Software Testing