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

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

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

　　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、写在最后

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

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

 感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取