如何对缺陷进行分析，都分析哪些指标...(2011-5-9)（获奖名单已公布）

默默巫 · 发表于 2011-5-9 15:31:29

如何对缺陷进行分析，都分析哪些指标，它们有什么意义？

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

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

zhifei.xie · 发表于 2011-6-7 10:45:59

所有的东西都是狗屁，浮云罢了！
敏捷开发和测试没有提到这个照样把测试做好
有些公司连需求都覆盖不到，还谈什么BUG分析
讲这些真得意义不大，还是实际点的好
真去分析这个需要1个人专门去做这个事了，很多公司压根就没有QA.........
理论和现实相差甚远.....
浮云....

zhifei.xie · 发表于 2011-6-7 10:31:06

这里得砖家们，哪里看了那么多的理论知识；1个比一个能吹！你们的公司内部都是这样严格执行和实施的吗？
如果实施了估计你们的开发和测试基本也都**了！理论一套一套的要能实施起来，还是实际点比较好吧
讲了这么多的理论确实不错，但是真正把这些应用的只有少数的一些大公司吧；没有流程、没有领导的支持、没有开发人员的配合、没有规章制度的制定、没有约束力！上面的这些说了都是白说......
再好的方法没法应用到实践中都是天花乱坠.......
都是些理想主义的QA！做QA的事情做多了.........

bjinfo_1998 · 发表于 2011-5-29 17:59:51

学习中

grassman907 · 发表于 2011-5-28 22:43:53

16楼上讲的很全，想补充的一点就是缺陷分析并不局限于测试完成阶段，而是贯穿于整个测试过程。
真多每一个新建的缺陷，都应该进行及时的进行分析，具体分析的细节在HP的QTP和IBM的ratiinal里面都有详细的定义，其主要指标不外乎：严重程度，缺陷来源模块，缺陷原因，缺陷状态，责任人，缺陷影响。其分别作用如下：
严重程度：在测试计划阶段应该有定义出不同等级缺陷的修复时间，一旦改缺陷未在规定时间内修复，则被认为break协议，该缺陷要被重点监视。
来源来源模块：用于指明那种来自于那个产品模块，以便分配个相关开发人员，并在后期对各模块的缺陷进行汇总。
缺陷原因：何种原因导致缺陷（code? bulid? design?）, 用于后期的缺陷汇总。
责任人：对多application 的系统（比如前端，中间层，后端），测试人员要在缺陷会议里明确出导致缺陷的原因，并把缺陷分配给正确责任人。
缺陷状态: 用于监控缺陷状态，每天的缺陷状态应该体现在天报里。
缺陷影响：改缺陷是否对其他模块产生印象，时候回block其他的case执行，所有被改缺陷block的工作应该在缺陷中注明，并体现在天报中

wscqb · 发表于 2011-5-27 17:20:34

学习了……

zhyb_2008 · 发表于 2011-5-25 17:06:07

又回论坛了。这个问题好像也有多方面的分析，从技术发展上，项目自身上，业务上等。有些多，不想分析了，向回贴回答该问题的学习。

linghan1991 · 发表于 2011-5-24 10:20:58

1、分析指标
缺陷分析时需计算一些分析指标，使分析结果得到度量，以便直观比对。分析指标有以下几项：
* 反映产品质量的指标：
缺陷密度 = 缺陷数量 / 软件规模
潜在缺陷概数 = (100% - 发布前缺陷去处率) * 缺陷密度
* 反映产品可靠性的指标：
平均失效时间 = 软件持续运行时间 / 缺陷数量
* 反映缺陷发现及修复的效率的指标：
缺陷检出率 = 某阶段当时发现的缺陷 / 属该阶段的全部缺陷 * 100%
发布前缺陷去处率 = 发布前发现的缺陷 / (发布前发现的缺陷 + 软件运行的前 3个月发现的缺陷)* 100%
缺陷修正率 = 修复过程中未引发其他问题的缺陷数 / 被修复缺陷的总数 *100%
* 反映缺陷修复成本的指标：
平均修复时间 = ∑缺陷修复时间 / 缺陷数量
平均修复成本 = 开发人员的平均人力成本 * 平均修复时间
相对返工成本 = 返工的工作量 / 项目总工作量 *100%

