做缺陷分析需要投入不少的人力和时间，所以在缺陷分析之前首先我们必须明确我们为什么要做缺陷分析，缺陷分析能给我们带来什么。是效率的提升还是开发质量的提高。

接下来我们要确定缺陷分析的粒度，如果粒度太大，无法分析出具体有用的结果，如果粒度太小，投入的人力时间太多，与最终得到的成效相比，代价过大。

缺陷分析主要不是解决缺陷，而是防止缺陷的再次发生。正如我们应该提高自身身体素质，防止生病，而不仅仅是治病。

进行缺陷分析首先我们要从缺陷的来源下手，来源主要分成两类：

1.产品发布以后的缺陷

数据：产品发布以后的缺陷主要来源于用户报的问题，当然也有一部分是自己内部员工发布的问题，可以是产品经理，测试，开发或者其他的员工。

目的：分析这部分缺陷能让我们知道我们测试工作中的不足，找到相关的原因，提高测试工作的质量。同时，可以发现用户遇到的问题，在之后的开发工作中避免这种问题再次出现，提升用户体验。

指标：计算出平均修复时间指标，知道我们维护阶段处理缺陷的效率。提高效率，提升用户的满意度。

2.产品发布之前的缺陷

数据：产品发布之前的缺陷主要来源是测试开的bug。

目的：分析这部分的缺陷，能发现需求上描述不清楚或者不合理的地方，编码容易出错的地方，流程上不合理需要改进的地方，软件薄弱的地方等。我们逐个击破，提高整个开发团队的素质。

指标：同时通过缺陷分析，计算出缺陷指标，评估风险以及开发阶段软件的质量和需要的工期。

下面我们要重点介绍的缺陷分类方法叫漏斗模型缺陷分析法。模型从上到下是一个逐渐缩小的过程，让我们从一开始的缺陷到最后找到导致这个缺陷的部门和生产过程，以便有针对性的进行改进。

模型从右到左是生产的反向过程，在右边的生产活动如果缺陷过多，就会掩盖掉其左边的生产活动，我们必须先解决掉右边活动存在的问题，减少它产生的缺陷，这样才能看到模型左边的生产活动存在的问题。 模型如下图，绿色的是缺陷的分类，蓝色的是生产活动，红色的是对应的责任职位。

我们如何利用这个模型进行分类呢。可以分为以下几步。

1.对缺陷进行分类

把所有的缺陷按照模型的最上面一层进行分类。如果是老的缺陷，那会比较麻烦，需要重新分析老的缺陷，然后给老的缺陷分类。如果打算忽略老的缺陷，直接在之后的缺陷里进行统计，那可以直接在创建缺陷的时候加入一栏“缺陷类别”，而类别就是模型里的第一层，之后的统计中就会方便很多。

2.计算出每个类别的缺陷数目，然后对应到生产活动。

我们的生产活动主要有：

-- 编写需求

-- 理解需求

-- 系统设计

-- 编码

-- 设计测试用例

-- 功能测试

-- 回归测试

-- 性能测试

-- 实施

然后按照缺陷个数的高低进行分析每一个生产行为，分析产生缺陷的原因，是因为人还是因为制度还是因为流程。然后进行相应的改进。

以我目前的一个项目来举例，首先我提取了最近一个月发布前的缺陷。（这里主要的是，缺陷数目越多，能发现的问题更多，也更具有代表性。我这里取一个月的缺陷，只是为了说明，因为数据量太小实际参考效果不佳。）

先根据缺陷类别统计每一个类别的缺陷个数，然后对应到生产活动。我们发现排名第一的是编码，第二的是需求，需求产生的缺陷个数居然有29个，占比32.6%。需求的缺陷占比如此之高是不太常见的。从另一方面来说如果解决了需求这一块存在的问题，在效率的提高和产品质量的提高上会有很大的帮助。一般如果是由于需求导致的缺陷，如果找到原因并且采取有效措施后会比较容易在以后的工作中避免。

那我们来具体分析下为什么会有这么多需求的缺陷。需求缺陷中，其中主要的问题是需求描述不清楚，其次是多语言翻译，最后是用户体验。 

需求为什么会描述不清楚，一是因为产品人员没有真正理解产品，很多情况没有考虑全面。 二是描述语言不够清晰，逻辑不够清楚。三是业务上没弄清楚真正需要的是什么。对于第一点，一方面产品人员要加强对于自身产品的理解，测试人员也可以在这方面给产品人员把关，尽量保证需求考虑足够全面。 对于第二点，产品人员在写需求的时候尽量理清思路再写。对于第三点，这一点比较难，需要产品人员多提升专业知识。 

对于多语言翻译，一开始产品人员就应该明确哪些语句需要支持多语言，并且列在一个表里，保证他们都翻译了。而不是通过测试，发现问题，报告缺陷，然后解决，再去验证。这样对于测试资源是一张浪费，特别是在测试资源紧缺的时候，更是雪上加霜。

对于用户体验方面，希望产品人员多提升在用户体验方面的认知，在设计产品的时候时刻注意，不能是一拍脑门做决定。

总结下来。对于需求产品的缺陷，只要产品人员在平时工作中多加注意，相信这一方面的缺陷会少很多。整个组的效率也会提升很多。

接下来我们来分析下编码导致的缺陷，编码导致的缺陷中占比比较大的是，逻辑错误，遗漏功能，和不同组直接的依赖。这里面我们能努力的方面是遗漏功能和不同组之间的依赖。

遗漏功能一方面是对于需求没有了解清楚，另一方面是没有考虑全面，比如特殊的数据处理，特殊场景的处理等。改进的方向是，在做之前确认自己是否真的理解了需求，还有就是积极参加测试用例评审大会，听一听测试人员的测试用例，看自己有什么遗漏的地方。 另外就是自己整理一份特殊数据，特殊场景的情况，每次做到有关的内容的时候，都提醒下自己是否考虑到了。

不同组之间的遗漏，在于组之间的不透明。对于相互影响的模块，可以考虑创建一个组之间模块依赖表，每一个组设置一个接头人，一旦有依赖的模块发生变化了立刻通知到其他组。对于上下游的模块，每次下游测试前要和上游确认所有的需要的准备工作已经完成。

前面的这些分析都是按照缺陷个数进行的分析。当然有些缺陷个数很少，可是影响却很恶劣，对于这种缺陷我们必须强烈避免，按照漏斗模型找到对应的生产活动对应的负责人，case by case的处理。坚决避免此类情况再次发生。

在我们日常的工作中，大家对于缺陷分析的重视度并不够。一方面是不知道该如何利用缺陷的价值，如何进行分析，另一方面是记录的缺陷不规范，要进行缺陷分析难度太大。我所处的项目组由于业务多，时间上紧，所以大家都很忙很累，大家都意识到流程上业务上存在问题，可是却无法知道具体问题出在哪里，如何改进，更没有数据可以用来说服老板或者其他人进行改变。直到某天我意识到，缺陷就是开发过程的产物，它最能说明我们的开发过程到底存在什么问题，然后我就开始进行缺陷分析，不过一开始没想好从哪个维度入手，也不清楚缺陷该如何分类，分类的粒度应该多大。于是慢慢的尝试，最终整理出来的漏斗模型里面列的那些分类，因为整个图很像漏斗加上分析的过程就像用漏斗一样，一遍遍的过滤信息，最终找到根本问题，所以我把它叫做漏斗模型。希望大家能从我这篇文章中得到帮助。