内容提要：本篇章具体阐述EBSE步骤四，评估和反思EBSE过程。

EBSE专题连载共分为“五个”篇章。此文为该连载系列的“第五”篇章，在之前的“篇章（四）”中，我们已经针对“步骤三：批判性地反思证据以及如何使用它来解决当前情况下的问题”进行了具体分析。作为此专题连载的收尾，我们将在本篇章具体阐述EBSE步骤四，评估和反思EBSE过程。

7.EBSE 步骤四：评估和反思EBSE过程

我们提出了一个分阶段的EBSE过程，它结合了系统的文献综述和价值流映射，并将其应用于汽车测试过程的软件过程改进。特别是，我们的EBSE过程包括四个步骤。首先，我们进行了案例研究以调查挑战。其次，我们进行了特定领域的系统文献。在此基础上，我们制定了解决方案提案，并将其与我们的文献研究结果相关联（见本专题连载篇章（三）的表9）。第三，我们执行了价值流映射，将测试流程的挑战映射到价值流，这是将产品通过流程的主要步骤带给客户所需的所有操作（见本专题连载篇章（四）的图 4）。这向我们展示了流程中浪费（价值流图中称为挑战）所在的位置。我们创建了未来状态图，显示需要进行改进的位置（参见本专题连载篇章（四）的图5）。在第四步中，我们反思EBSE过程。

据我们所知，我们在EBSE过程中整合系统文献综述和价值流图的方法是新颖的。这两种技术都是在各自领域广泛应用的技术，即系统文献综述被广泛应用，软件工程研究领域和价值流映射，是一种在精益和汽车领域过程改进中进行过程改进的技术。将这两种方法结合起来可以看作是进行产学合作以及将学术知识转移到工业界的好方法。

然而，这种方法也有明显的挑战。从本专题连载中可以看出，该公司遇到的问题分散到软件工程的几个不同子领域。因此，如果我们对所有这些挑战进行了完整的系统文献综述，我们将无法在合理的时间内完成这项工作。因此，我们进行了特定领域的文献综述，以找到仅应用于汽车和嵌入式领域的解决方案。自然，这使我们对可能的解决方案的了解有限，但如果我们不这样做，人类不可能完成这项工作。

这个问题的一个可能的解决方案，是使用现有的文献调查作为解决方案建议和价值流映射的输入。然而，当前软件工程中的文献调查是针对特定主题而不是针对特定问题的，因此我们看不到使用它们的可能方法。对于特定主题的文献综述，我们的意思是当前系统的文献调查解决了诸如“结对编程对软件工程的影响？”或“我们对软件生产力了解多少？”等问题。我们看到，行业实际上会从针对特定问题的文献调查中获益更多，因为他们应该解决诸如“为什么测试窗口被压缩以及我们能做些什么？”之类的问题。或“为什么我们的客户沟通不畅，我们如何改进？”。如果软件工程研究社区的主要目标是服务于工业需求，也许将来执行后一种类型的系统性文献综述会变得更加普遍。

8.有效性威胁

有效性威胁是一种你可能会错的特定方式，基于实证研究的研究确实需要考虑威胁。与本案例研究相关的潜在威胁是：结构有效性、外部有效性和可靠性或结论有效性。

8.1.结构有效性：

结构有效性与获得所研究概念的正确措施有关。为了缓解这种威胁，采取了以下行动。

• 访谈对象的选择：存在因为有偏见地选择受访者，而使案例研究结果产生偏差的风险。公司代表的选择考虑了以下方面，例如流程知识、角色、跨不同层次结构的分布以及有足够数量的人员参与（根据本专题连载篇章（二）的表2）。因此，已注意确保所选人员的多样性（跨项目和角色），这有助于降低偏见风险。

• 反应性偏见：研究人员的存在可能会影响研究结果。研究人员和组织签署了一份保密合同，每位受访者都得到了匿名处理他们的回答，并且只提供汇总结果的保证。

