理论教育 基于模型开发过程中的测试成果

基于模型开发过程中的测试成果

时间:2023-08-26 理论教育 版权反馈
【摘要】:基于代码的开发等级也适用于基于模型的开发。此外,基于模型的开发方法也允许在较早的阶段采用大量测试技术。基于模型测试的有效的测试策略必须考虑基于模型开发的具体细节,并且合适地考虑可执行模型的存在,因此在两个方面超过一般的测试策略。接下来在模型测试背景中执行检测过的测试方案。

基于模型开发过程中的测试成果

11.3.2.1 基于模型测试的测试等级

在基于模型开发过程中的测试扩大了原始测试理论中的测试范围。与基于代码的开发过程相比,将模型作为测试对象的使用明显较早地开始执行测试。被测试的功能模型通常在不同的推进阶段显现出来。几乎在每一个基于模型的项目中,都可以发现有两种变化,它们是“行为的”或“设计模型”与“执行模型”。尽管设计模型侧重于描述预期行为,但执行模型也包括了所有的实现方面,它们是编码活动的先决条件。

由于早期存在的可执行控制器模型,对功能开发者来说,在模型阶段早已可以证明和用不同的技术测试是可能的。因此错误可以被早些检测出来,并且以较低的成本删除。可用技术的范围在互动特设模拟到模型系统检测之间变动。

基于代码的开发等级(见11.3.1.1节)也适用于基于模型的开发。就执行平台而言,软件组件测试和软件集成测试可以稍微灵活地执行,这是因为自动代码生成器通常支持主机和目标平台。基于实际的原因,集成通常发生在模型层次,以至于在软件层次通常只测试单个组件和/或整体的应用软件,而不是不同的集成步骤,如图11.18所示。基于模型测试的主要优点是能在研发早期、生成代码之前,在模型层次上的附加测试等级可以用来测试适用性并增加它的成熟性。

类似于在彼此基础上建立的软件测试等级,“模型组件测试”“模型集成测试”和“模型系统测试”都可以得到解决。对于模型层次测试,设计和执行模型都可以被利用。

如果测试中包括了设备模型,例如测试是以闭环的形式执行的,那么这被称为“模型在环测试”(MIL)。类似的术语适用于软件层次测试。主机平台上的闭环测试被称为“软件在环测试”(SIL),目标平台上的闭环测试被称为“处理器在环测试”(PIL)。

这里所描述的测试程序,用作测试待开发的控制器,因此它侧重于控制器模型。不考虑这一点的话,汽车环境模型的质量也明显需要得到保障。

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

图11.18 基于模型开发的测试等级(详细图)

11.3.2.2 基于模型测试的测试策略

基于模型测试的测试技术[Con01,BN03],按常规就是改编传统的软件测试技术或指定域的分析或测试技术。

但是应用采用模型作为测试基础的测试设计技术可能导致不同的测试方案,这是由于特殊类型的形式和结构以及不同的抽象层次。此外,基于模型的开发方法也允许在较早的阶段采用大量测试技术。

同样的,因为使用单独的测试技术通常不能满足完整的测试,所以互补的技术必须适当结合在一起。高效测试策略的目标是以提供不同测试程序的适当组合,确保高的错误检测概率。基于模型测试的有效的测试策略必须考虑基于模型开发的具体细节,并且合适地考虑可执行模型的存在,因此在两个方面超过一般的测试策略。它应该考虑的内容有:

•将可执行软件模型中的测试设计技术作为测试基础。

•测试对象的不同的表示(进展阶段)通常出现在基于模型开发的背景中。

在模型层次上的功能性和结构性测试设计技术组合在一起,随后再重新利用测试方案,被证明是成功的,如图11.19所示。(www.daowen.com)

这种测试策略的重点是测试方案的系统设计,它以功能规范、接口嵌入式软件的可执行模型为基础。此外,合适的结构测试标准定义在模型级别上,以这种方式确定的测试质量可以被评估。如果有必要,额外的测试方案需要被定义,直到被选择的结构性测试标准得以实现。因此,一旦在模型级别上充足的测试覆盖范围得到确保,那么功能性和机构性测试方案可以被背靠背测试重新利用,用于检测软件和嵌入式系统,以此证明可执行模型和再现形式模型(刨除一些内容)之间的功能等同性。

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

图11.19 基于模型测试的有效测试方案

步骤详细介绍如下:

1.模型级别上的系统功能测试:起初在开发过程的早期,面向功能的测试方案系统地源自功能规范、接口和可执行模型(见11.2.1.1节和11.2.2.1节)。

测试方案的确定一直要继续下去,直到取得了充足的要求和取值覆盖范围。接下来在模型测试背景中执行检测过的测试方案。对测试方案的模型反应必须被记录下来。

2.监测模型覆盖率:在模型级别上测试结构覆盖率是很有用的,因为在实际软件存在之前可以决定覆盖率。这样,可以提供关于测试对象的结构覆盖率的早期说明。

用在步骤1(如果适用的话,也包括步骤3)中识别的测试方案获得的覆盖率必须测量。一旦足够的结构性模型覆盖率被实现的话,我们可以进行到步骤4。否则,我们需要重复进行步骤3。

3.在模型级别上的结构性测试:如果足够的模型覆盖率还没有取得,那么必须识别还没有覆盖到的模型单元,必须为这些模型部分创建特定的测试方案,还需要添加到现有的测试套件中(见11.2.1.1节和11.2.2.1节)。随后重新执行步骤2。此过程需要进行下去,直到达到足够的覆盖率。

在模型测试中,使用识别的测试方案来测试设计和/或执行模型。来自仿真模型在这些测试方案下的系统反应将必须记录下来。

4.使用软件与嵌入式系统执行背靠背测试:如果在下一步的开发中,软件和嵌入式系统是可以利用的,那么针对软件和嵌入式系统(在步骤1和步骤3中出现的)测试方案将被重复执行。系统的反应再次被记录下来,并与模型的反应进行比较(见11.2.3.1节)。在系统反应有足够的相似性(功能等价)的情况下,我们可以假设在C代码下模型的转变和它嵌入到控制单元中没有出差错。

根据步骤1到步骤4得到的基于模型测试的有效测试方案的示意图如图11.19所示。在步骤1和步骤3中,选择测试设计技术;在步骤2中,结构性测试标准;在步骤4中,比较程序。如果有必要,都可以适用于特定的项目。

基于功能和机构的测试方案系统性设计,使得大量与软件相关的错误可能暴露出来。在由不同覆盖率标准(例如以需求为导向、以数据范围为导向和以模型结构为导向)组合的有效测试策略背景中,可以保证足够的测试覆盖率。

在模型级别上把功能性与结构性相结合的测试设计技术,由基于模型测试的有效测试策略来定义,并随后多次重复利用为软件测试和嵌入式系统检测的测试策略,这样很明显产生了一个基于模型方法的主要优点:可以系统地测试嵌入式应用系统软件的前兆阶段。因此,测试活动可以被转移到早期的开发阶段,并且减少由模型测试发现的那些错误的纠正成本。

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

我要反馈