摘要
1 介绍
2 相关工作
3 参照ISO26262标准的基于场景的设计和测试流程
- A 场景的概念阶段
- B 场景的开发阶段
- C 用于验证的场景和验证
- D 对场景的派生需求进行分析
4 设计过程中场景的术语和测试过程
- A 功能场景
- B 逻辑场景
- C 具体场景
5 结论与展望
6 致谢
REFERENCES

摘要

最新版本的ISO 26262标准由2016年代表了安全关键电动/电子车辆系统安全导向发展的最新水平。这些车辆系统包括ADAS和车辆引导系统。ISO 26262标准中提出的开发过程基于多个v模型，并为每个过程定义开发活动和工作产品。在许多这些过程的步骤中，基于场景的方法可以用于实现自动驾驶功能产品的开发。为了完成不同过程步骤的工作产品，场景必须关注各个方面，比如人类可理解的符号或通过状态变量进行的描述。这导致了关于场景表示的细节级别和表示方法的符号的相互矛盾的需求。在这篇论文中，作者讨论了在不同过程中根据ISO26262标准定义场景呈现的要求，为已确定的抽象级别提出一个基于先前出版物的一致术语，并演示如何沿着ISO 26262标准中概述的开发过程的各个阶段系统地研究场景。

要点：（1）定义场景需要结合ISO26262；（2）演示了根据ISO26262开发不同阶段的场景。

1 介绍

ADAS系统和达到SAE定义的L1和L2级别的系统已经在市场中上市。L3（有条件的自动驾驶）和L4（高度自动驾驶）系统也在跟进（奥迪的TJP和Waymo的自动驾驶车辆）。引入更高级自动驾驶水平的一个挑战是确保车辆以安全的方式运行。对于ADAS系统，这个证据可以由在测试场地和公共道路数千英里的驾驶数据提供。但是对于更高层级自动化验证，基于距离的验证不是一个经济可接受的方法。

作为一种对基于距离验证方法的替代，我们提出了基于场景的方法。关键思想是有目的地改变和验证自动车辆的操作场景。因此，开发过程中必须记录场景的系统化生成和进一步的假设，以确保生成可跟踪的场景。

ISO 26262标准是开发安全关键的电动/电子车辆系统的指南，从而为在功能安全方面开发车辆导航系统提供了一个框架。ISO 26262标准，可以使用场景来支持开发过程。例如，场景可以帮助派生需求，开发必要的硬件和软件组件，并在测试过程中证明这些组件的安全性。在创建测试用例时，在任何情况下都需要场景来为测试对象生成一致的输入数据。然而，这些场景的不同应用导致在ISO 26262标准的每个开发阶段对场景表示都有不同的需求。

这个贡献为基于v模型的开发过程的场景提出了三个抽象级别。通过这种方式，可以在概念阶段的高层次抽象上标识场景，并在开发过程中进行详细和具体化。这允许采用结构化方法，首先根据ISO 26262标准定义项目，然后进行危害分析和风险评估(HARA)，并为安全验证和验证提供必要的测试用例。因此，作者建议在Ulbrich等人定义的基础上对“场景”一词进行扩展定义，并介绍了功能场景、逻辑场景和具体场景的抽象级别。这篇论文的德语版本已在ADAS讨论会上发表。

这篇论文的组织结构如下：第二部分给出了基于所选择的在自动驾驶功能开发中与场景相关工作的一个动机，使用场景的抽象级别，以及术语场景的现有定义。第三节推导并分析了ISO 26262标准开发过程中对场景表示和使用的需求。然后，第四节为场景定义了三个抽象层，并展示了如何在开发过程中将这些场景表示相互转换。最后第五部分进行了简短的总结。

2 相关工作

Ulbrich等人[5]分析了跨多个学科的术语场景，并对自动化车辆领域提出了一致的定义。在这篇论文中，作者使用场景的术语定义也参照了Ulbrich等人的定义。

