阿里云自助建站和华为云自助建站/药品网络营销公司

EBSE专题连载共分为“五个”篇章。此文为该连载系列的“第四”篇章，在之前的“篇章（三）”中已经结合具体研究实践阐述了“步骤二，通过系统调研确定改进方案”等内容。那么，在本篇章（四）中，我们将详细分析EBSE步骤三：批判性地反思证据以及当前问题解决。

汽车EBSE测试流程分析（一）：汽车软件测试的特征和问题

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

汽车EBSE测试流程分析（三）：通过系统调研确定改进方案

6. 步骤三：批判性地反思证据以及使用它来解决当前问题

价值流图(VSM)作为过程分析工具用于评估优势和劣势。该工具用于发现和消除浪费。价值流捕获了当前将产品通过主要流程步骤带给客户（流程的端到端流程）所需的所有活动（包括增值和非增值）。增值活动是为产品增加价值的活动（例如通过确保功能的质量），非增值活动是指等待时间。价值流中最大的延迟或瓶颈（即非增值）为提高流程能力提供了最大的机会。选择VSM背后的动机是因为它是一种高效的工具，我们可以通过它来完成测试过程以了解工作流程并明确地专注于从端到端的角度识别浪费。它使管理者能够从价值创造的角度后退一步，重新思考整个过程。此外，它对于汽车行业来说是很自然的，并且很容易被接受为一种改进方法，因为它起源于汽车领域（例如丰田产品开发系统）。

价值流图分两步完成。在第一步中，使用图3中的符号映射当前活动，区分增值和非增值活动。通过突发信号指示浪费和低效率。软件工程通常定义七种浪费（见表12）。之后，绘制未来状态图，其中包含对已识别浪费的改进。图1显示了从案例研究中进行的测试过程评估中获得的信息，如何映射到价值流活动。

​

图3：价值流图表示法

6.1.当前状态图

我们执行了一个过程活动映射，通过它我们可视化了在测试过程中执行的各种活动。本节介绍当前价值流图，其中概述了VSM和访谈中发现的浪费。流程创造的价值针对不同的团队规模确定，如表10（价值的定义）和表11（流程中的价值概述）所示。

​

表10：价值定义

非增值活动在测试过程的当前价值流中被识别，以便查看需要改进的地方，如图4所示。

测试过程的当前状态图，揭示了在精益软件开发/价值流映射的背景下定义的所有七种浪费。确定的七种浪费包括部分完成的工作、额外处理、交接、任务切换、再学习、延迟和缺陷（编号为W1-W7）（参见表12的浪费定义）。

这些浪费在测试过程中的不同活动中被识别出来，导致返工、等待时间增加或在整个测试活动中花费的时间效率低下。图4说明了规划的测试过程和识别的浪费。但是，在影响测试的其他活动（例如，需求管理等）中出现的问题没有显示在当前流图。其背后的原因及其对测试活动的负面影响在上一节中进行了讨论。

我们在测试过程中确定了12个区域（如图4所示的1-12），其中出现了浪费。以下是对当前流图中确定的每个子流程中发生的浪费的描述。

子过程1中识别的浪费：子过程1中观察到的浪费是部分完成的工作。未完成测试的原因是由于缺乏测试定义和匆忙完成测试（C1）而导致缺乏计划测试，最终导致以低测试覆盖率的非结构化方式进行测试。不明确的要求加剧了这种情况。

​

图4：当前状态图

​

表11：价值

​

表 12：浪费定义

子过程2中确定的浪费：在这个过程中，我们确定了“额外功能”和“切换”的浪费。有时在发布之前，从系统中删除的额外功能，即使它们已经实现，例如由于不稳定和不明确的要求（C03）。但是，也会对此类特性/功能进行测试。这种浪费是以编写测试计划、随后安排测试和分配资源的方式发生的。不明确的要求还需要重新学习（W3）。

子过程3中确定的浪费：如案例研究中所确定的，案例组织中的一个普遍问题是资源限制(C04)。这里发生的浪费是缺乏测试人员的可用性（W3：交接）以及作为组织结构一部分的角色和职责不明确，这阻碍了正确团队的形成，导致任务切换（W4）。

子过程4中识别的浪费：由于客户和开发组织需要大量时间来协商当前版本的候选需求，因此工作没有向前推进并被延迟（W1：部分完成的工作/W6）。据观察，此过程会重复多次，涉及与客户的多次交互，因为没有人与其他人对需求有相同的看法(C03)。为了为需求编写测试用例，必须有一套稳定而详细的需求来设计和分析下一个版本的测试。

