两年前基于工作经验写了这篇《汽车电子软件测试的“脉络”》，主要从测试管理的角度进行了串联。
这段时间，和业内同仁针对ASPICE 4.1中的各级测试做了几次workshop，得到了一些新的共识，趁热打铁，在此总结并输出系列文，第一篇针对单元与集成测试。
1软件单元测试
通常，我们可以将软件单元测试理解为汽车软件测试的最低级别。在此阶段之后，软件单元会在诸如SVN之类的代码配置管理工具中发布，并可用于更上一级别的测试，即软件组件集成测试。
测试目标：确保已实现的软件能够符合软件详细设计（即动态测试），并达到一定的代码覆盖率，以及符合代码规则（即静态测试）。
测试依据：动态测试用例来源于软件详细设计说明书，使用的用例设计技术一般有“等价类划分”和“边界值法”。
测试对象：一个单独的软件单元（如.c和.h文件），有时也直接面向一个代码仓。
进入标准： 已review并发布的软件单元测试用例与计划，用例已达到一定的（如100%）的设计要求覆盖率。
退出标准：已完成code review，已执行对应的测试用例，已达到一定的代码覆盖率（如90%~100%）。
负责角色：软件开发人员。
单元测试的详细内容同时可见《汽车软件单元测试的要点与意义》。
2软件组件集成测试
软件组件集成测试是汽车软件测试的第二级别。在此阶段之后，可以将软件组件集成在一起，并可用于更上一级别的测试，即软件集成测试。
测试目标：软件组件的接口按预期工作，满足资源消耗限制。
测试依据：架构设计书、接口文档、资源消耗目标等。
测试对象：一个单独的软件组件，包含一个或多个属于某个功能的单元。
进入标准：已review并发布的软件组件集成测试用例与计划，已完成软件单元测试，已完成组件内所有单元的发布。
退出标准：已执行对应的测试用例。
负责角色：软件开发人员。
3软件集成测试
软件集成测试是汽车软件测试的第三级别。在此阶段之后，可以将软件代码、相关资源和其他必要文件打包对外发布，并可用于更上一级别的测试，即软件需求测试。
测试目标：为集成的软件组件符合软件架构设计提供证据，包括软件接口和数据流，以及满足冒烟测试要求。
测试依据：架构设计书、架构模型、接口文档、时序图、非功能性需求书等。
测试对象：逐步集成并测试完整软件系统的各个部分。在持续集成的框架内，每次测试运行时都会自动执行所有预定义的集成测试用例，即回归测试。
进入标准：已review并发布的软件集成测试用例与计划，已完成软件组件集成测试，已完成软件架构的发布。
退出标准：已执行对应的测试用例。
负责角色：软件集成人员。
注意，软件组件集成测试一般更适用于较为复杂的软件系统和大型组织，以达到更精细的分工颗粒度。视实际情况，可与软件集成测试合并。
4全文小结
本文简单介绍了软件单元测试、软件组件集成测试和软件集成测试，这都属于软件向测试发布软件包之前的开发测试工作。
整体关注的是代码规则、代码覆盖率、code review、接口、资源消耗、堆栈、时序等底层的基础功能。
5写在最后
车离代码太远，压力层层衰减，而且越来越抽象，所以，开发测试的被重视度普遍较低。
