基于模型的代码生成器的系统测式.docx

基于模型的系统的测试代码生成程序IngoStu"rmer,MirkoConrad,HeikoDo"rr,andPeterPepper,成员，IEEE摘要：不象常见吩咐式程序语言（如C或者ADA）编译器，维护了基于模型的代码生成器生成的构件没有既定的方法存在尽管在形式验证领域取得进展。几种测试方法在工程实践中处于支配地位。这篇文章为运用在基于模型开发的代码生成器描述一个通用和工具独立的测试体系。我们通过测试TargetLink代码生成程序执行的最优化评价我们的方法的有效性。TargetLink代码生成器在基于模型自动化开发中是一个被广泛地接受和困难开发工具。索引术语测试和调试。1绪论汽车的嵌入软件被开发方式已经变更。可执行的模型现在被运用在开发的全部阶段，从起初设计到到实现（基于模型的发展）。用大众流行图形建模语言进行模型设计，象来自MathWorks1的SimUIink/Statcflow。新的方法允许通过所谓的代码生成器干脆从SimUlink和StatefIOW自动生成可控有效的代码，象dSPACE2的TargCtLink或者MathWOrkS3的实时工作室嵌入代码编码器。一个代码生成器本质上是一个编译器，它把一个用图形建模语言表示的源程序翻译成象C或者ADA一样的一个吩咐式语言。代码生成器相当地降低软件实现的努力。也，通过在模型级早期的质量保证获得质量级别可以导致高质量代码，供应代码生成器工作正确。由于这些特征，代码生成器有一个强大工业需求。基于模型代码生成器与传统编译器不同有几个方面。1）目标语言和源语言两者都可执行的。因此，代码生成器的可执行行为能干脆与模型的仿真行为比较。2）模型语言的语义常常不是明确的定义。语义可依靠信息的布局（例，位置的状态）及内部模型设置（例，块参数,数据类型的处理）。所以,语义被嵌入在模拟器的说明算法中4。3）特殊,象被Sinnnink定义数据驱动语言生成器组成一类新的开发工具。代码生成器不能简洁执行逐步翻译从模型分层体系结构到一个抽象的目标语言语法树。相反，他们必需分析数据依靠源于一个适当的计算机序列，这是代码生成器的精髓。在目前，基于模型的代码生成器不是同己制定的C或者ADA那样成熟。代码生成器的技术风险是高的，因为他们D是被一个相当小的开发团队运用和2）面对一个高效率的技术革新引起一个新版本的出现在一个短周期内。因此，一个正式化代码生成器正确性的证据在实际中是不行实行的。因此，通过基于建模工具代码生成器的运用取得生产效率的提高不能完全开采的。代码生成器与手工写代码一样必需用同样昂贵的精力检查，即使惊慌的质量度量已经花费在模型上。这篇论文为基于建模的代码生成器介绍了一种通用、切合实际的的测试方法。该方法大量运用代码生成器的输入和输出是可执行的事实。方法的目的有三点：1）测试案例的系统来历必需在测试包中执行的信念，因此它可以用服务于验证代码生成器。2）测试案例必需能自动产生覆盖高可变的模型。3）测试包必需能执行和自动评价，处理代码生成器的快发布周期。通过确认TargetLink代码生成器执行的优化，我们评价我们测试方法的有效性。这篇论文的剩余部分的结构如下：其次节介绍基于模型的代码生成。第三节描述了代码生成器的优化。第四节支撑一个系统的代码器测试理论线索的概要。第五节通过一个例了描述了系统代码生成器测试方法。第六节介绍了从三个案例获得测试结果第七节探讨了结果和局限性，和通过总结他的贡献和示意将来探讨方面结束论文。codegenerationtoolchain图.1基于模型的代码生成原理.2 .基于模型的代码生成在基于模型的开发中，一个限制算法的实现通过模型的逐步求精来开发，一个所谓的的物理模型起源于软件元件（图L左上）的功能需求说明书，物理模型捕获限制算法和依靠于（连续）输入信号和（内部或外部）事务的限制功能的描述行为。物理模型有代表性地运用浮点算法（FLP）和被用来验证关于在需求说明书规定需求的模型的功能行为。在机动机工程领域，嵌入式系统被定义作电子限制器（EeUs）。由于硬件资源的限制，ECU须要一个很小开销（例，有限或者没有抽象）和能有效的利用系统资源的（高级）编程语言。由于经济缘由，运用在一个ECU的微处理器是更相宜8,16,或者32-位固定点处理器。因此，物理模型不得不被实现专家手工精炼；例如，功能部分被安排到不同的任务和用必需的实现细微环节增加。而且，用在物理模型的FLP算法是适合嵌入式目标处理机（看5具体）的固定（FXP）算法。为了保持FXP数误差精度尽可能低，固定点的数据类型被护展以相宜伸缩信息，2.提炼的结果是实现了的模型。它包括为代码生成须要的全部信息和允许被代码生成器产生的有效C代码的创建。依靠于开发阶段和目的，为开发计算器（主机）生成的代码，在多数状况下，是一个标准的PC（图.1.右），在那种状况下，一个传统的编译者/链结者组合被用作将产生的代码译成可一个可执行的.对于目标硬件一一个典型的评估委员会类似于电子限制单元（EeU）限制-一个所谓交叉编译器被须要。这儿，一个连接器和装入器建业和装入二进制代码到嵌入设备。工具链确定建模工具（编辑器和模拟器），模型到代码的翻译工具（例如，代码生成器，（交叉）编译器，连接器，装入器），和，最终，目标硬件自身组成代码生成器工具链（图.1）。基于模型的代码生成器是一个基于模型开发的主要的优点。在软件实现阶段，一个代码生成器的运用导致一个重大的生产效率改进。个别探讨表明：通过代码生成7软件开发时间的降低达到百分之二十。假如手工确认过程在代码级也能降低，报告说节约达到百分之五十。这与其他用户供应国内信息是一样的。总的来说，与传统手工编码相比，生产效率提高达到50%o3 .代码生成器优化嵌入系统的代码生成常常有资源限制。624因此，就生成有效的代码而言，无论什么时侯可能，优化技术必需被采纳。例如，内存消费和执行速度。传统上，代码优化是通过（叉）编译器翻译源代码成可执行的目标代码来完成。这样标准优化是，例如，死代码消出，不变的传播，环路的解开，从传统编译器说明了解到的（看，例，8）。当运用一个代码生成器，优化已经在最高级表现形式被执行，例如，在中间（图）表现形式3（IR,看图.1.中间），和能运用呈现在模型级的巨大数量信息。一个有代表性基于模型优化，为了创建有效代码模板，企图组合不同模型部分，是块间优化。图.2显示一个图形模形描绘一个ifThen-else控件结构，那里假如A不在间距C2,Cl中，输出E等于输入A。另外，常量值C3被传播到输出E。控件逻辑被用所谓开关块D计算，它的操作如下：开关传播或者是第一个输入A或者是第三个输入E依靠于控件输入B的值（在这个案例中，输出或操作）。假如在控件输入符号是大于或等于一个内部临界值_t,开关传播第一个输入。否则，它传播第三个输入。当一个没有优化的代码生成器翻译图形模式块到块和为每个输出块引入变量，一个优化了代码生成器能翻译模型成一个单独if-thcn-else限制结构：if（A>Cl）II（A<C2）E=A;）elseE=C3;）留意全部表示块输出中间变量已经被消出和逻辑被插入交换条件。作比照，一个块翻译将产生额外的程序代码和，所以，导致一个高RAM消费。由于不同的代码生成器，代码生成器设置，或者优化技术的选择，一个特定的模型结构的实现可以多样化。因此，在一个模型和产生代码之间不同结构可能存在。在代码生成器优化中，四个主要优化/翻译策略的分类引起在模型和代码之间结构差异：1 .重复。代码为每个他的调用者重更实现可复用的模型结构。内联就是这样的一个优化技术。2 .复用。这个优化取一套等价但有区分的模型结构和为了降低程序尺寸用一个单独可复用的元件来实现他们。一个函数调用用不同的参数是一个典型的这样优化技术的例子。复用是与内联相对。3 .简化。模型结构的实现是合并或者丢弃为了得到效率（例，块间优化）或移去无用的部分（例，死路径消退）。4 .增加。额外代码被产生象代码爱护免受一个潜在被O除。在模型和代码之间结构不同将节5.3接着。4代码生成器测试4.1 测试的基本原理测试是一个可执行的测试对象，通过一个有限测试例子，带着发觉错误的意图。测试案例是为了一测试对象关于它的说明可能的输入。假如他们有时间依靠，测试案例的依次叫做测试向量。一个收集或套测试用例是常常称为测试套件。测试能显示出席了错误而不能显示缺席的错误11。因些，主要的挑战在测试是设计错误敏感的测试案例。这个任务最终确定测试的范围和质量。测试是到目前为止唯一的方法，在真实的环境允许动态检测程序的行为。对于基于模型的代码测试，我们将4.4节论证在真实的应用环境进行模型和程序行为比较是多么重要。功能设计测试技术（也叫做黑盒测试技术）和结构设计技术（也称作白盒测试技术）是最突出的测试案例设计方法12。功能测试是基于测试对象的需求说明书和通过测试案例覆盖尽可能多的需求。测试对象被假定是一个黑盒，它的实现细微环节不被测试设计考虑。对比功能测试，结构测试可以保证覆盖每个程序元素。一个常见的结构测试的缺点是不能保证功能的正确。由于这个缘由，一个好的测试策略是应当是一个功能和结构测试的组合。这样的一个功能和结构测试的组合定义为灰盒测试61.这个策略将被应用到代码生成器测试（5.3节和5.4节）6251*-ordertestcaselinker/loadert(Testoutputs图.3.动态代码生成揩测试方法4.2 代码生成器的范围测试为一个“完全"的代码生成器测试，单独地验证全部的翻译功能是明显不足够的。一个完全的代码生成器测试应当更多的测试目标的考虑。例，翻译规则的组合，健壮性，算法异样的处理，或者将以前从释放版本知道的漏洞作为重点重测目标。在我们方法常规范围内，对于代码生成器的每个测试目标作为一个特定的测试模块对待。全部的测试模块组成一个相应的代码测试套件。这扁论文焦点在模块测试规则优化，因为优化是在代码生成器翻译中最简洁出错的。但是，即使我们聚焦在代码生成翻译上，技术显示也可适应其它类型翻译。4.3 代码生成器测试案例在第一级，假如无效测试模块被拒绝和有效的测试模块被翻译成“功能等价”代码，代码生成器测试是胜利的。最近的检查显示功能等分估计须要一个二级的考虑。有效模块同代码生成器一样的行为必需用通过/失败确定来比较。为了那个目标，测试模块和被生成代码必需被执行用同样的一套测试套件来比较模块和代码行为(看图.3,左)。因此，一个有效的基于模型的代码器的测试案例通常组成测试模型(第一阶测试案例)同一套相应的这个模型的测试向量一样(其次阶测试案例)。由于这个测试模型可能处理内部状态，它不是充分的执行它用一个简洁的测试案例(例，常量值)，更准确地讲，其次阶测试案例必需是时间依靠测试向量,(测试向量i(t),看图3.左工相应的模型和代码执行(测试输出o(t),看图.3.右)的测试结果又是有时间标记的向量。4.4 动态代码生成器测试和功能等效翻译过程的正确性，例如，无论如何模型的语义己经被保存下来，是确定所谓背背测试了。在背背测试中，模型测试输出和来自他们用标识测试向量i(t)执行结果的输出进行比较。假如模型和代码显示同样测试输出，关于这套测试向量他们考虑被执行正确性在下面，在主机PC上模型上模拟叫做模型环绕模拟(MIL),在主机PC代码执行叫做软件环绕模拟(SIL),和在目标处理器代码执行叫做处理器环绕模拟(PlL)。有时间测试依靠的测试输出MIL,SIL,和PIL是。MIL(t),oSIL(t),和OPlL(t)(看图.3,右)。全部的三个输出是通过背靠背方式成对地比较。请留意，全部三个开发构件，即，在主机PC模型，在主机PC的上生成的代码，并且在目标处理器上生成的代码，考虑正确的模型到编码的翻译。通常，有效的鄙译须要那被产生的目标代码中实行展览，为任何规定的套输入数据，与执行源代码(看14)相同的看得见的效果。通常，作为为了标识输入/输出行为的一个需求被说明。然而，在基于模型代码生成器的联接中，这个需求是剧烈的，即使在一个模型到代码正确翻译状况下，你不能期望相同的行为。因此，传统观念的正确性,因为它们用于编译器不适用。更进一步地说，定义正确性必需基于一种充分类似的行为观念.信号比较算法(图3,右边)必需能容忍三个时间系列表达测试输出oMIL(t),oSIL(t),和OPlL(t)之间的不同，发在限制流量子化影响也能在值域引起不同。而且，由于不同的编译器运用OSIL(t)和。PIL(t)也不同。626程序语言语义显示系统反应不能用肯定的身份检查。部分订单象“很少定义"运用在指示语义的关系被选择作为基本等价关系。对于代码生成器确认，一个适当兼容关系必被选择对于每个测试模型和每个分别的测试向最测试结果输出必需同下面定义兼容性相比较。假如他们差异是等于或小于一个的起始值，两个输出信号（系统响应）是一样的。不同的功能定义和起始值依靠于单独的应用。象肯定值不同的简洁的比较算法能应同更多精细算法，象不同的矩阵方法16,17.兼容性观念服务于一个基本。这个基本定义了起先一个正确模型到代码翻译函数等效。假如仿真模型和源于生成的可执行的代码完成，当两个用同样的输入数据被执行时，导致依次一样输出数据，一个模型和来自他产生的代码是功能等效。这个定义受下列限制影响：D作为一种主机和目标的不同的数值精度的结果的数字模糊。2）在处理“边界区域”象”不是一个数字"或对于很巨大或小数（例，上溢，下溢）的数字限制。3）关于不同硬件类型运用不同执行所用时间。表1TargetLink度量标准的代码生成器MetricsTargetLinkCodeGenerator(V2.0)OptimiserNo.ofclasses3,000200No.offiles6,000400No.offunctions51,0002,500Lines(total)1,800,00093,000Linesofcode1990,00052,000Linesofcomments560,00027,0004.5估计测试困难性一个代码生成器被认为是一个困难的开发工具。表1显示，作为一个例子，包括优化功能的TargetLink代码生成器版本2.O一些度量标准。优化器实现16优化技术的哪三个是纯StatefloW优化。在目前的版本中,优化只是稍微的组成部分,尽管它的确是剧烈的竞争优势的一个代码生成器。对于测试，每个优化规则必需为合适的测试例所覆盖。因为有16条优化规则实施，在TargetLink第2.0版本里，你可以估计测试模块的数量和所需测试的测试向量。假如，例如，为了完全测试一项优化技术300测试模块被要求30个测试向量被为每测试模块须要，那时，对16个最优化规则来说至少16*300=4800的第一阶测试案例和16*300*30=144000的第2阶的测试案例必需被产生,这测试案例的数量在现有的测试套件范围内。（例如，ACATS18对ADA编译器来说由几100K测试例组成。）4.6 在代码生成器测试中主要的挑战在如下内容里，当运用传统的软件测试方法时如，例,提出在12,我们探讨代码生成器测试的主要的问题。不行用的规范。为了能进行一次有意义的测试，一台代码生成器的功能测试最好基于一种工具的完整的说明书。不过，事实上一种完整的代码生成器说明书常常未公开的或者至少不公开可得到的。除那外，说明可能不与他们的实际实现一样，因为新版本的工具在短周期出现。另外，和编译器形成对比，通常接受适合图表的语言的标准定义例如SimUlink或者StatefIow,是缺乏或者是未发表过的是。不过，有基于一种部分说明的软件的部分被测试的测试方法（算法，内状态或者程序行为的高级描述的学问）。这种方法常常被称为测试的灰盒测试61,它结合当在这工作内提议时的功能和结构试验。困难性和测试的范围。即使有一个完整的说明书，由于工具的困难性，用传统的软件测试方法详尽地测试一整个代码生成器将是不行行的。例如考虑，翻译的功能的功能测试对求和操作（p）。依据19,实现功能a=b+c有超过2,OOO方法，由于数据类型，信息的伸缩性，和可选择的限制（饱和）,而且，整个生成代码器实现的结构测试也成问题。Santhanam20指出ADA95的琐碎的编译器由625,000行ADA和C代码组成。他估计与D0-178B有关的编译器结构测试将须要58人多年的努力。不行行的单元测试。一个软件测试通常在几个测试阶段内进行，哪个是单位测试，集成测试，系统测试和验收试验21.虽然测试整个系统是可能的（并且必要），但是当整体上测试系统时，处理具体的功能性（例。一个单元）很难。因此，为了允许软件系统被测试，系统须要进行模块化成简洁管理的单元，以便测试可能被在一个基于模块到模块件的基础上执行。对于一个代码生成器，这样的一个单元可能被作为单个的翻译或者优化功能理解。当它归结为单元测试时，翻译功能不得不脱离软件系统和包围了试验工具。对一个最优化规则来说，这将意味着从代码生成器分别它并且分别测试它。为一个最优化功能供应被要求的桩和驱动，不过，意味着在相当程度上再造代码生成器并且设置它在代码生成器链子中。这，不过，不能实行。6274.7 达到最高水平的和相关的工作系统的测试方法有巨大未探究的。少数发表的在实际中用到的基于代码生成器的测试过程可能被分成4个类，他们常常连续运用或者相互组合运用。核心实力的测试。随着核心实力的测试，个别SimUIink和StatefIOW语言构建（例如,所谓“基本块”的Simulink,例如求和块），以及在代码产生期间应用代码模式，对期望的行为进行严格测试。这些块和图案是关于数据类型和按比例绘制信息是变更的并且被在不同的目标处理器上执行。从而，有几千次试验是非常一般的状况。实行和结果评估很在程序上是自动化22,23O核心实力测试的组合。组合个别的块及常用建模模式与预期的行为比照进行测试。在这里,主要重点是常常通过代码生成器执行的最优化。预期值的确定和试验结果评价是手工完成22。大规模运用的核心实力。大量的真实世界模型被用来检查工具的稳建性和正确性。测试结果通过专家6,23进行了具体分析。测试模型通常包括100O块。测试的代码生成器的配置方法。一种（半自动）系统测试检查安装、配置，以及运算在不同的电脑配置代码生成器并对涉及在tool-chain工具不同的软件版本的工具一起（例如，编译器）、234.7.1相关工作多种正式的验证技术己经被运用为了显示他们的正确性对编译器。两个突出的组是编译器验证和翻译确认的方法。对于那些发表的关于两种方法的工作综合调查在24供应。编译器验证集中集中于证明一个编译器在一切输入程序上正确的技术25。因为，到目前为止,Simulink和StatefloW的没有明确语义学是可供应或者被出版的，正式的证明的基本的必要条件之一缺失。翻译确认显示个别程序正确的翻译，但是如NeeUIa26andZucketal.27关于翻译优化编译器的验证的报告是编译器没被验证。工程方法更集中于测试。这里，许多探讨已经被在测试的编译器过程中做，例如，编译器的测试案例生成技术。自动的测试案例生成通常产生程序是将被翻译成从源语言28,29,30,31,32,33,34,35的文法或者从一个正式的语法模型36的测试案例。通过申请全部可能的同在37最初提议样的语法产品，那些测试程序被系统的得到。欲了解对不同的方法的评估，参见38。在手工测试案例创建范围内，测试案例被手工得到依据给的语言标准。在编译器结构，测试套用来确认C或者ADA编译器实现来保证语言符合。这里，测试案例被在各自的语言标准里为每个段落建立。在C确认中最突出套件的是39,40,和42。对于ADA编译器来说,运用一个测试套件的确认已经尤其在ADA编译器的证明过程18中限制。一种C和ADA测试套件的比较被提出在43中。两条测试方法的显着不利是D测试参考不能被自动获得，2）代码生成器的实现细微环节（说明,源码,等等）不考虑测试，以及3）留意集中于个别的语言的正确的翻译建立，这常常不明确影响象最优化那样的具体的翻译功能。因此，这些功能可能在相当程度上保持未受测试。另外,基于模型的代码生成器的一条基于语法的测试方法将须要一套直观语言语法（望见44）,承认源模型的图表的布局信息。鉴于平安关键软件生成，对于爱护代码生成器，证明代码生成器常常被认为是牢靠过程（望见口3对于细微环节来说）。第三方评价这保证，就一般接受的过程或者标准平安而言,代码生成器始终开发并且被检查，例如IEC6150845以及在汽车工业ISO/WD2626246和在航空电子设备方面的部门D0T78B47不过，由于优化行为和他们的结合是通常不完全指定，化码生成器优化目前不影响代码生成器的证明。5 一个系统代码生成器测试方法在下面，我们为基于模型代码器提出我们的测试方法。即使这种方法是一般和工具无关的，我们必需为对我们的方法的评估运用一台具体的基于模型代码生成器。对这目的来说，我们通过dSPACE2选择TargCtLink。TargetLink是广泛地接受和常常用自动基于模型的发展运用的困难的开发工具。TargetLink通过MathTVOrkS1从图表的模型建立语言Simulink和StatefloW产生C代码。但是这不意味着我们的方法限制到基于模型的把Simulink和Stateflow模型翻译成C代码代码生成器。假如供应的源语言和目标语言是可执行的，这种方法可能适应全部基于模型的代码生成程序。留意到是值得的为这工作，dSPACE为我们供应一种TargetLink执行的具体的最优化的非正式和部分说明。工具的源码不行供应；不过，运用最优化被代码生成器跟踪。628首先，我们要确定从四个基于模型的核心目标代码生成器测试前几节的探讨。请留意，为了得到一个系统的代码生成器测试方法，这些目标必需被满意：1 .测试模产生。为了产生合适的第一阶段的测试案例的一个系统的策略被要求。为了使这项任务自动化，我们开发了针对SimUlink和Stateflow（ModeSSa,看章节5.2）测试模型生成器。对于在考虑中基于模型的代码生成程序来说，通过dSPACE的TargetLink,这些测试案例是被组合成试验模块的可执行的SimUlink和StatefIoW测试模块。为了给一个具体的最优化规则的系统测验服务，一个测试模块是一个有效和无效的测试模块的样本。一个特殊的最优化规则的测试模块基于它的说明并且必需包括最优化在试验下的规则的功能性和全部可能的应用条件。留意到这样的一说明基于灰色盒的方法要求一（至少部分）最优化在测试下的规章的说明和必需识别出图表的布局依靠性。2 .测试向量的生成。二阶测试用例必需设计，这样测试模型全部可能的仿真追踪和生成的代码全部可能的执行跟踪都考虑在内，进行测试。这可以通过应用一个结构或白盒测试的方法来完成，无论在模型和代码上。二阶测试案件的集合是须要确定是否生成的代码真正地展览测试模型的动态行为模型，在全部的可能应用条件下。必需考虑跟踪等价，因为模型限制流和生成的代码可能会有所不同：优化规则可能省略或合并模型分支机构，或代码发生器可以产生额外的代码犹如第3节探讨一样。总之，测试向量产生的目的，是迫使追踪通过全部模型部分(没有别的)和完整的代码。3 .结果评估。经过背靠背地测试一个模型以及相应的代码，测试结果须要自动进行评估。正如在4.4节探讨一样，相同的测试输出从模型中和生成的代码无法预期。作为后果，先进的测试结果评价方法，可处理价值差异以及在时域，是必需的为了确定是否产生的代码的测试输出在PC主机oSIL(t)和产生的代码的测试输出在目标oPIL(t)是兼容原来的模型的测试输出(见4.4节)oMTL(t)o4 .测试环境。由于测试(见4.5节)数量浩大，一个自动化测试执行环境是必不行少的。测试的基础设施应当支持以下任务：a.生成的测试模型必需被翻译成代码。b.测试向量必需处理和应用到模型和代码。C.模型的跟踪仿真和代码的可执行跟踪必需被捕获d.测试结果必需评估和记录。整个测试过程须要自动化集成的一套测试工具，必需制定或者，假如存在，它必需集成到测试环境。依据上述的4个目标，基于模型的代码生成程序的一个系统的测试方法可能被确定。主要活动和测试结构被用图4.显示。这种方法的个别的步骤被在节5.1到5.5描述，用一个运行的例子补充。我们再次强调想下列描述只是一个一般的一个实例和独立工具的测试方法，满意目标1,2,3,和4和其基础被首先略述在48里。Optimization ruleTestveclor ； generation <ReactisModeSSaITest model generationTest modelpF¾ISimulationTest output oml(1)Test vector generationTest vector i(t)CompiIerZIinkerCode generatorC codeSignal comparison r-jliCross compiler/ linker / loaderTest output OPtLa) ExecutionTest output os(t) 马与a图.4.代码生成器测试方法5.1 优化规则的形式化确定合适测试案例的起先的起点是工具供应者供应的代码生成程序的一个最优化规则的非正式，原文说明。被测试的代码生成程序转换规则（例如I,一个开关组件简化）然后被作为一个图转换规则正式化49.这种代表供应一种输入图（模型）的图案怎样被替换，补充，或者删除的清晰的说明。而且，运用图转换规则不象编译器和代码生成程序的一项正式的规格说明技术一样不平常50。例子。I RHS 1 |A;if B.value always A= Zode Attributes: D.type= switch D.threshold= F.type=code folding (A, B, C)A.kind= Var Const B.kind= Var Const C.kind= Var Const;if B.value always V 图5简化图翻译规则用于开关的优化。图5显示一个正式化的简化的变型Simulink的最优化交换块。给出的图转换规则由一个左手边组成（LHS,即，查找模式），3位可选择的右手边（RHS,即，替换图案）。这是有相同的LHS的3个规则的标记的简化。非正式，关于一张规定的主机图G（一个相应Simulink模型的高级表现）的规章的实行工作如下：.在G里找到一个LHS的匹配，.从在LHS里有一幅图像的G除去全部图要素，但不在中间图GO的在RHS结果里，和.作为出现只在RHS里但不是在LHS里并且把他们嵌入GO的规则要素的图像建立新图要素。简而言之，当RHS为规则应用指示后置条件时，LHS图指示前置条件。另外的应用条件，例如节点属性，被在LHS下面规定（例如,节点A必需具有友好的易变的（变量）或者恒定的（常数）。折叠的操作者指示那结点A,B,和C可能相同。在图5里，D节点描述有它的临界价值的开关组件（也看图2）,它的输入部分通过节点A,B和C并且它的输出通过节点E。假如，例如，限制B端口的值总大或者相等比以下单个代码行将在图2例子中产生的临界值：E=A;6295.2 测试模型生成图转换规则形式上捕获最优化规则和服务作为一个“蓝图”为了确定测试模块。现在，转换规则潜在的输入空间被更细致考虑。输入空间被定义为规则能履行图转变的一套图实例。这套能，在原则上，是无限的。因此，我们将运用这种分类树方法51作为一个测试设计技术的基础，为了系统划分图转换规则的（或许无限）输入空间成有限的等价类的数量。有系统地从图转规则得到等价类和这些类的组合一种方法被供应在52里.不过，等价类的合适组合可能被自动产生测试例用分类树编辑CTE/XL53,在CTE/XL里定义的测试例可能被认为是第一阶测试例的抽象描述,即,测试模块（看图6）.图.6.带有组合表的分类树vuo=B3sselqUQU一qE8例子。图。6以一棵分类树的形式的表达了转换规则的输入空间划分。开关块的3个输入端口A,B和C的每个（子树输入）可能是一个易变的（变量）或者一个恒定的（常数）显著来源。另外，两个或者甚至开关块的全部3个输入可能被一个供应和相同的信号源（子树折直）。叶子的一个完全的组合导致40个测试例。一篇选录是在图。6.的底部在组合表中提出。测试例37（图7）,例如，用三个信号标量表达了一个开关块，端口A和B是折叠和，因些，被单个的输入端口输入1描述。开关r临界界J的可能被在另外子树里指定（不在图6显示）用象.1,0,0:5或者1被通常试验中运用的值。在如下内容里，我们假装t被设置为0.5。630起因于不同的组合类的潜在的测试例的数量能快速增长。这也并非罕见,几百甚至万潜在的测试用例。当在CTE/XL描述的基于抽象测试的手工创建模型的过程是费时和简洁出现错误的，这步己经自动化了。一个CTE/XL测试例说明被翻译成一个具体的Simlnink或者StatCfIoW测试模块（运用测试模型发生器MOdeSSa）54（Simulink和StatefloW的模型发生器）。ModcSSa为在CTE/XL组合表中指定的每个测试例创建一个测试模块。为了这样做，一个分类树的XML表现被建立并且翻译成一个相应SiImnink或者StateflOW模型（运用图翻译语言GRCAT）的XML表现。55.翻译阶段随后有有SimUlink模型构建的可执行的测试模块的吩咐产生和StateflowAPI吩咐产生。图7的低下半部为用ModeSSa构建的TC37测试例显示测试模型。用这种方式产生的整套测试模型组成了第一阶测试案例，它系统地监测功能的代码生成器关于优化规则在考虑中。5.3测试向量的产生图.7.测试案例TC37的实例.在代码生成器的行为可能被检查之前,合适的其次阶测试例被要求作为模型的一次输入为了仿真全部可能的仿真踪迹，通过给定的测试模块，我们在模型级应用结构测试设计技术。测试向量的一种选择,确定满意适当的白盒测试准则（模型覆盖）。这项任务能在相当程度上通过运用象ReaCtiS那样的工具被自动化56.常常，结构上覆盖模型的测试向量也将包括生成码的主要部分。在57,一个有很强的相关性确定在模型级覆盖和在分支代码级覆盖之间显示。第2套结构上的测试例不过被要求应付模型上的结构上的差异并且最优化和其他翻译引起的代码。在代码生成己经被进行，结构上的测试例是被确定在代码级。这里，自动化可能被取得,例如,用发展了的结构测试工具ET58.创建在模型级的测试矢量和创建在基础上的C代码的联合组成了一套测试向量被用来检查测试向量的功能等效和相应的C代码。取决于个别测验矢量，合并的过程能导致每个测试模块一或多个测试向量。通常，测试向量的数量将随着测试模块的尺寸和困难性增加。为了在模型级取得充分的结构上的确定上的覆盖，一个单独的第2阶测试例己经被设计。测试例37.1模拟测试模块37在一个0.3秒的时期。Inputl将被刺激如下：对于InPUt2激励如下：0;0:0_t<0：10:5;0:1_t<0：21;0:2_t_0:3:8<:1.4 一个背靠背的测试的模型和C代码基于模型的测试工具MTeSt59为测试模块的背靠背测试和产生的C代码供应一种环境。全部有效测试模块给SimUIink开关最优化和相应测试向量被导入MTeSt并且装配成一个测试工程,这个工程表示在测试下最优化的规则的测试模块。首先，模型仿真被执行为了获得，适合每个测试模块和它的相应测试向量的参考值。MlLetT。另外，用那些测试向量模型覆盖在事实上达到是被度量。假如要求的覆盖标准没有满意，提出了一个警告。631035.8.测试案例37.1测试结果.其次，MTCSt通过叫TargetLink起动C代码产生。C代码可能被编辑到主机环境或者交叉编译到一种目标环境4。取决于用户参数选择，通过运用相同的用于模型仿真的测试向量的集合，一个主机或代码生成器的目标主机能被执行。测试结果输出OSILetT和OPILetT,分别，被记录给更进一步脱机处理。事实上的代码的可达也是可以度量的。再次，假如被要求的覆盖范围标准没被在代码级上遇见，警告被提高。不足的模型和/或代码覆盖能,例如,被不能到达的结构构件引起（例如,死的路径）。因此，覆盖警告必需被评价手工和附加第2阶的测试例可能被确定。1.5 测验结果评估为了确定模型和代码是否功能等效，相应输出时间序列兼容性被检查。假如主机代码在考虑下,oMILetT和OSILetT用适当的信号比较法相比较，假如焦点在目标代码上在。UlLCtT和OPlLCtT之间的差别肯定要评估。象已经说明的那样，基于应用的合适的兼容性关系肯定被选择。大部分状况下一犹如给定例子模型一为每取用点计算系统肯定不同是不足的并且，随后，确定整个取样间隔的最大偏差。假如用这种方式确定的偏差是小于给定可接受的选择的门槛值3依据被敬重的输出的量子化描述的精度，两个信号都相容。图.8显示了，在5.3节给出的例子里，用测试向量37.1执行的MlL和和SIL结果的测试输出。假如测试模块的全部相应输出信号对是相容,模型和C代码被认为是功能等效,即,包括代码生成程序的代码生成工具链子正为测试模块和被选择的测试向量正确地工作。在一信号对或更多之间的不兼容的缘由可能是多样的：1.代码生成程序的实现本身的错误，2. 有其中的一个工具或者在代码生成工具链里硬件运用的一个问题，3. 一个错误产生的测试模块，4. 一种不完全或者错误的说明（错误的图转换），或者5. 一个错误的（模型）模拟器。因此被视察的偏差必需被手工调查。除了信号进行比较结果，结果测量模型和代码覆盖率还应作为模型和代码异同的一个指标。假如，例如，实现代码覆盖率的百分比大于模型覆盖,你会得出这样的结论:额外的代码已经产生。因此，这种方法也能用于评价一台基于模型的代码生成程序的最优化潜能（例如全部死的路径被删除）的评估。6试验结果代码生成程序的系统的测试方法已经被运用并且通过3个案例探讨测试（具体的测验结果被供应在52）:6.1 案例探讨1：Simulink开关在第一个案例探讨里，翻译和单独的最优化以及组合的SimUlink交换块被检查。我们可以表明,在特定状况下无效的代码生成，例如，当缩放是开着的。在新的代码生成器版本里,我们也发觉知道的问题仍旧存在。而且瑕疵可能被揭示那在相互组合优化开关块时发生。6.2 案例探讨2：Stateflow流程图其次案例探讨处理有效的和无效的if-then-else流程图的代码生成以及所谓的开关状态。特殊是ifthenelse的流程图的变体（看2细微环节）。一般视察被确认，有效if-then