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

点击阅读：汽车EBSE测试流程分析（一）：汽车软件测试的特征和问题https://blog.csdn.net/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个人，从可用性的角度来看，这是不可能的。特别是，对于小型项目，只选择了1个人。对于更大的项目，选择了更多的人。此外，应涵盖与测试过程相关的不同角色（包括开发人员、经理和指定的测试人员）。然而，参与访谈的最终员工名单是根据进行访谈的时间段的可用性而定的。

• 我们通过电子邮件向受访者解释了为什么他们被考虑参加这项研究。邮件还包含研究目的和采访邀请。

表1：项目概览（分析单位）

所选角色代表直接参与测试相关活动，或受整个测试过程结果影响的职位（见表 2）。

表2：角色描述

来自三个部门Alpha、Beta和Gamma（出于保密原因，部门名称已重命名）的项目和直线组织的角色都包含在我们的研究中。还可以看出，有些角色与项目工作相关，有些与部门内的直线职责相关，即他们支持部门内的不同项目。与部门、项目和角色相关的访谈数量如表3所示。

表3：受访者

在Alpha和Beta部门，有足够数量的员工可用，但在Gamma，由于该部门人员不足，只有1个人接受了采访。之所以选择此人，是因为她被认为是在测试汽车系统方面拥有丰富经验的专家。

4.3.2.面试设计

访谈包括四个主题；访谈的持续时间定为每次约一小时。所有访谈都以音频格式录制，并做了笔记。在所有采访中都使用了半结构化采访策略。采访的主题是：

1. 热身和经历：关于受访者背景、经历和当前活动的问题。

2. 软件测试过程概述：与测试对象、测试活动以及为进行测试所需和产生的信息相关的问题。

3. 测试过程中的挑战和优势：这个主题抓住了优势/好的实践以及挑战/表现不佳的实践。受访者应该说明他们使用了什么样的实践，它的价值贡献是什么，以及它在测试过程中的位置。

4. 测试过程的改进空间：这个主题包括收集有关为什么必须消除挑战，以及如何改进测试过程的问题。

4.3.3.工艺文件

研究了软件开发过程文档、软件测试描述文档、软件测试计划文档和测试报告等过程文档，以深入了解测试活动。此外，研究了与整个开发过程的组织和过程描述相关的文件，以熟悉公司使用的术语。这反过来有助于理解和分析访谈数据。

4.4.数据分析

为了了解汽车测试过程中的挑战和优势，我们使用编码的方法对不同的分析单元进行了深入分析。对5份访谈记录进行了手动编码，以创建一组初始代码。这些代码分为不同的主要类别，根据我们的研究问题（Level 1）、文献（Level 2）和开放编码（Level 3和Level 4）预定义，请参见表4。由此开发了编码指南。我们对采访中的转录文本采用了开放式编码，这些采访不断演变。例如，如果我们发现一个新的语句不适合已经确定的代码，我们就会创建一个新的代码，例如交互和通信。当我们发现另一个属于现有代码的语句时，我们将该语句链接到该代码。在对文本进行编码后，我们查看了每个集群，识别出非常相似的陈述，然后重新制定它们以代表一个单一的挑战/优势。完成后，我们审查了集群并为每个集群提供了高级描述。为了验证编码指南，案例组织的一名员工对访谈记录进行了手动编码，并将编码结果与研究人员的解释进行了比较，并进行了必要的修改。编码指南在整个数据提取阶段不断完善。

4.5.结果

结果包括对测试过程的描述，以及与该过程相关的优势和挑战。

4.5.1.测试过程

大多数受访者（9名受访者）表示，缺乏可应用于任何项目生命周期的明确测试流程。在所研究的8个项目中，只有3个项目具有明确定义的测试过程。据观察，每个项目都遵循与图2所示非常相似的过程，尽管并非所有项目都遵循此过程中概述的所有活动。

一个组织的测试策略描述了需要进行哪种类型的测试，以及如何将它们用于风险最小的开发项目。公司使用的测试策略主要集中在黑盒测试上，只有一小部分测试作为白盒测试执行。组织内有一本测试人员手册，其中描述了测试过程、方法和工具。但是，这项研究表明大多数团队都没有实施/使用它。进行的主要活动是：测试计划、测试分析和设计、测试搭建、测试执行和报告。其中，测试计划由5个项目（P1、P2、P4为代表的三个大团队和P5、P7为代表的两个小团队）提前完成。大多数小团队没有任何软件测试计划，尽管他们有非常灵活的测试策略/方法来进行测试。

