大神们求助：
APP 应用针对偶发性问题和固定机型（不可能覆盖所有机型）问题有什么方案吗？
问题点：
领导总能发现一些偶发的问题，针对他的机型我们也配置了对应的测试手机，但是也未复现（操作路径一致）后面领导再次演示时又无法复现。
领导发现后直接找开发，开发走查代码后说该模块功能确实有点问题。这种怎么解决。
综上所述：怎么解决偶发性问题？怎么防止此类问题导致领导对测试团队的信任危机?
对于已知的问题，找开发确认下前因后果，做下缺陷分析。如果是测试场景遗漏，补充对应的用例库。如果是固定机型问题，可以一个季度/半年去找三方做下比较全面的兼容测试。
IOS 的话其实还是比较容易覆盖的，因为机型就这么多，不像安卓五花八门的，按不同机型的分辨率，不同的 IOS 版本，还有手机型号
像老板的这种情况，可以加点 log，一旦出现偶现的问题方便跟踪
感谢你的建议，已和开发聊过，他并未找到问题原因，只是走查代码时发现不合理的地方，将不合理的地方改了一下，但不知是否和此相关，后面他和我反馈感觉不是那块。由于无法复现开发自己也不知道修复了没。
要不。。。你们众筹给领导换部新手机
首先，存在偶发性问题，说明代码逻辑上还存在一些漏洞，在一些极端场景下可能出现问题。只是这类场景出现条件苛刻，且会引发其出现的关键因素并非人为操作路径，所以很难复现。
针对这类问题，核心是需要获得领导出现此问题时，足够详细的信息（比如日志），帮助进行定位处理。如果是崩溃类的还相对容易，接入崩溃捕获平台即可（如 bugly 等）；但如果是功能类问题，可能需要基础平台侧想办法开发一些可以手动捞取指定手机上，应用内部打点日志信息的工具，结合足够详细的日志打印信息，才能有效辅助定位问题。
另外，偶发性问题测试无法在上线前发现，这个其实很难解。本质上，偶发性问题大多出在某一段逻辑不够严谨的代码中（如写了 if 没有写 else，针对 IO 操作没有有效捕获异常），或者是某个 sdk 使用姿势不正确，甚至是多线程情况下没有保障数据读写的线程安全引发问题。这类问题由于本身出现概率低，条件苛刻，所以正常测试中实际上很难发现，就算发现了也很难复现进而得到有效的修复和确认修复有效。要避免这类问题，个人能想到的是：设计层面上能充分考虑到后续可能遇到的所有情况 + 代码编写上有足够详尽的单元测试来保障每个单元的逻辑足够严谨完善 + 足够完善的 code review 避免单人思路受限 + 足够的线上灰度时间让代码接受真实用户的洗礼。这在国内互联网类业务大多研发时间很有限的状态下基本不大可能。所以，其实一般这种情况，老板自己都无法稳定复现的问题，其实老板也不会特别苛责为啥测试完还会出这样的问题。
1、单元测试（这个执行起来比较困难）
2、云真机测试（针对特殊机型）
3、线上灰度
偶发性问题应该一直都是业界比较麻烦的问题， 测试研发都头疼。
老板发现偶发性问题，开发走查代码发现该功能模块确实有问题（只是猜想），开发也不能确定是问题的根源，这种情况需要老板手机出问题时的场景，日志来定位问题。
上面大家说的兼容覆盖、代码逻辑覆盖自然是解决问题的有效措施，但在项目在范围、时间、成本固定的情况下，落地难度谁用谁知道。@ 今晚打老虎 总结的很好，短时间内要达到效果，可以从这 2 个本质问题入手：
1.怎么解决偶发性问题？
调整测试用例方法，分析领导这种特殊干系人以及用户的真实使用场景，针对性补充测试场景。但这只能降低大问题的出现概率，程序除了自身代码有漏洞，外部运行环境也可能有问题，没人能彻底解决，除非你有无限的时间和资源。
2.怎么防止此类问题导致领导对测试团队的信任危机?
首先应该分析出老板这出现问题的客观原因，同时从问题 1 可以看出，我们此时能做的是主观上反思并拿出态度，然后在从客观原因中划出边界、甩出黑锅。建议以产品核心利益为中心，与上下游一起，确认核心覆盖范围并达成共识，这样起码可以保证出问题的部分，不会造成太大的影响，而且超出部分出现问题，也不会说是测试一方的问题。
针对偶发性问题，希望提前挖掘出来一般 2 种做法：遍历测试、探索测试。这些测试，都可以引入各种故障异常的条件，比如磁盘打满、弱网等。
那假设确实无法提前挖掘，想后置复现出来怎么做：流量回放（服务端流量 + 移动端操作的录制与回放）、埋点跟踪、日志回捞…… 利用这些手段去缩小排查范围，最后还是要人肉找出问题。
不要想着有什么神仙方案能全自动化，太不切实际，更多是经验导向，可能这个问题一出现，基于经验和对系统的熟悉就能猜出大概是哪几方面的排查思路。
固定机型，不过是少了一维变量，转化一下就是固定机型下的偶发性问题罢了，同样的思路。