|
 | 如何成为一个优秀的程序员三 |
| | 稳扎稳打 步步为营
公司有专门的测试组,有一次,测试组的一个同事笑着恭维我说:你写的东西,我一般都很难挑出错,你大概有什么秘密武器吧!我确实有件武器,但一点都不秘密:那就是测试,测试再测试.程序员最重视的工作应该是测试.
很 多人错误地认为测试是软件编写后期的工作,即软件完工之后,再进行测试.我认为测试不但应该融入编写过程中,即每写完一个函数,都要进行测试,甚至在编写 程序之前,我们就必须考虑如何建立一个方便,快捷准确的测试系统.这就像古时候的军队打仗一样,要兵马未动,粮草先行.
测试的基本原则 是:检验软件是否满足规定的需求,确认运行结果是否符合预期结果.它是软件质量的基本保证( oftware quality assurance ).软件工业界喜欢将测试分成五个循序渐进的层次:单元测试,集成测试,确认测试,系统测试,验收测试( http://en.wikipedia.org/wiki/Software_testing ).很多大软件公司也依据这一理论,建立了严格的测试程序.在这里,我不想过多介绍这些测试理论,大家在互联网上可以找到很多这方面的资料.我只想谈谈我 本人在实际编码过程中是如何进行测试的.
一般来说,我每写完一个模块,我就写一个相应的MAIN程序,来测试该模块中的每一个函数.这样做有两个明显的好处:1 模块中的每一个函数的运行结果都得到验证; 2 如果我们能够很方便地写出MAIN程序,也就证明了模块本身具有很好的独立性,事实上也恰恰证明了模块结构的合理性.如果我在写这个MAIN程序的过 程中,遇到很多困难,比方说,我不得不牵扯到其他模块,那么我就会考虑是否我的软件结构不太合理.模块测试结束后,我会把这些小的MAIN程序都保留起 来.一旦我需要对模块进行修改,我再把这些这些小程序拿出来,对修改过的模块进行新一轮的测试.
将许多经过单独测试的模块融入系统之后, 我再对系统进行整体测试.在这个阶段,我的很多同事喜欢立即把产品放到真实的操作环境中去测试.我不太喜欢这样的做法.我以为真实的操作环境中有太多的不 定因数,比方说测试时间的局限,数据本身千变万化等等.在这种情况下,一旦出现问题很难找出原因.我更喜欢,在进入真实操作环境之前,先建立一个模拟环 境.举个例子,我曾经写过这样一个数据处理软件:我从另一个软件中得到很多数据,然后我对这些数据进行一定的加工处理,然后再将处理后的数据传递给另外一 个图形软件,该图形软件最后将数据显示出来.我们可以看到,整个数据处理流程经历了三个软件环节.我写的程序处在第二个环节.如果我立即将程序放到实际操 作环境中去,通过图形软件显示的数据来进行测试.那么我至少会遇到下面两个问题:
1 数据变化很快,我无法确认图形软件中显示的数据是否符合预期结果.
2 即使我能确认图形软件显示的数据有误,但是我还是无法知道问题出在哪个环节.
这 时候,最好的办法就是编写一个测试软件.建立一个可控制的模拟测试系统.我的具体做法是:编写一个简单的测试软件,它的工作是模拟上述数据处理流程中的环 节一和环节三.这样它将一些可控制的模拟数据注入到数据处理软件中,同时它又将得到处理后的数据.最后它对两组数据进行比较,很快就能发现问题所在.也许 有人就要问了,谁能保证你的测试软件没有问题呢?在我看来,这个问题得从两个方面来考虑:
1 相对于被测试的软件,测试程序通常都比较简单,不太容易出错,即使有错,也很容易修改.
2 我们应该尽量用一些高层语言来编写测试程序.我个人最偏爱的语言是:PYTHON.
PYTHON 是一种面向对象、脚本式计算机程序设计语言.它功能强大而完善.很多任务如果用C或C++来写,会很复杂,但转到PYTHON,就十分简单.我认 为,PYTHON是用底层语言工作的程序员进行测试不可缺少的工具.( http://www.python.org/ ).
程序通过了模拟系统的测试后,我们再把它放到真实的操作环境中去.一般来说,我习惯让程序在真实环境中至少运行两到三天.最后才将软件交给测试组.通过这样一个稳扎稳打, 步步为营的测试过程,软件的质量自然有所保证了.
|
|
