前登记的缺陷重复
重复问题
先前登记缺陷的编号
不是缺陷，是测试人员理解错误不是问题
说明需求和设计中对应的内容，以证明
软件行文符合预期要求。
缺陷轻微，且修改困难，或修改易不处理
说明缺陷和需求不相抵触，且轻微
导致更大的潜在问题
说明处理的困难和风险
如果按照开发计划，缺陷发生的功推迟处理
引用开发计划，写明何时处理。
能不属于当前开发阶段必须的完
需要项目负责人确认
成的
45验证
测试人员对“已解决”状态的缺陷进行重新测试，测试步骤应当按照登记的可重现步骤进行。
可编辑修改
f。
46关闭
测试人员确认缺陷已经解决后，关闭缺陷。对于否决的缺陷，测试人员需要和项目负责人讨论，项目负责人同意的可以关闭，项目负责人不同意的需要“重新打开”。
47再打开
验证测试不通过的缺陷，应当重新打开，状态变为“重新打开”。关闭了的缺陷再次出现时通常因为解决缺陷的方法导致相同位置出现不同形式的缺陷时，测试人员重新打开缺陷，开发人员需要继续解决。项目负责人应当关注“重新打开”的缺陷。
5缺陷记录
缺陷记录应当包含但不限于如下属性。
51编号
缺陷的唯一标示，可以方便对特定缺陷记录的引用。
52所属项目53软件发布版本
即缺陷是在什么发布版本中发现。对于文档缺陷，这里使用文档在配置库里的版本号。
54所属功能55负责人
负责处置解决缺陷的负责人，对于程序缺陷，负责人应当具体开发人员；对于文档缺陷，负责人应当是具体文档的作者。
缺陷登记者不明确责任人时，可以指定项目负责人为责任人，由他重新分配负责人。
可编辑修改
f。
56状态
即缺陷通过一个跟踪修复过程的进展情况
新
新登记的缺陷，这个时候缺陷记录内容可以不完整，可以继续补充
已经提交缺陷信息完整，并分配责任人，
打开
负责人开始处理
已解决
问题已经解决，负责人必须填写完整的处置记录，内容包含对原因的分析和解决方法。参见511
否决
责任人呢不同意缺陷，或不处理缺陷参见44和511
关闭
验证测试通过后
重新打开没有通过验证测试，或不同意被否决。已经关闭的缺陷再次出现的。
57严重程度
标志缺陷对整个软件产品功能的影响程度。可以用数字表示，分为1到5
档，可以用说明文字表示，具体项目可以根据自己的情况定义缺陷的严重程度标
准，下表是一个常用的标准
严重标示含义
程度
1
致命导致软件无法使用问题，例如整个程序崩溃，导致无法使用，测试无法继
续进行。
下面的问题应定义为严重度1级r