51Testing软件测试论坛

标题: 如何对缺陷进行分析，都分析哪些指标...(2011-5-9)（获奖名单已公布） [打印本页]
作者: 默默巫    时间: 2011-5-9 15:31
标题: 如何对缺陷进行分析，都分析哪些指标...(2011-5-9)（获奖名单已公布）
如何对缺陷进行分析，都分析哪些指标，它们有什么意义？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！





获奖名单
奖项获奖名单奖励答案链接
一等奖linghan199150元的移动充值卡16#
二等奖xlf24300论坛积分10#

作者: 真实的追求者    时间: 2011-5-9 18:05
先抢沙发
作者: 真实的追求者    时间: 2011-5-9 18:24
可以从以下指标分析
1、严重级别
在项目测试中，我们不能仅仅用“缺陷总数”作为评价项目出错程度的唯一指标。因为不同缺陷严重程度是不相同的，较为严重的缺陷带来的影响远远大于一般缺陷，所以，我们引入“缺陷严重级别”指标，用来标定缺陷的严重程度
2、缺陷类别
Bug类别用来描述bug的内容类别，比如功能、性能、界面等。这个指标可以帮助我们分析，在所有的bug中，哪些类型的bug比较多，应该值得关注，并且在后续的开发工作中，加强对类似问题的审核；在后续的测试工作中，加强对类似bug的测试力度，最大程度的在源头减少类似错误的发生
3、bug修复率
Bug修复率，也可以称为“bug修改成功率”，它能够反映bug责任人修复bug的效果，可以作为对开发人员的考核指标之一，同时可以督促开发人员认真执行单元测试
4、Bug修复工作量
根据以前项目的bug修复工作量的统计分析，可以得到不同严重性级别的bug及其对应的修改工作量
5、 时间跟踪报告
显示实际花费时间与初始估算时间的比例
显示这个版本的问题与进度计划相比是超前、推迟，或者按计划进行。
显示每个bug详细的工作量记录
6、开发者工作量报告
这个报告显示了开发者当前的工作量的详细情况——显示了每个项目的未解决的已分配问题的数量和剩余的工作量
7、版本工作量报告
这个报告显示了开发者当前的工作量的详细情况——显示了每个项目的未解决的已分配问题的数量和剩余的工作量。
8、版本工作量报告
这个报告显示了指定的版本的当前工作量详细情况——显示了每个用户的未解决问题的数量和剩余工作量
9、  Bug预计修复完成时间
在“bug修复工作量”中，我们考虑的是bug修改实际所需的工作量，但是没有考虑到项目开发所处阶段、人员分配等实际情况。在这个指标中，项目管理者希望能知道bug计划完成修复所需的时间。为了实现这个目标，我们可以根据bug的优先级，估计bug计划修复完成的时间

意义：所有这些指标的综合运用，能够比较全面的从量化的角度来描述一个项目中开发和测试工作的实际情况。PM、开发组长和测试组长可以选择对自己项目有用的统计指标，跟踪这些数据，以便及时跟踪和调整项目开发和测试，更好的管理项目
作者: jingsongfeng86    时间: 2011-5-10 11:14
作者: msnshow    时间: 2011-5-10 14:04
个人觉得，首先要搞清楚缺陷分析的目的是什么，清楚了目的，才清楚要做什么内容

