首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

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

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

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

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

写在最后

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

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

关注公众号,点击公众号主页右上角“ ··· ”,设置星标,实时获取公众号“水轻言”最新文章。

  • 发表于:
  • 原文链接https://page.om.qq.com/page/OJawva25FJm3qaf9KRSGP8tg0
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券