BUG处理规范

背景说明

为了减少开发、测试在Bug上花费不必要的沟通成本，同时为迭代总结会提供报告依据，督促开发提升质量意识，制定以下规范内容。

相关职责

角色	职责
测试人员	1. 根据规范提交bug； 2. 及时验证bug是否已解决； 3. 及时关注开发拒绝bug，和相关人员沟通讨论解决方式；
测试负责人	1. 审核测试工程师提交的bug； 2. 定期review bug，报告现状，并给出解决意见；
开发人员	1. 以优先级为依据分析解决bug
开发负责人	1. 定期 review bug，对bug多的模块加强code review和单元测试； 2. 分析bug解决进度，对产品质量及进度进行风险评估；
产品	1、当开发和测试存在意见分歧时，进行需求确认 2、从产品角度划分bug修改的优先级；

测试负责人定期发送测试统计报告（每周或每迭代一次，需要包含BUG数量、BUG趋势图、提测质次数等）。

---

提交规范

为了开发同学能迅速定位并尽快修复问题，测试同学需要尽量提供全面、精准的Bug描述信息。测试人员应初步定位BUG，能给开发提供修改建议。提交BUG时用清晰的语言写明以下内容。

BUG提交地址目前已经统一到禅道系统。

 

角色	职责
标题	1. BUG简洁描述。 2. 如果没有指明模块选项，标题需要带上模块名。 3. 能让开发一眼就能明白问题现象和可能原因。
重要等级	1. 参考重要等级说明，此项是分析项目质量的重要依据，为必填项。
优先级	1. 根据允许的修复时长来排优先级，此项为必填项。
复现步骤	1. 此处写明操作步骤，可以结合视频、截图来提高描述清晰度。 2. 如果在特定账户、请求数据下才能复现，需要写明使用的账户，请求数据。
结果	提供异常结果截图。异常日志明确到错误位置，方便开发一目了然。 如果是页面功能，尽量提供Http请求、响应参数供开发快速定位问题所处模块。 提供日志明细：日志需要包含请求参数、响应结果、以及异常日志详情。
预期	写明正确的结果。避免测试、开发理解有偏差。

---

BUG严重程度

致命：导致系统无法正常工作的bug。系统崩溃、数据丢失、数据毁坏、非法退出、内存溢出，500错误等。

严重：对系统功能影响较大的bug。比如错误结果、遗漏功能、数据丢失等。

一般：表现为实现不符合需求/设计，但对系统而言影响一般的bug。

轻微：小问题、UI错误，文案提示，不影响功能，代码规范。

---

优先级与修复时长

紧急（P1）：致命类BUG，需要立即修复，修复时长<4小时。

高（P2）：严重类BUG，当天修复。

中（P3）：非主流程类的重要问题，产品发布前修复。

低（P4）：针对轻微类型BUG，可选修复。

---

解决方案说明

已解决：当开发人员修复问题后，本着对问题负责的态度，尽可能用清晰的语言描述问题原因，解决方案，对肯能引起类似BUG的地方，以注释的方式，提醒相关测试人员。
不予解决：测试建议性需求或者体验性需求，都应该作为这个状态处理；并建议测试人员与产品等需求方进行沟通。
延期解决：延期解决的问题，并不是最终的状态，需要持续关注，最后开发负责人或产品进行排期处理。
无法重现：当开发人员遇到不能复现的bug时，首先跟测试人员进行沟通，沟通后仍不能复现的情况，尽可能描述相关过程，然后将该bug置为无法重现。

BUG定位

https://blog.csdn.net/kaka1121/article/details/51538979?locationNum=2&fps=1