automotive-testcase-generator

面向车载（汽车电子/智能网联）领域的标准化测试用例生成技能。 当用户提到以下内容时触发：车载测试、汽车电子、ECU、CAN/CAN FD/LIN/FlexRay/ 车载以太网、SOME/IP、UDS/OBD 诊断、DTC、域控制器、智能座舱、IVI 车机、仪表、 T-BOX、ADAS/智能驾驶、HIL 测试、功能安全 ISO 26262、ASPICE、CANoe/CAPL、OTA、 车载软件测试、汽车功能测试等需求的测试用例生成。 输入需求文档（Markdown/PDF/Word/Excel）或需求描述，输出按车载模块分组的、 带优先级着色与模块分隔行的结构化 Excel 测试用例文件。 不适用于：机器人/工业/视觉领域（请使用对应领域技能）、自动化测试脚本生成、测试执行。

车载测试用例生成器（Automotive Test Case Generator）

定位: 面向车载（汽车电子/智能网联）领域，从需求输出标准化、可追溯、可直接导入用例管理平台的 Excel 测试用例。 独立性声明: 本技能为车载领域专用，不引用其他领域技能；模块前缀、质量属性、设计方法均为车载化定义。

---

第一步：判断输入模式

在开始任何阶段之前，先判断输入规模：

输入	模式	执行策略
1 个文件 / 1 段需求描述	单文档模式	五阶段完整执行
2-3 个文件	小批量模式	逐个文档执行阶段二~三
> 3 个文件	批量模式	见下方批量模式说明

批量模式执行策略

text

输入：N个需求文档（N > 3）
         │
         ▼
阶段一：一次性扫全部文档 → 生成全局车载模块图（含域间信号/总线依赖）
         │
         ▼
阶段二~三：逐个文档执行（每个文档重复以下循环）
  ┌──────────────────────────────────────┐
  │  文档i：阶段二（需求提取）           │
  │       → 阶段三（设计+生成用例）       │
  │       → 暂存本模块用例               │
  └──────────────────────────────────────┘
         │
         ▼
阶段四：合并全部文档结果 → Excel（按模块分组，分隔行）

关键约束（防止 token 稀释）：

• 每个文档独立执行阶段二~三，不允许同时处理多个文档
• 每个文档生成的用例数不得少于 min(10, 可测需求数*2)
• 全局模块图（阶段一输出）作为后续每个文档的共享上下文

---

阶段一：车载模块识别与分层

由 AI 执行，无需脚本。

1.1 模块识别

扫描文档，识别涉及的车载功能模块。以域控制器/子系统粒度划分，参考下方前缀表命名，并在文档出现新模块时补充到模块图中。每个模块记录：

• 模块名称 — 如「智能座舱域」「车身域 BCM」「网关 GW」
• 核心功能 — 该模块承担的功能清单
• 关键信号/服务 — CAN 信号、SOME/IP 服务、UDS 服务等
• 状态流转 — 上下电、休眠唤醒、生命周期
• 域间交互 — 与其他模块的总线/信号依赖

1.2 车载模块前缀表（编号规则）

模块	前缀	示例
智能座舱域	CSN	TC-CSN-001
信息娱乐系统 IVI	IVI	TC-IVI-001
仪表盘 CLU	CLU	TC-CLU-001
车身域 BCM	BCM	TC-BCM-001
动力域/VCU	PWR	TC-PWR-001
底盘域（ABS/ESP）	CHS	TC-CHS-001
智能驾驶 ADAS	ADAS	TC-ADAS-001
网关 GW	GW	TC-GW-001
T-BOX / 车联网	TBOX	TC-TBOX-001
OTA 升级	OTA	TC-OTA-001
诊断服务	DIAG	TC-DIAG-001
总线网络	NET	TC-NET-001
功能安全	FUSA	TC-FUSA-001
网络安全	CSEC	TC-CSEC-001

新模块出现时，按 模块名英文缩写（≤4位大写字母） 规则自建前缀，保持全局唯一。

1.3 业务分层与最少用例数