•正确的数据访谈：结构有效性还解决了对访谈问题的误解。首先，对组织的一名员工进行了模拟访谈，以确保对问题的正确解释。此外，在采访之前（通过邮件/亲自）清楚地解释了研究的背景。通过将结果发送给每位受访者进行验证，对每次访谈进行成员检查。

8.2.外部有效性：

外部有效性是将研究结果概括为特定背景以及一般过程模型的能力。

• 特定公司：有效性的潜在威胁之一是本案例研究只研究了一家公司的测试过程。不可能在另一个组织进行类似的研究，因为这个特定的案例研究旨在改进各自组织的测试过程。然而，这种类型的深入研究提供了对汽车开发的总体知识，并且研究结果已从公司的特定流程映射到一般流程。因此，研究的背景和案例组织的情况得到了清晰详细的描述，这支持了所发现问题的概括，让其他人能够理解结果如何映射到另一个特定的背景。

• 团队规模：研究领域是汽车和嵌入式软件工程。团队规模会影响解决方案的适用性和此处讨论的挑战，例如，小型团队是敏捷工作的核心实践。我们想知道我们的案例在汽车软件公司群体中是否具有典型性。鉴于我们没有找到报告该领域团队规模的调查或研究，我们调查了类似的领域。因此，我们将搜索范围扩展到一般的嵌入式领域（包括航空电子、机器人等）。根据调查，团队规模差异很大，从少于3人的团队到多人超过300人的团队。最常见的案例是少于3人的规模（31个案例中的8个）、3到10人的团队规模（11个案例）和超过10到30人的规模（10个案例）。对于一般的团队规模，发现规模为8.16，标准差为20.16，最小-最大为1至468。其中没有报告中位数，但根据数字，它肯定小于平均值。这是因为少数非常大的团队对均值有很大影响，而在小团队方面，我们不能拥有小于1个人的团队。另外，请注意高标准偏差。因此，典型团队规模的问题类似于城镇或软件模块的典型规模的问题。

它们都极有可能按照幂律（或帕累托原理）分布，即大团队/城市/模块很少，小团队/城市/模块很多。因此，我们的团队规模似乎与其他（但不是所有）公司的团队规模相匹配。

在这种情况下研究的团队规模与研究人员调查报告的31个案例中的19个相关（团队规模小于10），这表明类似的领域也适用于较小的团队。关于解决方案（汽车的敏捷测试过程）的适用性，我们只能概括为所研究的团队规模，因此适用于与较小团队合作的汽车公司，或者将非常大的团队分解成较小团队的公司。

8.3.可靠性：

这种威胁与重复或复制有关，特别是如果在相同的环境中重新进行研究，将会发现相同的结果。

数据解释：研究结果总是存在受研究人员解释影响的风险。为了减轻这种威胁，该研究被设计为从不同来源收集数据，即进行三角测量以确保调查结果的正确性。对访谈进行了记录，并通过成员核查验证了正确的解释，以提高数据的可靠性。关于结果的结构（编码、挑战领域的识别），参与研究的研究人员审查了编码和解释，以避免研究人员产生偏见。我们还向被研究的公司展示了结果，他们同意了结构和确定的结果。此外，公司代表还审查了这篇文章，以检查信息是否符合他们的经验。在审查报告之前，我们还创建了一个结果结构作为思维导图。该思维导图还用于审查/成员检查。我们还让其中一位从业者进行编码，以验证我们是否会得出相同的解释，这使我们能够讨论/完善分析，从而提高解释的可靠性。

9.讨论

9.1.RQ1：哪些测试实践可以被视为汽车领域的优势？

测试的优势首先在本专题连载篇章（二）的第4.5.2节中列出，并在本专题连载篇章（四）的第6节中进一步阐述，其中映射了一般价值产生活动（见篇章（四）的表11）。在小型敏捷团队中工作被认为是一种好处，因为它减少了对文档和官僚作风的需求。小型团队还被认为会导致更多的迭代开发、更容易的持续集成，并允许更好地使测试与软件需求和设计保持一致。此外，受访者还将团队规模和敏捷方法的使用与改进的沟通联系起来，这使得软件测试更容易。先前的作品还描述了小型敏捷团队在软件测试方面的好处。此外，软件工程文献中反复讨论了良好沟通的重要性。

