在做 C/C++test 动态测试时，C/C++ test内存检查怎么开启，C/C++ test内存检查结果异常怎么判断 经常会和单元测试、应用监控、目标板运行放在一起看。内存检查不是普通静态规则扫描，它需要把程序编译成带监控能力的测试程序或应用程序，再在运行过程中捕捉内存访问问题。

　　一、C/C++test内存检查怎么开启

　　在开启内存检查前，作者需要先把两件事分清楚，那就是检查“函数测试时的内存问题”，还是“整个软件运行时的内存问题”，因为前者主要用来测单个函数，后者则是用在系统组装或者板子上运行的场景。

　　1、使用带Memory Monitoring的测试配置

　　使用者先进入【Parasoft】的【Test Configurations】界面，在自带的那些配置里面，可以去寻找写着Memory Monitoring的选项。

在测单个函数的时候，【Run Unit Tests with Memory Monitoring】这个配置就可以拿来用，它会把已有的测试跑一遍，内存问题的数据就会被收集到。

如果是测整个软件，【Build Application with Memory Monitoring】或者【Build and Run Application with Memory Monitoring】这两个配置也是可以选的，前者主要用来做出带监控的软件，后者在做完之后还会把软件跑起来，从而把结果收上来。

　　2、确认运行环境和目标平台

　　如果是在普通电脑上运行，配置起来就没那么复杂，编译器、运行参数、报告存放的路径、还有输入的数据是需要重点检查的；但要是换成嵌入式项目，板子、调试器、通信的办法、还有运行的目录就都需要注意了。像QNX的软件监控配置，里面就必须把目标电脑的地址、在板子上运行的目录、还有用户名等内容写清楚；TRACE32的场景也准备了【Run Application with Memory Monitoring using TRACE32】这个配置，使用者也得把它复制出来，再根据调试器的环境去一点点调整。

　　3、运行测试并收集结果

　　等这些配置都弄好以后，把要测的工程、模块或者用例选中，再把对应的Memory Monitoring配置跑起来就行了；那些监控软件的配置，通常会自动把下面这几个动作做完：把带监控的程序编出来、把程序传过去或者启动起来、把测试场景跑一遍、最后把运行的结果收回来。有一些嵌入式的模版，还会通过scp、rsh、调试器里的脚本、串口或者板子里的文件系统，把得到的结果传回到电脑上。

　　二、C/C++test内存检查结果异常怎么判断

　　当内存检查的结果出现异常时，只去看“报错有几条”是不行的，问题的种类、报错的调用栈、触发时的路径、能不能重复出现、还有这个结果是不是因为测试环境没弄好才产生的，这些才是更重要的东西；利用C/C++test的软件监控，可以把越界读、空指针访问、没初始化就读取等问题找出来，而且它还会把调用的轨迹给出来，方便去查问题是从哪里来的。

　　1、先看异常类型

　　内存检查能发现的常见异常，大致可以分成下面这几个种类：

(1)  内存泄漏

(2)  越界访问

(3)  空指针或非法指针访问

(4)  未初始化内存读取

　　2、再看调用栈和触发路径

　　在内存检查的报告里面，如果看到了call trace，只盯着最后一行看是不行的；最后一行往往只是发生死机或者报错的地方，但是真正的原因，很有可能在前面更早的申请、释放、赋值或者传参数的地方就已经产生了。

　　3、区分真实缺陷和环境问题

　　内存检查的结果出了异常，也有可能是因为测试环境配置得不完整导致的；比方说runtime library没有和板子的平台对上，链接脚本里面没有把监控数据的地方留够，板子里的结果文件没有完整地传回来，或者是软件没有正常退出来，导致工具根本没有机会去把结果汇总起来。

　　三、内存检查异常结果怎么处理更稳

　　内存的问题最让人头疼的就是“表面上看起来修好了，实际上没修干净”；在处理的时候，要把复现的条件留好，先把根本原因修掉，再通过复扫去验证，不能简单地把异常当成误报给屏蔽掉。

　　1、泄漏问题看所有返回路径

　　内存泄漏通常不是因为主流程忘了去释放，而是被某个异常的返回分支给漏掉了。

如果是更复杂的C代码，可以考虑用统一的出口来处理；如果是C++代码，则可以先考虑用RAII的办法，把资源交给对象的生命周期去管。这样在复扫的时候表现会更稳定，以后要是加了新的分支，也不容易再次发生泄漏。

　　2、越界问题看长度来源

　　遇到越界访问的时候，不能光去改下标；要往前去查长度是从哪里拿到的，是外面输入进来的、协议里的字段、配置表、还是数组自己本来的大小。很多越界的问题，原因都是“长度变量”和“实际缓冲区的大小”根本就不是一回事。这样去修代码，不只是为了让内存检查的结果通过，也是为了把输入的边界给补上去。

　　3、复扫时保持相同测试条件

　　把代码修好以后是需要复扫的，但是复扫的条件要尽量和报错的时候一模一样；测试用的数据、运行的参数、板子的版本、编译时的选项、还有Memory Monitoring的配置，这些全部都要保持一致。要不然的话，这次虽然没报错，也不一定能证明问题真的修好了，也有可能只是程序没有走到同一条路线上。

　　总结

　　要把C/C++test的内存检查开启，关键地方就是把写着Memory Monitoring的测试配置选对，并且让程序在真实的或者接近真实的环境里面跑起来；测单个函数可以用【Run Unit Tests with Memory Monitoring】，测整个软件可以用【Build Application with Memory Monitoring】或者【Build and Run Application with Memory Monitoring】。如果是嵌入式项目，板子、调试器、runtime library、通信的方式、还有结果传回的路径，这些都是要去检查的。