难以重现的bug怎么处理

这时候，真正的问题来了：如何捕捉难以重现的bug？这件事儿对于测试人员来说就这么难么？

答案并不那么乐观，重现“难以”重现的bug本来就是一件“难以”完成的事情。但“难以”并不是不可能，通过一系列的测试、分析方法，我们是能够抽丝剥茧把绝大部分隐藏的很深的bug揪出来的，当然有的时候你要考虑投入产出比，但投入产出比不是本篇要考虑的

为什么不能重现bug？     

最大的原因就是：测试人员对被测物的了解还不够深入。

我曾经做过一段很长时间的收集和统计，那些被称作过“难以重现”的bug最后都可以分为如下几类：

• 环境的变更造成了bug难以重现，这里的环境包括了：基础软硬件环境（操作系统、网络、存储、中间件、容器等等），被测物自身发生了某些变更。环境的变更一般是由于多人共用环境造成的，也有少量情况下是系统内部或者时间触发的变更（这类bug非常难重现）。

• 没有找到真正引发bug的操作。这些操作往往是一些不怎么显而易见的操作，测试人员在不经意间完成，而又忽略了这一操作，以致难于重现bug。

• 没有找到真正会引发bug的操作序列。很多bug的重现需要满足多个条件。在满足多个条件的状态下，你做了对应的操作，bug才会被触发。

• Bug必须使用特殊的数据才会出现，测试人员没有意识到她使用的数据的特殊性。一种比较难搞的情况是：同一组输入，在不同情况下（不是不同的业务情况）输入会被转化成不同的数据。我曾经见到过这么个例子，程序员用系统当前时间作为随机数的种子来生成id，但是id设置的比较短，一个存储的操作使用这个id，在一些情况下，发生了冲突，当时做功能测试这种小概率事件耗费了测试人员大量时间也没有稳定重现，还是在性能测试的阶段测试了出来。

• 测试人员由于错误操作，出现了误报（这很常见）。比如，记得自己执行了step3,其实没有，或者没有正确执行step却觉得正确执行了。

怎样对付这样的bug呢？

我喜欢James Bach 说的那句话：测试就像CSI。CSI是CriminalScene Investigation 的缩写，也是我非常喜欢的美国系列剧。

 

从我来看CSI的精髓在于：仔细观察，详细记录，科学分析，严密推理，有序求证，大胆假设，持续不懈，团队协作和一点儿运气。找bug其实和CSI探员做犯罪现场调查没什么太大区别。得知道，你工作的重要性一点儿不亚于CSI探员。

科学分析：对于黑盒测试人员来说，科学分析意味着你需要有一定的分析策略。我们需要采取一些形式化的方法来完成我们的分析。基于我的统计，缺陷难以重现有很大一部分原因是因为“没有找到真正引发bug的操作序列“。测试人员不可能像开发人员那样去跟入到代码内部，设置断点调试程序，他们主要的测试方式是直接来操纵被测物，并从外部观察被测物状态的改变。显而易见，“状态转换图分析法”是测试人员对付“难以重现bug”的最强有力武器之一。状态转化图能够帮助测试人员很好的选择操作路径，并且知道这么做有什么意义。“状态图转化法”绝对是测试人员值得花时间学习和研究的一种方法，你可以走的很深，也可以研究得很远（可以从MBT的方向进行拓展），限于篇幅，这里就不展开了。在这里推荐《探索吧！深入理解探索式软件测试》这本书，它的第八章对“状态转换”做了非常实用的描述。（很少用，我感觉和因果图差不多）

上文分析的让bug难于重现的另一种原因是没有找到“真正引发bug的特殊数据”。

我的常用做法是这样的：

• 画出系统交互图（要真正弄清系统的边界，这很重要），并识别出每种交互会有什么样的输入、输出数据和中间数据，识别出这些数据的规约和格式，这样你就不会对数据有遗漏。

• 考虑数据的等价类、边界值，对这些输入进行组合，分析数据之间是否有耦合关系，如果有耦合关系，弄明白关系是什么，设计违背这些关系的用例，最后采用组合测试工具初步生成测试集，再人工选取最可能出问题的数据集（直觉有时候非常管用）。

大胆假设：有的时候，看似八竿子打不着的东西竟然存在着千丝万缕的联系，而你获取信息的过程总是一个由少及多的过程，一开始这些联系是无法被识别出来的。通过推理，逐步验证，你慢慢的识别出了大部分内在联系。但有时候这种逐步推进的工作也会有局限性，工作如果出现了瓶颈（你试遍了你所有的假设，都没有重现bug），这时候就需要发挥一点儿想象力了，天马行空这时候从一定程度上又变得有用起来，当然天马行空也不是无厘头，还得靠我们所谓的“灵光一闪”，这号称是潜意识在帮助你。CSI的剧情中不也总是出现这种柳暗花明的桥段么？

