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

2023-10-31 15:27

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


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


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



01

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



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


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


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



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


但这个描述只能是一个正确的定义,仍然很难把握。什么叫最小可测单元?一个函数?一个类?一个.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

写在最后



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


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