为什么一些缺陷（Bug）总是难以重现？

很多公司，问题单提单量是绩效考核的很大一部分，甚至占到了90%或更高，这就导致了比较奇葩的现象：问题单提单量高，解决率却很低。这么说有点诛心的味道，实际工作中怀揣这种

问题1： 复现不了的问题
a. 昨天必现的问题、今天复现不了；

b. 生产环境必现的问题、测试环境复现不了；

c. 测试人员必现的问题、开发人员复现不了；

d. 一套环境必现的问题、另一套环境复现不了；

问题2： 自己的问题复现不了
A：发现的问题很多，也很严重，最终复现不了需要攻关解决、降级处理的也不少
B : 提交问题比A可能稍少也可能多，大部分问题在提交之前就分析的很透彻，甚至点出了问题的原因、出现的条件和场景，最终问题全部高效、及时的得到了解决。

出现以上问题的原因是什么？如何解决？下面一步一步说。

一、出现上述问题的原因
经过这些年工作的积累，以及与各领域测试同行的交流，问题复现不了的原因不外乎下面几个：

绩效导向，提单量影响绩效考核
问题是伴随出现的，不知道何时出现、如何出现的
你觉得你知道了根本原因，实际上你不知道
系统日志记录不完善、或者根本没有打开
测试过程全程无记录
问题单缺乏关键信息
高并发、多线程、异步调用复现概率低的问题
黑天鹅问题
二、解决问题的思路
1. 绩效导向问题

很多公司，问题单提单量是绩效考核的很大一部分，甚至占到了90%或更高，这就导致了比较奇葩的现象：问题单提单量高，解决率却很低。这么说有点诛心的味道，实际工作中怀揣这种想法的人其实非常少，这种结果是特定的考核机制下自然形成的，很多身处其中的人可能并没有意识到。

跟我们平常说的上有政策、下有对策是一致的，比如二套房，大家排队离婚。

姿势： 高大上的价值观引导，绩效考核方式是落实测试价值观的手段
a. 提交问题的目的，是为了解决问题，提升用户的使用体验。这样测试人员不仅会从技术角度分析产品的实现，还会从易用性等各个角度去衡量产品。
b. 测试的乐趣在于发现问题、定位问题的过程。一般喜欢打探小道消息、对问题刨根究底的人，测试都做的特别好。

现在很多公司已经调整了绩效考核的指标，比如阿里同学，重点考核的是上线发布后产品的质量、测试的效率、个人的成长。虽然最后一点有点虚，但是从现在阿里系出版的技术作品看，价值观引导确实做得好。

问题数量可以作为产品质量评价的一个数据，去衡量产品的质量，但前提是有代码缺陷密度等基线数据作为支撑，而不能拍脑袋。

2. 伴随出现的问题

执行测试时都有明确的目的性，这个用例测试的目的是什么，怀疑会出现什么样的现象。出现计划内的问题，是很容易复现和定位的。但伴随出现的问题，你一般不能第一时间抓住它，直到它产生了破坏作用，才能感知到问题的存在。它是在何时因为什么操作出现、什么事件触发的，不知道。这类问题就比较容易演化为难复现问题。

姿势：

保持冷静，不要激动，保持现状
思考一下：你对它做了什么？为什么这样？ 他们两个什么关系（可能没关系）？ 可能在什么地方、什么操作、什么事件触发的？
想明白了吗？想不明白叫别人一起想。
不管是否想明白，把操作记录、组网、数据、配置、状态全部记录下来
在不破坏环境的情况下，尝试验证想法；如果问题比较严重，考虑另搭环境验证；
想法得到验证后，简化环境验证问题，找到问题触发条件
3. 几个自作孽的问题

下面这几个问题，只要做事严谨是可以避免的：

你觉得你知道了问题原因，实际上你不知道
系统日志没开
系统日志记录不完善
测试环境、配置文件、环境数据无保留
操作过程无记录
问题单缺乏关键信息
以上这些原因都可能导致问题无法复现。发现问题后，分析问题的正确姿势：

先别着急提问题
回想可能是什么事件、什么操作、还是环境变化触发了这个问题。 如果你有记忆宫殿就好了。
查阅相关日志、操作记录进行验证
依据问题重要性，保存关键的信息
在现有环境中验证
找到稳定复现的条件 持续简化环境和复现条件 找到问题的确切触发条件和最简环境 提交问题，要附带所有必要信息 对于热爱测试的 工程师 来讲，这个过

找到稳定复现的条件
持续简化环境和复现条件
找到问题的确切触发条件和最简环境
提交问题，要附带所有必要信息
对于热爱测试的工程师来讲，这个过程是充满乐趣的，但是要有严密的逻辑思维能力和对被测试系统运行机制的深刻理解。找到原因后，你可能会得出这样的结论：开发为什么会犯如此低级的错误；开发对协议的理解有误；开发对此类数据的处理有问题等等。然后你可以跟开发说，你哪里的代码处理这个数据有问题、你哪里哪里理解错误，虚荣心会得到小小的满足。

大家有没有感觉到，在定位复杂问题时，日志系统里缺少的总是关键信息，而有的信息总是不太重要的， 软件可维护性任重道远。
另外，有些公司的crash问题是不用复现的呦，信息已经足够了。 你的公司能做到吗？

4. 高并发、多线程、异步调用复现概率低的问题

此类问题即使有日志信息，因为大容量、高并发，再加上异步处理打乱了原有的惯性逻辑思维，是很难用通用的方法定位出来的。
比如系统记录明确指针异常的问题，也有堆栈的信息，并且知道哪个指针为空，但是不知道如何导致的，经排查初始化完全没有问题。这种情况下就不能简单的通过返回NULL来解决，这样有可能用户得到的数据就是空的，虽然概率很低，但是会影响用户的体验。 特别是在初创公司，在激烈的市场竞争中，差的用户体验，无异于自掘坟墓。

姿势：此类问题测试同事是不太可能单独搞定的，一定要伙同资深开发同事一起分析（一般你不叫他他也会过来，这类问题是很有吸引力的）。主体思想是先提高复现概率、一步步缩小问题范围，最终定位出问题。具体思路怎么变态怎么来，客户端加大访问量、服务端减少资源、怀疑是网络的问题可以使用traffic control模拟报文错误或异常。说随如此说，碰到具体问题还是要具体分析，根据问题现象，进行有针对性的验证。

正在做测试的朋友可以进来交流，群里给大家整理了大量学习资料和面试题项目简历等等....