测试-问题排查

前言

每周四是我们组开周会的时间，会对上一周的工作进行总结，也会对下一周的工作做一些计划。其中值班是一项比较看天的工作，也许你值班的那一周相安无事，也许会被无数人@查问题。总之就是值班是个苦差事。
我们值班有都要负责哪些东西呢？归根到底就是影响我们测试进度的所有问题！！！
这里我们先进行一下归类
按照部门：内部和外部
按照类型：业务和环境
这里只是初步的进行分类，但是这个分类缺失无用的，因为给你抛过来一个问题时你是很难第一时间就知道这是个什么问题。所有我们需要一个排查问题的方法论（即你的套路）。这里我分享的只是我的套路，不一定是对的，但是却帮助我解决了许多问题。

方法论

我们以一个实际问题为例，退款touch页面加载失败。（我所负责的是国内机票出退改业务，这是业务量最大的入口，所以以这个为例）。

第一条：确认这是一个业务问题吗？

遇到这个问题，我已经确定了这不是一个业务问题！因为页面加载失败没有什么特殊的业务。但是比如一个按钮的展示，你首先需要确定这个按钮该不该出现在这个位置，并且有没有权限展示，这里面就存在两个业务问题。所以遇到这种问题，第一点是确定是否是业务问题？如果是请耐心解答业务问题，这里面更推荐将所有常见业务问题整理成相关wiki，直接扔出wiki，减少沟通成本！如果不是那就继续排查。

第二条：排除beta环境搭建带来的影响

是不是没有连接到测试环境？可能这条不一定适用所有情况，但是因为我们的beta环境搭建，带来了这个问题，所以必须先去check一下。
我们的app需要配置beta环境，我们的touch需要配置ng、squid代理、host配置等等。这些配置是否都访问到了对应的服务上。

第三条：查看tomcat或node日志

到这里，你需要了解代码，并且需要查看日志了。

ng

我们会使用ng作为反向代理服务器，所有需要检查ng的配置，以及查看log中upstream的实际机器。

node

对于node日志，我们的代码里会对所有的http接口的url 、入参、出参都打出来，你需要确定是哪个接口有问题，并且根据url，你可以通过ng的配置找到对应的服务，这里面会有转发配置错误、service服务器5xx问题等情况。

tomcat

如果是tomcat异常，通过有四种情况：服务不在线；代码问题；数据库问题；数据问题
但是只有两种解决思路，因为除了当前工程不在线，其余都需要真正看日志。

当前服务不在线

重启服务，并且保证你的心跳机制能够检查到服务在线。

其他问题

这个时候会有异常信息，除非你的代码里没有打印异常栈，那就是一件比较操蛋的事情了。
通过异常栈可以排查到问题，这里你需要了解如何查看异常栈，本周五组内开会排查问题，还有许多同学定位问题慢，究其根本就是不会看异常栈的问题。
首先，你要关注这是哪个Exception，优雅的代码就是你通过异常的名字就能知道这是个什么问题。
其次是cause by，它会告诉你是哪一行的问题，接着你可以按照调用关系去看下一行的代码，问题就出现在这里。

总结

说到底，如何排查问题就是两点：一是确定这是不是业务问题；二是按照你的调用关系逐级排查。