Go和Carroll[7]指出，场景在不同的规程中有不同的用途，但是用于描述场景的元素在所有情况下都是相似的。因此，场景可以用几个层次的细节和不同形式的符号来描述。场景可以用正式、半正式或非正式的符号表示。这种区别暗示了自动化车辆开发过程中场景的多层抽象。

Bergenhem等人[8]指出，车辆引导系统的完整需求，只有按照v模型进行一致的、可追溯的、可验证的需求工程过程，才能实现。一些出版物提出了一些方法，这些方法利用场景在自动化车辆的开发过程中生成工作产品。如ISO 26262标准所建议，Bagschik等人的[9]开发了一个程序，用于在危害分析和风险评估的过程步骤中生成潜在的危险场景。这个过程利用自然语言对交通参与者和风景进行抽象描述。分析了场景元素的所有可能组合，并结合L4级车辆引导系统有限用例中的功能故障描述进行了分析。

Schuldt等人提出了一个基于场景的测试过程，并通过一个4层模型展示了测试用例的生成。

Bach等人提出了一种基于模型的场景表示方法，该方法具有时空关系，是ISO 26262标准开发过程中的一种通用场景表示法。该场景表示方法是在高速公路上典型的ACC系统场景下实现的，并给出了实现结果。

上述出版物利用不同抽象层次的场景来开发车辆导航系统的功能和安全性。“场景”一词没有得到统一的定义，因此很难对场景在开发过程中的作用达成一致的理解。因此，作者将在接下来的部分中推导和分析场景的需求。

3 参照ISO26262标准的基于场景的设计和测试流程

2016年[13]发布的ISO 26262标准代表了在功能安全方面发展车辆导航系统的最新水平。图1概述了ISO 26262标准中提出的开发过程，可能利用场景生成所需工作产品的流程步骤用红色突出显示。

场景可以支持ISO 26262标准的整个开发过程，从概念阶段到技术产品开发，再到系统验证和验证。因此，必须对不同流程步骤产生的场景定义需求。这些需求允许在整个开发生命周期中使用场景的抽象级别的一致定义。以下各节引用ISO 26262标准定义的开发过程的工作产品，并对突出显示的过程步骤的场景提出需求。

A 场景的概念阶段

在技术开发之前，对正在开发的项目的概念进行了说明。在ISO 26262标准(第3部分)的概念阶段，定义项目，进行危害分析和风险评估，并制定功能安全概念。项目定义应包括功能概念、系统边界、操作环境、法律要求和对其他项目的依赖关系的描述。根据这些信息，可以推导出可能的操作场景。Reschka[14]提出识别安全驾驶状态，并根据操作场景指定名义行为。此流程步骤中的操作场景应以抽象的详细级别描述，并以人类可理解的方式表示(文本描述)。

ISO 26262标准定义的下一个使用场景的过程步骤是危害分析和风险评估。危害分析和风险评估包括两个步骤:态势分析和危害识别，以及危险事件的分类。在态势分析中，应描述故障行为将导致危险事件的所有运行状态和运行模式。因此，故障行为可以解释为偏离指定的名义行为。然后，将使用汽车安全完整性等级(ASIL)对危险场景(包括操作场景和故障行为的组合)进行评级。ASIL分类的参数是操作场景的暴露程度、可能的严重性和危险场景的可控性。为了确定这些参数，危险场景的描述必须包括静止的环境(风景)和所有可能与自动车辆交互的交通参与者。

根据现有技术的实际情况，由专家对危险场景进行分析。因此，危险场景必须用自然语言来描述。由于他们专业领域不同，人类专家在描述一个场景时使用术语的详细程度不同。因此，在危害分析和风险评估的过程中使用统一的词汇描述功能要点是必要的。此外，为了确保专家之间的共同理解，词汇表中的术语必须以半正式的方式表达。
在ISO 26262标准的概念阶段[C]，场景必须满足以下要求：
C1 人类专家应能以自然语言拟订该领域术语的方案
C2 场景应该以半正式的方式呈现。

