当讲到汽车行业的单位测试时，大大批人起初思到的测试场景便是性能测试。性能测试即是获取属于某个单位的扫数需求并编写测试用例来验证单位是否按预期性能做事。

当讲到汽车行业的单位测试时，大大批人起初思到的测试场景便是性能测试。性能测试即是获取属于某个单位的扫数需求并编写测试用例来验证单位是否按预期性能做事。

性能测试用例起原于需求，一个测试用例代表了被测体系一次“优良的运转”，笼盖了单位性能的某一方面。为了验证预期活动，测试职员通过界说特定的输入来慰勉被测体系，然后比拟预期结果和模子或代码的仿切实际结果是否一律。由此，测试用例是将需求文本转换为可用于仿真的数据流。

因为其特质，测试用例能够写得很长来涵盖特定的活动，而且需求平凡只是刻画联系的输出信号以及中心观测信号的预期活动。另外，纵使需求刻画了输出信号的预期活动，它也能够只是供给一共测试用例中的即时讯息。而不联系的信号平凡被视为“Don’t care”，而且也没有界说其即时讯息。

一条需求合系的扫数测试用例一朝都被告成地践诺了，这条需求就能够为被测试到了。即使现正在市集上有许众新的测试手艺，然而性能测试是验证被测体系性能活动的准绳测试办法。

现正在有少许东西能够主动天生测试用例，苛重能够分为两类，一是随机测试用例天生，个中测试用例是通过随机抉择输入数据来天生的，然后再检验到达的笼盖率。这种办法的便宜是能速捷地天生测试用例，然而天生的测试用例是不完全的，而且测试用例的长度能够长短常长，很难举办调试。根本上扫数联系测试东西都供给了这种办法。另一类是基于Model-Checking的测试用例天生。这种智能办法天生的测试用例是完全的，况且尽能够天生最短的测试用例去笼盖某个笼盖对象，乃至能够声明某个笼盖对象长久无法到达。于是它比随机测试用例天生花费时候长少许。目前唯有很少的东西能供给这种高级智能办法。要是有机械可读的需求即情势化需求，那么Model-Checking手艺就能天生性能测试用例。全部讯息请查看BTC EmbeddedSpecifier假设咱们现正在没有机械可读的情势化需求，那些主动天生的组织测试用例要是不是来调换性能测试，那么它们的主意是什么呢？关于性能测试，需求是测试用例的讯息起原，即使关于情势化需求也是这样，这点与主动天生的组织测试用例相仿，但讯息起原却差别。这些东西不斟酌需求，而是将被测试体系的组织属性行动测试用例天生的起原。主动天生的测试用例能够斟酌很众能够的组织特质。根本上，它们都是合于模子或代码笼盖率的。最常睹的笼盖对象是语句、分支或决定、条款和篡改的决定/条款笼盖(MC/DC)，个中ISO26262中正在软件单位层级提出的组织笼盖对象如下图所示

另有许众相仿于函数笼盖、等价类或孑立指定的笼盖对象，如下图所示为ISO26262中正在软件架构层级提出的组织笼盖对象

为了避免曲解，这类测试用例就被称为组织测试用例，当然它们的特质也有所差别。它们不是验证需求，而是通过变更输入和标定参数来“应激”被测体系。平凡，这些测试用例很短，它们斟酌了扫数步中的扫数信号，没有“Don’t care”的信号。然而，要是这些测试用例来自于被测体系，然后又正在被测体系上践诺，这莫非不是一个自我达成的预言吗?

推导组织测试用例能够分为两步。起初，（咱们称之为）引擎天生慰勉向量。慰勉向量只蕴涵输入数据，即每个输入信号和每个标定参数的数据，不蕴涵任何合于输出和中心观丈量的讯息。于是这些慰勉向量只刻画了怎样到达肯定的笼盖对象。

所以，平凡慰勉向量是来自模子依然来自代码并不紧急。要是咱们深切讨论这个话题，那么将代码行动源流有几个很好的情由，然而要预防的是要是运用日常的办法，由模子依然由代码推导出慰勉向量并没有什么区别。

这些天生的慰勉向量的首要好处便是，它们能够仍然指出了模子或代码中的少许组织性题目，这些题目与被测体系的鲁棒性相合，比方溢出、除零、值胜过范畴或无效值等。

第二步是要从慰勉向量派生出组织测试用例。由测试职员决断，该当从哪个源达成派生出输出活动。正在基于模子的开辟中，这平凡是模子。所以，扫数天生的慰勉向量都正在模子上践诺，并记载仿真的输出。如此慰勉个人和记载的仿真输出活动一块组成了一个组织测试用例。

现正在能够正在代码上再次践诺这些组织测试用例，以验证代码的组织活动是否与模子相像。换句话说，它验证模子是否确切地转换为代码。最常睹的题目比方精度偏差、数据溢出乃至编译器区别等，这些都能够导致模子和代码之间的活动差别。所以，ISO 26262猛烈推举举办背靠背测试。

因为这种办法依赖于模子或代码以及所选的笼盖率对象，于是它不须要来自测试职员的格外输入或交互。所以，这种测试办法能够所有主动化，并可使用于开辟和测试进程的接连集成情况中去。组织测试用例并不是为了…

主动天生组织测试用例是一种很简单的办法，但这也引出了一个题目，是否天生的测试用例能随机地合适一条需求。纵使这正在表面上是能够的而且有白皮书正在表面上争论过这种办法，但简直绝对相信不行够如此做。然而让咱们且则假设少许天生的组织测试用例合适需求。这意味着测试职员务必手动检验扫数天生的测试用例，并检验个中一个是否合适需求中的一条。因为模子或代码依然能够蕴涵失误，所以这种办法能够无法挖掘性能上的失误。另外，跟着需求的填充和天生的组织测试用例的填充，该职司的做事量和繁杂性将昭着成倍地填充。一朝实行了这一步，测试职员依然务必为尚未笼盖的需求编写格外的性能测试用例。结尾从做事和繁杂性的角度来看，这种办法并分歧用于现实的测试做事流。

总结即使主动天生的组织测试用例和手工编写的性能测试用例之间有很大的区别，然而它们是性能测试的有用添加，能挖掘模子和代码之间的组织题目。此外，试图将主动天生的组织测试用例照射到需求并不是一个适应的办法。

汽车测试网-首创于2008年，报道汽车测试手艺与产物、趋向、动态等 合联邮箱 marketing#auto-testing.net (把#改成@)