程序员测试能力的培养

今天郭XX测试"操作日志查询"的时候发现该块设计出现了很多问题. 这一块最后的修改是我做的.当初技术经

理张XX要求我把使用DBTRAN操作的分页显示修改成JAVA代码控制。程序改完后，我只是使用默认条件测试了

一下程序，而且还没有详细查看返回的信息是否正确。自我感觉OK后就提交给了技术经理张XX。而实际上这个

模块的修改是否已成功是没有任何保证的。模块本身有很多查询条件，每一个查询条件可以单独成立，也可以相

互之间进行组合，意思就是查询条件的组合会有很多。但是我一个组合也没有测试，更不用说条件测试覆盖率

了．还有就是后台有没有报错也没有测试．今天郭ＸＸ测试的时候就发现后台报错了，还有就是当全部条件选择

上时，查询出来的结果集会有问题．这次又暴露出自己做事不细心的缺点．

　　问题出现后后悔是没有用的，现在最主要的是找到一条让自己不再犯同样错误的解决方案．之所以没有进行

全面测试，是因为测试是一件很无聊的事情，同时对于测试的重要性自己没有足够重视．以前听国际卡的朱ＸＸ

说，他做了一个底层架构，项目经理叫他测试一个月后上线．他说怎么能行，至少要测试三个月，而且自己每天

都在那里加班查看代码，看是否有什么小ＢＵＧ．跟他相比，自己显得实在是太不负责任了．

　　不过我们也可以来分析一下产生这种局面出现的问题．我们项目的测试一直是以手工测试为主，尤其是进行

页面测试的时候．当涉及到多条件查询时，需要不停的在页面中点过来点过去，需要不停的停止和启动服务器．

这种方式很打击人的测试积极性的，每次都想尽快把它做完，觉得ＯＫ了就提交给技术经理．因此有必要对测试

方式进行一些改进，采用一些可以重用的测试方法来减少开发者的操作次数．使用手工测试还存在一个问题就是

技术经理根本就不知道你进行了那几项测试，测试完不完全根本就无从考查．原来是要求每个人写测试报告的，

但是到了后来没有几个人写．如果使用代码测试的话，情况就大大不一样了．有没有进行相应测试，测试完不完

全，看一下测试代码就知道了．这样程序的健壮性基本可以得到保证．

　　下面来讲述一下如何避免出现开头所说的情况了．我一直在寻求快速软件开发的方法，并且一直在想办法提

高自己的开发速度．快速开发导致的后果就是考虑不完全．这跟反应敏捷是一样的，反应敏捷的人大部分都会考

虑不完全．因此严格记录自己的开发时间和测试时间是避免错误局面出现的解决之道．