2. 座舱缺陷数据分类与采集：如何建立有效的缺陷数据库？
做座舱开发这些年，我见过太多团队在缺陷管理上栽跟头。说白了，就是「垃圾进，垃圾出」。你采集的数据不准，分类混乱，后面所有分析都是白搭。
今天我们就聊聊，怎么建一个真正能用的缺陷数据库。不是那种为了应付流程填个表就完事的，而是能帮你反推开发过程优化的那种。
2.1 缺陷分类标准：四大维度
我个人习惯把座舱缺陷分成四类：功能、性能、UI/UX、稳定性。这四类覆盖了座舱系统 95% 以上的问题。
| 分类 | 定义 | 典型表现 | 严重等级参考 |
|---|---|---|---|
| 功能缺陷 | 需求规格中定义的功能未实现或实现错误 | 导航无法规划路线、语音唤醒无响应、蓝牙连接失败 | P0-P2 |
| 性能缺陷 | 系统响应时间、资源占用等不满足指标 | 应用启动超过 5 秒、帧率掉到 20fps、内存泄漏 | P1-P3 |
| UI/UX 缺陷 | 界面呈现或交互体验不符合设计规范 | 图标对齐偏差 2px、字体大小不一致、手势冲突 | P2-P4 |
| 稳定性缺陷 | 系统在长时间或异常工况下出现异常 | 死机、黑屏、重启、ANR、系统服务崩溃 | P0-P1 |
关键原则：一个缺陷只归一个类别。如果某个问题既影响功能又影响性能，按最严重的那个维度归类。我在项目中遇到过不少团队把同一个缺陷同时标成「功能+性能」，结果统计时数据全乱了。
2.2 功能缺陷：别把「没做」和「做错了」混在一起
功能缺陷是最直观的。但这里有个坑——很多人把「需求没写」也当成缺陷报上来。嗯，这其实是需求问题，不是开发缺陷。
我建议功能缺陷只包含两类：
- 未实现：需求明确写了，但代码里没有。
- 实现错误：功能做了，但行为与需求不符。
举个例子。需求说「空调温度调节步长为 0.5°C」，结果你调一次跳 1°C。这就是实现错误。如果压根没有温度调节按钮，那就是未实现。
我的习惯：在缺陷数据库里加一个字段叫「需求 ID」，直接关联到具体需求条目。这样后期分析时，一眼就能看出哪个模块的需求实现质量最差。
2.3 性能缺陷：数据说话，别靠感觉
性能问题最怕「我觉得卡」。你想想看，一个座舱系统有几十个应用，每个应用启动时间差个几百毫秒，用户感知完全不同。
我一般要求性能缺陷必须附带以下数据：
- 测试环境：芯片型号、系统版本、内存占用基线
- 测试场景：冷启动/热启动、后台应用数量、是否正在导航
- 量化指标：具体数值（如「启动耗时 4.2 秒」而非「启动慢」）
- 对比基线：目标值是多少，当前值差多少
我曾经踩过的坑：有个团队报了一个「导航卡顿」的缺陷，没有附任何性能数据。开发同学查了两天，发现是测试时后台在下载地图数据。如果当时附上 CPU 和网络占用数据，这个问题 10 分钟就能定位。
2.4 UI/UX 缺陷：像素级对齐，但别钻牛角尖
UI/UX 缺陷是最容易扯皮的。设计师说「这个按钮偏了 1px」，开发说「肉眼根本看不出来」。我的原则是：以设计标注为准，但区分严重等级。
我常用的 UI/UX 缺陷分级：
- P2：功能不可用（如按钮被遮挡无法点击）
- P3：明显视觉偏差（如字体大小错误、颜色用错）
- P4：细微偏差（如间距差 2px 以内、图标轻微偏移）
说实话，P4 级别的缺陷要不要修，看项目节奏。我一般建议在 Beta 阶段集中修复，Alpha 阶段先抓 P2/P3。
2.5 稳定性缺陷：最头疼，也最值钱
稳定性缺陷是座舱系统的「癌症」。它不像功能缺陷那样明确，也不像性能缺陷那样可量化。它往往是偶发的、难以复现的。
我要求稳定性缺陷必须记录：
| 字段 | 说明 | 示例 |
|---|---|---|
| 复现概率 | 测试多少次出现一次 | 5/10（10 次出现 5 次） |
| 触发条件 | 操作步骤 + 环境状态 | 导航 + 音乐播放 + 充电 |
| 日志时间戳 | 问题发生时刻的系统日志 | 2024-03-15 14:23:45 |
| 系统快照 | 内存使用、进程状态、内核日志 | dmesg、logcat、top 输出 |
我的经验：稳定性缺陷的复现步骤越详细越好。我曾经处理过一个「偶发黑屏」问题，测试同学只写了「开车过程中黑屏」。后来我让他加上「当时正在使用 CarPlay + 导航 + 充电」，复现率从 1/20 提升到了 1/3。这就是数据的力量。
2.6 采集工具：选对工具，事半功倍
工具不在多，在于能不能和你的流程打通。我见过团队同时用三个缺陷管理工具，结果数据散落各处，根本没法分析。
我推荐的工具组合：
- Jira / 禅道：缺陷生命周期管理，适合团队协作
- TestRail / Testlink：测试用例与缺陷关联，适合追溯
- Logcat / dmesg：Android 系统日志采集，适合稳定性分析
- Systrace / Perfetto：性能追踪工具，适合性能缺陷定位
- 自建埋点平台：采集用户侧崩溃、ANR 等数据
建议：不管用什么工具，一定要保证缺陷数据能导出为结构化格式（CSV/JSON）。这样后续做数据分析和可视化时，才不会卡在数据清洗上。
2.7 缺陷数据库结构设计
下面是我个人比较推荐的一个缺陷数据库核心字段结构。你可以直接拿去用，也可以根据团队情况调整。
缺陷数据库核心字段（推荐）
--------------------------------
缺陷ID : 自动生成，唯一标识
标题 : 一句话描述问题
分类 : 功能/性能/UI_UX/稳定性
严重等级 : P0/P1/P2/P3/P4
优先级 : High/Medium/Low
状态 : New/Open/Fixed/Verified/Closed
所属模块 : 导航/多媒体/语音/设置/...
需求ID : 关联的需求条目编号
测试环境 : 芯片/系统版本/内存
复现步骤 : 详细操作步骤
期望结果 : 需求或设计规定的行为
实际结果 : 测试观察到的行为
附件 : 截图/日志/视频链接
发现阶段 : 单元测试/集成测试/系统测试/路测
发现日期 : yyyy-MM-dd
指派人 : 负责开发的工程师
修复版本 : 在哪个版本中修复
2.8 本章知识体系
下面这张图把本章的核心逻辑串起来了。从缺陷分类到采集工具，再到数据库结构，每一步都影响着你后续的分析质量。
核心思路：分类标准决定了你采集什么数据，采集工具决定了数据质量，数据库结构决定了你能不能高效分析。这三者缺一不可。我见过太多团队只关注工具，却忽略了分类标准和数据结构，最后数据一堆，分析不出来任何有价值的东西。