BUG处理流程规范.doc

BUG提出和处理流程规范 1引言 1目的 提高测试以及产品缺陷修改效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本 2适用范围 适用于研发部门（Confernece、Flash、监控），质量保证部门 1.3 定义 bug：通过测试检查出的产品缺陷； 新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分； 4参考资料 无 2 BUG提交和处理规范说明 在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条件，需要描述使用的环境，在BUG出现前的具体操作，如果抓图，必须抓取jpg全屏图象，但不能使用BMP格式上传到BUG库中，有抓包文件需要上传BUG库，空间不够需要放到\\192.168.0.254\qa\测试\bug日志目录中，标题以BUG号区分； 在测试人员提交bug的时候，必须按具体情况，填写重要级别、出现频率、优先级别三个栏目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该bug下的注解中提出意见，并“打回”给bug提交人员或质量部经理处，经过确认后修改； 开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成“已确认”时必须进行必要的描述和说明,在状态变更时，必须要指定具体接收人； 开发人员在注解中描述该BUG计划什么时候解决或做其他阐述的时候，要明确写清承诺的具体版本号，禁止使用“上一版本”、“本版本”、“下一版本”等字样，以免造成误会或混淆； 修改完成的BUG注释中加入相关的确认信息，如“XXX Review并通过。 如果已经是的BUG，测试人员在后期测试中又出现了需要重新打开，重开后的BUG状态为，测试人员需要再多一个操作，即指派给具体的研发人员。一直处于状态的BUG，测试人员需要经过两轮（即两个版本）测试后仍然没有重现的，可以关闭。但是此两轮测试在该BUG中必须有注释，比如：“版本（有具体版本号）测试没有重现”，当第二轮测试仍没出现时也需要注释一次，即可进行关闭。其特点：个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 支持多项目、多语言； 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 主页可发布项目相关新闻，方便信息传播； 支持上传文件，提供进一步的bug信息； 支持上传项目文档； 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 缺陷报告可打印或输出为CSV格式。支持可定制的报表输出，可定制用户输入域； 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel中进一步分析； 流程定制不方便，但该流程可满足一般的缺陷跟踪。在提交bug时需要填写相关信息，还可以上传相关文件（如出错的log或者截图等），对于bug添加注释（允许再次更新）。下面是基本信息的介绍[出现频率]可重现-- 稳定地能重现经常-- 比较经常出现偶尔 -- 偶尔出现不可重现 -- 无法重现N/A -- 其他情况[严重性] 不合理或别扭 -- 使用不方便，吹毛求疵的标准文本错误-- 文本错误崩溃死锁 -- 导致死机的bug严重错误 -- 导致功能无法正常运行下去次要错误---功能性问题 [优先权]高-- 优先级高 中 -- 普通优先级 低 -- 优先级较低，有时间就解决加急 -- 紧急bug,尽快解决特急 -- 刻不容缓，马上需要解决 无 -- 无关紧要，可以慢慢解决 [bug状态]新建 -- 新加入的打回 -- 需要更多的诊断信息，需要bug提交者提供已确认 -- 看过了， 确认问题和指派已分派 -- 指派给程序员解决已解决 -- 应该已经解决了，等待测试确认已关闭 -- 关闭bug，确认已经解决一个典型的bug跟踪流程：由测试人员提交bug，如果经过协商确认这不是bug，由测试人员直接“关闭” bug。如果是bug，但是可能延期到下一个版本或者不着急解决的，由测试或者开发人员将状态设为“已确认”。如果是需要修改的bug，“指派”到相关的开发人员负责。开发人员在完成bug的修改后将bug状态修改为“已解决”。然后由测试人员再次测试后确认bug修改了，将bug状态设为“已关闭”。这样一次bug修改就完成了。 但还有特殊情况，有时候关闭的bug会再次出现，这时候需要重新打开 bug，bug状态变为“打回”，重新进入“指派”或者“确认”的流程。可以注意到上面的流程中，“开发人员”是无权关闭bug的，他只能把bug标记为resolved等待“测