下面将介绍适应测试对象特殊性的一种功能性测试设计技术和一种结构性测试设计技术。

11.2.2.1 功能性测试设计：嵌入式系统的分类树方法CTM_EMB

嵌入式系统的分类树方法（CTM_EMB）（以前称作CTM/ES）^{[CDF＋99，Con04a，Con04b，CK06]}是分类树理论的一种延伸^[GG93]，该方法提供了一种功能测试设计技术——基于功能规定和测试对象的接口描述以及通过每个输入逐步定义的抽象时间序列对定时测试方案的全面图形描述。

基于测试对象的接口描述，测试对象的输入域被分成不同的区域——通常与各种输入匹配。不同的分区被称为“分类”，可以细分为（测试输入数据）等效类别。最后，选择输入数据分类中的不同组合，并编排成为“测试序列”。

为了说明问题，使用分析汽车踏板在车中位置的一个简化特征。这种功能可以被作为不同底盘控制系统的预处理部分。脚踏板解释（PedInt）组件通过使用实际车速（Vact）作为动力传动系统和制动的理想转矩（TdesDrive，T desBrake），以此指示当前归一化的加速踏板和制动踏板位置（详见参考文献[Hot97]）。此外，计算用来指示踏板是否被踩下的两个踏板（加速踏板和制动踏板）位置标志。

表11.1总结了对踏板解释（PedInt）组件相关的软件要求。出于以下考虑，应该测试这些决定两个标志计算的踏板解释（PedInt）的子功能，即编号为SR_- PI-01.x的所有要求。

表11.1 PedInt的软件要求规范（摘录）

作为第一步，应当决定与测试相关的接口。

假设一个测试对象有n个输入和m个输出。然后，测试对象的输入接口I用输入变量i_i（i＝1，…，n）来表示，输出接口O用o_j（j＝1，…，m）来表示。为了测试目标对象，有效测试接口的每个输入变量都必须用一个定时信号来触发，也就是一个数据时间序列来触发。输出变量必须记录下来。这样，测试接口IO决定了属于测试对象的“测试方案标志”。

图11.4表示的是一个PedInt组件的Simulink^[SL]模型，在下面的案例中把它作为测试对象；表11.2描述了它的测试接口IO。

这样，PedInt组件测试的符号表示如下：

表11.2 PedInt的接口说明

测试对象的输入域——可以被看做一个由许可范围内n个不同的输入信号组成的n维超立方体，它被不连贯地、完全分割成输入等效类——用于测试目的、适用的单个输入抽象。分区——就是通过分类树方法的图形表示，目的在于实现单个“等效类”的定义——就是对于潜在错误的检测，它们表现均匀。也就是对于一个类的所有值，检测对象表现得既正确也错误（“一致性假设”）。

启发式程序在实践中尽可能多接近这种理想的划分方面，已经证明非常成功。输入数据的类型和范围提供了第一条有价值的线索：其中用创立的最小值与最大值关注实值数据类型，例如，可以根据每一个类别的边界值、零值和中间点创建一个标准的划分。特定数据类的相似“标准分类”也可以被其他类型的数据所采用^{[CDS＋02，Con04a，Con04b]}。

一般情况下，特定数据类标准分类对于系统测试来说是不够详尽的。它们需要根据一致性假设进行细化或者人工修改以解决划分问题。在这方面，规定的质量和测试人员的经验是至关重要的。

根据标准划分，踏板的位置在0%至100%的取值范围内，可以划分为0、0～100和100。对于车速，分为5个区域：-10、-10～0、0、0～70和70。

图11.4 PedInt组件模型

由于vact车速对于测试PedInt的子功能（两种标志都要计算）来说，只起到次要的作用，所以标准分类这里未作修改。另一方面，踏板被压下只有当它高于一个确定的目标阈值pedmin，才会被激活，评估踏板位置识别踏板。因此踏板高于和低于阈值的位置应该分开考虑，这是因为行为预计有所不同。分类值也已经添加到精确的阈值中。为了保持分类树的灵活性，参数名称部分用作分类边界而不是固定值。踏板位置的最后结果分为以下的等级：0、0至ped_min、ped_min、ped_min至100、100。

