远程以太网/电源管理台架测试发现bug后自动通知到手机钉钉

台架测试发现bug后自动通知到手机钉钉"/>

远程以太网/电源管理台架测试发现bug后自动通知到手机钉钉

前述：从空间能看到这个草稿版,从有这个想法，到完全实现这个想法，总用时将近1个月。草稿是在完成了80%的重要工作时写的。今天就详细介绍这个工程是怎么实现的。17681826077WGM

一、实现这个功能的整体思路和要掌握的知识
（1）前篇文章完已经成了python控制CANoe实现自动化测试。那么python能控制钉钉么？答案是可以的。
那么如果用python一边控制钉钉，一边控制台架自动化测试，当台架发现问题，直接通知到钉钉是否可行呢？
这是当时的想法，也是思路。

（2）要实践这个思路必须要懂以下知识，那里不懂了就问“百度” ， 1.要学会python控制钉钉。2.要学会python控制CANoe，3.要将1和2的知识进行融汇贯通。4.关于细节部分要学会CAPL脚本如何监测频繁linkdown，如何监测在一个测试周期（休眠唤醒-唤醒到休眠）内SomeIP无法建立问题。如何监测bufoff，如何监测dut不休眠。最难的是监测到以上问题后，如何与钉钉关联，要做到发现一次问题，只推送一条对应的具体问题消息到钉钉。做到不频繁推送，不误触发，才是这个工程最耗时间、精力的地方。

二、实现这个功能的关键技术和疑难细节问题处理
（1）在CAPL里周期性监测以下几类问题
tex0 = “远程测试+请注意发现了太网频繁linkdown的bug”
tex1 = “远程测试+请注意发现了someip无法建立的的bug”
tex2 = “远程测试+请注意发现了DUT不休眠的bug”
tex3 = “远程测试+请注意发现了busoff的bug”
tex4 = “远程测试+请注意发现了远程控制失败的bug”
tex5 = “远程测试+请注意发现了休眠唤醒后DUT起不来的bug”
发现这类问题之后，去改变某一个信号值（关键技术1），例如信号名字为systembug， 当发现问题类型为tex0时，则systembug=0，并发送1帧CAN信号；当发现问题类型为tex1时则systembug=1，并发送1帧CAN信号，依次类推。
切记：发送完systembug=0时，一定要等待一定时长（这个时长与是否会频繁推送息息相关）并将systembug进行复位成F。
python通过（关键技术2）systembug=app.get_SigVal(channel_num=1, msg_name=“xxx”, sig_name=“xxx”, bus_type=“CAN”) #直接获取信号 systembug,
然后对systembug做if判断：

if systembug==0: #发生了频繁linkdown对应tex0tex=tex0message ={"msgtype": "text","text": {"content": tex},"at": {"isAtAll": True}}message_json = json.dumps(message)info = requests.post(url=webhook,data=message_json,headers=header)

(2)细节问题处理
其一、细节问题主要在CAPL里，python监测的while not msvcrt.kbhit()循环函数，有个特点就是当systembug信号停止发送，其仍旧以最后依次的systembug值，进行循环判断，所以必须要对systembug值复位。
其二、例如一个测试周期，如果出现m次linkdown是正常的，而实际出现次数为n ，if(出现次数n>m){。。。。。。。这里面最后一定要将n=0}，其目的是能正常进入下一轮监测。

语言--CAPL--
on timer linkdown// 与 python 对接关键函数   
{if(n>m)//    { output(systembug=0);delay(1);//经验所得延时1s发送钉钉1次，这个非常关键output(systembug=F);//切记发完后要进行复位}m=0;setTimer(linkdown,1000);   //设置监测周期 
}

三、总结感言
1.能想通，一般就能行的通，
2.整体大思路理顺了，具体的小思路就好开展了。
3.思路不顺代码怎么写都不行，思路顺了，代码就自然而然的就成了。