51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 1889|回复: 2

bug的一生:软件测试员,你是如何利用专业技术修复bug的?

[复制链接]

该用户从未签到

发表于 2019-2-2 11:16:22 | 显示全部楼层 |阅读模式
 bug像是一个被过分宠爱的小孩子,得到了特别多的关注。它们在开发者的IDE里悄然无声的诞生,但在现身之刻却引来一片喧闹“——bug的一生
  
  Bug的出生证明
  1945年9月9日,下午三点。哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。这还不是一个完全的电子计算机,它使用了大量的继电器,一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天,房间没有空调,所有窗户都敞开散热。
  突然,马克二型死机了。技术人员试了很多办法,最后定位到第70号继电器出错。哈珀观察这个出错的继电器,发现一只飞蛾躺在中间,已经被继电器打死。她小心地用摄子将蛾子夹出来,用透明胶布帖到“事件记录本”中,并注明“第一个发现虫子的实例。”
  从此以后,人们将计算机错误戏称为虫子(bug)
  软件测试中bug的生命周期
  对于测试人员来说,bug的生命周期一般分为:发现bug—>提交bug—>验证bug,那在这三个阶段中如何体现测试的专业度呢?
  第一阶段:发现bug
  1、充分利用80/20法则
  80/20法则,又称为,马特莱法则、二八定律、帕累托定律、最省力法则、不平衡原则、犹太法则。
  80/20法则揭示了80%的成果源自仅仅20%的行动,体现了投入与产出不平衡的“普遍真理”。
  一般情况下,80/20法则适用于以下软件测试情景:
  80%的软件缺陷存在于20%的软件代码中(软件缺陷的“群集”现象)
  80%的软件缺陷归因于20%的软件缺陷原因(软件缺陷的“群集”现象)
  在分析、设计、实现阶段的复审和测试工作只能够发现和避免80%的软件缺陷,而系统测试也只能找出其余Bug中的80%。
  2、跟开发人员有效沟通
  跟开发人员有效沟通,既可以沟通个人之间的友情,还可以获得开发相关的知识,更可以得到有益于软件测试的信息。
  3、从不同角度进行测试
  从管理层的角度考虑,我们要了解被测产品在公司众多产品中的优先级,做到软件测试的有效性,即确保软件缺陷的有效性。
  从开发人员的角度考虑,获知开发人员认为软件产品中那些模块开发难度大,缺乏信心,从而快速定位我们的测试重点。
  从最终客户的角度考虑,尽可能从他们的既有的使用习惯和可能的问题出发,也就是用户体验出发,找出尽可能多的软件缺陷。
  4、选择简易有效的测试工具
  比如,网页的链接测试,如果选择一些简单易用的链接测试工具,既能提高覆盖率,又能发现较多的软件缺陷。
  5、进行专项测试
  比如,安装测试,卸载测试,双(多)字节测试,查询测试,上传附件测试,快捷键测试,UI整体风格测试(包括按钮、成功信息、警告信息)等等。
  6、参照单元测试结果
  可以帮我们定位软件测试重点,做到花费较少的时间,找出较多的软件缺陷。
  7、参照其他测试人员报告的软件缺陷
  每个人的思维都是有局限性的,我们可以参照其他测试人员报告的软件缺陷,获取新的测试思路,从而发现以前未曾发现的软件缺陷。
  8、错误推测法
  对于有一定软件测试经验的人来说,是一个短时间内发现较多软件缺陷见效较快的方法,体现了经验的价值。
  第二阶段:提交bug
  1. 确保bug有效。
  提交的Bug必须是有效的,就要求我们在提交Bug时,确认: ①交付过程中测试者需按照设定好的模块,对Bug进行归类提交; ②Bug的类型默认为UI问题、功能问题、崩溃问题,提交Bug时不能弄错; ③需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、Bug是否唯一性; ④避免提交设计如此、操作错误、重复的、已知的Bug; ⑤尽量少花时间在边界值、页面显示问题上,多提业务逻辑功能、交互测试方面的问题。
  2. 写好bug描述。
  1)bug描述精确、没有歧义,详细简洁的测试步骤。
  2)保证各个字段内容与实际现象一致。比如:版本、复现率等
  3)对于复现率低的问题,尽可能提供一些可参考信息:截图、视频、日志、可能的步骤、可能原因等(如果你能通过各种手段定位到问题的原因,开发大神也会对你刮目相看的)
  4)对于特殊的测试场景,附带相关的数据,比如1024kb的图片等
  第三阶段:验证bug
  1. 确认好bug的复现前提及操作步骤。
  2. 确认bug产生的原因及修复方法。
  1) 明确bug产生的原因,触类旁通,分析其他模块可能存在的问题
  2 ) 通过bug产生的原因,积累测试经验,扩展测试思路
  3) 通过bug的修改方法,分析修改是否能修复问题?是否回引发其他问题?
  4) 积累bug经验,在后续相关问题发现时,快速定位问题,提供解决思路
  3. 确认bug的回归范围及用例。
  在了解清楚bug产生的原因及修复方法基础上,再根据业务关联、功能模块关联确认回归范围,确保bug修复全面且没有引起新的bug。
  总结:
  bug千奇百怪,不是每个bug都需要经历所有流程的。每个步骤都有它的难点。 有些bug难在事发点的定位,比如多线程,异步逻辑中的bug; 有些bug难在原因很难分析,多数是你看不懂代码; 有些bug难在你不敢改,那是你的修改方案没有做好充分的分析。
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-3-29 06:44 , Processed in 0.064977 second(s), 23 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表