汽车EBSE测试流程分析（二）：关于优势和挑战的案例分析

EBSE专题连载共分为“五个”篇章。此文为该连载系列的“第二”篇章，在之前的“篇章（一）”中已经阐述了汽车软件工程的特点，以及使用混合方法设计的分阶段EBSE测试过程，并提出问题。接下来，我们将具体分析EBSE步骤一：关于优势和挑战的案例分析。

点击阅读：汽车EBSE测试流程分析（一）：汽车软件测试的特征和问题https://blog.youkuaiyun.com/NewCarRen/article/details/130137367?spm=1001.2014.3001.5501

4.EBSE步骤一：关于优势和挑战的案例分析

我们进行了一项行业案例研究，以调查汽车软件测试过程中的优势和挑战，并确定改进空间，回答本专题连载（一）的RQ1和RQ2。

4.1.案例分析设计类型

案例是瑞典一家大型汽车组织的开发基地之一。案例组织已通过ISO认证。然而，该组织一直在努力实现其客户期望的SPICE级别。特别是，不同部门在考核中取得了不同的成绩。从这项研究中也可以明显看出一点，我们发现没有统一的测试流程，而且并非所有项目都有合适的测试计划。他们专注于车联网、物流、电子、机械、仿真建模和系统工程等领域的软硬产品。

我们报告了一个具有多个分析单元的案例，其中我们重点研究了在一个公司进行多个项目测试的现象。这种类型的案例研究有助于比较案例组织中用于不同项目的测试方法论、工具和方法。

这里的分析单元是所研究公司的不同项目。选择的方式是让他们在使用的方法、团队规模和用于测试的技术等因素上具有最大的差异。关注变化的项目的动机是能够引发广泛的挑战和优势。此外，这有助于提高普遍性，因为挑战不会偏向于特定类型的项目。

4.2.分析对象

此次所研究的所有项目都是定制的，因为案例组织是特定客户的供应商。这里的所有项目都是外部发起的，该组织不销售任何专有产品/服务。组织内的项目大多是维护项目或现有产品的改进。在这个组织中，一个角色在多个项目中承担多项职责是很常见的。表1给出了所研究项目的概述。

系统：大多数系统是嵌入式应用程序（P1、P2、P3、P4、P7和P8），即它们涉及软件和硬件部分，例如控制单元、液压件等。在P2、P5和P6中开发的Windows应用程序不控制硬件。

团队规模：我们区分小型项目（团队少于4人）和大型项目（团队有4人或更多人）。大多数团队规模较大，如表1所示。小型团队不一定拥有结构化的开发和测试流程、角色和职责、测试方法或工具。三个项目（P3、P6和P8）未报告任何测试计划。模块数量较多的项目由大型团队开发，与小型团队处理的项目相比，这些项目已经过时。也就是说，随着时间的推移，这些系统已经有了相当大的发展。

开发方法：组织内采用不同的软件开发方法。然而，基于模型的开发是最突出的（P4、P5、P7和P8），并与瀑布模型概念一起使用。瀑布是指涉及需求、设计、组件开发、集成和测试的顺序过程。在一个项目（P2）中采用了使用Scrum的敏捷开发。参与维护的小团队采用了临时方法 (P6)。最近有两个项目引入了一些敏捷实践来合并迭代开发（P1和P5）。

工具：测试项目中使用各种工具，例如测试用例和数据生成器、测试执行工具、缺陷检测和管理工具、调试工具、需求跟踪和配置管理工具以及用于建模和分析电子控制单元（ECU）的工具。除了这些工具之外，当任何其他工具无法满足项目的特定目的时，在某些项目中会使用定制工具。这些工具通常用于测试执行，使测试环境接近目标环境。小型团队（例如P3）不依赖测试工具，而是使用电子表格。负责多个模块的大型团队使用多种工具来组织和管理测试工件。

测试级别：如表1所示，几乎所有项目（八分之七）都进行了单元测试，并且在五个项目中使用了集成测试。项目中的单元/基本测试类似于冒烟测试。但是，此上下文中的单元测试没有明确定义的范围。研究的项目中有一半使用了测试自动化。然而，不断增加的测试用例并不总是更新到自动化架构中。从访谈数据可以看出，很多团队并没有进行系统集成测试。然而，大多数团队都认为集成测试可以取代系统测试。如表1所示，其他形式的测试，如回归和探索性测试，不太常见，但最近在公司内越来越重要。

4.3.数据采集

数据是通过访谈和过程文档收集的。然而，由于缺乏可用性和数据质量（例如定量数据）不足，未收集其他来源的数据。使用多个数据源（三角测量）背后的动机是限制仅一种解释的影响，并由此使结论更有力。

4.3.1.受访者选择

受访者的选择过程使用以下步骤完成：

• 创建了参与测试过程的人员的完整列表，无论他们的角色如何。

• 我们想为每个项目选择至少2个人，从可