ITPub博客

首页 > 自动化运维 > 大规模网络运维 > bug的一生:软件测试员,你是如何利用专业技术修复bug的?

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

原创 大规模网络运维 作者:博为峰网校 时间:2019-01-16 17:27:51 0 删除 编辑

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


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31407649/viewspace-2563617/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2016-11-02

  • 博文量
    123
  • 访问量
    51447