单元测试规范要求是什么（单元测试规范要求是什么意思）

如今，汽车领域的许多创新都是通过软件和电子系统实现的。可靠的测试流程是开发流程中不可或缺的一部分，用于验证所实施的软件是否按预期运行。ISO 26262或 ASPICE等标准要求一致的测试文档。测试文档的一个重要部分是测试用例规范，它由软件测试标准ISO 29119定义。测试用例规范包含一组从特定测试对象的测试基础派生出来的测试用例。应随时避免测试用例规范的失效和误解。虽然可以使用突变测试等技术来评估自动化测试的质量，但用于评估非正式测试用例规范质量的自动化方法很少或仅限于特定领域的测试语言，即测试和测试控制符号(TTCN-3)。为了确定汽车测试用例规范的潜在改进领域，本文旨在研究如何使用给定的测试用例规范模板来评估质量。

分析基于从测试用例规范中提取的数据，这些数据适合作为测试用例规范质量评估的指标。分析提供了对汽车测试用例规范的洞察，并确定这些测试用例规范中是否有足够的形式化来实现质量的自动评估。

作为数据源，从汽车OEM收集了总共16个不同项目的816个测试用例规范。所包含的测试用例规范要么是内部创建的，要么是由供应商创建的。

在第2节中，我们概述了测试用例规范，并提供了一个示例。第4节包含分析得出的潜在质量指标的描述，包括选定测试用例规范的定量数据。此后，我们在第5节总结并提出了对未来工作的一些展望。

测试用例规范是汽车环境中测试文档的核心部分。它们用于记录要执行的测试用例。测试用例规范包含一组测试用例，这些测试用例对于根据定义的测试目标充分测试特定测试对象是必不可少的。测试用例的基本特征是具有唯一标识符、先决条件和后置条件、输入、预期结果、测试执行的优先级和可追溯性信息（例如对相关需求的引用）。除了这些测试用例基本属性外，还经常指定其他领域或公司特定的测试用例属性，例如状态、测试目标、作者、模型系列或测试平台。这些属性称为测试用例元数据。

测试用例元数据和基本属性与测试用例相关，可以在测试用例规范模板中定义。图1显示了汽车测试用例的示例和测试用例规范模板的应用。雨刮器和清洗系统的测试用例由其基本属性和汽车特定的测试用例元数据（例如车辆系列、测试平台）描述。测试用例属性由列表示，行用于定义不同的对象类型，例如文本、标题、测试用例或测试步骤。并非所有属性都与每种对象类型相关，因此某些单元格应为空（图1中的深灰色单元格）。不同的对象类型彼此之间具有层次关系。例如，必须将测试步骤分配给测试用例。

（a）测试用例基本属性

（b）测试用例元数据属性（虚线边框）

图1.使用测试用例规范模板的汽车测试用例定义示例

我们从汽车OEM的IBM Rational DOORS数据库中收集了数据，并确定了总共2435个测试用例规范。此后，过时的测试用例规范已被排除，将测试用例规范的数量减少到972个。过时的测试用例规范是指那些不基于当前测试用例规范模板或其最后修改日期在2015年之前的规范。此外，未包括重复项、备份或按名称标记为过时的测试用例规范，导致测试用例规范进一步减少到816个，共16个不同的项目。项目与车辆领域有关，例如动力传动系统、底盘或舒适系统。

基于测试用例规范模板确定的测试用例规范如图1所示。测试用例源自自然语言需求，因此相关的测试用例属性也是使用自然语言指定的。

我们根据可以通过编程确定的信息对收集的数据进行了定量分析。因此，我们使用DOORS可扩展语言(DXL)从已识别的测试用例规范中提取定量数据。

基于代表性项目详细介绍了分析结果。所选项目包括来自动力传动系统领域的总共12个测试用例规范，这些规范代表了汽车测试用例规范。图2-5显示了该项目的分析结果。接下来，将根据所检查的各种标准讨论已识别的质量指标。

A. 标准1：测试用例规范相对于需求规范的大小

测试用例规范中的平均测试用例数为511（参见图2中的测试用例数）。但是，非常大的测试用例规范包含超过2200个，小的测试用例规范只能包含31个测试用例（参见图2）。但是，测试用例规范的大小意义不大，并且不会对测试用例的正确性做出任何陈述。因此，必须将它们与相应需求规范中指定的可测试需求相关联考虑。例如，具有856个测试用例的测试用例规范（参见图2，TCS 12）可归类为大型。与测试用例规范12相关联的需求规范包含2462个可测试需求。建议至少用一个测试用例测试一个需求。因此，显然应该有更多的测试用例来验证2462个相关需求。但是，测试用例规范的大小与可测试需求数量之间的关系只能作为测试用例规范完整性的指标。可以通过系统先前的测试用例规范确定测试用例规范适当大小的参考值。

B. 标准2：所含对象类型的分布

测试用例规范包含大量测试用例和测试步骤，如图2中的绿色条所示。基本场景类型的对象表示可由多个测试用例引用的可重用先决条件。分析表明，测试用例规范中通常只有极少量的基本场景，或者根本不使用基本场景。相反，先决条件通常会从一个测试用例复制到另一个测试用例，而不是在基本场景中存储和引用可重用的结构。这在大型测试用例规范中尤其明显。通过使用基本场景，可以减少重复，并增加已建立结构的重用。减少重复还可以最大限度地减少对重用部分进行更改所需的时间和精力，因为更改可以集中进行。测试用例规范还包含未定义的对象，这些对象未分配任何对象类型（例如TCS 11，图2）。少数测试用例规范包含单独的对象类型，并且模板未预定义。这违反了模板，可能会影响导出到下游工具。

