第二十讲，HIL零基础搭建及应用教程，测试用例设计

公开章节，欢迎转发啦~~~

上一讲，我们从理论和根本原理上，详细探讨了“多控制器联合HIL”，比如三电HIL，彻底扒了扒它到底是个什么东东，相信各位读者一定能形成对这种“联合HIL”的正确认知，也能从VCU HIL中触类旁通，很容易地搭建出这样一个三电HIL（如果有必要的话）。

本讲，我们继续讲述HIL的应用，讲测试用例的设计，我们先以人工测试为例，并适当考虑着以后的自动化测试。

在阅读本讲之前，您应至少仔细阅读过第6、7、8、10、12、13、14、15章节，并通过这些章节，详细了解至少两个方面的内容：功能定义、HIL设备软硬件信息。

很多厂家的HIL设备，之所以成为摆设，供应商的误导是一部分原因，还有一部分，是车企自己的工作没有做好。其中最为典型的就是，功能定义不明确。功能都不明确，那还测个啥！所以，师子一号的系列文章，除了讲技术，还讲流程和方法，因为没有流程，HIL就无从谈起，根本做不起来。但是，师子一号所介绍的流程，是“必要的、基本的、极简化的”流程，只保留了最核心的环节，这样我们就能既不被流程困住，又能享受到规范性带来的好处，从而使车企的工程师不会为流程所累，好钢能用在刀刃上。

测试用例要有一定的标准和格式，格式标准有两个用处，一是使工程师做测试用例的时候，规范一些，毕竟，填表比自由写段落，信息肯定更直接、更清晰。二是，为方便机器识别，为后期自动化测试做准备。

师子一号看到过形形色色、格式各异的测试用例，有的清新简洁，有的却非常麻烦。小编综合了各家优点，并做了稍微改进，决定为大家介绍下面格式的测试用例。

测试用例一般都是用Excel做的，人工测试的话，基本都是如此。

基于Excel的自动化测试，是所有HIL集成商孜孜不倦的追求，但是遗憾的是，目前行业对此并无标准，各玩各的，各个供应商都希望以自己标准为主导，让客户按照自己的来，而且，相当一部分的自动化测试都是用Python、RobotFramework等IT技术，把Excel转化成代码，然后倒入到Dspace、ETAS、NI等HIL系统中执行。师子一号对此深表痛心，好端端的汽车工程师，为什么要花费那么多精力去研究IT技术呢？我们的重心工作是汽车设计，不是给HIL查找各种bug。难道真的就没有一种极简的基于Excel的、不需要查代码的、能自动提示各种错误的自动化测试方法吗？（答案是有的）

我们来看一下这个excel内容，这个是一个非常简洁、实用的测试用例格式了。测试工程师、功能设计工程师，大家一起，设计测试case，并且经评审通过，各方均认可。等测试case确定下来了，测试人员来到HIL设备跟前，对照着测试case，一步一步操作，就可以了。

很明显，测试case的设计、评审，需要平时日积月累，不断优化、增加，需要动脑筋。测试的执行，需要的细心、集中精力，不太需要动临时创新。

我们来解释一下这个测试case的格式。

A列是动作类型，它的参数决定了本行的动作属于哪一类（一般应至少有控制某个值、检查某个值、时间控制、IfElse等基本类型），通常情况下，本列的值应使用下拉菜单来选择。其用途之一是让本行的目的一目了然，二来是便于机器识别。本讲不牵涉到机器识别，所以师子一号把这一列暂时删去，后续自动化测试章节，再详细描述。

B列是动作描述，是由测试工程师在设计测试case的时候，对本行的目的进行备注，否则不备注的话，以后再看，就看不懂了。

C列是变量名，是Veristand系统的变量，比如pannel中的标签名，是告诉测试人员，我这一行要控制或者查看的是哪个变量。

D列是要设置成的值。如果本行的类型是控制HIL中的某个变量，那么本列的数值有效。

E列是要读取的值。测试工程师和设计工程师在设计case的时候，是对VCU当前的输出心里有数的，这个“数”，就来自于我们的功能设计。把这个期望值填写在这里即可。

