1. 为什么软件测试工程师也要啃Linux命令做软件测试这行Windows操作界面用惯了很多人第一反应是“我点点鼠标不就行了学命令行干嘛”。但真到了测Linux服务器端的项目或者环境部署、日志分析、性能定位这些环节鼠标基本退化成摆设。尤其是这两年国产系统、麒麟系统在银行、政务、医疗这些行业铺开测试环境清一色换成了Linux或者类Unix环境如果你连最基本的tail、grep、ps都玩不转连日志都拉不出来那基本就卡在第一步了。我在实际带项目的时候见过不少这样的场景测试环境出了问题开发说“你去看下日志”结果你连日志在哪个目录、用什么命令打开、怎么按关键字过滤都搞不定。不是说这有多丢人而是这个问题本来不该成为测试的瓶颈。我们毕竟是来验证功能、发现缺陷的不是来跟操作系统较劲的。所以把常用的Linux命令整理成一套顺手的东西对测试效率的提升立竿见影。这篇文章不是给你塞一份什么几千条命令的大全那些看着唬人实际用不上。我按照软件测试工程师日常工作的真实路径来拆文件操作、日志查看、进程管理、性能监控、网络排查、文件传输、权限配置、排查技巧。每一条命令都附上我在真实项目里踩过的坑和使用心得你可以直接照着用当成自己的命令速查手册。2. 测试环境搭建期目录与文件操作的底子功夫2.1 目录切换与查看别再cd到怀疑人生很多人说ls、cd这种命令太基础不值得学。但基础命令恰恰是日常使用频率最高的一点不夸张我每天输入的Linux命令里ls和cd占了四成。ls -l列出文件详情包括权限、属主、大小、修改时间。这个参数组合是刚需测试要确认配置文件是否生效第一件事就是看文件的时间和权限对不对。ls -lt按时间倒序排列文件。找最新的日志文件时这一条比啥都管用。ls -la显示包括隐藏文件在内的所有文件。很多配置文件都是隐藏的比如应用目录下的.env文件。cd -切换回上一个目录。在多个配置目录之间反复跳的时候这一条能省下大量时间。提示尽量用Tab键补全路径既可以避免手动敲错也能快速确认目录里到底有什么。2.2 文件操作复制、移动、删除的安全意识测试环境虽然不像生产环境那么金贵但误删文件这种事谁都不想碰到。我给自己定的规矩是批量操作之前先加--dry-run或者-n参数看一眼确认无误再动手。cp -rp source_dir target_dir-r递归复制目录-p保留文件权限和时间戳。部署测试版本时这个组合几乎必用。mv file1 file2重命名或移动文件部署时替换配置文件常用。rm -rf这是双刃剑中的双刃剑。建议执行前先敲ls确认当前路径再用pwd看一遍特别是切换了用户或者sudo之后目录错了删除的就是整个环境。搜索文件是另一个高频场景。我经常需要在几十个包、几百个配置文件里找一堆关键字靠肉眼翻是愚蠢的find /opt -name *.conf按文件名查找。find /home/test -size 100M查找超过100MB的大文件。日志文件把磁盘撑爆的问题就是靠这条来定位的。find /logs -type f -name *.log -mtime -3查找三天内修改过的日志文件排查问题时非常实用。2.3 文本查看三剑客cat、head、tail、less测试人员天天跟文本打交道配置文件要看、日志要翻、结果要对比这几个查看命令必须形成肌肉记忆。cat适合查看小型文本文件或者把多个文件拼接后输出。head -n 50 file只看文件前50行。启动日志的前几十行通常是重要的初始化信息。tail -n 50 file只看文件末尾50行。程序崩溃后最后的堆栈信息全在这里。tail -f file实时跟踪文件末尾内容。调试接口、观察日志输出时这条命令是常驻工具。less分页查看大文件按Shiftg跳到最后按/输入关键字进行搜索按n查找下一个。看几十MB的日志必须用less而不是vi。3. 日志分析与定位grep、tail、awk的三重奏3.1 grep是测试人员最重要的命令没有之一日志分析是整个测试环节里最耗时的部分之一而grep是解决这个问题的钥匙。它的核心作用就是在文本中按模式匹配行看起来简单用法却极深。实际测试中我用到最多的组合grep ERROR app.log在日志中捞所有报错行。grep -i error app.log忽略大小写。有些日志框架输出的是Error有些是ERROR不-i过滤会漏报。grep -r Exception /opt/app/logs/递归搜索整个目录。接口报错但不知道打到哪个日志文件时用这一招能快速缩小范围。grep -A 20 -B 5 NullPointerException app.log显示匹配行之后20行-A、之前5行-B。报错上下文比报错本身更有价值只看一行堆栈根本不够。grep -E ERROR|WARN|Exception app.log正则表达式多条件匹配一次找出所有问题级别日志。grep -l 需要查找的关键字 *.log只列出包含关键字的文件名。测试多个微服务实例时这一条能直接告诉你去哪个节点排查。grep和管道组合几乎是测试日常# 查看错误日志中前10条 grep ERROR app.log | head -10 # 统计错误总数 grep -c ERROR app.log # 查看某个接口返回500的请求数量 grep api/user/info access.log | grep HTTP/1.1\ 500 | wc -l3.2 tail与grep组合动态监控日志输出调试实时功能时tail -f和grep是王牌组合tail -f /opt/app/logs/order_service.log | grep 订单状态变更在有日志滚动的情况下文件会按大小或时间切割成多份。如果只想看最后一次启动以来的日志tail -f会跟丢位置这时候用tail -F大写会更稳因为-F能适应日志文件名变化做Logrotate之后也不会断。3.3 时间段日志截取与统计压测结束后最烦人的事情是从一堆日志里把某个时间窗口内的分析出来。只靠grep关键字不够需要结合正则表达式或者用sed把时间范围内的行拎出来# 提取2024-12-01 14:30:00到14:45:00之间的日志 sed -n /2024-12-01 14:30:00/,/2024-12-01 14:45:00/p app.log windowed.log这种方式在性能测试中相当实用。压测脚本起始时间是14:30结束是14:45那这个窗口内的日志对应着完整的压力阶段拉出来单独分析比从头到尾扫一遍快得多。3.4 awk在日志统计中的真实价值awk看起来有点古老但它在日志统计分析上的能力Excel真不一定比得上。测订单接口时日志里每行都记录了耗时我想快速知道平均耗时和最大耗时一条命令就出来了# 假设日志最后一列是耗时(ms) awk {sum$NF; count; if($NFmax) max$NF} END {print 平均耗时:, sum/count, 最大耗时:, max} app.logawk的$1、$2这些字段是按空格分隔的列。日志格式固定时非常好用字段位置一变就要调整。还有更简单的分析方式用sortuniq统计错误类型分布grep ERROR app.log | awk -F] {print $2} | sort | uniq -c | sort -rn这条命令的意思是把每个报错行按照]分隔取第二个字段作为错误类型排序、统计出现次数、按次数倒序排列。压测之后跑一遍整个系统在压力下最容易出现哪类错误一目了然。4. 进程与端口排查谁占了我的环境4.1 ps命令找到目标进程的姿势测试过程中最多遇到的问题就是环境起不来、端口被占、服务重复启动、进程挂了没自动拉起。ps是解决这些问题的第一步。ps -ef | grep java查看所有Java进程。这是最常用的没有之一。应用是Java开发的就搜java是Python开发的就搜python。ps -ef | grep order-service按服务名精确匹配。ps -eo pid,ppid,%cpu,%mem,cmd --sort-%cpu | head按CPU占用排序后只看前几条性能测试中发现某个进程CPU飙高时就用这条。需要注意的一点ps -ef | grep 关键字这条命令本身会把grep的进程也列出来真正的进程信息排在最后。4.2 端口占用谁抢了我的8080端口冲突是测试环境最常见的故障之一。新部署的服务起不来十有八九是端口被别的服务占用了。排查方法三件套# 方法一netstat老牌命令 netstat -tlnp | grep 8080 # 方法二ss更快速推荐 ss -tlnp | grep 8080 # 方法三lsof能直接看到进程名 lsof -i:8080-t表示只显示TCP-l表示监听状态-n表示不做域名解析-p表示显示进程PID和名称。三个参数组合在一起一条命令就能定位到是哪个PID、哪个程序占着端口。找到PID之后如果是僵尸进程或者重复启动的旧进程直接kill -9 PID清理掉。4.3 查看进程树和终止命令有时候服务起了多个实例你只想杀掉某个子进程直接用PID不够清晰。这时候看进程树最直观# 按树形结构查看进程 pstree -p | grep order_service # 杀掉某个精确匹配的命令行进程按关键字 pkill -f order-service.jar # 强制杀掉指定PID kill -9 PID这里提一个血的教训kill -9不是首选方案它会直接干掉进程可能导致数据未落盘、文件损坏。能正常关尽量先执行shutdown脚本或kill不带参数只有确认进程卡死的情况下才用-9。但测试环境下进程起不来又占着端口时-9反而是最干脆的办法。5. 性能监控压测阶段必备的组合装备5.1 top命令的动态视角性能测试过程中top是打开频率最高的监控工具。它会实时刷新系统整体状态包括CPU使用率、内存使用量、负载均值以及每一个进程的CPU和内存排行。测试过程中我一般是这么用top的按大写M按内存使用量排序看哪个进程吃内存最凶。按大写P按CPU使用量排序定位CPU瓶颈进程。按数字1查看每个CPU核心的独立使用率判断负载是否均匀。更常用的是把top输出保存下来或者用批处理模式# 每3秒刷新一次共记录20次保存到文件 top -b -d 3 -n 20 /tmp/top_capture_20241201.txt压测结束后打开这个文件能回溯出整个压测时间段内哪个进程长期占据高CPU哪段时间系统负载飙升这是性能定位的原始证据。5.2 内存与磁盘的命令化体检内存泄漏是服务端测试最讨厌的问题。测试环境跑个三天三夜的稳定性测试发现内存占用持续上涨这时候free命令就是你的仪表盘free -h-h参数会自动换算成GB、MB等人类友好的单位。看的时候重点关注available这一列它反映的是系统实际可以分配出去的内存比used更有参考意义。如果available持续走低、swap开始被大量使用基本可以定性为内存紧张。磁盘方面测试环境日志文件把磁盘写满是我见过频率第二高的故障。df用来查看整体使用率df -h接着用du排查哪个目录最吃空间# 查看当前目录下一级子目录占用的空间 du -h --max-depth1 | sort -hr | headsort -hr会按人类可读的大小倒序排列哪个目录占了多少空间直接看头部几行就够了。5.3 vmstat与iostat定位硬件瓶颈压测中如果怀疑是CPU调度或者磁盘I/O层面的瓶颈vmstat和iostat比top更直接。vmstat能一口气展示出进程、内存、swap、I/O、CPU状态# 每隔2秒采集一次共采集5次 vmstat 2 5输出里的us表示用户态CPU占用sy是系统态wa是I/O等待。wa过高表示磁盘读写是瓶颈性能测试中如果发现TPS上不去了但wa飙升第一反应应该是看存储而不是看CPU。磁盘那块用iostat看iostat -x 2 5%util接近100%意味着对应磁盘已经处于饱和状态。测试数据库、文件服务这类磁盘密集型应用时这个指标几乎决定了性能天花板。6. 网络问题排查接口调不通时怎么办6.1 连通性检查ping与telnet的组合判断测试接口的第一步经常是确认网络通不通。ping负责检查网络层连通性telnet负责检查端口是否开放两者是组合搭档。# 检查目标主机是否可达 ping -c 4 10.10.10.20 # 检查目标主机的8080端口是否开放 telnet 10.10.10.20 8080ping通不代表端口通端口通不代表服务正常服务正常也不代表接口返回正确。这三层逻辑要分开排查。telnet连上了会显示Connected to连不上会提示Connection refused或者timed out。很多初级测试小伙伴一看到接口报错就找开发其实自己先这么排查一遍能定位掉一半问题。6.2 curl接口测试的命令行瑞士军刀curl可能是被测试人员低估最严重的命令。它可以模拟各种HTTP请求甚至可以当作临时的接口测试工具# 发送GET请求并显示响应头和响应体 curl -i http://10.10.10.20:8080/api/health # 发送JSON格式的POST请求 curl -X POST http://10.10.10.20:8080/api/order \ -H Content-Type: application/json \ -d {orderId:A1001,amount:999} # 查看请求耗时明细 curl -w DNS解析耗时: %{time_namelookup}s, 连接耗时: %{time_connect}s, 总耗时: %{time_total}s\n -o /dev/null http://10.10.10.20:8080 # 带上cookie模拟登录态 curl -b session_idabc123 http://10.10.10.20:8080/api/user/info当你有JMeter或者Postman却懒得打开的时候一个curl就能快速验证。尤其是调试环境问题时想要确认某个接口到底是通还是不通、返回体长什么样curl的效率和直观度都是第一梯队。6.3 tcpdump抓包定位问题的最终手段有些网络问题排查到最后应用日志显示请求已经发送服务端却没有任何记录常规手段都没法定位。这时候只能抓网络包看底层数据流通tcpdump就是为这个场景而生。# 监听8080端口上的所有流量并保存到文件 tcpdump -i eth0 tcp port 8080 -w /tmp/app.pcap # 监听8080端口为了可读性显示ASCII内容 tcpdump -i eth0 tcp port 8080 -A抓出来的包用Wireshark打开分析能看到完整的TCP三次握手、请求数据包和响应包。有一次我排查一个偶发性的接口超时问题应用日志里没有任何异常最后就是靠tcpdump发现服务器返回了TCP重传定位到是网络链路问题而不是服务代码问题。这类经验在面试中拿出来讲比背一百个命令都加分。7. 文件传输与解压部署与采集的日常7.1 tar打包解压一条龙测试环境部署包里几乎都是tar.gz格式。解压、打包、查看包内容这几个操作太常用了# 解压tar.gz包 tar -zxvf app.tar.gz # 解压到指定目录 tar -zxvf app.tar.gz -C /opt/app/ # 打包目录为tar.gz tar -zcvf app_backup.tar.gz /opt/app/ # 查看压缩包内容列表先不做解压 tar -tzvf app.tar.gz-z表示gzip压缩-x表示解压-c表示创建-v显示详细过程-f指定文件名。这几个参数在表达层面可以组合出很多变体。7.2 从Windows本机与Linux服务器互传文件测试人员的日常状态是本地Windows或Mac服务器是远程Linux环境。文件互传怎么搞很多新人问我有没有图形化工具其实命令行里就自带方案。最常用的是scp基于SSH协议简单安全# 把本地文件上传到服务器 scp local-testcase.zip root10.10.10.20:/opt/test_files/ # 从服务器下载文件到当前目录 scp root10.10.10.20:/opt/app/logs/order.log ./ # 整个目录递归传输 scp -r root10.10.10.20:/opt/app/logs/ ./logs/小文件用scp就够但几十个GB的日志或者大体积安装包scp就力不从心了。更高效的方式是用rsync支持断点续传rsync -avzP --progress root10.10.10.20:/opt/app/logs/ ./logs/-P参数允许断点续传-z是传输时压缩-a是归档模式保持文件属性。还有一套zmodem命令在Xshell、SecureCRT里很实用服务端安装lrzsz之后# 上传文件到服务器 rz # 下载文件到本地 sz file.txt它会弹出一个图形化文件选择框体验接近Windows的文件对话框。小文件倒腾的时候这个比scp更顺手。7.3 压缩包解压乱码问题搜索热词里有“linux 解压文件乱码”这一点确实很多人碰到过。Windows上用WinRAR或7-Zip打的zip包拿到Linux上解压文件名直接变成乱码。原因很古老Windows用的是GBK编码Linux默认UTF-8两边不对付。解决办法是安装unzip后使用-o加上指定编码# 以中文GBK编码解压 unzip -O GBK file.zip如果unzip版本不支持-O参数可以用Python的zipfile或者p7zip处理7z x file.zip我自己遇到乱码时还会用convmv工具做文件名编码转换convmv -f GBK -t UTF-8 --notest *.zip这类坑在测试国产设备、Windows与Linux混用的场景里特别多发建议优先确认来源文件是用什么系统打的包从源头约定编码格式才是彻底的方案。8. 权限与用户管理测试账号怎么配才安全8.1 查看与修改文件权限测试环境里经常碰到的问题是权限不够连日志文件都看不了。Linux权限体系核心是三组权限属主u、属组g、其他用户o每种身份下又分读r、写w、执行x。使用ls -l查看文件时第一列就是权限位ls -l /opt/app/config.yml看日志文件常用的操作# 给所有用户增加读权限 chmod r /opt/app/logs/order.log # 对属主赋予全部权限对组和其他用户赋予读写权限数字法 chmod 766 file # 让目录及其内部所有文件继承权限设置 chmod -R 755 /opt/app/scriptschmod的数字法我建议必须掌握r4、w2、x1加起来就是权限值。rwx是7rw-是6r-x是5。762就表示属主rwx、属组rw-、其他人-w-。这个对应关系背下来以后看任何权限表达式都不会慌。8.2 修改文件属主和属组测试环境的服务是以特定用户运行的如果日志输出目录的属主不对服务根本写不进去文件# 修改属主和属组为testuser chown testuser:testgroup /opt/app/logs/ # 递归修改整个目录树 chown -R testuser:testgroup /opt/app/排查服务启动时报Permission denied的问题时先看文件归属再看权限位基本百发百中。8.3 用户与用户组的增删改在测试环境搭一套独立的测试用户和用户组是规范做法。而且面试时经常被问到怎么新建用户# 新建用户并创建同名的home目录 useradd -m testuser # 设置或修改密码 passwd testuser # 加入sudo组获得管理员权限Debian/Ubuntu系 usermod -aG sudo testuser # 新建用户组 groupadd testgroup # 把用户追加进组 usermod -aG testgroup testuser记住useradd默认是不会自动创建home目录的加-m才有。如果你想给测试账号指定shell加参数-s /bin/bash。很多刚上手的人用useradd创建用户后发现没有home目录或者不能登录就是这个细节没注意到。9. 系统状态检查环境起不来的根因排查9.1 系统版本与硬件信息测试中经常需要记录环境信息比如软件兼容性测试要记录操作系统版本、内核版本、CPU架构。这时一组命令可以全部搞定# 查看内核版本和发行版信息 uname -a # 更详细的操作系统信息CentOS/Ubuntu/麒麟都支持 cat /etc/os-release # 查看CPU信息 lscpu # 查看CPU核数 nproc国产化适配测试尤其要关注os-release的输出能直接区分是银河麒麟、中标麒麟还是统信UOS。不同发行版的包管理方式和目录细节有差异记录环境时把这些信息都截图或输出到文本后面出报告用得上。9.2 查看系统负载和运行时间服务是不是因为资源耗尽而挂的运行时间和负载均值就能说清楚一部分uptime这条命令会输出当前时间、系统已运行时间、在线用户数以及最近1分钟、5分钟、15分钟的负载均值。如果15分钟负载一直很高而1分钟负载不高系统可能在恢复中反过来1分钟远远高于15分钟说明系统正在承受突发压力。9.3 服务管理systemctl和service命令现在主流的Linux发行版都用systemd管理服务测试环境部署完启停服务全靠systemctl# 启动服务 systemctl start nginx # 停止服务 systemctl stop nginx # 重启服务 systemctl restart nginx # 查看服务状态 systemctl status nginx # 设置开机自启 systemctl enable nginx # 查看所有正在运行的服务 systemctl list-units --typeservice --staterunning老一些的CentOS 6或某些系统的初始化脚本用service命令service nginx status service nginx restart排查环境起不来的问题有一个标准顺序先systemctl status看服务当前状态再journalctl查看系统日志最后再翻应用自己的日志。不要一上来就去翻应用日志很可能起因是服务根本没起来或者被系统杀掉了。10. 压测场景下的完整排查流程说完了单个命令我来串联一个真实的场景帮助你把上面的内容串成一条线。假设你正在做订单服务的性能测试压测脚本跑了一个小时突然发现TPS断崖式下滑接口大量超时。这时候按下面这个流程走第一步确认服务进程状态。用ps -ef | grep order-service确认服务还活着用top确认CPU、内存是否有异常。第二步看系统整体负载。用uptime看5分钟内的负载均值用vmstat 2 5看CPU等待、内存交换、I/O等指标。第三步拉取应用日志。用tail -n 200看看最新日志里面是不是刷满了报错信息再用grep统计错误类型grep ERROR /opt/app/logs/order_service.log | awk -F] {print $2} | sort | uniq -c | sort -rn | head -10第四步检查端口和服务端口监听状态。用ss -tlnp确认服务仍在监听用curl -w看一下具体接口的响应时间。第五步看磁盘和内存。df -h确认磁盘没满free -h确认内存没耗尽。这五步做完问题基本就能定位到一个精确的方向。如果还查不出来再用tcpdump配合Wireshark做底层抓包分析。这套流程我用了很多年每次都能够在十分钟内给开发一个明确的问题范围而不是笼统地丢一句“系统好像卡了”。11. 常见问题速查表问题现象排查命令高频原因服务起不来systemctl status、journalctl -xe端口被占用、配置语法错误端口被占用ss -tlnp | grep 8080、lsof -i:8080旧进程未杀掉日志刷新缓慢df -h、du --max-depth1磁盘空间不足接口超时curl -w、tcpdump网络链路、后端处理慢CPU持续飙高top、ps -eo %cpu --sort-%cpu死循环、GC频繁、压测流量过大内存持续上涨free -h、top -M内存泄漏、缓存堆积文件解压乱码unzip -O GBK、convmvWindows与Linux编码不兼容Permission deniedls -l、chmod、chown文件属主或权限位不对服务自动挂掉dmesg、journalctlOOM Killer、配置不合法注意很多问题排查完根因都是多个因素叠加上面的表格只是入口。真正定位到最终结论还需要结合应用日志和业务逻辑综合判断不要把命令当成万能解药。12. 学习Linux命令有效的方式一是多用二是了解原理很多人收藏了命令大全但真的遇到问题时还是抓瞎。为什么因为命令光看不练永远形不成记忆。我自己带新人的时候会让他们做一个小练习把一台测试服务器当作自己的学习环境每天用命令行完成指定任务比如查看当前系统状态、找出占用CPU最高的进程、追踪某个接口的日志输出、把一个目录打包下载到本地。连续练上一周常用命令基本就能顺手了。再来说说原理。每条命令其实背后都有对应的系统调用和文件抽象逻辑。比如ls实际是在读取目录文件ps是读取/proc虚拟文件系统下的进程信息free是读取内存管理相关的统计数据。当你理解了Linux“一切都是文件”这个设计理念很多命令的行为就自然理解了而不是靠死记硬背。Linux命令的学习路径是稳步性的不要追求一次吃透几百条花时间在grep、tail、ps、top、curl、tar这种日常使用频率最高的命令上性价比更高。等其他命令熟练了再去学sed流编辑、awk高级统计、管道组合这些进阶技巧就不会觉得吃力了。最后分享一个我个人的习惯每个测试项目结束后把这次排查过程中用到的有效命令和踩过的坑整理成一份Markdown笔记按项目归档。下次遇到类似问题直接翻自己的笔记比翻搜索引擎快得多。这也是为什么我建议你把这篇文章收藏下来当作自己的速查手册但在实际项目里形成自己的一套命令集才是根本。