本文主要是介绍运用GDB进行UT/ST的小经验，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本文转载至：http://blog.oasisfeng.com/2007/05/29/using-gdb-for-ut-and-st/
转载说明：这个观点比较有意思，好处是可能很快就搭好测试环境。但是只是适合于用户空间的应用，对应内核模块就不行了，也有可能可以通过QEMU+gdb来实现。
用惯了VC/Eclipse图形化的程序调试界面后，要适应GDB这种“回归淳朴”的命令行方式，确实需要一些时间。不过当你熟悉了GDB的高级用法后，才能真正体会到程序调试那种随心所欲，尽在掌握的酣畅感。
最近一段时间用GDB作代码测试，积累了一些小小经验，希望对尚未熟悉GDB的朋友有所帮助。（本文以C语言为例说明相应的用法，其它语言可参考GDB帮助文档中对其的支持说明）
业界比较专业的UT（Unit Test，单元测试）工具很多，所以通常不必直接用GDB进行UT，但使用这些专业工具前往往需要花大力气配置环境，编译驱动等，若对于一个小项目，则比直接使用GDB作UT麻烦多了。所以，小项目往往可以借助GDB进行UT/ST合一的测试，效率提升是非常可观的。
ST（System Test，系统测试）一般需要尽可能的逼近实际运行环境，所以应尽量避免或减少对代码有直接介入的工具。这时以GDB作为测试/调试手段就非常实用了。
下面就几个UT/ST中使用频率最多的场景介绍一些GDB的使用经验：
- 函数测试
这在UT中使用最多，同时也是部分ST用例的入口。GDB中可以在Ctrl+C暂停程序执行后，使用call命令调用程序中的任何函数，使用方法与被测程序语言的语法一致，如：
call foo(5, “Hello!”)
函数执行的上下文比较特殊，栈空间是GDB临时分配的特殊内存区域，进程空间与被测函数相同，但与任何具体线程无关。如果使用call进行UT，则你会发现GDB的断点设置对call所调用的函数无效，这是GDB的一个默认保护：任何命令涉及的表达式（函数调用同样被视作表达式）都不受断点影响。为了顺利进行UT，我们必须手动修改这一默认设置：
set debug expression 1
这样就可以break在被call所调用的函数中了。
Tip：如果函数中使用了类printf的输出函数，那么可能在call之后看不到任何输出，那是由于标准输出的缓冲造成的，只需简单的c (continue)一次就可以观察到输出了。
- 简单的函数桩
UT中对函数进行打桩是一件非常麻烦的事情，对于小项目，往往会浪费大量的精力。其实，通过GDB，我们可以变相的实现简单的函数桩，且较为便捷。
基本思路就是在需要打桩的函数上设置断点，待进入函数后，根据对函数的打桩需求，可以分别采取如下措施：
（1）直接返回：用GDB的return命令强制返回即可，如果有返回值，直接跟在return后面即可，如：
return 5
（2）执行函数的部分逻辑：这需要借助GDB的执行路径篡改功能。
“jump <行号>”直接跳至对应的代码行继续执行，也可以用“jump *<地址>”跳转到机器指令地址。（题外话：在x86开发环境下，即使像VC这种不支持“执行路径篡改”功能的调试器，也可以通过直接修改寄存器PC的值达到跳转的目的）
- 临时数据的构造
在测试一些包含复杂数据类型的代码时，常常需要构造一些复杂结构的临时数据，通常简单易行的办法是直接分配一块临时内存，如：（假设SOME_TYPE是某种复杂数据类型，如typedef的struct、union、enum等）
set $temp = ({SOME_TYPE *} malloc(sizeof(SOME_TYPE)))
然后为临时变量$temp填充相应的数据：
set $temp->some_field = 7
最后将其用作普通的数据参与测试：（假设foo()函数接收SOME_TYPE *类型的参数）
call foo($temp)
GDB强大的调试功能尚远不止如此，充分运用这些高级特性可以大大节省程序调试的时间，并且达到一些常常在你意料之外的效果。欢迎各位朋友就这方面的话题进行探讨！
这篇关于运用GDB进行UT/ST的小经验的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
