登陆

单元测试到底是什么？应该怎么做？

来源：上海控安

2020-06-08

说起软件测试，大家在脑海中浮现的主要有软件集成测试，系统测试等，可能不太会想到单元测试。一般来说软件开发任务繁重，时间短，不会把软件的单元测试作为一个独立的工序纳入到工作范畴，如果要求工程师执行单元测试，工程师一般会说：

1. 功能实现都忙不过来，哪有空做单元测试

2. 编译都过了，还测什么

3. 还要搭建测试环境，编写测试代码，相当于重新写了一遍代码功能

4. 应用层和底层耦合很深，不集成到ECU上根本无法进行测试

5. 单元测试可以合并到后续的软件集成测试和HIL测试中进行

是不是很熟悉的理由？

这些理由固然是深刻的事实，那单元测试就不值得去做么？

下面我们就从投入产出比和测试方法上介绍一下单元测试到底能给开发人员带来多大好处。

● 为什么要做单元测试

● 符合ASPICE和功能安全的单元测试流程

● 主流测试工具

● 小结

为什么要做单元测试

1. 消除深度未知隐患
软件开发天生就具有极大的复杂性，没人能100%保证自己写出来的程序没有问题。开发中的初步功能验证我们会用仿真，或模型及代码调试技巧进行结果值确认，这种测试一般只能覆盖部分执行路径，未覆盖执行路径就留下了很多未知隐患。为了保证我们的程序在各种情况下都能按照预设响应，就需要对我们的模型或者代码进行严格的基于需求的测试和覆盖率测试（俗称：白盒测试），而这种测试只能在单元测试中进行。

2. 带来自信
项目的开发不可避免会遇到频繁的需求变更问题，如果没有一个良好的单元边界，很可能修改后的程序会引起更多Bug出现。为了降低此类变更影响分析的时间成本，设计出良好的单元边界，进行单元回归测试则显得尤为重要。通过充分的单元测试，大幅度减少后续的软件集成和系统集成产生的问题，构建高可信度的软件产品。

3. 更快反馈，更省时间
单元测试一般在PC机上完成，执行速度快，容易发现深层次问题，并能快速定位问题的来源、得出测试结果后，可以针对相关需求，向开发人员进行反馈，小步快速迭代，高效实现正确的需求和代码。

4. 优化设计和架构
单元测试可以辅助优化设计和架构，比如通过处理器在环（Processor In the Loop）来评估最长执行时间（WCET），内存和堆栈使用量，优化设计和架构，尽早地回避集成后的执行时间及内存的溢出问题。

5. 满足行业规范要求
满足Automotive SPICE过程及ISO26262安全规范对单元测试的要求，以从第三方认证公司获取相关认证证书。

符合ASPICE和功能安全的单元测试流程

如下图所示，ASPICE针对单元测试规定了独立的工序（SWE.4）

SWE.4有7个实践项（BP），8个成果物要求，功能安全对需求分析，等效性测试，代码覆盖率等也有明确要求，拨开大量文档说明的迷雾，结合我们在项目中的最佳实践，这次特别把SWE.4的主要工作流程总结如下，以方便大家参考使用。

这里的A静态分析和B等效性测试都是和需求无关的结构性测试，可以通过工具全自动完成，在早期找出模型或者代码的结构性不一致的问题，减少迭代，为后续的功能测试打下良好的基础。

主流测试工具

BTC EmbeddedPlatform(单元篇)

工欲善其事必先利其器，这次我们也介绍一款工具，方便大家有更深入的理解。

BTC EmbeddedPlatform是有20年历史的世界知名自动化测试工具，面向单元测试提供了符合ASPICE和ISO26262完美的解决方案，下面我们逐一介绍该软件的功能是如何匹配测试要求的。

B. 等效性测试

在基于模型开发中，代码是由代码生成器自动生成的。为了确认模型到代码转换的一致性，评估浮点小数点和定点小数点的差异等，功能安全强烈推荐要求完成等效性测试。BTC可自动生成代码MCDC级别100%覆盖率的测试用例，同时进行MIL和SIL，以及MIL和PIL的比较，全自动完成等效性测试，显著提升代码的可靠性。