登陆

谈谈汽车软件测试验证

来源：公众号“汽车电子与软件”（转载自公众号“侯哥工作感悟 ”）

2020-07-23

导读：

整车厂的软件测试和软件行业的软件测试是不同的，虽然有相似之处，但是绝对不能完全照搬。汽车行业在虽然是”新四化“的趋势下，软件越来越重要，很多人也开始喜欢套用软件行业那一套来看待汽车的软件测试。但作为测试人员，还是要有清醒的认识，方法和思路可以学习借鉴，但绝对不能照搬，否则一塌糊涂。

1. 引言

随着新车型的功能和需求在不断增加，汽车上的电子控制器多达150个，到2030年，有专家预言汽车将拥有大约3亿行软件代码。相比之下，今天的汽车有大约1亿行代码。从另一个角度对比来看，一架客机估计有1500万行代码，一架现代战斗机约为2500万行，大众市场PC操作系统接近4000万行。

作为整车厂都是-我们有一个美丽的梦想——我的产品功能逻辑完美，性能出众，系统稳定可靠，用户体验棒棒哒！可从现实情况来看，用一句话来形容：理想很完美，现实很残酷。

整车厂里一个不公开的秘密，就是早期的用户，准确点来说大约是新车投产6个月内，甚至是一年左右的时间，那些用户实际上是担当着O新车型一个类似实验的小白鼠角色—-虽然说起来有点扎心早期的用户在率先体验的同时，也有很大几率在经受着诸如黑屏，网络连接问题，行车辅助系统时不时的跳出一些警报给你一些惊喜.....，这些还算是可以接受的，但更有严重一些的，如车辆在路上抛锚，自动驾驶故障直接把车辆损毁，这些问题就不仅仅是体验不好了，甚至是危及到生命了！虽然问题发生了我们可以找到很多理由—没错，从人的趋利避害的本性来讲，我们更喜欢把这个责任推到其他地方去，比如开发设计的不合理，供应商零件质量，用户使用不当，环境太复杂等等。但从本质上来讲，所有这些问题，整车厂的负责测试的团队是脱不了干系的。

所以下面的系列文章是关于汽车测试的一些介绍和思考，为从事测试或对汽车测试感兴趣的同仁们提供一些参考。

2. 测试的评价模型

谈到汽车测试，首先要搞清楚测试的质量目标是什么，或者说，对于测试的对象要用什么样的指标来评估。汽车软件测试所采用的评价模型实际上也是参照软件行业的标准，用”ISO/IEC 9126 – 软件质量模型”来评估汽车上的软件质量的，这个标准后来在2011年被新的”ISO/IEC 25010-系统和软件质量模型” 这个评估模型从6个方面(质量特征)来对一个软件的质量进行评价：功能性，可靠性，易用性，效率性，维护性和可移植性，详细的解读大家可以在网上查找相关资料。

目前对于汽车上的软件测试更多的是集中在功能性维度，但随着系统复杂性的增加，比如信息娱乐系统从最初的基本功能发展到基于Linux或QNX等，包含云端交互，在线音乐，导航，语音对话等功能。测试工作不仅是要保证功能逻辑的正确性，更重要的是，要保证系统的可靠和稳定，兼容性和性能表现良好。通俗的讲，就是不仅歌要唱得好，舞也要跳得好，颜值也得跟上…

所以这种情况下，汽车软件测试至少要关注这些方面：

功能
性能属性
可靠性
兼容性
稳定性
可恢复，或者说出错时系统如何响应

3. 软件测试有哪些？

如大家所熟悉的，汽车电器系统/软件的测试一般来说大致可分为3个测试层级: 单件测试，系统测试和整车测试。

如果再进一步细化，单件测试还可划分成代码测试，软件单元测试以及集成测试。

在系统层级的测试可以从单一的子系统测试-如外部灯光系统测试-到包含多个子系统的功能域的测试，比如车身域测试，信息娱乐域测试。

关于整车层面的测试，实际上，还可以细分为从研发部门的角度，进行的整车功能、属性特征，主观评价等等方面的测试，以及从质量验收或用户角度，进行的质量验收性测试。

除此之外，对于整车电器系统，还有些测试的内容时涵盖了从单件到整车，如总线协议，网络通信，网络管理，诊断刷写等。

在这些测试中，一般来说单件测试的工作是由供应商负责保障的，系统和整车集成的测试是作为整车厂所关注的。但随着这些年的发展，一些整车厂也开始做起了单件的软件开发，所以一些单件测试的能力也开始逐步建立了。

