2. 测试流程基础：V模型、W模型、敏捷测试在嵌入式中的落地
聊测试流程，很多人第一反应是「找个模板套上去」。但嵌入式测试不一样——硬件耦合深、资源有限、迭代节奏复杂。我见过太多团队拿着互联网的敏捷模板硬套，结果固件还没烧录完，需求又变了。
这一章，咱们就掰开揉碎聊聊：V模型、W模型、敏捷测试，到底怎么在嵌入式里真正落地。
2.1 V模型：嵌入式测试的「骨架」
V模型是嵌入式测试的经典模型。它把开发和测试对应起来，左边是开发阶段，右边是测试阶段。说白了，就是「你写什么，我就测什么」。
核心思想：每个开发阶段都有对应的测试阶段，测试活动提前介入。
我刚开始做嵌入式测试时，总觉得V模型太死板。后来在一个车载项目中，因为需求文档没评审就开发，结果硬件改版三次，测试用例全废。嗯，从那以后我再也不敢跳过V模型的「需求评审」环节。
V模型的典型阶段
| 开发阶段 | 对应测试阶段 | 嵌入式中的关键活动 |
|---|---|---|
| 需求分析 | 验收测试设计 | 需求可测性评审、硬件接口确认 |
| 概要设计 | 系统测试设计 | 系统架构测试策略、通信协议验证 |
| 详细设计 | 集成测试设计 | 模块接口测试、中断优先级测试 |
| 编码实现 | 单元测试 | MCU寄存器测试、临界代码覆盖率 |
我的习惯：在需求阶段就拉上硬件工程师一起评审。很多嵌入式问题，其实是需求里没写清楚「上电时序」或「异常电压处理」。
2.2 W模型：把测试「嵌入」开发流程
V模型有个问题——测试还是跟在开发后面。W模型则强调：测试和开发并行进行。你想想看，嵌入式开发中，硬件和固件经常并行开发，W模型正好匹配这种场景。
W模型把V模型拆成两条线：一条是开发线，一条是测试线。两条线同步推进，测试活动从需求阶段就开始。
W模型在嵌入式中的关键节点
- 需求阶段：测试团队参与需求评审，编写可测性检查清单
- 设计阶段：测试团队设计测试策略，搭建硬件测试环境
- 编码阶段：测试团队开发自动化测试脚本，准备测试工装
- 测试阶段：执行测试，反馈缺陷，回归验证
我曾经踩过的坑：在一个物联网项目中，我们按W模型并行推进，但测试环境搭建晚了三周。结果开发完才发现硬件接口不匹配，整个测试计划重排。所以，W模型的关键是「测试环境要提前到位」。
2.3 敏捷测试在嵌入式中的落地
说到敏捷测试，很多人觉得嵌入式做不了——硬件迭代慢、测试周期长。其实不然。我参与过一个智能穿戴项目，团队用Scrum，每两周一个Sprint，照样跑得起来。
嵌入式敏捷测试的核心，不是照搬互联网的「每日构建」，而是找到适合硬件的节奏。
嵌入式敏捷测试的三大调整
| 互联网敏捷 | 嵌入式敏捷调整 | 原因 |
|---|---|---|
| 每日构建 | 每周构建+硬件仿真 | 硬件烧录耗时，仿真可加速 |
| 全自动化测试 | 核心用例自动化+硬件在环 | 部分硬件测试无法自动化 |
| 快速迭代 | 硬件版本锁定+固件迭代 | 硬件改版成本高，需稳定基线 |
落地建议：嵌入式敏捷测试，建议采用「硬件仿真+固件迭代」模式。先用QEMU或硬件仿真器跑核心逻辑，等硬件稳定后再做硬件在环测试。
2.4 三种模型的对比与选择
你可能会问：到底选哪个？我的经验是——看项目阶段。
- V模型：适合需求稳定、硬件成熟的维护型项目
- W模型：适合硬件和固件并行开发的新项目
- 敏捷测试：适合快速原型验证、算法迭代类项目
其实，很多成熟团队是混合使用的。比如，整体框架用W模型，每个迭代内部用敏捷测试。说白了，流程是工具，不是枷锁。
2.5 本章知识体系
下面这张图，帮你理清三种模型的关系和落地要点。
2.6 避坑指南
最后，分享几个我亲身踩过的坑，希望能帮你少走弯路。
我曾经犯过的错：
- 在硬件未稳定时强行跑敏捷迭代，结果每个Sprint都在修硬件bug
- W模型中测试环境搭建太晚，导致测试用例无法执行
- V模型中忽略了需求评审，后期需求变更导致大量返工
我的建议：不管用哪种模型，先做一次「测试策略评审」。拉上开发、硬件、产品三方，把测试范围、环境、资源对齐。这一步做好了，后面至少省一半的返工时间。
测试流程不是写文档，而是指导行动。选对模型，落地执行，才是嵌入式测试的核心。