汽车软件单元测试的要点与意义

 

测试是一个非常基础的概念，这种基础让大家可以随意在它前面添加各种定语。

尽管这种添加的背后多数是不同的分类维度，但让测试本身成为了繁杂概念的集合，这也让我们总有种无法把握的烦躁感。

单元测试就是这堆让人烦躁的繁杂概念之一。

1

3种软件测试分类及单元测试的定义

如前所述，软件测试的分类维度非常多，我们仅从以下常见的3种方式阐释：

按是否执行软件分类：静态测试和动态测试，单元测试横跨二者。

按是否关注内部代码分类：白盒测试和黑盒测试，单元测试属于白盒测试。

按汽车软件集成层次分类：从单元测试到整车验收有各级测试（参考《汽车软件集成的5个层次》），单元测试属于最低一个层级。

当我们去网上搜索单元测试的定义时，往往会看到类似这样的说法，“单元测试是指对软件中的最小可测单元进行测试”。

但这个描述只能是一个正确的定义，仍然很难把握。什么叫最小可测单元？一个函数？一个类？一个.c？还是一个功能模块？

争论一直存在。

搁置争议，我们只看汽车行业。按照惯例或标准，广义上，可以把软件集成测试以下所有测试都看作是单元测试。

2

单元测试的4种类型

进一步地，在汽车软件领域，我们可以将单元测试细分为代码评审、静态分析、单元（代码功能）测试和单元（代码覆盖度）测试。

前两种属于静态测试，后两种属于动态测试。

2.1 代码评审

根据形式或正式程度上的差异，代码评审会分成很多名目，比如：

走查（Walk Through）

同行评审（Peer Review)

代码评审（Code Revew）

结对编程（Pair Programming）

代码审查（Code Inspection）

但简单来说，代码评审就是人看，一个或一组人面对可阅读的源代码（有时也需要结合需求或软件文档），进行随意的或正式会议下的检查。

可能会识别出如下的一些问题：

无注释的代码

不可达的条件路径

太复杂的循环嵌套

无返回值的分支

未初始化的变量

空指针的引用

不规范的命名规则

......

理论上，对于手写代码的合理性与正确性，他人及更有经验的他人去检查一遍，有一定的意义，甚至某些案例下，会胜过后期测试。

比如，开发调用了名称相似的变量，这种错误可能在流到很后期才会被探测到。

实际上，代码评审也同其他评审类似，都是无奈为之而又常常流于形式的手段。

解决这类问题的方法不外乎3个：

• 用更负责且有经验的人

• 提升形式的强制性

• 积累充足的Checklist

其中，在下一节静态分析工具使用后，人的经验就成为了代码评审存在的最大意义。

总之，代码评审不算是典型的测试，但作为编码后的第一道屏障，仍然有必要存在。

2.2 静态分析

相较于人工代码评审的低效，静态分析是依赖于诸如Parasoft、Polyspace、Coverity等工具的自动化分析。

因为不需要执行软件，所以静态分析仍然不需要二进制代码或可执行程序。

静态分析工具通常主要支持以下两种分析类型：

语法分析：主要检查是否符合编程语言的语法规则，如MISRA C。

代码路径分析：主要包括控制流分析（如语句条件分支、循环迭代次数)、数据流分析（如变量值的传递）、代码复杂性（如圈复杂度、路径长度）、依赖关系（如函数之间的调用、模块之间的依赖）等。

当对部分或全部代码进行静态扫描后，会得到基于内置规则集的判定结果，一般会包含分等级的规则违反情况。

如MISRA C: 2012分为强制（Mandatory）、必要（Required）和建议（Advisory）。

通常，强制项必修，必要项需要进行评审。但有时候，涉及到第三方标准库时，就无法按照这个规则执行了，具体还是要看产品类型（如是否涉及信息安全）和公司要求。

此外，由于编译器基本也都具备类似的代码检查作用，静态分析工具也可以理解为编译器的扩展。

因此，我们也会把编译器警告或错误作为要处理的条目。

2.3 单元（代码功能）测试

这部分测试的源头是软件详细设计，测试重点从代码写得漂不漂亮转移到代码写得有没有用，也就是是不是符合了设计。

