一、编写Bugreport的原则

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

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

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

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

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

衡量优秀的Bugreport的质量指标：

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

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

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

二、如何编写Bugreport

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

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

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

• 产品名称：测试产品的名称；

• 产品子系统：测试产品的子系统，如果产品比较小，该项可以忽略；

• 产品模块：测试产品发现问题的模块的名称；

• 测试版本：当前的测试版本；

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

• 测试阶段：模块测试、内部集成测试、外部集成测试；

• 问题级别：紧急、严重、一般、轻微；

• 优先级别：高、较高、一般、低；

• 问题来源：测试、工程故障、升级、其他；

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

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

3、负责人：

• 开发人员：测试产品模块的开发人员；

• 测试人员：发现Bug的测试人员；

• 抄送：该Bug需要抄送给相关的开发人员或测试人员。一般来说，一个Bug除了发送给改Bug的开发负责人和测试负责人外，还需要抄送给项目经理、测试经理、该产品开发小组其他人员，该产品测试小组其他人员。

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

4、Bug的详细描述：这是Bug最重要的一部分，对Bug描述清晰准确，不仅有助于开发人员迅速定位解决问题，还对以后的维护工作有很大的帮助。一些比较简单的Bug，可以使用一两句话把问题准确描述，而对于一些比较严重或负责的Bug或者是新的需求，则应该详细说明。

5、附件：对于一些特殊的问题或者不能用语言很好地描述的问题，可以增加界面图形说明或参考资料或详细日志等附件。

6、其它属性：

• BugID：Bug的唯一标志；

• 建档时间；

• 建档人；

• Bug回复时间；

• Bug关闭时间。

一般来说，在报bug之后，这些属性一般由bug跟踪管理系统自动生成。

三、如何划分bug的严重级别

Bug的严重级别指的是软件缺陷对软件质量的破坏程度，也就是该软件缺陷的存在将对软件的功能和性能产生怎样的影响。在软件测试中，软件缺陷的严重级别应该从软件最终用户的立场来做判断，考虑缺陷对用户使用造成的后果的严重性。

1、紧急

• Bug足以造成系统崩溃，造成文件不可靠或潜在的数据丢失；

• Bug造成非正常地返回操作系统（系统崩溃或显示系统错误信息）；

• Bug造成程序越或要求Reboot系统；

• 造成缺乏关键的程序功能并无法逾越；

• 由于设计问题，使系统存在严重隐患。

2、严重

• Bug可能不会削弱系统，但将造成严重问题（如严重的格式化错误等）；

• 功能缺乏给用户带来极大不方便；

• Bug可以绕过，但将会很不方便或很难实现；

• 存在不明确或不完整的错误信息提示，极大地影响产品使用；

• 由于Bug的存在使产品其它部分不能测试；

• 由于计算方法问题，使数据错误；

• 由于设计原因，造成前后不一致，但问题可恢复。

3、一般

• 这个Bug在将来是严重的，但比主要问题要轻；

• 可以有一个比较简单的绕过Bug的解决方案；

• 存在不明确或不完整的错误信息提示，但对产品使用影响较小；

• 容错性方面存在不足；

• 由于精度问题造成数据不一致。

4、轻微

• 不可能被用户发现的Bug；

• 某个控件没有对齐，某个标点符号丢失等低级错误；

• 尚无法满足的新需求。

四、如何划分bug的优先级别

Bug的优先级是指解决软件缺陷的先后顺序，即哪些缺陷需要优先解决，哪些缺陷可以稍后解决。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，同时需要考虑问题修改的成本与时间。

1、高

这类Bug对产品影响非常大，造成产品不能移交。

2、较高

这类Bug对产品影响比较大，如果产品带着Bug发布给用户将会产生麻烦。

3、一般

这类Bug对产品影响一般，如果Bug被fix，产品会更好；或者是这类Bug对产品影响一般，如果fixbug不影响产品的交付期，一定要fix。

4、低

这类Bug对影响较小，只有在其它所有Bug已经被fix后，再fix这类Bug。

一般来说，严重级别高的bug具有较高的优先处理级别，但是严重级别和优先级并不总是一一对应。有时候严重级别高的Bug优先级不一定高，而一些严重级别低的Bug却需要及时处理，具有较高的优先级。例如，如果某个严重的bug只在非常极端的条件下产生而通过配置或人为注意可以避免，则可以稍后解决。另一方面，如果软件缺陷的严重性很低，例如，提示错误，但是提示信息很容易造成别人的误解，则必须尽快修改。

