第三章：V模型开发流程
大家好，我是老张。今天咱们聊聊V模型。
说实话，我刚入行那会儿，对V模型的理解就是“左边画需求，右边做测试”。后来踩了不少坑才明白——这玩意儿没那么简单。
3.1 V模型各阶段概述
V模型长什么样？你想想看，左边是自上而下的开发活动，右边是自下而上的测试活动。中间那条竖线，就是我们的时间轴。
我习惯把V模型分成这么几个阶段：
- 左侧（自上而下）：需求分析、系统设计、硬件/软件设计、单元实现
- 底部：编码与实现
- 右侧（自下而上）：单元测试、集成测试、系统测试、验收测试
每个阶段都有对应的输出物。比如需求分析阶段输出的是需求规格，系统设计阶段输出的是系统架构。这些输出物，就是下一阶段的输入。
核心要点：V模型不是简单的“先做左边再做右边”。左右两侧是相互映射的。左侧的每个阶段，都对应右侧的一个测试阶段。
举个例子：你在左侧做系统设计时，就要想好右侧的系统测试怎么搞。我在项目中见过太多人，左边设计完了，右边测试才发现根本测不了。嗯，那叫一个惨。
3.2 需求管理
需求管理，说白了就是搞清楚“我们要做什么”。
在ISO 26262里，需求管理有严格的要求。我给大家列几个关键点：
- 需求来源：客户需求、法规要求、安全目标
- 需求属性：每个需求都要有唯一ID、版本号、状态、优先级
- 需求追溯：从顶层需求到底层实现，双向可追溯
- 需求变更：变更要走正式流程，不能随便改
我曾经在一个项目里，客户临时加了个需求。项目经理觉得“小改动，直接改代码就行”。结果呢？测试用例没更新，回归测试漏了，最后在客户现场出了故障。从那以后，我坚持所有需求变更必须走流程。
我的习惯：用需求管理工具（比如DOORS、Jama）来管理需求。别用Excel，真的会出事的。
需求管理还有个重要环节——需求评审。我建议至少做两轮：
- 技术评审：检查需求是否可实现、可测试
- 安全评审：检查需求是否覆盖了安全目标
你想想看，如果需求阶段漏了一个安全需求，后面要补回来，成本至少翻10倍。这不是开玩笑的。
3.3 架构设计
架构设计，就是决定“怎么做”。
在V模型里，架构设计分为两个层次：
- 系统架构：把系统拆成子系统，定义接口和交互
- 软件/硬件架构：把子系统拆成模块，定义模块间的依赖关系
我个人的经验是，架构设计要关注三个核心：
| 关注点 | 说明 |
|---|---|
| 模块划分 | 高内聚、低耦合。每个模块职责清晰 |
| 接口定义 | 接口要稳定，避免频繁变更 |
| 安全机制 | 故障检测、故障响应、故障容错 |
举个例子，我在设计一个制动控制系统时，把安全机制单独抽成了一个模块。这样即使其他模块出了问题，安全模块还能独立工作。嗯，这叫“故障隔离”。
避坑指南：我曾经见过一个架构，所有模块都共享一个全局变量。结果一个模块写坏了数据，整个系统崩溃。记住：共享状态是万恶之源。
架构设计还有个重要输出——安全分析。常用的方法有：
- FMEA：失效模式与影响分析
- FTA：故障树分析
- HAZOP：危险与可操作性分析
这些分析的结果，会反馈到架构设计中。比如FMEA发现某个模块的故障可能导致危险，那就要在架构层面增加冗余或监控机制。
3.4 系统集成与测试
系统集成与测试，是V模型右侧的核心活动。
我把它分成三个层次：
- 单元测试：测试单个模块的功能
- 集成测试：测试模块间的交互
- 系统测试：测试整个系统的功能
每个层次都有对应的测试策略：
| 测试层次 | 测试对象 | 测试方法 |
|---|---|---|
| 单元测试 | 单个函数/模块 | 白盒测试、语句覆盖、分支覆盖 |
| 集成测试 | 模块间接口 | 黑盒测试、接口测试、通信测试 |
| 系统测试 | 完整系统 | 功能测试、性能测试、安全测试 |
我记得有个项目，单元测试覆盖率做到了95%，但集成测试时还是出了问题。为什么？因为单元测试只测了单个模块，但模块间的时序关系没测到。所以，集成测试绝对不能省。
关键原则：测试要尽早开始。别等到所有代码写完了再测。我习惯在写代码的同时，就开始写测试用例。这叫“测试驱动开发”。
系统集成还有个重要环节——回归测试。每次修改代码后，都要跑一遍回归测试，确保没引入新的问题。我在项目中会用自动化测试工具来跑回归测试，省时省力。
最后，给大家一个建议：测试用例要覆盖正常场景和异常场景。正常场景验证功能，异常场景验证安全。比如：
- 正常场景：输入有效数据，输出正确结果
- 异常场景：输入无效数据，系统能正确处理（比如报错、降级、安全停机）
嗯，今天就聊到这儿。下一章咱们聊聊ASIL等级和安全目标，那才是ISO 26262的核心。