最近加入了徐哥的百人计划第6期，跟随行业其他哥哥姐姐们一起互相学习和成长，有人想要了解一下如何通过看日志来定位问题，分享一下个人的成长经验！
一、前置准备：
-
开发打日志是符合规范的(业务相关日志在单独一个文件里)
个人认为，一条好的日志需要有要素：
- 日志等级
- 线程号
- 时间
- 对应的模块
- 接口请求地址
- 入参
- 出参
- 一些必要的业务描述
- 日志打印最好可以有配置控制，避免打印日志消耗性能（配置最好是有个后台，不要麻烦运维）
-
测试人员应该对业务流程熟悉 （重要）
- 通过绘制业务流程图，可以做到，第一版本可以只绘制自己怎么点
- 大致清楚业务调用关系（不清楚找开发问）
-
测试人员工作的测试环境拥有独立环境系统可以用linux或其他方式查看日志
- Linux系统日志（xshell、SecureCRT……）
- kibanna
- 其他工具
二、阅读整理：
- 打开测试环境Linux服务器到日志路径下，开始查看日志
tail -f xxx.log
- 对着自己画的业务流程图开始点，并整理日志
举个例子：登录功能
-
页面点的效果：
- 从XXX入口点击
- 输入手机号
- 点击获取验证码
- 输入验证码
- 点击登录
- 展示登录后的页面
-
日志里就会这样：
- 进入xxx入口会获取到一些初始化信息（比如微信公众号会有openid的获取）
- 输入手机号之后，获取验证码有请求短信系统，发送请求、结果、业务日志
- 点击登录后，会请求用户中心，判断这个人是否注册
- 账号信息，以及一些标记这个账号登录的日志
-
从这里你可以知道
- 短信发送的接口是什么，以及返回值
- 用户中心登录的接口是什么，以及返回值
- 用户中心获取用户信息的接口是什么，以及返回值
- 以及一些业务文字（比如发送短信、登录之类的）
上述只是一个简单的登录功能，其他功能也可以用这个方式进行整理，其实多阅读后也会记住，经常出问题的部分我一般会专门笔记记录，以及线上出现问题的时候一些问题查找的方法比较复杂，在查完一次之后我也会输出文档总结出来（下次直接看笔记速度快）
更好的日志：
除了上述信息以外哪些还需要打在日志里面会更好呢，有时候是开发为了查线上问题加上的日志（注意是会更好但是日志打太多也会影响性能），排名不分先后
- redis
- MQ消息队列
- session值，cookie值
- 数据库
- 其他接口必要的环境要素（比如微信公众号的appid、openid等）
- 定时任务
三、应用
线上反馈问题，可能是bug可能是上游业务接口返回异常
- 先在手机上尝试是不是必现
- 看有没有手机号、userid、memberid、订单信息等（有就补充吧相关账号信息找出来
- 出问题的业务日志，比如说登录收不到短信
- 找到手机号，看有没有请求短信系统成功
- 没有请求原因可能是（没有获取到openid）、前端卡住了……
- 请求了返回失败了（找短信系统的开发）
四、解答：
- 为什么需要时间
线上排查问题大法，先看时间锁定范围（日志经常根据日期分段），然后关键文字、接口 - 为什么需要线程号
线上排查问题的时候，可以根据一些关键字查到相关信息后，在根据线程号获取整段业务相关日志 - 为什么需要模块名称
一般开发用的，测试有时候也可以针对性查看相关模块日志（grep用）
五、总结：
- 熟悉业务逻辑（看不见的部分也要知道东西从哪里来到哪里去做什么）
- 查看公司wiki（一般有相对完整的接口文档）
- 多看、多整理必要接口，跟进线上问题，是个好的校验自己总结是否有效的方法
- 多问开发，比如这次需求有哪些比较关键的日志他自己加的
