做软件测试这些年我越来越觉得Linux命令是和测试理论同等重要的硬功夫。不管是功能测试、接口测试还是性能测试只要你的被测系统是部署在服务器上的终归绕不开“上服务器看一眼日志、查一下进程、看看磁盘空间”这些操作。尤其是现在很多公司的测试环境都是Linux容器或虚拟机你会不会用命令直接决定了排查问题的效率。这篇文章不打算给你堆砌一份面向运维的完整命令大全而是想站在测试人员的实际工作场景里把那些高频使用、能真正解决测试问题的Linux命令整理出来每个命令都会配合我实测过的运行结果方便你对照着看也可以直接抄去用。1. 测试环境里先抓稳文件和目录操作1.1 穿梭路径cd、pwd、ls 的日常组合测试工作里最烦的其实不是复杂的逻辑而是“目录都找不到”。我一进测试环境第一件事永远是pwd确认当前路径然后用ls看目录里有什么。很多测试新手在Windows上被图形界面惯坏了到了Linux里一输入命令就心虚其实路径就是两件事你在哪、你要去哪。pwd会打印当前工作目录的绝对路径比如$ pwd /home/tester/app/logsls不只是列出文件名它有几个参数在实际排查中特别有用。ls -l能显示权限、属主、文件大小和修改时间ls -lh会把大小显示成人类易读的K、M、G单位ls -lt按时间倒序排列方便你找最新修改的日志文件。我自己常用的组合是ls -lht先看最新的文件是哪个再配合后续的日志命令去查看。cd切换目录时有一个很容易被忽略的点cd ..是返回上一级cd ../..是上两级cd -是回到上一次所在的目录。多个日志目录来回切换的场景下cd -真的能省不少事。很多人习惯自己手动敲绝对路径结果敲错一个字母被报错弄得心烦意乱其实只要先cd /home/tester/app/logs进了正确的根目录再用相对路径一层层往下走出错概率会低很多。1.2 文件复制、移动、删除的几个关键细节测试人员经常要把测试包从一台机器拷贝到另一台或者把旧的日志清理掉。cp、mv、rm这三个命令表面上简单但实际上有几个细节如果不注意是会出事的。复制目录必须加-r这是测试新手的经典错误。比如把整个config目录复制成备份$ cp -r config config_bak $ ls -l drwxr-xr-x 2 tester tester 4096 4月 10 10:23 config drwxr-xr-x 2 tester tester 4096 4月 10 10:23 config_bak如果你忘了-r报错信息是cp: omitting directory config这个报错本身就是提示说明目录不会被复制只是被跳过了。移动文件用mv它的好处是同一个文件系统内移动速度很快代价只是改个目录项。但跨文件系统移动的时候它实际上是“复制删除”的过程对于超大日志文件来说会明显卡顿这个心理预期要有。删除文件就要特别谨慎了。rm -rf这个组合是每个Linux用户都听说过的风险命令-r表示递归删目录-f表示强制删除不提示。我个人的习惯是删除前先用ls确认路径或者干脆先mv到一个临时目录确认没问题再删。尤其是在测试环境里曾经出现过同事手滑把log目录拼成local目录一条命令下去整个环境配置文件全没了。宁可多敲一个ls也不要拿rm -rf去赌自己的手速。mkdir -p也是测试中特别实用的参数。它会自动创建不存在的上级目录比如$ mkdir -p /home/tester/reports/2025/04 $ ls /home/tester/reports/2025/04如果不用-p前面的2025目录不存在时会直接报错你会陷入“要先创建一级再创建二级”的笨拙循环。2. 日志排查是测试的日常grep 和 tail 最常用2.1 实时跟踪日志tail -f 的“现场直播”测试工作中最刚需的操作就是在系统运行的时候实时看日志。tail命令专门用来查看文件末尾的内容默认查看最后10行。最经典的是tail -f它会持续追踪文件内容的变化新写入的日志会直接滚动出来效果跟“直播”一样。比如启动测试服务后在另一个终端窗口里执行$ tail -f /home/tester/app/logs/app.log 2025-04-10 10:30:01.123 INFO [http-nio-8080-exec-1] com.demo.controller.UserController : 用户查询请求, userId1001 2025-04-10 10:30:01.456 DEBUG [http-nio-8080-exec-2] com.demo.service.UserService : 查询数据库耗时 12ms 2025-04-10 10:30:02.000 WARN [http-nio-8080-exec-3] com.demo.config.RateLimitFilter : 接口访问频率超限, ip192.168.1.88按下Ctrl C退出跟踪模式。这个操作在排查接口报错、观察异步任务执行情况、确认消息队列消费是否正常时都是第一选择。还有一个变体是tail -n 100表示显示最后100行适合不想滚动太多、只看末尾部分日志的场景。如果你不想一直开着终端“直播”可以用tail -n 200 app.log /tmp/last200.log把最后200行日志保存到临时文件再慢慢分析。反正原则就一条先定位日志文件再快速提取末尾内容别一上来就打开整个日志文件看几GB的日志文件用编辑器打开基本就卡死了。2.2 grep 过滤日志从“大海捞针”到“精准命中”日志文件一大tail就不够了必须配合grep做内容过滤。grep是我在测试环境里使用频率最高的命令没有之一。它的核心逻辑就是“按关键字搜索文本内容”并输出包含关键字的行。最基本的用法是搜索某个错误关键字$ grep ERROR /home/tester/app/logs/app.log 2025-04-10 09:45:11.220 ERROR [http-nio-8080-exec-5] com.demo.service.OrderService : 订单状态更新失败, orderId20250410001 2025-04-10 09:48:37.891 ERROR [http-nio-8080-exec-7] com.demo.service.PaymentService : 支付回调验签失败, transactionIdTXN000123456实际测试中更常见的是“多个关键字组合过滤”我需要同时满足“某个接口”和“报错”两个条件。这里我用的是grep -E或者管道符组合比如$ grep OrderService app.log | grep ERROR第一个grep先筛出包含OrderService的行第二个grep再筛出包含ERROR的行两次过滤叠起来就得到精确结果。这条命令看着简单但在排查问题时的价值极高比你在几千行日志里用肉眼找不知道高效多少倍。还有几个参数值得记住。grep -i忽略大小写适合搜索的单词大小写不确定的情况grep -v反向匹配过滤掉包含某个关键字的行比如grep -v DEBUG可以排除调试日志grep -A 5 ERROR表示匹配到 ERROR 后额外输出后面5行内容这在做错误上下文排查时特别有用因为很多报错并非单行而是需要看后面的堆栈信息才能判断原因。平时排查问题我还会用grep -c统计错误出现的次数判断是偶发问题还是必现问题。比如$ grep -c NullPointerException app.log 17这个数字一旦出现基本就能判断这是个高频异常不需要再去逐行数了。2.3 定位日志文件的辅助命令find 和 file有时候你根本不知道日志文件放在哪尤其是第一次接手一个不熟悉的测试环境。这时候find命令就派上用场了。它能按文件名、路径、时间等条件查找文件。比如我要找一个所有以log结尾的文件$ find /home/tester/app -name *.log /home/tester/app/logs/app.log /home/tester/app/logs/error.log /home/tester/app/logs/access.log如果记不清服务日志是在/var/log下还是在应用目录下可以用find / -name app.log 2/dev/null从根目录全盘查找2/dev/null是把权限不足的报错信息丢弃掉不然满屏的Permission denied会把有用结果淹没掉。file命令则是查看文件类型的偶尔看见一个扩展名不明确的日志或数据文件直接file filename就能看出它是文本文件、压缩文件还是二进制文件。比如$ file app.log app.log: ASCII text $ file app.log.gz app.log.gz: gzip compressed data, was app.log, last modified: ...这个命令的作用是帮你判断某个文件能不能直接vim或cat查看还是说它是个压缩文件需要先解压对测试人员来说属于高频辅助工具。3. 测试服务器上的进程和性能监控3.1 用 ps 和 top 快速定位异常进程排查后端问题时订单处理变慢了、接口超时了第一反应往往是看看服务器上的进程是否异常以及CPU、内存占用率是不是飙高了。ps是进程查看的经典命令它能列出当前系统中的进程快照。用得最多的组合是ps -ef它显示所有进程的完整信息包括UID、PID、父进程PID、CPU占用、启动时间、执行命令等。如果你要查某个特定的服务进程直接配合grep$ ps -ef | grep java tester 12345 1 0 4月09 ? 00:23:45 /usr/lib/jvm/java-17/bin/java -jar demo-app.jar tester 12378 12345 0 4月09 ? 00:05:12 /usr/lib/jvm/java-17/bin/java -jar demo-app.jargrep java会连自己这个grep命令本身也匹配出来所以经常会在结果最后看到一条grep --colorauto java这是正常现象不用觉得奇怪。如果你只关心某个服务的进程ID可以用pgrep -f demo-app.jar它直接输出PID干净利落。在写脚本或需要kill某个进程时这个命令尤其方便。top命令则是“动态版”的进程监控它会每隔几秒刷新一次展示系统当前的CPU使用率、内存使用率、负载均值以及各进程按CPU占用率排名的实时列表。进入top界面后按P键按CPU排序按M键按内存排序按q退出。比如你在压测过程中看到某个进程CPU占用率一直是100%那基本可以断定这个接口的实现有性能瓶颈或者代码里出现了死循环。3.2 端口和网络连接排查测试过程中经常遇到“服务启动了但接口访问不通”的情况。这时候第一件事就是确认服务端口到底有没有在监听。netstat -tlnp或者ss -tlnp是查看端口监听状态的核心命令$ netstat -tlnp | grep 8080 tcp6 0 0 :::8080 :::* LISTEN 12345/java看到LISTEN状态且最后关联到12345/java说明服务确实在监听8080端口。如果这里没有任何输出说明服务可能根本没起来或者被别的进程占用了端口需要进一步排查启动日志。如果是外部请求不通还需要看连接是否建立。ss -tn可以列出所有已建立的TCP连接统计某个IP的连接数时可以配合awk做计数。比如压测的时候想看看当前并发连接数$ ss -tn | awk NR1{print $5} | awk -F: {print $1} | sort | uniq -c这串命令的意思是把所有TCP连接的对端IP提取出来再做去重统计得出每个来源IP建立的连接数。这用来验证压测流量是否打到了被测服务上非常直观。3.3 磁盘空间和内存使用快速排查测试环境跑一段时间后最容易出现的资源问题就是“磁盘满了”。磁盘满会导致服务写日志失败、消息队列堆积、数据库事务无法提交一系列连锁故障会让人非常头疼。所以每次环境有问题我基本都会先看一眼磁盘使用率$ df -h 文件系统 容量 已用 可用 已用% 挂载点 /dev/vda1 50G 45G 2.1G 96% /看到96%基本就不用再猜了先清理空间再说。如果要精确定位哪个目录占的空间最大用du -sh /home/tester/app/*$ du -sh /home/tester/app/* 248M /home/tester/app/bin 1.2G /home/tester/app/logs 36M /home/tester/app/conf日志目录只用了几个星期就涨到了1.2G这就是磁盘空间的主要消耗来源。测试环境的日志建议定期做清理或压缩或者配置日志轮转策略否则迟早会炸。内存方面free -h是最直接的工具$ free -h total used free shared buff/cache available Mem: 7.6G 4.2G 1.1G 128M 2.3G 2.9G Swap: 2.0G 512M 1.5G这里真正有意义的是最后一列available它表示在不触发交换的前提下还可以分配给新进程的内存大小。free的数值小不要紧buff/cache会随内核策略自动释放所以判断内存吃紧要看available而不要只盯着free。4. 文本处理三剑客sed、awk、sort/uniq 的测试妙用4.1 sed批量替换和精准截取日志测试人员拿到一批日志或者一批测试数据后经常要做格式化处理。sed是流编辑器它擅长做“按行处理”的替换、删除和插入操作。最常见的用法是全局替换某个关键词比如我想把日志中的DEBUG全部改成TRACE但不改变原文件内容、只输出到屏幕可以这样写$ sed s/DEBUG/TRACE/g app.log | head -5 2025-04-10 10:30:01.456 TRACE [http-nio-8080-exec-2] com.demo.service.UserService : 查询数据库耗时 12mss/旧内容/新内容/g中的g表示每一行内所有匹配都替换而不是只换第一个。如果你确认替换无误需要写回原文件则用sed -i s/DEBUG/TRACE/g app.log。-i是直接修改文件操作前一定要先备份这个参数是“不可撤销”的。另一个高频场景是按行号截取文件内容。比如我想看日志文件中第1000行到第1010行的内容$ sed -n 1000,1010p app.log-n表示不自动打印所有行p表示打印匹配的行。这个用法在分析某个时间点前后的日志片段时极其高效不用打开整个文件慢慢滚动。4.2 awk按列提取字段做数据统计awk在测试工作中最核心的价值是“按列拆分文本”。日志格式如果比较规整用空格或制表符分隔那么awk能轻松提取出你关心的部分。比如前面我们查进程的那个命令ps -ef | grep java输出中第二列是PID。如果我想把PID和启动命令都提取出来可以写$ ps -ef | grep java | grep -v grep | awk {print $2, $8, $9} 12345 /usr/lib/jvm/java-17/bin/java -jarawk默认按空白字符切分每一行$1是第一列、$2是第二列依此类推。print后面可以拼多个字段逗号会自动补一个空格。这个极简用法就已经能解决测试工作中大量“提取信息”的需求了。如果日志里的时间字段和消息字段需要重新格式化awk也能做到。比如我想把下面这行日志的“日期级别消息”三部分提取出来$ echo 2025-04-10 10:30:01.123 ERROR xxx | awk {print $1, $3, $4} 2025-04-10 ERROR xxx不要在awk里做太复杂的逻辑测试工作往往只需要临时提取几个字段复杂处理交给脚本更稳妥。4.3 sort 和 uniq统计重复项快速判断数据分布排序和去重统计在测试中主要用于两类场景一类是验证接口返回的数据是否有重复另一类是统计某个关键字出现的次数。sort按字典序排序uniq去重并统计连续重复的次数。关键是uniq只处理“相邻重复”的行所以必须先sort再uniq顺序反了统计结果就不对。比如统计日志中出现过的接口路径次数$ grep GET /api/user app.log | awk {print $7} | sort | uniq -c | sort -nr 32 GET /api/user/info 18 GET /api/user/list这个组合非常经典grep先筛出包含关键字的行awk提取第7列请求路径sort把相同路径排在一起uniq -c统计次数最后sort -nr按次数从大到小排列。这样一份“接口调用频率排行”就出来了用来分析压测流量的分布情况、判断哪些接口被测得最多都很有参考价值。sort -nr里的n是按数字大小排序r是倒序。如果你漏写了n结果会变成字典序10会排在2前面直接得到错误结论这个细节必须牢记。5. 打包解压、权限管理和系统信息查询5.1 tar、zip、unzip测试包部署必备技能测试环境部署的时候最常见的交付物就是一个压缩包。后端给的测试包可能是demo-app.jar前端资源可能是dist.tar.gz文档可能是docs.zip。你必须要熟练掌握解压压缩的全部套路。tar命令基础的压缩和解压格式一定要背下来$ tar -czvf demo-app.tar.gz demo-app/ # 压缩目录为 tar.gz $ tar -xzvf demo-app.tar.gz # 解压 tar.gz-c创建归档-x解压归档-z使用 gzip 压缩-v显示过程-f指定文件名。如果你解压时看到tar: ... 无法 open: 没有那个文件或目录大概率是-f后面的文件名写错了或者文件根本没在当前目录。tar的参数顺序其实不用死记但-f必须放在最后并且后面跟文件名这是很多新手踩过的坑。对于.zip文件用zip压缩、unzip解压$ unzip test-reports.zip Archive: test-reports.zip creating: test-reports/ inflating: test-reports/index.html如果你想解压到指定目录用unzip test-reports.zip -d /tmp/reports。这里有个小技巧unzip -l test-reports.zip可以不真正解压只查看压缩包内有哪些文件适合在解压之前先确认内容是否是你想要的避免把一堆文件乱解压到当前目录。5.2 权限基础chmod 和 chown测试环境里经常遇到“文件没权限”的报错比如服务启动时提示Permission denied或者打开日志文件时提示权限不够。这涉及到Linux的权限模型每个文件有三个权限位读、写、执行分别对应三类用户属主、属组、其他用户。chmod用来修改权限最常用的数字表示法里4代表读、2代表写、1代表执行。所以chmod 755 script.sh的含义是属主拥有读写执行权限4217属组拥有读和执行权限415其他人拥有读和执行权限415。如果某个文件是别人上传的你只有查看需求但被挡住了一个临时办法是把其他用户的可读权限打开$ chmod or app.log $ ls -l app.log -rw-r--r-- 1 tester tester 1024 4月 10 10:23 app.logchown用来修改文件属主比如把文件归属改给当前部署用户$ sudo chown tester:tester demo-app.jar测试环境里的 sudo 权限通常需要申请大家记得别天天想着乱用 sudo而是先看看是不是自己的文件权限问题。5.3 系统信息uname、hostname、uptime 排查环境差异测试环境里出现“本地好好的服务器上报错”的情况时经常会需要对比操作系统差异。uname -a能查看内核版本、主机名、处理器架构等信息$ uname -a Linux test-server-01 5.15.0-91-generic #101-Ubuntu SMP ... x86_64 x86_64 x86_64 GNU/Linuxhostname则直接输出当前服务器的主机名在同时操作多台测试服务器时这个命令能帮你确认自己是不是登录错了机器别小看这个操作我见过不少人在错误的服务器上重启服务最后折腾半天才发现环境搞混了。uptime显示系统运行时间和负载均值$ uptime 10:45:01 up 12 days, 3:22, 2 users, load average: 2.01, 1.85, 1.62load average后面的三个数字分别表示过去1分钟、5分钟、15分钟的系统负载。如果1分钟负载远高于5分钟和15分钟说明系统刚刚经历了一波压力如果长期大于CPU核数说明系统可能一直处在过载状态。测试性能问题的时候这几个数字能起到快速判断的作用。6. 常见问题与排查技巧实录6.1 高频问题速查从现象到命令的对应关系在实际带新人和排查问题的过程中我总结了一些出现频率极高的问题场景。下面这个表格基本上可以当成测试环境首发排查清单来用。现象优先排查命令可能的结论接口超时、请求无响应top、free -hCPU/内存资源耗尽或进程卡死日志不更新df -h磁盘满了写不进去服务启动失败tail -n 100 启动日志端口被占用、配置文件错误、依赖服务没起访问端口不通netstat -tlnp | grep 端口服务未监听或防火墙拦截数据库连接失败ping、telnet ip 端口网络不通、端口未开放、DB服务未启动拿到一批乱码文本file 文件名文件是压缩文件或二进制需要先转换格式找不到日志文件find / -name *.log 2/dev/null日志输出路径和预期不一致这个表不追求覆盖所有问题但给测试人员提供一个快速切入的思路。排查问题最重要的是先确认“问题边界”然后再一步步缩小范围而不是一上来就打开代码看逻辑。6.2 给测试同学的最后几条经验第一所有“批量删除”和“批量替换”操作前一定先备份或者先加打印预览。rm -rf和sed -i这两类命令是测试环境事故的重灾区一次回车操作可能就是几小时的返工。第二管道命令尽量短小清晰拆开执行。很多人为了装酷一条命令写十几个管道的组合结果中间某一环节出问题根本不知道错在哪里。我习惯把长命令拆成几步执行先过滤、再提取、最后统计每一步都确认一下中间结果。慢是慢一点但排查问题更稳。第三别怕把命令写到本地的笔记里。我自己有一个“测试环境命令速查”文档把所有高频命令、边界参数、遇到过的问题都记下来尤其是那种“今天调试了半小时终于搞定的命令”下次遇到相似场景直接翻笔记效率提升非常明显。测试的本质是找到系统的薄弱点而Linux命令就是你接近这些薄弱点的手段。它不神奇但足够高效。只要你在日常工作中多用、多记、多总结这些命令很快就能成为你的肌肉记忆。