2、汇总统计
在缺陷分析中可以使用统计方法对收集的变更进行分类、汇总。
* 缺陷发生日期统计：是按变更提交的年月统计。分析反映缺陷发生的动态趋势。
* 缺陷性质统计：变更性质属性一般分为：缺陷变更和需求变更两种。
* 缺陷状态分布：变更状态属性分类很多，但在缺陷分析中没必要分那么细，故按 3 种统计：关闭、挂起和处理中。分析主要反映缺陷修改完成情况。
* 缺陷按产品分类统计：该分析能显示各软件子系统的缺陷分布情况。
* 缺陷按原因分类统计：是按变更的根本原因属性进行分类统计，统计不包括需求变更。该分析能揭示缺陷原因的分布。
* 缺陷测试情况统计：统计仅涉及变更的根本原因是系统设计、程序编码、维护和外部问题等缺陷变更。该分析能暴露软件测试本身存在的问题。
* 缺陷来源统计：该分析主要反映用户或软件代理的地区分布，发现一些客户分布规律。　　
分析统计表、图可按单一属性，也可按多个属性进行汇总统计。

linghan1991 · 发表于 2011-5-24 10:14:10

先占个位

applejuzi · 发表于 2011-5-22 15:29:16

15#的讲的很全，支持1下。

charles · 发表于 2011-5-22 15:13:28

前提条件：
1.测试用例评审通过，且需求覆盖率要达到100%；
2.从需求设计到运营整个生命周期的Bug数据信息；

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

综合分析：
1.所有有效缺陷数/测试用例数以及所有有效缺陷数/代码行数，作为基数，用于根据测试用例数以及代码行数预测类似项目的缺陷数；
2.测试用例有效性=测试用例发现的有效缺陷数/执行一遍测试用例所有有效的缺陷数；
3.根据缺陷严重级别和缺陷状态分析缺陷严重程度的分布，（所有缺陷，未修改缺陷，计划延迟的）的严重程度分布情况；
4.按缺陷状态和日期查看缺陷的趋势，（所有，新提交，关闭）的缺陷趋势图，用于评估预测系统可发布日期；
5.缺陷产生原因分布情况，根据分布情况评估缺陷主要产生的原因以后续有效的更有针对性的改进也可以形成软件开发的知识库，以提高新项目的质量和工作效率；
6.缺陷模块分布情况，根据缺陷的模块分布情况进一步分析模块的复杂度，针对缺陷密度高的模块调度开发资源；
7.按照缺陷注入阶段、缺陷发现阶段、缺陷修复成本以及缺陷对客户的影响成本，可以评估计算不同阶段修复缺陷的成本以及不同阶段对客户的影响成本，可以进一步体现测试的价值；
8.根据缺陷状态和缺陷修复人，可以分析监控开发人员的工作量，以更有效的调度开发资源，确保项目进度；

xiaofufu · 发表于 2011-5-18 13:33:18

谢谢太有价值了

S小虾米 · 发表于 2011-5-17 11:13:29

试着答一点
1.bug的当前状态
2.严重程度
3.生存期限
4.趋势观察

xlf24 · 发表于 2011-5-14 10:34:05

首先需明确对缺陷进行分析的目的，哪些指标是项目里需要的，然后对其进行定制。而对缺陷进行分析的目的基本是为了总结当前项目的状态及为下一个项目的流程改进提供数据。比如发现各类缺陷的发生概率，及缺陷的分布状态等。及时提出预防缺陷发生的措施来提高软件产品的质量的同时降低项目成本。
对于缺陷的收集及管理，主要是通过对缺陷属性的控制，缺陷属性的基本项有：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%

题外话：缺陷可以算是软件工程里与我们息息相关的一个点了，这个问题挺好的，即可以用来温习及巩固以前的知识也可以用来学习新的知识。谢谢了。