1.提出的bug，开发要求重现后，但是在系统上已经重现不了
2.测试过程中，bug为偶现，但找不到规律
。。。
碰到类似上面的情况，不管开发还是测试都很纠结，负责任的开发会考虑：如果拒绝，万一我打回之后又出现了这个问题，那还是要给我返回来的；测试也会考虑：碰到无法重现的bug，总是给我打回来，如果我关闭了，那将来万一出现了怎么办？
那么这类不是必现的bug该如何处理？
1.如果在当前版本发现了bug，一定要在当前版本进行bug重现
如果更换了版本，那么在开发过程中，开发人员基于绩效考核可能会偷偷修改bug（可能性比较小），另外，换了新版本也有可能出现环境的不一致性，那么原环境的bug就不能在新环境上进行复现。
再就是可能出现环境中的热补，导致代码有所改变，所以引发的bug无法重现。因为这些不确定性，才可能导致bug无法重现或者运气化重现。
为了排除这些影响，要在我们当时出现bug的版本下进行bug的重现；如果必须要再在另一个版本上重现bug,时间允许的话,可以考虑回退到之前的版本。这个时候，每个版本的包都需要分门别类保存起来显得尤为重要。
2.项目时间允许的情况下，开发人员应大力协作复现bug
开发人员在自己负责的那部分代码确定没有问题之后，这时候就需要去考虑接口，是否在接口数据处理上存在问题，同时也需要其他开发人员进行配合。
同样地，测试人员也需要尽最大努力来还原当时的场景：包括环境、数据、前置条件、测试步骤等。
3.测试人员要再次确认用例设计的覆盖度和周密性
对于测试而言，用例设计的覆盖不够，步骤和设计不够严谨也会导致bug不在我们的掌握中.
一是原本用例就没有好好设计过，未经评审过，大家测试时就很随意，这样的话就要抓紧时间,赶紧把用例好好重新设计一下，再叫上相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，只有这样,才能保证软件覆盖度能满足本次项目需求的要求；
二就是是该项目已经经过严格的需求评审及用例评审了。当然，即便如此也不能避免漏测以及对特殊情况的考虑。
如果经历了以上三个步骤之后，绞尽脑汁，仍然不能使bug复现时，可以这么理解:经历了各种步骤的努力之后,仍然不能复现的bug优先级别不高，需要重新评估重要度，但仍需要对这个bug进行持续关注。
如果项目组统一决定不影响版本发布，就密切关注这个问题（已知问题），在发布后进行验证。而且该bug不能关闭，延期进行跟踪，如果之后的几个版本连续没有出现问题，那么就可以关闭问题单了。
最后，是考虑公司的整体性情况，是否针对提交bug的规范上存在需要完善的地方，那么针对这种出现的问题进行公司规范的改善，对公司流程还有测试人员素质的提升，效果都是事半功倍的。
================================================
测试人员在测试过程中一定要把业务逻辑理清楚，页面的初始状态不要遗漏测试，要把UI图与app页面进行详细对比：
项目中出现过的漏测情况：
页面说明：页面中有列表键，点击即可加载右侧列表抽屉，列表抽屉分两个tab：所有、我的收藏
bug重现步骤：从页面进入列表，切至我的收藏tab页，收藏列表无内容，关闭抽屉，回到页面，再点击列表按钮，页面异常。
漏测点：测试对该功能需求点有遗漏，没有测到列表按钮每次打开时定位在第一个tab页，导致问题产生。