? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
一、摘要
? ? ? ?
二、名词解释 三、目的 四、范围
五、Bug编写规范
o o o o o
1. 主题 2. 描述 3. 环境 4. 截图 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分类”
Bug来源 代码逻辑错误 未理解需求/需求遗漏实现 来源解释 代码逻辑错误导致对的Bug 因未理解需求导致功能实现错误
JIRA的BUG编写规范
