📋 文档说明
适用对象:软件测试工程师
文档目的:快速定位和分析系统稳定性问题
最后更新:基于实际项目经验总结
🚨 紧急问题快速定位
1. 五分钟问题定位法
# 第一步:搜索最严重问题
grep "dgt and det match" log.txt -A 20
grep "vm reboot" log.txt -A 10
grep "System hang" log.txt -A 6
# 第二步:检查问题摘要
grep "sum:" log.txt -A 5 -B 2
# 第三步:统计问题频率
echo "严重重启: $(grep "vm reboot" log.txt | wc -l)"
echo "系统卡顿: $(grep "system hang" log.txt | wc -l)"
echo "内核崩溃: $(grep "panic" kernel_log.txt | wc -l)"
2. 问题严重度分级表
| 级别 |
日志特征 |
测试关注度 |
| P0-紧急 |
vm reboot: Watchdog + dgt and det match |
⭐⭐⭐⭐⭐ |
| P1-严重 |
System hang: FW Slow Critical |
⭐⭐⭐⭐ |
| P2-重要 |
System hang: FW Slow |
⭐⭐⭐ |
| P3-一般 |
应用层ANR/FC |
⭐⭐ |
🔍 核心日志文件识别
必须检查的文件列表
# 按优先级排序的文件检查清单
文件1: kernel_log.txt # 内核日志 - 最最重要!
文件2: system_log.txt # 系统日志
文件3: lastkmsg # 最后一次内核消息
文件4: power_log.txt # 电源日志
文件5: modem_log.txt # 基带日志
文件内容速查表
| 文件 |
包含内容 |
搜索关键词 |
| kernel_log.txt |
内核panic、watchdog、驱动错误 |
panic, watchdog, error |
| system_log.txt |
系统服务崩溃、ANR |
crash, ANR, died |
| lastkmsg |
死机前的最后消息 |
同kernel_log |
| power_log.txt |
充电、电池、重启 |
shutdown, reboot, battery |
📊 关键日志模式解析
1. 系统重启类型判断
# 重启原因快速诊断
grep -i "poweroff.*ps_hold" kernel_log.txt # 正常重启
grep -i "poweroff.*AP_WDT" kernel_log.txt # 看门狗卡死
grep -i "kernel.*panic" kernel_log.txt # 内核崩溃
grep -i "thermal.*shutdown" kernel_log.txt # 过热保护
2. 重启原因对照表
| 重启类型 |
日志特征 |
严重程度 |
责任团队 |
| 正常重启 |
ps_hold + reboot,1000,system |
低 |
系统组 |
| 看门狗重启 |
AP_WDT + vm reboot |
高 |
框架组 |
| 内核崩溃 |
Kernel panic + 调用栈 |
高 |
驱动组 |
| 温度保护 |
thermal + shutdown |
中 |
硬件组 |
🎯 问题根因分析技巧
1. 上层问题 vs 底层问题判断
上层问题特征(应用/框架层):
# 进程名特征
process: system_server
process: com.android.*
# 包名特征
android.os.xxx
com.android.server.xxx
# 问题类型
Blocked in monitor [Service]
ANR in [App]
底层问题特征(驱动/内核层):
# 内核特征
Kernel panic
[驱动名] timeout
hardware error
# 硬件特征
PMIC, thermal, memory
2. 问题频率分析方法
# 统计相同问题的发生次数
grep "dgt: 3aec0d1ba4928627b9b0c56266d64af2" log.txt | wc -l
# 查看问题时间分布
grep "system hang" log.txt | cut -d' ' -f4 | sort | uniq -c
📝 测试问题报告模板
问题报告标准格式
【问题标题】
[组件名]发生[问题类型]导致系统[影响程度]
【问题现象】
- 用户可见现象描述
- 发生时的操作步骤
- 问题复现概率
【日志证据】
- 关键日志时间:2025-11-21 10:35:23
- 问题类型:vm reboot / system hang
- 错误摘要:[粘贴sum字段]
- 调用栈关键点:[粘贴det关键行]
- 问题指纹:dgt: xxxxxxxxx
【重现建议】
- 测试步骤详细描述
- 重点关注的操作
- 监控指标建议
【初步分析】
- 问题层级:[上层/底层]
- 影响范围:[系统级/应用级]
- 怀疑方向:[具体组件或服务]
🔧 实战分析脚本集
1. 快速日志分析脚本
#!/bin/bash
# quick_analysis.sh
echo "=== 系统稳定性快速分析 ==="
echo "检查时间: $(date)"
echo -e "\n1. 严重错误统计:"
echo "vm reboot: $(grep -c "vm reboot" kernel_log.txt)"
echo "System hang: $(grep -c "system hang" system_log.txt)"
echo "Kernel panic: $(grep -c "panic" kernel_log.txt)"
echo -e "\n2. 最近严重错误:"
grep "dgt and det match" system_log.txt -A 5 | tail -10
echo -e "\n3. 高频问题指纹:"
grep "dgt:" system_log.txt | cut -d' ' -f3 | sort | uniq -c | sort -nr | head -5
2. 重启原因分析脚本
#!/bin/bash
# reboot_analyzer.sh
echo "=== 重启原因分析 ==="
grep -i "poweroff\|reboot" kernel_log.txt | grep -v "normal" | head -10
echo -e "\n重启类型分布:"
echo "正常重启(ps_hold): $(grep -c "ps_hold" kernel_log.txt)"
echo "看门狗重启(AP_WDT): $(grep -c "AP_WDT" kernel_log.txt)"
echo "内核崩溃(panic): $(grep -c "panic" kernel_log.txt)"
🎓 测试场景与日志对应关系
常用测试场景的日志关注点
| 测试类型 |
重点监控日志 |
关键指标 |
| 压力测试 |
system_log.txt中的ANR |
响应时间、卡顿次数 |
| 稳定性测试 |
kernel_log.txt中的panic |
死机重启次数 |
| 功耗测试 |
power_log.txt |
电量消耗、充电状态 |
| 性能测试 |
perf_log.txt |
CPU频率、帧率 |
| 兼容性测试 |
system_log.txt中的FC |
应用崩溃次数 |
💡 高级技巧与注意事项
1. 时间线分析方法
# 找到问题时间点,查看前后日志
grep -B 50 -A 20 "2025-11-21 10:35:23" system_log.txt
# 或者按时间范围提取
sed -n '/2025-11-21 10:30:00/,/2025-11-21 10:40:00/p' system_log.txt
2. 跨日志关联分析
- 系统卡顿(system_log) → 可能导致看门狗重启(kernel_log)
- 应用崩溃(system_log) → 可能引发框架死锁(system_log)
- 温度过高(power_log) → 可能触发温控重启(kernel_log)
3. 避免的常见误区
- ❌ 只看应用日志,忽略系统日志
- ❌ 只关注错误数量,不分析错误类型
- ❌ 不查看错误上下文,断章取义
- ❌ 忽略问题发生的时间模式
📞 研发沟通话术
有效的问题描述
"在压力测试中发现系统频繁重启,从日志看是InputManagerService在监视器线程上死锁,
阻塞了61秒后触发看门狗重启。dgt指纹是e2f0317...,在8小时内发生了5次。"
问题升级标准
- 立即升级:P0问题 + 高频发生 + 影响主干功能
- 正常处理:P1问题 + 中低频发生 + 影响次要功能
- 观察记录:P2/P3问题 + 偶发 + 不影响功能
🔄 持续学习建议
日常积累
- 建立问题案例库:记录典型问题的日志特征
- 总结模式识别:同类问题的共同特征
- 跟踪问题修复:验证修复后的日志变化
技能提升
- 学习Linux内核基础:理解panic、watchdog机制
- 掌握Android框架:了解系统服务工作原理
- 熟悉高通平台:掌握芯片特有日志格式
文档维护提示:随着项目进展,不断补充新的问题案例和分析方法,保持文档的实用性。