使用测试列表帮助程序员有效减少BUG

当一个程序员写完代码以后，（这样说其实很空泛，怎样规模的代码呢，暂且认为是一个将要交付的系统功能的代码），并初步测试通过后不要急于提交，应该先自己review一遍，其目的在于检查代码中能够通过肉眼而非Debug就可以发现的问题。比如：

l         定义的变量是不是都用上了，定义了但没有使用的变量显然影响其他人的阅读。更为严重是自己定义的局部变量是不是和某些全局变量同名，如果存在可能使得整个系统出现莫名其妙的问题，而且很难跟踪到。

l         注释是不是都完整了。如果说在编程期间为了一气呵成而没有详细注释的话，这个时候应该补上了，我想其意义大家一定都很清楚了吧。特别的，许多人（包括我自己在内），经常为了省事而将现成的代码直接拷贝过来稍加修改就大功告成。就在内心喜悦的同时却忽略了一个小小的细节就是原来的注释没有改掉。结果拐过头来review的时候却发现摸不着头脑，这都那跟那阿。为了防止被同事甚至领导取笑，相信我，这个时候就好好检查一下吧。

l         该释放的资源是不是还驻留在内存中。这一点对C、VC程序员尤为重要，导致的后果也无需多说，尽量在造成系统崩溃前就解决掉吧。

……

上述的这些都是些鸡毛蒜皮，花不了多少时间也不会立刻引起用户的注意，关键在于功能逻辑是否正确，这个并非静态跟踪所能实现的，程序员也很难怀疑自己犯了怎样的错误。其实把详细设计说明书或者需求分析书（如果两样都没有，呵呵，反正从头到尾都是在裸奔，还有啥好害怕的），拿出来逐项对照着在运行起来的程序上Check一遍，就足以发现绝大部分问题了。但是这个时候，由于每个人的关注点不一样，解决问题的方式也不一样，所以检查的粗细程度也不相同，该怎么办呢。最好是有个书面的东西，这就是所谓的测试列表（Check List）。大概的形式应该如下：

机能名称：XX    制作人：XX                          最终完成日期：XXXX-XX-XX

大项目

中项目

小项目

测试概要

负责人

Check日期

XX窗体(页面)的代码文件XX

有/无

 

 

XX窗体(页面)的SQL脚本文件XX

有/无

 

 

XX窗体(页面)的DLL文件XX

有/无

 

 

XX窗体(页面)

XX子窗体(子页面)

功能XX(如XX明细的计算)

原始明晰数据XXX，计算的结果XXX，所用公式或方法

 

 

…

…

…

…

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

程序员最后往往需要提交许多内容，如源代码文件，使用的SQL脚本文件以及其他脚本文件（视具体情况），编译生成的DLL文件、EXE文件等，稍不注意就会遗留什么，因此就在这张测试列表的开头全部列出来，回头提交时作为条目清单。

之后，就是具体的功能项目的测试结果，这里最好是与需求分析说明书或者详细设计说明书上的内容对应起来，一个小的功能就作为一个测试项，而且当然是越细越好（如果你有充分时间的话）。程序员在撰写该测试列表的同时应该能够发现一些逻辑上的问题或者与原来需求不符的地方，此时应立即停止下一个测试，先将当前发现的BUG修改掉之后再继续。

当测试列表全部完成后，应将源代码连同该测试列表一同交给上级的负责人，上级负责人会对照着测试列表做一次Review。实际上，正是有了这张测试列表，上级Review的时候才有的放矢，将其负担减轻了不少。最终到测试人员甚至客户那里，潜在的BUG已经少了很多，除非需求本身也有问题。

也许有人会问，现在各个公司都在使用各种代码检查工具、管理工具，甚至还遵循怎样的标准规范，谁还会用这样土的办法啊。然而，代码管理工具并不能帮你Debug出逻辑上的错误，代码检查工具也不可能智能到将相互关联的逻辑中存在的错误一一罗列出来，实际许多情况下程序员可能并不会也不愿意花时间去编写那些测试脚本。而那些标准规范呢，呵呵，它阻止不了人们偷懒，而且如果都能够制作出一份完整详细的测试列表不也是在遵循一种规范吗。