层级	定义	测试深度
核心层	无此模块车辆不可用（如动力、制动相关）	穷尽各种场景（≥7条）
重要层	影响体验/安全但不阻塞（如座舱、IVI）	主流程+关键异常（≥5条）
辅助层	锦上添花（如氛围灯、主题）	仅主流程（≥3条）
基础层	通用能力（如日志、参数配置）	基本功能验证（≥2条）

安全相关模块（制动/转向/安全气囊相关）一律按核心层处理，且必须包含故障注入与降级用例。

1.4 输出格式

json

{
  "模块": [{
    "名称": "智能座舱域", "层级": "核心层", "前缀": "CSN",
    "核心功能": ["多屏交互", "语音助手"],
    "关键信号/服务": ["屏幕亮度信号", "语音识别服务"],
    "状态流转": ["下电→唤醒→运行→休眠"],
    "关联模块": ["IVI", "网关GW", "T-BOX"],
    "最少用例数": 8
  }]
}

批量模式下，所有文档的模块合并到一个 phase1_modules.json，标注 源文件 字段。

---

阶段二：需求提取与分类

由 AI 执行。

2.1 需求提取

从文档中提取每条可验证的需求，不遗漏。车载需求常以「功能需求」「网络需求」「诊断需求」「性能需求」形式出现，分类标记。同时提取每条需求引用的国标/行标/企标（如 GB/T 28046-2019、QC/T 系列、主机厂企标编号），无引用时标注 [无标准引用]。

2.2 复杂度来源分类

复杂度来源	识别信号（车载示例）
输入空间	车速/温度/电压范围、报文信号值域、输入长度限制
状态组合	上下电、休眠/唤醒、驾驶模式切换、诊断会话切换
条件逻辑	多传感器融合判定、安全条件多因素判断
流程步骤	启动流程、OTA 升级流程、刷写流程、蓝牙配对流程
配置组合	车型/配置项组合、区域版本、多语言、多分辨率

2.3 车载质量属性标记

质量属性	触发条件（车载示例）
功能	功能行为描述
网络/协议	总线报文、周期、信号、超时、错误帧
诊断	UDS/OBD 服务、DTC、刷写
性能	响应时间、启动时间、流畅度、吞吐
可靠性	掉电保护、异常恢复、长时间运行、总线断连
功能安全	安全机制、失效降级、ASIL 相关
网络安全	身份认证、加密、防入侵、SecOC
环境/EMC	高低温、振动、电压波动、抗扰
兼容性	车型/硬件版本/软件版本/协议版本
标准合规	需求引用国标/行标/企标或强制认证要求
易用性	HMI/交互类模块：操作效率、误操作防护、可学习性、反馈清晰

2.4 需求可测性检查

可测性状态	定义	处理方式
可测	输入输出明确，结果可验证	正常生成用例
不可测	描述模糊（如"体验流畅"）	标记不可测，不生成用例
需澄清	缺少关键细节	做合理假设，标注[假设]

2.5 输出格式

json

{
  "源文件": "01-座舱需求.md",
  "需求": [{
    "编号": "REQ-CSN-001", "描述": "车机冷启动时间不超过 10s",
    "模块": "智能座舱域", "复杂度来源": ["性能", "流程步骤"],
    "质量属性": ["性能", "可靠性"], "引用标准": ["[无标准引用]"], "可测性": "可测"
  }]
}

---

2.6 需求完备性提示（隐含关注点）

需求未明示但按领域惯例隐含的关注点，默认覆盖或标注 [隐含项] 提示澄清，不得直接忽略：

需求类型	隐含关注点（需求未明示也须覆盖或澄清）
语音助手	误唤醒率、抗噪（风噪/胎噪/音乐场景）、热词混淆
车云通信/远程	数据传输加密（TLS）、隐私数据脱敏、日志保护
电源管理	唤醒源清单、休眠进入条件、静态电流分状态
诊断	安全访问锁定策略、会话超时回默认、刷写中断恢复
OTA	签名校验、版本回滚、失败上限、多 ECU 协同
ADAS/智驾	误触发率、边界触发距离、传感器失效降级

