∙一、摘要
∙二、名词解释
∙三、目的
∙四、范围
∙五、Bug编写规范
o 1. 主题
o 2. 描述
o 3. 环境
o 4. 截图
o 5. 其他
∙六、注意事项
一、摘要
本文档主要描述了技术产品部测试人员提交Bug时需要遵守的规范。

二、名词解释
∙JIRA JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

三、目的
规范Bug编写，一方面，可以方便开发人员根据Bug描述快速进行定位问题原因，减少沟通成本，另一方面，可以帮助测试经理、非技术人员、产品经理、开发经理及其他测试人员等了解Bug，第三，可以体现测试团队的专业性、严谨性。

四、范围
该文档适合技术产品部测试人员使用，适合于任何产品和项目。

五、Bug编写规范
1. 主题
为了节约开发阅读Bug时间，同时考虑到开发人员容易通过Bug标题来猜想Bug，所以，Bug标题显得尤为重要。

以下为Bug标题编写时需要遵守的规范。

1）用简短的语句描述问题，主题文字过多，增加开发阅读Bug时间。

2）格式：在什么位置，在什么条件下，做什么操作，操作的结果。

∙在什么位置：问题所在的路径，格式为“XX-页面：”
∙在什么条件下：如果问题为兼容性Bug，比如浏览器兼容或者分辨率兼容。

格式为“在IE11浏览器下，”，如果Bug不属于兼容性问题，不用加此描述。

∙做什么操作：问题触发的动作，比如：“执行审批通过”。

∙操作的结果：即问题的表象，比如：字段“报送时间”取值不对、报404错误。

格式举例：采购中心-招标计划详情：在IE11浏览器下，展开“查看参与人员”，内容错乱。

3）除了第二点描述的格式，对于Bug描述，除了描述实际的结果外，有时候我们会直接描述期望结果，比如，集采销售-招标计划列表：列表字段“填报时间”应该修改为“报送时间”。

4）描述无歧义。

Bug描述如果有歧义，开发容易因为改错Bug，导致增加Bug修复成本。

5）涉及界面UI的文字，用双引号标注，比如：集采销售-招标计划列表：列表字段“报送时间”取值错误。

2. 描述
描述是对Bug标题的详细补充，对于复杂Bug，标题不足以帮助开发定位问题，需要详细步骤来支撑。

1）对于标题就能描述清楚的Bug，描述可以与标题完全一致。

2）对于标题不能描述清楚的Bug，描述一般格式如下：
1.【重现步骤】
2.【实际结果】
3.【期望结果】
在实际编写过程，可以省略某一部分，比如标题清晰表达了问题现象，此时再“【期望结果】”就能清晰表达问题。

3）对于需要复杂数据准备的Bug，在描述里备注账号格式为：账号/密码，比如，lotus009@qq.coom
3. 环境
环境为产生Bug时，用户使用的浏览器、操作系统、分辨率、账号等，主要用于辅助开发排查问题。

1）URL：Bug产生的页面URL，方面开发快速找到修改代码的地方。

2）浏览器、操作系统、分辨率：如果是兼容性问题，需要在此注明产生问题的环境。

4. 截图
一份好的截图，可以方便开发人员快速确认错误的表现形式和错误的位置。

1）截图工具统一使用：FSCapture.exe。

2）不要仅仅截图，需要在图上标注出有问题的地方，并文字进行辅助说明。

3）如果问题为500、404等错误，需要附上日志截图，方便开发定位代码行。

4）如果Bug为与需求不符Bug，截图需要同时包括需求与系统实现，减少开发查阅需求的时间。

5）如果Bug为读取数据错误，截图需要同时包括数据库的存储结果及系统数据的展示的对比图。

5. 其他
1）正确选择“Bug分类”
2）正确选择Bug的优先级
3）正确选择Bug所属模块Bug模块主要是用于Bug分析和输出测试报告时，做模块Bug统计。

六、注意事项
1.
一个Bug只能包括一个错误同一个Bug里包括多个问题，开发修改Bug的时候，容易遗漏，导致Bug被多次Reopen。

2.
3.
所有Bug统一记录在JIRA中，测试人员在测试过程中发现的或非测试人员本身发现的Bug，无特殊情况，不能用其他工具记录，同时不允许以口头方式直接告知开发人员，统一记录在JIRA中以便统一管理，一方面，有利于项目资产的建立及项目过程问题的分析，另一方面，避免造成记录丢失或遗忘。

4.
5.
避免重复提交Bug，Bug的重复提交会增加测试人员的工作量，同时也可能增加开发人员的心理压力，所以在多人测试的时候，一方面，避免多人同时测试同一个功能点，另一方面，提Bug之前，先确认Bug库中是否已经存在，第三，发现问题的时候，可以告知主负责该模块的测试人员，由他来提交Bug。

6.
7.
对于无效Bug，目前测试人员有删除Bug的权限，建议通过删除来处理无效的Bug，以免影响Bug的统计。

8.。