企业官网建设流程全解析

Linux 命令 + AI 辅助排查：测试工程师实战指南

作者：楠风测开 | 5 年测试工程师 | 上海 本文 3800 字 | 阅读 10 分钟 | 建议收藏 ⭐

前言

Day 7-10 我讲了 AI 工作流、Obsidian 第二大脑。

进入 Linux 领域——测试工程师必备技能。

我做测试 5 年，前 3 年以前都要用 Linux（服务部署在 Linux 上），但遇到问题就懵：

• 服务挂了不知道怎么查
• 日志满屏不知道看哪里
• 性能慢不知道瓶颈在哪

后来系统学了 Linux + AI 辅助，效率提升 10 倍。

今天讲 3 件事：

1. 30 个常用命令（分组，实战必备）
2. 真实问题排查案例（用命令查分析）
3. AI 辅助定位（ChatGPT + DeepSeek 两个工具实战）

一、基础篇：30 个常用 Linux 命令

测试工程师不需要像运维那么精通，但30 个命令必须会。

1. 文件操作（6 个）

pwd # 当前目录 ls -la # 详细列表（隐藏文件+权限） ls -lh # 人类可读大小 cd /var/log # 绝对路径 cd ../logs # 相对路径 mkdir -p /opt/test/2024 # 递归创建目录 rm -rf /tmp/test # 强制递归删除

3. 文件查看（6 个）

cat # 一次性显示 less # 分页显示（可搜索） head -n 20 # 前 20 行 tail -n 100 # 后 100 行 tail -F # 实时跟踪（看日志变化） wc -l # 统计行数

4. 关键字搜索（4 个）

grep "ERROR" app.log # 关键字搜索 grep -i "error" app.log # 忽略大小写 grep -B 5 -A 5 "error" app.log # 显示前后 5 行 grep -c "error" app.log # 统计出现次数

5. 进程查看（5 个）

ps aux # 所有进程 ps aux --sort=-%cpu | head # 按 CPU 排序 ps aux --sort=-%rss | head # 按内存排序 pgrep -f "java" # 查找进程 kill -9 PID # 杀进程

6. 系统监控（5 个）

top / htop # 实时监控（CPU/内存） free -h # 内存使用 df -h # 磁盘使用 du -sh /opt/test # 目录占用大小 iostat -x 1 # IO 监控

7. 网络工具（4 个）

netstat -tunlp # 端口监听 ss -tunlp # 端口监听（新版） curl http://localhost:8080 # HTTP 请求 ping -c 4 www.baidu.com # 网络连通性

二、理论篇：脚本设计 3 原则

写脚本前，记住 3 个原则：

原则一：通读跑一遍再上线 先在自己机器测试，再上生产 原则二：加 set -e 和错误处理 set -e # 任何命令失败就停止 trap 'echo "Error at line $LINENO"' ERR 原则三：加日志 exec >> /var/log/script.log 2>&1 echo "$(date '+%Y-%m-%d %H:%M:%S') - 开始"

三、实战篇 1：真实问题排查案例

场景：服务响应慢，怎么排查？

某天下午，测试同事反馈："接口响应很慢，几秒才返回。"

下面是完整的排查过程（真实可复用）：

Step 1：看系统整体状态

# 先看 CPU 和内存 top # 看内存使用 free -h # 看磁盘（避免磁盘满导致慢） df -h

输出解读：

• top 第一行：load average: 5.20, 4.80, 4.50（CPU 满载）

Step 2：找最耗资源的进程

# 按 CPU 排序，找最耗 CPU 的进程 ps aux --sort=-%cpu | head -10 # 输出可能看到： # USER PID %CPU %MEM COMMAND # root 1234 95.0 30.0 java -jar app.jar # → 进程 1234 占 CPU 95%

Step 3：看进程详情

