前言
工作多年，发现诸多测试新人对缺陷分析了解甚少，市面上也很少有书籍专门对缺陷分析方法进行介绍。故在此总结一些自己的经验，希望能提供一些思路：
内容提要
对于如何有效分析缺陷，本文将分三个部分向大家介绍：
（一）BUG属性分解：我们首先一起来解读BUG的诸多属性，为何我们需要这些属性，这些属性对我们后续的分析有何帮助？在这一部分会为大家做一定解析。
（二）单项目BUG分析与质量评估：获取BUG后如何解读缺陷，如何通过这些缺陷了解项目质量和风险？本文将以改编的案例形式重点介绍。
（三）综合分析与数据度量：放大自己的视角，把缺陷全局化，用管理者的眼光建立基线指标，指导后续项目提升与改进。将此作为真正意义上缺陷分析工作的扩展。
关键词：缺陷分析；质量评估；数据度量；
正文
（一）BUG属性分解
1、BUG属性
所谓BUG属性，其实简单讲就是我们日常提报BUG时要求填写的内容，每个公司都有自己的填写标准，内容会有所差异，这里向大家介绍一些基础字段
属性 | 描述 |
项目名称 | 由公司自行定义，用于区分本次测试与其他测试项目 |
项目所属模块 | 由公司自行定义，用于标识本次测试范围 |
BUG标题 | 一般是对BUG的简要描述，依据各公司要求规范填写 |
BUG类型 | 需求错误，设计错误，编码错误，其他参考2章节 |
BUG严重程度 | 致命，严重，一般，建议参考3章节 |
BUG优先级 | 高优先级，中优先级，低优先级参考4章节 |
缺陷描述： | 描述重现步骤，预期结果和实际结果 |
缺陷状态： | 活动，已解决，已关闭，待决定参考5章节 |
BUG提出者 | 缺陷提出者，一般为项目测试人员 |
BUG制造者 | 缺陷制造者，一般为程序开发人员 |
BUG版本号 | 一般分为BUG发现版本和BUG修复版本两类 |
BUG解决者 | 缺陷解决这，通常为缺陷制造者本人 |
2、BUG类型
例如：
编号 | 类型 | 描述 |
1 | 需求错误 | 需求本身不符合逻辑导致的错误 |
2 | 设计错误 | 因设计文档和需求不符导致的错误 |
3 | 编码错误 | 程序和需求不符导致的错误 |
4 | 其他 | 其他错误 |
……………………
查看全文请点击下载：http://www.51testing.com/html/11/n-832511.html
（二）单项目BUG分析与质量评估
单项目BUG分析是日常工作中最常见的分析指标，可以通过缺陷在项目各环节的变化来了解项目质量和项目进度，并预估项目风险。
项目缺陷分析有很多入手点，下面有三个案例，针对短期维护类项目，小型工程类项目和中小型重构项目，以部分BUG属性作为分析依据。
1、短周期维护类项目缺陷分析
案例一：通过三个基础指标（BUG类型/BUG严重程度/BUG缺陷状态）分析项目缺陷，假设人力，时间等因素均正常。
项目类型 | 某网站市场活动 | |
功能描述 | 情人节即将来临，某网站针对一些特定产品策划了情人节促销活动 | |
项目周期 | 10个工作日 | 需求分析与评审2个工作日，设计与编码 3个工作日测试4个工作日，验收与发布1个工作日 |
人力投入 | 5.5人 | 项目经理 1人，需求分析师1人，UI设计1人，开发人员1人，测试人员1.5人 |
Point1：
