最近加入了徐哥的百人计划第6期，跟随行业其他哥哥姐姐们一起互相学习和成长，有人想要了解一下如何通过看日志来定位问题，分享一下个人的成长经验！

一、前置准备：

1. 开发打日志是符合规范的(业务相关日志在单独一个文件里)

   个人认为，一条好的日志需要有要素：

   • 日志等级
   • 线程号
   • 时间
   • 对应的模块
   • 接口请求地址
   • 入参
   • 出参
   • 一些必要的业务描述
   • 日志打印最好可以有配置控制，避免打印日志消耗性能（配置最好是有个后台，不要麻烦运维）

2. 测试人员应该对业务流程熟悉 （重要）

   • 通过绘制业务流程图，可以做到，第一版本可以只绘制自己怎么点
   • 大致清楚业务调用关系（不清楚找开发问）

3. 测试人员工作的测试环境拥有独立环境系统可以用linux或其他方式查看日志

   • Linux系统日志（xshell、SecureCRT……）
   • kibanna
   • 其他工具

二、阅读整理：

1. 打开测试环境Linux服务器到日志路径下，开始查看日志

tail -f xxx.log

2. 对着自己画的业务流程图开始点，并整理日志

举个例子：登录功能

• 页面点的效果：

  1. 从XXX入口点击
  2. 输入手机号
  3. 点击获取验证码
  4. 输入验证码
  5. 点击登录
  6. 展示登录后的页面

• 日志里就会这样：

  1. 进入xxx入口会获取到一些初始化信息（比如微信公众号会有openid的获取）
  2. 输入手机号之后，获取验证码有请求短信系统，发送请求、结果、业务日志
  3. 点击登录后，会请求用户中心，判断这个人是否注册
  4. 账号信息，以及一些标记这个账号登录的日志

• 从这里你可以知道

  1. 短信发送的接口是什么，以及返回值
  2. 用户中心登录的接口是什么，以及返回值
  3. 用户中心获取用户信息的接口是什么，以及返回值
  4. 以及一些业务文字（比如发送短信、登录之类的）

上述只是一个简单的登录功能，其他功能也可以用这个方式进行整理，其实多阅读后也会记住，经常出问题的部分我一般会专门笔记记录，以及线上出现问题的时候一些问题查找的方法比较复杂，在查完一次之后我也会输出文档总结出来（下次直接看笔记速度快）

更好的日志：

除了上述信息以外哪些还需要打在日志里面会更好呢，有时候是开发为了查线上问题加上的日志（注意是会更好但是日志打太多也会影响性能），排名不分先后

1. redis
2. MQ消息队列
3. session值，cookie值
4. 数据库
5. 其他接口必要的环境要素（比如微信公众号的appid、openid等）
6. 定时任务

三、应用

线上反馈问题，可能是bug可能是上游业务接口返回异常

1. 先在手机上尝试是不是必现
2. 看有没有手机号、userid、memberid、订单信息等（有就补充吧相关账号信息找出来
3. 出问题的业务日志，比如说登录收不到短信
4. 找到手机号，看有没有请求短信系统成功
5. 没有请求原因可能是（没有获取到openid）、前端卡住了……
6. 请求了返回失败了（找短信系统的开发）

四、解答：

1. 为什么需要时间
   线上排查问题大法，先看时间锁定范围（日志经常根据日期分段），然后关键文字、接口
2. 为什么需要线程号
   线上排查问题的时候，可以根据一些关键字查到相关信息后，在根据线程号获取整段业务相关日志
3. 为什么需要模块名称
   一般开发用的，测试有时候也可以针对性查看相关模块日志（grep用）

五、总结：

1. 熟悉业务逻辑（看不见的部分也要知道东西从哪里来到哪里去做什么）
2. 查看公司wiki（一般有相对完整的接口文档）
3. 多看、多整理必要接口，跟进线上问题，是个好的校验自己总结是否有效的方法
4. 多问开发，比如这次需求有哪些比较关键的日志他自己加的

工作不久可能方法较笨，还有其他的请在评论区里留言交流呀～