F列是时间控制，特别针对于有较高实时性要求的逻辑，比如，控制某个值之后多少毫秒，进入下一个动作；或者，读取某个值，并等待它符合预期，等待多少毫秒。这些都是时间参数，对自动化测试特别有意义，但是在人工测试的时候，准确把握这个时间参数，是有难度的，所以，如果是人工测试，就把那些时间参数强的信号，通过“第一类闭环自动模型”来实现，如果是自动化测试，那就能准确控制这些时间点，没必要再用那些“第一类闭环自动模型”了。由此可见，所谓“第一类闭环自动模型”，也不是一成不变的，要根据设备的实际情况，看看“是不是必须的”。

G列是区块备注。只有每行的B列动作描述，还是不行的，行数多了，回头看，还是难以看懂，这个时候，我们可以通过区块备注，把若干行放在一起进行一个综合描述，会很方便我们后续阅读、修改、复用。在师子一号的文章里，后续我统一把每一行叫做一个动作，把相关的、第G列统一备注的几个动作，称作一个case。

这个简化的、简洁的测试excel文件的内容，依赖于状态冻结了的HIL台架（软件和硬件）和定版了的VCU功能定义文件，如果HIL台架状态变更，那测试case有可能需要修改，如果功能修改，测试case也需要修改。

图中这个case，目的就是快速建立起VCU热管理控制功能的信号初始值（有些车企的HIL，使用“闭环模型”，一个很重要的目的就是用这些“闭环模型”给VCU提供初始值，因为闭环模型在HIL运行的时候，就会自动建立初始值，把测试快速跑起来，确实能省劲，），因为我们是直接控制这些变量，而不是通过模型控制，所以，自由度很大，测试覆盖率很高，边角旮旯都可以做测试（边角旮旯的信号值所做的测试，被有些供应商称作“极限测试”，因为那些模型到达不了这些边角旮旯的信号值呗。但是在师子一号看来，也算不上“极限”，简单的信号值控制而已。）

我们继续充实这个excel文件的内容，如下图：

很明显，师子一号所提供的这个excel格式，就是模仿人工测试的情形的，只是把这一切全都自动化了、精确化了。师子一号在上图中，仅仅列出了一点点P4电机温度对风扇的影响的case，但是实际上，这个case可以很大，做个几十行是很有必要的。但是好在，我们这个case，只要做一次，以后就可以复用了，再加上如果我们合理的功能模块划分、必要的开发流程规范支持，我们这个excel文件甚至可以后续在多个项目中不断复用（只要功能能复用，测试excel文件就可以复用）。

OK，这就是师子一号给大家带来的测试用例设计文档，非常简洁简单，就这一个文件搞定。

后续章节，我们还会对这个文件的格式、用法进行详细探讨，期待您的关注。

至于测试的执行过程，小编就不说了，没啥可说的，足够细心就可以了，而且后续我们也会介绍自动化测试，那才是HIL领域真正的皇冠，我们会详细讨论。

技术是永无止境的，单纯的技术是没有意义的，技术应该为我们的目的服务，而我们的目的就是把车做好、做优秀。师子一号给大家带来的东西，或许不是技术最先进的，但是一定是极其好用的，一定能帮助您在围绕着HIL、把功能做得更健壮，一定有助于把车做得更好。我们的愿景就是帮助广大从业者，从层层迷雾中拨云见日，为我们共同的目标而努力。

下一讲，师子一号将带着大家，去逛逛HIL相关的网站（技术论坛、行业新闻、采购信息、商业广告信息等等），扒一扒网上各种关于HIL的信息。师子一号将会把那些云里雾里的的句子翻译成白话文，把那些包装吹牛甚至造假的信息给含蓄地揶揄一下（您可以想象一下发论文的场景，明明啥也没研究出来，却要编得妙笔生花），把那些努力上进地例子给鼓励一下，让您看看，这一切原来都是那么简单、可爱。

师子一号相信，这绝对是一场让人期待，充满乐趣的欢快旅行，让我们一起期待吧~