第二十讲,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的信息。师子一号将会把那些云里雾里的的句子翻译成白话文,把那些包装吹牛甚至造假的信息给含蓄地揶揄一下(您可以想象一下发论文的场景,明明啥也没研究出来,却要编得妙笔生花),把那些努力上进地例子给鼓励一下,让您看看,这一切原来都是那么简单、可爱。

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190221G07FGF00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券