下面将更详细地描述这些步骤：

测试计划：此活动旨在解决要测试的内容和原因。此活动的进入标准是为发布准备好优先需求，作为测试计划的输入。该阶段交付的是软件测试计划，包含对所需资源的估计和调度、要创建的测试工件，以及所需的技术、工具和测试环境。该阶段测试涉及的角色有客户、项目经理和测试负责人。如果项目没有可用的测试负责人，则开发人员自己参与测试计划活动。测试计划的出口标准是客户和项目管理对测试计划的批准。

表4：通过编码进行分析

测试分析和设计：此测试活动旨在确定如何执行测试（通过定义测试数据、测试用例和被测过程或系统的进度），这记录在软件测试描述中。软件测试描述还定义了在测试执行期间将执行哪些测试（即测试技术）。此阶段的其他交付是需求可跟踪性矩阵、测试用例和用于实现测试用例的测试脚本设计。测试用例是使用所有项目中使用的测试用例管理工具编写和管理的。进入这个阶段的标准是软件测试计划得到客户和项目管理人员的认可。上一阶段安排的测试计划会更新为每个测试活动的所有详细时间表。此阶段涉及的角色是测试负责人或测试协调员，他们负责设计、选择、确定优先级和审查测试用例。由于测试人员在项目之间分担责任并且并不总是可以执行测试任务，因此在大多数项目中，开发人员负责为自己的代码编写测试用例。项目经理负责测试活动的监督。

测试搭建：在汽车软件测试中，测试搭建是测试过程中最重要的部分，因为它涉及构建描述目标环境的测试环境。这个级别的结果是拥有硬件和可以将其可视化为实时环境，包括测试脚本和所有其他测试数据。由于案例组织与大多数项目的控制引擎和电子控制单元(ECU)一起工作，建模工具如Simulink和MATLAB被用来可视化目标环境。大部分测试人员或开发人员参与此活动。项目经理负责提供资源，如硬件设备。测试组长监督活动。

测试执行和报告：测试过程的最后阶段是执行测试并将结果报告给客户。为了执行测试，测试负责人或项目经理将选择合适的人来运行测试脚本。测试完成后，结果将记录在缺陷管理系统中。此阶段的结果是一份软件测试报告，其中描述了所执行的整个测试及其测试结论。稍后还会对结果进行分析和评估，以发现与之前版本的测试报告相比是否存在任何差异。如果出现严重错误，将纠正这些错误并重复测试。项目经理负责决定测试执行的停止标准。

4.5.2.优势和经验

发现测试过程的优势取决于团队规模。大多数在小型团队中被视为优势的实践，在大型团队中并不被视为优势，反之亦然。也就是说，从访谈中可以明显看出，优势随团队规模而变化。

在小型敏捷团队中工作：测试活动很灵活，无需生成大量测试报告。大型团队仅针对小型版本执行此操作。大型团队有一个非常结构化和计划驱动的测试方法。小型团队专注于持续集成和迭代开发（例如，P2使用具有持续集成和冲刺计划的Scrum）。敏捷测试实践使他们更容易为与需求规范兼容的每个迭代计划测试。这反过来又可以使测试与其他活动（如需求、设计等）正确对齐。与小团队相比，大团队在大多数时候更注重重用测试用例，这使得他们更有效率。

图2：测试过程

沟通：在具有敏捷实践的项目中可以发现沟通的优势，例如站立会议、定期的利益相关者协作以及在开放式办公空间中一起工作。每个活动都涉及一个测试人员，这表明整个开发生命周期中的并行测试工作。除此之外，敏捷方法增强了团队精神，导致团队成员之间的高效互动，并形成了跨职能团队。其他项目使用每周会议和其他电子服务，例如项目内的电子邮件和消息传递。

共享角色和责任：小型团队认为让一个人来执行测试人员和开发人员的角色是一种优势，因为这不会延迟等待某人测试软件的过程，一位开发人员表示：“当我们工作时，由于测试人员与开发人员是同一个人，所以不会延迟报告。因此，如果开发人员/测试人员发现错误，他知道错误是从哪里引入的，而不是责怪别人，开发人员在编写代码时会更加小心”。但是，大型团队并不认为这是优势；这些团队中的大多数都没有任何专门的测试人员（除了一个拥有专门测试团队的大型团队）。

