如何提交一个好的bug？提交时需要关注那些要素 ？这里给出你答案

bug是测试人员和开发人员沟通的'中间件' ，作为修改者来说 ，当然希望看到的bug能通俗易懂 ，降低他对bug的理解难度 。但是就是这么一个基础的工作，你也会偶然听到开发人员的反馈，诉说测试人员在提交bug的随意性，完全无法让人理解 。当然究其原因也不难理解，就是在bug标题上描述的太过混乱 。

那么 ，如何使得我们提交的bug能更具有可读性呢 ？ 在这里我们先简单的回顾下bug所包含的要素有什么 ？

1.bug包含的要素

以上截图是描述一个bug所包含的主要字段 ，其中红色字体是比较重要的字段 ，但是对于开发人员来说他关注的字段可能就那么几个 ：

• bug标题

• bug的严重程序

• 复现步骤或者附件 。

  其中bug严重程度 ，决定bug被修改的前后次序 ；而bug标题和复现步骤(或附件) 决定着开发在bug理解上所用的时间 ，虽然这个时间一般都用不了多长时间，但是编写一个槽糕的bug会让开发人员的心情很烦 ，可能导致开始出现的那种情况 。

  你也可以这样理解，若一个bug标题足以让开发理解了此bug的含义，那么他就没必要再看复现步骤或其它字段了 。而且，能在2s理解的bug含义就比5s理解要更好 。所以 ，所以如何写好一个bug的本质就是如何缩短开发人员对bug的理解时间

  2.bug标题怎么写 ？

  首先，减少开发人员对bug描述的一个关键要素就是要让其快速定位到模块 ，也就是这个bug出现在那个模块 。最好能让它做到一眼就知道在那个模块 。所以，解决这个问题的关键就是在bug描述的开头加上模块 ，已让其更加醒目。

  其次 ，在描述bug时最好先去描述它的操作步骤 ，也就是进行了怎样的操作 ，描述的语言尽量要符合准确，正确和简洁的标准 。

  最后 ，就是写出它的预期结果是什么 ，好让开发知道它是和实际结果不一致的 。

  综上描述 ，我们就可以将其总结为一个公式，具体如下 ：
  

   

  下面我们来个例子 ，比如下面这个bug 。

   最终提交到缺陷系统上就应该是如下这样的 。

  其它的案例 ：  

  3.建议加上附件

  为什么说加上附件呢 ？ 因为有的bug不好复现 ，这时录一个小视频是最好的 ，然后上传到bug中 。有助于快速定位bug。但是大多数bug按照固定步骤都能复现 ，这时其实配合一张图片就可以了 。当然上传图片也是有讲究的 ，

  首先 ，图片要进行复制粘贴到“复现步骤”区域内 ，这样做的好处就是一打开bug就能看到截图 。

  其次 ，上传的图片要在关键位置加以说明，用它来辅助bug标题的描述 ，也就是通过它能快的理解bug . 比如上图的导出 ，就是在导出功能和数据展示的地方用红框框住 ，这样有助于快速定位位置。 所谓的一图胜千言就是这个道理 。

  4.总结

  • 对于难以复现的bug来说 ，1标题 + 1视频来说明足以 。

  • 对于常规bug来说 ，1标题 + 1图片来进行描述即可 。