让同一个人编写代码并测试该代码的共享角色，在小团队中被认为是一个好处，但在大团队中被认为是一个缺点。在许多情况下，小型或大型团队都没有专门的测试人员。传统上，软件测试文献建议人们不应该测试自己的程序。然而，对行业中单元测试实践的调查实际上表明，开发人员创建了单元测试，而不是像建议的那样由外部测试组织创建。此外，对三个软件产品公司的案例研究表明，正如我们在本专题连载中所阐述的那样，专门测试人员的比例也很低。我们的发现扩展了先前工作的发现，表明对专门测试人员的需求以及是否应该测试自己的程序的问题，可能与团队规模的上下文变量有关。

然而，大型团队也体验到了一些在小型团队中未发现的好处。例如，大型团队通常有经验丰富的人员可用。这允许使用测试人员的知识和技能来决定执行哪个测试。最近一项研究行业探索性测试的工作，强调了测试人员知识的重要性。我们的发现加强了关于知识在工业软件测试中的作用的有限先验证据。探索性测试被发现是一种优势，它是脚本化和自动化测试的良好补充。有证据表明ET从工业环境中获益，例如能够找到最关键的缺陷。此外，ET和TCT之间的实验比较表明，在考虑缺陷检测有效性时，测试用例可能不会增加任何好处。

大型团队还受益于更好的管理，这在测试工件的重用、更好的测试活动组织、更有组织的工具使用以及通过基于会话的管理控制探索性测试中可见。因此，尽管小型团队和敏捷工作方式带来了可观的收益，大型团队也有收益，但它们更多地源于传统管理。

9.2.RQ2：在测试汽车系统时发现的挑战/瓶颈是什么？

尽管如前一节所述，大型团队的许多好处来自更好的管理，但也发现组织和流程问题在大型和小型团队中都存在问题。发现缺乏统一的测试过程是有问题的。可以找到关于一般软件过程改进的类似挑战，例如，人们不了解流程或流程不兼容。我们还发现由于软件开发延迟，导致测试窗口受限，且导致测试速度过快。时间和成本限制也与工艺挑战密切相关，例如，如果客户无法提供验证要求，那么测试显然难以确定范围和管理。在行业顾问获得的灰色文献中，据报道，这种测试窗口的挤压可以追溯到软件开发的V模型。此外，利益相关者对测试的不良态度在演示和讨论中被反复提及，因为研究者与几位软件测试专业人员进行了互动。

此外，在没有专门的测试团队的团队中，发现了测试的人力资源限制。因此，他们将需要专门的测试人员，或者通常需要更多的人员来创建执行测试。在调查公司的先前工作中发现了同样的问题，在这些公司中，测试被有目的地组织为横切活动，而不是依赖专门的测试人员。

我们在软件测试中发现了两类与知识相关的问题。首先，问题与域或被测系统有关。换句话说，案例公司的新测试人员需要经过培训或经验才能做出有用的贡献。领域和系统知识的先决条件与探索性测试特别相关，这与探索性测试的最新发现相匹配。我们还发现，对软件缺乏欣赏导致缺乏测试基础知识。认识到缺乏测试基础，研究人员指出，尽管经验丰富的行业专业人士知道基本的测试技术，但他们可能无法正确应用它们。同样，我们的实证研究结果加强了我们对工业软件测试问题的认识，似乎缺乏公司特定知识，以及缺乏基本测试知识也是汽车领域的挑战。

三个开发团队都提到了与需求相关的问题。众所周知，明确规定的需求构成了软件测试的基础，但直到最近，在实践中解决这个问题在经验软件工程研究中才受到有限的关注。在我们的案例中，我们发现了与需求清晰度、波动性和可追溯性相关的问题。

沟通方面的挑战要么是由于缺乏与软件需求有关的客户交互，要么是由于在测试前被转移到其他项目的前项目员工的适当交互。缺乏客户沟通加上需求不足，很自然地导致软件测试出现问题。然而，项目人员的更替也会影响测试，因为在项目结束时，原始开发人员或其他人员将无法回答开发人员的问题。