测试技术、工具和环境：在这里，我们对项目的规模进行了不同的观察。在小团队中，使用较少的测试工具和方法来避免更多的文档。与大型团队相比，这些团队的项目模块通常较少。在这种情况下，系统为测试人员/开发人员所熟知（开发和测试由小团队中的一个人完成），这使得使用最少数量的工具和方法进行测试变得容易。小团队（例如项目P3、P6）一般先进行冒烟或单元测试，测试系统的基本功能，然后再进行集成测试。一名员工通过以下方式传达单元/基本测试的用途：“我认为单元测试是一种优势。有了这个进入细节并确保每个子系统都按预期工作”。这里使用的测试工具是由团队开发的，以适应项目需求。但是，这些为其特定团队开发的定制工具不会在团队之间共享。小型团队的主要关注点是拥有一个与目标环境具有相同硬件和接口的测试环境。这使得项目中的测试维护变得高效。

推荐的代码测试工具

与小团队相反，大团队使用多种方法和工具进行测试以执行多项活动。在大型团队中发现的最明显的优势之一是基于经验的测试（例如P1、P2、P4和P8等项目）。由于相同的团队成员多年来一直致力于同一个项目，他们发现在产品开发和测试中使用他们基于经验的知识很容易。一个大型团队中负责质量协调的员工说：“用于测试的指标对我们团队没有太大帮助，因为测试更多地是基于我们的经验，我们用这些经验来决定需要运行什么类型的测试用例。”另一个可感知的优势是在项目P1和P2中应用的探索性测试/基于会话的测试管理。一位员工指出“执行基于会话的测试（即探索性测试）的章程，我们发现了更详细级别的关键错误”。硬件在环(HIL)也被认为是大型团队之一的优势，因为它可以在集成测试期间检测到大部分缺陷。用于集成和系统级测试的HIL被认为是一种优势，因为它可以检测最关键的缺陷，例如大型和复杂系统的时序问题和其他实时问题。非正式代码审查被认为是大型团队的优势，尽管它们也被用于小型团队。非正式的代码审查避免测试产生偏见，因为它是由负责编码的人以外的人执行的。

谈到工具，测试用例管理工具被认为是大型团队（例如P4）的优势，正如一位员工指出的那样，“我认为测试用例管理是存储测试用例、选择应该执行的测试以及测试人员提供反馈的好方法”。其他被认为有用的工具是缺陷管理工具（例如，项目）。大型团队中的测试环境非常适合测试，因为它描述了实时环境。

4.5.3.挑战

挑战分为几个领域。对于每个挑战领域，我们还说明了在挑战领域内提出挑战的项目数量，以及挑战领域所关注的过程领域（见表5），并报告了每个领域的一系列相关问题。

表5：挑战领域概览

C01：测试的组织及其过程相关问题：组织问题涉及与组织及其测试过程相关的执行不力的实践，如变更管理、缺乏结构化的测试过程等。组织问题还包括利益相关者对测试的态度（如果测试被给予低优先级）。

C01_1：没有统一的测试流程：项目在测试方法和工具的使用上各不相同，由于硬件和软件的功能分散和复杂性不断发展，找到一个适合所有项目的统一流程被认为是一项挑战。尽管有测试人员手册可以帮助实现更统一的流程，但由于团队没有意识到这一点，或者人们觉得这不适合他们的项目特征，所以没有使用它。非结构化和组织性较差的流程适用于小型项目，但不适用于大型项目，因为这会影响质量。正如受访者所指出的那样，“感觉缺乏结构化的测试流程，而且总是没有组织。它对小项目很有效，但对大项目不适用”。

C01_2：测试仓促完成，计划不周：交付日期没有延长，因为需要更多的时间，这导致测试受到影响，仓促完成。此外，客户没有及时交付用于测试的硬件和确保良好的质量，因此测试无法提前完成；结果是普遍不遵守测试的最后期限。

C01_3：利益相关者对测试的态度：过去的改进工作侧重于实施，而不是测试。因此，新的测试方法没有得到管理层的太多支持，这有时会使团队开发自己的方法和工具，这需要付出很大的努力。

C01_4：异步测试活动：测试与供应商相关的其他活动不同步；测试工件必须重新结构化，以便与供应商提供的工件同步。这会导致测试方面的返工。

C02：测试的时间和成本限制：时间和成本约束方面的挑战可能是由于在需求、测试活动或测试过程上花费的时间不足。

C02_1：缺乏规定验证要求的时间和预算：验证要求是在测试期间进行验证的要求（例如，规定必须测试系统的环境条件）。由于没有编写验证要求而节省的时间和金钱导致了流程其他部分的大量返工和时间，特别是测试。

