关于测试与调试的日子

“嵌入式软件的可靠性与测试”，看上去就知道是个既有理论深度又有现实价值的课题。看了好几篇论文，大概也知道了测试有哪些最基本的方法，不过对于它的现实价值还不是很清楚，毕竟没有做过多少嵌入式软件，现在的经验认识仅限于，迫不得已，无法保证程序是按照自己预期的过程运转时，才有测试、调试出马，这多半意义上是一种惩罚直到最近帮着一个朋友检查一个涉及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相关的系统调用按照执行顺序组成一个序列执行时出问题，从而断定。进而改进后，问题消失，并归为知识空白缺陷。