五、如何进行Bug描述

1、简明扼要的bug描述

一些比较简单的Bug，可以使用一两句话把问题准确描述，比如：“在管理网页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”

2、严重的程序缺陷bug描述

比较严重或复杂的Bug，应该在bug报告中进行详细的说明。对于产品的程序缺陷，也就是测试的时候发现的问题，此时作为Bug的详细描述，应该包括（根据实际情况选择）：

• 测试要点：测试用例的测试要点；

• 测试配置：如果有特殊的配置，需要在Bug描述中说明；

• 测试环境：发现Bug的测试环境；

• 测试步骤：详细描述发现Bug的操作步骤和流程；

• 实际结果：按照测试步骤测试后实际出来的操作结果；

• 预期结果：按照测试步骤测试后原本预期的操作结果；

• 测试结论：通过对比实际结果和预期结果，“诊断”程序出错原因；

• 归纳引申：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。

同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？

举例：

• 试点：检查点对点互通（简称P2P）网关系统短信过滤模块smfilter在大压力业务的时候是否有内存泄露或CPU暴涨；

• 测试配置：将系统所有模块的配置都调整到最优化配置，数据库中导入100万个手机过滤黑名单和50万个过滤关键词；

• 测试环境：smfilter安装在10.3.3.92，其余业务模块安装在10.3.3.91，测试工具安装在10.3.3.96，均为suse9操作系统；数据库安装在10.3.3.96，为oracle9204版本；

• 测试步骤：

1. 清理测试环境，确保测试环境干净；

2. 使用top查看系统各模块资源在正常范围之内：smfilter的内存使用5%（10M），CPU使用率为6%；

3. 使用手机模拟测试工具向P2P网关发送1000万条MO短信，同时使用网关模拟工具向P2P网关系统前转1000万条MT短信；其中各有200万条MO/MT短信含有是黑名单号码，200万条MO/MT短信内容含有关键词；

4. 观察smilter的内存使用率和CPU使用率是否上涨，发现CPU使用率在正常范围之内缓慢上升，但内存使用率则不断狂涨；

• 实际结果：短信发送高峰期，CPU使用率为56%，短信发送完毕CPU使用率恢复到8%；而内存使用则从原来的10M一直上涨到1.6G，且短信发送完毕也没有下降；

• 预期结果：在压力测试过程中，CPU和内存应该在正常范围内缓慢上升，短信发送完毕应该恢复到测试开始时的使用率；

• 测试结论：smfilter在大压力的情况下出现内存泄露的情况，请及时查找原因并解决。

3、新需求Bug描述

在后期维护中，对于新的需求，也作为Bug记录进Bug跟踪管理系统。在作为一个Bug增加进系统之前，应该由项目经理、开发人员和测试人员对新需求进行了评估和讨论，最终决定了解决方案。在这个过程中，测试人员充当着一个非常重要的角色，需要对需求非常明确，而且应该从系统的高度和设计的高度全面考虑需求的实现。此时作为Bug的描述，应该包括（根据实际情况选择）：

1. 求说明：详细的需求要点。

2. 配置说明：是否需要增加或修改配置，如果需要则详细说明应该增加或修改的配置。

3. 数据库结构：是否需要新增或修改数据库表结构，如果需要则详细说明新的数据库结构。

4. 实现方法：实现新需求采取的策略或技术，这部分通常是在讨论的时候由项目经理和开发人员决定的，当然，测试人员应该审核采取这样的技术是否真的合理，这就要求测试人员有比较强的技术背景了。

5. 业务流程：新需求在处理过程的业务流程，对于业务流程该如何处理，测试人员事先一定要先确认，并在Bug描述中进行详细的描述，使开发实现新需求以及测试人员验证新需求提供有效的依据。根据经验，有些时候，开发也不会很全面考虑整个系统的业务流程，经常会出现新增功能增加之后新问题又出来的情况，如果测试人员可以在描述中清楚说明整个业务的处理流程，就可以大大减轻开发工作量和测试工作量了。当然，前提是测试人员自己一定要对业务流程有一个非常清晰的概念，对于一些不能确认的流程，在事先可以征求项目经理的意见或与开发讨论确认。