B 场景的开发阶段

一旦对危险场景进行了分析，就形成了功能性安全概念。为了实现功能概念，必须在流程4-6中推导出技术安全要求。与功能需求相反，技术需求概述了可以进行物理量化的标准。例如，与其他交通参与者保持安全驾驶距离的功能需求可以用米为单位的距离从技术上表达出来，这是必须满足的。因此，每个危险场景都必须从概念阶段的语言和半形式化表示转换为系统级（4）技术产品开发的状态值表示。这些状态变量的列表是对场景的精确描述，但是，由于细节级别很高，人类专家无法直观地处理这些状态变量。为了减少场景的数量，可以将状态值总结为值范围。然后，状态值范围可以在有效/无效范围中进一步详细说明，以分别定义一组安全值和不安全值，或者对系统边界建模。场景的详细表示确保了对将要开发的项目的需求能够以可验证的方式进行表述。这是ISO 26262标准第4-9步安全验证的必要条件。

总之，在ISO 26262标准的系统开发阶段[S]，场景必须满足以下要求：
S1 场景应包括用于场景表示的状态值的参数范围
S2 场景应该为参数范围的表示提供正式的符号(例如数据格式)，以支持自动化处理

C 用于验证的场景和验证

在测试阶段，将检查实现的系统是否满足前面流程步骤中指定的需求。为了进行验证，必须系统地计划、指定、执行、评估和记录测试[13,part 8, section 9.2]。
每个测试用例规范必须包含以下独立于测试方法的信息[13,part 8, section 9.4.2]:
1）一个独特的识别
2）用于验证的工作产品的引用
3）前置条件和配置
4）环境条件
5）包含它们时间序列的输入数据
6）包括可接受变量的期望行为

测试用例生成的一个非常具有挑战性的方面是输入数据的规范。该数据必须包含每个参数的时间序列，这些参数本质上影响测试对象的行为。与此同时，由于系统高度连接，输入数据可能不包含任何不一致的地方，而是表示一个一致的场景。
项目定义中已经给出了有关正在验证系统的操作环境以及可能的操作场景的信息，该定义是在开发过程的概念阶段根据ISO 26262标准指定的。基于这些信息，可以为测试用例的规范导出一致的输入数据。项目定义中使用场景用语言表示，并在抽象的细节级别上进行表述。要在测试用例的范围内使用这些抽象场景，必须详细地指定这些场景并将其具体化。

场景的详细规范可以在技术安全要求规范的范围内执行[13,part 4, section 6]。技术安全要求描述了项目如何对可能影响安全目标符合性的外部刺激作出反应。通过这种方式，技术需求还定义了哪些参数范围必须确保正在开发的系统的功能。这个参数空间必须在验证过程中进行测试，因此必须考虑到测试用例的生成。此外，在详细指定场景的步骤中，必须将场景转换为正式形式表示。一个正式的表示是必要的，以确保稍后可重复的测试用例执行。场景必须通过不同的测试方法(如模拟或现场测试)定义测试用例执行所需的所有参数。因此，在详细指定场景的步骤中，必须将基于有组织术语的非正式描述转换为基于物理系统状态值的正式描述。

要生成包含在测试用例中的输入数据，必须在具体化步骤中从指定场景的连续参数范围中选择离散参数值。Schuldt[15]建议使用等价类、边值分析和组合方法来识别代表性样本。这种方法提供了测试用例的系统生成，但是缺乏确定有意义的测试覆盖率的方法。为了确定有意义的测试覆盖率，必须考虑测试概念、场景选择和必要的测试方法。场景在具体步骤中会系统化的进行派生，然后被正式描述，在测试中呈现出一致的数据输入。因此，派生的场景可以在测试用例的范围内用于对实现的系统进行验证。

