缺陷定义和提交规范

Bug标题：

代码错误、界面优化、设计缺陷、配置错误、安装部署、安全相关、性能问题、标准规范、测试脚本、其他、文字错误、图片问题、界面排版

下面举个列子（之前看的别人写的，忘了链接）
1.Bug 标题清晰易懂，标准是一眼就明白需要反馈的问题；
2.提供必现的操作步骤（如果有的话），记得按第三方的角度去进行描述，最好自己可以按描述无脑操作一遍试试；
3.进行关联场景的验证，尽可能确定出现问题的关键要素，可以把验证过的场景都补充到 bug 说明中；
4.确定关键要素后，尽可能的去定位问题出现的技术原因，避免只是简单的现象描述；
5.就算问题很明显，也需要截图为证，必要的时候进行录屏；

二、bug规范

Bug记录包含内容和tag两部分。

2.1 内容模板

bug描述——bug的直观简短的描述
登录信息——如果需要登录才能复现的bug，提供登录的账号和密码，可缺省
bug复现步骤——对于操作步长超过3的，且RD难以理解怎么复现的问题，提供复现问题的步骤。
预期结果——描述需求预期的结果，必要时辅以截图说明
实际结果——描述RD实现后的实际结果，必要时辅以截图说明

2.2 tagtag部分包括以下几项（必填）：

优先级——需要RD修复的紧急程度，是问题严重性和对测试block程度的综合考虑
严重级别——问题严重程度，可理解为被用户接受的程度
问题分类——描述问题本身的属性，是最直接、最直观的一个分类方式
问题发现阶段——描述QA发现问题的阶段，是评估QA测试质量的重要指标
问题引入方式——评估RD开发质量的重要指标
问题来源——比较粗放的一种分类方式，作一个大体的分类
解决结果——描述bug修复情况
发现版本——发现问题的版本，统一为x.x.x
修复版本——修复问题的版本，统一为x.x.x