嵌入式控制系统特征交互感知测试用例生成

理论计算机科学电子笔记264（2010）37-52www.elsevier.com/locate/entcs嵌入式控制系统特征交互感知测试用例生成Malte Lochau，Ursula Goltz乌尔苏拉·戈尔茨1，2，3程序设计和反应系统研究所德国摘要在嵌入式控制系统中，例如在自动驾驶领域中，功能的数量和耦合的增加导致了相互作用的特征的复杂网络和广泛的变体。因此，今天的软件开发过程必须包括系统的方法来分析系统规范和实现的功能正确性。基于模型的测试对于嵌入式软件系统特别重要，因为测试用例可以在被测的真实系统上执行，并且可以发现由软件和硬件的交互引起的故障。 由于特征通常被设计为在模块化和隔离的方式中，由系统中同时活动的不同步的甚至矛盾的特征的非预期干扰引起的意外和不期望的行为通常未被检测到，这可能导致严重的安全问题。在系统集成级克服这种功能交互是乏味的，因为它会导致大量难以管理的测试用例。 我们描述一种基于模型的方法，用于有效地生成测试用例，特别是针对功能交互分析。 我们首先基于严格的功能架构模型以形式化的方式描述特征交互，并描述如何检测潜在的特征交互。对于测试用例生成，可以像往常一样使用行为模型，如Statecharts和相应的覆盖标准，但只有那些模型被集成到测试模型中，这些模型有助于考虑的功能之一。 这导致了在全面的测试覆盖率之间进行权衡，以发现由交互功能引起的可能的错误，但仍然有合理数量的测试用例。 该方法的步骤被说明是从汽车领域的案例研究的手段。关键词：基于模型的规范和测试，测试序列生成方法，特征交互，嵌入式控制系统，汽车领域。1介绍1.1动机用于控制和监测机械和电气过程的嵌入式软件系统变得越来越普遍。在汽车领域，软件已经是电子控制单元网络的关键部分[4]。的1感谢[13]的所有作者为本文中使用的案例研究做出贡献2电子邮件：lochau@ips.cs.tu-bs.de3电子邮件：goltz@ips.cs.tu-bs.de1571-0661 © 2010 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2010.12.01338M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37通过将软件功能与对诸如传感器和致动器之类的硬件设备的共享访问进行协作来实现一组特征，即驾驶员可识别的复杂功能。各种相互作用的组件将被集成，构建具有高内部复杂性和与环境的密集交互的反应系统。通常，在汽车领域，特征集是固定的，并且在设计系统时，运行时使用的数据元素和信号是已知的。因此，功能架构和组件内部行为的严格建模方法特别是在安全关键系统的背景下，形式化分析方法对于确保系统规范和实现的功能正确性至关重要。除了模型检查等验证技术之外，基于模型的测试对于嵌入式控制系统验证也是必不可少的，因为测试用例可以应用于实际的被测系统，同时考虑到软件系统与目标平台硬件交互时的影响。在本文中，我们描述了一种基于模型的方法，用于嵌入式控制系统的测试用例生成，明确考虑到功能的相互作用。该方法的目的是在测试用例生成系统的检测和分析潜在的不良行为所造成的干扰的与考虑系统中所有功能的完全集成所需的测试套件相比，所需测试用例的数量可以显着减少。 基于我们采用类似状态图的行为模型，即 用于测试用例生成的状态流行动。该方法是通过汽车领域的案例研究来说明的。1.2基于模型的开发和测试用例生成模型驱动的软件工程对于应对当今软件项目的复杂程度变得越来越重要像UML（统一建模语言）中捆绑的建模语言用于表示正在开发的系统的结构和行为的相关属性。考虑到嵌入式软件系统的开发步骤，应用具有不同抽象级别的建模方法，提供系统上基本工件的视图在汽车领域，基于模型的、工具支持的控制系统开发实践非常流行，并被纳入了AUTOSAR等标准[1]。此外，基于模型的形式化分析方法可用于通过形式化验证（例如模型检查）或基于模型的测试来确保测试方法通常不能确保没有故障，即证明功能正确性。系统测试的应用旨在通过调查系统输出是否与测试用例（即特定用途）M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）3739案子测试的主要好处是，从行为模型自动生成的测试用例可以通过可执行和可重复的场景应用于被测的真实系统。基于模型的测试追求测试设计的自动化，即：从被测系统的模型中选择和生成测试用例测试用例的数量和复杂性可以通过对算法进行参数化来控制，例如，说明系统的哪些部分需要测试。覆盖标准确定测试用例选择过程的粒度，从而允许根据所选择的覆盖程度进行可靠性假设1.3特征交互汽车控制系统中功能的数量和耦合性不断增加，导致了一个复杂的交互功能网络，以实现客户此外，关于可能的特征组合的多种变型要求特征的灵活集成和移除然而，今天因此，由来自系统的不同部分的不同步特征的非预期组合引起的意外和不期望的行为在最坏的情况下，这种特征相互作用[7，12，10]可能导致严重的安全问题，例如，当ABS干扰ESP（电子稳定程序）从而阻碍减速过程[4]时。在组件重用的情况下，当需要但缺少特定功能交互时，也会出现类似的现象，例如，当安全关键功能未能否决另一个可能威胁其安全执行的功能时2预赛在下面的讨论中，我们考虑一个简化的形式系统规范模型。面向功能、基于组件的方法受到软件密集型嵌入式控制系统架构和行为规范的最先进工程方法的启发，例如汽车领域的AUTOSAR标准[1]2.1功能架构我们将功能架构定义为由逻辑构建块（即软件系统的组件集C）组成的四元组F=C，S，A，V。一个组件C∈ C的接口将过程消耗的输入值定义为参数，将产生的输出值定义为内部函数计算的结果。我们使用（共享）值的抽象概念来推断组件之间潜在的数据/控制依赖关系，而忽略了实际使用的通信范式。因此，值V∈ V可以被解释为信号、共享变量等。传感器组件S ∈ C和致动器组件A ∈ C在功能级别模仿传感器和致动器硬件设备的角色40M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37位置按钮关键位置pw_移动门锁(a) 连接器视图（b）值视图Fig. 1. 门系统即传感器值的源或用于控制致动器的值的汇。由于我们省略了分层组件结构，即在组件中，每个C ∈ C都被假设为原子，可以定义为C =<$I，O，R <$V，其中I<$V表示组件读取的输入值，O <$V表示组件更改的输出值。因此，I= O表示C的Interface值。Runnable R指的是实现组件功能的函数集的内部进程的行为规范。在C ∈ S的情况下，I=0成立，O={O S}是传感器提供的测量值。对于C∈A，O=I，相应地成立，I={I S}是与致动器无关的值。传感器/执行器的内部行为规范R可以忽略不计。在基于组件的体系结构规范中，连接器的概念被引入来表示组件之间的依赖关系，表示为使用关系。对于函数体系结构F中的组件C1∈ C和C2∈C，我们有从C1的输出值V∈O1到C2的输入值VJ∈I2的连接器，i <$V=VJ，因此对于每个V∈O1<$I2。作为一个运行示例，我们在下文中引用了一个简化的案例研究车门控制系统（详见[13图1所示的功能架构FDS包括用于电动车窗的控制部件PW∈ C和用于中央锁定系统的控制部件CLS∈ C1（a）中的表示使用连接器（箭头）来说明组件和环境之间的数据流，而1（b）中的值（圆圈）和组件传感器组件PW Position Sensor∈ S测量车窗的垂直位置，PW Button Sensor∈ S提供电动车窗按钮的状态，CLS KeySensor∈ S提供钥匙的位置。执行器PW Actuator∈ A上下移动电动车窗，LockActuator∈ A锁止和解锁车门。 V中的值用于在组件。可以按下电动车窗按钮“向上”或“向下”，迫使电动车窗执行器将车窗移动到所需方向，直到（a）按钮被释放，或（b）车窗到达位置传感器指示的最高/最低位置。相应地转动钥匙，门就可以上锁和开锁。连续两次将钥匙转动到锁定位置会激活中控锁，因此不仅可以锁定车门，还可以将车窗移动到最高位置。CLScls_statusPW门门pw位置PW_位置_传感器pw_移动PWpw按钮PW_按钮_传感器cls_status关键位置门锁CLSCLS_钥匙_传感器锁_执行器PW_执行器M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37412.2行为规范功能体系结构的组件C∈ C通过实现系统的原子功能的软件工件来主机处理。我们假设C的这些可运行项R的规范是作为分层状态机给出的，例如S状态流自动机。S状态流形式主义[8]是一种类似状态图的方法[9]这在嵌入式系统工程中很普遍，因为它是MAT的一部分LAB/Simulink工具集。在这里，我们考虑STATEFLOW的基本表示具有最常见特征的模型本文提出了一个基本的湍流模型，物理规范R被给出为SF R= S，T，sub，S0，其中S是状态集，T 是转换的集合，sub是子状态关系，S0S是集合默认状态。在这一点上，我们省略了显式的最终状态。除了基本状态外，S状态流自动机还提供复合状态，即导致状态层次范围的异或状态和引入并发子的机械.复合状态S∈ S包含直接子状态SJ∈ S，它们通过子状态关系sub_S× S相关，因此（S，SJ）∈sub。因此，sub定义了一个以基本状态为叶子的复合状态树层次。的直接子状态XOR状态通过异或相关，并且AND状态的直接子状态本身是包含AND状态的正交区域的XOR状态。S状态流自动机的最外层状态，因此状态层次结构的根是XOR状态。 对于每个XOR状态S，恰好有一个直接子状态SJ∈S0英[中]/阿作为S的默认状态。 转换SSJ∈ T 从一个来源状态S∈ S 到目的地状态SJ−−−−→∈ S用复杂ECA规则标记通过共享值V定义系统中的行为和通信，其中这三个部分中的每一个都是可选的。E部分列出了系统中发生的触发转换的事件，C部分包括条件，即转换到火灾所需满足的防护。作为事件，我们假设系统中的某个值发生变化，而条件则通过值的表达式来定义A部分规定了在进行转换时要执行的操作，即值重新分配。ECA规则中的值的访问和使用必须与周围组件的接口规范相匹配：（1）对于在E部分或C部分中读取的值v∈ V，以及A部分中赋值的RHS，v∈ I必须保持，（2）对于赋值的LHS中的值v∈ V，v∈ O必须保持。再次考虑样品门系统：控制组件PW和CLS包含可运行件RPW和RCLS，每个可运行件由单个STATEFLOW模型SFPW和SFCLS组成，如图2和3所示。转换由输入值上的条件电动车窗的三种状态表示车窗的位置，即上（关闭）、下（打开）和挂起（在中间），其由值pw position∈ {1，−1， 0}表示，并且相应地对于pw button和pwmove也是相同的，其中0表示根据按钮状态和车窗位置，通过设置执行器值pwmove将车窗移动到预期位置，直到车窗到达最高/最低位置。最初关闭时，只有当中央锁处于非活动状态（即cls status== 0）时，才能打开车窗。中控锁作用于钥匙位置42M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37[pw_button==-1AND cls_status==0][pw_button==-1AND pw_position！=-1]/ pw_move：=-1[pw_position==-1] /pw_move：= 0pw_uppw_pending[pw_button==0]/pw_move：= 0下载[pw_position==1]/pw_move：= 0[pw_button==1AND pw_position！=1]/ pw_move：= 1[pw_button==1或pw_position！=-[1]图二. 车门系统[key_position==1] /door_lock：= 1[key_position==1]/cls_status：= 1cls中心锁[pw位置！1]/pw_move：= 1cls_upcls_unlockcls锁cls_pending[pw_position==1]/pw_move：= 0[key_position==-1]/door_lock：= 0[key_position==-1]/door_lock：= 0; cls_status：= 0; pw_move：= 0图三. 车门系统值1表示当锁定两次时，中控锁激活，将车窗移动到最高位置，并设置状态标记clsstatus，以通知电动车窗功能。当执行时，S流自动机SFR的当前状态是一个配置σ=Sσ，V →D，其中SσS是活动状态的集合，V：V → D是一个解释函数，将当前值映射到某个通用域D的元素。一个执行步骤从一个配置σk=ν Sσk，νkν导出到根据所选择的操作语义，随后的配置σk+1=νSσk+1，νk+1作为对于全面的讨论，例如解决冲突的过渡激活和非决定论，我们参考[16]。然后，SF R的运行被定义为（可能是无限的）步骤序列（σ0，σ1，.，σn，.. . ）.我们假设，组件C的可运行R中的几个进程通过最外层层次的正交组合被集成在一个状态机规范SFR中SFR=SFR1<$SFR2=<$S1<$S2<$Sc，T1<$T2，subJ，S0， 1<$S0， 2<$S0，c<$其中SC={Sroot，Sreg}将新的XOR根状态Sroot添加到包含AND状态Sreg的SFR，AND状态Sreg的区域是SFR1和SFR2的先前根状态。关系sub相应地适应于subJ，并且新的根状态S0，c被添加到SFR1和SFR2的默认状态的集合。 假设SFR1位于组件C1中，SF2位于组件C2中，则承载SF R的组件CR=SFR1<$SFR2可以构造为：CR=C1<$C2=I1 <$I2，O1<$O2，R<$其中R是指SFR。请注意，这个基本结构可以根据用于实现的交互概念进行细化。例如，M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）3743仅由C1和C2访问的局部变量可以从CR的接口值中移除，例如构成隐藏在CR中的局部变量VR V。在这种情况下，IR=I1<$I2\ VR，OR=O1<$O2\ VR。例如，当将电动窗部件和中央锁定部件集成到门系统组合C DS中时，可以从CDS的接口中移除值cls_status∈ 0_CLS_PW，从而成为C DS的本地值。所介绍的基本STATEFLOW结构对于控制系统的行为建模是足够的，但也可以像往常一样丰富，参见例如。[9、16]。2.3功能网络一个功能是由一系列相关的系统工件实现的，这些工件以某种方式合作，以便以用户可识别的方式来检查环境。环境应该是系统的一个硬件组件，或者它位于系统之外，因此是间接的。特征链源自环境，其某些属性通过传感器数据来识别。根据要实现的控制任务计算系统反应的数据处理是通过一系列交互功能完成的，最终协调一些致动器对环境产生所需的影响通常，嵌入式控制系统的功能实现不同类型的反馈控制回路。形式上，特征可以被定义为f=Sf，Rf，Aff，其中SfS是传感器S∈Sf，其传递值OS，即与特征相关的刺激和测量数据，R∈Rf是可运行的，即实现f的交互功能，并且AfA是致动器A∈Af，其通过调整IA而被特征所激励，以便获得期望的行为。这些工件之间的互连是由其组件的连接器导致的，这些组件导致了相互关联的特性的网络。示例车门系统包括两个功能：电动车窗和中控锁系统：fPW=N {PW位置传感器，PW按钮传感器}，RPW，{PW执行器}fCLS=PW {PW位置传感器，CLS钥匙传感器}，RCLS，{PW执行器，锁执行器}2.4特征交互检测一般来说，如果两个或多个特性访问至少一个共享的系统工件，那么它们可能会相互交互。根据抽象级别，这些交互点可以是用于实现多个特征的传感器/执行器、组件、可运行对象、值等。根据我们的系统规范模型，我们通过共享值来表征特征交互。两个特征f1和f2相互作用，如果：(i) 这两个特征都使用至少一个共享值v∈ V。44M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37(ii) 至少有一个特征分配给v。第二个条件意味着v不可能是一个符合特征交互直觉的传感器值。我们将此定义称为明显的特征交互，因为它还包括明确预期的交互，例如系统内从一个进程到另一个进程的状态标签的简单传递。f1和f2的不经意特征交互出现，如果：(i) 这两个特征都使用至少一个共享值v∈ V。(ii) 这两个特征都指定为v。因此，f1和f2可以同时修改v，或者是修改内部控制值，或者是修改执行器的行为。同样，这种交互通常是通过设计引入的，并且是正确同步的，例如通过控制标签，如样品门系统中的cls状态。然而，这些模式必须经过彻底验证，以排除意外行为。如果两个功能同时被激活，即，实现改变相同值的不同特征的正交STATEFLOW（子）自动机，矛盾的力可以被注入到致动器。一个特例对于由对环境具有矛盾效应的不同特征所影响的两个不同的致动器，为了探测这种星座，可能需要进一步了解环境。在门系统示例中，两种类型的特征交互都存在，这将在下一节中进行分析为了检测一组特征f1，f2，.中的特征交互，f n实现为一个系统F=C，S，A，V，我们定义一个特征依赖图为GFD=<$NF，ED<$N F，其中NF是节点的集合，每个节点对应于系统的每个特征fi，ED<$NF× L ×NF是连接节点的边的集合，这些节点的特征共享至少一个由标签L∈ L引用的F的系统伪影。在最一般的情况下，这并不局限于特定的工件集，边缘是无向的。 在第3.2节中，我们将把值v∈ V视为共享工件，并将边定向以表示读写依赖关系。2.5测试用例生成所介绍的系统模型可以用作各种目的的正式系统规范，例如正式分析和自动代码生成。由于该模型反映了系统的功能需求，因此它也可以作为一个测试模型来导出测试用例，即：激励的样本序列和系统的预期反应，以验证系统的实现。刺激通常被称为事件，即相关的，因此可见的“脉冲”发生在某个时间点，并以一定的顺序到测试中的（子）系统的接口。根据我们的系统模型抽象，我们假设这样的事件是一个事件，即改变系统中的值。根据应用测试的层次结构，测试用例中考虑的值来自单个功能、组件的接口，最后是整个系统。在最后一种情况下，刺激主要与传感器值有关，因此测试用例模拟环境，而在较低级别上，测试也模拟本地M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）3745在系统内的某个点上产生的值，并由被测系统工件的接口识别 从行为规范R构造的测试用例可以定义为t = t（e1，e2，.， e n），Φ n. 根据测试级别的不同，R可能是一个基本功能，也可能是由不同的组件/组合组成的，直到整个系统的集成模型。事件ei是值v∈ V的变化，这些值是CR的输入，因此是对v（v）的一个干扰，因此触发了S态流模型中的跃迁和相应的反应。对于一个完整的测试用例t = t（e1，e2，.，e n），Φ n，R的反应是一个游程Φ =（σ0，σ1，.，σ n）。 当t应用于被测系统，如果系统行为与测试用例预测的Φ中的行为不同，则出现故障当执行黑盒测试时，只研究CR的输出值，并将其与测试oracle Φ的配置σ i中预测的值进行比较。否则，当执行白盒测试时，可以考虑Φ的配置链中的状态和值的完整细节。例如，样本电动车窗部件的测试用例可以是：t pw=（关键位置：= 1，关键位置：= 0，关键位置：=-1），Φ其中Φ中的预测结束配置为{门锁== 0，cls状态 == 0}。故障建模等其他技术可用于注入不正确或意外的输入，以检查系统是否进入错误状态[5]。由行为规范R构造的测试套件给出为T=n {t1，t2，.，t m}，因此，对于R的行为模型，要考虑m个测试用例的集合t i和覆盖标准t i，例如，路径覆盖。要生成的测试用例的数量m取决于标准的严格性，模型的大小（状态，转换等的数量），R的接口值的数量和域等。以下部分中提出的构造原则旨在通过仅将那些行为规范组合到可能导致特征交互的测试模型R来测试可能的特征交互时减少m3面向特征交互分析的测试用例生成3.1基于状态流模型的测试用例生成一般来说，基于模型的测试集生成包括四个步骤：（1）建立测试模型，即系统规范，（2）验证测试模型，例如通过模拟，（3）生成关于充分性准则的测试用例，以及（4）执行测试用例。所采用的充分性标准在很大程度上取决于测试模型：对于面向控制/数据流的表示，即流图和基于自动机的方法，可以使用图算法，例如用于路径覆盖，并且对于面向源代码的标准，可以应用语句/表达式覆盖，定义使用分析等。在这里，我们考虑功能架构F和组件可运行项的相关行为STATEFLOW模型SFR特征fi是指功能46M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37系统需要实现的需求，因此需要通过从测试模型生成的测试用例进行验证。在第2节中介绍的特性的规范可以用来跟踪实现中涉及的系统工件的相关功能需求，并因此要解决基于模型的测试用例生成。对于像STATEFLOW这样的状态图形式主义，提出了各种基于模型的测试用例生成方法，例如[5，2，6，11]。总的来说，共同的基本思想可以归纳如下：转换成一个流图：测试用例生成算法，例如。对于路径覆盖，主要基于构成基本数据/控制流程图的测试模型。因此，导致分层自动机方面的行为规范的状态图式形式主义首先要被转换（注意）为适用于测试模型[5，11]：(i) 通过添加额外的转换来移除XOR状态。从最里面的XOR状态开始，直到AND状态的所有区域都只包含基本状态。例如，在图3的中控锁系统的模型中，XOR状态cls central lock将被移除，并且“unlock”转换将被添加到每个先前的(ii) 通过构造所有区域的子状态的笛卡尔积来去除AND状态，即通过交织来解决正交性，参见例如[5]的文件。(iii) 步骤（i）和（ii）自下而上地重复执行，直到达到根状态，因此sub被合格性标准应用和测试用例选择：一般来说，合格性标准，尤其是覆盖率标准，定义了根据其揭示故障的潜力来证明测试套件有效性的措施这样的标准指示何时停止测试的时间点，即，何时生成的测试用例集合对于系统的可靠正确性声明来说足够“丰富”。因此，所选择的标准意味着所使用的测试生成方法和相应算法所需的测试模型。例如，当应用路径覆盖时，图中的每个可能的转换序列给出测试用例，其中转换被映射到匹配该特定转换的触发器的事件（值分配）。特别是对于具有非终止控制回路的反应控制系统，由于路径的长度可能是无限的，因此要覆盖的路径的数量是无限的。 作为一个解决方案，一个适当的上限k的最大路径长度是选择的方式类似的原则，环路覆盖标准[5]。此外，模型检查技术可以应用于选择有区别的测试序列，参见例如[14，15]。要生成的测试预言至少包含预期的输出，或者仅用于最终步骤，或者用于测试的完整跟踪，并且可以扩展到支持全面调试的内部系统配置的详尽预测对于断层建模等技术的应用[5]测试预言也可以定义要达到的错误状态。当处理面向数据的标准时，控制路径不仅要被匹配转换条件的任意值覆盖一次，而且要被可能的整个域覆盖。M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）3747值，详见[11]。当将测试用例生成和应用嵌入到工程过程模型（例如V模型）中时，可以区分伴随开发阶段的测试用例的不同级别的抽象和相关系统工件，例如，功能测试，即单独测试系统的单个“原子”功能（例如，向上移动电动车窗），模块/组件测试，即测试（子）功能（例如，完整的电动车窗特征），直到集成/系统测试，即测试完整的系统功能，包括 满足要求规范中要求的所有功能。根据抽象层次的不同，测试用例生成所需的测试模型是由所涉及的工件的部分模型组成的，即：S潮流模型在该级别集成的（子）组件相应的测试用例然后传播得到的测试模型接口的输入激励（参见第2.2节）。测试用例的执行，即接口激励序列注入到被测（子）系统中是通过模拟值变化/事件的源来实现的例如，传感器值的注入，即环境的模拟可以通过硬件在环设置来完成3.2面向特征交互的测试用例生成系统测试的测试套件的详尽生成和执行是乏味的，因为系统中所有组件的并行组合导致具有爆炸数量的状态（以及因此的路径）的图。此外，将所有功能混合到综合测试用例中使得识别导致测试应用期间观察到的故障的故障源变得困难，特别是当由不经意的功能交互引起时。因此，在组件测试和系统测试之间需要一个中间步骤，专门研究有限数量的功能之间的相互作用。 然后通过并行组合构建测试模型只有那些参与实现至少一个交互功能的STATEFLOW模型。首先，这种混合可以成对进行，然后通过组合几个相互作用的特征，最后是相互关联的特征的整体集合，这与系统测试生成的最差等价 对于实现一组特征f 1，f 2，.的系统规范F = C，S，A，V，f n，特征交互测试用例的生成可以通过以下步骤完成。3.2.1特征依赖图构造如第2.4节所述，我们将值集合V作为由特征fi共享的伪影，指示用于构造GFD=n {n1，n2，.，n n}，E D，其中节点n i∈N F表示特征fi，并且边（n i，v，n j）∈ V D连接特征fi和fj的节点，如果它们共享变量v ∈ V。边（ni，v，nj）是从将v分配给特征fi的节点引导到通过分配或读取来访问v的特征fj的节点的有向边。对于每个赋予v的特征fi，Con-D，（ni，v，ni）∈ED成立. 对于一个特征f i= Sfi，Rfi，Afi，我们将IAfi称为由f i指定的致动器值的集合。由fi读取的传感器值的集合OSfi在我们的构造中可以被忽略，因为这些48M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37pw_移动pw_move、door_lock、cls_status图四、车门系统在系统内从不分配值，因此不能引起特征交互。 对于可运行项R ∈ Rfi，我们通常将其分量C R= R∈ IR，OR，R ∈ I R。 我们定义由特征fi的至少一个可运行项改变的值V fi，c ∈ V的 集合 为：Vfi，c=IAfi{R∈RfiOR}以及由特征fi的至少一个可运行项读取的值（传感器值除外）的集合Vfi，r∈ V，通过：Vfi，r={R∈RfiIRIOSi算法1将系统规范F的特征fi以及如上所述的fi的相关集合Vfi，c和Vfi，r作为输入，并构造连接特征fi的节点ni的特征依赖图GFD的边集合ED。为算法1特征依赖图构造1：对于所有f，我做2：对所有v∈Vfi，c做3：对于所有fj做4：如果v∈Vfj，c<$Vfj，r，则5：ED←（ni，v，nj）6：如果结束7：结束8：结束9：结束考虑每个特征fi，可能被该特征改变的值的集合v∈Vfi，c。如果fj也通过读取或改变值v来访问值v，并且从ni到nj的边被添加到用v标记的VD，则出现与特征fj的可能交互。 注意（ni，v，ni）∈ED也适用于这个构造。 图 4显示了为示例门系统构建的特征依赖图。节点指的是电动车窗（PW）和中控锁系统（CLS）的功能。注意，只有那些至少被特征之一改变的值才出现在边缘处。3.2.2特征交互检测上面构造的特征依赖图通过共享值明确地揭示了特征之间耦合的不同程度。 对于G FD，我们用变量v ∈ V表示节点n i的传入边的数量，|n i|v. 我们考虑特征fi的以下情况：pw_移动PWCLSpw_move，M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）3749(i) |v = 1|v= 1(a) （fi，v，fi）∈Ed，即特征fi是唯一的特征改变值v，因此没有关于V的特征交互出现。(b) （fi，v，fj）∈Ed，其中ii=j，即特征fj改变V，特征fi读作v. 因此，在fj和fi之间存在明显的特征交互作用。(ii) |v > 1|v> 1(a) （fi，v，fi）/∈Ed，即fi读取由相互作用的特征改变的值v。因此，fi可以通过系统中的其他特征的特征交互来间接地确定(b) （fi，v，fi）∈ E d，则fi与其他特征同时改变v存在不经意的相互作用。我们现在可以定义关于变量v的相互作用特征集FIv，其中{fi，fj}<$FIvi分别满足情况i（b）或（fj，v，fi）∈ED和情况ii（b）。例如，在门系统中，我们有|n PW|pwmove= |n CLS|pwmove= 2，因此电动车窗和中央锁定系统经由对电动车窗致动器的并发访问的不经意的特征交互，并且因此FIpwmove={PW，CLS}。与此相反，|n PW|clsstatus= 1通过显式地使用状态标记来指示两个功能之间的明显交互。3.2.3功能交互分析的测试用例对于单个特征fi=Sfi，Rfi，Afi，测试模型SFfi可以通过将可运行集Rfi中的所有S状态流自动机正交合成，然后将合成后的S状态流转换为图来构造，如3.1节所述。所得测试模型的接口由Sfi、Afi以及来自SFfi接口的其他全局可见值组成。交互特征fi∈FIv和fj∈FIv的测试模型现在可以通过组合SFfi<$SFfj来构造。对于特征交互感知的测试用例生成，所得到的流图中的那些转换是感兴趣的，在其ECA规则中出现共享变量v对于测试用例的创建，t=（e1，e2，...，e n），Φ i，其“引发”特征交互，t必须包含触发由f i和访问v引起的转换的事件e i，a s e e l l a e v e n t e j映射到f j的转换，f j也访问v。因此，在构造流程图的转换时，必须添加注释，其中包含转换所源自的特征的相关信息。为了全面覆盖功能交互，对于测试套件T ={t1，t2，...，t m}，因此必须选择包含到v的所有不同访问星座及其在测试模型的路径中发生的排序的测试用例，即读-写/写-读序列（明显的交互）和写-写序列（不经意的交互）。再次考虑门系统：表1显示了相互作用特征PW和CLS的第一个简单测试用例。每一行表示来自测试序列的输入事件和相应的系统运行，即，门被锁上，然后窗户开始向下移动，由按钮刺激释放，50M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37输入PW输出PW状态CLS输出CLS状态关键位置：= 1上门锁：= 1→cls锁pw按钮：=−1→pw待定cls锁pw位置：= 0pw move：=−1pw待定cls锁.....表1第一个测试用例输入PW输出PW状态CLS输出CLS状态关键位置：= 1上门锁：= 1→cls锁关键位置：= 1上cls status：=1→cls挂起pw位置：= 0上pw move：= 1CLS待定pw按钮：=−1上pw move：= 1CLS待定.....表2第二个测试用例输入PW输出PW状态CLS输出CLS状态关键位置：= 1上门锁：= 1→cls锁pw按钮：=−1→pw待定cls锁pw位置：= 0pw move：=−1pw待定cls锁关键位置：= 1pw待定cls status：=1→cls挂起pw位置：= 0pw move：=-1pw待定pw move：=1CLS待定.....表3第三个测试用例符合测试Oracle。注意，车窗位置传感器的输入激励可以通过耦合到电动车窗致动器的环境模型连续传递，以实现闭环控制。在检测到特征相互作用FIpwmove={PW，CLS}之后，可以构造用于调查PW和CLS到电动车窗致动器的接触的适当测试用例。对于这个例子，不经意的特征交互产生于转换Tpwmove T，英[中]/阿S−→其中动作A包含赋值pw move：= RHS。测试用例为了研究这个特征，相互作用必须覆盖tPW∈Tpwmove的组合并且tCLS∈Tpwmove在特征PW图中的所有可能的顺序，其中tPW是指源自特征PW的STATEFLOWSFPW的SFPW到SF CLS的转变，并且tCLS相应地源自SFCLS。如表2所示，两个功能均操纵pw move的测试序列必须包括按下电动车窗按钮并将钥匙转动到锁定位置两次。这个场景涵盖了PW和CLS之间通过valuecls状态进行的交互，这一点我们在前面已经很明显地认识到了如果按预期激活中控锁，状态标记会阻止此外，电动车窗系统能够经由位置传感器跟踪车窗的状态（位置），尽管其由系统中的“未知”伪像操纵现在考虑表3中的测试用例，其中注入了事件的不同顺序注意，在最后一个步骤中，系统达到这样的状态，其中两个特征都试图通过相反的力来同时操纵窗口致动器，这覆盖了如上所述的不经意因此，有了这个M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）3751测试用例可以发现PW和CLS之间的不正确同步在行为规范中，因此在系统实现中。问题在于，只有当电动车窗控制器处于最高位置时，才会检查状态标记注意，该示例还包括“物理”特征交互的变型，因为用于移动窗的致动器直接借助于窗位置来影响环境，其然后影响窗位置传感器，并且因此再次影响特征PW和CLS。更进一步，研究“传递”的潜在影响，即特征的隐式交互。 对于不同的值v和v j，有两个特征交互集FIv和FIvJ，并且FIv≠FIvJ=/因此，来自FIvm的特征可以与来自FIvJ的特征相互作用，尽管它们不共享任何值。例如，如果FIv={f1，f2}和FIvJ={f2，f3}，因此FIv<$FIvJ={f2}，f1和f3may通过F2相互连接。因此，将通过以下方式建立相应的测试模型：由f1，f2和f3组成。这不仅可以通过FI的交叉对来推广，而且可以通过所有可能的组合来推广，这将自然导致集成所有功能的完整系统的测试模型。应在何种程度上执行该过程可以取决于决策标准，例如所涉及的特征的安全级别、耦合程度，即共享值的数量等。4结论与展望我们描述了一种基于模型的测试生成方法，明确考虑到功能交互的检测和全面调查，但旨在减少所需的测试用例相比，详尽的功能测试在系统级。该方法基于对功能架构和行为规范的严格建模，使用类似状态图的形式主义。作为未来的工作，不同水平的“传递”耦合通过相应地调整明显的和不经意的交互的概念，这可以潜在地导致测试用例的进一步减少此外，可以集成用于明确地调查由环境中的因果依赖性引起的特征交互的适当作为诸如温度和日光传感器的传感器值之间的因果依赖关系。最后，行为模型的高级规范将在测试用例中解决，例如时间约束。取决于所使用的时序模型，即同步与异步步骤语义[9，8]，相应的方法将被应用。例如，引入时钟作为变量，相关的滴答事件作为额外的输入，可以为时序约束定义转换条件，这可以在测试用例生成和执行期间显式地考虑引用[1] AUTOSAR合作伙伴，汽车开放系统架构（最后一次访问是2009年11月）。网址http://www.autosar.org52M. 洛豪大学Goltz/Electronic Notes in Theoretical Computer Science 264（2010）37[2] Bader ， A. ， A. S. M. Sajeev 和 S. Ramak