总而言之，场景必须满足以下要求，以在测试阶段[T]中使用ISO 26262标准:
T1 场景应通过具体的状态值进行建模，以确保其重现性，并使测试方法能够执行场景
T2 场景不应该包含任何不一致性
T3 场景应以高效的机器可读方式表示，以确保自动测试执行

D 对场景的派生需求进行分析

表I说明了指定的需求与场景描述的形式是矛盾的。一方面，需求C1声明了对抽象的、语言的场景表示的需求，另一方面，需求S2和T3声明了对高效的、机器可读的场景表示的需求。由于语言表示很难被机器处理，而且人类无法读取有效的数据格式(主要是二进制编码)，因此需要不同形式的场景表示。

类似地，需求S1和T2需要场景表示的不同级别的细节。一方面，需求S1要求通过状态空间中的参数范围来表示场景。这种表示形式提供了关于确定要测试的具体值的多个自由度。另一方面，需求T2要求包含具体参数值的表示。这种形式的表示对于可重现的测试用例执行是必需的。因此，机器可读场景必须支持两个不同级别的细节。

4 设计过程中场景的术语和测试过程

如前一节所述，ISO 26262标准在开发过程中对场景表示类型的要求是相互矛盾的。在下一节中，作者将为场景提出三个抽象级别，并展示如何在开发过程中将这些抽象级别相互转换。图2说明场景的三个抽象层次:功能场景、逻辑场景和具体场景。

A 功能场景

功能场景描述了最抽象的场景表示级别。在ISO 26262标准的概念阶段，这些场景可用于项目定义、危害分析和风险评估。它们由语言表示，以确保人类专家能够轻松理解现有场景、讨论它们并创建新的场景。作者提出了以下定义:
功能场景包括语义级别上的操作场景。域的实体和这些实体之间的关系是通过语言场景符号描述的。场景是一致的。用来描述功能场景的词汇是明确适用于所使用的用例的，并可以表现不同水平的细节。

语义层次上的功能场景表示包括对实体和这些实体之间的关系/交互的语言和一致的描述。对于语言描述，必须定义一致的词汇。这个词汇表包括用于不同实体(车辆A、车辆B)的术语，以及用于这些实体之间关系的短语(车辆A超过车辆B)。

功能场景所需的详细级别取决于实际的开发阶段和正在开发的项目。在定义词汇表时必须考虑这两个方面。例如，高速公路试点需要一个词汇表来描述道路几何形状和拓扑结构、与其他交通参与者的交互以及天气条件。相反，一个停车场驾驶员需要一个词汇来描述建筑的布局，而天气条件可能无关紧要。如果使用一个全面的词汇表来描述实体和这些实体之间的关系，那么可以从词汇表中派生出大量的场景。对于生成一致的功能场景，词汇表中的所有术语都必须是不同的。定义领域实体的术语的来源，例如，实际的标准和指导方针，如道路交通规则或德国高速公路建设标准。

图3显示了一个双车道高速公路上的高速公路驾驶员的功能场景。一辆汽车和一辆卡车在道路的右边行驶，汽车跟着卡车。

在本例中，用布局和几何图形描述了道路。根据项目的用例和领域，词汇表必须包含额外的术语来描述这些特性，比如用于布局的“三车道高速公路”和用于几何的“直线”或“clothoid”。场景根据从预先定义的词汇表中选择其他术语可以发生变化。

B 逻辑场景

逻辑场景在状态空间变量的协助下可以更详细地描述功能场景。这些状态空间变量描述了这些实体以及这些实体之间的关系。逻辑场景可在系统开发阶段被用来派生其他场景和表示项目的需求。为此，逻辑场景通过正式的符号描述状态空间变量的值范围。作者对逻辑场景的定义如下:

逻辑场景包括状态空间级别上的操作场景。逻辑场景通过状态空间中的参数范围表示实体和这些实体之间的关系。参数范围可以选择用概率分布指定。此外，参数范围的关系可以在相关性或数值条件的帮助下选择性地指定。逻辑场景包括场景的正式符号。

