理论教育 系统测试活动及典型技术

系统测试活动及典型技术

时间:2023-08-26 理论教育 版权反馈
【摘要】:将测试分解为单个“测试活动”,形成了系统测试的基础,并提升构造的步骤。然后介绍这三种测试活动的典型测试技术。这里的测试活动和测试技术暂时独立于具体的测试等级。

系统测试活动及典型技术

术语“测试”,不仅描述测试活动本身,而且也描述测试设计和评估。将测试分解为单个“测试活动”,形成了系统测试的基础,并提升构造的步骤。这样带来了更好的文档和可追溯性[Weg01]。在文献中给出的测试活动细分是变化的(见参考文献[Gri95、BN03]),但经常可以区分“中心活动”和“支撑活动”。为了以方法论的方式进行不同的测试活动,大量的“测试技术”已经开发出来。

本节从介绍测试活动测试方案设计、测试运行和测试评估开始。然后介绍这三种测试活动的典型测试技术。这里的测试活动和测试技术暂时独立于具体的测试等级。

11.2.1.1 测试方案设计

在测试活动之中,合理的(就是对误差敏感)测试方案设计对于一个值得信赖的汽车控制软件测试来说,是一项最重要的活动。

“测试方案”(图11.2)是一种包含测试输入和期望输出的有限结构:在确定性转化系统中的一对输入与输出;在确定性反应系统中的一系列输入与输出;在不确定反应系统中的一棵树或一张图。“测试套件”是一组有限的测试方案[UPL06]。如果测试方案包含时间的变化,那么它们被称为“计时测试方案”;如果测试方案不包含时间的概念,它们被定义为“非计时测试方案”。

978-7-111-52251-5-Part04-2.jpg

图11.2 一个测试方案的元素

因为穷举测试即使对于小型系统来说实际上几乎都不可能(由于组合的原因),因此有必要从可能的测试方案中选择尽可能小的子集,确保测试对象能够进行尽可能全面的测试[Mye79]。这一选择过程造成了动态测试的抽样性[Lig92]。选择合适的样本(即测试方案)决定了测试的范围和质量。

由于测试方案设计的突出意义,因而在过去开发了许多技术,它们为测试者在选择合适的测试方案提供了支持[Weg01]。应用这些测试设计技术系统化了测试方案的选择,并使它们具有可追溯性和重复性[Sim97]

在下文中,“测试设计技术”代表了基于确定信息源——被称作“测试基础”选择和/或设计测试方案的一个标准化的、但不一定是必需的正规技术。因此,测试设计技术包括了一个合理的符号,它用于描述所选择的测试方案。在其他方面,可能的测试基础包括需求规范、设计模型或者根据模型创建的程序代码。

用于测试方案选择的众多可以想象的标准也同样适用于大量现有的测试设计技术。对于测试设计技术的分类可以采用不同的标准[Mye79,Lig92,Gri95,Bal98,Bel98,Con01]。然而,通常测试设计技术的划分是根据测试方案选择中是否考虑测试对象的结构来进行的。此外,如果测试基础存在一个分类,那么可以进行更细致的划分。

如果测试对象的内部结构与测试方案的选择没有关系,则该技术称为“功能性的”或“黑箱测试设计技术”;否则称作“结构性的”或“白箱测试设计技术”。测试步骤中如果需要内部结构的部分知识,则该技术称为“灰箱测试技术”。

功能技术的目标就是尽可能全面地测试对象的特定功能。结构性技术的目标就是尽可能多地覆盖待测试对象的确定结构元素。待覆盖的结构元素可以根据测试对象的控制流(控制流相关的测试设计)或数据流(数据流相关的测试设计)来定义。

然而,功能技术与结构技术的差别——特别在黑箱技术中——不提供任何有关测试方案源出于哪里的信息。唯一的要求是黑箱测试中的测试方案的来源不是源自程序结构。测试基础为测试设计技术提供了进一步的分类标准。

如果测试方案源自通常的文本或者功能规定(根据测试对象,只有接口可以考虑),则被称为“面向规定的测试设计”。如果把测试对象的模型作为基础,则被称为“面向模型的测试设计”。最后,如果以源代码作为测试的基础,则被称为“面向代码的测试设计”。

对不同的测试设计技术的描述可以在其他人的文献查到[Mye79,Lig93,Bal98,BN03]。由于汽车嵌入式系统的特征,针对控制软件开发的实用测试技术不同于为行政管理或科学技术软件开发的技术。因此,实际的测试设计技术应该根据这些细节进行调整,并需要解决时间和序列问题。特别的,他们必须允许描述定时测试方案。现有的其他领域的测试方法在这方面只有有限的用途。

因为单一的测试设计技术对于全面的汽车控制软件的测试来说是不够的,所以互相补充的测试技术必须适当地组合起来。因此,为了确定测试方案,通常要查询不同来源的信息(文本规范、设计模型,有必要的话还需要早期模型或单独的测试模型),并且把功能技术和结构技术结合起来。不同的测试设计技术的组合被称为“测试方法”。通常,它们不仅包括测试设计技术,而且包括用于其他测试活动的技术,例如测试评估。

11.2.1.2 测试运行

在“测试运行”范围内,测试对象受到测试输入(在测试方案中建立的)激励。记录系统对此的反应。

