阶段：项目进入到第8个月了，还有1周用来清理后续，就宣告结束这场胜仗了。
投靠阵营：软件测试组；
内部对立阵营：软件开发组；
外部对立阵营：客户。
场景：就在完成了大量重复操作和回归测试之后，以为胜利在望的时候，突然发现程序有不稳定现象。征兆为“退出程序时的内存异常”。有些使用时间长久的WINDOWS操作系统，莫名奇妙就会出现这个懊恼提示。这犹如吃米饭吃到最后一口时，发现里面有石子儿那般破坏快感。由于项目对于程序稳定性没有特殊要求，2个旧版本中的不稳定概率很低，导致这次的意外没有被提早发现。无论如何，作为测试人员，既然“吃石子儿”的好运降临在我的头上，就不能辜负这次机会。
作战方案：的确，采取纯粹的黑盒测试方法，很难捕捉问题的源头。因此这样的硬骨头是很有挑战意义的。还是这样，按照换位思考的方法来综合出一个最合适的解决方案，而非最优秀的解决方法。从客户角度来思考，在不影响功能的状态下，不要出现这个吓唬人的框框就行了；从开发人员的角度思考，在项目末期出现这个故障，是比较头大的，如果不影响主要功能的稳定，想办法让框框消失就可以了，尽量不要大兴土木重新来过；因此，作为测试人员，找到问题的大致方向，给开发人员提供思路，即可。不必刨根问底显示你的“艰苦奋斗”而影响全队的作战士气。
第一阶段：没有规律，没有重现方法。
首先我们知道，这个内存错误提示框，是WINDOWS为了保护硬件而组织程序驻留在非法内存中抛出的。因此，在这个阶段，想要开发人员简单的屏蔽这个框框是不现实的，也是不负责任的。你肚子痛，医生叫你随便吃药，也不告诉你吃的什么药，反正你付钱拿药就行。那还有没有天理呢，呵呵。——不过这个阶段情绪挺差，组合了很多测试用例和方法，依然没有找到任何规律，也不能确定如何才能重现。有至少2天，处于这种状态。
第二阶段：没有规律的重现。
被动防御了2天，战局没有进展，开发人员却给了一个新的版本。在这个版本中关于这个程序异常，可以说没有任何实质性的进展。不过似乎在夹缝中有了转机，这个版本中加强了对最新功能模块的修改，使得使用并关闭程序之后，WINDOWS报错的概率大幅度提高。这样一来，有了2条模糊的思路：1，是否和新功能修改有关；2，是否有内存泄漏。即使如此，出错的规律依旧没有找到。就这样，每天打开内存监视工具，尝试寻找规律。可能医学上的临床观测，也是类似如此吧，哈哈。
第三阶段：寻找资料，逐步沟通。
在网络上搜索内存泄漏的技术资料，并再次熟悉程序架构：C++编程，新功能中外挂了一个DELPHI开发的DLL。在这两种语言编写出来的程序中，前者对于指针的把握问题很普遍，而后者对于程序关闭时的内存回收机制也同样具有很多先例性问题。有了这些资料作为后盾，我对于内存泄漏的猜测有了更足够的信心。跑去和开发人员沟通，次日便得到回复：代码中存在部分导致内存泄漏的错误。逐一修改，得到了新版本的程序再测试。临床检验有了初步诊断，但是仍旧没有摆脱危险。
第四阶段：水落石出。
某一天早晨，开发人员主动过来告之，该新模块中调用的DLL存在关闭程序时回收机制的问题。（不搜不知道，网络上一搜索，资料一大堆）在察看了程序代码之后，可以轻而易举地找到出错规律，并能每次重现。开发人员友好地提供了重现方法，为了新版本的测试而提供方案。这样，我们从第一阶段的毫无头绪到现在的水落石出，终于把症结给捕捉。石头从嘴里吐出，漱漱口再吃一颗口香糖吧。
总结：冷静、整理、规划、沟通、探讨、总结。在合作竞争的环境下，共同努力，促进良性循环，完成工作，增进感情。