# 看进程详情 ls -la /proc/1234/ # 或用 jstack 看线程栈（Java 应用） jstack 1234 | head -100 # 输出可能看到： # "Thread-12" #12 daemon prio=5 # → 某个线程卡住了

Step 4：查日志找原因

# 查 ERROR 日志 tail -200 $LOG_DIR/app.log | grep "ERROR" # 查慢请求 grep "slow" /var/log/app.log | tail -20 # 查数据库慢查询 grep "slow_query" /var/log/mysql/mysql.log

Step 5：定位根因

经过上面 5 步，常见原因：

Step 6：实时跟踪

# 实时跟踪某个进程 top -p 1234 # 实时跟踪日志变化 tail -F /var/log/app/app.log | grep "ERROR" # 查看网络连接 netstat -an | grep ESTABLISHED | wc -l

四、实战篇 2：AI 辅助定位（ChatGPT + DeepSeek）

工具：仅用 ChatGPT 和 DeepSeek 两个 AI 工具。

4.1 用 ChatGPT 辅助排查

场景：Java 应用 OOM（OutOfMemory）异常

Step 1：把错误日志贴给 ChatGPT

我的 Java 应用报错： java.lang.OutOfMemoryError: Java heap space at com.test.service.OrderService.createOrder(OrderService.java:42) at com.test.web.ApiController.handle(ApiController.java:28) 应用启动参数：-Xmx512m -Xms256m 并发用户：约 200 请帮我分析： 1. 最可能的原因是什么？ 2. 给我一些排查命令 3. 推荐解决思路

Step 2：ChatGPT 回复

可能原因： - 堆内存不够（512M 偏小） - 内存泄漏（推荐用 MAT 分析 heap dump） - 大对象未释放 排查命令： # 1. 看 JVM 堆使用 jmap -heap 1234 # 2. 生成 heap dump jmap -dump:format=b,file=heap.bin 1234 # 3. 看 GC 情况 jstat -gc 1234 1000 解决思路： 1. 提高堆内存：-Xmx1024m -Xms512m 2. 用 MAT 工具分析 heap dump 3. 排查代码中的大对象

Step 3：执行 ChatGPT 提供的命令

# 看堆内存配置 jmap -heap 1234 | grep "MaxHeap" # 看 GC 情况 jstat -gc 1234 1000 | head # 输出：发现 Old Gen 占用 95%，确认内存不足

Step 4：让 ChatGPT 解读结果

我的 jstat 输出： S0C S1C S0U S1U EC EU OC OU PC PU 10752K 10752K 0K 0K 65536K 16384K 174784K 166785K ... Old Gen 已用 166M / 175M（95%），Full GC 频繁 请帮我： 1. 这种情况说明什么？ 2. 推荐的最优配置是什么？ 3. 除了改内存，还有什么优化？

ChatGPT 回复：

这种情况说明： - Old Gen 内存紧张，频繁 Full GC - 应用存在大对象或内存泄漏 - 堆内存设置偏小 推荐配置： -Xmx2048m -Xms1024m -XX:NewRatio=2 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/dump 其他优化： 1. 用 MAT 分析 heap dump 2. 优化 SQL（避免大结果集） 3. 用缓存代替重复查询 4. 及时关闭资源

4.2 用 DeepSeek 辅助排查

场景：性能突然下降 50%，找根因。

Step 1：DeepSeek 用中文对话（更符合国内习惯）

我的应用性能监控显示： - CPU 使用率：昨天 30%，今天 80% - 接口响应时间：昨天 100ms，今天 500ms - 数据库连接池：昨天 50%，今天 95% 应用最近 1 天有 2 次发布： 1. 中午 12 点：缓存策略调整 2. 下午 4 点：数据库索引优化 请帮我分析： 1. 哪个发布最可能导致性能下降？ 2. 给我具体排查命令 3. 如何快速验证猜测？

DeepSeek 回复：