一点儿运气：说实在的，有的时候重现bug就是靠运气，你不得不承认这一点。事实上很多美好的事情发生都得依靠运气，比如中彩票。要记住的一点是，运气是建立在你不懈努力的基础上的。如果你一张彩票不买，你肯定什么也中不了。但如果你坚持买上几年，中个五块十块甚至二百也不是梦。

Let it go：全试过了，连运气都没有。你只能放手，回到最上面我说的那两条了：找开发来帮忙，或者给开发报issue。btw，即使不能重现bug，也应该给开发人员提供更多信息：如log、dump文件、监控记录、屏幕截图等。做一个负责人的测试人员，把烦恼真实的留给下家，这很重要：）

 

最后，附上一个实战思路：

 

如果你没有办法稳定的复现bug，可以通过概率统计的方式将问题反馈。如果10次里出现一次问题，不足以打动开发人员重视问题，可以通过自动化测试的方式提高执行次数的数量级，如果一千次出现50次~100次。这个问题就足够引起重视了。在negotiate的时候，这是一种好思路。

 

3.多读一些其它书籍，不限于技术书籍。如果想读的书有利于工作，推荐一些如何做思辨思维的书。《思考的艺术》《六顶思考帽》《你的灯亮着么》《学会提问》是我喜欢的4本书。

它们会教你怎么独立思考，养成提问的习惯，而提问的习惯是我们现在的测试人员最缺乏的一件事情。人们往往拿了被测物就开始忙着写用例，忙着测试。而不是先探索它、研究它。

当然IT技术也要掌握，如果你的IT技能能够赶上开发，你发现你做测试的思路会非常的宽广：）

4.把书籍中的东西跟你的工作对比，把好的东西引入工作（这点是检验书本质量的好方法，也是促进你思考，促进你能力提高的好方法）。

6.搞定你所在行业的领域知识：如常见IT技术，常见业务知识，这些知识掌握的越深，你的价值越高。测试技术是内功，但是你能直接为企业带来价值的最大之处是你对被测物熟悉程度，也就是你的领域知识！！！

7.没有方向？从你的工作入手，比如，你遇到的最大的难题是什么？我怎么解决它？我需要掌握什么样的技术解决他？我要推动什么样的组织改变来解决它？别人怎么解决它？有没有更好的方法？使用后我改进了那些？google一下别人有没有同样的问题（回复wyfq，直接FQ用Google）？尝试作对比，如果觉得他做得好，尝试联系那个人讨论一下。看看对方的进展。尝试把活儿干得特别漂亮。你能解决10个中等问题以后，你的能力会有大幅度提高。 

自动化测试很火热，我想去学

selenium\appnium很火，我想去学

听说性能学好了，会很有前途，我想去学

据说，测试掌握了脚本技能才能很好的发展，我想去学

学Python语言好，还是Java语言好？

 

OK，如上基本上是多数同学经常问到的问题以及疑惑

 

老徐观点：一件事，想清楚目的和本质，你就有答案了；

 

很多同学，每天都在学习，痛苦的学习，逼迫自己坚持去学，看大家在学什么，自己也想学，收集了很多很多的资料、视频去学；

结果：每天都很累，学完还是什么都不会；

为何？

没有目标驱动，没有想过学这些来解决什么问题，没想过实际工作中如何把学习的这些内容实践；当然结果就是，学完第二天就完全忘了！忘了！

 

正确的学习姿势是怎样的？

老徐推崇的是工作中学习、用到再去学习、需要什么学什么；

前提：在这之前要打好基础，否则临时需要久久不能入门，完全无法切入；

 

OK，回到开始老徐列出的几个问题；

很多同学自动化概念都没搞清楚，自动化能解决什么问题、什么情况适合用自动化都没搞清楚，上来就学qtp等工具，然后说自己会自动化了；

就像，很多同学学性能测试，就是学会如何用LR，重点是很多同学学半天LR还没学会如何用！

其他一样，学习一个东西，做一件事，先想清楚这件事的目的是解决什么问题，它的本质是什么？

9-从事几年后，迷茫了？

可以详细陈述你当前的阶段，你的优势，你的兴趣，你掌握的技能；

找老徐聊聊，也许能给你点建议；