内容简介:bug像是一个被过分宠爱的小孩子,得到了特别多的关注。它们在开发者的IDE里悄然无声的诞生,但在现身之刻却引来一片喧闹“——bug的一生Bug的出生证明1945年9月9日,下午三点。哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。这还不是一个完全的电子计算机,它使用了大量的继电器,一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天,房间没有空调,所有窗户都敞开散热。
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难在你不敢改,那是你的修改方案没有做好充分的分析。
欢迎加入 51软件测试大家庭,在这里你将获得【最新行业资讯】,【免费测试 工具 安装包】,【软件测试技术干货】,【面试求职技巧】... 51与你共同学习,一起成长!期待你的加入: QQ 群: 755431660
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- itest(爱测试) 紧急 BUG 修复版 4.5.6发布,BUG 跟踪管理 & 敏捷测试管理软件
- Web测试入门——软件测试员必知的50个常见测试点
- 测试人必须了解的软件测试流程及5大测试过程模型,经典干货分享!
- 软件测试中服务器稳定性测试方法
- 软件测试相关知识总结
- 我对软件测试的感悟
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Stylin' with CSS
Wyke-Smith, Charles / 2012-10 / $ 50.84
In this completely revised edition of his bestselling Stylin' with CSS, veteran designer and programmer Charles Wyke-Smith guides you through a comprehensive overview of designing Web pages with CSS, ......一起来看看 《Stylin' with CSS》 这本书的介绍吧!