6. 异常处理：在新增一个功能的时候，需要考虑这个功能可能会出现什么异常，这些异常出现的时候系统该如何处理。

举例：

1、需求点：为了提高高峰期点对点互通网关短信状态报告处理效率，增加状态报告缓存处理功能

2、新增配置项：在ptop模块的配置文件ptop.ini中增加以下配置：

[SERVER]
CacheStatus=0//是否需要启用短信状态报告缓存处理功能，0表示不启用，1表示启用，默认配置为0。
CacheStatusDir=SMS01//缓存状态报告的目录，每个smsPtop必须唯一
FetchInterval=10//状态报告缓存进行处理的时间间隔，单位：豪秒

3、业务流程：

• 若启用了状态报告缓存功能，接收到短信状态报告后做简单判断并给对方回响应；

• 将状态报告缓存到CacheStatus目录；

• 新起一条线程处理状态报告，FetchInterval时间间隔扫描一次状态报告目录，并处理状态报告；

• 若不启用状态报告缓存处理功能，则处理流程与原流程相同。

4、异常的处理：

• 接收到状态报告后如果存放失败，则马上处理状态报告；

• 若出现线程池满，则先sleep一秒，然后再处理状态报告；

• 模块重新启动后，若有状态报告积压，优先将积压数据取出来处理。

Bug报告的确是需要花费一定的时间，但是也给予效果显著的回报，使产品获得更好的质量。一方面，一个优秀的Bugreport可以轻易地打开开发人员和测试人员之间的积极关系，在时间上前期花费在编写优秀Bugreport上的时间和后期由于返工差的Bugreport花费的时间相抵消；另一方面，也可以有效改进测试小组和高层、平行管理层之间的沟通，增强测试小组的信任度。

六、如何进行Bug回复描述

开发人员修改问题之后，将Bug回复给对应的测试负责人。很多开发人员在回复的时候只是简单地用“已解决”或“fixed”这样的语句，对于简单浅显的问题来说，这样已经足够。而对于复杂或重要的问题，在回复的时候应该详细说明测试的解决方法，一般来说，Bug回复应该包括：

1. 问题原因：导致Bug产生的根源；

2. 问题结果：问题是否已经被解决说明，如“问题解决”、“下一版本解决”、“无法解决”等；

3. 配置说明：在fixedBug的时候是否需要增加或修改配置项，如果需要则详细说明配置；

4. 数据库结构：解决此问题是否需要改动数据库表，如果需要则需要详细说明；

5. 目标文件：解决此Bug的代码文件以及涉及到的相关代码文件文件；

6. 解决方法：解决此Bug的方法；

7. 改动代码：解决此Bug的时候有哪些代码被改动或增加，并将新的核心代码在回复中粘贴出来；

8. 业务流程：解决此Bug或新增功能的业务流程是否变更，如果有则详细说明新的业务流程，对于特殊的异常的处理也应该进行详细的说明。

开发人员回复Bug之后，测试人员会进行验证，如果问题还没解决或修改后引进了新的问题，则将这个Bug重新回复给开发人员，并且在回复中进行详细的问题描述。

七、如何进行Bug关闭描述

开发回复Bug之后，测试负责人验证该Bug，如果问题得到解决则关闭（否则回复给开发负责人，让其继续追踪）。关闭一个Bug时，大多数的测试人员都是采用“问题解决”或“OK”这样的语句回复，作为一个简单的问题这样回复已经足够。但是对于一些比较复杂的问题或需求，可能经过了多次的修改，修改的最终结果已经跟Bug描述有相当部分的出入了，因此在关闭Bug的时候，应该对Bug描述的内容进行一个总结：

1. 问题结果：问题是否已经被解决说明，如“问题解决”“下一版本解决”“无法解决”等；

2. 配置说明：软件问题解决之后最终需要新增或修改的配置文件和配置项目；

3. 数据库结构：软件问题解决之后，软件升级涉及到修改的数据库表结构有哪些以及需要执行哪些脚本；

4. 业务流程：Bugfixed之后的业务流程，如果是新需求，还要进行新功能点说明。

原文链接：https://blog.51cto.com/psnx168/1436559