汽车嵌入式软件单元测试、集成测试、系统测试介绍

老灰╮(╯-╰)╭

已于 2024-01-04 14:08:34 修改

阅读量3.3k

点赞数 11

分类专栏： CICT 文章标签：汽车单元测试集成测试

于 2023-10-20 10:39:09 首次发布

本文链接：https://blog.csdn.net/weixin_42447823/article/details/133912247

版权

CICT 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

关键词

嵌入式、单元测试、集成测试、系统测试

概述

基于目前的汽车电气架构主要是分布式的电器架构，汽车的功能分解到了各个相应的功能模块，因此嵌入式汽车软件的复杂度，相比于IT软件，并没有那么大，但质量要求相对非常高。为了解决软件开发过程中的各种问题，先后引入了瀑布模型、V模型、敏捷等。
这里以V模型引入汽车嵌入式软件开发中的单元测试、集成测试和系统测试。
嵌入式软件测试标准GJB-Z-141-2004

软件测试标准 ISO-IEC-IEEE-29119
在这里插入图片描述

一、单元测试

1.1黑盒测试

黑盒测试是软件测试中的一种测试方法，它是指在不了解系统内部结构或工作原理的情况下，通过输入数据并观察输出结果来判断系统的正确性、完整性和可靠性的测试方法。
黑盒测试的重点在于测试对象的功能和性能是否符合需求规格说明书的要求。黑盒测试适用于所有软件类型，无论是桌面应用程序、服务器端软件还是嵌入式控制系统等。
黑盒测试分为等价类划分、边界值分析、决策表测试、场景测试等多种方式。

1.1.1等价类划分

等价类划分是最为常用的一种测试方法之一，它将所有可能的输入数据划分成若干个等价类，每个等价类的数据被认为具有相同的影响，从而提高测试效率和测试覆盖率。
例如一个温度采集复杂驱动，不同电压的输入表示不同温度，我们需要在传感器允许范围内输入对应的电压值来观察是否输出了对应的温度。

1.1.2边界值分析

通过测试极限数据来检测软件中可能存在的错误。
例如一个温度采集复杂驱动，温敏传感器测量温度范围为-40℃——150℃，对应电压为0.2V——4.5V，我们可以在边界处出入0.19V或者4.6V的情况。

1.1.3决策表测试

适用于复杂的业务逻辑的测试。决策表是一种规范化的表格，通过列出所有可能的输入组合和输出结果来描述一个系统的决策逻辑。通过决策表测试，可以发现许多在其他测试方法中难以发现的问题。

1.1.4场景测试

场景测试是一种基于用户使用场景的测试方法，它可以发现软件在不同场景下的异常行为和错误。
例如LCC（车道保持辅助）功能在不同路况下的运行情况。

1.2白盒测试

1.2.1白盒测试简介

白盒测试是一种在知道程序内部结构的情况下采用的测试技术或策略，选取足够的测试用例，对源代码实现比较充分的覆盖，以便尽可能多地发现程序中的错误．它包括逻辑覆盖、路径测试、控制流测试和数据流测试等方法。

在ISO/IEC/IEEE 29119系列软件测试标准中，第四部分基于结构的测试技术用于白盒测试中，我们将着重关注右图中红色方框选中的部分
在这里插入图片描述
白盒测试相较于软件单元测试是一种更为详细的测试方法，测试人员需要了解被测试软件的内部结构和逻辑。它测试软件中的程序代码的每一条路径是否能按预期执行，以检测程序中可能存在的逻辑错误和漏洞，提高软件的质量和安全性。

1.2.2白盒测试优点

白盒测试有如下优点：
白盒测试可测试出隐藏的错误，优化代码；
白盒测试的测试用例可实现自动化；
白盒测试比其他测试方法更全面，因为它能测试代码的所有路径

1.2.3语句覆盖

若要使语句覆盖度达到100%，则要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。语句覆盖的测试用例是依据源代码中显性的存在的语句进行编写的，所以无法测试出隐藏的分支或条件，如悬空的else；再如，在Do-While结构中，语句覆盖执行其中某一个条件分支。显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只关注语句是否执行一次，而不考虑其他情况。但是，通过语句覆盖，可以找到程序中的Dead Code，即未执行的代码(如函数中return后面的语句)；未执行的分支 (如分支判断条件总是为true或false)。
在这里插入图片描述

1.2.4分支覆盖

在这里插入图片描述
语句覆盖测试程序中每条语句至少执行一次的情况，但是它无法检测程序中隐藏的分支或循环运算。分支/决策覆盖是白盒测试中测试执行路径覆盖度大于语句覆盖的方法，它们可用来：

验证代码中的所有分支；
检测由于隐藏分支导致程序操作异常；
消除语句测试无法覆盖的问题。
但是，如右图所示，条件A、B和C构造一个了布尔表达式，分支覆盖和决策覆盖只关心决策的路径，会忽略决策条件中布尔表达式内部的分支。
在这里插入图片描述