汽车软件用例的设计，一般有如下两种密切相关的方法：

2.3.1 等价类划分法

等价类划分是将软件单元的输入数据划分为等价数据（即可以导致相同的输出）的分区，而后用测试用例去至少覆盖每个分区一次。

其背后的诉求是，通过划分输入数据的类别来限定测试用例的数量。

举一个例子。

一个函数输入的范围是1~100，如果要穷举式测试，我们需要为输入参数编写100个测试用例。

而使用等价类划分法的话，测试用例就可以分为三类：

有效（1~100）

以下无效（例如0）

以上无效（>100）

于是，用例也就可以缩减为3个。

可能有人很快会有疑问，按照等价输入数据进行测试，会不会有遗漏呢？

没错，尤其是边界值处很容易出错。这就是第二个方法要解决的问题。

2.3.2 边界值法

仍然以上一个案例展开。

使用边界值法的话，我们可为等价类划分法定义的测试用例作如下补充：

刚好在边界（1，100）

刚好在边界以下（0，99）

刚刚越过边界（2，101）

经过两种方法的结合，缺陷发现的能力会进一步提高。

2.4 单元（代码覆盖度）测试

单元（代码功能）测试完成后，够了吗？不够。

我们没测出bug，代表的不是软件没bug，而是没测够。

没测够的典型表现是测试用例对代码的覆盖程度不足，这就是本节要处理的问题。

主要的代码覆盖度测试类型包括以下4种，严格程度从上到下依次增强：

语句覆盖（Statement Coverage）：这是最基本的覆盖度类型，它确保每个代码语句至少执行一次，100%的语句覆盖率可以保证没有死代码，属于入门级别的测试。

分支覆盖（Branch Coverage）：分支覆盖确保每个分支语句（通常是if语句）都被覆盖到，即每个分支的真和假两种情况都被测试到，有助于揭示一些逻辑错误，如if a and b then...，用例为a真+b真（分支为真）、a真+b假（分支为假，与其他条件组合等价）即可100%。

条件覆盖（Condition Coverage）：条件覆盖要求每个分支语句的每个条件都被覆盖，即每个条件的真和假两种情况都被测试到，它比分支覆盖更为严格，因为它会关注条件的组合覆盖，如if a and b then...，用例为a真+b真、a真+b假、a假+b真、a假+b假才可100%。

修改条件/判定组合覆盖（Modified Condition/Decision Combination Coverage）：这一级别的覆盖要求同时满足条件覆盖和判定覆盖，以确保条件和判定之间的组合覆盖，是一种更加严格的覆盖度测试。

不同的项目和产品可能需要不同类型的代码覆盖度测试。

通常，基础的覆盖度（如语句覆盖和分支覆盖）是必要的起点，而在需要更高可靠性和安全性的项目中，可能会选择更严格的MC/DC覆盖度，比如，涉及ASIL D的模块。

3

单元测试意义的思考

说意义的话，我们可以很快说出一大堆，bug提前暴露、提升软件质量、软件更加健壮、利于重构、清除技术债务、积累组织资产......

问题在于，在不好言明的价值和巨大的交付压力之下，单元测试太容易被权衡掉了，谁还没有个意义呢？

实际上，管中窥豹，对这类重要但不紧急事情的意义的探讨会折射出很多面的信息，比如下面这个算式。

自动化的程度+对软件的理解+产品的竞争力+公司的文化+行业的生态=单元测试的意义

4

全文小结

本文主要在讲单元测试的一些基本概念和应用场景。

首先，从是否执行软件、是否关注内部代码和汽车软件分层集成这3个方面解释了单元测试的特点。进而，引申出汽车软件单元测试的概念。

接着，将单元测试细分为代码评审、静态分析、代码功能测试、代码覆盖度测试，并分别进行了描述。

由于单元测试离客户需求太远，往往被务实的我们忽略，如何看待其价值需要探讨，第3小节对此做了简单分析。

5

写在最后

不只是单元测试，软件大举进入汽车行业的过程中，未来无形不可见和当下有形可见的价值冲突持续在上演。

如何把握向左还是向右的分寸始终是一个巨大的决策考验。