一般我们是直接通过 code review 来确认重要地方有打印 log 的代码 + 功能测试的时候留意下是不是真的有打印。正常来说一个用户请求或操作，在一个系统内部打印的 log 在 10 条以内，所以人工看工作量倒不会很大。

听你的描述，这种 log 更类似于用户操作或者客户端各类操作的事件埋点？

log 不是用来查问题的吗 为什么还要验证 log

log 记录的正确性要求严格的话还是验证下比较好
客户端产品模拟点击，知道每一步的操作，访问日志断言即可（粗略验证）

理论上可以，但实际上很少有这样做的。

一般保存日志有几种方式：数据库、文件、消息队列消费至 ES；
如果你要验证 log，只需要在执行对应操作后，去检查是否产生了正确的日志（读数据库、文件等）即可。

线上环境应该不会加吧 测试环境有时候用来调试问题会加一些 log 日志

只能慢慢去使用系统，对比 log，搞一个干净的环境，最后摸清源头了，脚本也就出来了

有些 log 是记录用户操作或者是管理员操作之类的，上家公司碰到类似的；当时只能靠手工查询对应的数据表验证；
理想情况下：个人觉得可以一次性操作完后然后查询 log，写一个脚本去验证。

可以，但是估计工作量也很大，因为变量太多，这种情况只能说在固定环境下进行验证。

准确说应该是用户的一些行为记录。不是说 debug 的 log，原谅我用词不当

因为 log 量大，每次都要依次查看，很是费力。所以想问问各位有移动端经验的是怎么做的。

好的，多谢

为啥消息队列都会推送给 ES 原理是什么

感觉你想说的是数据分析，对 log 进行数据分析呢

额， 其实数据分析我们不做，数据分析是服务端有人做，但是我们需要验证发送的数据正确。

其实这里需要关注的是两个点：
1、客户端写 log 的逻辑
2、上传 log 的功能
那么测试方法来了：
1、客户端写 log 使用公共类/方法，因此调用这个 API 即可，然后覆盖各种场景
2、上传功能，这个就是老生常谈了，先确认文件的唯一标准为：文件名 +MD5。如果研发有提供 download/查询的接口直接使用即可；如果没有相关接口接比较麻烦了，测试环境可以直接上服务器确认，或者自己写个 download。发布线上只要确认分支 id，其他可能出问题的也就只有网络和存储服务器了，基本可以认为测试任务完成了。

那这是另一个范畴了，和你的题目差异比较大。。。

可以看看小红书 MTSC 2018 的一个 topic ，介绍他们怎么测试客户端埋点的，做得比较全和自动化。

是这样的，主要是对一些用户行为的分析，用于以后对产品进行改进。由于有太多的变量因素，所以一直找不到有效的测试方法

客户端上传肯定是调用服务器的 api，直接自己写一个服务器的 api，然后让客户端调用，在程序上直接写验证脚本。这样弄一个，以后都可以自动化测试了。而且还可以持续集成。后续测试只需补充用例就可以了。