把测试方法分为黑盒、灰盒、白盒，主要是根据软件代码的能见度进行划分，而项目的测试过程是一个复杂的过程。除了会用到不同的方法外，还会涉及软件的一些特性测试，对于这些特性，需“专事专办”，走“绿色通道”，效率方可凸显。这些特性与软件的应用领域或市场需求有关，不同的软件会需要不同的特性测试，如内存泄漏测试、软件性能测试、数据兼容性测试等。下面以最让软件开发与测试人员头痛而又常被忽略的内存测试为例进行介绍。

　　内存泄漏（Memory Leak），特别是那种潜伏在代码深处的内存泄漏问题，无论对开发人员还是测试人员都是最为痛心疾首，解决起来或重现起来最为棘手的问题。有一些软件对内存使用的要求特别高，例如嵌入式软件，由于设备本身的内存资源有限，对内存分配与释放的及时性需做出快速响应。否则即使是小块的内存碎片，也可能在“日积月累”后的某一天时间里，设备突然不工作了，或工作得犹如蜗牛爬行，甚至崩溃。内存问题都可归为严重问题（即使有些代码看上去只是使用了几个字节的内存块没有释放而已）。正如“内存问题无小事，一旦发作就要命”。下面是一个内存慢泄漏案例。

　　【案例】原来是内存慢泄漏

　　某市某三甲医院的检验科设备一天到晚总是那么忙，不仅医生忙，连检验设备也很忙。据某医生说，检验室的一台微生物精密检测仪已连续工作有一个多月了。好像有人性一样，这些天感觉测量速度有点慢，而今天甚至干脆就停下来了。软件界面点击无反应，好像是死机了，正等着维护人员来维修。

　　问题很快反映到了仪器的软件研发部门。尽管维护人员已收集了一些现场信息，包括软件停止界面图片、当前测量数据等，开发与测试人员在接到反馈后也马上组成解决小组，分析、调试软件，重现问题等，但历经近一周时间的努力，仍无结果。不过开发人员在分析过程中提到几个疑点，其中之一就是内存泄漏问题，但奇怪的是，在挂上了内存监测工具后，连续测量无发现有内存泄漏的丝毫痕迹。后来为证实是否存在内存慢泄漏的问题，解决小组采取了压力测试的方案。加快测量的时间，让在医院里工作一个多月的软件测量次数增加，最后发现当测量次数达到1000次后，发现存在1KB左右的内存消耗增长，相当于医院做两天的样本测量。最后证实，问题的确实是内存的慢泄漏引起的。由于该医院使用仪器长期没关过机，最终把此问题暴露了出来，而在每天都进行关机的医院中，此问题始终没有发生过。

　　上面案例中关于内存泄漏的问题，可见其影响的严重性及在后期解决的代价。有了前车之鉴，这样的问题是否可以在研发前期就发现呢，回答当然是肯定的。不过，据笔者调查，有不少公司常会出现这样一种现象，当测试负责人提出进行专人专项的内存测试时，常会遇到一大部分人的反对，理由是测试人员从来没有提过这方面的Bug，产品卖了几年，也没收到用户在这方面有不良的反馈，软件在内存使用方面应该还是可信的。这是典型的侥幸心理，究其原因还是公司领导层对软件质量的重视不足，这也正是为什么国产软件的质量还远远落后于国外的主要原因。