---

阶段三：测试设计 + 用例生成

3.0 四层深度硬约束模板

每个模块必须严格按以下四层模板生成用例，不允许跳过任何一层。这是硬约束，不是建议。

text

┌─ 第一层：主流程（至少 1 条 P0）───────────────┐
│  模块核心路径正向走通（如：上电→功能正常→下电）      │
│  步骤数: 4-5 步                                 │
└─────────────────────────────────────────────┘

┌─ 第二层：业务分层（至少 2 条 P1）──────────────┐
│  ├─ UI/交互元素 + 逻辑（按钮、菜单、弹窗）        │
│  ├─ 信号/字段边界（0/空值/最小/最大/特殊格式）     │
│  └─ 元素/信号组合（多屏联动、车速联动亮度）        │
│  步骤数: 3-4 步                                 │
└─────────────────────────────────────────────┘

┌─ 第三层：黑盒方法（至少 3 种不同方法）──────────┐
│  场景法 / 边界分析 / 等价类 / 判定表 / 状态迁移 /  │
│  故障注入 / 错误猜测（选3种以上，正反向都要）       │
└─────────────────────────────────────────────┘

┌─ 第四层：探索性（每模块至少 2 条 P3，──────────┐
│  占比为参考值（建议 10%~30%，不强制））                       │
│  极端数据 / 特殊操作 / 环境异常（总线断连、电压跌落）/ │
│  数据一致性（显示 vs 信号核对）/ 隐式推测          │
│  步骤数: 3 步                                   │
└─────────────────────────────────────────────┘

3.1 每层完成检查

逐层检查，当前层不通过不进下一层：

层	完成标志	不通过怎么办
第一层	≥1 条 P0 主流程	写不出 → 需求理解不够 → 回头重读需求
第二层	≥2 条 P1（信号边界+组合）	写不出 → 漏了交互/信号细节 → 重扫模块要素
第三层	≥3 种不同方法	写不出 → 对照复杂度来源表重新分析
第四层	≥2 条探索性（占比参考 10%~30%）	写不出 → 错误猜测法想 2 个风险点

3.2 车载设计方法选择矩阵

复杂度来源	推荐方法	覆盖目标
输入空间	边界分析 + 等价类划分	车速/电压/温度边界、有效/无效值域
状态组合	状态迁移法	上下电/休眠唤醒/模式切换，含非法转换
条件逻辑	判定表法	安全条件组合、多条件报警
流程步骤	场景法	启动/刷写/OTA/配对流主路径与分支
总线/网络	故障注入 + 场景法	丢帧/错帧/超时/错误帧/断线恢复
诊断	状态迁移 + 场景法	会话切换、DTC 生命周期、安全访问
配置组合	Pairwise（参数≥6时）	车型/配置项组合

3.3 方法数量约束

每个模块至少使用 3 种不同设计方法；单文档所有用例至少覆盖 4 种方法。安全相关模块必须包含故障注入方法。

3.4 车载异常场景分类

异常测试覆盖以下六类，每个模块至少覆盖输入+流程+环境三类（安全模块还须覆盖安全/状态异常）：

异常类别	说明	用例示例
输入异常	无效格式、越界值、空值	车速信号越界 → 仪表显示降级
流程异常	流程中断、回退、重复触发	OTA 升级中断 → 状态保持可恢复
环境异常	总线断连、电压跌落、温度异常、信号丢失	CAN 断线 → 相关功能进入安全状态
权限异常	未认证、越权、安全访问失败	诊断安全访问失败 → 拒绝并锁定
数据异常	无效 DTC、重复数据、关联缺失	读取不存在的 DTC → 返回正确负响应
状态异常	非法状态转换、重复操作	休眠中触发唤醒请求 → 正常唤醒

3.5 优先级分配