我们还发现了与测试技术、工具和环境相关的挑战。令人惊讶的是，我们公司缺乏测试自动化的工具，因为人们认为自动化测试在汽车行业等嵌入式领域会很好理解。缺乏工具使用可以追溯到公司拥有的测试自动化工具与对此类工具的要求之间的不匹配。有时公司甚至被迫开发自己的工具。这些工具的问题并不令人惊讶，因为最近的一项调查表明，大约只有一半的受访者认为市场上现有的测试工具可以很好地满足他们的需求。

纳入质量方面也被认为是有问题的，例如，可靠性目标被视为难以实现。此外，质量目标的定义缺失或定义太晚以及缺乏质量措施，被认为是有问题的。公司在这些领域面临问题并不奇怪，并且仅在最近几年才开发出经过工业验证的轻量级方法来解决此类问题。

还发现了与修复相关的问题，因为它表明很难从复杂的系统中找到源代码中的缺陷。难以检测缺陷的另一个原因是在项目结束时进行大爆炸式集成和测试，而不是在发布期间进行持续测试和集成。

关于测试文档，面临着一个二元问题。一方面，据称文件不足。另一方面，据称有太多不支持公司软件测试活动的文档，部分原因是文档更新不佳。这些与文档相关的问题在软件行业中非常普遍，这也是敏捷方法占据主导地位的部分原因——当没有文档时，人们不必因为文档不断过时而感到失望。

9.3.RQ3：文献中对基于实践经验的汽车测试过程提出了哪些改进建议？

对于26个挑战中的15个，我们在汽车测试文献中找到了解决这些挑战的解决方案。鉴于我们将文献综述的范围限定在与汽车和嵌入式软件工程相关的文献上，我们无法确定针对汽车文献中所有挑战的解决方案。因此，这些解决方案可能超出了我们审查的范围，但它们并未应用于研究领域。我们根据文献确定了七个解决方案建议，这些建议与需求管理、能力管理、质量保证和标准、测试自动化和工具、敏捷整合和测试管理有关。解决方案的概述在本专题连载篇章（三）的第5.1.3节中介绍，挑战与解决方案参考之间的映射在表9中。

9.4.RQ4：考虑到EBSE Step 1中确定的流程活动、优势和劣势，流程中的价值和浪费是什么？

我们识别了浪费，并将它们的位置映射到公司使用的汽车软件测试过程。本专题连载篇章（四）的表13给出了浪费和价值的综合视图。该表显示许多浪费是由于需求问题造成的，突出了需求在软件测试中的重要性。浪费W2、W3、W5和W6与需求问题相关。其结果是，最近的研究重点是将需求研究与验证研究相结合。

9.5.RQ5：基于EBSE Step 2中确定的解决方案，当前价值流图所代表的过程应该如何改进？

提出了一个新流程，其中包含来自文献综述的改进建议（见本专题连载篇章（四）的图5）。该过程结合了敏捷软件开发、审查、测试自动化以及持续的缺陷检测和纠正。可见，测试过程不仅与建议的改进有关，而且需求过程也受到影响。总的来说，我们可以得出结论，重要的是对改进后的流程对流程其他部分的影响进行评估，以调整改进工作。也就是说，当流程更新时，我们必须考虑其他流程，还要考虑更改如何影响组织、架构等。在这方面，文献讨论了业务、组织、流程和架构(BAPO)方面的对齐，但迄今为止，还没有针对这些活动的系统对齐的解决方案。因此，我们在这里强调了重要性，但此时无法为端到端流程提供解决方案。

从业者审查了该流程，并就其设计、可行性以及它有可能解决公司环境中提出的挑战达成一致。

9.6.RQ6：使用EBSE过程和混合研究方法的哪些方面运作良好？如何改进该过程？

