怎样有效记录缺陷（Bug）？

怎样有效记录缺陷（Bug）？

01 有效的记录，提交高质量Bug

我们发现这个缺陷之后，如何进行有效的记录？如何提交高质量的Bug

 至少让开发看到这个Bug的时候，他知道怎么样去进行复现。然后他不会第二次第三次第四次来问你，呃，你这个是怎么操作的，你这个是怎么复现的？你这个准备数据是什么？

如果说你提了一个Bug之后，一个开发不断的来跟你沟通，你的操作是什么样子的，你有什么前提条件，你要准备什么样的数据、环境。

有这些问题就表示你的Bug提交得不到位。这个肯定会影响开发修改的效率，在这中间他怀疑你提交的Bug不好，你怀疑他的理解能力不够，一来一回就很容易起冲突！

怎样有效记录缺陷，在这里我给大家总结了五个点。

第一个我们要保证这个缺陷是可以重现的，我们常见的Bug我们可以把它分为两大类，

• 第一类：是可以复现的Bug
• 第二类：是偶现的Bug，就是说低概率出现的Bug。

 

对于第一类可以复现的Bug，比较简单，比如我在我的界面打开一个文件夹，然后进到某一个路径，然后我某一个Excel表格打不开，那么这就是一个Bug，在这里不管我是在我的环境底下还是在开发的环境底下，都存在这个问题。

对于第二类的问题，比如说我打开某一个文件夹，进到某一个路径之后，有时候进来表格打不开，有时候又可以打开，对于这种出现的概率比较的低，是不稳定的，对于这一类我们就把它叫做偶现的问题。

对于这两类问题我们做为软件测试工程师应该怎么样去处理？

首先第一个点，对于偶现的bug也好还是可以复现的Bug也好，咱们都要提交，只要是一个Bug都要进行提交。

只是在提交的时候呢，咱们偶现的Bug你要多提交一些东西，因为对于偶现的bug，开发那边不一定能够复现，开发不修改的几率就大了。

第一个写清楚当时的环境，第二个提供更多的帮助，让开发来复现这个问题

去录一些视频，抓一些日志，你提供的这一些东西，都是能够帮助开发提高修改这个Bug的概率的。

我一个人在测试的时候，这个问题可能就是十分之一的概率，那么如果说是一百万个人来进行同样的操作，那么它可能会出现的概率就大大提高了。

既然它会出现，它就肯定会有一个稳定的路径，只是目前我还没有发现，所以说对于偶现的Bug我们千万不能去忽视。反而要去重视。

 

第二一个的话呢，我们要去记录这个缺陷的时候，就要把重现这个Bug的步骤写出来，写步骤的时候既不要太啰嗦，也不要太简略。

第四一个，每一份报告中只记录一个缺陷，前面我们提到的我打开一个文档，里面的一个表格打不开，这是一个Bug，

如果说我们在同一个路径还发现了另外一个Bug比如文件显示不全，同样的路径同样的操作我发现了两个Bug，那么我们就需要分两个Bug作为提交。

最后一个点就是我们在描述的时候，只要做到陈述事实就可以了，不要去做主观臆断。不要加上的主观的一些情绪，或者说你自己的一些语气助词等等之类。

 

02高质量的Bug记录

 1) 通用UI要统一、准确

缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。

 2) 尽量使用业界惯用的表达术语和表达方法

使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

 3) 每条缺陷报告只包括一个缺陷

每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。

 4) 不可重现的缺陷也要报告

首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。

 5) 明确指明缺陷类型

根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。

6) 明确指明缺陷严重等级和优先等级

时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。

 7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置

描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

 8) 短行之间使用自动数字序号，使用相同的字体、字号、行间距

短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。

 9) 每一个步骤尽量只记录一个操作

保证简洁、条理井然，容易重复操作步骤。

 10) 确认步骤完整，准确，简短

保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。

 11) 根据缺陷，可选择是否进行图象捕捉

为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。

 12) 检查拼写和语法缺陷

在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。

 13) 尽量使用短语和短句，避免复杂句型句式

 软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。

 14) 缺陷描述内容

 缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。

 

简单来说一个好的描述需要使用简单、准确、专业的语言来抓住缺陷的本质，否则，它会使信息含糊不清,在开发中测试人员向开发人员提出BUG,应尽可能的描述当时操作的明细,提供精准的测试要素有助于开发人员快速定位BUG位置。如下总结几点开发中测试的经验：

 1.操作流程,如第一步做了什么.等等

 2.测试使用的浏览器类型和版本

 3.测试的URL地址

 4.测试使用的账号，密码

 5.错误提示消息.

 6.错误发生的时间

 7.附上抓图说明

 精准的信息沟通方式非常重要。

 沟通方式准确无误能使开发人员免去猜测。事半工倍.

 以下几种工具可以考虑：Foxmail、禅道、QQ、Jira

 适当配合会议和面对面沟通。能使我们的工作效率更高。

 

总结，根据我的工作经验，测试人员如果要提高质量的bug,必须做好上面的各项步骤。高质量的bug,不仅有助于开发快速定位和修复问题，同时也体现了你的能力，容易得到开发人员和团队的认可。所以我们首先要不断地提高自己的测试技术，养成良好的提bug习惯，在测试工作的职业生涯中越走越宽。

 

转摘为：https://mp.weixin.qq.com/s/Bys8tcJLJ8RWldBGe_5EhQ