正在汽车、航空等安详合连的界限，不单代码的体量越来越大，安详性羁系也不时抬高，例如汽车行业出台了ISO26262尺度，航空业有DO-178尺度等，对软件计划、测试和验证提出了总共、厉酷并且完全的央求。而企业的糊口压力央求新产物尽疾进入商场，这无形中挤压了开发的计划和测试周期。基于模子的计划（MBD）恰是正在这种状况下涌现的新方式，不单加疾了体系的斥地，消浸了保护本钱，同时对测试机谋，提出了新的央求。

正在汽车、航空等安详合连的界限，不单代码的体量越来越大，安详性羁系也不时抬高，例如汽车行业出台了ISO26262尺度，航空业有DO-178尺度等，对软件计划、测试和验证提出了总共、厉酷并且完全的央求。而企业的糊口压力央求新产物尽疾进入商场，这无形中挤压了开发的计划和测试周期。基于模子的计划（MBD）恰是正在这种状况下涌现的新方式，不单加疾了体系的斥地，消浸了保护本钱，同时对测试机谋，提出了新的央求。

软件的测试，通常可能分为静态测试和动态测试。静态测试不运转序次，凭据软件的语句觉察软件正在合规方面的缺陷，例如MISRA C对软件的编写，对语句的利用给出了格外完全的央求。静态测试也可能凭据软件的逻辑相干，觉察软件可以存正在的缺陷。动态测试是正在软件编译结束后，欺骗测试用例来运转软件，以到达测试主意。动态测试或许直接窥察软件行径，推断运转结果是否适当计划央求。动态测试是软件颁布前最终的保证，其要紧性不问可知。

软件的计划是基于计划央求的，即软件所需求达成的效力。于是软件测试务必验证软件的输入输出等行径餍足计划央求的效力。关于一个管制体系，手工天生测试用例的难点是，计划央求所形容的形态或场景，平淡同时包蕴输入和输出，并且跟时序形态相合。于是正在主动化测试用具涌现前，体系测试需求体验富厚的工程师手动天生测试用例。

这种正在众个贯串时序上餍足特定形态的测试，有时间只需求复制餍足条款的第一个测试用例就能达成，而有时间并不如此乐观。

正在上述两种测试央求中，都用到了“巡航体系正在管事形态”，从图_1可能看到，这个形态是体系的输出量，这就央求手工用例计划工程师，或许从输出量反推出一个或一组输入（测试用例），来餍足“巡航体系正在管事形态”如此的央求。

跟着体系越来越庞杂，手工反猜想试用例越来越疾苦。咱们利用美国Reactive-Systems公司的Reactis产物，主动天生测试用例，获得了不错的成绩。

关于比拟简陋的计划央求，Reactis支撑C发言来编写UDT和Assertion。如下图_3所示进入UDT和Assertion的修立界面。

pression栏目可能看到，UDT的修立即是一句尺度的C代码语句。对应的Assertion只需将ex

ink文献，而System正在这个文献中，挑选用于该测试的模子。下面的Inputs是做输入联系的，使验证模子和被测模子的输入逐一对应。

Assertion的设定肖似，图_5是Assertion的Stateflow模子，用于计数有几个贯串时序爆发速率缺点大于1mph，当觉察有赶上3个时序时报错。正在设定结束后，软件界面上会涌现带框的对准镜和闪电图标（如图_7所示）。

Reactis效尤ISO26262的遮盖度测试方式，把UDT和Assertion都看作是遮盖度宗旨。UDT是否遮盖显示计划央求的场景或形态的测试用例是否存正在，而Assertion是否遮盖显示正在计划央求的场景或形态下，违犯计划央求的反例是否找到。

正在天生测试用例后，会叙述是否找到违反计划央求（Assertion）的状况。这时需求当心，只要正在UDT达成遮盖，即找到餍足计划央求所需求的场景和形态的状况下，Assertion的叙述才是有用的。测试工程师可凭据Reactis所叙述的，爆发违反计划央求的这个测试用例，对模子举行调试，发行软件的缺陷。

ISO26262尺度中与软件测试合连的实质，厉重界说正在ISO26262-6文献中，如图_8所示。

将上述三方面归纳起来，就可能获得ASIL安详品级，从A（安详紧张最低）到D（安详紧张最高）。关于体系测试的每一个方面（测试宗旨），ISO26262用符号显示关于分别安详品级实用性:

