研究了几天的代码，今天终于把一个故障定位出来了，却一点成就感也没有，我为我们的过程控制感到悲哀。这是在测试部发生的一个“不可思议”的问题，说它不可思议是因为出问题的模块已经是很老的模块了，这个故障我们还是第一次遇到。

　　从故障发生的现象和现场采集的数据找到了真正的问题。这两天我抛开开发任务，认真的研究了一下代码的逻辑，今天终于发现原来我们的代码里面一个全局数组的使用可能存在越界，没有任何保护措施。这个问题说简单也简单，说难也难。说它简单是因为如果认真阅读代码，分析每一个逻辑分支的话，这个问题是不难发现的，说它难是因为代码的可读性太差，直接影响人的阅读兴趣，很难让人有兴趣去分析它的每一个逻辑分支。但是如果按照软件工程提供的单元测试方法认真进行单元测试的话，这个问题是不难测出来的，所以，前期的单元测试做的肯定不充分。

　　这段代码从产生到现在已经一年半了，测试部已经在几个版本里测试过了，但是这种错误一般很难从现象上表现出来的，所以测试部责任不大。但是即使开发的时候单元测试不充分，这个模块已经有好几个人维护过了，每个人至少都会学习一遍代码，代码走查也做过多次了，但是这个问题也没人发现。这也说明每一个维护人员都没有认真的看代码，只关注代码实现的功能，没有关注代码的逻辑处理，我也不例外，可能跟代码的可读性差有关系。

　　回想这一年来，我已经处理过好几个代码逻辑上的问题了，问题定位都是花费了比较长的时间的，这不是因为我的能力问题，因为不只我一个人参与定位，最后还是我分析代码找出原因的。这些都是可以在单元测试中发现的，单元测试的时候，可能一个测试用例就可以测试出来的。

　　虽然单元测试和代码走查都可能发现这种故障，但是我觉得控制单元测试比控制代码走查更容易一些，因为代码走查还是跟人的因素比较大，但是单元测试只要按照方法做了，人的影响不是很大。

　　我们的项目经理不重视单元测试，也许他们不是真的不重视，但我感觉现实是这样的。开发阶段只有一个联调任务，再加上现在大家还是习惯于任务驱动的，单元测试只是简单的测试自己模块的功能没有问题，单元测试用例的覆盖程度也没有衡量标准。并且每个版本到了联调阶段本来就会延期，进度上的压力，更难做到真正的单元测试了。

　　单元测试差的直接后果就是我们的维护成本相当的高，版本一到测试部，开发人员是需要经常去测试部定位故障的，更为遗憾的是，有些逻辑上隐藏的故障，依靠系统测试是很难发现的，我们的代码一旦商用，故障在网上暴露出来，付出的代价更是不可估计的。

　　单元测试是在开发人员控制代码质量比较好的一个阶段，我们需要重视起来，尽量把故障在开发阶段就消灭掉。