优先级	分配规则	占比参考
P0	核心层主流程 + 安全相关 + 阻塞性异常	10-20%
P1	核心层分支 + 重要层主流程 + 关键边界	30-40%
P2	核心层非关键 + 重要层异常 + 辅助层主流程	30-40%
P3	极端边界 + 低频场景 + 探索性测试	参考 10-30%

3.6 测试数据生成规则

按以下优先级生成具体值：

1. 边界值数据 — 车速 0/30/120/最高限值、电压 9/12/16V、温度 -40/-20/85/125℃
2. 有效等价类数据 — 合规范围内的典型值（如 CAN 周期 10/20/100ms）
3. 无效等价类数据 — 每个违规类型各一条（超长报文、非法 DTC、越界信号）
4. 特殊值数据 — 空值、0xFF、全 0、全 1、异常长度

总线报文、信号值、DTC 编号等使用测试专用假值，标注 [测试数据] 前缀；涉及真实车辆数据一律脱敏。

3.7 用例字段结构与输出格式

固定规范以 references/format-spec.md 为准（生成时必读，不得偏离）。字段速览： 用例编号 / 业务域模块 / 优先级 / 测试维度 / 用例类型 / 设计方法 / 测试场景 / 测试点 / 操作步骤(3-5步) / 测试数据 / 前置条件 / 需求来源 / 总线信号 / 测试环境 / 测试级别。 输出 JSON 结构见 format-spec.md 第 3 节。

3.9 车载领域设计模板（遇到对应功能直接套用）

模板 A：CAN 总线报文场景（网络/鲁棒性）

1. 正常周期报文 → 信号值正确解析、显示一致
2. 报文周期超时（>3 倍周期）→ 信号进入替代值/默认值，相关功能降级或报警
3. 注入错误帧（CRC/位错误）→ ECU 忽略该帧，不影响后续通信
4. 丢帧 → 错误计数递增，不产生误动作
5. 总线恢复 → 信号恢复正常，无报错残留、无需复位

模板 B：UDS 诊断流程（诊断类必套）

1. 会话切换：默认 10 01 → 扩展 10 03（刷写场景用编程会话 10 02）
2. 安全访问 27：正确密钥成功 / 错误密钥失败 / 连续失败 N 次锁定（验证锁定与解锁策略）
3. 读 DTC 19 02：无故障 → 返回无 DTC；有故障 → DTC 状态位（确认/待确认/历史）正确
4. 清 DTC 14 → 验证清除且状态位归零，同时不影响未完成诊断
5. 负响应验证：非法服务 → NRC 11（不支持）；参数非法 → NRC 31（请求超出范围）

模板 C：OTA 升级（车联网/座舱升级必套）

1. 升级前检查：版本比对、存储空间、供电/电量条件、车辆状态（不允许行驶中升级）
2. 下载：断点续传；下载中断 → 状态保持可重试，不损坏
3. 安装：安装中断/断电 → 自动回滚旧版本，可再次升级
4. 升级后：版本确认、签名校验、核心功能回归、升级失败次数上限与提示

模板 D：ADAS 场景（智驾功能必套）

1. 场景要素组合：目标类型（行人/车辆/两轮车）× 相对速度 × 距离 × 天气（晴/雨/雾）× 光照（昼/夜）× 车道（直道/弯道）
2. 预期 = 功能触发（FCW/AEB/车道保持）或明确不触发，边界用「最近/最远触发距离、最小速度差」
3. 传感器失效场景：摄像头/雷达失效 → 功能降级提示，无虚假制动

3.10 模块-维度覆盖矩阵（深化约束）

设计完成后，每个模块对照矩阵自查：核心层模块至少覆盖 7 个测试维度，重要层至少 5 个（功能/网络/诊断/性能/可靠性/功能安全/网络安全/环境EMC/兼容性）。在输出 Excel 时按「模块 × 测试维度」核对覆盖，缺项补用例。

3.11 车载专项测试（区别于常规功能/异常/边界测试）

需求或模块涉及以下专项时，按专项测试生成用例（同样遵循四层深度硬约束；前置条件必须标注专项设备/环境，如电波暗室、HIL、环境箱）：

