微信+17031115530，拉测试微信群交流
****************************************************************************************
对很多测试人员（尤其是对新手来说）在工作过程中最不愿遇到的一件事情就是：在测试过
程中发现了一个问题，觉得是 bug，再试的时候又正常了。
碰到这样的事情，职业素养和测试人员长期养成的死磕的习性会让她们觉得不能放过这个
bug，但是重现这样的 bug 有时候需要花费大量的时间，有的时候还有一些盲目性（因为黑
盒测试的缘故，很多内部状态是不可见的，因此无法获取有效的信息来做跟踪），效率较为
低下。
在实际工作中，时间和进度摆在那里，在经历了多次痛苦的失败尝试之后，测试人员的处理
方法一般会有如下几种：
1.向开发人员寻求帮助来重现 bug；
2.当做一个 issue 报给开发人员。
可是这样的做法存在如下问题：
1.开发人员责任心不够强，不愿意花太多精力去求证这件事情，常见的回复就是：在我这儿
没事儿啊，我也重现不了，bug 关了吧。结果随后在生产系统上，bug 又开始随机出现了。
2.就跟测试人员不擅长编码和调试一样，开发人员并不擅长找出 bug。经过一番尝试以后，
他们也找不出什么问题来，常见的回复同第一条是一样的。bug 上线后又出现的宿命也是一
样的。
这时候，真正的问题来了：如何捕捉难以重现的 bug？这件事儿对于测试人员来说就这么难
么？
答案并不那么乐观，重现“难以”重现的 bug 本来就是一件“难以”完成的事情。但“难以”并不
是不可能，通过一系列的测试、分析方法，我们是能够抽丝剥茧把绝大部分隐藏的很深的
bug 揪出来的，当然有的时候你要考虑投入产出比，但投入产出比不是本篇要考虑的，本篇
只讲一些我积累的经验。
为什么不能重现 bug？
最大的原因就是：测试人员对被测物的了解还不够深入。
微信+17031115530，拉测试微信群交流
我曾经做过一段很长时间的收集和统计，那些被称作过“难以重现”的 bug 最后都可以分为如
下几类：
1.环境的变更造成了 bug 难以重现，这里的环境包括了：基础软硬件环境（操作系统、网络、
存储、中间件、容器等等），被测物自身发生了某些变更。环境的变更一般是由于多人共用
环境造成的，也有少量情况下是系统内部或者时间触发的变更（这类 bug 非常难重现）。
2.没有找到真正引发 bug 的操作。这些操作往往是一些不怎么显而易见的操作，测试人员在
不经意间完成，而又忽略了这一操作，以致难于重现 bug。
3.没有找到真正会引发 bug 的操作序列。很多 bug 的重现需要满足多个条件。在满足多个条
件的状态下，你做了对应的操作，bug 才会被触发。
4.Bug 必须使用特殊的数据才会出现，测试人员没有意识到她使用的数据的特殊性。一种比
较难搞的情况是：同一组输入，在不同情况下（不是不同的业务情况）输入会被转化成不同
的数据。我曾经见到过这么个例子，程序员用系统当前时间作为随机数的种子来生成 id，但
是 id 设置的比较短，一个存储的操作使用这个 id，在一些情况下，发生了冲突，当时做功
能测试这种小概率事件耗费了测试人员大量时间也没有稳定重现，还是在性能测试的阶段测
试了出来。
5.测试人员由于错误操作，出现了误报（这很常见）。比如，记得自己执行了 step3,其实没
有，或者没有正确执行 step 却觉得正确执行了。
怎样对付这样的 bug 呢？
我喜欢 James Bach 说的那句话：测试就像 CSI。CSI 是 CriminalScene Investigation 的缩写，
也是我非常喜欢的美国系列剧。
从我来看 CSI 的精髓在于：仔细观察，详细记录，科学分析，严密推理，有序求证，大胆
假设，持续不懈，团队协作和一点儿运气。找 bug 其实和 CSI 探员做犯罪现场调查没什么
太大区别。得知道，你工作的重要性一点儿不亚于 CSI 探员。
仔细观察
第一件事情就是要观察，观察你所做的一切操作和一切相关的系统反馈。在一开始，观察的
重要性要远远大于思考，通过观察你获得蛛丝马迹，这些蛛丝马迹是你进行思考和假设的关
键输入。例如，我在一次测试的过程中，发现做某种操作的时候会相当慢，极少数情况下还
报错过一两次，当询问了开发人员后得知这个操作的后台实现步骤是：先查看数据是否在缓
存中，如果不在，则从远端服务器请求数据。我抓住少数情况下会报错的这一现象，仔细观
察它的出错信息后猜测报错并不是因为网络连接不稳定引起的，而是由于远端服务接口实现
微信+17031115530，拉测试微信群交流
有问题引起的，后来重新设计了测试用例，果然找到了问题所在。如果不仔细观察出错信息，
就会听信开发人员认为这是网络不稳定引发的正常 issue 而错过这个 bug。
详细记录
详细记录你的操作步骤及返回结果非常有助于回朔问题，也有助于后续分析。准备一个 word
文档，和截图工具有时候非常必要。另外，在观察的时候，你不仅要注意被测物的最终返回，
还需要观察过程中的一些中间状态，往往这些中间状态提供的信息才是解开问题的关键。这
些中间状态一般会被记录在 log 文件中，因此知道你的被测物是如何记 log 的，log 被记录
在哪里非常重要。log 给了你另外一个看系统的角度。log 是有级别的，如果级别可以动态
调整，在找比较难找的 bug 时，可以将 log 记录的级别调至最低（DEBUG 级）让它们记录
更多内容。利用系统的错误转储文件（比如 linux 的 core dump 文件，windows 下也有相应
的记录转储文件的方式）分析也是个不错的办法（需要较高技术能力），但一般建议测试人
员把这些转储文件交给更专业的开发人员来分析。
除了 Log，如果能有监控信息，也要查看他们。比如系统提供的监控平台，监控日志；应用
自己的监控平台、监控日志（如果有的话）；采用一些外部技术手段截取一些中间状态信息，
如使用 sniffer 抓取通讯包，使用 Fiddler 截获 HTTP 报文内容；给运行程序插桩来查看内存，
堆栈，线程，函数被调用情况等情况，如 Jprofile，gpertool 等等。
科学分析
对于黑盒测试人员来说，科学分析意味着你需要有一定的分析策略。我们需要采取一些形式
化的方法来完成我们的分析。基于我的统计，缺陷难以重现有很大一部分原因是因为“没有
找到真正引发 bug 的操作序列“。测试人员不可能像开发人员那样去跟入到代码内部，设置
断点调试程序，他们主要的测试方式是直接来操纵被测物，并从外部观察被测物状态的改变。
显而易见，“状态转换图分析法”是测试人员对付“难以重现 bug”的最强有力武器之一。状态
转化图能够帮助测试人员很好的选择操作路径，并且知道这么做有什么意义。“状态图转化
法”绝对是测试人员值得花时间学习和研究的一种方法，你可以走的很深，也可以研究得很
远（可以从 MBT 的方向进行拓展），限于篇幅，这里就不展开了。在这里推荐《探索吧！
深入理解探索式软件测试》这本书，它的第八章对“状态转换”做了非常实用的描述。
上文分析的让 bug 难于重现的另一种原因是没有找到“真正引发 bug 的特殊数据”。
我的常用做法是这样的：
1.画出系统交互图（要真正弄清系统的边界，这很重要），并识别出每种交互会有什么样的
输入、输出数据和中间数据，识别出这些数据的规约和格式，这样你就不会对数据有遗漏。
2.考虑数据的等价类、边界值，对这些输入进行组合，分析数据之间是否有耦合关系，如果
有耦合关系，弄明白关系是什么，设计违背这些关系的用例，最后采用组合测试工具初步生
成测试集，再人工选取最可能出问题的数据集（直觉有时候非常管用）。
微信+17031115530，拉测试微信群交流
严密推理
天马行空对测试人员很重要，但是当你试图重现一个 bug 的时候，这并不是一个非常好的方
法。抓住了蛛丝马迹，你就要推理是为什么产生了这种蛛丝马迹。限于工作性质，测试人员
更多的会从：业务完整性、数据完整性、业务正确性、数据正确性等方面考虑问题。但是，
如果测试人员对被测物的 IT 架构有比较深入了解的话，推理的范围会扩大到技术实现层面，
如：多线程可能引发的问题，网络引发的问题，excepiton 处理不当引发的问题，全局事务
设计不当引发的问题，内存泄漏引发的问题，数据库表设计不合规引发的问题等等等等，这
些会让你的分析推理能力如虎添翼。当然，如果限于条件，测试人员不具备这类能力，则应
该在适当的时候请求开发人员协助。
有序求证
这里只有一点需要注意。那就是，在求证的过程中不要打散弹枪，按照你的推理一步一步的
来，一个个推理的来验证，一次只引入一处修改。这样才能让你的捕虫网编制的足够细密。
大胆假设
有的时候，看似八竿子打不着的东西竟然存在着千丝万缕的联系，而你获取信息的过程总是
一个由少及多的过程，一开始这些联系是无法被识别出来的。通过推理，逐步验证，你慢慢
的识别出了大部分内在联系。但有时候这种逐步推进的工作也会有局限性，工作如果出现了
瓶颈（你试遍了你所有的假设，都没有重现 bug），这时候就需要发挥一点儿想象力了，天
马行空这时候从一定程度上又变得有用起来，当然天马行空也不是无厘头，还得靠我们所谓
的“灵光一闪”，这号称是潜意识在帮助你。CSI 的剧情中不也总是出现这种柳暗花明的桥段
么？
坚持不懈
话不多说，有的时候你差的就是那么一点儿点儿耐心。
团队协作
很多情况下，重现 bug 不是一个人能搞定的。我们需要测试环境 ready，测试数据 ready，各
种监控、分析工具 ready，各种不同的视角开拓思路、加深对被测试物的认识。这是 team
work！！！独行侠有时候很管用，但是终究有极限。这就是为什么 CSI 是一票人在做而不
是一两个人在做。
微信+17031115530，拉测试微信群交流
一点儿运气
说实在的，有的时候重现 bug 就是靠运气，你不得不承认这一点。事实上很多美好的事情发
生都得依靠运气，比如中彩票。要记住的一点是，运气是建立在你不懈努力的基础上的。如
果你一张彩票不买，你肯定什么也中不了。但如果你坚持买上几年，中个五块十块甚至二百
也不是梦。
Let it go
全试过了，连运气都没有。你只能放手，回到最上面我说的那两条了：找开发来帮忙，或者
给开发报 issue。btw，即使不能重现 bug，也应该给开发人员提供更多信息：如 log、dump
文件、监控记录、屏幕截图等。做一个负责人的测试人员，把烦恼真实的留给下家，这很重
要：）
其实上面的大段论述是站在测试人员角度上来看的。我也写很多代码，作为一个开发人员（哈
哈）我查错的方式一般是：
1.先能稳定的复现错误。（这一步最难）
2.设桩，打印出一些中间状态来分析，看到那一块儿错了。
3.摘除不相干的代码，慢慢迭代，定位错误。
4.如果发现调用第三方依赖跟你想的不一样，先读文档，然后再测试第三方依赖。有问题再
想办法。
5.良好的程序设计和单元测试覆盖度才是不二法门，会让你的调试变得简化的太多。。。用
过都说好：）
6.测试工作的确增强了我排错的能力。coding 的同学都尝试做几个月测试吧。会有相当大的
好处。
最后，附上一个实战思路
如果你没有办法稳定的复现 bug，可以通过概率统计的方式将问题反馈。如果 10 次里出现
一次问题，不足以打动开发人员重视问题，可以通过自动化测试的方式提高执行次数的数量
级，如果一千次出现 50 次~100 次。这个问题就足够引起重视了。在 negotiate 的时候，这是
一种好思路。
*************************************************************************************************
微信+17031115530，拉测试微信群交流
网友评论