一、编写Bug report的原则

　　Bug report是测试中最重要的一部分，也是测试人员价值的终极体现，一个有效的Bug report，在编写的时候需要遵循以下原则：

　　（1）Bug可重现，尽可能找到重现规律。测试人员在编写Bug report之前必须在检查问题是否可重现，问题重现才可以让开发更有效地查找到原因并解决问题，对于比较复杂的问题，最好能够将Bug现场重现给开发人员，以方便问题追踪和原因定位。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。

　　（2）Bug描述简明准确，对于问题的描述，应该尽可能简明、准确。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤，不要出现在Bug report中。

　　（3）一个Bug report只描述一个Bug，如果将几个问题都写在一个Bug report中，开发人员很难有效发现自己的问题并解决，从而导致有些优先级别高的Bug没有得到及时的解决。因此在写Bug report的时候，将Bug按照不同的优先级别将不同的问题指定给相应的开发人员。

　　（4） Bug的唯一性，在提交Bug report之前，要先确认这个Bug是否已经被其它人发现并报告。

　　衡量优秀的Bug report的质量指标：

　　（1）对管理层来说，是清晰明了的，特别是在主题概要这一级；

　　（2）对于开发人员来说，是有用的，主要是提供能够让开发人员高效地调试问题的相关信息，使其可以很快的将Bug从“Opened”状态转变成“Closed”状态，提高测试和开发的工作效率；

　　（3）对于后期的维护，能够有效从Bug信息查询出问题的描述和解决的方法。

　　二、如何编写Bug report

　　Bug report作为测试和开发之间沟通的桥梁，测试人员在报Bug的时候，有效的Bug描述，会更加容易帮助开发解决问题。一般来说，作为一个优秀的Bug report，应该包括以下内容：

　　1、标题：简明扼要地对Bug进行一个概述，让人看标题就知道大概出现了什么问题。比如：“smfilter模块在压力测试时出现内存泄露。”Bug

　　2、的属性，Bug的属性应该包括：Bug

　　（1）产品名称：测试产品的名称。

　　（2）产品子系统：测试产品的子系统，如果产品比较小，该项可以忽略。

　　（3）产品模块：测试产品发现问题的模块的名称。

　　（4）测试版本：当前的测试版本。

　　（5）测试平台：Bug的产生跟平台有关，有些在suse下产生的Bug，在soralis下则正常，因为在报Bug的时候需要将当前测试的服务器的版本。

　　（6）测试阶段：模块测试、内部集成测试、外部集成测试。

　　（7）问题级别：紧急、严重、一般、轻微

　　（8）优先级别：高、较高、一般、低

　　（9）问题来源：测试、工程故障、升级、其他

　　（10）问题类型：功能问题、版本问题、遗留问题、新需求、低级错误、改进建议、移植修改、割接问题、配置错误、编译问题、性能问题、设计问题、兼容问题、新功能增强、偶发性出错。

　　这些属性在Bug跟踪管理系统中应该有默认值，在测试人员报bug的时候选择对应的属性值。