软件测试之如何重现难以重现的bug
生活中有这么一种现象：如果你关注某些东西，它就会经常出现在你眼前，例如一个不出名的歌手的名字，一种动物的卡通形象，某个非常专业的术语，等等等等。这种现象也叫做“孕妇效应”。还有类似的一种效应叫做“视网膜效应”，它讲的是：你有什么东西或者特质你就特别容易在别处发现你有的这类东西和特质。干了多年测试的我就会经常发现日常使用的系统中有很多的bug，而我老婆就发现不了。今天要说的事儿是“重现难以重现的bug”，这件事儿在本周共遇见了4次：第一次是微博上有一篇《程序员，你调试过的最难的 Bug 是?》(后面会附上);第二次是一个同事跟我抱怨，好几个bug难以重现特心烦，并问我怎么处理比较好;第三次是本周上线的产品出现了一个当时难以重现的bug，我们对它做了初步的分析;第四次是翻看史亮写的书《软件测试实战》，偶尔翻了翻，竟然看到一小节在写“处理难以处理的缺陷”。这时候，脑子里很多东西汇集到了一起，我想还是记录一下吧。下面是正文：
也许测试人员(尤其是对新手来说)在工作过程中最不愿遇到的一件事情就是：在测试过程中发现了一个问题，觉得是bug，再试的时候又正常了。碰到这样的事情，职业素养和测试人员长期养成的死磕的习性会让她们觉得不能放过这个bug，但是重现这样的bug有时候需要花费大量的时间，有的时候还有一些盲目性(因为黑盒测试的缘故，很多内部状态是不可见的，因此无法获取有效的信息来做跟踪)，效率较为低下。在实际工作中，时间和进度摆在那里，在经历了多次痛苦的失败尝试之后，测试人员的处理方法一般会有如下几种：1.向开发人员寻求帮助来重现bug;2.当做一个issue报给开发人员。可是这样的做法存在如下问题：
1.开发人员责任心不够强，不愿意花太多精力去求证这件事情，常见的回复就是：在我这儿没事儿啊，我也重现不了，bug关了吧。结果随后在生产系统上，bug又开始sui随机出现了。
2.就跟测试人员不擅长编码和调试一样，开发人员并不擅长找出bug。经过一番尝试以后，他们也找不出什么问题来，常见的回复同第一条是一样的。bug上线后又出现的宿命也是一样的。
这时候，真正的问题来了：如何捕捉难以重现的bug?这件事儿对于测试人员来说就这么难么?
答案并不那么乐观，重现“难以”重现的bug本来就是一件“难以”完成的事情。但“难以”并不是不可能，通过一系列的测试、分析方法，我们是能够抽丝剥茧把绝大部分隐藏的很深的bug揪出来的，当然有的时候你要考虑投入产出比，但投入产出比不是本篇要考虑的，本篇只讲一些我积累的经验。
为什么不能重现bug?
最大的原因就是：测试人员对被测物的了解还不够深入。
我曾经做过一段很长时间的收集和统计，那些被称作过“难以重现”的bug最后都可以分为如下几类：
1.环境的变更造成了bug难以重现，这里的环境包括了：基础软硬件环境(操作系统、网络、存储、中间件、容器等等)，被测物自身发生了某些变更。环境的变更一般是由于多人共用环境造成的，也有少量情况下是系统内部或者时间触发的变更(这类bug非常难重现)。
2.没有找到真正引发bug的操作。这些操作往往是一些不怎么显而易见的操作，测试人员在不经意间完成，而又忽略了这一操作，以致难于重现bug。
3.没有找到真正会引发bug的操作序列。很多bug的重现需要满足多个条件。在满足多个条件的状态下，你做了对应的操作，bug才会被触发。
4.bug必须使用特殊的数据才会出现，测试人员没有意识到她使用的数据的特殊性。一种比较难搞的情况是：同一组输入，在不同情况下(不是不同的业务情况)输入会被转化成不同的数据。我曾经见到过这么个例子，程序员用系统当前时间作为随机数的种子来生成id，但是id设置的比较短，一个存储的操作使用这个id，在一些情况下，发生了冲突，当时做功能测试这种小概率事件耗费了测试人员大量时间也没有稳定重现，还是在性能测试的阶段测试了出来。
5.测试人员由于错误操作，出现了误报(这很常见)。比如，记得自己执行了step3,其实没有，或者没有正确执行step却觉得正确执行了。
怎样对付这样的bug呢?
我喜欢James Bach 说的那句话：测试就像CSI。CSI是Criminal Scene Investigation 的缩写，也是我非常喜欢的美国系列剧。
从我来看CSI的精髓在于：仔细观察，详细记录，科学分析，严密推理，有序求证，大胆假设，持续不懈，团队协作和一点儿运气。找bug其实和CSI探员做犯罪现场调查没什么太大区别。得知道，你工作的重要性一点儿不亚于CSI探员。
仔细观察：第一件事情就是要观察，观察你所做的一切操作和一切相关的系统反馈。在一开始，观察的重要性要远远大于思考，通过观察你获得蛛丝马迹，这些蛛丝马迹是你进行思考和假设的关键输入。例如，我在一次测试的过程中，发现做某种操作的时候会相当慢，极少数情况下还报错过一两次，当询问了开发人员后得知这个操作的后台实现步骤是：先查看数据是否在缓存中，如果不在，则从远端服务器请求数据。我抓住少数情况下会报错的这一现象，仔细观察它的出错信息后猜测报错并不是因为网络连接不稳定引起的，而是由于远端服务接口实现有问题引起的，后来重新设计了测试用例，果然找到了问题所在。如果不仔细观察出错信息，就会听信开发人员认为这是网络不稳定引发的正常issue而错过这个bug。
如需了解更多测试技术信息请关注：深圳多测师软件与技术服务有限公司
软件测试之如何重现难以重现的bug相关推荐
- 如何重现难以重现的bug
生活中有这么一种现象:如果你关注某些东西,它就会经常出现在你眼前,例如一个不出名的歌手的名字,一种动物的卡通形象,某个非常专业的术语,等等等等.这种现象也叫做"孕妇效应".还有类似 ...
- 线上bug检测工具 android,Android 测试中对于偶现且难以重现的 bug 的处理
吐槽 请先允许我对此类 bug 进行吐槽,相信做测试的同学都碰见过这种 bug! 我们在测试过程中经常会碰见一类很头疼的 bug,就是偶现性的 bug,所谓偶现性,是相对于必现而言,这类 bug 有些 ...
- 测试人遇到难以重现的bug，要怎么办？
长时间做测试的人,自然也惹上了一堆毛病.譬如,这生了病不叫病,叫做bug. 好了 发现bug了第一件事情 重现或者说确认开始了 摸了摸自己的胸口 恩....有点痛 但是又似乎是飘渺的 看来这还是一个难 ...
- 难以重现的Bug怎么处理
在开发过程中,不管是开发人员还是测试人员最不愿意碰到就是偶现的Bug.如果复现吧需要花费大量时间和精力,而且还不一定能成功复现,不复现吧到线上出了问题谁都受不了. 为什么不能重现Bug? 1.环境的变 ...
- 软件测试之BUG的提交注意事项
交bug时的注意事项 (1) 发现一个问题时,不必急着提交,可以先做验证(包括复现.对比测试等)进行证实, 看是概率性问题还是每次必现的问题,需要时也应使用不同版本不同机器做对比验证,当然,如果已经很 ...
- 软件测试之BUG描述
测试人员在找到bug后,就要提交bug了,要提交bug时,最主要的就是要描述好bug,一个好的bug描述,能让开发人员,更快的定位到问题产生的原因,能够更快的解决bug,而,如果描述的很模糊,有可能开 ...
- 软件测试之魂：核心测试设计精解
软件测试之魂:核心测试设计精解(第2版)(掌握核心竞争力成为不可替代的测试精英) 肖利琼著 ISBN 978-7-121-19677-5 2013年5月出版 定价:59.00元 356页 16开 编辑 ...
- 软件测试之魂：核心测试设计精解（第2版）
<软件测试之魂:核心测试设计精解(第2版)> 基本信息 作者: 肖利琼 出版社:电子工业出版社 ISBN:9787121196775 上架时间:2013-5-13 出版日期:2013 年5 ...
- 软件测试之魂：核心测试设计精解（第2版）》
<软件测试之魂:核心测试设计精解(第2版)> 基本信息 作者: 肖利琼 出版社:电子工业出版社 ISBN:9787121196775 上架时间:2013-5-13 出版日期:2013 年5 ...
最新文章
- 从Java类库看设计模式
- 程序员取悦女票的正确姿势---Tip1（iOS美容篇）
- 图像风格迁移也有框架了
- 字典生成_Python数据字典生成工具详解
- HyperLedger Fabric Introduction——区块链超级账本介绍
- 批量修改MSSQL架构名称
- lucene.net 应用资料
- opencv3学习总结1
- 湖南铁路科技职业技术学院计算机等级,湖南铁路科技职业技术学院——高速铁路动车乘务专业...
- 基于verilog的FFT设计与实现
- MOTOMAN-SV3X运动学建模验证图
- uint8 转换为 float
- linux 启动作业,[转载] 随身带着走的作业系统 ~安装Linux作业系统于随身碟~
- 软件体系结构 复习题
- 计算机显示器出现黑屏分析
- postman中从url中获取各参数值
- Mybatis collection 递归查询并自动装填所有子节点（多参数查询传入参数方法）
- 移动运营商ipcc文件_教你如何在苹果官网提取IPCC文件
- Mobile开发(绘制背景图片)
- LeetCode20.有效的括号——纯C