逻辑场景描述覆盖了所有必要的元素，这些元素用来满足技术派生的需求以用于实施在系统中解决这些场景。对于ISO 26262标准开发过程中场景的逐步规范，逻辑场景必须通过状态空间中的正式符号来描述，其中参数必须通过值范围来定义。为了更详细地描述这些参数范围，可以选择为每个参数范围指定概率分布(如高斯分布、均匀分布)。此外，参数范围之间的关系可以选择用数值条件(如车辆的超车速度必须大于被超车速度)或相关函数(如车道宽度与曲线半径相关)来指定。

图4显示了从图3所示的功能场景派生出来的逻辑场景。通过将语言表示转换为状态空间和描述参数的场景规范，将功能场景转换为逻辑场景。因此，词汇表中的每个术语都必须分配给描述该术语的参数。在这个例子中，两条车道都用车道宽度来描述，曲线几何用半径来表示，车辆沿着车道的纵向位置来描述。此外，“跟随”一词要求卡车的纵向位置大于汽车的纵向位置。为了在本文中反映这个例子，作者选择了一个简化的参数集。实际上，需要更多的参数来描述词汇表中的单个词汇。例如，卡车还可以通过其尺寸、重量和发动机功率来指定。

此外，对于图4中示例中的每个参数，都指定了该参数在实际中出现的值范围和概率分布。这些信息有助于在系统开发阶段制定技术需求，并为在测试阶段系统地生成具体场景提供基础。

C 具体场景

具体的场景使用状态空间中的不同参数描述实体和这些实体之间的关系。通过从参数范围中选择具体的值，可以将每个逻辑场景转换为具体的场景。在测试阶段，可以使用具体的场景作为测试用例生成的基础。作者对具体场景提出了以下定义:
具体的场景清晰地描述了状态空间级别上的操作场景。具体场景通过状态空间中每个参数的具体值表示实体和这些实体之间的关系。

对于具有连续值范围的每个逻辑场景，可以派生出任意数量的具体场景。例如，通过为每个参数选择一个无穷小的采样步长，可以实现无限多个具体场景。通过对各参数具有代表性的离散值进行识别和组合，实现了高效的具体化。只有具体的场景可以直接转换为测试用例，并利用车辆引导系统执行。

图5显示了从图4所示的逻辑场景派生出来的具体场景。对于每个参数，都选择了定义值范围内的具体值，同时满足了有关参数的指定条件。

要将具体的场景转换为测试用例，具体的场景必须由测试对象的预期行为和将要使用的测试基础设施来扩充，Ulbrich等人的[5]就是这样说的。预期的行为可以从功能操作场景、逻辑场景或功能项定义派生。

5 结论与展望

本文根据ISO 26262标准的开发过程，分析了基于场景的车辆制导系统设计方法的实用性。为此目的，已经确定了可以使用场景生成相应流程步骤的工作产品的流程步骤。更进一步，关于场景表示的要求已经被定义，而且不同的过程步骤所产生的关于需求的矛盾已经显示出来。在此基础上，为了满足上面定义的所有需求，作者提出了场景的三个抽象层次。此外，还给出了每个引入的抽象级别的定义，并展示了如何使用场景的抽象级别为ISO 26262标准中定义的不同流程步骤生成工作产品。

未来根据ISO 26262标准进行的开发，需要新的方法和工具来生成功能场景，并将这些功能场景转换为具体的场景。除了这个工作，还有一份合作工作需要提交给2018IEEE智能车辆研讨会，合作工作是基于知识的方法用来创建包含大量变量的功能场景。因此，场景的现有数据格式可以集成到建议的抽象级别中。然后，可以针对自动化车辆的测试概念开发用于场景规范和场景具体化的新方法和工具

6 致谢

我们要感谢项目成员，项目由德国联邦经济事务和能源部的PEGASUS和aFAS资助，并与之进行了富有成效的讨论和反馈。我们的工作部分由大众汽车公司资助。此外，我们感谢Andreas Reschka对pap第一版的贡献

