缺陷从提交到关闭所经过的状态

这是本人理解的缺陷状态变化过程,若有不正确的地方还请指出
yes表示条件都是通过的: 从上向下分别表示缺陷没有重复, 没有拒绝修复, 没有延期修复, 缺陷回归验证通过; no表示与yes相反的条件

缺陷的生命周期和缺陷的识别
缺陷的生命周期
发现缺陷——》提交缺陷——》确认缺陷——》分配缺陷——》修复缺陷——》验证缺陷——》关闭缺陷
缺陷的识别
通过测试用例中预期结果进行识别

通过需求规格说明书进行识别

通过用户手册及其他文档进行识别

通过同行业相类似成熟的商业软件来识别

通过和开发人员的沟通进行识别

通过和有经验的测试人员沟通进行识别

参照同行业隐式需求进行识别

1、缺陷分析定义
缺陷分析本质上是对缺陷中包含的信息项进行收集，汇总，分类之后使用统计方法或者分析模型得出分析结果。

2、缺陷数据的收集
缺陷提交时需要收集的信息


1 缺陷的严重等级
2 缺陷所在的模块
3 缺陷发现的时间
4 缺陷所在的版本号
5 缺陷的发现者
6 负责修改缺陷的工程师

缺陷关闭时需要收集的信息


1 缺陷关闭的时间
2 关闭缺陷的版本
3 修复缺陷而改动的代码行数产生缺陷的根本原因 （例如 ：需求，分析，编码，软/硬配置）   

3、分析 

缺陷的发展趋势（新发现缺陷数量增长趋势和关闭数量的趋势）缺陷发展趋势图有助于我们了解各版本中缺陷数量的分布。特别在回归测试阶段中，缺陷的分布可以直接反映出版本的质量状况。
缺陷分布状况：缺陷按模块的分布情况；缺陷按产生的根本原因的分布状况。模块分布图是反映的是各个模块中缺陷数量的分布状况。它可以被用来评估各模块质量水平，开发难度。同时也能从侧面反映出测试资源在各模块分布情况
缺陷产生的原因分布图。该分布图是缺陷分析中最为重要的一张图表，因为它可以直接反映出各软件工程活动的质量，为软件过程的改进提供直接的参考数据。一般来说，缺陷产生的根本原因划分的越细致，分析的结果就越精确。

缺陷描述

对缺陷的描述应该包含以下的内容：

缺陷ID

唯一的缺陷ID，可以根据该ID追踪缺陷

缺陷状态

常见的缺陷状态有：“新建”、“待解决”、“已解决”、“已修复”

一般的，测试人员识别缺陷，其初始状态是“新建”；项目经理或技术领导分析缺陷，分配给合适的开发人员来解决，状态流转为“待解决”；指定的工程师解决缺陷，将其状态跟踪到“已解决”，测试人员复核该缺陷，如果复核通过，则关闭缺陷，状态是“已修复”，如果复核不通过，则打回到“待解决”。

缺陷标题

描述缺陷的标题

缺陷的详细描述

对缺陷的详细描述，缺陷如何复现的步骤等等，之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细

缺陷的严重程度  四个等级

描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“细微”四种

缺陷的紧急程度   >> 1级最高

描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级

缺陷的紧急程度与严重程度虽然是不一样的，但两者密切相关，往往的越是严重，就越是紧急，所以有些组织只用“严重程度”

缺陷提交人

缺陷提交人的名字

缺陷提交时间

缺陷提交的时间

缺陷所属项目/模块

缺陷所属的项目和模块，最好能较精确的定位至模块

缺陷指定解决人

缺陷指定的解决人，在缺陷“新建”状态为空，在缺陷“待解决”状态下由项目经理指定相关开发人员修改

缺陷指定解决时间

项目经理指定的开发人员修改此缺陷的deadline

缺陷解决人

最终解决缺陷的人

缺陷处理结果描述

对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改

缺陷处理时间

开发人员处理此缺陷的时间

缺陷复核人

对被处理缺陷复核的验证人

缺陷复核结果描述

对复核结果的描述（通过、不通过）

缺陷复核时间

对缺陷复核的时间

测试环境说明

对测试环境的描述

必要的附件

对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的

除上述描述项外，配合不同的统计的角度，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等属性。