BUG处理流程规范

1、BUG提出和处理流程规范1引言1目的提高测试以及产品缺陷修改效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本2适用范围适用于研发部门（Confernece、Flash、监控），质量保证部门1.3 定义bug：通过测试检查出的产品缺陷；新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分；4参考资料无2 BUG提交和处理规范说明在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条件，需要描述使用的环境，在BUG出现前的具体操作，如果抓图，必须抓取jpg全屏图象，但不能使用BMP格式上传到BUG库

2、中，有抓包文件需要上传BUG库，空间不够需要放到 HYPERLINK 192.168.0.254qa测试bug日志 192.168.0.254qa测试bug日志目录中，标题以BUG号区分；在测试人员提交bug的时候，必须按具体情况，填写重要级别、出现频率、优先级别三个栏目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该bug下的注解中提出意见，并“打回”给bug提交人员或质量部经理处，经过确认后修改；开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成“已确认”时必须进行必要的描述和说明,在状态变更时，必须要指定具体接收人；开发人员在

3、注解中描述该BUG计划什么时候解决或做其他阐述的时候，要明确写清承诺的具体版本号，禁止使用“上一版本”、“本版本”、“下一版本”等字样，以免造成误会或混淆；修改完成的BUG注释中加入相关的确认信息，如“XXX Review并通过。如果已经是“关闭”状态的BUG，测试人员在后期测试中又出现了需要重新打开，重开后的BUG状态为“打回”，测试人员需要再多一个操作，即“指派”给具体的研发人员。一直处于“打回”状态的BUG，测试人员需要经过两轮（即两个版本）测试后仍然没有重现的，可以关闭。但是此两轮测试在该BUG中必须有注释，比如：“XX版本（要求有具体版本号）测试没有重现”，当第二轮测试仍没出现时也需

4、要注释一次，即可进行关闭。3 Mantis Mantis是PHP/MySQL/Web-based缺陷跟踪系统。其特点：个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 支持多项目、多语言； 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 主页可发布项目相关新闻，方便信息传播； 支持上传文件，提供进一步的bug信息； 支持上传项目文档； 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 缺陷报告可打印或输出为CSV格式。支持可定制的报表输出，可定制用户输入域； 有

5、各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel中进一步分析； 流程定制不方便，但该流程可满足一般的缺陷跟踪。在提交bug时需要填写相关信息，还可以上传相关文件（如出错的log或者截图等），对于bug添加注释（允许再次更新）。下面是基本信息的介绍出现频率可重现- 稳定地能重现经常- 比较经常出现偶尔 - 偶尔出现不可重现 - 无法重现N/A - 其他情况严重性不合理或别扭 - 使用不方便，吹毛求疵的标准文本错误- 文本错误崩溃死锁 - 导致死机的bug严重错误 - 导致功能无法正常运行下去次要错误-功能性问题优先权高- 优先级高中 - 普通优先级低

6、- 优先级较低，有时间就解决加急 - 紧急bug,尽快解决特急 - 刻不容缓，马上需要解决无 - 无关紧要，可以慢慢解决bug状态新建 - 新加入的打回 - 需要更多的诊断信息，需要bug提交者提供已确认 - 看过了， 确认问题和指派已分派 - 指派给程序员解决已解决 - 应该已经解决了，等待测试确认已关闭 - 关闭bug，确认已经解决一个典型的bug跟踪流程：由测试人员提交bug，如果经过协商确认这不是bug，由测试人员直接“关闭” bug。如果是bug，但是可能延期到下一个版本或者不着急解决的，由测试或者开发人员将状态设为“已确认”。如果是需要修改的bug，“指派”到相关的开发人员负责。开

7、发人员在完成bug的修改后将bug状态修改为“已解决”。然后由测试人员再次测试后确认bug修改了，将bug状态设为“已关闭”。这样一次bug修改就完成了。但还有特殊情况，有时候关闭的bug会再次出现，这时候需要重新打开 bug，bug状态变为“打回”，重新进入“指派”或者“确认”的流程。可以注意到上面的流程中，“开发人员”是无权关闭bug的，他只能把bug标记为resolved等待“测试人员”或者其他管理人员关闭 bug。mantis在权限的实现方面支持下面几种权限的用户查看人员 - 只能观看bug情况的用户报告人员 - 只能提交bug的用户修改人员 - 能够提交bug和更新bug的状态开发人员 - 有很高的权限，可以对BUG进行修改、 指定、解决、关闭、删除。经理 - 管理project的用户，可以将开发人员指定给某个项目。管理员 - 系统管理员在mantis的权限控制系统中“开发人员”拥有对bug生存周期的全部权限，个人感觉这是不妥的，至少关闭、删除 bug的权限要属于bug的“报告者”或者“经理”一级，有时间的话可以对于系统进行