BUG提交建议
我们在提交BUG之前需要将发现的问题与BUG库中的问题进行对比，避免重复提交同样的BUG。
一、新建BUG
1.BUG标题规范 
BUG标题：BUG主要信息描述，需要采用简洁、切中要害的概要。
什么界面进行什么操作出现什么结果（1.操作步骤指对测试结果起到关键作用的一步；2.结果要描述清晰准确）
标注特殊说明（如项目/模块名称：，如通话：）
2.项目名称/模块路径
项目名称：该BUG属于哪个项目，归哪个项目组解决，使不同的项目组组看到和及时定位自己项目的错误。
模块：是准确说明该问题所属的模块，以便于开发等其他相关人员更方便准确的定位问题
模块路径
3.BUG状态
Open、Resolved、Duplicate、Postponed、Closed、Rejected、Reopen
4.指派给
分配给当前处理该BUG的负责人
5.抄送给
将当前BUG发送给其他相关负责人
6.严重程度
1级：（Low）建议类错误，对软件的改进意见或者建议
2级：（Medium）使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大
3级：（High）影响系统正常运行的缺陷，主要功能出现错误，影响到产品的使用
4级：（Very High）主要功能丧失，严重地影响系统要求或基本功能的实现。不能执行正常工作功能或重要功能，因软件原因导致系统司机、数据丢失等需要马上修正。
7.可再现性
描述BUG的重现概率
8.版本
需要添加当前测试的软件、硬件测试版本信息
9.优先级
优先级一般与严重程度相对应
1级：低优先级
2级：正常处理
3级：高度重视
4级：马上解决
10.如何发现
测试过程中分不同阶段，这些阶段主要分为需求检查、代码检查、上线遗漏、单元测试、集成测试、冒烟测试、系统测试、回归测试、验收测试、自由测试、客户反馈、其他。
resolved是什么状态11.解决
解决者：解决当前BUG的人员信息
解决日期：解决当前BUG的日期
解决方案：描述该问题出现的原因及解决方法，或其他描述信息
12.其他信息
处理状态：与BUG状态类似，可以以BUG状态作为唯一标识
13.BUG相关
相关BUG：开发人员发现有重复的BUG需要将之前已经提过的BUG ID号附在该位置
相关CASE：在执行测试用例的过程中发现BUG，并将该CASE ID附在该位置
14．附件
是粘贴必要的附件，如果可重复性是“可重现”的而复现步骤较复杂可以选择粘贴附件，如果较简单则没有必要。如果可重复性是“不可再现的，在能够抓到截图或log的情况下必须粘贴附件。
15.BUG复现步骤
[初始条件]
3G网络正常、开启WIFI（测试前提条件写清楚，提高BUG的复现概率）
[详细步骤]
手机出现触摸屏失效、冻屏、网络等问题，尽量回忆前5步操作
（测试步骤清晰、简单明了，抓住问题关键步骤，描述问题尽量避免使用错别字并且尽量使用专业用语）
[实际结果]
[期望结果]
[备注]
可以描述对比机测试情况或其他参考信息
新建一个BUG处于Open的状态，并且测试人员将BUG转到开发负责人或直接转到开发人员名下，开发人员根据实际情况将BUG可以置为Postponed、Duplicate、Rejected、Resolved
等并将BUG转到测试人员名下，然后测试人员对BUG进行验证，判断该BUG是Closed还是Reopen。