|
|
首先需明确对缺陷进行分析的目的，哪些指标是项目里需要的，然后对其进行定制。而对缺陷进行分析的目的基本是为了总结当前项目的状态及为下一个项目的流程改进提供数据。比如发现各类缺陷的发生概率，及缺陷的分布状态等。及时提出预防缺陷发生的措施来提高软件产品的质量的同时降低项目成本。
对于缺陷的收集及管理，主要是通过对缺陷属性的控制，缺陷属性的基本项有：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%
题外话：缺陷可以算是软件工程里与我们息息相关的一个点了，这个问题挺好的，即可以用来温习及巩固以前的知识也可以用来学习新的知识。谢谢了。 |
|
/1 
关于我们
发表于 2011-5-9 15:31:29
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
