缺陷描述 对缺陷的描述应该包含以下的内容： 缺陷ID 唯一的缺陷ID，可以根据该ID追踪缺陷 缺陷状态 常见的缺陷状态有：“新建”、“待解决”、“已解决”、“已修复” 一般的，测试人员识别缺陷，其初始状态是“新建”；项目经理或技术领导分析缺陷，分配给合适的开发人员来解决，状态流转为“待解决”；指定的工程师解决缺陷，将其状态跟踪到“已解决”，测试人员复核该缺陷，如果复核通过，则关闭缺陷，状态是“已修复”，如果复核不通过，则打回到“待解决”。 缺陷标题 描述缺陷的标题 缺陷的详细描述 对缺陷的详细描述，缺陷如何复现的步骤等等，之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细 缺陷的严重程度 四个等级 描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“细微”四种 缺陷的紧急程度 >> 1级最高 描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级 缺陷的紧急程度与严重程度虽然是不一样的，但两者密切相关，往往的越是严重，就越是紧急，所以有些组织只用“严重程度” 缺陷提交人 缺陷提交人的名字 缺陷提交时间 缺陷提交的时间 缺陷所属项目/模块 缺陷所属的项目和模块，最好能较精确的定位至模块 缺陷指定解决人 缺陷指定的解决人，在缺陷“新建”状态为空，在缺陷“待解决”状态下由项目经理指定相关开发人员修改 缺陷指定解决时间 项目经理指定的开发人员修改此缺陷的deadline 缺陷解决人 最终解决缺陷的人 缺陷处理结果描述 对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改 缺陷处理时间 开发人员处理此缺陷的时间 缺陷复核人 对被处理缺陷复核的验证人 缺陷复核结果描述 对复核结果的描述（通过、不通过） 缺陷复核时间 对缺陷复核的时间 测试环境说明 对测试环境的描述 必要的附件 对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的 除上述描述项外，配合不同的统计的角度，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等属性。