REFERENCES

[1] Society of Automotive Engineers (SAE), “J3016 - Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems,” Society of Automotive Engineers (SAE), 2016.
[2] “TechDay piloted driving – The traffic jam pilot in the new Audi A8,” 2017, accessed: 01–15–2018. [Online]. Available: https://www.audi-mediacenter.com/en/techday-piloted-driving-the-traffic-jam-pilot-in-the-new-audi-a8-9276
[3] “Waymo is first to put fully self-driving cars on US roads without a safety driver,” 2017, accessed: 01–15–2018. [Online]. Available: https://www.theverge.com/2017/11/7/16615290/waymo-self-driving-safety-driver-chandler-autonomous
[4] W. Wachenfeld and H. Winner, “The Release of Autonomous Vehicles,”in Autonomous Driving, M. Maurer, J. C. Gerdes, B. Lenz, and H. Winner, Eds. Berlin, Heidelberg, Germany: Springer Berlin Heidelberg,2016, pp. 425–449.
[5] S. Ulbrich, T. Menzel, A. Reschka, F. Schuldt, and M. Maurer, “Defining and Substantiating the Terms Scene, Situation, and Scenario for Automated Driving,” in 2015 IEEE 18th International Conference on Intelligent Transportation Systems (ITSC), Las Palmas, Spain, 2015, pp.982–988.
[6] G. Bagschik, T. Menzel, A. Reschka, and M. Maurer, “Szenarien für Entwicklung, Absicherung und Test von automatisierten Fahrfunktionen - English title: Scenarios for Development, Test and Validation of Automated Vehicles,” in 11. Workshop Fahrerassistenz und automatisiertes Fahren FAS 2017, Walting, Germany, 2017.
[7] K. Go and J. M. Carroll, “The Blind Men and the Elephant: Views of Scenario-based System Design,” Interactions, vol. 11, no. 6, pp. 44–53,2004.
[8] C. Bergenhem, R. Johansson, A. Söderberg, J. Nilsson, J. Tryggvesson, M. Törngren, and S. Ursing, “How to Reach Complete Safety Requirement Refinement for Autonomous Vehicles,” in CARS 2015-Critical Automotive applications: Robustness & Safety, Paris, France, 2015.
[9] G. Bagschik, A. Reschka, T. Stolte, and M. Maurer, “Identification of Potential Hazardous Events for an Unmanned Protective Vehicle,” in 2016 IEEE Intelligent Vehicles Symposium (IV), Gothenburg, Sweden, 2016, pp. 691–697.
[10] T. Stolte, A. Reschka, G. Bagschik, and M. Maurer, “Towards Automated Driving: Unmanned Protective Vehicle for Highway Hard Shoulder Road Works,” in 2015 IEEE 18th International Conference on Intelligent Transportation Systems (ITSC), Las Palmas, Spain, 2015,pp. 672–677.
[11] F. Schuldt, F. Saust, B. Lichte, M. Maurer, and S. Scholz, “Effiziente systematische Testgenerierung für Fahrerassistenzsysteme in virtuellen Umgebungen - English title: Efficient systematic test case generation for automated driving functions in virtual driving environments,” in AAET- Automatisierungssysteme, Assistenzsysteme und eingebettete Systemefür Transportmittel, Braunschweig, Germany, 2013, pp. 114 – 134.
[12] J. Bach, S. Otten, and E. Sax, “Model based scenario specification for development and test of automated driving functions,” in 2016 IEEE Intelligent Vehicles Symposium (IV), Gothenborg, Sweden, 2016, pp.1149–1155.
[13] ISO, 26262 – Road vehicles – Functional Safety, 2016.
[14] A. Reschka, “Fertigkeiten- und Fähigkeitengraphen als Grundlage für den sicheren Betrieb von automatisierten Fahrzeugen in städtischer Umgebung - English title: Skills and ability graphs as basis for safe operation of automated vehicles in urban environments,” Ph.D. dissertation, Technische Universität Braunschweig, 2017.
[15] F. Schuldt, “Ein Beitrag für den methodischen Test von automatisierten
Fahrfunktionen mit Hilfe von virtuellen Umgebungen - English title: Towards testing of automated driving functions in virtual driving environments,” Ph.D. dissertation, Technische Universität Braunschweig,2017.
[16] Richtlinie für die Anlage von Autobahnen - English title: Guidelines for Constructing Motorways, Forschungsgesellschaft für Straßen und Verkehrswesen Std., 2009.

