背景：
为什么会问这样的问题，是因为楼主 (后续简称 jb) 工作环境有关，jb 觉得，需求编写 -- 编码 -- 测试 -- 上线 -- 数据分析（问题跟踪），这一个环节，后面 3 个都是需要测试介入的，但是具了解到类似百度等大公司在问题跟踪这方面是有专门一个部门去处理，是不需要测试人员特意介入，但是 jb 这是小公司，所以只能对应测试同学负责；
大至 app 产品，小至一个需求，如何衡量用户是否热爱该产品或者功能，基本上都是通过渗透率来衡量，但是俗话说的好，人是无法满足的，取悦了这一批用户，另外一批用户就会有意见，因此，用户反馈就成了一个产品优化的一个重要节点；用户反馈内容有很多，大部分用户反馈内容分为 5 类：
- 喷子
- 热情用户
- 反馈 BUG
- 无厘头
- 表达自身感受
这里就讨论反馈 BUG 这一类；
现状：
大部分主流 app 都会自带反馈问题渠道，比如 QQ，微博等，基本上反馈问题界面都是要求填写问题内容，但是对于联系方式（手机或者 QQ 等）则不做要求；
因此得出问题反馈有两类：
- 一类是只有问题
- 一类是有问题且有联系方式；
通常跟用户沟通都是通过 QQ 的方式，即使用户提供的是手机号码，最终还是通过 QQ 的方式进行沟通；
在沟通的时候，就会遇到 4 种情况：
- 用户问题依然必现，但是内部无法重现；
- 内部问题重现；
- 用户此时无法重现，但是有一定概率出现；
- 用户仅出现一次
jb 的疑问就在这里，对于用户无法重现的问题，社区额朋友你们是怎么处理的？
jb 去咨询过其他公司的同学，都基本是，尽量重现，如果还是不能重现，就不管了；但是楼主觉得这样处理不太好，因为这样处理并不能让问题闭环，因为一个用户能出现，其他用户也能出现，只是可能其他用户不想反馈问题而已；
脑洞：
因此楼主脑洞了一下，想到 2 种办法：
- 了解到蛮多 app 都是内部通道命令,比如类似于安卓系统的开发者模式,需在关于手机的版本号点击几次,才会显示入口的功能,点击后就能开启 app 对应的功能，然后又调试功能或者信息收集功能引导用户使用，然后获得更多信息，便于解决问题 ----------- 但是这样做就会把所有调试等功能都暴露出来，部分可能涉及到 app 自身的信息，如果黑客等发现这一通道，可能会做其他小动作；
- 为了避免 1 方法里的情况，想到就是把调试功能做成单一的通道，虽然可能会有几十个调试命令或者功能，但是至少能确保，哪些是能提供给外部使用，哪些是内部使用的；
最终整理下问题吧：
- 对于用户无法重现的问，但有联系方式，该如何把问题闭环？
- 对于用户无法重现的问题，无联系方式，如何把问题闭环？
谢谢大家~祝大家新年大吉，工作顺利，身体健康，阖家幸福~
具了解到类似百度等大公司在问题跟踪这方面是有专门一个部门去处理
惭愧地很，我们是不仅测试，开发都要参与用户反馈的问题处理，全民参与。问题到你手上了，你就得处理，无论是能重现还是不能重现，必须有一个答复，即便这个答复有可能不正确，先把闭环完成。
我们排查问题的途径很多：
- 通过用户的描述重现
- 不能重现，查询用户的日志，我们有算不上完整的日志，但是还是能排查出很多问题。
但是用户的状况实在太多，有些实在太过离奇的问题其实也只能无疾而终。
#1 楼 @Lihuazhang这里想咨询下，日志，打点是可以去打，但是一般从产品的角度来说，只会关注并提出产品相关的统计，导致上线后却没法通过这些统计发推问题，也许后续版本会新增部分异常统计继续进行信息收集，但是这存在一个时间成本的问题，如果没有其他限制，大可以不停迭代发版本出去收集信息，但现实是这样处理搞不好会导致用户流失，所以想了解下有没有一些能短时间内（比如几天内都算）能确定问题或者快速收集到日志的一些手段，想借鉴借鉴~
当然，如果能通过查询日志就能排查问题，也说明对应的同学对相关统计点都比较熟悉，这也是一个很快的办法，但感觉是在日志比较完善的情况下才能这样分析~
收集的描述中最好让用户选择是否必现。。我们是除了 a 类和充值掉单这类的，其他都次日回复。根据用户描述查数据库行为日志。如果没有的，服务端判断是否要加，要加的也是等待周更新一起出去。至于反馈给用户就是客服做得了。客服收集问题测试验证问题定级分发开发者次日答复客服_约定修改时间...
—— 来自 TesterHome 官方 安卓客户端
有一些专门做 app 测试的公司，比如听云，可以满足您的需求（真不是诚心做广告，实在是恰好满足）
羡慕呀，我们公司不再现的就放弃了。 没有日志可以让我们进行排查。尤其是各种莫名其妙的闪退 bug。
#6 楼 @lunamagic 没有日志，应该是想办法获取日志，包括联系用户等，jb 做过半年类似客服的工作，每天就是在各种论坛，微博、QQ 等地方跟用户沟通，从效果上看，还是有蛮多突破点的，所以，应该是要想办法获取更多的日志信息，只有尝试了，才知道这个问题能否闭环，jb 的痛点也在这，因为跟用户交流比较耗费时间，用户不一定长期在线，或者用户晚上在线，我们下班了，就错过了配合时机了，所以 jb 也是来看看各位有没有更高效的办法处理这类事情
#4 楼 @jiazurongyu 客服同学的确可以做很多东西，比如问题分类，问题初验证，联系用户等等，但是实际 case by case 的时候，还是需要测试同学跟进的，因为客服的专业性没测试同学的强~
不停迭代新增日志或者统计是一个办法，但是时效性是个硬伤；
行为日志是可以做，但是感觉对于 app 来说，去做行为日志的话，最大的瓶颈应该是服务器压力跟解析速度 + 统计点是否充足，这估计要投入不少成本进去。。。
求更多的同学看到并且一起讨论问题，相信并不止 jb 一个人遇到该问题。。
1.测试直接联系用户一对一处理
2.记录本地日志，协助开发解决
目前我遇到是这样解决的
几天过去了，jb 回头看自己提问的问题，是想了解业界针对用户反馈问题的跟进手段有哪些，从目前来看，其实业界大部分都是统一流程的，可以联系上的用户则 one by one 跟进，联系不上的，通过分析收集到的日志来分析问题~
jb 自己把自己的问题深挖一下，其实为什么要了解业务对这种情况的跟进手段有哪些？其实是因为 jb 有痛点：
1）从联系用户到联系上用户到问题沟通等，中间有时间成本，而且经常去跟进问题的话，基本上就没时间去做其他事情了，每天都是跟用户打交道；
2）千辛万苦联系上用户且用户端问题必现，但是因为一些条件不满足，比如用户没 root 权限导致拿不到 anr 日志等等，就导致无法继续跟进，这放佛就是煮熟的鸭子飞走了，好心塞~
因此问题重点可能就变成了，如何在不需要联系用户的情况了解用户的操作并发现问题点；
答案是有的，正如@Lihuazhang所说的 -- 日志 fejx9，这当前前提是需要收集大量的类似用户行为日志；
那除了行为日志，没其他了？答案还是有的，貌似这 2 年，安卓聊的很热的有组件化，热修复等功能，jb 觉得热修复是组件化的一个节点吧，那是否可以把一些调试功能或者收集日志的功能通过组件的方式下发到用户的 app 上等等，都是有无限遐想的~
其实 jb 内心是希望，离用户更进一步，目前的方式，自己感觉是跟用户的交流依然停留在表面，想用户用的更爽，与用户距离近了，才能更加了解用户~
后续简称 jb==
#15 楼 @testerwan 
工作上已习惯了，哈哈哈哈
，但换个角度想，联系用户、调试包等是最终手段了，从测试角度来说，因丰富跟进问题的手段才是最重要的~