通过分类树，把划分成类可视化（图11.5中部）。图11.5的下部显示了针对各个输入变量等效类别如何划分整个测试对象的输入域。

图11.5 从测试接口到分类树

实际测试方案是在测试输入分区的基础上设计的。测试方案以综合、抽象的方式描述了这些输入随时间变化的过程。因此分类树的树叶用来定义“组合表”中的列。为了抽象地表示测试方案，它们被分解为单独的测试步骤。根据它们的时间顺序组成了表的行（图11.6的上部和中部）。

每个测试步骤的测试输入通过组合分类树中的不同分类来定义。它是通过标记相应组合表中对应的主列中的元素来完成的。这就形成了测试输入场景的序列。每一个输入场景的历程可以由组合表中最右列的“时间标签”的注释来定义（图11.6中部）。

图11.6 定义测试序列

定时输入，即在连续性测试步骤中随着时间的推移改变输入的值，可以通过标记对应于该输入不同的分类等级来表示。因此在各自的测试步骤下的测试输入被限制在部分间隔或标记分类的单值中。测试步骤中被标记的输入类别的组合决定了各个时间点处测试对象的输入（图11.6中部）。

单个触发信号的中间值通过连续性测试步骤标记之间的过渡曲线来定义。不同的过渡类型代表不同的信号类型（如表11.3中的斜坡、阶跃、正弦）。通过这种方式，触发信号可以在参数化、逐步定义的函数的帮助下用抽象的方式来描述（图11.6中部和下部）。

表11.3 用线型表示的信号类型分配

进一步的测试序列可以在分类树下重复上述过程来描述。

对于第一个测试方案中的PedInt案例（图11.7中的测试方案#1），其目的是调查识别带特定值的踏板触发，它们中的每一个值都在一定的时间内保持恒定。

第二个测试方案（图11.7中测试方案#2）检查测试对象的滞后特性。为了做到这一点，踏板的位置是变化的——在整个值域内以斜坡的形式变化，且每个斜坡上下各一次。这时，实际类的选择对v_act是任意的。

对于不同、但是常数的踏板位置，第三个测试方案（图11.7中测试方案3）以2s的节奏线性倾斜穿过了整个非负速度区域。

在此输入数据分块的基础上的测试方案定义其实是一个组合的任务：选择输入数据类的不同组合，并按时间排序。(www.daowen.com)

在测试方案的设计已经完成之后，有必要检查它们是否有足够的测试覆盖率。在测试设计阶段，CTM_EMB早已允许在分类树和测试方案的基础上，确定不同抽象覆盖准则。

图11.7 PedInt测试方案的分类树

“需求覆盖分析”可以验证设计的测试方案是否足够覆盖测试对象所有规定的要求。在分析的过程中，有必要证明每一个要求是通过至少一个测试方案来检查，且现有的测试方案足够测试各方面的要求。

表11.4为通过测试方案得到的测试需求的覆盖情况。针对SR-PI-01.1至SR-PI-01.4的必要的需求覆盖已经实现。更高级别的要求SR-PI-01不需要单独测试，因为它已经隐含在所有的衍生需求中完成了测试。

表11.4 PedInt可追溯矩阵

此外，CTM_EMB支持“覆盖范围分析”。这种分析检查了充分考虑的在测试方案分类树下定义的所有等价类。这种检查可以根据各自的应用情况、通过使用不同的所谓的“分类树覆盖标准”（CTC）来完成^{[GG93，LBE＋04]}。

“最小标准”CTC_MIN如图11.8所示，它要求分类树下每一个单独的类在至少一个测试步中选择它。最小标准通常只要几个测试序列就可以完成。但是错误检测率非常低。

图11.8 最小标准CTC_MIN

