提Bug和修复Bug的流程
2019-03-10
测试人员对Bug的描述模版
- 问题现象/需求分析
- 问题的title，要注明类型，比如[客户发现] / [内部发现]，然后尽量一句话描述清楚问题现象
- 问题联系人。写明如果对问题有疑问，找谁确认？
- 如果第三方系统上面也有记录，那就写上第三方系统对应的链接，在第三方系统上也可以写自己的Redmine链接
- 问题是偶发还是必现？
- 问题现场是否保留？
- 问题的重现步骤？环境(生产/测试) / 版本(第N次变更) / 初始条件 / 触发条件 / 期望 / 实际现象
- 问题的初步排查过程和目前的结论
- 排查过程
- 对应的日志
- 初步结论
- 如果有对接过研发，写明对接者
- 需要研发提供的支持
- 列清楚想问的每个问题
- 说清楚期望达到的效果
- 可以给出修复建议
开发人员Fix Bug的描述模版
- 问题现象（在本地重现确认问题后，如果有补充可以追加描述）
- 问题现象
- 重现步骤
- 日志
- 问题分析
- 问题的排查过程
- 必要的业务逻辑的描述
- 每一步排查的论据：简要的代码和日志
- 问题原因
- 问题产生的根本原因，不明的话就写直接原因
- 问题从什么时候/什么版本开始存在？
- 问题是不是Regression？
- 修复建议
- 修复的大致思路，必要的代码逻辑
- 修复涉及哪几个模块？
- 在哪个版本被修复？
- 后续怎么快速验证是不是这个问题？
- 怎么验证这个问题被Fix？
- 问题结论
- 问题是否被解决？
- 问题怎么解决的？Code/配置？
- 后续怎么避免此类问题再次发生？Unit Test或其它手段。
Review（Code + Test）
- 提交的Patch必须要有人Review后才能Merge，不能给自己+2
- 提交的Patch要显式说明有没有单元测试
- 提交Patch后，不要直接上到预生成环境，先在本地环境集成测试环境中测试通过
- Code Review的同学要结合Redmine上描述认真review，不仅review代码，还要Review 本地基础环境中的测试，确认Bug有效。
