嵌入式软件测试笔记3 | 嵌入式软件测试开发的多V模型
【摘要】 1 简单的多V模型原则上，每一种产品形态，都遵循一个完整的V型开发周期；包括设计、开发和测试活动，所以用多V表示；多V的本质是为同一个系统开发不用的实物形态；如下多V模型的开发生命周期： 2 迭代与并行开发 2.1 开发模型多V模型只是一个简化的描述方式，不应该被看做是简单的连续过程（“瀑布模型”）；中间的“V”是处于多次迭代开发的，此时可采用的迭代开发模型为RUP模型（统一过程）和XP模...
1 简单的多V模型
- 原则上，每一种产品形态，都遵循一个完整的V型开发周期；
- 包括设计、开发和测试活动，所以用多V表示；
- 多V的本质是为同一个系统开发不用的实物形态；
- 如下多V模型的开发生命周期：
2 迭代与并行开发
2.1 开发模型
- 多V模型只是一个简化的描述方式，不应该被看做是简单的连续过程（“瀑布模型”）；
- 中间的“V”是处于多次迭代开发的，此时可采用的迭代开发模型为
RUP模型（统一过程）和XP模型（极限编程）。
2.2 嵌入式开发过程的复杂性
- 多团队项目；
①软件、硬件开发团队；
②独立并行的工作；
③硬件和软件的协同。
- 系统分解、并行开发、分阶段集成。
①每个部件开发一个模型；
②硬件和软件的迭代开发；
③不同的部件进行集成。
3 多V模型中的测试活动
3.1 测试活动和因素
- 测试活动和因素分三类：测试技术、测试层次与测试类型、其他因素；
- 开发和测试生命周期中需要分配的测试相关的因素和活动：
| 技术 | 测试层次与类型 | 其他因素 |
|---|---|---|
| 代码覆盖范围分析 | 体系架构设计确认 | 体系架构设计 |
| 控制流测试 | 代码审查 | 认证 |
| Fagan检查 | 一致性测试 | 详细设计 |
| 故障模型及后果分析（FMEA） | 详细设计确认 | 详细测试计划 |
| 故障注入 | 硬件/软件集成测试 | 设计&构建工具 |
| 故障树分析（FTA） | 主机/目标机测试 | 设计&构建模拟器 |
| 正式确认 | 模型集成测试 | 设计&构建占位程序（stub） |
| 接口测试 | 实地检测 | 设计&构建驱动程序（driver） |
| 模型检查 | 回归测试 | 可测性设计 |
| 突变（Mutation）测试 | 需求确认 | 高层次需求 |
| 随机测试 | 软件验收测试 | 法律要求 |
| 稀有事件测试 | 软件集成测试 | 低层次要求 |
| 模拟 | 系统验收测试 | 主测试计划 |
| 状态转换测试 | 系统集成测试 | 生产需求 |
| 统计使用测试 | 单元测试 | 发布标准/建议 |
| / | / | 安全计划 |
3.2 模型开发周期中与测试相关的元素分配
3.3 原型开发周期中与测试相关的元素分配
3.4 最终产品开发周期中与测试相关的元素分配
4 嵌套多V模型
4.1 嵌套多V模型
4.2 嵌套多V模型中较高层次的测试因素
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）