自动化车辆的开发、测试和验证场景相关推荐

ASP.NET MVC4 微信公众平台开发测试一: 验证
ASP.NET MVC4 微信公众平台开发测试一: 验证背景,想做一个微信公众号的自动回复系统,于是想动手写一下.记录这些,是一边写程序一边写在这里,也是记录一下自己的思路. 微信公众平台开发时,需 ...
CIO访谈实录丨渤海人寿携手SmartX超融合大幅提升开发测试效率
客户访谈:金融/保险业新金融科技时代,数据的可靠性及平台计算性能是核心要义:新业务上线拓展的迅捷性,更是激烈竞争中重要的取胜之匙.在创新技术驱动业务发展理念的指引下,保险行业新兴寿险企业渤海人寿选择 ...
不宜使用Selenium自动化的10个测试场景
尽管在很多情况下测试自动化是有意义的,但一些测试场景是不应该使用自动化测试工具的,比如Selenium.WebDriver. 下面有10个示例,来解释为什么自动化在这种情况下使用时没有意义的,我还将为 ...
mysql集群方案对比_MySQL云原生方案在携程开发测试场景中的实践
一.背景与使用场景随着Kubernetes平台在容器云计算领域的一统天下,云原生 (Cloud Native) 一词也被提的越来越频繁.各类应用纷纷走上了容器化.云原生化的道路,无状态服务应用在Ku ...
GitHub免费支持CI/CD了，开发测试部署高度自动化，支持各种语言，网友：第三方凉凉...
郭一璞栗子发自凹非寺量子位出品 | 公众号 QbitAI GitHub激动地宣布,终于支持CI/CD了. CI\CD,全称:持续集成 (Continuous Integration) ,持续 ...
基于Jenkins的开发测试全流程持续集成实践
今年上半年一直在公司实践CI,本文将上半年来的一些实践总结一下,可能不太完善或优美,但的确初步解决了我目前所在项目组的一些痛点.当然这仅是一家之言也不够完整,后续下半年还会深入实践和引入Kuberne ...
百度王一男： DevOps 的前提是拆掉业务-开发-测试-运维中间的三面墙
这是一个创建于 375 天前的主题,其中的信息可能已经有所发展或是发生改变. 由数人云.优维科技.中生代社区联合发起的系列 Meetup < DevOps&SRE 超越传统运维之道&g ...
python行为驱动测试开发_行为驱动开发在 Python 开发测试中的应用
行为驱动开发 (BDD) 简介行为驱动开发是什么? 说到行为驱动开发(BDD),无可避免的要提到敏捷里面的测试驱动开发(TDD),TDD 的主要思想是"代码即文档",其倡导的流程 ...
世纪性难题：剪不断、理还乱的开发测试关系
如果说产品经理是开发人员最痛恨.最想群殴的人,那么测试人员无疑是开发最纠结.最想甩锅的人. 开发一方面需要测试人员把控产品质量,帮助他提升产品信心,另一方面又厌恶测试人员质量把控太严,导致他工作量增加 ...
对开发测试工程师的理解
开发测试工程师随着测试在软件开发周期中越来越受到重视,国内测试的缺口一直比较大,各种软件和互联网公司都大肆招收测试工程师,有些走在前面的公司甚至从今年开始取消了测试工程师职位,全部变成了测试开发职位 ...

自动化车辆的开发、测试和验证场景

目录

摘要