一般说来缺陷分析，都是为了更好的预防缺陷，从根本提高软件产品的质量
作者: jiazurongyu    时间: 2011-5-11 19:32
缺陷定为首先是级别 s,a,b,c,d级别
根据不同测试周期,控制bug产生
作者: jiazurongyu    时间: 2011-5-11 19:33
那么当完成了v1.0版本,打包了v1.1版本,那么v1.0版本就是参照,参照上个版本的遗留缺陷进行分类.
当功能变更而使bug带走的,可以关闭这类bug,记录这类因未修复而解决的bug
作者: jiazurongyu    时间: 2011-5-11 19:34
记录风险点,统计bug100%重现的命中率
作者: ruirui。    时间: 2011-5-12 15:36
先占位
作者: xlf24    时间: 2011-5-14 10:34
首先需明确对缺陷进行分析的目的，哪些指标是项目里需要的，然后对其进行定制。而对缺陷进行分析的目的基本是为了总结当前项目的状态及为下一个项目的流程改进提供数据。比如发现各类缺陷的发生概率，及缺陷的分布状态等。及时提出预防缺陷发生的措施来提高软件产品的质量的同时降低项目成本。
对于缺陷的收集及管理，主要是通过对缺陷属性的控制，缺陷属性的基本项有：summary, description, report date, affect version, module, security, priority, Defect status, defect solution, fix version, fix date, assgin to, reopen times, phase detected, phase injected, defect type, Reason，worklog
这里每个基本项有每个基本项的目的，我们可以利用他们的组合来实现我们的目的。以上提到的项除了summary与描述不用参与之外，任意两个属性均可用来组合成图表。在此列下几个常用分析图表：
1：phase detected 及 security 的组合报表
这个报表里的数据，用来分析各个阶段发现的缺陷严重程度的分布及每个阶段发现缺陷的比例。从该图可以看出哪个阶段的测试需要加强。若在SIT阶段发现了太多的critical的issue，则说明SIT阶段之前的测试力度不够，这些issue影响到了测试进度，对项目计划有影响。
2：phase injected 及 phase detected 的组合报表
这个报表里的数据，用来分析缺陷引进的阶段分布及缺陷被发现的阶段的分布，反映了缺陷发现及修复的效率,从这个图可以看出哪些阶段引进的缺陷遗留到了其他阶段。比如说在SIT阶段发现了很多需求阶段引进的错误，那么说明需求阶段对需求的准备及测试需改进。
3：Review efficiency（需求阶段加设计阶段发现的缺陷与UI加SIT阶段发现的缺陷之比）
从缺陷的角度来说，软件测试的目的是缺陷预防及缺陷侦察，缺陷的成本是发现的越晚越高，那么从这个图表可以我们看出在编码之前我们消除了多少的缺陷。可以看出评审的力度是否需要加强及评审方法是否需要改善。这个比例当然是越高越好。一般公司会有指标定义。
4: 发布前缺陷去处率 (UAT之前发现的缺陷与UAT阶段发现缺陷之比）
我们知道缺陷被客户发现了是件让作为测试人员的我们很不爽的一件事。那么这个比例可以看出有多少的缺陷被我们遗漏了，这个比例的大小直接影响到了客户及我们的心情，更影响了老板的心情。从这里也可以看出我们的产品质量及团队的工作成果。若这个比例太小，则需考虑团队测试的技术需要怎样加强。
5：Defect Injected and Defect Reason
看名字就应该很清楚这个图表的目的是为了查看缺陷引进的原因，根据这些数据可以我们提出改善方案。
最后还有一个叫做Delivered Defect Density， 他是UAT阶段发现的缺陷比上实际每人每月投入的工作量。从这里可以看出我们的生产质量。可以根据这个数据可以延伸出其他更多的有需要的报表，如人与缺陷个数，人与缺陷严重级别，人与缺陷的投入时间等等。这个指标也是老板们很关注的。
另外还有些指标，如：
反映产品质量的指标：
    缺陷密度 = 缺陷数量 / 软件规模
    潜在缺陷概数 = (100% - 发布前缺陷去处率) * 缺陷密度
反映产品可靠性的指标：
    平均失效时间 = 软件持续运行时间 / 缺陷数量
反映缺陷修复成本的指标：
　　平均修复时间 = ∑缺陷修复时间 / 缺陷数量
　　平均修复成本 = 开发人员的平均人力成本 * 平均修复时间
　　相对返工成本 = 返工的工作量 / 项目总工作量 *100%

题外话：缺陷可以算是软件工程里与我们息息相关的一个点了，这个问题挺好的，即可以用来温习及巩固以前的知识也可以用来学习新的知识。谢谢了。
作者: S小虾米    时间: 2011-5-17 11:13
试着答一点
1.bug的当前状态
2.严重程度
3.生存期限
4.趋势观察
作者: xiaofufu    时间: 2011-5-18 13:33
谢谢  太有价值了
作者: charles    时间: 2011-5-22 15:13
前提条件：
1.测试用例评审通过，且需求覆盖率要达到100%；
2.从需求设计到运营整个生命周期的Bug数据信息；

指标：
1.缺陷严重级别（致命，严重，一般，轻微，建议）
2.缺陷注入阶段（需求、设计、编码、集成、运营）
3.缺陷发现阶段（需求、设计、编码、集成、运营）
4.缺陷提交时间，用于分析缺陷按时间的趋势
5.缺陷修复人
6.缺陷模块，按模块分析缺陷分布，可以反映相关开发人员的技术水平和模块复杂度
7.缺陷类型（功能缺陷，UI缺陷，数据缺陷、兼容性、性能）
8.缺陷产生原因（需求、设计、编码、配置、数据、异常操作，其他）
9.缺陷修复成本，指开发人员修复缺陷的实际工作量
10.缺陷状态（提交，待修复，已修复，非缺陷，已关闭，延迟）

综合分析：
1.所有有效缺陷数/测试用例数 以及所有有效缺陷数/代码行数，作为基数，用于根据测试用例数以及代码行数预测类似项目的缺陷数；
2.测试用例有效性=测试用例发现的有效缺陷数/执行一遍测试用例所有有效的缺陷数；
3.根据缺陷严重级别和缺陷状态分析 缺陷严重程度的分布，（所有缺陷，未修改缺陷，计划延迟的）的严重程度分布情况；
4.按缺陷状态和日期查看缺陷的趋势，（所有，新提交，关闭）的缺陷趋势图，用于评估预测系统可发布日期；
5.缺陷产生原因分布情况，根据分布情况评估缺陷主要产生的原因以后续有效的更有针对性的改进也可以形成软件开发的知识库，以提高新项目的质量和工作效率；
6.缺陷模块分布情况，根据缺陷的模块分布情况进一步分析模块的复杂度，针对缺陷密度高的模块调度开发资源；
7.按照缺陷注入阶段、缺陷发现阶段、缺陷修复成本以及缺陷对客户的影响成本，可以评估计算不同阶段修复缺陷的成本以及不同阶段对客户的影响成本，可以进一步体现测试的价值；
8.根据缺陷状态和缺陷修复人，可以分析监控开发人员的工作量，以更有效的调度开发资源，确保项目进度；
作者: applejuzi    时间: 2011-5-22 15:29
15#的讲的很全，支持1下。
作者: linghan1991    时间: 2011-5-24 10:14
先占个位
作者: linghan1991    时间: 2011-5-24 10:20
1、分析指标
缺陷分析时需计算一些分析指标，使分析结果得到度量，以便直观比对。分析指标有以下几项：
* 反映产品质量的指标：
缺陷密度 = 缺陷数量 / 软件规模
潜在缺陷概数 = (100% - 发布前缺陷去处率) * 缺陷密度
* 反映产品可靠性的指标：
平均失效时间 = 软件持续运行时间 / 缺陷数量
* 反映缺陷发现及修复的效率的指标：
缺陷检出率 = 某阶段当时发现的缺陷 / 属该阶段的全部缺陷 * 100%
发布前缺陷去处率 = 发布前发现的缺陷 / (发布前发现的缺陷 + 软件运行的前 3个月发现的缺陷)* 100%
缺陷修正率 = 修复过程中未引发其他问题的缺陷数 / 被修复缺陷的总数 *100%
* 反映缺陷修复成本的指标：
平均修复时间 = ∑缺陷修复时间 / 缺陷数量
平均修复成本 = 开发人员的平均人力成本 * 平均修复时间
相对返工成本 = 返工的工作量 / 项目总工作量 *100%

2、汇总统计
在缺陷分析中可以使用统计方法对收集的变更进行分类、汇总。
* 缺陷发生日期统计：是按变更提交的年月统计。分析反映缺陷发生的动态趋势。
* 缺陷性质统计：变更性质属性一般分为：缺陷变更和需求变更两种。
* 缺陷状态分布：变更状态属性分类很多，但在缺陷分析中没必要分那么细，故按 3 种统计：关闭、挂起和处理中。分析主要反映缺陷修改完成情况。
* 缺陷按产品分类统计：该分析能显示各软件子系统的缺陷分布情况。
* 缺陷按原因分类统计：是按变更的根本原因属性进行分类统计，统计不包括需求变更。该分析能揭示缺陷原因的分布。
* 缺陷测试情况统计：统计仅涉及变更的根本原因是系统设计、程序编码、维护和外部问题等缺陷变更。该分析能暴露软件测试本身存在的问题。
* 缺陷来源统计：该分析主要反映用户或软件代理的地区分布，发现一些客户分布规律。 　　
分析统计表、图可按单一属性，也可按多个属性进行汇总统计。
作者: zhyb_2008    时间: 2011-5-25 17:06
又回论坛了。这个问题好像也有多方面的分析，从技术发展上，项目自身上，业务上等。有些多，不想分析了，向回贴回答该问题的学习。
作者: wscqb    时间: 2011-5-27 17:20
学习了……
作者: grassman907    时间: 2011-5-28 22:43
16楼上讲的很全， 想补充的一点就是缺陷分析并不局限于测试完成阶段， 而是贯穿于整个测试过程。
真多每一个新建的缺陷， 都应该进行及时的进行分析， 具体分析的细节在HP的QTP和IBM的ratiinal里面都有详细的定义，其主要指标不外乎： 严重程度， 缺陷来源模块， 缺陷原因， 缺陷状态， 责任人， 缺陷影响。  其分别作用如下：
严重程度： 在测试计划阶段应该有定义出不同等级缺陷的修复时间， 一旦改缺陷未在规定时间内修复， 则被认为break协议， 该缺陷要被重点监视。
来源来源模块：用于指明那种来自于那个产品模块， 以便分配个相关开发人员，并在后期对各模块的缺陷进行汇总。
缺陷原因：何种原因导致缺陷（code? bulid?  design?）, 用于后期的缺陷汇总。
责任人： 对多application 的系统（比如前端， 中间层， 后端）， 测试人员要在缺陷会议里明确出导致缺陷的原因， 并把缺陷分配给正确责任人。
缺陷状态: 用于监控缺陷状态， 每天的缺陷状态应该体现在天报里。
缺陷影响： 改缺陷是否对其他模块产生印象， 时候回block其他的case执行， 所有被改缺陷block的工作应该在缺陷中注明， 并体现在天报中
作者: bjinfo_1998    时间: 2011-5-29 17:59
学习中
作者: zhifei.xie    时间: 2011-6-7 10:31
这里得砖家们，哪里看了那么多的理论知识；1个比一个能吹！你们的公司内部都是这样严格执行和实施的吗？
如果实施了估计你们的开发和测试基本也都**了！理论一套 一套的要能实施起来，还是实际点比较好吧
讲了这么多的理论确实不错，但是真正把这些应用的只有少数的一些大公司吧；没有流程、没有领导的支持、没有开发人员的配合、没有规章制度的制定、没有约束力！上面的这些说了都是白说......
再好的方法没法应用到实践中都是天花乱坠.......
都是些理想主义的QA！做QA的事情做多了.........
作者: zhifei.xie    时间: 2011-6-7 10:45
所有的东西都是狗屁，浮云罢了！
敏捷开发和测试没有提到这个照样把测试做好
有些公司连需求都覆盖不到，还谈什么BUG分析
讲这些真得意义不大，还是实际点的好
真去分析这个需要1个人专门去做这个事了，很多公司压根就没有QA.........
理论和现实相差甚远.....
浮云....



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2