JBuilder 2005单元测试之慨述

非洲不知道什么是食物,欧洲不知道什么是短缺,亚洲不知道什么是自己的看法,拉丁美洲不知道什么是邀请,美国不知道什么是其他国家。

  一个产品只有通过检验才能投放市场,同样的,一个业务类也只有在经验测试后才能保证功能的正确性,以便被其他类或程序调用,否则隐藏其中的Bug就蔓延开了。业务功能点测试是测试人员的职责,但业务类API的正确性必须由开发人员保证。   回忆一下最近你所开发的系统,往往一个最难忘的情节是通宵达旦地毯式搜索某个刁专的Bug,历尽千辛万苦,最终找到并解决了它。查找一个隐藏的Bug往往是踏破铁蹄无觅处,而找到后却是:解决全不费功夫。   造成这尴尬窘局有以下几点原因:   其一是使用增量式测试策略,即先编写功能代码,在模块开发完毕后才回过头来编写测试用例,因为一个功能模块可能包含许多相互关联的类,形成了层层调用,交错复杂的调用网络,一旦发现了Bug,只得查户口似的逐一排查,其艰辛程度可想而知。   其二是使用不正确的测试方法,如在每个类中提供一个main()测试函数,对类中的功能方法进行测试,通过运行类的main()方法查看类功能的正确性。在某种程序上,这或许是一个值得赞扬的工作习惯,但工作方式却不足取。因为每个类都必须单独运行,以执行其测试功能,并由开发人员观察测试的正确性。随着程序规模的扩大,类数目直线上升,原有的类也会发生代码的调整,一些功能点可能就变成了漏网之鱼,变成了茫茫"类"海里的黑户口,将来"违法乱纪"起来就很难监控了。   针对这些传统测试思想的不足,测试先行、频繁测试、自动测试的测试思想被越来越多的开发人员所接受并付诸实践。   测试先行乍听起来有点让人不可思议,一件东西还没有做出来就想着怎么去测试它?仔细分析,这并不荒唐,因为这让你在设计类时,站在调用者的角度去理解类的对外接口,迫使你深入理解类的外在关系,考虑接口的用途,而在具体编写程序时才去具体考虑内部实现细节,这样设计出接口将更易使用,结构也会更趋合理。   频繁测试,即指测试不应当是阶段性的工作,而应当在程序编写过程中不断进行。因为系统中的类之间往往都存在较多的关联关系,当更改了类的功能时,往往会有多个类受到直接或间接的影响。所以你应该频繁测试以及早发现这种因功能、调整而引起的Bug,越早发现错误解决它的代价越小。频繁测试也是XP编程的一个重要环节,XP编程总让人觉得他们注重功能实现而忽视测试,其实他们也非常关注测试,毕竟测试可以使他们尽可能快的稳步前进。   所谓自动测试并不是说有一个工具可以让你像安检器一样,自动测试出你类中的问题。而是指应用一定的测试框架,为每个业务类编写独立的测试用例,类代码调整后,对应的测试用例同步调整。多个测试用例组成一个测试套件一起批量运行,它们就像一个强大的Bug嗅探器,一旦发现Bug就会输出特定的信息报告错误,只要一个测试用例没有通过测试就说明程序中有问题。测试用例中所包含的测试规则完成由你定制,这个测试套件对Bug嗅探的"灵敏度"完全取决于测试用例的测试规则,框架提供编写和运行测试用例的规范性方法。   在编写一个业务类时,需要相应编写对应的测试用例,一开始挺招"惯性定律"抵触的,因为它要求你将创建一个测试用例类,似乎需要更多的工作。但你的付出是会得到加倍回报的,随着软件类规模的增大你会发现,当传统测试方法越来越捉襟见肘,穷于应付时,基于测试框架的测试技术依然"谈笑自如"。当然别人这么说,我们也不应当马上就深信不疑,疑惑永远是值得推崇的科学精神,我们应该通过自己的实践却真真切切地体会这种改进所带来的快乐。

本文JBuilder 2005单元测试之慨述到此结束。笑着活是一辈子,哭着活也是一辈子。反正只要活着就笑着活下去吧。小编再次感谢大家对我们的支持!

您可能有感兴趣的文章
JBuilder2005单元测试体验之测试配置

JBuilder2005单元测试之捆绑多个用例

JBuilder2005单元测试之JUnit框架

JBuilder2005单元测试之创建测试固件

JBuilder2005单元测试之业务类介绍