陕西企业网站建设哪家好,如何做阿里巴巴网站,wordpress 删除 版权,手机网站 微信链接怎么做EBSE专题连载共分为“五个”篇章。此文为该连载系列的“第四”篇章#xff0c;在之前的“篇章#xff08;三#xff09;”中已经结合具体研究实践阐述了“步骤二#xff0c;通过系统调研确定改进方案”等内容。那么#xff0c;在本篇章#xff08;四#xff09;中#…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过程”。