专项测试	触发条件	用例要点
EMC 测试	涉及 EMC 要求（ISO 11452 抗扰 / CISPR 25 发射 / ISO 7637 瞬态）	辐射抗扰、传导发射、电压瞬态（抛负载）、等级 A/B/C 判定
环境可靠性	涉及温湿度/振动/盐雾/IP 等级（ISO 16750 / GB/T 28046）	高低温运行、温度循环、振动耐久、盐雾、防尘防水
功能安全	涉及 ASIL 等级/安全机制（ISO 26262）	故障注入、安全机制验证（看门狗/ECC/信号合理性）、进入安全状态时间
网络安全	涉及车云通信/诊断安全/OTA 安全（ISO 21434）	SecOC、安全启动、诊断安全访问、通信加密、渗透测试
ADAS 场景测试	智驾/辅助驾驶功能	法规场景（NCAP / UN R152）+ 自定义场景，仿真+实车，边界触发距离
协议一致性	涉及总线协议实现	CAN 一致性、SOME/IP 服务一致性、DBC 信号对齐
耐久/路试	量产前可靠性验证	台架耐久、温度循环、整车路试里程
OTA 专项	涉及升级功能	版本管理、断点续传、回滚、多 ECU 协同、失败恢复
电源管理	涉及休眠/唤醒/静态电流	静态电流、唤醒风暴、电压跌落恢复、掉电保护

专项用例的「测试环境」列必须写明专项设备（电波暗室/HIL/环境箱/振动台/路试车辆），不可写通用台架。

3.12 标准合规要求（国标/行标/企标）

标准是验收依据，不是背景知识。 车载领域强标准监管，按以下规则生成合规用例：

1. 标准识别：阶段二已提取每条需求的 引用标准；需求未注明时，按知识库「标准与规范体系」用领域默认标准兜底
2. 标准优先级：强制国标（GB）> 推荐国标（GB/T）> 行标（QC/T 等）> 企标（主机厂规范）；企标严于国标时以企标为验收线，冲突取更严值；强制国标为底线不可豁免
3. 合规用例生成：标准条款 → 验证方法 → 判定准则，逐条成例：
   • 环境/EMC 类：按标准的试验条件（温度范围、试验等级）写前置条件与参数
   • 安全类：按标准的安全要求验证安全机制与响应时间
   • 性能类：按标准的指标限值写判定准则
4. 判定准则：用例「预期」必须引用标准限值（如 GB/T 28046-2019 高温 +85℃ 运行 1000h 功能正常）
5. 标准版本：注明标准号+年份（如 GB/T 28046-2019），不同版本限值可能不同
6. 合规用例的「测试维度」标为「标准合规」，需求来源列同时关联需求编号与标准号
7. 试验项级门禁（硬性）：标准覆盖率按「试验项」统计而非需求统计——引用标准的需求，对照 references/domain-knowledge.md「标准-试验项矩阵」逐项勾选试验项，每项至少 1 条合规用例（如 GB/T 28046.4 的低温/高温/温循/湿热/盐雾/日照、EMC 的辐射抗扰/传导抗扰/ESD/瞬态/发射）；覆盖统计 sheet 输出「标准 × 试验项 × 用例数」矩阵，试验项覆盖率 100% 为硬性验收线，缺项直接补用例

3.13 测试级别分配与回归指引

测试级别（执行层级）：每条用例的「测试级别」列按以下规则分配：

测试级别	定义	用例倾向
单元级	单模块/单 ECU 逻辑	逻辑边界、异常
集成级	模块间交互、总线通信、接口	通信、时序、互操作
系统级	端到端功能、跨域联动	主流程、组合场景
验收级	指标验收、标准合规、专项	精度、EMC、环境、合规

执行层级映射：

执行层级	适用场景	用例倾向
MIL/SIL	模型/软件在环	控制逻辑、算法函数
HIL	硬件在环（ECU 实物+总线仿真）	网络、诊断、信号交互
台架	系统级台架	端到端功能、上下电
实车	整车道路	验收、场景、路试

