“嵌入式软件的可靠性与测试”,看上去就知道是个既有理论深度又有现实价值的课题。看了好几篇论文,大概也知道了测试有哪些最基本的方法,不过对于它的现实价值还不是很清楚,毕竟没有做过多少嵌入式软件,现在的经验认识仅限于,迫不得已,无法保证程序是按照自己预期的过程运转时,才有测试、调试出马,这多半意义上是一种惩罚直到最近帮着一个朋友检查一个涉及PDA平台、RFID 阅读器的程序时,才发现,对于微软做的那套开发平台,Visual C++ 那些变态的东西,对于程序功能的验证,对于实际运行时各种细节情形的考虑,不依赖于测试/调试是没有出路的。
开始时,是一个对读到的RFID标签进行简单的便于可读性的操作,两个程序逻辑:1、忽略已存过的;2、若没有空位,替换掉最老的,否则,存起来。检查了几遍,没有发现问题。忍住没有跳楼,第二天,考虑唯一还没有跟踪过的变量,发现最起头的RFID驱动程序(*.lib)提供的接口函数的返回值不是想象中的“读到的标签数”,而总是30,而这一点,据说“没有说明书说明”。暂不考虑这样一个4000RMB的硬件没有说明这一点让人不可思议,恼火的是这样的程序无法在Embedded Visual C++下面进行在线调试/跟踪,这就很郁闷。估计许多硬件厂商都是只提供windows平台下的驱动程序库的,而windows提供的开发平台又是这么一个鸡肋的样子,那么,唯一的出路就是不断用AfxMessageBox打印数据,然后一遍又一遍的调试。
接着,另一个bug在于,PDA上用多标签页播放时,总是容易出错,切换到了另一个标签,前一个标签的视频/音频还是照旧,没有按照预定的停止播放。同样的,用窗口实时打印变量的值,结果这个窗口函数也不是那么好使的,刚开始设置的参数不能让它打印出来,后来以为是点击标签的事件被底层默认分配给了MediaPlayer,没有交给我们的界面点击事件处理方法,遂在界面初始化中加了一次捕获点击,想要跳过每次对于第一次点击不按照预定程序逻辑走的陷阱,结果,竟然,启动界面后,打印窗口显示连续两次点击都“造反”了,没有按照预定逻辑走。看来,不是事件处理机制的问题。考虑到问题总是处在启动后的第一次点击,遂考虑等待一会儿再操作,结果奇迹般的好了。进一步核实,启动界面后,还需要等待11秒左右,background logic delay=11s,也就是说,windows上看到了界面,并不意味程序就绪了,后台还没有准备好。
从这样一个血淋淋的教训看出来"调不如测“。嵌入式软件的程序逻辑写好了,离运行正常还有很远一段路程,而这,很多时候由于各种限制,比如开发环境的制约,只能依赖于测试给我们提供一些”线索“,积极进行统计归纳,推测出问题所在,才有进一步改进的可能。
补充:5/26:那个系统总算做完了。后面遇上的一个问题是socket进程和WMP控件进程冲突的问题,表现为播放视频时很卡,最后查明是对socket技术的不了解,简单的close操作还不行,socket是一个对象instance,必须调用析构方法才能释放掉所有资源。
先不说这个技术点,就说这个问题是如何查明(indentify)的:替换降解法。通过本地播放,排除WMP控件自身的问题;通过安排线程先后运行,确定问题出在第一个运行的使用socket通信的线程上,没有完全释放资源,但是不确定是该模块的那个部分。这里,不是简单的采用覆盖测试的方法,而是区分系统级逻辑和用户级逻辑,先是抽取用户逻辑,没有问题,而抽取使用socket相关的系统调用按照执行顺序组成一个序列执行时出问题,从而断定。进而改进后,问题消失,并归为知识空白缺陷。