3、发生条件（原因）

　　这一模块中主要的部分是对缺陷发生的原因进行说明。其次要写明原因分析责任者（一般是对应机能的开发人员），原因区分，缺陷区分等项。之所以要将原因写明，也是为了给其他犯同样错误的开发人员一个借鉴。Bug票并不是单个人的问题记录，是一个项目中多体现出来的问题所在，有可能同样的问题，多个开发者都会出现，那么其中一个解决了的话，bug票记录在案，那么别的开发人员可以通过原因分析来找到自己的问题，并加以纠正，这样可以提高整个项目的效率。这些都有分析人员来填写。在测试人员开出这张票的时候，往往会将开发者默认为原因分析者填写进去，这样，开发者容易根据自己的姓名来找到对应的bug票。如果分析者跟开发者不是同一个人的话，将由分析者自己将那一栏的内容给更新掉。这时的缺陷对应状态可以变更为：对应中。

　　4、对策处置

　　对策处置的关键在于对策内容，这是针对缺陷的对应方法的记录。重要性如同发生条件中的原因记录。除此之外，还包含有处置者，修正日，修正版本号，缺陷种别，对应类别等。

　　这里要强调一下修正版本号的重要性，这如同测试人员开票时要写明bug出现的版本号一样，修正之后的版本号也必须写明。这样，测试人员在对应这张票的时候，可以根据相应的版本来取source 进行测试。这是版本管理规范化中必须的要求。

　　缺陷种别主要是要表述清楚，这个bug到底是开发人员开发的有误，或是测试人员测试的不当导致的错误，抑或是设计人员一开始设计上的错误。这也是为了便于整个项目问题分析而设立的。这一部分由对应者来负责填写。此时的缺陷对应状态变更为：对应结束

　　5、缺陷确认

　　缺陷确认是在开发人员把bug修正之后，测试人员再根据修正版本取相应source来进行测试，确认那个bug是否真的已经修正了。在确认的过程中，可以将bug票的对应状态更新为：检证中。而当这个bug经测试之后没有问题了，那么对应状态可以设置为：检证结束。这也意味着这张票已经结束了。

　　在确认这块中，还应注明检证者，检证日，版本号和检证结果。因为起票的人未必是后来进行缺陷确认的人，所以这一项得有相应的确认者来填写。版本号也未必是开发人员写的版本号，有可能对应者在对应这个bug票的时候，打了版本，然后他在对应别的bug的时候又打了新的版本上去。这时候测试者往往可以取更新的那个版本来进行测试，所以这时要准确的填写清楚确认测试时的版本号。而检证结果是两种，OK/NG。因为不一定开发人员修正之后的一定是正确的，所以这时候，检证结果的记载也是很重要的。如果检证没有通过，那么测试人员可以将对应状态再次变更为：修正依赖中。让开发人员再次对应。

　　当然项目不同，bug票的设置也会略有不同，但是如果把大的模块把握好的话，无论什么样的项目都可以设计出好的bug票。