IDEA激活码
测试人员除了对测试用例进行测试外，很重要的一项工作还需要对发现的bug进行描述并提交开发人员，在bug描述中，不可或缺的都会要求填写复现几率，always/sometimes/once，它们分别代表百分之百复现，偶现和只复现一次
测试人员根据测试步骤执行N次，bug出现M次，然后用M除以N，得到的值如果是1，即表示100%复现，如果是1/N，表示只复现一次，如果是1/N和1之间的数字，就是偶现的几率
上面这些，每一个测试工程师都不会陌生，但是我们真的有仔细想过always/sometimes/once吗？
我们测试的软件或者系统，它们是用代码逻辑实现的，并不是如同抛硬币一般，我这次抛了是正面，下次抛了就是反面
代码和逻辑是确定的，漏洞存在了就是存在了，并不会这次测试发现了就说明有bug，下次测试没发现就变成了偶现
那为什么不同的bug复现几率有差别呢？
我们以最常见的偶现问题，机器重启为例
客户报了个机器重启的问题，描述为：
1.车机连接蓝牙手机
2.用车机听歌30分钟
3.接听来电，通话5分钟
4.挂断，车机重启
很简单的步骤，测试人员尝试复现，做了100次这样的操作，还是没有发现此bug，那能够说明没有问题吗？
当然不能
为什么没复现呢？
你以为你是按照bug描述执行的复现步骤，但是这个复现步骤真的就是造成此问题出现的原因吗？不见得，不然为什么没复现呢？
有可能客户的车机系统已经运行了好几个小时，有可能客户在之前打开了很多的app，有可能客户在户外气温很高也说不定呢
所以换个角度思考，如果我真的知道了触发bug的条件，那这个bug就是100%复现，所谓的必现和偶现是不是只是触发bug的条件易或难的区别
这是不是意味着所有的bug都应该设置为always呢？
当然不是，如果你把所有的精力都花在很难复现的问题上，你要错过多少简单的问题呢？
测试人员无法兜住所有的问题，也永远不可能猜透用户的心思
你觉得酒吧就应该用来喝酒，所以你把所有关于酒的情况测试了一遍，没想到某个顾客进去要了一份蛋炒饭，然后酒吧就爆炸了