C. 标准3：测试用例的大小

测试用例的平均大小（以要执行的测试步骤数量来衡量）为3.83个测试步骤。但是，在代表性项目中也可以识别出最多包含76个测试步骤的测试用例（参见TCS 8，图3）。大型测试用例在后期的测试执行中更容易出错，并使调试更加困难。例如，手动执行76个测试步骤以重现失败的步骤非常耗时。此外，过多的测试步骤可能表明多个测试用例已合并为一个大型测试步骤。因此，将它们分成几个测试用例是有意义的。

D. 标准4：测试用例规范的类型

测试用例通常具有构建测试用例流程的测试步骤。这样做的好处是可以避免非常庞大、广泛和连贯的测试过程描述。它还支持将记录的预期结果分配给明确定义的一组输入和操作。对于非常小的测试用例，用于分析的测试用例规范的模板允许在不使用测试步骤的情况下定义操作和预期结果。分析表明，当完全省略测试步骤时，测试用例规范就会存在（参见TCS 3，图3）。在这种情况下，通常可以观察到输入和预期结果超载。多对输入和预期结果组合在一个测试步骤中。这意味着不再可能明确地将输入与预期结果关联起来。当测试用例规范同时使用两种方法时，情况也是如此。在大多数情况下，在测试用例规范中会发现两种方法的混合（例如图3中的12个）。这种形式更容易出错，并且难以理解。

E. 标准5：链接对象类型的类型

对链接对象类型的分析揭示了测试用例和工件之间的链接。图5中的表格显示了允许链接的链接方案。一般来说，这些是外部链接（例如，工件是需要验证其正确实施的需求，参见图4中的TCS 8）或内部链接，即由测试用例引用的基本场景等工件，参见图4中的TCS 11）。在某些情况下，没有链接任何需求（参见图4中的TCS 5、6和7）。在这种情况下，需求覆盖范围不足。链接分析还可以用作质量指标，以检测记录需求中的错误，即，如果未为需求设置对象类型（未定义的链接，例如图4中的TCS 6、7和11）或需求规范不是基于标准模板（未知链接，例如图4中的TCS 5）。在考虑的测试用例规范和链接的需求规范的情况下，必须为需求设置对象类型需求。此外，可以检测到不符合模板和不正确的链接（参见图4中的黑条）。这包括在基于需求的测试方法中不能被视为可测试的标题、信息或流程需求的链接。

F. 标准6：链接对象类型的数量

一个测试用例平均链接到1.68个需求。这也符合每个需求应由至少一个测试用例检查的前提。但是，当一个测试用例链接了121个需求时，也存在巨大的偏差。如此多的链接需求可以看作是检查此类测试用例的指标，要么是因为它太大，可以分成几个测试用例，要么是因为单个测试用例似乎不太可能涵盖这么多需求。根据我们的经验，超过20个链接需求可以被视为关键。

G. 标准7：模板一致性

分析发现了几项违反模板指南的行为。这些对测试用例规范的进一步处理有显著的负面影响（例如，自动验证机制不适用或导出到下游工具失败）。例如，自定义章节结构（添加或重命名章节）意味着测试用例未包含在导出中或导出失败。此外，如果某些强制属性没有填写（例如输入、预期结果、测试平台、模型系列），它可以作为测试用例规范质量的指标。

我们的调查显示，测试用例规范没有完全按照所用测试用例规范模板的指南进行记录。因此，需要进一步调查根本原因。测试用例规范的自动化质量评估需要充分的形式化。由于测试用例规范的属性集高度个性化，基于模板的结构评估似乎并不适用于所有测试用例规范。由于测试用例通常是以散文形式编写的，因此很难以编程方式评估测试用例的内容并将其与需求和测试概念的内容进行比较。为了进行自动化质量评估，必须将测试用例形式化，并必须满足模板指南。此外，应该注意的是，测试概念和底层需求的内容在测试用例规范的质量评估中起着重要作用。由于这些信息不是以相同的数据格式提供的（例如需求、DOORS中的测试用例和Word中的测试概念），因此无法自动评估是否符合指南。分析表明，存在一些标准，可以用作对测试用例规范结构的检查进行初步质量评估的质量指标。这尤其包括相对于需求规范的测试用例大小、链接需求的数量、对给定链接方案的遵守情况或测试概念中定义的测试目标和测试平台的实施。这些标准可用于获得对测试用例规范质量的初步印象。这可能是在给定时间进行更详细检查是否合理的条件。

我们未来的工作将集中在测试用例描述的定性分析上，这些描述大多基于自然语言。需要机制来支持和加速对测试用例规范的审查。

摘要：20世纪90年代，电子元件在大众产品中的日益集成促使设计办公室引入系统工程方法。在汽车行业，由于减少污染排放和出于安全考虑的需要，这种部署得到了加速。ISO 26262等安全标准的引入以及联网和自动驾驶汽车的设计需要开发新的系统建模方法，特别是基于模型的安全分析方法(MBSA)。在本文中，我们将解释如何结合逻辑架构的定义来确定功能安全概念。这将基于失效传播机制。该方法应用于汽车案例研究。

原文作者：Pierre Mauborgne，Samuel Deniaud，Éric Levrat，Éric Bonjour，Jean-Pierre Micaëlli，Dominique Loise

猿力部落编译：猿东东，猿西西

本文提出了一种定义功能安全概念的方法，该方法与系统逻辑架构的定义相结合。它依赖于一个共同实现功能和功能障碍活动的过程。在应用于意外喷射燃料后，讨论了该方法的独创性和局限性。支持此流程的验证工具正在原型化。他们应该识别关键路径，并验证引入的安全功能是否能够删除关键路径并满足安全目标。