4、问题识别与记录：问题来源、严重性分类与高质量报告编写

大家好，我是老张。在ASPICE流程里，问题识别与记录是闭环管理的第一步，也是最容易被忽视的一步。很多团队把问题记录当成“填表”，结果填出来的东西别人看不懂，开发人员也复现不了。今天我们就来聊聊，怎么把这一步做实。

4.1 问题来源：评审、测试、客户反馈

问题的来源其实就三大类：评审、测试、客户反馈。每一类的侧重点都不一样。

4.1.1 评审中发现的问题

评审包括需求评审、设计评审、代码评审。这类问题往往偏“早期”，比如需求歧义、设计缺陷、代码逻辑错误。我个人习惯，评审时发现的问题一定要当场记录，不要等会后回忆。因为评审讨论时信息最密集，一转身就容易漏掉细节。

评审问题的特点：

• 通常涉及文档或代码的修改
• 需要明确责任人（谁写的谁改）
• 严重性往往偏高，因为发现得早

4.1.2 测试中发现的问题

测试问题是最常见的。单元测试、集成测试、系统测试，每个阶段都可能发现问题。这里要注意，测试问题必须包含复现步骤，否则开发人员根本没法修。

我记得有一次，测试人员报了一个“偶发死机”的问题，描述只有一句话：“系统偶尔死机”。开发人员查了两天没找到原因。后来我要求测试人员补充复现步骤和日志，才发现是特定温度下、特定操作序列才会触发。你看，没有复现步骤，问题就变成了玄学。

4.1.3 客户反馈的问题

客户反馈的问题最棘手，因为环境不可控。这类问题通常来自现场，可能是偶发性的，也可能是特定工况下的。处理客户反馈时，我建议优先收集车辆信息、故障码、操作日志。能拿到原始数据最好，拿不到也要尽量还原现场。

4.2 问题严重性与优先级分类

问题来了，先别急着修。先分清楚严重性和优先级。这两个概念容易混淆，我简单解释一下。

严重性：问题本身对系统的影响程度。比如刹车失灵就是致命，界面显示错位就是轻微。

优先级：问题需要被处理的紧急程度。比如一个严重性低但影响发布进度的问题，优先级可能很高。

我常用的分类标准如下：

等级	严重性	优先级	示例
致命	系统崩溃、安全风险	立即修复	刹车无响应、安全气囊误触发
严重	功能失效、数据丢失	高优先级	导航无法定位、空调不制冷
一般	功能异常但可绕行	中等优先级	倒车影像延迟、语音识别不准
轻微	界面问题、体验不佳	低优先级	按钮颜色不对、字体大小不一致

4.3 编写高质量问题报告

问题报告写得好不好，直接决定了修复效率。我见过最差的问题报告就一句话：“系统崩溃了”。这种报告，开发人员看了想打人。高质量的问题报告，至少要包含三要素：重现步骤、环境信息、日志。

4.3.1 重现步骤

重现步骤要写清楚“先做什么、再做什么、最后出现什么”。最好用编号列表，每一步都要精确。比如：

1. 启动车辆，挂D挡
2. 以30km/h匀速行驶
3. 按下方向盘上的“语音助手”按钮
4. 说出“导航到最近的加油站”
5. 系统卡顿3秒后，中控屏黑屏

你看，这样写，开发人员照着做一遍就能复现。如果问题偶发，还要注明“尝试5次出现2次”这样的频率信息。

4.3.2 环境信息

环境信息包括：硬件版本、软件版本、网络状态、温度、电压等。汽车电子尤其要注意供电电压和温度，很多问题都是特定条件下才出现。

我建议用表格来记录环境信息：

项目	内容
ECU型号	VCU_3.2.1
软件版本	SW_2024.08.15
供电电压	12.6V
环境温度	35°C
测试设备	CANoe 12.0

4.3.3 日志

日志是问题分析的“黑匣子”。记录问题时，要附上关键时间段的日志，不要只给一个几十MB的完整日志文件。我习惯在日志里标注出问题发生的时间点，方便开发人员快速定位。

举个例子：

// 问题发生时间：2024-08-20 14:23:45
[14:23:40] INFO: 语音识别模块初始化完成
[14:23:42] INFO: 接收到语音指令 "导航到最近的加油站"
[14:23:43] WARN: GPS信号弱，定位精度下降
[14:23:45] ERROR: 导航模块无响应，超时退出
[14:23:46] FATAL: 中控屏进程崩溃

你看，从日志里能清楚看到：GPS信号弱导致导航模块超时，最终引发崩溃。这就是日志的价值。

4.4 总结

问题识别与记录，说白了就是为后续的根因分析和修复打好基础。你想想看，如果问题报告写得不清不楚，后面所有环节都会受影响。所以，我建议团队建立问题报告模板，强制要求包含重现步骤、环境信息和日志。刚开始大家可能觉得麻烦，但习惯了之后，你会发现修复效率提升了一大截。

嗯，今天就聊到这里。下一节我们讲根因分析，到时候我会分享一些实战中常用的分析工具和方法。