最可能：下午 4 点的数据库索引优化 原因： - 索引优化可能导致索引失效或选错索引 - 数据库连接池占用 95% 暗示 SQL 执行慢 快速排查命令： # 1. 看慢查询日志 grep "slow_query" /var/log/mysql/slow.log | wc -l # 2. 看当前执行的 SQL SHOW PROCESSLIST; # 3. 看索引使用情况 EXPLAIN SELECT * FROM orders WHERE ...; # 4. 对比昨天和今天的慢查询数 diff <(grep "slow" /var/log/mysql/slow.log.1) \ <(grep "slow" /var/log/mysql/slow.log)

Step 2：执行命令验证

# 看今天的慢查询数量 grep "slow_query" /var/log/mysql/slow.log | wc -l # 输出：532（昨天只有 89） # 看现在执行的 SQL mysql -e "SHOW PROCESSLIST;" # 发现：有 5 个慢查询卡在 orders 表

Step 3：让 DeepSeek 解读

我查到了： - 今天慢查询 532 条（昨天 89 条） - 当前有 5 个慢查询卡在 orders 表 请帮我： 1. 索引优化的常见错误是什么？ 2. 如何快速修复（回滚 vs 优化 SQL）？ 3. 怎么避免类似问题？

DeepSeek 回复：

索引优化常见错误： 1. 删了被查询依赖的索引 2. 改了索引但没看执行计划 3. 索引顺序错误（联合索引顺序） 4. 函数导致索引失效 快速修复方案： 1. 立即回滚索引（如果有备份） 2. 或用 EXPLAIN 找问题索引 3. 重写有问题的 SQL 避免方法： 1. 索引变更前备份 2. 上线前用 EXPLAIN 验证 3. 灰度发布 4. 加监控告警

五、AI 工具对比：什么时候用哪个？

实战技巧：

ChatGPT 适合： - Java/Python 报错信息 - 国际技术框架问题 - 深度技术解释 DeepSeek 适合： - 中文业务场景 - 复杂逻辑分析 - 长篇代码 review

六、真实数据：AI 辅助排查效果

我做 AI 辅助排查半年：

传统方式：30 分钟查一个问题 AI 辅助：1 小时（5 分钟 AI 提问 + 25 分钟执行） 提效：2 倍（但成功率提升 50%） 关键：AI 提供思路 + 命令，我执行 + 验证

关键认知：

AI 提供思路 + 命令，我执行 + 验证

不是 AI 替代排查，而是AI 加速排查。

七、30 个命令速查表（保存用）

📁 文件操作：pwd / ls / cd / mkdir / rm / find 📄 文件查看：cat / less / head / tail / grep / wc ⚙️ 进程管理：ps / kill / pgrep / pkill / nohup 📊 系统监控：top / htop / free / df / du / iostat 🌐 网络工具：netstat / ss / curl / ping 🔍 关键字搜索：grep / grep -i / grep -B -A / grep -c 🔐 权限用户：chmod / chown / sudo ⏰ 进程监控：top -p / tail -F / nohup & 📦 杂项：history / alias / man

八、写在最后：测试工程师的 Linux 能力

做了 5 年测试，我最大的感受是——

测试工程师不懂 Linux 是短板。

今天：学 5 个 Linux 命令（top/free/df/ps/tail） 本周：每周用 1 次 AI 辅助排查（先 ChatGPT） 90 天：积累 30 个命令 + 10 个真实案例

1 年后回头看，你的 Linux 能力会从 0 到 60+。

下期预告

Day 12：Linux 日志分析 + AI 智能诊断 - 日志位置 + 类型 - 5 款 AI 工具实战演示 - 真实日志排查案例

如果这篇文章对你有帮助：

1. 点赞 + 收藏（建议收藏）
2. 评论区告诉我你最常遇到的 Linux 问题
3. 转发给同样怕 Linux 的测试同事

全文 3800 字 | 阅读 10 分钟 | 建议收藏

【原创声明】本文为楠风测开原创，转载请联系作者授权。