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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

好的，多谢

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

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

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

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

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