二、Bug状态的说明
I、Bug活跃状态的说明
提交Bug时必须说明以下内容：
1.标题：对Bug现象进行简明描述，一般不超过20个字
2.状态及原因：状态改为活跃的（Active），原因为测试失败或构件失败
3.发现模块：Bug产生的代码模块或者在不清楚情况下先填发现的业务模块，以后进行更新。
4.发现版本及时期：推荐填写Build号而不是Revision号。因为测试只能发生在一个可测试的build上。只有构建失败才可以填写最新的那个Revision号。所谓时期可能是迭代号或者Milestone名称，依据项目管理流程定义。
5.优先级（Priority）与严重度（Severity）：一般两者成正相关，考虑项目资源或风险可能略有调整。优先度越高表明需要越早解决，严重度分为
1）.危险的（Critical）：关键的或者主要的功能无法使用，没有规避方法。用户不会使用该产品。
2）.高危的（High）：关键功能或主要功能没法使用，但可能规避，用户可能因该Bug而放弃使用该产品。
3）.中等的（Medium）：产品功能有缺陷但不致命，用户可能使用，但影响公司信誉。
4）.低危的（Low）：产品缺陷不是很紧要，但最好给予修改。
6.Bug所有人：一般此阶段是填写对应模块开发人员。不清楚情况下填写项目经理或者开发经理，由他们再另行分派。
7.详细描述：这一内容的填写最能区分测试人员的素质与水平的高低，大抵该区域填写的内容要涵盖如下方面:
1）发现的环境与操作步骤，记录Bug发生时你的环境和操作，可能它并不一定重现，但描述清楚可让涉众对问题有更形象的了解。
2）发生的概率，Bug不一定必然重现，如果非确定发生的Bug最好描述发生的概率，便于确定Severity。
3）个人的判断，高素质的具备较强开发能力的测试人员可能这时能够直接告诉DEV问题的原因或者问题代码所在。
8.相应链接与附件：可以包括失败时的截图，Log文件或者参考的链接（要保证有效性）
II、Bug解决状态的说明
一个Bug报告给DEV后，或直接处理或Bug-Scrub会议讨论把活跃状态的Bug改为解决的状态，更改时需要填写：
1.Bug所有人：需要验证关闭的Bug填写Tester，需要讨论的填写项目经理
2.修改理由：参见第一部分关于Bug解决两条路径的说明。
3.修改的版本号：填写修改代码或文档检入（Check-in）的Revision号，自动化系统最好在构建时自动改写为修复后最新可用Build号。这需要DEV在修复时关联代码和Bug。
4.Bug的根本原因与修复方案说明：DEV需要填写该Bug发生的原因，便于涉众了解产品问题的症结，便于Tester针对修复和周边模块设计新的测试用例。
III、Bug关闭状态的说明
经过解决的bug由Tester验证关闭，填写原因，状态改为关闭的；验证不通过的填写状态为Active以及理由，并加必要注释于历史记录中。这时的填写可以参看活跃状态的说明。
