overview前言
今天继续介绍TSMaster新功能—自动化模块在测试中的判定方法。众所周知，判定在测试中决定了一个用例是过还是不过，用自动化模块就可以轻易地实现测试逻辑。那么怎样才能在测试逻辑执行后合理地对结果进行判定呢？
在此，需要大家更新TSMaster软件至最新版本。最新版本下载链接可以直接在公众号菜单栏回复“TSMaster”，即可获取。
1. 判定相关的API函数
如何才能对测试的结果进行判定呢？这里就需要一系列和判定相关的API函数。举个简单的例子：比如需要判断一个发动机的温度信号是否在0-50度之间，该怎么做呢？
1.1 自动仿真
在系统的安装文件中，选取示例的数据库CAN_FD_Powertrain，将其拖入TSMaster环境中进行加载。
通过总线仿真激活所有节点，允许自动仿真，并启动总线仿真，仿真虚拟的节点。
1.2 温度信号值的范围
在自动化模块中的入口点按一下回车动作，添加一个动作，然后双击设定。动作的属性为API函数调用，并且在小程序的系统函数的列表上输入verdict，选择check verdict。这个函数就是用来立即检测信号值的范围。
这里有4个参数，分别是显示的名称、参数的实时值、及所允许的最小和最大值。在名称处可以随意的填写，比如engine temp，这个字符串最后会进到这次报告里面，而实时的值，需要选择这个发动机的温度信号。
在min和max这两个信号我们分别赋值为0和50，判断这个信号是否在0-50之间，如果是那么检测通过，如果否那么检测失败。
点击运行程序，当前只是0，可以看到检测是成功的。如果将这个engine temp改为100度，再运行程序，可以看到检测的失败。然后会弹出一个检测信息，也就是当前的温度等于100。并不在0到50的范围之间，那么以上就是测试中的立即检测的方法。
2. Signal checker的一系列API
发动机的温度如果一直在变化中，而我们又需要在一段时间内检测温度是否在允许的范围。通用的方法就是使用循环，例如c语言的for函数或者是图形语言的运行和跳转，使它不停的往回跳，在这个循环中不断的检测。但是这个方法效率低下，而且如果同时需要对多个信号进行判断，这样的逻辑就复杂了。因此直接实施逻辑显然不是一个合理的做法。那么此时就用到TSMaster的Signal checker的一系列API。
2.1 add check with time
假设希望检测发动机的温度在0秒到15秒之内是否在0-50度之间，可以使用一个限定时间的检测函数，我们过滤一下通过checker这个字符串，可以过滤出signal checker的系列函数，那么第一个函数叫做add check with time。这个函数就是用来检测在一段时间内这个信号的值是否在范围之内。
2.2 8个参数
第1个参数是信号类型，点击常量，然后在这里输入checker，可以看到signal type有3种类型：分别是can信号lin信号或者是系统变量，在此我们选择的是can信号。
第2个是检测类型，点击常量，通过Signal checker的关键字进行过滤，可以看到检测的类型。
第3个是统计类型，统计信号的最小、最大值或者是平均值等等。选择总是检测，接下来是信号的名称，选择发动机信号，温度信号engine temp。但是需要注意的是，需要把字符串前面的CAN前缀删掉，这样才是字符串的本身。
第4个是信号容许的最小值，我们设定为0。第5个参数是信号容许的最大值，设为50度。第6个是检测时间，默认从0开始。第7个是检测结束时间，设定到15秒或者长一点30秒。第8个是我们所添加的检测句柄。
2.3 添加检测信号
每当注册了一个检测模块之后，都会返回这个模块的句柄给到我们的程序，我们的程序就可以反复通过读取这个句柄来获取相关的检测结果。在此需要用本地变量来关联它，我们添加一个本地变量，把它改成ID，然后回到属性，关联我们的本地变量，这样就实现了一个信号检测的添加。
接下来延时20秒时间，用的是wait方法，这里是毫秒所以是2万，消息可以不写，这样就不会打印。
再接下去就是获取检测结果，还是一样API还是要通过checker来进行过滤，那么这里可以找到get result，这个函数有4个参数，CheckId就是我们刚才获取的距离，我们选择ID，下面3个是返回值，我们都可以不填，不填就意味着我们不需要这个返回值，直接抛弃。
在c语言里面这些值都必须与对应的变量进行关联，在图形编程语言里面可以直接抛弃，当然可以看到最后一个是结果的一个字符串表达，我们可以把这个表达也存下来，这里我们申请一个字符串，把它命名为s，然后在这个地方关联，我们的本地的字符串就实现了一个检测，那么我们可以让这个检测做到随着程序启动自动运行。
3. 启动程序
3.1 正常值范围
点击启动，程序在运行，这个时候程序在wait等待过程中，等待的时间是20秒，在这个过程中可以看到信号的值一直是0度。我们可以随意的修改，有时候我们可以输入engine temp，那么这个值有时候我们改成35，那么就在变化，此时这个过程检测是很顺利的，并没有出现0到50之外的值。
3.2 超出正常值
如果我们尝试把engine temp值直接改成66，那么修改的瞬间检测就判断到信号超出了正常的值范围，不在0到50的范围，所以会打印出错信息。在等待20秒结束之后，可以看到我们的检测函数也会立即变成红色。
3.3 测试发动机的温度
我们实际希望测试的是发动机的转速，也就是EngSpeed在3,000-5,000转之间时发动机的温度是否还在0-50度的范围之内。那么这个就需要用到带触发的判断。
回到自动化模块，将第一个判断的API函数修改一下，改成第二个叫add check with trigger。这个函数有10个参数，前5个参数被保留了，我们继续保持它的值不需要调整。从第6个参数开始，就是跟触发的这个信号有关。
我们的意图是设置为发动机的转速，所以在这里trigger的类型依然是一个常量是一个CAN信号类型，在这里输入TYPE_CAN，触发的名称就是CAN信号的名称。
我们这里选择EngSpeed，同理还是要将前缀CAN去掉，表示这是一个字符串而不是一个值，那么接下来就是trigger的最小和最大值。我们刚才说的是3,000 和5,000转速，然后最后是一个CheckId，将它关联到我们的本地变量里，每调用一次，添加判断的函数就会在我们的检测引擎里面增加一个判断模块。
我们是可以在测试的开始前或者结束之后清空我们测试引擎的判断模块，比如说在开始前可以选择一个函数调用依然是checker，相应的函数有个叫做clear，这就是把所有的检测全部清掉，然后可以再增加我们新的一个检测。这个时候我们就把这个信号相关联的检测给实现，就意味着只有当检测条件，就是我们的发动机的转速是在3,000到5,000转之间的时候检测才会开启。
3.4 延长时间至30秒
我们可以将这个延时时间加长，比如说加到30秒方便我们观察，这个时候我们可以再次启动一下程序，可以看到程序在运行。这个时候发动机转速是0，所以不在这个范围之内。我们可以随意设置Temp，比如说设到100，这个时候都没有问题。我们将Speed改成4,000， 这个时候检测就成立了。
如果我们这个时候输入的值超过50，我们将发动机转速设置为4000，然后这个时候还是没有任何问题的。
如果将温度设置66，设置的瞬间可以看到检测就失败，它不在0到50的范围之内。在等待30秒之后可以看到我们的checker这个函数的返回值做了一个判定，那就是在这个3,000到5,000转之内，它的温度值并不满足0-50的范围的要求，实际的值也都打印了出来。API函数的返回值也都进行了打印。
Chinese 
English