引子：

    最近在思索如何相对客观和完善的衡量项目质量？我的老板推荐了一份资料，最近在看，做点笔记。

摘录：

1. In fact, many
companies (and groups in Microsoft, for that matter) use the bug tracking system as a project
management system, including work items right alongside the defects

 

2.root cause analysis of bugs is common. Other groups of bugs might be analyzed
by looking at the engineering process where the bugs were introduced and the engineering
process where they were detected to determine how effectively bugs are found during
different engineering processes. This type of analysis is usually referred to as defect removal
efficiency (DRE). Both root cause analysis and DRE are much more effective when all bugs are
recorded.

 

3.One of the things that management seems to love the most about a database full of bugs is
the reports they can generate to represent the variety of information available in the system.
No magic formula or query tells whether your project is ready to ship or if it is in trouble, but
there are countless methods of examining the data.

 

4.The zero bugs concept really means that
there are zero bugs that we know about that will stop us from shipping this product. Incoming
bugs are triaged, and then are assigned to a developer to fix, are postponed, or are resolved
as won’t (ever) fix. Eventually, as the bar for fixing gets higher and higher, the active bug
count hits zero. Sometimes, this is called zero bug bounce.

 

5.ODC技术，英文全称Orthogonal Defect Classification，译作“正交缺陷分类”，是一种介于定性和定量之间的分析方法。其基本过程是，首先将缺陷按其不同属性分别归入正交的类别中，然后对分类后的缺陷进行定量分析，从中得出过程改进措施。ODC技术的成本只有根本原因分析（Root Cause Analysis，RCA）方法的十分之一

 那么下面我们再来看看ODC怎么样的来影响客户。软件产品对于客户的影响有哪些方面呢？在ODC中定义了如下方面：

1. Installability
2. Security
3. Performance
4. Maintenance
5. Serviceability
6. Migration
7. Documentation
8. Usability
9. Standards
10. Reliability
11. Requirements
12. Capability

在ODC中，还定义了其他的元素来组合使用以帮助我们更好的了解问题出在哪里，同时帮助我们做出正确的决定。

        在测试人员发现一个问题并且开一个defect时，需要给defect定义下面的属性：

1) Activity, 它是指在哪种测试中发现的defect, 例如：UT、FVT、SVT 等等。

2) Trigger, 问题出现的情况

3) Impact，影响客户的方面

        当开发人员接到一个defect并且开始修改代码时，他需要定义下面的属性：

1) Target, 将要在哪里改正错误，例如：design、code 等等

2) Defect Type, defect的类型，例如：算法、初始化 等等

3) Qualifier: 只有三个，他们是missing、incorrect 和extraneous

4) Source: defect 的来源，例如：内部代码、outsource的代码等等

5) Age: defect是新代码还是重写的代码

6.Delete removal efficiency (DRE):-

It is a measurement to estimate efficiency of testing team.

DRE=A/A+B

A=N0.of defects found by testers

B=N0.of defects found by customer side people.

Test matrices (or) test responsible matrices:-

It is nothing but mapping b/w development stages & test factors.

In that we have five development stages & fifteen test bases factors.

Traceability matrices:-

It is mapping b/w the customer requirements & test cases.

DRE=	在开发过程中缺陷被解决的数目（Defects removed during a development phase ）	X 100%
	在该阶段缺陷潜伏的数目（Defects latent in the product at that phase）

 

Defect Removal Efficiency or Test Effectiveness
Defect Removal Efficiency (DRE), or its corollary Test Effectiveness in the test phase provide, the risk
portion of the Test Risk Matrix. By displaying in the matrix the projected DRE of a set of test practices the
full impact of phase tuning decisions can be visualized. Using the formula below provided by Card (1990)
the DRE of past defect removal activities can be arrived at for use in the matrix.
E = N/(N + S)
where
E = effectiveness of activity
N = number of faults (defects) found by activity
S = number of faults (defects) found by subsequent activities