关于测试工程师来说，ISO26262-6-9的单位测试和ISO26262-6-10集成测试是最合连的一面，图_9是咱们总结的测试重心。

基于计划央求的测试，正在前一节依然作了扼要解释，下面就9.4.5和10.4.6的央求，作进一步说明。

从ISO26262-6-9.4.5可能看到，遮盖度测试，包含语句、分支和MC/DC应当正在单位测试阶段获得餍足。同样，ISO26262-6-10.4.6指出，函数和挪用的遮盖度测试的要紧性。即使未能餍足这些遮盖度测试央求，应扩大测试用例来餍足，或解释来因。

效力测试是ISO26262的构成一面，但效力测试只是包蕴了计划央求所例举的极少场景，与9.4.5和10.4.6所央求的遮盖度测试，侧核心分别。效力测试所天生的测试用例，平淡达不到遮盖度测试的央求。而遮盖度测试并不重视体系效力，不行验证体系是否餍足计划央求。

为了举行遮盖度测试，咱们已经挑选美国Reactive-Systems公司的Reactis软件。行业内也有不少其他软件可能达成同样的效力，咱们以为Reactis的操作比拟直观，效力完善（支撑基于S-Function的C代码白盒子测试），主动天生的测试用例出力比拟高，并集成了调试效力。

– 即使需求对S-Function的C代码举行白盒子测试，只需右键点击S-Function模块，修立所包蕴的C代码源文献。

从图_6可能看到，Reactis供应了众种遮盖度宗旨，不单包蕴ISO26262-6-9和6-10所央求的语句、分支、MC/DC、函数，以及挪用等宗旨，还包含极少用户可以重视的宗旨。例如“CSEPT”用来对Stateflow举行测试，当主形态切换时，窥察子形态是否退出。

利用Reactis的叙述效力，可能很便利的查看各测试宗旨的遮盖度和总体遮盖度。如图_12所示。

固然借助测试用具软件可能主动形成测试用例，然而完整依赖用具到达ISO26262央求的遮盖度也不太可以，或者需求极少手法。于是，何如抬高遮盖度，就成为测试工程师新的课题。

从本文的效力测试一面可能看到，Reactis把效力测试也看作遮盖度宗旨来主动天生测试用例，可谓总共皆遮盖。于是，Reactis正在抬高遮盖度方面，供应了极少适用的机谋。

因为软件中包蕴大方的条款推断语句，这些语句对输入量的取值格外敏锐，过于宽松的输入值规模，将使得主动搜罗测试用例变得格外疾苦，而不稳当的输入值设定，会使得探寻算法底子找不到或许遮盖的用例。于是，测试工程师正在导入模子后，务必对每一个变量，凭据实践的可以性举行设定。图_13是Reactis供应的输入值设定窗口，可能看到Reactis供应了富厚的设定体例，餍足各品种型的取值需求。

正在许众状况下，咱们依然有了一个测试用例的子集，例如达成效力测试的用例，咱们希冀扩充这个子集，来遮盖ISO26262的安详性测试央求。如图_14所示，Reactis供应了“Preload Files”效力，让用户将这个子集预先导入到软件中，当主动天生的测试用例跟子会集的测试用例反复时，可能利用“Prune”选项告诉Reactis是否可能剪切子会集的测试用例。

当已有测试用例正在某个或某些宗旨的测试方面展现不佳时，可能针对这些遮盖度宗旨举行测试用例的天生。如图_14所示，正在“Coverage Objectives”栏目，可能仅仅挑选需求聚焦的遮盖度宗旨。

正在本文的效力测试一面依然提到UDT测试。正在那里，UDT厉重是为了寻找计划央求的场景或形态，通常与Assertion配合利用。原形上UDT也可能稀少用于遮盖度的测试。关于比拟庞杂的逻辑，例如涉及较长的贯串时序，默认的修立很难觉察有用的测试用例。这时务必昭彰告诉用具软件去合切这种需求。正在这种状况下，就可能利用UDT来到达主动天生测试用例的主意。

安详合连的管制体系测试，不单需求餍足效力验证的央求，还需求餍足行业的安详样板。因为测试的央求，不单涉及输入量，还需求同时思索输出量、体系形态、时序、以及遮盖宗旨，给测试工程师提出了很高的寻事。本文以Reactis用具为例，通过利用主动化测试用具，工程师只需求从计划央求和安详央求起程，编制测试模子或测试条款，就能让用具主动形成高效的测试用例，餍足效力和安详性的测试央求。