浅论Javascript在汽车信号测试中的应用

起因

上周老板又给了我这个车辆工程毕业的码农一份工作:
要我写一个测试台架出来。

我先简单的分析了测试台架的几种典型的工况:
1、发送一个CAN信号,测试能否查到。
2、发送一个信号,是否能在规定时间内得到相应的回复
测试用例可能有上千条,但是万变不离其宗,总而言之就是测试信号和一些功能是否正常,暂时不涉及节点的模拟和管理等。
最后我采用.Net框架方便调用DLL(因为有很多硬件要对接),使用JS引擎实现测试的基础功能,使用JSON序列化数据。
Winform+WPF控件实现界面,使用Python将已有的测试用例转换成代码。
最后,实现了测试自动化的同时,允许测试人员对已有的用例进行修改,做到修改用例不用重新编译代码,开发和调试方便。

思考

那么我其实可以通过统一测试用例配置文件格式的方式来做:
例如:
TX(ID=123,Data=[1,2,3,4,5,6,7,8])
WaitForRX(ID=124,Data[3]=0,timeout=5000ms)
或者是
{"TX",123,[1,2,3,4,5,6,7,8]}
{"RX",5000,124,[?,?,?,0,?,?,?,?]}
这种JSON格式的测试用例。最后提供一套测试用例的编辑、转换器,测试的同志就可以开心的使用了。
但是,测试用例里又出现了这一种:
While sending Signal XX in 50 Frame/Second, XXXXXXX
这个时候我决心把常用的API暴露出来,形成一种新的语言,我们不妨称之为CAN控制语言,于是诞生了CAPL,我们给CAPL写了个IDE叫CANOE,成立了Vector公司,现在……
咳咳,扯淡扯远了!
我只是简单的把CAN收发的常用功能和一些IO,以及用户交互封装了一下,然后给了一个外壳,就可以完成各种测试任务了,那么软件剩下的部分其实是上千个测试脚本的管理,这个不复杂嘛,实在不行我们可以直接用Win的文件系统嘛!
测试用例的不确定性导致了我下定决心使用脚本语言解决这个问题,让测试能足够的灵活,配置文件可管理,以后也能向后兼容。

设计

我初步设计,Javascript需要以下基础功能:
1、程序的输出显示
提供了log,print,alert等函数,看名字也知道是干嘛的了
2、程序的输入:
由于C#没有输入框,我单独写了一个InputBox,主要就靠这个输入。其次还提供了confirm函数来输入布尔值。
3、程序的文件和网络IO
使用get函数来获取URL中的数据,同时提供文件的读写和追加写入功能
4、CAN的收发功能
这里需要提供CAN信号的管理,CAN信号的发送和等待收取,以及CAN信号的周期后台发送、停止发送功能。这一部分才是核心。

技术选型采用了C#,.NET 4。
Javascript的引擎是Noesis.javascript,由于不需要太美观,所以使用Winform更加方便一点,再使用ElementHost融合一些WPF的控件,做到要灵活的地方能灵活,定死的地方开发快速。

我对自己的技术选型还是很自信的,总而言之,我认为是做到了严肃活泼的地步。
(但是对自己的界面美观程度很不自信……)
最后IDE大概是这个样子的:

IDE只是其中一个模块,但是是其中最强大功能模块了。

JavaScript和C#的融合

其实我当初想用Python作为融合的脚本语言的,但是考虑到JS引擎小巧,可以带在DLL里跑,最后还是选型了JS。
JS的缺点非常明显,尤其是类型很弱这样的问题,使得开发API的时候一定要吃透JS和C#调用的规律。而且说来惭愧,因为这是测试任务,JS异步的特性在这里没有一点发挥(又跑题了)
我在工程里新建了一个JavascriptEngine类,用来包装一个JS引擎,我这个程序所有的测试用例都只在一个容器中运行,减少开销。
首先Import动态链接库

using Noesis.Javascript;

随后在类里新建一个静态的上下文(Context我也不知道怎么翻译比较好)

static JavascriptContext ctx;

随后在初始化代码中初始化:

static JavaScriptEngine() {
    try {
        ctx = new JavascriptContext();
        //导入函数的js文件
        ctx.SetParameter("$", new JavaScriptUtility());
        runFile("UserLib.js");
    } catch (Exception e) {
        Logger.logError(e);
    }
}

这个时候可以加在一些你自己写的库函数和类,JavaScriptUtility是我写的一个用来承载常用函数的类,因为之前写jquery比较多,比较熟悉$符号,所以沿用了jquery的符号。
这个时候我如果在JavaScriptUtility里新增一个函数:

public class JavaScriptUtility {
    public static void alert(string queryInfo, string title) {
        MessageBox.Show(queryInfo, title, MessageBoxButtons.OK, MessageBoxIcon.Information);
    }
}

这个时候你就可以在引擎中调用这个函数:

ctx.Run("$.alert('Hello noesis.javascript','alert')");

这个时候就可以看到你执行的代码。
如果你想兼容风格,方便移植一些浏览器上写的代码可以这样:

var alert = function(text,title){
    $.alert(text,title);
};

像这样封装一下就好,需要注意的是该引擎不支持胖括号的写法,你可以这么写:

function alert(text,title){
    $.alert(text,title);
};

但是不能这么写:

var alert = (text,title)=>{
    $.alert(text,title);
};

我已经踩过坑了,浏览器上好好的代码,上了Noesis就挂逼了,谁也不知道怎么回事。
顺便说一下类型问题,类型系统还是比较智能的,比如你写了两个函数,第一个是

void fun(object u);

你又重载了一次:

void fun(int u);

这个时候如果你输入数字去调用,会调用第二个,输入字符串就会调用第一个。

总结

对于能固定下来的任务,不要想着使用脚本,使用脚本会增大使用人员的门槛,咱这里已经不讨论效率问题了,效率差100倍我也不惊讶。
需要使用脚本引擎的是,变化大,而且往往以后也不能确定怎么改,而且可能随时要改的任务。
脚本的通用性比较好,但是大多数从事汽车行业的人就算会写CAPL也不一定会JS。
软件的编写,除了考虑个人的奋斗,也要考虑历史的进程啊!

原文地址:https://www.cnblogs.com/TsingJyujing/p/6851580.html