测试是一个非常基础的概念，这种基础让大家可以随意在它前面添加各种定语。
尽管这种添加的背后多数是不同的分类维度，但让测试本身成为了繁杂概念的集合，这也让我们总有种无法把握的烦躁感。
单元测试就是这堆让人烦躁的繁杂概念之一。
01
3种软件测试分类及单元测试的定义
如前所述，软件测试的分类维度非常多，我们仅从以下常见的3种方式阐释：
按是否执行软件分类：静态测试和动态测试，单元测试横跨二者。
按是否关注内部代码分类：白盒测试和黑盒测试，单元测试属于白盒测试。
按汽车软件集成层次分类：从单元测试到整车验收有各级测试（参考《汽车软件集成的5个层次》），单元测试属于最低一个层级。
当我们去网上搜索单元测试的定义时，往往会看到类似这样的说法，“单元测试是指对软件中的最小可测单元进行测试”。
但这个描述只能是一个正确的定义，仍然很难把握。什么叫最小可测单元？一个函数？一个类？一个.c？还是一个功能模块？
争论一直存在。
搁置争议，我们只看汽车行业。按照惯例或标准，广义上，可以把软件集成测试以下所有测试都看作是单元测试。
02
单元测试的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的模块。
03
单元测试意义的思考
说意义的话，我们可以很快说出一大堆，bug提前暴露、提升软件质量、软件更加健壮、利于重构、清除技术债务、积累组织资产......
问题在于，在不好言明的价值和巨大的交付压力之下，单元测试太容易被权衡掉了，谁还没有个意义呢？
实际上，管中窥豹，对这类重要但不紧急事情的意义的探讨会折射出很多面的信息，比如下面这个算式。
自动化的程度+对软件的理解+产品的竞争力+公司的文化+行业的生态=单元测试的意义
04
全文小结
本文主要在讲单元测试的一些基本概念和应用场景。
首先，从是否执行软件、是否关注内部代码和汽车软件分层集成这3个方面解释了单元测试的特点。进而，引申出汽车软件单元测试的概念。
接着，将单元测试细分为代码评审、静态分析、代码功能测试、代码覆盖度测试，并分别进行了描述。
由于单元测试离客户需求太远，往往被务实的我们忽略，如何看待其价值需要探讨，第3小节对此做了简单分析。
05
写在最后
不只是单元测试，软件大举进入汽车行业的过程中，未来无形不可见和当下有形可见的价值冲突持续在上演。
如何把握向左还是向右的分寸始终是一个巨大的决策考验。
