你发现的缺陷（Bug）为什么总是难以复现？

问题1： 复现不了的问题
a. 昨天必现的问题、今天复现不了；
b. 生产环境必现的问题、测试环境复现不了；
c. 测试人员必现的问题、开发人员复现不了；
d. 一套环境必现的问题、另一套环境复现不了；

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

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

一、出现上述问题的原因

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

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

二、解决问题的思路

1. 绩效导向问题

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

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

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

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

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

2. 伴随出现的问题

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

姿势：

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

3. 几个自作孽的问题

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

1. 你觉得你知道了问题原因，实际上你不知道
2. 系统日志没开
3. 系统日志记录不完善
4. 测试环境、配置文件、环境数据无保留
5. 操作过程无记录
6. 问题单缺乏关键信息

以上这些原因都可能导致问题无法复现。发现问题后，分析问题的正确姿势：

1. 先别着急提问题
2. 回想可能是什么事件、什么操作、还是环境变化触发了这个问题。 如果你有记忆宫殿就好了。
3. 查阅相关日志、操作记录进行验证
4. 依据问题重要性，保存关键的信息
5. 在现有环境中验证

   原文转自：http://www.jianshu.com/p/380e347f301a

   • 共2页:
   • 上一页
   • 1
   • 2
   • 下一页