主页 > 知识库 > JBuilder 2005单元测试之慨述

JBuilder 2005单元测试之慨述

热门标签:Linux服务器 团购网站 服务器配置 银行业务 阿里云 Mysql连接数设置 电子围栏 科大讯飞语音识别系统

  一个产品只有通过检验才能投放市场,同样的,一个业务类也只有在经验测试后才能保证功能的正确性,以便被其他类或程序调用,否则隐藏其中的Bug就蔓延开了。业务功能点测试是测试人员的职责,但业务类API的正确性必须由开发人员保证。

  回忆一下最近你所开发的系统,往往一个最难忘的情节是通宵达旦地毯式搜索某个刁专的Bug,历尽千辛万苦,最终找到并解决了它。查找一个隐藏的Bug往往是踏破铁蹄无觅处,而找到后却是:解决全不费功夫。

  造成这尴尬窘局有以下几点原因:

  其一是使用增量式测试策略,即先编写功能代码,在模块开发完毕后才回过头来编写测试用例,因为一个功能模块可能包含许多相互关联的类,形成了层层调用,交错复杂的调用网络,一旦发现了Bug,只得查户口似的逐一排查,其艰辛程度可想而知。

  其二是使用不正确的测试方法,如在每个类中提供一个main()测试函数,对类中的功能方法进行测试,通过运行类的main()方法查看类功能的正确性。在某种程序上,这或许是一个值得赞扬的工作习惯,但工作方式却不足取。因为每个类都必须单独运行,以执行其测试功能,并由开发人员观察测试的正确性。随着程序规模的扩大,类数目直线上升,原有的类也会发生代码的调整,一些功能点可能就变成了漏网之鱼,变成了茫茫"类"海里的黑户口,将来"违法乱纪"起来就很难监控了。

  针对这些传统测试思想的不足,测试先行、频繁测试、自动测试的测试思想被越来越多的开发人员所接受并付诸实践。

  测试先行乍听起来有点让人不可思议,一件东西还没有做出来就想着怎么去测试它?仔细分析,这并不荒唐,因为这让你在设计类时,站在调用者的角度去理解类的对外接口,迫使你深入理解类的外在关系,考虑接口的用途,而在具体编写程序时才去具体考虑内部实现细节,这样设计出接口将更易使用,结构也会更趋合理。

  频繁测试,即指测试不应当是阶段性的工作,而应当在程序编写过程中不断进行。因为系统中的类之间往往都存在较多的关联关系,当更改了类的功能时,往往会有多个类受到直接或间接的影响。所以你应该频繁测试以及早发现这种因功能、调整而引起的Bug,越早发现错误解决它的代价越小。频繁测试也是XP编程的一个重要环节,XP编程总让人觉得他们注重功能实现而忽视测试,其实他们也非常关注测试,毕竟测试可以使他们尽可能快的稳步前进。

  所谓自动测试并不是说有一个工具可以让你像安检器一样,自动测试出你类中的问题。而是指应用一定的测试框架,为每个业务类编写独立的测试用例,类代码调整后,对应的测试用例同步调整。多个测试用例组成一个测试套件一起批量运行,它们就像一个强大的Bug嗅探器,一旦发现Bug就会输出特定的信息报告错误,只要一个测试用例没有通过测试就说明程序中有问题。测试用例中所包含的测试规则完成由你定制,这个测试套件对Bug嗅探的"灵敏度"完全取决于测试用例的测试规则,框架提供编写和运行测试用例的规范性方法。

  在编写一个业务类时,需要相应编写对应的测试用例,一开始挺招"惯性定律"抵触的,因为它要求你将创建一个测试用例类,似乎需要更多的工作。但你的付出是会得到加倍回报的,随着软件类规模的增大你会发现,当传统测试方法越来越捉襟见肘,穷于应付时,基于测试框架的测试技术依然"谈笑自如"。当然别人这么说,我们也不应当马上就深信不疑,疑惑永远是值得推崇的科学精神,我们应该通过自己的实践却真真切切地体会这种改进所带来的快乐。

标签:江苏 衢州 衡水 萍乡 蚌埠 广元 枣庄 大理

巨人网络通讯声明:本文标题《JBuilder 2005单元测试之慨述》,本文关键词  ;如发现本文内容存在版权问题,烦请提供相关信息告之我们,我们将及时沟通与处理。本站内容系统采集于网络,涉及言论、版权与本站无关。
  • 相关文章
  • 收缩
    • 微信客服
    • 微信二维码
    • 电话咨询

    • 400-1100-266