做测试这些年我面试过不少人也带过不少新人发现一个很有意思的现象很多人简历上都写着“熟悉Linux常用命令”可真到了测试环境出问题的时候脑子里能想起来的基本只有cd、ls、ping这三个。让去看个日志不知道用什么命令让确认缓存有没有生效不知道redis-cli怎么进让查一下服务为什么起不来连docker logs都没用过。这不怪大家。测试日常被功能用例、测试计划、缺陷报告包围命令行这种东西不像功能测试那样有明确的操作路径很多时候是“用到才学”但又不知道什么时候该用。可恰恰是这些“用不到就永远想不起来”的命令才是测试工程师从“会点点点”走向“会定位问题”的分水岭。这篇内容我想结合自己这些年踩过的坑和沉淀下来的习惯把测试工作中真正高频的常用命令按场景梳理一遍环境日志、版本协作、数据验证、容器排查、移动端调试、接口探测每一类都配上典型使用场景和参数说明。适合刚入门想提升效率的测试新人也适合工作两三年但始终没系统整理过命令行技能的同行。命令本身不复杂复杂的是你愿不愿意在遇到问题时多敲一下tab、多看一眼help。真正值钱的不是背下多少命令而是建立起“出问题往哪个方向查”的直觉。1. 测试不只会点点点命令行的价值边界1.1 从一次线上事故复盘说起去年我们项目有一次线上告警业务反馈某个支付回调一直失败。开发同事第一反应是“看看网关日志”结果测试环境的网关日志没有接入日志平台只能在服务器本地查。如果当时只会用cd和ls面对服务器上几十个目录、几百个日志文件基本就是大海捞针。实际上整个排查过程就是三板斧# 进入日志目录按时间筛出当天的文件 cd /data/logs/gateway/ ls -lhtr | tail -20 # 连续跟踪日志输出同时过滤关键词 tail -f gateway.log | grep -i callback\|timeout\|error # 在已有的日志文件里统计错误出现的频率 grep -c ERROR gateway-2024-06-18.log不到五分钟就定位到是下游服务某个字段返回了空值。这一套操作没有任何高深的地方但它要求你至少知道日志大概率在哪个目录、用什么命令能快速找到文件、用什么命令能过滤出关键行。这三件事恰恰是命令行的基本功。复盘的时候我们都会感慨如果当时同事连ls和grep都不熟练光靠肉眼翻几万行日志这个线上问题至少要拖一两个小时才能定位。1.2 测试岗位对命令行能力的隐性要求现在稍微像样一点的测试岗位JD里都会写“熟悉Linux常用命令”“熟悉数据库操作”“了解Docker”“熟练使用抓包工具”但很少有人告诉你这些技能到底在什么场景下用。我梳理了一下日常工作中会用到命令的典型场景至少有这些环境验证开发给了一个新的测试包你需要起服务、看端口、查日志确认版本是否更新成功问题定位接口报500你需要去服务器上看应用日志、查数据库状态、确认依赖的中间件是否正常测试数据准备需要造特定数据比如注册用户、插入订单、重置缓存直接操作数据库或Redis远比在界面上点更快回归范围确认一条缺陷修复后你需要通过git diff/log确认代码到底改了哪里避免误测或漏测环境恢复测试环境被弄乱之后重启服务、清缓存、重置数据是测试自己的事接口调试没有现成接口文档工具的时候curl是最快的验证方式。基本上这些场景都绕不开命令行。理解了这个背景你就明白为什么下面这些命令值得花时间系统过一遍——不是为面试简历好看而是为了在真实项目里不卡壳。1.3 不同测试方向的命令侧重点不同测试方向对命令的要求其实差别挺大一份通用的“命令大全”反而让人抓不住重点。我根据自己的观察列个对照表测试方向最常用的命令类型使用说明功能/业务测试Linux日志排查、数据库查询定位问题、验证落库数据接口测试curl、telnet、Redis命令直接调接口、查缓存状态、查库比对UI自动化测试adb、Git、Linux基础设备调试、脚本版本管理、CI执行环境性能测试top、free、df、curl -w观察资源占用、请求耗时分布数据/数仓测试SQL、HDFS常用命令数据校验、离线任务日志排查想明白自己当前在做哪个方向就知道该优先学哪一类。不需要一开始就试图覆盖全部命令。2. 环境与日志排查Linux命令是测试的第一工具2.1 日志追踪tail与grep的组合拳测试环境接口报错开发让你把日志发给他前端调接口超时你要确认后端到底有没有收到请求服务莫名其妙重启你要看崩溃前的最后输出。这些场景都指向同一个技能日志操作。日志操作是测试最频繁遇到的需求核心命令就那么几个# 实时跟踪最新日志 tail -f /data/logs/app/application.log # 只跟踪最后200行并同时过滤关键词 tail -200f application.log | grep -i exception # 在历史日志里搜索带行号忽略大小写显示上下文各5行 grep -in NullPointerException application.log # 搜索某个错误并同时显示前后各5行上下文 grep -n order timeout -A 5 -B 5 application.log # 统计错误出现次数 grep -c ERROR application.log # 把搜索到的报错行写入独立文件方便转发给开发 grep Exception application.log error.log这里有两个亲测有效的细节。第一tail -f 是跟踪文件末尾加 -F 会在文件被轮转rename后自动重新打开这在日志按天切分的系统里特别实用不加 -F 有可能在切分后跟丢日志。这个坑我踩过——早上9点日志切分tail -f 就卡在旧文件上不动了害我以为服务没输出。第二grep 的 -A 和 -B 参数非常适合看异常堆栈因为Java或Python报错往往不是一行而是连续好几行堆栈只看命中行有时根本看不出完整原因。2.2 系统状态与端口检查从“服务起没起”到“资源够不够”测试环境最常见的三个“事故”服务起不来、端口被占用、内存或磁盘满了。对应的命令也几乎固定# 检查进程是否存在 ps -ef | grep java # 查看端口占用情况 netstat -tlnp | grep 8080 # 新版系统更推荐ss ss -tlnp | grep 8080 # 查看CPU、内存占用 top -o %CPU free -h df -h # 查看某个端口对应的进程 lsof -i:8080几个容易忽略的点。第一netstat -tlnp 的 -p 参数需要较高权限普通用户可能看不到进程名只能看到端口在监听。这种情况可以提权或者用 lsof -i:端口 做补充。第二测试环境磁盘写满是个高频事故磁盘一旦满了服务会表现得很诡异日志写不进去但不报错、数据库事务卡住、接口超时。所以排查问题的时候养成先看一眼 df -h、free -h 的习惯真的能省很多时间。第三top查看负载时不只盯着%CPU和%MEM还要留意load average如果load很高但CPU不高很多时候是磁盘IO或锁等待这时候再用iostat、dstat进一步看不过这些工具不一定预装需要时再装就行。2.3 文件查找与传输找配置、导日志、传文件测试环境部署最常做的就是改配置、拉日志、传安装包# 按文件名查找 find /data -name application*.yml # 按修改时间查找找出最近改动过的文件 find /data -mtime -1 # 打包日志目录 tar -zcvf logs.tar.gz /data/logs/app/ # 解压 tar -zxvf logs.tar.gz # 远程传输文件 scp logs.tar.gz user192.168.1.10:/data/tmp/ # 或者用rsync断点续传 rsync -avz logs.tar.gz user192.168.1.10:/data/tmp/find 配合 -name 和通配符是最常用的。比如一个服务有多个环境配置文件application-dev.yml、application-test.yml、application-prod.yml测试验证的时候经常要确认当前加载的到底是哪个用 find 加 cat 就比在目录里挨个翻快得多。tar 命令不需要背太多只记两种组合就够了压缩是 tar -zcvf 目标文件 源目录解压是 tar -zxvf 压缩包剩下的按需查help。还有一个容易被忽略但超级实用的组合是 history 和 grep。你曾经在某个环境执行过一条很长的命令重装环境后想找回原来的启动参数直接 history | grep java 就能翻到比自己回忆可靠得多。顺带提一句Windows环境测试机上如果只能用cmd或PowerShell对应的常用命令是 ipconfig、netstat -ano、tasklist /FI IMAGENAME eq java.exe、sc query 服务名PowerShell里更常用 Get-Process、Get-Content -Wait 日志文件。思路和Linux完全一致只是语法不同不必被操作系统差异吓住。3. 版本协作与代码定位Git命令是测试的隐形肌肉3.1 测试为什么也要懂Git可能有人说“Git是开发的事我测功能就好”。理论上确实可以但实际工作中你会发现这些场景会反复出现测试环境分支不小心被切到别人的开发分支你测了半天测的根本不是这个版本缺陷修复后你要验证“这次改动是否真的只涉及修复方案提到的几个文件”防止开发顺手改了一堆不该动的东西版本发布前你需要确认当前环境上的代码是否包含某个修复提交回归测试时怀疑是代码变更引入的问题你想快速定位改动范围。不懂Git的话以上场景只能反复去问开发不仅效率低而且你在团队里的角色会越来越像“传话筒”而不是一个能独立完成质量保障的工程师。3.2 测试高频Git命令集我用一个最典型的版本验证场景来串联命令。假设你们项目的迭代分支是 release-2.3.1开发刚合入了一个修复你需要去测试环境确认修复是否生效同时确认代码只改了指定文件# 先看一下本地所在分支 git branch --show-current # 拉取远端最新代码 git pull # 查看远端分支上最近5条提交记录 git log --oneline -5 origin/release-2.3.1 # 查看这个分支比主干多了哪些提交 git log --oneline master..release-2.3.1 # 查看最近一次提交改了哪些文件 git show HEAD --stat # 对比两个分支之间的文件差异 git diff master release-2.3.1 --stat # 只看某个具体文件的差异 git diff master release-2.3.1 -- src/main/java/com/xxx/OrderService.javagit log --oneline 是最常用的--oneline 让每条提交只显示一行加上 -5 显示最近5条信息密度很高。git diff 加 --stat 能在不看代码细节的情况下快速看出两个版本之间动了哪些文件对测试判断影响范围非常有用。如果开发告诉你“问题已经修复了代码在feature/xxx分支”你需要# 拉取远端所有分支信息 git fetch # 切换分支并拉取最新代码 git checkout feature/xxx git pull这里要特别提醒在测试环境部署时记得先 git branch --show-current 确认当前分支这不是防开发而是防自己。我见过太多次因为测试环境分支不对导致整个迭代白测的情况一旦你部署的是旧代码所有的通过结果都没有意义。还要注意几个容易误操作的命令。git reset --hard 会丢失本地未提交的改动千万别在共享环境乱用。需要回退某个提交时优先用 git revert它不会删除历史而是生成一个反向提交安全得多。另外切换分支前如果有未提交的改动用 git stash 暂存避免因为本地脏文件导致切分支失败。如果项目里还用了git submodule更新时记得加上 git submodule update --init --recursive这是很多人部署测试环境时莫名报错的原因——子模块根本没拉下来。4. 数据验证与中间件操作缓存和数据库命令4.1 Redis缓存测试绕不开的命令测试里涉及登录token、验证码、接口限流、商品库存、分布式锁这些功能时Redis都是核心依赖。用命令行直接操作Redis比在界面上干等缓存过期高效得多# 连接Redis redis-cli -h 192.168.1.20 -p 6379 -a 密码 # 查看所有key只建议在测试环境使用 keys * # 查看key对应的值 get user:login:token:12345 # 查看剩余过期时间秒 ttl user:login:token:12345 # 删除指定key del user:login:token:12345 # 查看当前数据库key总量 dbsize # 查看内存、连接数等运行信息 info memory info clients # 切换到指定dbRedis默认有16个库编号0-15 select 2几个实际使用场景。造“登录过期”场景测试登录态过期后跳登录页最直接的方式不是等token自然过期而是先 get 查到token对应的key再 del 删掉然后重新触发接口请求立刻就能验证。验证码场景开发经常把验证码存在Redis里测试时为了省去查手机短信或邮箱的步骤可以直接 get 拿到验证码。限流场景限流计数器的key用 ttl 查看窗口剩余时间就能判断限流策略是否按预期生效。但有几个坑必须强调。第一keys * 在key数量很大的情况下会阻塞Redis生产环境千万不要执行测试环境如果key特别多也要慎用。需要搜索时用 scan 0 match user:* count 100它是通过游标分批遍历的不会长时间阻塞。第二flushdb、flushall 这类清库命令在测试环境能不用就不用因为你不知道其他同事正在往这个Redis写什么数据一个flush可能让别人的调试环境当场报废。真要清理优先定位到具体key再删。第三redis-cli 的 -a 参数会暴露密码在共享服务器上执行的话其他人通过 history 就能看到能用交互式输入密码就不要写在命令行里。另外很多测试同学不知道Redis有db编号的概念结果在select 0里查不到数据其实数据在select 2里白费半天功夫。如果遇到这种情况先 dbsize 看看每个库有没有数据再决定在哪查。4.2 MySQL查数据、造数据、清数据业务数据大多落在关系型数据库测试里最常见的数据库操作是查数据做校验其次是造数据和清理脏数据# 连接数据库 mysql -h 192.168.1.30 -P 3306 -u root -p # 进入库 use test_db; # 查看所有表 show tables; # 查看表结构 desc user; # 查询数据limit必须带上 select id, username, status, create_time from user where mobile13800000000 limit 10; # 统计数量 select count(*) from order where status1; # 造一条测试数据 insert into user (username, mobile, status) values (testuser01, 13800000001, 1); # 清理测试数据一定带where delete from user where mobile13800000001 limit 1;命令本身不复杂真正要强调的是安全意识。在开发或测试环境执行update和delete之前一定要先select确认where条件能命中预期数据。我见过同事执行 delete from user 时忘了写where一秒钟清空整张表最后只能找DBA从备份恢复那天的测试计划基本就黄了。还有两个能提高效率的用法。一是用 explain 看查询的执行计划测试中如果接口响应很慢怀疑数据库层面有问题可以先 explain select ... 看有没有走索引再反馈给开发而不是只会说“接口好慢”。二是把常用查询存成SQL文件用 mysql test.sql 批量执行或者在mysql客户端里 source /path/to/test.sql 加载。造数据的脚本也建议写成SQL文件重复使用别每次手敲。如果用PostgreSQLpsql客户端里常用 \l 列库、\dt 列表、\d 表名 看结构核心思路是互通的。5. 容器化时代的排查能力Docker与K8s常用命令5.1 Docker容器就是新的“测试环境”现在很多测试环境已经容器化。对测试而言docker命令主要用于三件事看服务是否正常、看日志、进出容器排查# 查看运行中的容器 docker ps # 查看所有容器包含已停止 docker ps -a # 连续跟踪容器日志tail显示最后100行 docker logs -f --tail 100 容器名或容器ID # 进入容器内部执行命令 docker exec -it 容器名 /bin/bash # 不进容器直接执行单条命令 docker exec 容器名 curl -s http://127.0.0.1:8080/health # 查看容器的端口映射和挂载信息 docker inspect 容器名 | grep -A 10 Ports # 重启、停止、启动容器 docker restart 容器名 docker stop 容器名 docker start 容器名 # 查看镜像列表 docker images # 构建镜像在包含Dockerfile的目录下 docker build -t 项目名:标签 . # 用docker-compose管理多容器环境时 docker-compose logs -f docker-compose up -d docker-compose down实际中最常见的场景是“服务起不来”。容器启动后立即退出这时 docker logs 能看到应用报错如果日志正常但端口访问不了大概率是端口映射问题docker ps 里能看到类似 8080-80 的映射把宿主机的8080映射到容器的80。另一个高频操作是 docker exec -it 容器 /bin/bash容器相当于一个迷你Linux环境你可以在里面执行第2章讲的所有常用命令看进程、查端口、查文件。很多测试同学一说到容器就发怵其实把容器理解成一台远程服务器就行操作方法完全一致只不过进入方式从 ssh 变成了 docker exec。需要提醒的是docker stop/start 和 docker rm 是两件完全不同的事前者是停止/启动容器数据还在后者是删除容器容器一删容器内未挂载到宿主机上的数据就没了。在测试环境要谨慎删除容器尤其是数据库容器删了恢复成本非常高。5.2 K8s当容器规模变大测试也得会看Pod项目一旦上了K8s测试环境通常也是一套集群kubectl是绕不开的。测试最常用的K8s命令其实不多# 查看所有命名空间的Pod kubectl get pods -A # 查看某个命名空间下的Pod kubectl get pods -n test-ns # 查看Pod详细信息比如事件、镜像、重启次数 kubectl describe pod 服务名-xxx -n test-ns # 跟踪Pod日志 kubectl logs -f --tail 100 服务名-xxx -n test-ns # 进入Pod执行命令 kubectl exec -it 服务名-xxx -n test-ns -- /bin/bash # 查看服务暴露方式 kubectl get svc -n test-ns # 把远端服务的某个端口映射到本地方便本地调试 kubectl port-forward -n test-ns svc/服务名 8080:80K8s和Docker最大的区别在于Pod的名字是随机生成的kubectl get pods 看到的名字通常长得像 service-7b8f9c6d4f-abcde后面那串是随机部分。你只需要根据前缀定位服务然后用 describe 和 logs 去排查。kubectl describe pod 这条命令值得单独说。它会展示Pod的Events里面记录了Pod为什么被杀掉、为什么镜像拉取失败、为什么健康检查没通过。测试遇到“服务频繁重启”这类问题第一件事就应该是看Events而不是闷头翻代码。比如Pod状态显示OOMKilled说明内存超限被杀接下来该看资源限制和内存使用如果显示ImagePullBackOff说明镜像拉取失败多半是镜像仓库问题或标签写错。如果项目用Helm部署那么 helm list 可以查看当前部署的release版本helm upgrade --install xxx chart路径 更新部署。这些一般由运维负责但测试如果懂一点排障时能少等很久。6. 移动端与接口探测ADB和网络命令6.1 adb移动端测试的瑞士军刀移动端测试如果只会装app、点界面一旦出现崩溃或者需要构造特殊状态就会很被动。adb是Android Debug Bridge几乎所有安卓自动化框架比如Appium、UI Automator底层都是通过adb来驱动设备的所以懂adb是移动自动化测试的基础# 查看设备是否连接成功状态为device才正常 adb devices # 查看设备型号/安卓版本 adb shell getprop ro.product.model adb shell getprop ro.build.version.release # 安装/覆盖安装apk adb install -r 你的应用.apk # 启动一个应用 adb shell am start -n com.example.app/.MainActivity # 停止应用 adb shell am force-stop com.example.app # 抓取日志CtrlC停止 adb logcat -v time # 按包名过滤日志并输出到文件 adb logcat -v time app.log # 查看已安装的应用列表 adb shell pm list packages | grep com.example # 查看当前前台应用 adb shell dumpsys activity top | grep ACTIVITY # 截图并保存到电脑 adb exec-out screencap -p screen.png # 上传/下载文件 adb push local.txt /sdcard/ adb pull /sdcard/screenshot.png . # 本地端口转发调试WebView或抓包常用 adb reverse tcp:8080 tcp:8080实战里最常用的是 logcat。安卓崩溃时日志会打出 FATAL EXCEPTION把logcat日志保存下来后用 grep -A 30 FATAL EXCEPTION 截取堆栈发给开发开发基本能立即定位。如果崩溃只发生在特定流程可以先执行 adb logcat -c 清空日志再复现一次这样日志文件里只有这一次复现的相关内容干净利落。adb install -r 的 -r 表示覆盖安装如果安装报 INSTALL_FAILED_UPDATE_INCOMPATIBLE通常是签名不一致需要先卸载再装。对iOS测试命令行相对受限macOS上可以用 xcrun simctl 管理模拟器真机一般依赖Xcode和第三方工具这里不展开。重点提醒安卓方向的同行adb比任何GUI工具都可靠自动化脚本里用adb命令拿到的设备状态最准。6.2 接口与网络探测curl、telnet、ping接口测试离不开请求和验证。如果只是想快速确认一个接口是否可用curl是最快的# 发GET请求并显示响应头和响应体 curl -i http://192.168.1.10:8080/api/order/list # 发POST请求携带JSON数据 curl -X POST http://192.168.1.10:8080/api/order/create \ -H Content-Type: application/json \ -H Authorization: Bearer xxx \ -d {orderId:12345,amount:99.9} # 只输出响应状态码和耗时 curl -o /dev/null -s -w HTTP状态码:%{http_code} 耗时:%{time_total}s\n http://192.168.1.10:8080/health # 查看DNS解析、TCP连接、首字节耗时明细 curl -o /dev/null -s -w dns:%{time_namelookup} tcp:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n http://192.168.1.10:8080/healthcurl -w 的输出格式在接口巡检和初步性能评估中非常有用能直观看出耗时是花在DNS解析、TCP握手还是响应阶段配合后端日志就能判断瓶颈在哪一层。网络连通性排查方面# 基础连通测试 ping -c 4 192.168.1.10 # 检查某个端口是否开放 telnet 192.168.1.10 8080 nc -vz 192.168.1.10 8080这些是接口联调的基础。很多时候测试抱怨“接口不通”第一步就该用 telnet/nc 确认端口通不通、用 curl 确认HTTP服务有没有返回而不是直接拉开发一起看日志。多做一个分层排查沟通效率会高很多这也是资深测试和初级测试的差别之一。如果要做弱网测试PC端一般用Fiddler或Charles模拟限速命令行里也可以用curl的限速参数做粗略验证但真正模拟移动网络环境还是建议用客户端的弱网模板这块更多是工具配置层面的东西。7. 实战派的学习路径从命令到能力7.1 按场景学习而不是背命令表很多人想学命令第一反应是找一份“Linux命令大全”背下来。但命令大全只适合查阅不适合学习因为脱离场景的命令过两三天就忘。我建议按场景来你手头遇到的具体问题是什么就学相应的那几条命令然后把场景和命令一起记到自己的笔记里。比如今天遇到“端口被占用”就把 netstat -tlnp、lsof -i、ss -tlnp 记下来标注“适用范围端口冲突排查”。下次再遇到类似问题翻笔记就能找到。7.2 高频命令速查表我把前面提到的命令按场景整理成一份速查表可以截图存下来或者放进自己的笔记场景命令说明看实时日志tail -f 文件路径加-F防止日志轮转后跟丢搜日志关键词grep -i 关键词 文件-n显示行号、-A/-B显示上下文看进程ps -ef | grep 关键词确认服务是否启动看端口netstat -tlnp | grep 端口号或ss -tlnp看磁盘df -h磁盘满会导致各种诡异问题看内存free -h内存不足常见于测试环境传文件scp 文件 userhost:/路径或rsync -avz看Git提交git log --oneline -5快速确认最近改动看Git改动文件git diff 分支1 分支2 --stat判断影响范围Redis查keyredis-cli然后keys/scan测试环境用scan更安全Redis看过期ttl key验证缓存过期策略MySQL查数select ... limit 10一定加limitMySQL清数delete ... where ... limit先select确认范围Docker看容器docker ps -a-a看包含已停止Docker看日志docker logs -f --tail 100 容器名服务起不来先看它进容器docker exec -it 容器名 /bin/bash容器内就是LinuxK8s看Podkubectl get pods -n 命名空间注意Pod名随机K8s看事件kubectl describe pod 名称 -n 空间排查重启/拉镜像失败adb装包adb install -r 包名-r是覆盖安装adb抓日志adb logcat -v time崩溃复现前先-c清日志接口探测curl -i 地址快速看响应头和体端口探测telnet IP 端口 / nc -vz IP 端口分层排查网络问题这张表不求全覆盖的都是在测试工作中超过八成使用频率的命令类型。你没看错就是二十多个命令支撑起了测试日常的排障能力。不需要背到滚瓜烂熟只需要知道什么场景该去查哪个方向剩下的交给help和搜索。7.3 最后分享几个让我效率翻倍的小习惯第一个是善用alias把高频命令缩短。Linux下写入 ~/.bashrcmacOS写入 ~/.zshrc生效后每次敲两个字母就能完成操作alias kkubectl alias kgpkubectl get pods -A alias gpgit pull alias glgit log --oneline alias dpsdocker ps -a alias dlogdocker logs -f --tail 100Windows的PowerShell也可以用function或Set-Alias做类似的事。第二个是养成“先查后动”的肌肉记忆。凡是能删数据、重置环境、停服务的高危操作先看一眼当前环境、当前分支、当前容器再执行。很多线上事故都是因为“我以为我在测试环境”造成的。第三个是维护自己的命令速查笔记。每次新学到一个命令记录三件事场景、命令、注意点。过三个月回看这些笔记比任何课程都有价值。实话讲命令行这东西刚上手会觉得晦涩一旦用顺了你就再也回不去“只会点点点”的状态。希望这篇内容能帮你在下一次环境报错时少一点慌张多一分笃定。