子过程5中识别的浪费：这里的延迟再次以长时间等待（W06：延迟）的形式出现，用于引发验证要求（C03），从而最终确定要在测试活动中执行的测试用例清单。以前版本的测试用例有时不会更新。这会花费大量时间和精力来重写（W5：重新学习）以前版本的要求，并将这些测试用例包含在当前版本中。测试用例生成缺乏自动化，也是造成这种延迟的一个原因，因为只要不自动化，测试就是返工（与测试工具相关，C07）。

子过程6中确定的浪费：如前面挑战C10中所讨论的那样，有关测试的文档并不总是得到维护。以前版本的测试用例并不总是更新到测试用例存储库，这意味着未记录的测试工件（W1：部分完成的工作）。这些丢失的测试工件中的一些可能会使测试活动陷入危急情况，最终导致再次重复整个测试。

子过程区7的浪费：部分项目需要测试设备进行测试。客户的测试设备无法按时用于测试（W3：交接）。然而，在某些情况下，这种浪费会减少，因为在先前版本中使用的测试环境会被保存下来，并为产品的后续版本进行维护。正如挑战C7中所指出的，这种疏忽没有具体原因。

子过程区域8中的浪费：案例组织中执行的所有测试活动，都使用不同的工具进行管理，这通常是为了节省时间。但实际上这些工具并不能达到这个目的。相反，使用这些工具管理和映射测试工件会消耗更多资源，有时还会产生冗余，从而产生不必要的复杂性。没有一个可以管理和组织汽车领域所有测试活动的统一工具，这使它成为一个挑战（C7），从而造成称为交接（W3）的浪费，这与人员、设备等的可用性有关。

子过程区域9中的浪费：测试未作为与开发(C09)并行的活动进行。最终跟踪缺陷会消耗时间和金钱，这似乎是测试人员的负担，导致巨大的延迟(W6)。大多数团队不使用支持早期缺陷检测的验证活动，例如检查和代码审查。此处发生的另一种浪费（W4：移交）可能是由于缺乏测试人员的可用性以及使用特定测试技术（例如探索性测试或基于经验的测试）实施测试的培训。探索性和基于经验的测试基于测试人员的直觉和技能（参见C04）。尽管此类测试技术被认为是案例组织的优势，但目前只有有限数量的、有能力进行此类活动的测试人员可用。当这些有经验的测试人员退出或转移到另一个项目时，这反过来会导致测试延迟。然而，关于如何使用测试技术和工具的文档不会持续更新（有时不可用），因此不能信任执行测试 (C10)。
（关于C01-C010参见本专题连载篇章（二））

子过程区域10中的浪费：自项目开始（W1：部分完成的工作）以来，未正确引出需要包含在被测工件中的质量属性，从而导致产品质量差。部分受访者认为测试只是为了确保基本功能的质量，因此无法确保交付系统的可靠性（C08）。缺乏衡量质量水平和能够将测试结果与先前版本进行比较所必需的质量标准。对测试结果的分析有助于重新定义需要在下一版本产品中实施的质量改进。一些员工还报告了长时间的延迟（W6：延迟），因为在报告缺陷后必须等待开发人员修复缺陷。当负责代码的人在上一个项目中完成工作后，立即转移到其他项目时，这种等待时间似乎很长（见C04）。如果测试与开发并行执行，则可以解决此问题。

子过程区域11中的浪费：由于需求的波动性 (C3)，需求规范没有很好地记录，从而导致对需求的误解。在开发和测试被误解的需求上投入的精力和资源是没有用的（W3：重新学习）。然后在与客户进行一系列交互之后，引出和开发必要的需求，这会导致不必要的返工和任务切换(W5)。

子过程区域12中的浪费：在以前的版本中检测到的缺陷有时没有修复（W1：部分完成的工作），这是客户同意的。但是随着系统的发展，这些缺陷很难在下一个版本中跟踪。缺乏验证活动和早期缺陷预防活动（W7：缺陷）在发布前造成混乱，当前版本中的一些未解决的缺陷留给下一个版本。这个过程在每个版本中重复多次。随着功能的增长，遗留了许多未修复的缺陷，在如此复杂的系统中很难追踪这些缺陷。

表13提供了浪费及其与挑战的关系的摘要。

6.2.未来状态图