4. 测试的类型

如前所提到的，测试存在多个层级，另一方面，我们知道还存在着各种类型的软件测试，例如功能测试，非功能测试，自动化测试，敏捷测试及其子类型等。

我们在测试过程中都会遇到几种类型的测试。我们可能听过一些，也许已经做了一些工作，但并不是每个人都了解所有测试类型

每种测试都有其自身的功能，优点和缺点。下面就是关于在日常测试中通常使用的一些测试类型。

功能测试类型包括：

单元测试
集成测试
系统测试
完整性测试
冒烟测试
接口测试
回归测试
验收测试

非功能测试类型包括：

性能测试
负载测试
压力测试
安全测试
兼容性测试
恢复测试
可靠性测试
可用性测试
一致性测试

上述软件测试类型只是测试的一部分。实际上，在软件行业，至少有超过100多种的测试类型。此外，并非每个的项目都使用所有测试类型。因此，上面也只罗列了一些比较常见的软件测试类型。

同样，不同的团队对一些测试类型的描述和定义也是不同的，但对其本质或是基本的目的是一致的。随着项目，需求和范围的变化，这些测试类型，过程及其实现方法会不断变化。

5. 测试的技术和方法

关于测试的方法和测试技术，是可以从很多方面去讨论的。下面只是简单的介绍一些概念和方法。

1. 从测试的是否关注软件的内部结构的角度来看，可划分为白盒测试，黑盒测试以及灰盒测试 – 非黑即白是小孩子的思维，成年人的世界当然要成熟一些，所以我们不光有黑盒，白盒，还要掺杂着搞一下。

白盒测试是基于有关软件/程序代码内部逻辑的知识进行的测试，更多的时候是开发人员采用这种测试技术来检查实际的代码。测试的覆盖范围从代码语句，分支，路径，条件等方面，大概就是下面这个样子.

关于白盒测试，作为主机厂的小伙伴们，是不是对这个有点懵逼？没做过，啥子鬼东西？所以在通常情况下，白盒测试更多地发生在供应商的单件层级。

黑盒测试是基于需求和功能进行的测试，主要在测试人员来设计和执行，测试关注的是测试的重点是整个系统的功能，当然，也可以是非功能性的方面。

黑盒测试在整个开发和测试生命周期中都会被采用，即在单元，集成，系统，验收和回归测试阶段。

除了上述两种测试方法外，还有一种介于白盒测试与黑盒测试的测试方法，即所谓的灰盒测试。灰盒测试同时关注输出对于输入的正确性和内部表现两方面，但这种关注不像白盒测试那样详细和完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。有时候虽然输出的结果是正确的，但内部其实已经错误了，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样灵活的测试方法

2. 从测试执行过程是否有人工参与的角度来看，测试方法还可以分为自动化测试，手动测试以及半自动测试（也就是自动测试加手动测试）。

a.自动测试，就是将大量重复性的测试工作交由自动化，测试件去完成。通常就是使用自动化测试环境，编写测试脚本，模拟手动的测试步骤，利用软件去控制完成全部的测试内容。这种测试方法更多的是应用在单件测试以及系统测试。

b.手动测试，就是由测试人员按照事先编写的测试目录，根据测试用例中描述的测试步骤和方法，手工的一个一个地执行测试，包括与被测试对象进行交互，观察测试结果。手动测试的方法更多的是应用在系统测试以及整车测试方面，虽然这种测试方法比较原始，但是在主机厂中是非常重要而且必要采用的一种测试方法。

c.除此而外，还有一种所谓的半自动测试，这个有两个含义，一个是在自动测试过程中，有些场景需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工制定的要求完成自动测试。另一个是在一些自动测试环境中，某些场景的测试用例无法用自动测试程序控制去完成，需要手动执行，比如一些需要交互的场景等。这种测试方法多应用在有多个系统交互或者功能域的测试环境。

6. 测试的阶段

软件测试在软件行业有一个术语叫做“Software Testing Life Cycle（STLC）- 软件测试生命周期”，其是一个测试过程，按确定的顺序进行的测试活动，以满足测试质量的目标要求。软件测试生命周期可划分成若干个阶段，在不同的公司，按照各自的实际情况，划分成6-8个阶段。尽管划分的阶段不尽相同，但其本质的要求还是相同的。

下面是一个常见的测试阶段划分：