“最大标准”CTC_MAX如图11.9所示，它要求每一个可能的类的组合在至少一个测试步中选择它。贯彻最大标准将会导致较高的错误检测率。然而，与这种标准有关的问题是一种可能的组合爆炸。当类的数量很多时，这是不可能实现的。

“n类组合标准”CTC_n代表一种妥协。这里，有必要确保每一种可能的n类组合在至少一个测试步中选择得到。例如一个二维的组合CTC₂（图11.10）是可执行的。

图11.9 最大标准

图11.10 二维组合标准CTC2

在测试设计过程中必须以具体问题的方式选择合适的标准。如果预先定义的标准没有充分满足要求，那么需要添加额外的测试方案直到达到所需的标准。

就数据覆盖范围而言，三种确定的测试方案满足最小标准CTC_MIN，如图11.7所示，但是它们不能满足更高的要求，例如CTC₂或连CTC_MAX也达不到。在实践中，这意味着需要添加更多的测试方案，直到达到分类树覆盖标准。

现在所取得的测试方案包含抽象的触发信息，但是只有类而没有使用具体的数据。因此在下一步中，它们需要采用具体数字进行实例化。

在组合表中定义的测试方案代表各个输入信号的“信号走廊”，必须在其中找到实际的输入时间序列历程。等价类的边界值限制了各个输入步骤中的输入范围。图11.6中下部显示了这个步骤。

在一致性假设的基础上，当确定基础点的值时，可以在标记的间隔内选择任何值。在本案例的范围内，采用平均值测试原理，即在每一种情况下，选择等价类的平均值作为测试数据（如图11.11所示，ped_min＝5%）。

图11.11 PedInt测试数据时间序列（测试方案#1）

到目前为止，所展示的就是如何系统性确定与紧凑描述在CTM_EMB的帮助下针对汽车控制软件黑箱测试方案。需求覆盖范围和输入数据覆盖范围（分类树覆盖）允许为确定的测试方案进行质量评估。

CTM_EMB可以部署为一个黑箱测试设计技术，独立于实际的开发过程。其首要任务是对测试对象行为和接口的说明。

11.2.2.2 结构性测试设计：决策覆盖测试

在结构性测试设计中，测试案例来源于测试对象的结构信息。在面向控制流测试设计中，那些案例来源于测试对象的控制流。在基于模型的开发背景中，可以同时利用模型的控制流和源代码作为它们的基础。

在面向控制流的结构测试中测试设计的目标是覆盖确定的若干项控制流程图像。如果测试对象是Simulink/Stateflow^[SL，SF]模型，那么可以借助模型覆盖标准“决策覆盖”（简称DC）来确定测试目标。DC检查模型中代表决策点的项目内容，例如开关模块和状态流。对于每一项内容，通过该项目的不同模拟路径都要被覆盖到^[BCS＋03]。

以图11.12为例，该图展示了为了实现全面覆盖通过开关模块的不同的路径，并列出了测试目标。

在和DC有关的PedInt模型中，唯一的模块是右上角的开关模块。如果phi_Acc大于或等于70，则通过上输入，否则通过下输入。为了实现全面决策覆盖DC，phi_Acc必须在某些时刻小于70，而在另外的时刻大于或等于70。测试方案#1满足这个条件；没有必要为了在模型级上实现决策覆盖而添加结构性测试方案。

图11.12 在模型级上的DC——通过开关模块和测试对象的路径

有关代码级的相关标准是“分支覆盖”（C1）。基于C1的测试设计的目的是至少执行源代码的每一个程序分支一次。这里，程序分支被粗略地定义为：从一个程序开始或从控制结构的一个分支，到下一个控制结构或程序结束的可能的路径^[BCS＋03]。

以图11.13为例，该图显示了摆脱If语句的不同分支，并列出了为实现全面的C1覆盖必须满足要求的测试对象。

图11.13 代码级上分支覆盖——控制流图像和测试对象