1，BUG全部提交到http://XXX.XXX.XXX.XXXBUG论坛上
2，创建的问题的时候，“概要”--用简单明了的语句说明白你这个BUG，就相当与BUG的中心语句
3，BUG优先级分为4种情况
致命问题：系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全
严重问题： 系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响
一般问题： 系统的次要功能没有完全实现，但不影响用户的正常使用。
建议性问题：不影响功能的、有关易用性的、文字、操作可以提出一些建议的问题
4，然后选择你提交的BUG所以那个模块,并选择提交问题时测试程序的影响版本
5，选择这个BUG所属模块是属于那个开发人员 ，并把问题指派给他
6，环境：填写你当时出这个BUG的现场环境，如：操作系统是winxp,测试的终截者是那天的版本等（这个根据实况进行填写，可写也可不写）
7，另外可以通过上传截图或附件，可以进行简单明了的说明BUG存在，也可做为BUG证据
8，最重要的在填写描述: 最好是把BUG产生的步骤一步一步写清楚，可以用以下方法写（如果一句话就可以说明的BUG，就不必要分步骤了）
1，。。。
2，。。。
3，。。。
4，。。。
写清楚，然后写出测试出的结果和你期望的结果，如：
测试结果：。。。。。
期望结果：。。。。。
9，BUG验证/关闭问题说明：
当BUG由open变为FIXed，你就应该进行回归测试，如果回归测试后该问题被解决，则你就closed该BUG，并在注释中填写如下信息：
验证通过：是
验证日期：。。。
验证版本：。。。
如果回归测试验证不通过，则Reopend该BUG，并在注释中填写你验证的版本
10，关于研发人员解决问题
研发人员解决BUG写的注释一定要有以下几点：
1，说清楚BUG产生的原因
2，写出BUG产生的文件
3，修改后该文件的版本号
如果研发解决问题的注释上只写“已解决”这样的话，就一定要叫他们加上上面的信息
可能这个要根据不同的公司进行修改，我们分配问题就是直接分给相关开发人员，而不用通过经理再去分配任务。
Bug提交规范及注意事项：
一、BUG提交规范
目前所使用的JIRA系统中，BUG的内容主要包括以下要素：
| 缺陷ID |
BUG的唯一标示，由JIRA自动生成。 |
| 项目名称 |
每个要测试的软件项目都有唯一的名称。 |
| 问题类型 |
选择是BUG还是新功能，子任务等。 |
| 主题 |
简明的对BUG进行概要描述。 |
| 严重程度 |
BUG的严重程度 |
| 优先级（缺少） |
BUG解决的优先级 |
| 到期日 |
BUG需要处理的截止日期 |
| 模块 |
BUG所属的组织模块 |
| 影响版本 |
产生BUG的版本号 |
| 解决版本 |
解决BUG的版本号 |
| 经办人 |
需要指派处理的人员，如不清楚统一给项目负责人 |
| 报告人 |
报告BUG的人员 |
| 环境 |
描述当前测试的软硬件环境 |
| 描述 |
在详细描述中，可对BUG产生的前提条件、操作步骤、实际结果、预期结果等进行描述 |
| 附件 |
提交BUG时，可上传必要的附件。（截图，日志等） |
| 备注 |
其他需要注意的地方； |
具体提交规范如下：
1. 现象描述
详细描述BUG的现象；
2. 测试环境
说明发现BUG的测试环境；
3. 前提条件
详细描述BUG产生的前提条件。例如浏览器，操作系统，移动设备组件版本，软件版本等；
4. 操作步骤
详细描述发现BUG的操作步骤；
5. 期望结果
描述预期正确的结果；
6. 实际结果
描述实际不正确的结果；
7. BUG严重性等级
初步判定BUG的严重性等级；
8. BUG优先级
判定BUG被修复的优先级别；
9. 附件
包括：BUG现象截图、操作产生的系统日志等；
注：严重等级以上BUG必须带有附件，一般性BUG则附件可选。
10. 备注
BUG补充说明信息，如：测试分析意见、其它设备有无类似情况等；
附BUG提交范例：
【前提条件】
操作系统：Win7
浏览器：IE10，Firefox 47.0.1
【操作步骤】
1. 首页，点击“我要注册”；
2. 打开注册页面，输入未注册过的手机号和密码
3. 点击 注册按钮；
【实际结果】
注册不成功，停留在当前页面
【预期结果】
注册成功，跳转至首页
二、BUG提交注意事项
1. 测试人员提交新缺陷时，尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、（建议），并尽量截图；
2. 当你的BUG报告以“不可重现”打回给你时，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语，再检查是否有遗漏或清晰的步骤，再去找研发人员。
3. 测试人员在精简空话的同时，应该再仔细检查报告是否会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的，不会产生争执的词语；
4. 不要使用感叹号或其它表现个人感情色彩的词语或符号；
5. 不要使用含糊的词语（例如，好像，似乎）或网络语言来描述发现的现象；
三、Bug的类型
1. 文档缺陷：术语不一致，文档缺失，不易理解等；
2. 设计缺陷：需求不明确，操作便捷性等；
3. 配置缺陷：安装部署不成功，配置文件错误等；
4. UI 缺陷：风格不一致，界面不友好等；
5. 数据校验：数据长度，类型缺失校验；
6. 查询统计：查询结果列表异常等；
7. 功能缺陷：功能不可用；
8. 可靠性 ：用户权限错误等；
9. 性能缺陷：查询性能，并发处理等；
10. 流程缺陷：流程不能流转，流程错误结束等；
11. 语言质量：字符未本地化，标点符号，商标符号错误；
12. 用户互动：与使用者互动不良；
四、Bug的等级划分
BUG等级是根据BUG出现在系统中的严重程度来分的。主要定义如下5级：
1. 致命BUG，包括以下各种错误：
1.1 由于程序所引起的死机,非法退出
1.2 死循环
1.3 导致数据库发生死锁
1.4 因错误操作导致的程序中断
1.5 严重的数值计算错误
2.严重BUG，包括以下各种错误：
2.1 功能不符
2.2 数据流错误
2.3 程序接口错误
2.4 轻微的数值计算错误
3.重要BUG，包括以下各种错误：
3.1 操作界面错误
3.2 打印内容、格式错误
3.3 简单的输入限制未放在前台进行控制
3.4 删除操作未给出提示
4.轻微BUG，包括以下各种错误：
4.1 界面不规范
4.2 辅助说明描述不清楚
4.3 显示格式不规范
4.4 长时间操作未给用户进度提示
4.5 提示窗口文字未采用行业术语
4.6 可输入区域和只读区域没有明显的区分标志
4.7 系统处理未优化
5.微小BUG：
5.1 界面重构、描述更改、流程改进
五、 Bug优先级划分
危机：要求立即修改，作为修改最高等级；
紧急：要求重点修改，产品发布前必须修复；
中等：需要尽快进行修改，产品发布前必须修复；
尽快：需要修改，如果时间允许应该修改；
不急：可能要修复，时间空余情况下进行修改。
六、其他注意事项
当发现一个BUG时，请注意下面的问题：
1. 同一软件中的相似功能是否有相同的问题？
2. 其他的浏览器是否有相同的问题？
3. 其他的软硬件配置是否有相同的问题？
4. 其他的区域是否有相同的问题？
5. 以前的版本是否有相同的问题？
