怎样才能提交一个让开发人员拍手叫好的bug单

怎样才能提交一个让开发人员拍手叫好的bug单

软件测试人员写得最多的文档就是测试用例和BUG，现在测试用例和BUG都没有标准的模板，每个公司使用的缺陷管理工具都有可能不一样，如果你换了一家公司就有可能接触到新的缺陷管理工具，但提交bug的方式却是大同小异，今天这篇文章主要讲解怎样才能提交一个高质量的BUG单。

目录

为什么要提交BUG单

缺陷管理工具

编写高质量的BUG单

---

为什么要提交BUG单

其实要提交BUG单的原因很简单，就是在测试过程中程序中出错了，那么测试人员就要提交BUG单，以便开发人员能够早时修改。

为什么一定要提交BUG单?直接跟开发面对面交流或者通过即时通讯传递了不就可以么？答案肯定是不行。

王豆豆总结了几点：

1. 提交清楚明了的bug单，有利于开发人员快速分析和定位bug
2. 在缺陷管理工具上提交bug单，有利于研发人员对bug的跟踪和管理
3. 在测试活动结束后，可以通过分析bug的级别、每天提交bug的数量、每天修改bug的数量、每个功能模块的bug数量等等因素，从而达到评估软件质量

缺陷管理工具

以下是目前企业中比较流行的缺陷管理工具：

王豆豆目前的公司用的是腾讯的Tapd，以前没用过，现在用起来觉得和其他的缺陷管理工具一样，并不会出现难以上手的情况。

编写高质量的BUG单

今天这个bug就是今日头条的发文模块的bug，前几天在发文章的过程中发现的，估计这是一个概率性的bug，今天发文的时候重试好几次也没有发现。

01

缺陷管理工具

今天给大家演示在Tapd上如何提交高质量的bug

02

什么是高质量的bug

王豆豆以为如果抛开提交的bug单是否是一个真正的缺陷，一个高质量的bug就是取决于这个bug是否能被研发团队其他人看懂并且能准确复现出来。毕竟提交的bug并不是给测试人员自己看的，而是给开发人员和团队其他成员看的。

有些公司bug修改完成后，并不是提交人回归，有可能是组内其他成员，如果写得不清不楚会给大家带来麻烦，需要更多的时间去检查和重试。

故，一个高质量的bug是多么重要，一个高质量的bug应该具备标题清楚合适、操作步骤条理清晰明了、结果明确，同时有相应的截图和日志。

03

缺陷的模板

软件测试人员在测试新版本提交bug之前，会在缺陷管理工具中去创建一个本次迭代的模板，将一些公共点包含进去，避免测试人员在提交缺陷时进行重复地输入、减少测试人员提交缺陷的时间、并能统一缺陷的格式。

缺陷的模板如下：

04

提交BUG

只要写好一个bug最重要的几个要素，那这个bug质量应该不会差的。

首先是缺陷标题，对缺陷标题的要求很简单---》看到缺陷标题就知道这个bug单是提的什么bug。

王豆豆喜欢写bug标题使用bug的实际结果，例如：【IOS】12位的手机号成功注册为会员 ；【XXXX结算】发起换卡API，报错银行卡号不存在。。。。等等

【今日头条发文模块】发布文章时添加内部链接，输入正确的标题和链接，点击确定提示请选择插入文章

第二点应该是重现步骤，重现步骤清楚可以极大地提高bug重现的机率，如果开发人员能自己一次性就复现出来，那就可以避免与开发人员进行多方的沟通和复现操作。

前置条件: 1.今日头条发文功能正常 2.添加的文章在今日头条存在 重现步骤描述： 1.在发表文章界面-》文章编辑栏-》点击文章链接 2.点击“选择文章” 3.输入不存在的已发表文章标题关键词，点击搜索，查询结果为空 4.点击“内部链接” 5.输入已存在的链接文字和链接地址 6.点击确定 重现频率： 50% 实际结果： 1.弹出提示界面，显示“请选择插入的文章” 期望结果： 1.在文章中添加内部链接成功

bug编辑中的截图：

一个bug中最好是能附上相应的截图和日志，特别是截图，清晰和正确的截图能使开发更快速地重现bug，而且开发人员会更喜欢，这是因为人更喜欢看图片而非文字，图片显示更加直观。

如果有日志更好，一般不管是测试前端界面还是没有界面的后台，只要进行了操作都会打印出日志，那么报错时就更有（这个可以通过操作日志级别来控制），如果日志比较少，可以用截图的方式来显示，如果日志比较多，那就最好以附件的方式上传上去，附上相应的日志能更方便开发人员快速定位bug和解决bug，所以日志也是必不可少的元素。

但是如果是界面上的错误，一眼就能看出是错误是什么和如何解决，可以省略日志。

05

其他元素

（1）关联需求

Tapd可以关联需求，这是指bug是出自哪一个需求，可以关联也可以不关联，有些工具没有这栏选择，所以我们忽略它吧。

（2）预计开始和预计结束

这二个选项级别也不是很重要，可以不填。

（3）当前处理人

这个选项是必填项，可以指派给这个bug下一个处理人，可以指定多个处理人，王豆豆现在一般是指派给对应的开发人员。

有些工具这里可以不用选择，可以根据工具的bug处理流程，自动指定给下一个处理人，如果是自动指定一般是测试经理。

（4）模块

选择此bug出自哪个模块

（5）优先级

根据bug的级别选择优先级。

bug的优先级有紧急、高、中、低，根据bug的优先级可以确定bug修复的优先级。

（6）严重程序

选择bug的等级

bug等级有致命、严重、一般、提示、建议，bug等级指定此bug的重要性，与bug的优先级共同确定bug修复的顺序。

（7）发现版本

这个一般是确定在模板中，指明此bug出自哪一个版本，有利于后期的回归和bug review。

写到这里就可以点击提交，将bug提交给下一个处理人，那这个bug开始它的一生了（bug的生命周期），直到再次回归到测试人员的手里被关闭。

这是王豆豆实际提交的bug，已被修复关闭了，已经隐去了敏感信息。