台架测试发现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.思路不顺代码怎么写都不行,思路顺了,代码就自然而然的就成了。
更多推荐
远程以太网/电源管理台架测试发现bug后自动通知到手机钉钉
发布评论