由于汽车软件的工业研发并不是在特定的基础上发生的,而是发生在不同的阶段,不仅仅是最后的产品,因此将在伴随研发的测试流程中测试,而且是其不同的初级阶段(模型演化阶段)。在基于模型的开发流程背景中,出现了如起初的汽车控制软件模型(可能是变化的抽象表示形式:设计模型、实施模型)。它然后被翻译成程序代码(可能分为几个阶段:浮点/固定点代码),然后被加载到相应的目标硬件[可能也分为几个阶段:原型硬件、产品电子控制单元(ECU)]上。每一个开发的工件(表达形式)都可以进行测试。软件的可执行模型测试被称为“模型测试”或“模型等级测试”。由此产生的在研发计算机的软件测试被称为“软件测试”(严格意义的)或“软件等级测试”。而软件在目标系统上的测试被称为“嵌入式系统测试”或“系统等级测试”。在传统的、基于代码的开发过程中,模型测试并不适用。(www.daowen.com)

如果正在测试的测试对象多于一个表达形式,那么早期的测试结果可以作为“测试基准”,也就是另一种表现形式的测试的期望输出。这样的“对比测试”被称为“背对背测试”。对比测试的另一种变体是“回归测试”,即两种不同的形式分别和测试对象原来的表现形式进行对比。

对于测试运行,我们通常需要一个“测试环境”,确保有测试输入的测试对象的馈入和系统反应的记录得以进行。后者需要持续保存,至少要等到测试评估。根据测试对象的类型和使用的运行环境,可以为测试环境采取不同的形式:在基于代码软件测试的情况下采取“存根”和“驱动因素”,在基于模型级测试情况下采用“测试线束”。

根据测试执行中是否包括设备或设备模型,有人提出了“闭环测试”或“开环测试”。在一个闭环测试执行中,设备或设备模型的相关部分必须集成到测试环境中。在闭环控制组件中,因此可以反馈,如实际值。

为了测量在测试运行中的结构测试的有效范围,“用仪器装备测试对象”(模型或源代码)是有必要的。

支持测试执行的测试技术被称为“测试执行技术”。

978-7-111-52251-5-Part04-3.jpg

图11.3 测试运行与评估

11.2.1.3 测试评估

在测试评估范围中,通过考虑定义的“合格标准”将系统反应与预期行为进行比较。然后把比较的结果与测试执行信息结合起来,浓缩成为一个“测试判定”,如图11.3所示。

如果存在一个通过模型表示测试对象行为的“测试基准”,那么也就可以在基准模型的帮助下,评估真实系统的反应。在这种情况下,在测试设计中在没有明确先验确定期望输出的情况下,也可以进行测试评估。

系统反应和预期行为之间的比较可以不同的方式进行:最容易的测试评估形式是“人工视觉评估”(通过“仔细观察”做出评价)。对于这一点,记录的系统反应以合适的方式处理(例如系统反应曲线),然后提交给测试者进行视觉检查。人工视觉评估的一种特殊情况是利用现实中的照片或示意图的“动画系统反应”[CH98,RCK+00]。对于这点,测试对象的变量或状态就与车辆动画的图形和数字元素或者可视化面板耦合在一起。通过这种方式,可以描绘出图形,例如速度、旋转角度等车辆变量。此外,矢量变量可以通过渐进淡出相应的矢量箭头来实现可视化。

每当我们直接测试汽车或者如果需要非视觉人类感官知觉来定性地评价系统反应时,我们总使用“人工的非视觉评估”。特别是在舒适性评价中采用这种测试,例如对自适应巡航控制系统的加速行为的评估。在口语中,人工非视觉评估也被称为“乘坐舒适性测试”。

当没有自动生成可用的预期输出或参考输出,或者所分析的系统反应过于复杂难以自动做出系统评估时,就需要用到人工评估。人工评估的缺点是出错率高,而且需要花费大量的时间,尤其对大型测试套件。

如果通过布尔计算值可以判断系统反应的正确性,或者如果使用集成到运行测试环境中的“看门狗”检查,那么测试评估可以简化成计算逻辑预测值——使用看门狗的输出信号。这就意味着系统可以通过评估看门狗来实现自动测试评估。对于这点,可以监测例如控制器的特征或动态信号边界。举例可以在参考文献中找到[CH98,Rau02]

虽然不定时测试方案中系统反应与预期行为的比较是相对简单的,但是在定时测试方案中,我们必须把以输出时间序列形式表示的系统反应和期望行为或和以参考时间序列形式表示的参考值进行对比。接着测试评估问题可以简化为系统反应信号(时间序列)与参考信号对应数据或预期输出数据之间的鲁棒信号比较。

此外,在测试评估环境中,有必要决定测试对象的行为是否认为正确或被拒绝是不正确的。在这里,评估的结果被分为三类:“通过”“失败”或“不确定”(交通灯评估)。结合测试执行的状态(分为“错误”和“未定”),测试结论就诞生了。根据测试执行和测试评估,既可以人工也可以自动执行结论信息。在实践中,经常存在自动化预评估与人工审核相结合的形式,其目的在于将测试的责任权归于测试者。

此外,在测试评估中,核查建立的测试对象和测试标准在测试中是否达到所需的要求程度是很有必要的。在功能性测试中,可以确定和分析比如达到的“要求覆盖率”或“数据范围覆盖率”;或在结构测试中,可以确定和分析达到的“结构模型或代码覆盖率”。如果达到的覆盖度不足,那么有必要分析原因,且要进一步补充测试方案。

支撑测试评估的测试技术被称为“测试评估技术”,将在下面介绍。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