新手测试工程师的Linux：从连服务器到定位Bug，这么多就够了

相信很多新手跟我一样会问：测试又不是运维，为什么要学Linux？我学完之后发现，不会Linux，连Bug都查不了。

一、测试人员为什么要学Linux？

刚开始学的时候我也疑惑：测试不是点点点吗，跟Linux有什么关系？

学完才明白，测试用Linux主要干两件事：

说白了，开发跟你说“服务器报错了，你去看看”，你不能说“我不会连服务器”吧？

二、实操：用Linux查日志定位Bug

下面是我模拟的一个场景，完整走了一遍“从连服务器到抓Bug”的流程。

场景设定：开发说测试服务器的应用报错了，让我去看看。

第1步：连上服务器

用FinalShell等工具连上服务器，需要四个信息：

第2步：确认当前位置

连上之后，先输入：

pwd

作用：查看当前在哪个目录。

第3步：进入日志目录

cd /var/log

作用：切换到日志存放的目录。Linux的日志通常放在/var/log下。

第4步：查看有哪些日志文件

ls

作用：列出当前目录下所有文件。

第5步：实时查看日志

tail -f app.log

作用：实时滚动查看日志的最新内容。-f是 follow 的意思，会一直刷新。

💡为什么不用cat？
生产环境的日志文件可能几十个G，直接cat会把整个文件读出来，终端直接卡死。tail -f只显示最新内容，安全又高效。

⚠️我踩过的坑：

第一次用tail -f的时候，日志刷得飞快，我根本看不清哪一行是报错。而且我盯着看了好久，发现日志在刷，但报错只有最开始那几行，刷过去的全是重复的INFO信息。

后来我学乖了，两种做法：

1. 先停掉实时刷新：Ctrl + C退出，再用grep一次性抓

2. 用管道过滤：tail -f app.log | grep "ERROR"，只显示ERROR级别的日志

第6步：退出实时查看

看到满屏都是没用的信息，按Ctrl + C退出。

第7步：精准抓取报错信息

grep "Exception" app.log

作用：从日志文件里专门把包含“Exception”的行抓出来。

也可以搜其他关键词：

grep "ERROR" app.log grep "NullPointerException" app.log

拿到报错之后，怎么判断问题在哪？

grep抓出来的报错，直接给开发或者自己也可以会先做三步判断：

第1步：看异常类型

第2步：看报错时间和频率

• 是刚发生的，还是一直在报？

• 用grep "ERROR" app.log | wc -l统计报错条数

第3步：看报错上下文

grep -A 5 -B 5 "Exception" app.log

• -A 5：显示报错行后面5行

• -B 5：显示报错行前面5行

很多时候，真正的错误原因藏在报错行的上一行或下一行，只看报错那一行反而看不出问题。

三、其他高频命令

除了查日志，还有几个命令测试也必须掌握：

3.1 查看系统进程

ps -ef | grep java

作用：查看所有进程，然后筛选出跟 java 相关的。

测试场景：怀疑服务没起来，可以用这个命令确认进程在不在。

3.2 查看端口占用

netstat -anptu | grep 8080

作用：查看端口占用情况。

测试场景：接口请求不通，可能是端口没开，用这个命令确认一下。

3.3 强制杀死进程

优先 kill 进程号，kill 无效再用 kill -9

kill -9 12345

作用：强制结束进程号为 12345 的进程。

测试场景：服务卡死了，进程关不掉，用-9强制杀掉。

3.4 查看服务器IP

ifconfig

或者：

ip addr

作用：查看服务器的IP地址。

四、Linux高频命令速查卡

口诀：进目录、看日志、搜关键词、查进程、看端口、杀进程