一、 编写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标题：简明扼要地对Bug进行一个概述，让人看标题就知道大概出现了什么问题。比如：“smfilter模块在压力测试时出现内存泄露。”
2、 Bug的属性，Bug的属性应该包括：
（1） 产品名称：测试产品的名称。
（2） 产品子系统：测试产品的子系统，如果产品比较小，该项可以忽略。
（3） 产品模块：测试产品发现问题的模块的名称。
（4） 测试版本：当前的测试版本。
（5） 测试平台：Bug的产生跟平台有关，有些在suse下产生的Bug，在soralis下则正常，因为在报Bug的时候需要将当前测试的服务器的版本。
（6） 测试阶段：模块测试、内部集成测试、外部集成测试。
（7） 问题级别：紧急、严重、一般、轻微
（8） 优先级别：高、较高、一般、低
（9） 问题来源：测试、工程故障、升级、其他
（10） 问题类型：功能问题、版本问题、遗留问题、新需求、低级错误、改进建议、移植修改、割接问题、配置错误、编译问题、性能问题、设计问题、兼容问题、新功能增强、偶发性出错
这些属性在Bug跟踪管理系统中应该有默认值，在测试人员报bug的时候选择对应的属性值。
3、 Bug负责人：
（1） 开发人员：测试产品模块的开发人员
（2） 测试人员：发现Bug的测试人员
（3） 抄送：该Bug需要抄送给相关的开发人员或测试人员。一般来说，一个Bug除了发送给改Bug的开发负责人和测试负责人外，还需要抄送给项目经理、测试经理、该产品开发小组其他人员，该产品测试小组其他人员
这些属性在Bug跟踪管理系统中也应该有默认值，在测试人员报bug的时候选择对应的负责人。
4、 Bug的详细描述：这是Bug最重要的一部分，对Bug描述清晰准确，不仅有助于开发人员迅速定位解决问题，还对以后的维护工作有很大的帮助。一些比较简单的Bug，可以使用一两句话把问题准确描述，而对于一些比较严重或负责的Bug或者是新的需求，则应该详细说明。
5、 附件：对于一些特殊的问题或者不能用语言很好地描述的问题，可以增加界面图形说明或参考资料或详细日志等附件。
6、 其它属性：
（1） BugID：Bug的唯一标志
（2） 建档时间
（3） 建档人
（4） Bug回复时间
（5） Bug关闭时间
一般来说，在报bug之后，这些属性一般由bug跟踪管理系统自动生成。
三、 如何划分bug的严重级别
Bug的严重级别指的是软件缺陷对软件质量的破坏程度，也就是该软件缺陷的存在将对软件的功能和性能产生怎样的影响。在软件测试中，软件缺陷的严重级别应该从软件最终用户的立场来做判断，考虑缺陷对用户使用造成的后果的严重性。
1、 紧急
（1） Bug足以造成系统崩溃，造成文件不可靠或潜在的数据丢失
（2） Bug造成非正常地返回操作系统（系统崩溃或显示系统错误信息）
（3） Bug造成程序越或要求Reboot系统
（4） 造成缺乏关键的程序功能并无法逾越
（5） 由于设计问题，使系统存在严重隐患
2、 严重
（1） Bug可能不会削弱系统，但将造成严重问题（如严重的格式化错误等）
（2） 功能缺乏给用户带来极大不方便
（3） Bug可以绕过，但将会很不方便或很难实现
（4） 存在不明确或不完整的错误信息提示，极大地影响产品使用
（5） 由于Bug的存在使产品其它部分不能测试
（6） 由于计算方法问题，使数据错误
（7） 由于设计原因，造成前后不一致，但问题可恢复
3、 一般
（1） 这个Bug在将来是严重的，但比主要问题要轻。
（2） 可以有一个比较简单的绕过Bug的解决方案
（3） 存在不明确或不完整的错误信息提示，但对产品使用影响较小
（4） 容错性方面存在不足
（5） 由于精度问题造成数据不一致
4、 轻微
（1） 不可能被用户发现的Bug
（2） 某个控件没有对齐，某个标点符号丢失等低级错误
（3） 尚无法满足的新需求
四、 如何划分bug的优先级别
Bug的优先级是指解决软件缺陷的先后顺序，即哪些缺陷需要优先解决，哪些缺陷可以稍后解决。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，同时需要考虑问题修改的成本与时间。
1、 高
这类Bug对产品影响非常大，造成产品不能移交。
2、 较高
这类Bug对产品影响比较大，如果产品带着Bug发布给用户将会产生麻烦。
3、 一般
这类Bug对产品影响一般，如果Bug被fix，产品会更好；或者是这类Bug对产品影响一般，如果fix bug不影响产品的交付期，一定要fix。
4、 低
这类Bug对影响较小，只有在其它所有Bug已经被fix后，再fix这类Bug
一般来说，严重级别高的bug具有较高的优先处理级别，但是严重级别和优先级并不总是一一对应。有时候严重级别高的Bug优先级不一定高，而一些严重级别低的Bug却需要及时处理，具有较高的优先级。例如，如果某个严重的bug只在非常极端的条件下产生而通过配置或人为注意可以避免，则可以稍后解决。另一方面，如果软件缺陷的严重性很低，例如，提示错误，但是提示信息很容易造成别人的误解，则必须尽快修改。
五、如何进行Bug描述
1、 简明扼要的bug描述
一些比较简单的Bug，可以使用一两句话把问题准确描述，比如：“在管理网页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”
2、 严重的程序缺陷bug描述
比较严重或复杂的Bug，应该在bug报告中进行详细的说明。对于产品的程序缺陷，也就是测试的时候发现的问题，此时作为Bug的详细描述，应该包括（根据实际情况选择）：
（1） 测试要点：测试用例的测试要点
（2） 测试配置：如果有特殊的配置，需要在Bug描述中说明
（3） 测试环境：发现Bug的测试环境
（4） 测试步骤：详细描述发现Bug的操作步骤和流程
（5） 实际结果：按照测试步骤测试后实际出来的操作结果
（6） <
