测试评估

ODC分析应用
• Defect 按引入的模块或者负责开发人员来分
缺 陷 数 量
缺 陷 数 量
缺 陷 数 量
A
B
C
D
A
B
C
D
A
B
C
D
不同的模块，缺陷数量不同
ODC单维度分析
各类缺陷按界定所占比例图
遗漏
17.00%
48.90%
错误 多余
遗漏
错误
34.10% 多余
ODC多维度分析
各类触发因素发现各类缺陷数统计
基本应用
量化评估和预测 − 评估产品质量
− 预测现场缺陷（通过调节因子提高预测有效性）
开发过程质量管理 − 缺陷率的峰值越早出现越好
− 尽可能降低Rayleigh 曲线
Rayleigh 模型的应用
Rayleigh 曲线
相关系数0.995 表明估计的精 确度较高。
估计发现缺陷 实际发现缺陷
测试执行最终结果
总的测试用例 测试结果 通过 6762 数量 6021 91.69% 占比（%） 89.04%
4.17%4.14% 1.04% 1.61%
Passed
Investigated
Failed
跟踪
失败 阻塞 其他
109
70 282 280
1.61%
1.04% 4.17% 4.14% 89.04%
2、直接目的
改进开发过程 发现软件缺陷
测试评估的概念
• 测试评估
– 测试评估是在测试结束后（后期）对整个测试过程与 产品进行评估的过程，主要包括对于测试工作的总结、 缺陷数据的分析以及测试过程的评估。
测试评估： 对整个测试过程与产品进行评估
测试评估的目的
• 检查软件产品是否满足客户需求－－最终目的 • 发现软件产品的程序错误－－直接目的 • 改进软件开发过程－ －附带目的/增值目的
标准符合性
赋值/初始化 条件检测 /分支 算法实现 函数/类/对象设计 接口/消息 技术 当地语言支持
准确性 设计一致性 编成基础 测试单运行覆盖 测试单运行边界/单选输入
0
10
20 缺陷数
30
40
四象限分析总览
特性/模块稳定性四象限分析图 60 遗 留 缺 陷 密 度 极不稳定
50 40
30
不稳定
累 计 缺 陷 数 20 0 15 0 10 0 5 0 0
a
实际缺陷增长趋势
3/15 3/25 3/05 3/15 3/25 4/05
a b
ODC分析
原因
结果
还可以结合 问题发现日 期、问题发 现阶段等字 段进行分析
触发因素
结果影响
验证
问题发现活动 验证程度
验证
开发
缺陷类型 内容类型 缺陷界定 问题根源对象
预测build或产品的极限缺陷及退出测试所需要时间 – 最后一轮测试的样本点应在90%置信限以内；
– 被测试对象的缺陷去除率DRE应达到或超过95%;
– Gompertz曲线的相关系数应达到或大于0.99,如果未达到该要求，则 判断缺陷密度质量目标是否达到。 指导测试计划和测试策略调整
Gompertz应用
我们已经知道一个版本发布时的平均发现缺陷密度和测试投入密度。
四象限分析的应用
最好情况- 高工作量投入密度/低发现缺陷密度 正常情况-高工作量投入密度/高发现缺陷密度 最坏情况-低工作量投入密度/高发现缺陷密度 不确定情况-低工作量投入密度/低发现缺陷密度
Rayleigh 分析原理
0
10 不确定
20
20 30 10 0 工作量密度
40Байду номын сангаас
50 稳定
遗 留 缺 陷 密 度
60
高
差
不确定
低
一般
好
高
低
工作量密度
四象限分析应用
四象限分析的原理
四象限分析是一种应用广泛的分析方法，它基于测试投入与产出的比较，
来近似判断各特性的测试质量情况，其使用的前提假设条件是：
各特性的测试投入质量是一致的，相同的测试工作量投入带来的测试 回报大体一致的；
产品策划缺陷数据 缺陷分析原始 数据
ODC分析
按ODC标准分类后 ODC分析报告 的产品测试缺陷数 据 特性级缺陷数据 缺陷分析报告
四象限分 析
Gompertz分析总览
累计缺陷趋势图
累 200 计 缺 150 陷 数 100 50 实际缺陷增长趋势 0
3/15 3/25 3/05 3/15 3/25 4/05
测试评估
致力成为业内领先的云计算整体解决方案提供商
目录
第一章 测试评估的定义和目的
第二章 测试评估的流程和方法
第三章 测试退出的评估和标准
第四章 其他测试评估相关内容
测试评估
测试评估的定义和目的
软件测试生命周期
测试计划
测试设计
测试开发
测试评估 测试执行
软件测试的目的
验证用户需求 1、最终目的 3、附加目的
基于需求的测试覆盖 测试覆盖（已执行的）= Tx / RfT 成功的测试覆盖（已执行的）= Ts / RfT Tx ：已执行的测试用例总数 Ts：完全成功、没有缺陷的已执行测测试用例数 RfT是测试需求（Requirement for Test）的总数 基于代码的测试覆盖 测试覆盖 = Tc / Tiic Tc 已执行的代码行
Tiic 代码总行数
测试评估-测试覆盖评估
• 测试覆盖评估
– 需求覆盖一般和功能测试与黑盒测试技术相关；代码覆盖一般和结 构测试与白盒测试技术相关。
– 用户直接关心测试的需求覆盖率，看产品是否符合自己的要求；而 技术人员关心测试的代码覆盖率，看产品是否存在技术上的缺陷。
测试评估-产品质量评估
• 产品质量评估重点关注
缺 陷 数
统计极限缺陷数220个，已经 发现208个，内部测试的缺陷 去除率达标94.5%。内部测试 质量较高。 现场可能遗留缺陷12个。
0
测试周期
Rayleigh 曲线 K= tm= 219.65 2.667
统计分析 相关关系 标准偏差 极限缺陷 残余缺陷 0.9954 3.511 220 12
• 趋势分析（图例）
– 通过下图我们可以很容易地观察出缺陷发现的波动和异常情况，从而进一步
分析如何开展下步工作。
测试退出评估2
• 累计用例覆盖度
– 累计用例覆盖度实际上是一种测试进度的体现（缺省认为用例的覆盖就是对需求的覆 盖），用例覆盖度应该多为测试项目完成退出的一个重要指标（90%以上？）。
测试用例总数 通过测试用例发现的缺陷数 缺陷发现总数 其中：致命缺陷 重大缺陷 一般缺陷 提示缺陷 6762 406 806 12 146 597 51 测试用例有效率（ % ） 缺陷发现生产率(缺陷 /人天) 测试用例执行率(测试用例/人天) 50.37% 1.03 8.68 测试执行持续(人天) 779
正确性
可维护性
灵活性 可测试性 产品转移 可移植性
可靠性 效率 完整性 可使用性
重复使用
连接性
测试评估
测试评估的流程和方法
测试评估的主要内容
• 对软件质量的评估
– 评估软件产品的质量状况 – 为产品放行提供决策依据
• 对软件生产过程的评估
– 为过程流程改进提供依据 – 评估项目人员的工作绩效
– ……
Blocked
Other
测试退出评估3
• 累计用例覆盖度（续）
– 从下图可以看出，缺陷的增加和用例覆盖度的增长基本呈正比关系，如果我们的用例 覆盖度只有不到50%，那么我们可以推测可能还有一半的缺陷没有发现出来。
用例覆盖和发现缺陷的关系
900 87.00% 800 700 661 600 500 400 300 200 100 0 0.00% 0 307 60.00% 592 83.00% 723 90.90% 1.00 0.90 0.80 0.70 0.60 0.50 累计缺陷发现数 累计用例覆盖度
开始 No
最后一轮样本在 90%的置信区间 内？
Yes
No
缺陷去除率 DRE ≧ 95% Yes No 相关系数r ≧0.99
No
缺陷密度目 标是否达到？ Yes
Yes
继续测试
退出 测试
Gompertz应用
• 从缺陷分类的角度，累计缺陷数趋势图也应遵循该模 型：
– – – – 按缺陷严重程度（致命、严重、一般、提示） 按引起缺陷的根本原因/引入阶段（SRS、HLD、LLD、CODE） 按缺陷性质（遗漏、错误、多余） 按缺陷触发因素（函数/类/对象设计、标准化、接口……） cT Y=ab 累计缺陷趋势图
对测试策略的要求
– 在每轮测试执行前，进行测试用例完备性评估，保证用例设计基本完备； – 在每轮测试执行前，进行上一轮测试的缺陷解决情况的检查，上一轮测试的缺
陷关闭率应达到80%以上，以确保被测试度对象实际的可靠性及时得到提高。
Gompertz应用
评估测试效率
– 由Gompertz模型参数c的物理意义可知，c值越大（越接近1）， 表明缺陷下降的速度越慢，测试达到饱和的时间相对越长。
责任来源
问题位置 缺陷年龄
开发
定位
ODC分析应用
分类 分析
需求
概设
详设
Code
UT
ST
ODC分析应用
• Defect 严重程度分类
严重：1 一般：2 提示：3 建议：4
缺 陷 数 量
缺 陷 数 量
缺 陷 数 量
严 一 重 般
提 建 示 议
严 一 重 般
提 建 示 议
严 一 重 般
提 建 示 议
不同的测试阶段，缺陷分布不同
Rayleigh 曲线
f(t)=K t
2
1 m
2
te
2tm 2
缺 陷 数
估计发现缺陷 实际发现缺陷
0
测试周期
Rayleigh 模型的应用
基本假设
开发过程中的缺陷发现率与现场的缺陷发现率成正比——Myers定律 在缺陷数一定的情况下，如果越多的缺陷被越早发现和清除，那在后面阶段
遗漏的缺陷就越少——现场缺陷少。
– 从量化的角度，依据统一的标准，分析缺陷在产品中存在的趋 势及各类属性，从而达到评估产品质量的主要目的。
• 通过缺陷分析，能为产品的质量评估提供客观、全面的依据
– 将过程管理能力的分析和产品质量的分析区别开，便于改进措施的 聚焦。
1、缺陷分析报告 2、性能分析报告
测试评估-产品质量评估方法
主要活动
– 代码覆盖
• 测试质量评估——专注于测试结果
对测试对象的可靠性、稳定性以及性能等的测评。质量建立在对测试
结果的评估和对测试过程中缺陷的分析基础上： – 缺陷分析报告 – 性能评测报告
测试评估-测试覆盖评估
• 测试覆盖评估
– 测试覆盖是对测试完全程度的评估，测试覆盖（程）度决定了软件 测试的质量如何； – 可分基于需求的测试的测试覆盖和基于代码的测试覆盖：
重点关注对产品质量的评估
测试评估流程
开始 No
测试覆盖满足？
Yes
Yes
Gompertz No No ODC Yes No Four Quadrant Analysis Yes 结束
继续
测试评估方法
• 测试覆盖评估——专注于测试过程
对测试完全程度的评估，以测试用例和已执行测试的覆盖程度表 示： – 需求覆盖
测试评估
测试退出的评估和标准
测试什么时候结束？
• 几种观点：
– 测试没有止境，只是从开发转到测试，测试转到维护，维
护转到客户/用户，客户/用户的每一次使用就是一次测 试。 – “没有时间了、没有钱了…”---当用于软件测试的时间、资 金等资源不够的时候，就到了测试该结束的时候。
– 使用概率统计和软件可靠性理论建立软件故障模型，依据
Y=ab
cT
a
ab
Gompertz分析适用条件
被测试对象的同一性原则
– 在被统计的时间范围内，只对软件进行缺陷修正活动，软件的特性、复杂度、 规模、测试过程等不发生质的变化（一般不大于10%）
统计的时间区间内应包含多轮测试（轮数N ≧2）
– 对于一轮测试的情况，不能采用Gompertz模型进行分析。因为在一轮测试中 ，因测试用例执行顺序的不同，可能产生截然相反的两种分析结果。这时 Gompertz分析结果的可信程度较低，不能作为决策的依据。
Gompertz 分析
活动描述
通过对产品测试缺陷的趋势分 析，对产品质量进行评估和预 测，指导测试策略和测试计划 调整。 主要通过对ODC分类中触发因 素等测试相关字段的基线分析 和趋势分析，来评估测试质量 并指导测试改进。 通过对测试工作量投入和缺陷 发现情况的综合分析，评估产 品质量
活动输入
活动输出
测试目的
• 评估软件产品的质量状况 • 为产品放行提供决策依据 • 分析缺陷发现、分布情况 • 为过程流程改进提供依据 • 为项目管理提供分析数据 • 评估项目人员的工作绩效
测试评估目的
测试评估的内容
• 产品质量评估：
– 对测试对象的可靠性、稳定性以及性能等的测评。质量建立在对测试 结果的评估和对测试过程中缺陷的分析基础上。
模型确定什么时候结束测试。 问题有时就是答案
测试结束的常用标准
• 建立在量化的基础上 • 随着测试时间推移，单位时间里的BUG数减少
• 当故障模型曲线趋近于直线，且单位时间发现的BUG
很少，甚至为0时，可以作为一个里程碑（milestone） • 随着运行环境、需求的变化，故障曲线也会发生变化
测试退出评估1