冒烟/回归快速用例优先落在 HIL 或仿真层级；精度/安全/合规类落在实车/台架层级，报告中注明实际执行层级。

级别覆盖要求（硬性）：

1. 每个模块用例至少覆盖 2 个测试级别（单元/集成/系统/验收）
2. 整份交付物必须出现全部 4 个测试级别（单元/集成/系统/验收 各 ≥1 条）
3. 执行层级与级别对应：逻辑/算法类用单元级（MIL/SIL），通信/诊断用 HIL，端到端用系统级（台架），合规/精度用验收级（实车/专项设备）

回归用例要求（硬性）：

• 每个模块至少 1 条「用例类型 = 回归」的用例（P1/P2 为主），需求来源列关联原需求，作为回归集复用基础

回归测试指引（阶段五配套）：

1. 变更驱动筛选：按「模块 + 需求来源」过滤受影响用例作为回归集
2. 冒烟集：每个核心层模块的 P0 主流程用例作为变更后快速验证集
3. 回归复用：用例类型=回归 的用例优先复用；探索性用例不纳入常规回归
4. 层级匹配：回归环境优先与产线一致（实车），成本不允许时用 HIL/高保真仿真替代并在报告注明

---

阶段四：Excel 输出

输出规范以 references/format-spec.md 第 4 节为准（生成时必读）。要点：双 sheet（用例 15 列 + 覆盖统计）、优先级着色（P0红/P1橙/P2绿/P3灰）、模块分隔行 【模块名称】、操作步骤 chr(10) 换行。

---

阶段五：交付前最终检查

阻断语义（硬性）：以下检查任一项不通过 → 返回对应阶段修正，未全部通过不得交付；检查是生成时的门禁，不是事后说明。

高频遗漏核对（生成时逐项核对，勿跳过）：

• 引用标准的需求已对照「标准-试验项矩阵」枚举全部试验项（缺项即补合规用例）
• 每个模块「用例类型 = 回归」≥ 1 条（3.13 回归集基础）
• 交付物覆盖全部 4 个测试级别（单元/集成/系统/验收 各 ≥1）
• 每个模块设计方法 ≥ 3 种（3.3，可脚本统计）
• 核心层维度 ≥ 7、重要层 ≥ 5（3.10）
• 每个模块异常场景 ≥ 3 类（3.4）

常规检查清单：

• 每个模块最外层结构 ≥ 设计方法 3 种
• 每个模块覆盖异常场景 ≥ 3 类（安全模块含故障注入）
• 每条用例操作步骤 3-5 步
• 测试数据提供具体值（车速/电压/温度/报文 ID）
• 每条用例可追溯到需求（需求来源列非空）
• 总线/诊断类用例填写「总线/信号」列
• 无跨领域内容混入（本技能只出车载用例）
• 引用标准的需求均有合规用例（标准覆盖率 100%，判定引用标准限值）
• 回归集可用：核心层模块均有 P0 冒烟集，变更可按模块+需求来源筛选回归用例

单文档模式最少用例数参考

模块层级	最少用例数	覆盖内容
核心层	7	P0(1主流程) + P1(2分层) + P2(2黑盒) + P3(2探索)
重要层	5	P1(1主流程) + P2(2分支) + P3(2异常)
辅助层	3	P2(1主流程) + P3(2基本异常)
基础层	2	P2(1正向) + P3(1反向)

该数字是底线不是上限；安全相关模块不受此限，按核心层从高处理。

---

引用文件一览

文件	内容	何时阅读
references/domain-knowledge.md	车载领域知识库（协议/标准/方法/工具/风险点/前置条件模板）	每次生成前通读，重点看「测试类型」「风险点」「前置条件模板」
references/format-spec.md	用例字段结构与 Excel 输出规范（固定格式）	生成用例与输出 Excel 时必读
examples/	真实案例：requirements.md（需求输入）+ testcases.xlsx（输出 Excel）	演示/验收参考，不影响生成

核心约束已内联到本文件。本技能不依赖其他领域技能文件。