2. 日志排查常用命令怎么用
日志排查是测试工程师在 Linux 环境中最常用、也最能体现问题定位能力的技能之一。很多功能 Bug、接口 Bug、环境 Bug，页面上只会表现为“系统异常”“接口失败”“操作无响应”，但真正的原因往往藏在服务日志里。测试人员如果只会截图页面现象，开发还需要重新复现；如果你能带着接口时间点、请求参数、订单号、用户 ID 和日志关键异常一起提 Bug，定位效率会高很多。
日志排查不是简单地打开文件看几行，也不是背几个命令就够了。真正有效的日志排查需要建立一条清晰链路：用户做了什么操作，接口什么时候被调用，请求参数里有什么业务标识，服务日志有没有进入对应方法，是否打印了异常堆栈，数据库或第三方服务调用是否失败，最终响应为什么返回错误。掌握这条链路，日志命令才有价值。
一、测试为什么要会查日志
测试环境里的很多问题，前端页面看不到细节，接口响应也可能只返回通用错误。例如：
- 页面提示“系统繁忙”，但不知道具体异常；
- 接口返回 500，但响应体没有堆栈；
- 支付失败，但不确定是支付接口失败还是回调处理失败；
- 文件上传失败，但不确定是权限、路径还是大小限制；
- 自动化用例失败，但不确定是数据问题还是服务异常；
- 测试环境部署后访问异常，但不知道服务启动时哪里报错。
这些都需要看日志。日志能帮助测试判断问题归属，是前端传参错误、后端逻辑异常、数据库异常、第三方服务异常、配置错误，还是环境资源问题。
二、日志排查常用命令
1. tail 实时查看日志
tail -f 是测试最常用命令之一。它可以实时查看日志输出。比如你准备复现一个接口问题，可以先打开日志：
tail -f application.log
然后在页面或 Postman 中操作，观察日志是否打印对应请求和异常。
如果只想看最近 200 行，可以用：
tail -n 200 application.log
接口刚刚失败时，查看最近日志通常比从头翻文件更高效。
2. grep 搜索关键字
日志文件很大时，grep 是核心工具。常见搜索关键字包括：订单号、手机号、用户 ID、接口路径、ERROR、Exception、TraceId。
grep "ERROR" application.log
grep "NO202604300001" application.log
grep -n "Exception" application.log
-n 可以显示行号，方便继续用 less 定位上下文。
3. less 分页查看大文件
大日志不要直接 cat，容易刷屏。less 可以分页查看，还能搜索。
less application.log
进入后输入 /关键字 搜索，按 n 跳到下一个匹配。这个方式适合看异常上下文。
4. wc 统计行数
wc -l application.log
这个命令不常用于定位具体 Bug，但可以了解日志规模。有时日志突然暴增，也能提示服务可能在频繁报错。
5. 根据时间范围排查
如果知道问题发生在 10:30 左右，可以先按时间关键字搜索：
grep "10:30" application.log
更规范的日志通常会带日期时间、线程、日志级别、类名、TraceId。测试提 Bug 时最好记录精确操作时间，方便开发按时间查。
三、日志里重点看什么
1. ERROR 和 Exception
ERROR、Exception、NullPointerException、SQLSyntaxErrorException、Timeout、Connection refused 都是常见异常关键字。
但不要只截一行错误。很多异常需要看上下文，比如请求参数、调用链、根因异常。提交 Bug 时可以截取关键堆栈，不要贴几千行无关日志。
2. 业务关键字
订单号、用户 ID、手机号、支付流水号、优惠券 ID、工单号等，是定位具体业务问题的关键。如果日志里有这些字段，就能快速关联到用户操作。
3. TraceId / RequestId
很多系统会在每次请求生成 TraceId。测试抓包或接口响应里如果能拿到 TraceId，再到日志里搜索，就能定位完整调用链。
4. 第三方接口调用结果
支付、短信、地图、文件存储、风控等第三方服务异常，通常会在日志中体现请求和响应。测试要关注是本系统处理失败，还是依赖服务返回失败。
5. SQL 或数据库异常
比如字段为空、唯一键冲突、SQL 语法错误、连接超时、事务回滚。数据库异常常会导致接口 500 或业务状态不一致。
四、典型场景：接口返回 500 怎么查日志
处理步骤可以这样：
- 记录接口请求时间；
- 记录请求参数和业务 ID；
- 登录测试服务器；
- 用
tail -n 200查看最近日志； - 用
grep搜索订单号、用户 ID 或 TraceId； - 找到 ERROR 或 Exception；
- 看异常前后的上下文；
- 判断是参数问题、代码异常、数据库异常还是第三方服务异常；
- 整理证据提交 Bug；
- 修复后用相同数据和相关边界场景回归。
面试时可以这样讲：
如果接口返回 500，我不会只截图响应。我会先记录请求时间和关键业务参数，比如订单号或用户 ID，然后到服务器日志里用
tail看最近日志，用grep搜索业务关键字或 ERROR。如果日志里有异常堆栈，我会结合请求参数判断是后端空指针、数据库异常、第三方接口超时还是配置问题。提 Bug 时会附上接口请求、响应和关键日志，方便开发定位。
五、典型场景：支付失败日志怎么查
支付失败通常涉及多个环节：创建支付单、调用支付渠道、接收支付回调、更新订单状态、写支付流水。
日志排查不能只看一个接口。应该按流程查：
- 创建支付请求是否成功；
- 支付渠道返回什么；
- 是否收到回调；
- 回调验签是否通过；
- 订单状态是否更新；
- 支付流水是否写入；
- 是否有重复回调或幂等拦截。
可以根据订单号或支付流水号搜索：
grep "NO202604300001" application.log
grep "PAY202604300001" application.log
如果日志显示支付渠道成功，但订单状态没更新，就要继续查回调和数据库更新逻辑。
六、日志排查常见误区
1. 只搜 ERROR
有些业务失败不一定是 ERROR，可能是 WARN 或业务 code。要结合订单号、接口路径、TraceId 搜索。
2. 不记录操作时间
没有时间点，查日志会非常低效。提 Bug 时一定记录大概操作时间。
3. 只截最后一行异常
异常堆栈要看根因，有时最后一行只是包装异常，真正原因在 Caused by 后面。
4. 查错服务日志
微服务项目里一个业务可能经过多个服务。要确认问题发生在哪个服务，不要一直查错日志文件。
5. 忽略测试数据
日志显示参数为空或状态不允许时，可能是测试数据前置条件不对。要先确认数据状态。
七、日志证据怎么写进 Bug
一个高质量 Bug 可以这样写：
操作时间：2026-04-30 10:32
测试账号：tester01
订单号：NO202604300001
接口：POST /api/orders/pay
现象：接口返回 500，页面提示系统异常
日志关键异常：NullPointerException at PaymentService.pay(...)
初步判断：支付接口处理优惠券字段为空时未做判空
这样的 Bug 比“支付失败”清晰很多。
八、面试回答模板
如果面试官问“日志排查常用命令怎么用”，可以这样答：
我平时主要用
tail、grep、less查日志。复现问题前会用tail -f实时看日志；问题已经发生后会用tail -n看最近日志；日志较大时会用grep按订单号、用户 ID、TraceId、ERROR、Exception 搜索；需要看上下文时用less分页查看。比如接口返回 500，我会记录请求时间和业务 ID，再搜索日志中的异常堆栈，结合请求参数判断是后端逻辑、数据库、第三方服务还是测试数据问题。
九、常见追问
追问：日志很大怎么查？
可以用 tail -n 看最近日志，用 grep 搜索关键字，用 less 分页查看。不要直接 cat 大文件。
追问：只有页面报错，没有接口信息怎么办？
先用浏览器开发者工具或抓包工具找到对应接口，再记录请求时间、接口路径和业务 ID，然后到服务器日志中搜索。不要只凭页面现象判断后端问题。
追问：日志里没有 ERROR 怎么办？
可以搜索业务 ID、接口路径、WARN、业务 code、TraceId。也要确认日志级别是否配置正确、是否查对服务和文件。
追问：怎么判断是不是测试数据问题？
查看请求参数和数据库状态，确认账号、订单、权限、状态流转是否满足前置条件。如果数据状态本身不对，要先修正测试数据再复测。
十、练习清单
- 用
tail -f实时查看日志； - 用
tail -n 200查看最近日志； - 用
grep ERROR搜索错误； - 用订单号搜索完整业务链路；
- 用
less查看大文件上下文； - 记录一次接口失败的操作时间；
- 整理一次日志证据；
- 区分 ERROR、WARN 和业务失败；
- 从异常堆栈中找到根因；
- 准备日志排查面试回答。
日志排查是测试定位能力的基本功。你不需要会所有 Linux 命令，但必须能围绕业务问题，用日志把现象和原因连接起来。
配套刷题：
