当测试人员向开发人员反馈问题时,是否经常听到这么一句:“我的电脑上没有问题”,这在新手口中,更容易听到。
但是为什么他们会这么说呢,究其原因,可能是因为测试人员的电脑上出现的Bug让他束手无措,无计可施,所以只能搬出“我的电脑没问题”这一说辞来推诿,以证明自己的软件没有问题。
为了避免这种情况,我们需要从两方面着手,
1:在测试人员发现问题时能更有效地保存软件出错时的现场环境或软件状态。
2:开发人员应掌握一款轻量级的调试工具,能在测试人员的电脑上进行在线调试,或能离线下调试测试人员保存下来的软件出错状态。
第一方面比较好解决,一般的软件公司都有一套比较完善的Bug提交机制,因此在发现Bug时,可要求测试人员在发现Bug时,保留现场通知开发人员,由开发人员决定是否继续保留现场由他进行在线调试或抓取进程的内存转储文件(dump文件)提交至Bug库进行离线调试。
第二方面则需要开发人员掌握一款轻量级即方便安装的调试工具windbg,这样才方便在测试人员的电脑上安装调试,相比Visual Studio 系列的几百兆的安装程序,Windbg只有十几兆的安装包就显得小巧多了,使用这款工具,可以在软件在线即不重启情况下,调试内核态应用程序(如驱动等)和用户态应用程序(开发人员编写的应用程序),也可在离线模式下调试内存转储文件(dump文件),dump文件记录了软件出错时内存状态,通过分析该文件,我们可以查看进程当时的各线程的调用栈,各调用函数的参数,局部变量,全局变量,堆信息,内存值,临界区,事件,互斥体,句柄等信息,通过这些信息,可以帮助我们能有效地分析内存泄露,死锁,软件崩溃,资源泄漏等软件Bug。调试Dump文件这点尤其有用,因为Dump文件是我们能从用户电脑上获取Bug出错时的软件信息的唯一可供我们调试的资料。
Windbg支持命令行模式,也支持图形界面操作,界面操作及快捷键与Visual Studio很相似,熟悉Visual Studio的朋友可以很快上手,像我这种命令行控的人,更喜欢它的命令行模式。
那么,以下是windbg的运行界面,看看它长咋样的:
再来简单介绍一下它的常用命令:
查看stack:kb, kp, kP
查看变量:dv
搜索内存:s
搜索符号: x
查看内存:dd,da,db
分析死锁:!cs, !lock
自动分析:!analyze
加载dll: .load, .reload
显示加载的模块信息: lm, lmvm
关于windbg的具体使用方法请听下回分解。