测试人员应该如何报bug?

上一篇 / 下一篇  2021-09-22 15:04:34 / 个人分类:测试

       首先,确保你所发现的问题是确实是一个bug,不要出现因为测试人员操作错误或配置错误所引起的“bug”,这样会降低你在开发人员心中的可信度。在测试的时候,如果发现测试的实际结果与预期测试结果不符时,不要着急马上报bug,先想想为什么会出现错误。作为专业的测试人员,应该能够对出现的问题进行跟踪,确认了在配置、操作没有错误的前提下,通过追踪分析确认所测试的业务流程确实是存在bug,并能大概对bug的产生原因进行定位。测试人员,需要做到专业,尽量少给开发找麻烦,不要制造实际上并不存在的bug。
       确认了所发现的问题是一个bug之后,按照测试步骤再执行一次,确保bug是可重现的而不是随机的。如果bug不能重现,应该尽量找到bug重现的规律,在一些比较难重现的问题可以找开发配合一起查找原因,如果还是无法重现则需要在bugreport中对出现的问题描述清楚并说明出现的随机性。
       接下来就是填写bugreport了,在填写bugreport的时候,最重要的是bug的标题和bug描述。在bug报告中,首先用一句话对bug进行简要精确的描述作为bug的标题,让开发或项目经理一看就知道存在什么问题,比如“XX模块在压力测试2小时后出现内存泄露”。而在bug的描述中,需要使用简明准确的语言描写出现bug的测试步骤、实际的测试结果、预期的测试结果和结论,也就是说描述导致出现bug的操作步骤是怎样,由测试步骤所做的操作引起的测试结果是什么,而预期的结果应该是怎样,并由实际结果与预期结果相对比说明问题所在。比如:“在管理网页新增用户,当新增的用户登录名名称很长(例如登录名长度为输入框允许的最大长度),按‘新增’按纽新增后系统提示已经有该用户存在,而事实上该用户并不存在,建议对超长的用户名进行处理。”
       在测试人员发现了一个已隔离的,可重现的问题后,应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的流程?同一个故障是否会引起更加严重的问题?如果存在,也需要提出来让开发一并处理。
       在开发对bug进行修改之后,测试需要报着怀疑的态度认真地对问题进行验证,需要严格按照测试步骤来进行测试,检查开发是否已经正确修改了所出现的问题,以及开发对bug进行了修复之后是否会引进新的问题。不要相信开发说“已经修改好了,肯定没问题了”就不对问题进行细致的检查了,如果开发修改得不彻底,问题仍然会存在的,或者可能会由于开发在修改bug的时候忽略了另一些细节导致了新bug的出现。尽量不要在关闭bug之后,才发现这个问题还没有修改彻底;也不要出现bug关闭之后,出现了新的bug。
       测试对bug进行验证确认已经修改ok之后,关闭bug。在关闭的时候,应该对Bug最终修改结果进行简要描述,如果bug的修改引起配置或数据库或业务流程的变更,也需要在bug关闭描述中进行说明。

TAG:

a13023060672的个人空间 引用 删除 a13023060672   /   2021-10-22 15:05:54
5
引用 删除 13535192299   /   2021-09-28 08:53:35
5
 

评分:0

我来说两句

日历

« 2021-10-22  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 9351
  • 日志数: 72
  • 建立时间: 2021-06-21
  • 更新时间: 2021-10-22

RSS订阅

Open Toolbar