在玩公司游戏的时候，遇到一个偶现 bug：游戏中一个界面，打开后显示的内容是一个玩家列表，但是有时候打开这个界面，里面的玩家列表是空的，等一会儿再看这个界面里面的列表又出现了，虽然没有找到让每一次点开这个界面都可以让列表为空的复现方法，但是我发现在点开这个界面的时候，如果这个界面中有玩家列表，然后挂着这个界面一段时间不管，这个界面的列表就会消失。
个人感觉可能是游戏缓存这块的问题，同时也准备提单，将这个情况告知给技术进行问题排查，发在这里也是想听听各位大佬的意见：1、平时遇到这种偶现的 bug 应该如何进行处理比较妥当 2、在发现这个问题后，如何进一步排查问题产生的原因，思路是怎样的
遇到偶现 bug:
- 记录复现步骤、复现的时间、复现的环境、截图、日志
- 记录客户端的版本信息（如有旧版本就验证下旧版本是否复现 对照下）
- 频率评估，根据发生的频率做 bug 等级判断
- 创建 bug 单：将 1、2、3 记录的信息都写在 bug 单里
- 根据实际情况通知相关人士
想下 bug 的原因
排查 bug 一般就是猜下原因，然后根据原因去逐步排查，你这个是列表显示问题，那么就有可能是以下几种情况：
1. 请求延迟： 本地网络不佳或者服务器网络波动，导致未能及时获取数据
2. 异步加载：网络延迟、服务器响应时间太久、处理回调的时间较长影响数据的及时显示
3. 定时器： 可能开发写了定时更新或者刷新玩家列表，你刚好在刷新的那一刻点进去
4. 内存泄漏导致：卡顿和响应延迟、刷新频率降低、内存回收等
5. 缓存：缓存加载延迟、缓存过期导致显示为空、缓存刷新
那你排查步骤一般就是：
- 先确定下你看到的列表是 H5 还是原生
- 先检查自己本地网络环境和设备性能
- 对比安卓端和苹果端应用是否问题一致（确认下是单端问题还是双端问题，又或者是后台问题）
- 抓包下用户列表的接口，做下接口的基准测试，就看下响应时间和错误率（如果错误率高、响应时间长，找报 bug 给后台）
- 多次复现下客户端的 bug，抓包日志数据
- 报 bug 单给客户端开发，让开发去定位（测试这边更多是把 bug 分给正确的人，描述清楚 bug 的复现步骤，还有贴上你上述对本地网络环境、设备机器型号、后台接口测试、双端复现结果、还有日志） .
我这 P40 遥遥领先的必现重启型问题都不给我解决，这偶现问题解不解决的无所 D 谓
- 发现问题就要记录
- 偶发但不严重的排查优先级降低
- 偶发但严重的要优先花资源排查
- 实在排查不出来，记录风险
至于如何排查，先看能否发现稳定复现的方法，复现不了就根据现象反推，一般偶发的问题和缓存，网络，多业务执行时因为响应不及时顺序错乱，环境等相关。
个人看法：
1、从现象分析，这个列表数据大概率是从服务端获取的，而且不是只请求一次，挂在当前界面，也会实时请求，考虑抓包定位一下 ？ 更高效的方式是问一下客户端开发
2、从业务上考虑这个实时请求是否有必要？当然大概率是需要的
3、搞清楚了数据到底是如何获取的，然后抛开客户端，去测试一下数据获取是否有异常比如接口测试
4、数据来源测了之后，再考虑一下客户端是否需要更完善的异常处理，这个也要结合业务，比如这个列表数据实时获取失败的时候，能不能不刷新？
同游测个人经验：
遇到偶现 bug 怎么处理
1、先开单记录，如果是影响较大的就花时间去处理，影响不大，有时间的时候再去看，因为游测工作量还是挺大的
2、开单是最重要的，避免后续太忙给搞忘了
针对你这个问题，我的想法：
1、先看协议，如果返回的协议是空的，那么找后端反馈，如果返回协议正常但是显示是空的，反馈给前端
2、反馈完如果程序看代码难以修复，需要你稳定复现才能修复的话，就可以问下程序这里处理的逻辑是咋样的，再自己去联想每一步出问题的可能性，再去尝试复现
3、再复现不出来的话，就找程序加日志，看看具体是在哪里有问题
4、复现的时候如果随机概率较高的话，可以拉程序过来坐，复现出来了直接现场给他看就好了
录屏或者录像，提交 Bug 啊