Chinaunix首页 | 论坛 | 博客
  • 博客访问: 668892
  • 博文数量: 134
  • 博客积分: 3158
  • 博客等级: 中校
  • 技术积分: 1617
  • 用 户 组: 普通用户
  • 注册时间: 2008-03-30 22:36
文章分类

全部博文(134)

文章存档

2012年(2)

2011年(28)

2010年(68)

2009年(35)

2008年(1)

我的朋友

分类: 嵌入式

2010-12-16 14:25:10

测试人员应该如何报bug【转】

 

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