正如一位受访者所指出的：“将客户规范重新写入我们自己的要求中？这在今天是不可能的，因为客户不会为此付费，而且我们没有内部预算。”总的来说，缺乏验证要求导致缺乏目标和明确的测试范围。

C02_2：测试设备按时可用：测试设备不能按时可用且质量不好，导致无法进行单元测试。

C03：与需求相关的问题：测试需求不足、难以理解的高层次需求以及需求波动性是阻碍进行适当测试以实现高质量的挑战。这些问题通常发生在客户由于缺乏时间或知识而没有正确指定需求时，这意味着需求管理不善。

C03_1：缺乏明确的需求：在理解和记录明确的需求方面投入的精力太少，导致在后期阶段（如测试）重新解释需求的精力太多。正如其中一名员工所指出的：“我认为，我们最好开始在需求管理方面付出更大的努力，避免客户抱怨误解/曲解他们指定的需求，以便最终减少问题，并节省重复更改和测试所有内容的时间”。

C03_2：最终确定测试设计和启动/停止测试的标准尚不明确：根据访谈，一旦需求稳定，将完成测试过程的定义。受访者将需求波动性与测试的启动和停止标准联系起来。需求的波动性要求重新定义整个测试计划。这在实际测试开始时起到了障碍的作用。在组织使用测试脚本执行测试的情况下，随着需求的涌入，他们很难定义何时停止脚本编写和启动/停止测试。何时停止测试的标准主要与预算和时间有关，而与测试覆盖率无关。

C03_3：需求可追溯性管理问题：需求和测试之间的可追溯性可以更好，以便在需求变化时轻松确定哪些测试用例需要更新。此外，缺乏可追溯性使定义测试覆盖范围变得更加困难。缺乏可追溯性的原因是需求有时过于抽象，无法将它们与具体功能及其测试用例联系起来。

C04：测试的资源限制：这些挑战与熟练测试人员的可用性及其知识有关。

C04_1：缺乏专门的测试人员：并非所有项目都有专门的测试员，而是开发人员解释需求、实现软件和编写测试。缺乏独立的验证和确认（不同的人编写软件并测试软件）导致测试中存在偏见。

C04_2：测试人员不可用：考虑到系统的复杂性，积累知识成为一名优秀的测试人员需要时间。如果经验丰富的测试人员在项目之间轮换，很难找到能够完成手头任务的人。一位负责测试的受访者表示：“很难找到有同样经验的人，而且由于产品的复杂性，他们需要很长时间来学习和了解产品。因此，在进行测试之前，需要具备相同的知识。”

C05：与知识管理相关的测试问题：本案例研究中发现的与知识管理相关的问题包括：

C05_1：关于测试的领域、系统知识转移和知识共享问题：公司使用的新测试技术（探索性测试）需要大量的知识，而这些知识是不可用的，因为测试人员总是在变化，并且所研究公司雇用的新测试人员来，这些知识是不可用的进入项目。尽管需要达到一个项目不依赖于一个人的状态，但没有足够的信息和培训材料来说明如何进行测试。从采访中我们还发现，知识转移的挑战被放大了，因为除了软件之外，它还强调控制工程、机电一体化和电气工程。

C05_2：缺乏基本测试知识：由于测试人员缺乏基本的测试知识，测试的优先级较低。关于这一背景，一位参与生命周期管理活动的受访者表示，“我认为缺乏关于测试基础的信息。我们中的一些人不知道什么时候开始测试，什么时候结束测试，这感觉就像是灰色地带，在任何地方都没有明确定义”。

C06：测试中的互动、沟通相关问题：与测试中不同利益相关者之间的沟通相关的实践中的问题。还包括不适当的沟通形式，如缺乏定期的面对面会议，客户和测试人员之间缺乏沟通。

C06_1：缺乏与客户就需求进行的定期互动：在项目开始时，客户互动更频繁，就测试中的验证需求而言，客户互动太少。客户方面没有合适的人员就测试要求进行沟通。

C06_2：在测试过程中缺乏与项目中其他角色的互动：缺乏与已转移到另一个项目的先前团队成员的沟通，即使他们是需要的（例如，为了验证和修复已识别的错误）。一位受访者通过以下方式叙述了这件事；“我已经为我们的团队分配了一个人，然后他必须与我们沟通，但有时这个人很难找到那个人，因为他现在在另一个团队工作”。

