结合案例说明如何解决难以重现的Bug

发表于:2010-5-31 13:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:xilentz(cnblogs)    来源:51Testing软件测试网采编

  这一篇文将结合一个案例谈谈解决随机BUG的一些经验。我这里说的随机BUG是指那些你没法通过一些确定的步骤可靠地重现的BUG。我想做软件开发的人都会同意,即使不是最难,随机BUG应该也是最难解决的BUG类型之一。有人也许说,只要找到问题的根源就一定能可靠地重现问题,不能重现只是因为你还没找到问题的根源。这话也许没错,但也还是存在一些情况,即使找到了问题的根源也没法可靠地重现,比如我碰上的这个就属于这种情况。

  问题是这样的,我们是一家设备制造商,有自己定制的主板,在主板上开发系统软件(Kernel+Drivers),再在系统软件上构建应用软件-这在嵌入式系统开发中是比较典型的一种模式。我们有一款产品使用的平台是StrongArm SA1110+Windows CE 4.1(这在当年是很常见的一种解决方案)。问题出在关机时,有时候屏幕已经黑了,看起来设备已经完全下电,但其实内部主板的电还没掉,这时按开机键没有反应-系统lockup了。结果是只能拔掉AC电源和电池让主板下电然后才能重新开机。恶劣的情况是,如果用户只使用电池供电,而且他没意识到系统处于 lockup状态,过不了多久电量耗尽电池就会报废。

  要找出这个问题,当然必须搞清楚系统挂在了哪里,然后才能寻找对策。因此首先搞清楚系统关机的机制。

  在Windows CE中,关机操作触发后,下电过程由电源管理模块执行,大概是这样:

  1. 广播关机消息给关注该消息的 Application和Driver;

  2. 挂起图形界面子系统(GWES);

  3. 通知所有非块设备驱动(non-block drivers,这些driver可能需要访问注册表或文件因此需要在块设备驱动停止之前处理);

  4. 给 Kernel发送IOCTL_HAL_PRESUSPEND消息(OEM开发商可以利用这一消息做一些关机前处理);

  5. 禁止除电源管理模块以外的所有其他模块使用注册表和文件系统;

  6. 通知所有块设备驱动(block drivers);

  7. 关闭图形子系统;

  8. 关闭文件系统;

  9. 调用OEMPowerOff。OEMPowerOff由OEM厂商实现,执行真正的硬件下电操作。

  Windows CE系统在关机时执行的操作还是挺多的,有必要想办法缩小问题的范围。对付这种情况一种很有效的办法是在相关模块中添加打印语句输出一些调试信息。初步调查很快发现问题出在OEMPowerOff里面,OEMPowerOff是操作系统把一切事情都做完最后调用的函数,执行真正的关机操作,通常会涉及一些 外设的下电和CPU的电源状态的切换。我们这个平台的关机逻辑设计有点儿怪:关机操作在一个CPLD中实现,为防止信号干扰导致的误操作,它监控CPU的两根GPIO管脚,这两根管脚信号符合特定时序时CPLD就执行关机动作。真正需要关机时,OEMPowerOff通过控制这两根GPIO管脚产生特定时序,触发CPLD的关机操作,然后CPLD依次给CPU Core和主板下电。这个设计看起来没什么问题,但是为什么会导致随机lock-up呢?我们百思不得其解。困难的地方在于这个问题极难重现,在大多数情况下关机是很正常的,反复开开关关一天也不见得能重现一次。如果找不到办法重现问题,解决方案当然也就无从谈起-即使你有再好再合理的想法,你甚至都无法验证你的想法正确与否。另一方面,客户的反馈又表明这个问题确实存在,而且随着出货量增加,案例越来越多,不容忽视。

  对付这类随机BUG,我有一些固定的套路。首先一定要想办法把测试自动化,这样可以利用多台机器,24小时进行不间断测试,通过增大样本空间来缩短重现问题的时间。在这个例子中,开机键可以用脉冲信号发生器产生的脉冲模拟,关机动作可以在系统跑起来后运行特定程序来触发。这两个要点解决了,自动测试装置也就建立起来了。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号