在我们的研究中，我们面临着改进具有分散问题领域（例如需求、测试自动化、沟通问题等）的过程的情况，同时我们的行业合作者希望在合理的时间内为他们的问题提供解决方案。因此，我们决定将文献综述的范围集中在汽车软件工程上。从长远来看，我们发现现有的文献综述会有所帮助，因为它们不那么笼统，而且更多的是问题驱动/重点。我们提供了两个例子，即“为什么测试窗口会被挤压，我们能做些什么？”或“为什么我们的客户沟通不畅，我们如何改进？”。

除此之外，我们还看到有必要进一步扩展和了解基于先前研究的循证方法。有多种策略可用于执行基于证据的测试过程的步骤，此处介绍了一种执行基于证据的测试过程以改进过程的方法。将来，我们将在很大程度上受益于对比不同的策略，并提供证据证明它们对结果的影响，例如，文献综述。这也将有助于在研究投入的精力/时间与产出质量之间做出权衡决策，使我们能够向公司详细说明我们的战略将如何影响我们为他们提出的建议。示例问题是：

• 使用搜索字符串搜索文章、进行滚雪球抽样（查看已识别论文的参考文献——反向滚雪球；还是查看引用已识别论文——正向滚雪球）更好吗？

• 我们是否必须找到所有文章，或者是否有良好的抽样策略，以便系统评价的总体结论不会改变？

• 我们如何才能以公正的方式有效地选择研究，来解决我们的研究问题？

• 我们应如何解释和汇总不同研究的结论？

在未来关于EBSE的研究中，我们将跟踪时间和精力，因为这是一个重要的变量，很少报告（到目前为止我们也没有报告），但我们认识到需要做出明智的选择策略决策。已经提出了可以用来回答上述问题的文献，例如，研究人员评估系统文献综述中的搜索，还有研究人员将滚雪球抽样与数据库搜索进行比较，以及研究人员从一组确定的文章中确定了论文选择策略，并且提出了聚合证据的策略。

10.结论

我们使用分阶段的基于证据的测试过程，结合案例研究、系统文献综述和价值流分析来研究挑战，并为我们的案例公司创建解决方案建议图。这些技术已被广泛应用，但据我们所知，这是第一次将它们结合用于解决具体案例研究中的问题。我们看到，结合这些方法是进行行业学术合作的好方法，因为它允许使用严格的学术方法研究实际的工业问题，并产生映射到公司当前软件流程的结果。然而，在进行这项工作时，我们也意识到这种方法的一个重大挑战。行业问题通常分散在不同的领域，例如，影响测试过程的问题可能源于需求工程、知识管理或测试环境。对如此大的区域进行文献研究将是一项工作量巨大的任务。我们通过执行特定领域的文献综述解决了这个问题，我们只关注汽车和嵌入式领域的研究。另一种解决方案是利用现有的文献综述。但是，它们目前是针对特定主题而不是针对特定问题的，这严重限制了它们的现成使用。也许在未来，系统的文献综述应该针对特定问题，即帮助行业，而不是针对特定主题，即帮助研究人员和论文学生。

对于汽车测试过程，我们已经确定了汽车软件测试中软件测试的优势和挑战。我们通过研究三个不同部门的11个不同的开发团队，以单个公司的案例研究来做到这一点。我们发现，尽管汽车有其自身的一系列独特挑战，例如，与测试环境相关的问题，本专题连载中确定的大多数挑战仍然可以与上一节中讨论的其他领域报告的问题相关联。虽然，有人会认为汽车领域通常会遵循严格的软件开发方法，例如，使用正式指定的需求和高度计划驱动的软件开发过程，我们发现事实恰恰相反。此外，我们发现似乎问题最少的开发团队之一正在从敏捷软件开发方法中受益。然而，必须承认，与小型团队相比，大型团队往往受益于更好的管理。

在未来的工作中，需要将基于证据的测试过程应用于其他过程改进问题。此外，我们观察到需要根据实践状态（例如，关于团队规模）来描述汽车领域的特征。因此，需要表征该领域的调查。

关注牛喀网，学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

文末福利！

软件静态和动态代码测试工具免费试用申请，扫码添加牛小喀企业微信，回复"软件测试"

该专题连载关联资料免费下载，扫码添加牛小喀企业微信，回复“EBSE专题资料”

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！