Bug管理指南

·Bug相关概念

   =》 什么是bug?

 　 — 功能没有实现或与规格说明不一致的问题是bug；
　　— 不能工作(死机、没反应)的部分是bug；
　　— 不兼容的部分是bug；
　　— 边界条件未做处理是bug；
　　— 界面、消息、提示、帮助不够准确是bug；
　　— 屏幕显示、打印结果不正确也是bug;
　　— 有时把尚未完成的工作也作为一个bug。

·判断Bug的规则

　　— 软件未达到产品规格说明书（需求）标明的功能。
　　— 软件出现了规格说明书指明不会出现的错误。
　　— 软件功能超出规格说明书指明的范围。
　　— 软件未达到规格说明书虽未指出但应达到的目标（隐含需求）。
　　— 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
　　— 需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止。

·Bug的生命周期

　　— Bug的生命周期就是指Bug从开始提出到最后完全解决，并通过复查的过程。在这个过程中Bug报告的状态不断发生着变化，记录着Bug的处理进程。

　=》Bug Lifecycle Using Bugfree

　=》The Specific step in Bug Lifecycle

·有效描述Bug

　　— 短小：只解释事实和演示、描述Bug必需的细节；
　　— 单一：每一个报告中针对一个Bug；
　　— 步骤清晰：要清楚地描述出Bug的发生场景，包括前置条件和操作的详细步骤；
　　— 再现：按照预定步骤可以重现相同状况；
　　— 在报告Bug时只描述事实，不做评价，也不要有人身攻击；
　　— 必要的时候可以添加注释（remarks）；
　　— 可以上载屏幕抓图和其他附件。
Bug的摘要是要用一句话的形式简明扼要地将Bug描述出来，要清晰指出Bug所在部位以及其错误类型，不能太笼统。
如“页面对非法输入有问题”可以修改为“流量信息查询页面对于非法输入没有进行校验”。

·Bug 的状态
　　— 新建状态（ NEW ）
　　　　 Bug创建后的初始状态。
　　— 已分配状态（ASSIGNED）
　　　　 经过确认为合法软件问题后分配给开发人员的状态。
　　— 待验证状态（RESOLVED） 
　　　　 开发部门对软件问题进行处理或修改后的状态。
　　— 重新打开状态（REOPENED）
　　　　 对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。对于“关闭/延迟修改”状态的软件问题，如果时机成熟，需要重新开发，则将其状态改为“重新打开”状态。
　　— 关闭状态（CLOSED）
　　　　 Bug生命周期的结束。
　　— 解决状态（VERIFIED）
　　　　 经测试部门对修改后的软件问题进行验证并确认修改正确后的状态。
　　— 未经证实状态（UNCONFIRMED）
　　　　 由开发人员自己提交的Bug，是一种初始状态，待测试人员确定后变为“New”。

·Bug 的级别：在软件测试过程中发现的Bug，要根据其严重程度进行分类，

　　=》然后，进行不同的处理。可以把Bug划分为七级：
　　　　第一级（blocker）: 引起操作系统“挂起”或“崩溃”的错误；
　　　　第二级（critical）: 引起软件本身“挂起”或“崩溃”的错误；
　　　　第三级（major）: 不能完成软件说明书定义的功能的错误；
　　　　第四级（normal）: 程序所完成的功能与软件说明书定义不符的错误；
　　　　第五级（minor） : 显示方面的错误；
　　　　第六级（trivial） : 其它“轻微”的错误（如文本差错）；
　　　　第七级（enhancement）：增强或者改进。

　　=》 根据严重程度，处理工作日

　　　　Blocker、critical：响应时间1天，处理1天
　　　　Major、normal：响应时间1天，处理3天
　　　　Minor、trivial：响应时间1天，处理7天
　　　　Enhancement:时间未定

·跟踪Bug

　　— 测试人员要不断跟踪Bug，直到Bug修正，问题解决为止。
　　— 新提交的Bug为NEW状态，经开发人员修改后，Bug变为RESOLVED（待验证）状态。此时就需要测试人员对Bug进行回归测试，验证问题是否修正。如果问题仍然存在，则测试人员将该Bug的状态修改为REOPENED（重新打开）；如果通过验证确认问题已经修改好了，则测试人员将该Bug的状态置为VERIFIED（已验证），同时添加附加意见如“该Bug在Release xx.xx版本中已经修正”。

　　— 还有一种情况：开发人员认为Bug在当前版本可以暂不修改，而考虑在后续版本中再做修正，Bug的对应状态为LATER。
　　— 对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意在后续版本修正，则测试人员可以将该Bug的状态置为VERIFIED；如果讨论结果是需要在本版本中解决问题，则测试人员应将该Bug的状态置为REOPENED，重新打开Bug。