【缺陷管理】10：怎样有效的记录软件缺陷(Bug)？

bug从修复到解决的流程

       通常情况下，一个bug从发现到解决的流程应该是这几步：   

                                                                                                    

这其中，发现bug的环节不可控，因为我们不知道什么时候会有bug提出来，我们能做的就是发现bug后用最少的时间和人力成本来解决这个bug（都说技术人员的kpi不好衡量，如果做好了形成了团队的规范准则，应该也可以算一个绩效点，因为可以提高工作效率，至于权重多少，需要配合实际数据来分配）。复现bug环节，简单的问题很好复现，可能比较耗成本又最容易忽视的环节应该是复现bug了，至于定位bug，修复bug和测试环节，因为天生自带主角光环，更容易被重视。那么，有没有办法尽可能减少这个环节的时间和人力成本呢？

 

发现bug是测试人员必须具备的能力，不管在什么公司，测试人员在执行测试任务的时候，发现bug和提bug,以及跟踪Bug是必要的工作。如何提出高质量的bug,是体现测试人员水平的重要标志。从功能测试人员，到测试开发，高级测试开发等，都避免不了与bug打交道。可是现在也存在这么一种现象：测试人员提的bug质量不高，开发人员看不明白。于是就来找测试人员，来解释这个bug是怎么回事，如此来回折腾浪费工作时间，在跨部门协作的时候，这样的情况尤其严重。

 

 

 

测试人员提bug质量不高，主要表现在如下几个方面：

（1）bug表述不清，只有一句话，介绍bug是什么，然后没有其他的说明。

（2）不提bug,发现问题直接告诉开发人员，在工作交流平台上不断讨论bug。

(3)发现bug的场景没有保留，重现成本较高。

 

  针对上面的各种情况，我们测试人员要不断地提高相应的能力，提出高质量的bug。如何提出高质量的bug呢？

 

一，熟悉Bug管理工具

  每个公司不管规模大小，都应该有bug管理平台，如jira,禅道，teambition,或是公司自主研发的项目管理平台；只要我们通过相应的平台来管理项目，bug等，要想更好地提bug必须先全面了管理平台的功能。很难想象，如果你相应的管理平台都不会用，如何更好的辅助测试呢？

 

二，准确地给bug定级

  根据bug的影响，每个公司会定不同的bug分级标准。如p0,p1,p2,p3,或是致命，严重，一般，低级与建议,或者A,B,C,D。作为测试人员必须了解相应的分析标准，在发现bug后才能准确地给bug定位，从而影响bug的修改优先级。

 

三，准确记录bug信息

  要想准确地定位bug，从而快速地修复bug,相应的bug信息是必须的，同时发现bug必须通过公司的bug管理平台进行记录和跟踪。有的时候公司会通过bug管理平台来设定bug的模板，有的公司没有，但是不管有没有模板，我们需要记录以下信息：

【前置条件】

  XXXX

【测试步骤】

1，XXXX

2，XXXX

3，XXXX

【预期结果】

  XXX

【实际结果】

  XXXX

同时上传错误日志或是错误界面截图。准确设置相应的bug负责人，相关知情人，以及其他的必要信息。如果bug比较复杂，保留bug发现的现场，以供开发人员来进行排查。

 

四，实时跟踪Bug进展

  Bug提交后不是就和测试人员没有关系了，你需要实时跟踪bug的进展情况。根据bug的不同级别，关注开发人员修改的进度，相应的修改情况是否准确记录。同时要做到如下几点：

（1）根据测试安排和轮次，先将发现的bug进行记录，不能反复验证bug.

（2）不要相信开发人员，不管他说的修改的内容如何，影响范围如何，必须按自己先前的测试用例进行验证。

（3）如果上线的时候，原则上必须把bug修复完；如果没有修复完，对bug进行评审，级别高的必须修复，低级别的需要产品进行确认。

（4）大型项目结束后，必须对bug进行分析和汇总，分析问题出现的原因及避免方案。

 

在您以往的工作中，一个Bug记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

 

一条Bug记录最基本应包含：

 

bug编号

bug严重级别，优先级

bug产生的模块

bug摘要，阐述bug大体的内容

bug对应的版本

bug详细现象描述，包括一些截图、录像....等等

bug出现时的测试环境，产生的条件即对应操作步骤

 

高质量的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习惯，在测试工作的职业生涯中越走越宽。

 

祝福大家工作愉快!

写在最后
如果对python自动化测试、web自动化、接口自动化、移动端自动化、面试经验交流等等感兴趣的测试人，可以关注微信公众号：【程序员二黑】，获取软件测试工程师大厂面试资料！我的学习交流群： 785128166 群里有技术大牛一起交流分享~

如果文章对你有感兴趣，麻烦伸出发财小手点个赞，感谢您的支持，你的点赞是我持续更新的动力。