如何完整全面地描述一个缺陷？提交缺陷的时候涉及到哪些属性？我们都用过各种不同的缺陷跟踪工具，它们大多数支持定制的功能。那么，怎样的缺陷描述是比较合理完整的？

    大多数的缺陷报告包括下面一些属性：

Summary(缺陷摘要)：用一句话概要地描述缺陷的现象

Descrīption(缺陷描述)：详细的描述缺陷重现的环境、前置条件、步骤、期望结果、实际结果等。

owner/assignee(指定的负责人)：通常是负责修复该缺陷的开发人员，在有的系统中也支持开发人员修复好缺陷修改其在缺陷跟踪系统中的状态后把它指定（assign）给相关的测试人员。

status(状态)：缺陷当前的状态，常见的分类有open/fixed/closed，有些系统还在open状态之前加上一个submitted状态，表示只是提交了缺陷，可能还需要确认之后才算正式的open的缺陷。

priority（优先级）：通常分为high/normal/low，或者可以加上resolve immediately

severity(严重程度)：可以分为block/critical/major/minor/trival

found in: 缺陷被发现的版本，通常平时测试的都是一些build，只有正式release出去了，才会在产品环境下由客户发现缺陷。所以这里填的版本信息应该大多是build号，由于数量太多，并且预先很难知道被测的是哪一个build，所以这里使用文本框填写比使用下拉框选择预定义的版本信息要适用。

fixed in：缺陷被修复的时候由开发人员填写。在使用daily build的团队中，开发人员可以取得当前最新的build号，加1就是下一个build号，用它来反映修复将在哪个build中被包含。在使用svn作为源码控制的开发环境下，可以填写提交修复的revison number，基于它做的build就是将包含修复的build。

resolution（解决办法）：由开发人员修复缺陷的时候填写。解决办法可以包括：Architecture/Code Change/Configuration Change/Database Change，另外可以包括Need Information来把缺陷返回到测试人员那里，也可根据实际情况选择duplicate/Not a defect/Software limitation等解决方案。

verified in: 反映缺陷的修复在哪个版本被验证了

attachment（附件）：附加的屏幕截图、服务器或客户端日志等相关文件，便于开发人员定位缺陷的原因。

下面是几个我认为有帮助的缺陷属性：

Environment：描述缺陷被发现的环境，可分为Development/Test/production，用以区别开发人员开发过程中自己发现的缺陷（通常是一些影响比较大的，比如设计上的缺陷，否则一般都是自行解决，不会提交一个缺陷）、测试人员测试环境下发现的缺陷以及客户在产品环境下发现的缺陷。方便的对测试环境下和产品环境下的缺陷进行区别，对之后的数据统计、测试效率的评定都是很有帮助的。

Release Note?: 如果缺陷属于software limitation不予修复，或者在当前release不予修复，勾选上Release Note，便于过滤出这样的缺陷，好统一加上release note

Affects Doc?：如果缺陷发现了设计或需求中的问题，需要修改原始的文档，那么这个属性就很有帮助。