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

lsekfe

说起软件测试，大家在脑海中复现的有软件集成测试，系统测试等，可能没想到会有单元测试。一般来说软件开发任务繁重，时间短，不会把软件的单元测试作为一个独立的工序纳入到工作范畴，如果要求工程师执行单元测试，工程师一般会说：
　　1.功能实现都忙不过来，那有空做单元测试
　　2.编译都过了，还测什么
　　3.还要搭建测试环境，编写测试代码，相当于重新写了一遍代码功能
　　4.应用层和底层耦合很深，不集成到ECU上根本无法进行测试
　　5.单元测试可以合并到后续的软件集成测试和HIL测试中进行
　　等等是不是很熟悉的理由？
　　这些理由果真成立，单元测试不值得去做么？
　　下面我们就从投入产出比和方法上来介绍一下单元测试到底能给开发人员带来多大的好处。
　　为什么要做单元测试
　　1.消除深度未知隐患
　　软件开发天生就具有极大的复杂性，没人敢100%保证自己写出来的程序没有问题。开发中初步功能验证我们会用仿真，或模型及代码调试技巧进行结果值确认，这种测试一般只能覆盖部分执行路径，未覆盖执行路径就留下了很多未知隐患，为了保证我们的程序在各种情况下都能按照预想动作，就需要对我们的模型或者代码进行严格的基于需求的测试和覆盖率测试（俗称：白盒测试），而这种测试只能在单元测试中进行。
　　2.带来自信
　　项目的开发不可避免的遇到频繁的需求变更问题，如果没有一个良好的单元边界，很可能修改后的程序会莫名其妙的引起更多的Bug出现。为了降低这种变更影响分析的时间成本，设计出良好的单元边界，进行单元回归测试则显得尤为重要。通过充分的单元测试，大幅度减少后续的软件集成和系统集成产生的问题，构建高可信度的软件产品。
　　3.更快反馈，更省时间
　　单元测试一般在PC机上完成，执行速度快，容易发现深层次问题，并快速定位问题的来源，得出测试结果后，可以针对相关需求，开发人员进行反馈，小步快速迭代，高效的实现正确的需求和代码。
　　4.优化设计和架构
　　单元测试可以辅助优化设计和架构，比如通过处理器在环（ProcessorIntheLoop）来评估最长执行时间（WCET），内存和堆栈使用量，优化设计和架构，早期回避集成后的执行时间及内存的溢出问题。
　　5.满足行业规范要求
　　满足AutomotiveSPICE过程及ISO26262安全规范对单元测试的要求，以从第三方认证公司获取相关认证证书。
　　符合ASPICE和功能安全的单元测试流程
　　如下图所示，ASPICE针对单元测试规定了独立的工序（SWE.4）

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

这里的A静态分析和B等效性测试都是和需求无关的结构性测试，可以通过工具全自动完成，早期找出模型或者代码的结构性不一致的问题，减少迭代，为后续的功能测试打下良好的基础。
　　主流测试工具BTCEmbeddedPlatform(单元篇)
　　工欲善其事必先利其器，这次我们也介绍一款工具，方便大家有更深入的理解。
　　BTCEmbeddedPlatform是有20年历史的世界知名自动化测试工具，她面向单元测试提供了符合ASPICE和ISO26262完美的解决方案，下面我们逐一介绍该软件的功能是如何匹配测试要求的。
　　A：等效性测试
　　在基于模型开发中，代码是由代码生成器自动生成的。为了确认模型到代码的转换的一致性，评估浮点小数点和定点小数点的差异等，功能安全强烈推荐要求完成等效性测试。BTC可自动生成代码MCDC级别100%覆盖率的测试用例，同时进行MIL和SIL，以及MIL和PIL的比较，全自动完成等效性测试，显著提升代码的可靠性。


　　出典：ISO26262等效性工作原理

BTC等效性测试分析结果例
　　B：软件详细设计
　　软件详细设计为SWE.3的主要产出物，规定了软件单元的功能和非功能需求，为后续的软件单元测试规范提供了良好的输入。
　　C：单元测试规范（UnitTestSpecification）
　　软件单元测试规范是针对软件详细设计基于测试理论进行分析，为指导编写出明确完整的测试用例提供基础。其内容例如下图所示：

在本例中，软件测试规范给出了明确的测试操作指示外，还在文档层面满足软件需求的各种情况（正常，异常，边界值，等价类，状态变换等），实现了测试的全覆盖。也可以把这个文件理解为文本测试用例。
　　D：编写测试用例
　　编写测试用例的主要工作是把上述的单元测试规范转化为工具可执行的测试数据（输入，参数，期望值等）。BTC提供了一个清晰易用的测试用例编辑器，快速完成测试用例的编辑以及对代码的各种模式的仿真（MIL，SIL，PIL）。

E：需求覆盖率
　　需求覆盖率则评估测试用例对需求的覆盖程度，一般通过评审来实现。BTC也可以给出报告看是否需求得到了至少1条测试用例的覆盖。

F：代码覆盖率
　　功能安全要求代码在MCDC覆盖率上均到达100%，并对死代码做出判断和接受时的理由说明。BTC工具可自动生成测试用例，达到MCDC100%，同时找出死代码的位置。
　　代码覆盖率统计报告

BTC代码分析细节报告（绿色为覆盖部分，黄色为需要确认的未达到部分）

G：测试报告和总结
　　为了符合ASPICE和ISO26262相关要求，需要准备代码覆盖率分析报告，等效性测试报告，以及基于需求的功能测试报告等，这些报告都可以从BTC工具中自动生成出来。
　　小结
　　单元测试执行方便，可以早期发现错误，为软件产品的可靠集成打下良好的质量基础。使用像BTC等专业的工具，高效进行测试的同时，保证需求和代码覆盖率，符合ASPICE和ISO26262行业规范要求，为产品的第三方认证打下良好的基础。