从结果中可以明显看出，其他流程，尤其是需求收集和文档，以负面方式影响测试并导致许多浪费。我们发现最常见的浪费，即W3：交接和W1：部分完成的工作，是由于长时间延迟引发明确和稳定的测试要求而发生的。测试过程中已识别的挑战报告说，不断涌入的需求导致测试覆盖率下降，以及由于延迟测试导致的故障数量增加。当前版本中出现的故障有时没有得到修复和交付，因此相同的故障在下一个版本中重复出现，但跟踪和修复变得困难且成本高昂。因此，当前使用的测试方法不适合连续的需求流，表明有必要转向新的方法，这种方法可以管理和组织变更，同时提高质量。

​

表13：浪费

未来状态VSM如图5所示，本质上是敏捷的。所示过程代表一次迭代。

我们推荐使用敏捷实践(SP6)和测试管理(SP7)，这有助于通过开发和测试的并行化、早期故障检测和简短的沟通方式更有效地利用测试人员的时间。敏捷还有助于在测试人员的要求方面实现高透明度，因为测试计划是针对所有迭代完成的。但是，可以针对每次迭代详细更新测试计划。特别是敏捷实践(SP6)强调需求积压和迭代资源估计，以保持它们的准确性和灵活性。同时，需要记录测试计划，因为这是能够有效地重用测试工件并使测试与每次迭代的需求活动（在SP7中提出）保持一致的先决条件。为了引出需求，用户故事被发现很有用（参见SP1）。抽象级别可能很重要，因为在一个抽象级别上对需求进行优先排序时，必须将优先级传播到其他级别（参见SP1）。
（关于SP1-SP7参见本专题连载篇章（三））

发现灵活的测试过程是项目的优势，尤其是在小型团队中。大多数时间测试是以交付更多功能（价值：V1）而不是质量的方式完成的。然而，一些测试技术，例如完全依赖于测试人员能力和技能的探索性和基于经验的测试，被发现可以提高汽车领域实施的测试过程的质量。这项研究还表明，资源限制方面的挑战，例如难以找到具有适当测试能力的从业者，他们具有执行汽车领域特定测试的专业知识和经验，成为质量整合的障碍。在这种情况下确定的浪费，可能是长时间的延迟或缺乏执行测试活动的人员（W3、W4）。8个研究项目中几乎有6个缺乏专门的测试人员。

使用质量标准/措施(SP3)有助于达成对测试的共同看法，因此交流和知识共享变得更加容易，这在进行测试的人数稀少时非常重要。敏捷测试方法可能不会自动导致质量合并，但通过适当的敏捷实践，这是可能的（参见SP6）。本研究中对Scrum master的采访清楚地表明，当正确使用敏捷方法时，它是一种力量，不仅提供灵活性和敏捷性，还提供质量。

与时间和成本限制、测试技术(C02)以及工具和环境(C07)相关的挑战，使得编写好的测试显然具有挑战性。自动化测试可以节省时间并提高测试的价值和收益。正如SP4中记录的那样，已经提出了多种工具和方法来自动执行不同类型的测试，因此选项多种多样，选择哪个选项也取决于给定上下文中的比较分析。为了进一步改善这种情况，团队可以尝试实施其他测试技术，例如探索性测试，它已经在一些项目中使用并且可以有效地发现缺陷。探索性测试已在本专题连载的篇章（二）的第4.5.2节中作为优势提到。单元测试和回归测试的自动化可以促进测试用例的重用，并为最终产品增加价值。在敏捷开发(SP6)中，测试驱动开发有助于单元测试的自动化，因为自动化测试是在编写新功能之前编写的。基于SLR本专题连载的篇章（二）的第4.5.2节中确定并建议了多种支持测试的工具，这些工具已在汽车行业中使用。

​

图 5：未来状态图

从这项研究中可以合理地说，测试不像开发新代码那样受到重视。从访谈中可以看出，测试的优先级较低，这不利于测试中的知识共享和知识转移。在这方面，能力管理可以被认为是测试活动必不可少的，它可以通过知识转移和共享来提高测试方面的技能和知识（参见SP2）。此外，我们认为，如果可以在项目开始时估计所需的测试人员，并以轮换方式分配且与多个团队分享他们的知识，那会更好。这也将帮助他们提高每次迭代的能力水平，从而改进测试。

针对已识别机会的解决方案提案基于SLR和访谈（考虑到所提到的价值和好处）。在本研究范围内无法验证解决方案建议。然而，建议取自同行评审的文献，这些文献在行业中得到验证，并且与本研究调查的公司使用敏捷的经验非常一致。此外，解决方案已提交给提供反馈的从业者。提出的未来状态过程已经包含了他们的反馈。

更多内容，请关注“汽车EBSE测试流程分析（五）：步骤四，评估和反思EBSE过程”。