C06_3：与客户的非正式沟通：总体而言，与客户缺乏面对面和非正式沟通，客户通过提供模糊的描述进行沟通，但这些描述没有得到澄清。一位经理补充道：“我认为最重要的是保持关系（与客户的非正式关系），并要求客户在你告诉我们你想要什么之前，我们不能开始工作”。

C07：测试技术、工具和环境相关问题：与当前测试技术、环境和工具的使用有关的问题。

C07_1：缺乏自动化导致返工：单元测试和回归测试的自动化没有有效完成。一位受访者指出，“只要没有适当的自动化，测试就是返工”。由于缺乏工具支持，生成和有效地自动化测试被视为一项挑战，导致在想要重新运行测试时返工。

C07_2：整个测试活动没有统一的工具：一位测试负责人指出需要可用于测试的统一工具“我们有很多工具可供测试，但在决定使用哪种工具时存在一些困难，因为所使用的每种工具都有缺点和优点。有时我们被迫开发定制工具，因为我们无法从市场上获得任何能为我们做一切的工具”。一个在汽车领域进行所有测试活动的工具可以很容易地使用，而不是管理和组织目前使用的大量工具。

C07_3：测试设备维护不当：需要维护多个测试环境，缺乏维护会导致返工，实际测试开始前的交付周期很长。一位受访者很好地总结道：“我们有几个测试环境和测试步骤需要维护。它们并不总是需要维护的，需要很长时间才能开始实际的测试”。

C08：质量方面相关问题：与纳入测试质量属性有关的问题，如可靠性、可维护性、正确性、效率、有效性、可测试性、灵活性、可重用性等。涉及质量和其他活动之间的权衡。

C08_1：可靠性问题：系统的可靠性没有达到所需的程度。由于缺乏测试流程和硬件组件故障，质量很难整合。正如一位受访者所指出的那样，“很难达到一个系统的几个要求标准，例如工作时间更长、资源密集度较低、在不同平台上工作的能力等”。

C08_2：从项目一开始就没有很好地规定质量属性：质量要求没有很好的规定，导致复杂系统在现有产品的市场上出现质量问题。

C08_3：没有质量测量/评估：没有质量措施，但人们认识到它们的必要性，以提高评估测试结果的能力，一名员工说：“尽管我们的客户很满意，但质量曲线必须更好。我认为应该记录质量措施，以便于更好地分析测试结果”。

C09：缺陷检测问题：与使测试人员无法追踪缺陷，或缺陷产生的根本原因的实践相关的问题，也包括与缺陷预防相关的问题。

C09_1：过程中的后期测试使得修复缺陷的成本很高：由于系统的复杂性和后期测试，系统中的缺陷数量随着系统的发展和规模的增加而增加。由于之前版本中缺少许多缺陷，导致客户在接下来的版本中报告了大量需要纠正的缺陷，这使得修复缺陷的成本很高。

C09_2：难以跟踪先前版本中未修复的缺陷：对于复杂零件的开发（即涉及处理时间问题和其他关键问题），两个不同版本之间的系统行为差异需要相同。但这种情况并不总是发生，因为在当前版本中触发了以前版本中未修复的错误。这是因为当这些错误在如此庞大的系统中无法追踪时，它们可能会在下一个版本中变得严重。

C10：与文档相关的问题：与测试文档相关的执行不力的实践，如文档不足、没有文档或文档过多，无法为维护测试过程中的质量提供适当的支持，都是该挑战领域的主题。

C10_1：关于测试工件的文档没有持续更新：受访者强调，提供的文档（如测试用例和其他测试工件）不足以进行测试，不能信任；一位受访者补充道，“测试文件没有持续更新，所以我们发现它们不可靠”。提到的原因之一是对测试工件进行了一些小的更改，但这些更改并没有相应地更新测试文档。未更新文档导致返工。

C10_2：没有关于某些特定测试方法和工具的详细手册：在这方面的另一个观察结果是缺乏关于工具和方法如何工作的文件。一位受访者很好地总结道：“有对工具的支持，但我们总是找不到可以用它们解决问题的人。我想它可以被更好地记录下来”。然而，据观察，组织内有一些手册可以达到这一目的。但对于一些特定的工具（如定制工具）或方法，这是行不通的。当进行测试的人不能理解手册中的术语或他们不知道这些手册时，就会出现这个问题。

更多内容，请关注“汽车EBSE测试流程分析（三）：EBSE步骤二，通过系统文献综述确定改进”，关注牛喀网，学习更多汽车科技。