2021年Bug管理规范及流程.docx

《2021年Bug管理规范及流程.docx》由会员分享，可在线阅读，更多相关《2021年Bug管理规范及流程.docx（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精品word 可编辑资料 - - - - - - - - - - - - -Bug属性规范及流程版本时间创建人1.02021.6.19第 1 页，共 8 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -目录Bug 属性规范及流程11. 目的32. 范畴33. 工具34. 角色和职责35. Bug 属性定义45.1 bug类型45.2 bug严峻性55.3 bug优先级56. Bug 治理流程66.1 提交 bug66.2安排bug.66.3解决bug.76.4验证bug.76.5遗留bug.76.5.1 跟踪遗留bug76.

2、5.2 产品发布后发觉的bug86.6 bug分析8第 2 页，共 8 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -1.目的本文档定义bug的整个生命周期，规范bug的解决方案及治理流程；Bug在流转的过程中有章可循；规范 bug严峻等级与bug 解决优先级， 使开发人员与测试人员能依据 此文档精确判定bug的严峻程度并加以解决；2.范畴开发人员.测试人员3.工具禅道：4.角色和职责序号角色职责01测试工程师1) 提交 bug ，用 bug级别反映bug的严峻程度2) 验证 bug为否已被解决02开发负责人1) 确认 b

3、ug ，并进行bug安排2) 分析 bug修复进度，对项目的质量.进行风险评估03开发工程师1) 修改 bug ， 并备注处理方式第 3 页，共 8 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -5. Bug 属性定义属性名称描述来源包含所属产品.所属模块.所属项目.影响版本，挑选bug来源利于开发定位并解决；bug类型依据 bug的自然属性划分的bug种类严峻性因 bug引起的故障对软件产品的影响程度优先级Bug 必需被修复的紧急程度标题用一句简洁的语言将问题的核心描述出来描述具体描述bug 显现的步骤和结果附件为 bu

4、g添加更核心的说明，更有说服力的证据，包括截图.视频.log 等概率描述 Bug复现的概率5.1 bug类型Bug 类型描述功能产品功能方面的bug ：包括模块功能实现.功能使用性.规律性等bug UiUI 表现，包括对话框样式和文字描述问题接口与其他组件.模块或设备驱动程序.调用参数.掌握块或参数列表相互影响的 bug性能不满意系统可测量的属性值，如：并发量.数据量.事务处理速度等其他设计.安装.移动性等第 4 页，共 8 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -5.2 bug严峻性Bug 严峻性描述致命 (1)不

5、能执行正常的功能操作，或者因产品缘由导致系统死机，需立刻修复的问题严峻 (2)部分功能存在严峻缺陷，尚可连续测试，不影响产品稳固性；一般 (3)次要功能或者界面存在的一些错误，不影响正常测试；优化 (4)测试对于产品的一些改进建议；5.3 bug优先级Bug 优先级描述紧急 (1)影响测试，需立刻修复；高(2)必需在版本发布之前修改完；中(3)必需修改，不肯定立刻修改，需争论确定在某个特定的里程碑前修改完低(4)对产品的影响比较小，在时间不答应的情形下可以临时不修改第 5 页，共 8 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - -

6、 - -6. Bug 治理流程6.1 提交bug在提交一个缺陷的缺陷，第一尽量描述这个缺陷的属性；当然，我们在提交一个问题之前第一应当保证，这个缺陷为没有被提过的，以免造成重复缺陷单；提交后的bug状态为：激活6.2 安排bug开发经理对bug进行初步评审，确定并指派到相应开发人员；安排后的bug状态为：已确认第 6 页，共 8 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -6.3 解决bug开发人员在确认完一个问题需要处理时，那么就对其进行处理工作；解决后的bug状态为：已解决6.4 验证bug回来缺陷对于测试人员来说为

7、特别重要的工作，其有三个入口两个出口；确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回来；测试人员再次确认，假如真如开发人员所说，就将问题关闭；假如非开发人员所说，为由于问题描述模糊或其它缘由喂重现问题，就再次注明缘由转给开发人员；确认修复问题：对开发人员修复的问题再次进行确认，确认能过，就关闭问题；确认不通过，将问题再次打开并转给开发人员；确认固定问题：有方案的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应当准时关闭；有些固定问题依旧存在且变得紧急，对于这类问题应当准时打开交给开发人员处理；验收通过的bug状态

8、为：已关闭；验收不通过的bug状态为：激活；6.5 遗留bug6.5.1 跟踪遗留 bug对于让步发布的产品，需要跟踪产品发布后的答应情形；对遗留的bug跟踪记录并分析其影响范畴，知道遗留bug形成解决结果；第 7 页，共 8 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -6.5.2 产品发布后发觉的bug产品发布后的bug来源有： 客户.开发.测试人员； 该类 bug在发觉后需要提交给项目组，纳入 bug治理，该类bug的发觉阶段标识为已发布，便于分析缘由；6.6bug分析通过 bug的数据分析，总结bug显现的缘由.类型.规律，实行相应措施防止该类型bug再次显现，提高产品质量；1） ） 统计项目组阶段bug的趋势图，用于分析产品的质量；2） ） 测试人员的每个项目的测试终止以后，将bug分析结果写在测试报告中；第 8 页，共 8 页 - - - - - - - - - -