背景说明
为了减少开发、测试在Bug上花费不必要的沟通成本，同时为迭代总结会提供报告依据，督促开发提升质量意识，制定以下规范内容。
相关职责
| 角色 |
职责 |
| 测试人员 |
1. 根据规范提交bug； 2. 及时验证bug是否已解决； 3. 及时关注开发拒绝bug，和相关人员沟通讨论解决方式； |
| 测试负责人 |
1. 审核测试工程师提交的bug； 2. 定期review bug，报告现状，并给出解决意见； |
| 开发人员
扫描二维码关注公众号，回复：
5795882 查看本文章
|
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. 如果在特定账户、请求数据下才能复现，需要写明使用的账户，请求数据。 |
| 结果 |
|
| 预期 |
写明正确的结果。避免测试、开发理解有偏差。 |
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