1.2.5数据流测试

数据流测试源代码中定义的变量是否被使用。其中，变量的定义表示为为变量指定了类型和名字，如“char variable;”，变量的使用表示为变量参与了判断(Predicate-use，简称 p-use)，如“if (variable > 10)”，或计算(Computation-use，简称 c-use)，如“variable=3;”。数据流测试的测试条件为变量的定义-使用对(Definition-use pair)，即变量定义的位置到使用的位置，通常，这里的位置表示行号。数据流测试的测试覆盖项分为两类，一是用于计算的变量，一个变量只需要一个测试覆盖项，实现其中一个定义-使用对应即可；二是用于判断的变量，一个变量需要的测试覆盖项等同于定义-使用对数量，一个测试覆盖项实现变量的一个定义-使用对应。
在这里插入图片描述

详情: 单元测试——白盒测试

二、集成测试

2.1灰盒测试

灰盒测试是界于黑盒测试和白盒测试之间的一种测试。之所以存在灰盒测试，是因为按测试阶段来划分，整个测试的流程包括单元测试、集成测试、系统测试，而白盒测试对应单元测试，黑盒测试对应系统测试，那么在正确的测试过程中，应该是先测试单元模块，单元模块测试完成之后，并没有立即进入系统测试，而是集成测试，这个时候其使用的方法就是灰盒测试，即我们测试完成单个模块后，虽然单个模块没有问题，但并不代表这些模块组合在一块时就一定没有问题。那么要验证这些功能模块组合在一起有没有问题，这就是我们说的集成测试，其使用方法就是灰盒测试。

2.2集成测试内容

集成测试是在单元测试之后进行的，以确保所有单元相互协调运行。通常，一个单元将被视为具有独立功能，但在与其他单元交互时可能会引起问题。这就是软件测试如此重要的原因，尤其是作为一个整体的测试单元。
集成测试主要验证是否满足软件架构和需求，大多数情况下采用灰盒测试。例如各个单元之间的数据接口测试，软件性能测试（cpuload，cycletime，runtime等）

三系统测试

系统测试通常在集成测试之后，将所有模块集成到完整的硬件系统上，验证是否满足系统架构需求。通常采用黑盒测试。系统测试需要在尽可能遍历所有工况，考虑尽可能多的、极限的运行环境。

四静态测试

静态代码测试是一种分析源代码的过程，用于查找潜在的编码错误、代码缺陷和安全漏洞。静态代码测试并不直接运行程序，而是检查代码的结构、语法、命名规范、代码复杂度等方面的问题。静态代码检测可以在软件开发早去提供安全问题反馈，帮助开发人员在编译和运行代码之前发现潜在的问题。

五测试工具

5.1Tessy

用于单元测试和集成测试
Tessy是一个针对嵌入式软件的C/C++代码进行单元、集成测试的工具，它可以自动化地执行测试、评估测试结果并生成测试报告。Tessy的目标就是：通过自动化整个测试周期，完美支持针对C语言的单元测试/集成测试，同时，Tessy也同样关注测试组织和测试管理。
tessy简介

在这里插入图片描述

5.2 Gtest

用于单元测试和集成测试。
Gtest是Google的一个开源框架，它主要用于写单元测试，检查真自己的程序是否符合预期行为。可在多个平台上使用（包括Linux, Mac OS X, Windows, Cygwin和Symbian）。它提供了丰富的断言、致命和非致命失败判断，能进行值参数化测试、类型参数化测试、“死亡测试”。

5.3 VectorCAST

VectorCAST是领先的专门用于高可靠性和高安全性软件的自动化动态测试工具链，覆盖软件的单元测试、模块测试、集成测试、系统功能测试、回归测试和覆盖率分析等软件全生命周期SDLC的主要测试环节。 VectorCAST支持对C, C++和Ada语言的测试，尤其适用于对嵌入式软件应用的测试。

5.4 QAC

用于静态代码测试。
Helix QAC是权威的C/C++代码合规性静态分析工具，适用于对代码的规范性和可靠性有较高要求的软件系统。Helix QAC提供编码规则检查、数据流分析和代码度量分析等全面的代码静态分析功能，可以自动检测软件中不规范的、不安全的、不明确的、不可移植的有关编码风格、命名惯例、程序逻辑、语法和结构的代码。Helix QAC现已广泛支持MISRA C/C++, AutoSAR C++14, CERT C/C++, CWE C/C++, HiCPP, JSF等常用编码规则集，并完全符合ISO 26262, ISO/SAE 21434, ASPICE, EN 50128, IEC 61508, IEC 60880, IEC 62304, DO-178B/C等研发标准对工具鉴定和认证的要求。