Chinaunix首页 | 论坛 | 博客
  • 博客访问: 273667
  • 博文数量: 757
  • 博客积分: 40040
  • 博客等级: 大将
  • 技术积分: 4935
  • 用 户 组: 普通用户
  • 注册时间: 2008-09-09 12:37
文章分类

全部博文(757)

文章存档

2011年(1)

2008年(756)

我的朋友

分类:

2008-09-09 12:44:24


  “没有人喜欢bug。”大多数关于单元测试的文章以这句话开篇。的确,我们都希望代码如设计的那样准确地执行,但是就好像叛逆孩子一样,程序在完成之后产生的行为将难以控制。比那些家长们幸运的是,我们可以运用工具以确保程序达到预期效果。
  
  市面上有很多用于测试,分析以及debug程式的工具,其中以JUnit最为有名。这是一个协助软件工程师,QA(品质监管)工程师测试阶段性代码的平台。几乎每个接触过JUnit的人都对它有强烈的感情:要么喜欢,要么讨厌。主要的抱怨之一是它缺少做复杂场景测试的能力。
  
  通过突破传统模式的思考,这一问题可以得到解决。这篇文章将介绍JUnit如何利用Pisces来实现复杂测试。Pisces是一个开源项目,作为JUnit的扩展,它可以让你写出由一些JUnit测试组成的测试单元,每个测试单元可以以串行或并行的方式运行在一个远程主机上。Pisces可以让你构成、运行复杂场景,并在一个地点协调它们。
  
  JUnit 基础
  
  JUnit中有两个基本对象,TestCase和TestSuite。TestCase通过提供一组方法来实现一系列测试。例如,setup()方法用来在每项测试开始前建立测试所需的测试环境,而teardown()方法用来在测试后销毁该环境。其他的方法都会完成各式各样的任务,例如,在测试中进行性能检测,判断变量是否为null,比较变量以及捕捉异常。
  
  要创建测试程序,需要继承TestCase类,覆写setup和teardown方法,然后添加自己的测试函数,这些函数通常以“test测试名”的形式命名。
  
  下面是一个测试程序的例子:
  public class MyTestCase extends TestCase {
  /**
  * call super constructor with a test name
  * string argument.
  * @param testName the name of the method that
  * should be run.
  */  public MyTestCase(String testName){
  super(testName);
  }
  /**
  * called before every test
  * 在每项测试开始前被调用
  */  protected void setUp() throws Exception {
  initSomething();
  }
  /**
  * called after every test
  * 在测试完成后被调用
  */  protected void tearDown() throws Exception {
  finalizeSomething();
  }
  /**
  * this method tests that ...
  * 这个方法测试……
  */  public void testSomeTest1(){  ...  }
  /**
  * this method tests that ...
  * 这个方法测试……
  */  public void testSomeTest2 (){
  ...
  }
  }
  
  TestSuite是由几个TestCase或其他的TestSuite构成的。你可以很容易的构成一个树形测试,每个测试都由持有另外一些测试的TestSuite来构成。被加入到TestSuite中的测试在一个线程上依次被执行。
  
  ActiveTestSuite是TestSuite的一个子类。被添加到ActiveTestSuite中的测试程序以并行方式执行,每个测试在一个独立的线程上运行。创建一个测试单元的方法之一是继承TestSuite类并覆写suite()方法。
  
  下面是一个简单的例子:
  public class MyTestSuite extends TestSuite {  public static Test suite() {
  TestSuite suite =       new TestSuite("Test suite for ...");
  // add the first test  // 添加第一个测试
  MyTestCase mtc = new MyTestCase("testSomeTest1");
  suite.addTest(mtc);
  // add the second test  // 添加第一个测试
  MyTestCase mtc2 =new MyTestCase("testSomeTest2");
  suite.addTest(mtc2);
  return suite;
  }
  }
  
  运行一个测试或测试单元非常简单,因为从JUnit提供的GUI开始,到所有的IDE开发环境,例如Eclipse,都有GUI可以使用。
  
  图1, 显示了TestSuite在Eclipse中是如何表示的。
  [[The No.1 Picture.]]
  图1,集成在Eclipse中的JUnit
  
  因为介绍JUnit并不是这篇文章的主题,而且有很多关于JUnit的文章,本文就只提供这些JUnit基础概念的概要。在“资源”小节里有对JUnit更深入介绍的文章。
  
  JUnit的优点和缺点
  
  JUnit是一个易用的,灵活的,开源的,测试平台。就像所有其他项目一样,它有很多优点,但也有不足之处。通过使用无需人工干预的JUnit自动测试平台,我们很容易累积起大量的JUnit测试程序从而保证以往的bug不会重现。另外,JUnit便于和编译单元(如,Ant)以及IDE单元(如,Eclipse)集成。
  
  JUnit的弱点也众所周知。它仅支持同步测试,而且不支持重现和其他异步单元。JUnit是一个黑箱测试平台,因此测试那些不会直接影响功能的bug(例如,内存泄漏)就非常困难。除此之外,它不支持易用的脚本语言,因此,想要使用JUnit就要懂得。
  
  JUnit的另一个不足是JUnit测试被限制于一个JVM之上。当要测试复杂或分布式场景的时候,这就变成个大问题。本文剩下的部分,就这个问题及其解决方法进行论述。
  
  复杂场景测试:试复杂的分布式场景?
  
  1. 那些确保小单元的完整性的测试很有用,但同时也有局限性。经验告诉我们,大多数bug是在完整的测试中被发现的。这些问题从两个模块不能一同正常协调工作,到两个独立应用程序的异常。无论这是两个应用服务,还是客户/服务环境,甚至是点对点模式,对这些复杂场景的测试尤其重要,因为那些难缠的bug往往寄生于此。但是用JUnit对此几乎无能为力。
  
  2. 虽然具有平台无关性,但测试一个应用程序在多种操作系统上的表现还是一个明智的选择。你的程序可能在所有的操作系统上都能运行,但是却不一定严格地按照你设计的那样正常工作。在所有的操作系统上重复同样的一组测试程序是一件耗时的工程,而用JUnit你不能进行分布式测试,因此你无法让同样的一组测试同时运行在几个JVM之上,而每个JVM运行在不同的操作系统之上。
  
  3. 一些单元代码,只能在多JVM场景下被测试。例如,测试建立一个连接(TCP socket或者HTTP连接)以及从中取得的信息的完整性。这样的测试不可能(或者说很难)在单一JVM上测试。而这是JUnit给我们的唯一选择。
  
  用Ant协同测试
  
  仅使用JUnit和Ant来协调几个运行在不同JVM上的测试是可能的。Ant可以以并行或者串行的方式执行任务(使用标记),而且可以设置当有任何测试失败的时候,就停止运行。
  
  但这种方法有其局限性,首先,使用JUnit和Ant仍然把你限制在一个操作系统之上。其次,随着你的测试程序的累积,你会发现Ant XML文件会变得越来越大,以至于无法管理。第三,我们发现在某些情况下,分支JVM会在Ant任务结束后保留下来甚至继续运行。
  
  Pisces项目就是为了解决JUnit的这些限制而来的,它给予JUnit复杂场景和分布式测试的能力。本文下面的章节将介绍这个开源项目。
  
  利用Pisces打破JUnit的局限
  
  Pisces基础知识
  
  Pisces是一个开源项目,它扩展了JUnit平台。就像许多其他的扩展程序一样,Pisces添加了新功能的同时也保证了扩展前后JUnit操作的一致性。
  
  Pisces的核心是在同一主机或不同主机上实现在远程JVM上运行JUnit测试的能力。这些远程测试程序会封装在本地运行的JUnit测试程序中,因此开发人员或者QA(品质测试)人员可以用通常的JUnit GUI工具来运行这些通常(本地)的测试程序。用来包装远程测试的对象叫做RemoteTestCase,它也是TestCase册子类。
  
  图2显示的是远程测试程序和它的包装器。
  [[The No.2 Picture.]]
  图2,远程测试和它的包装器
  
  在每一个远端,我们运行一个Pisces代理程序,并指定唯一的代理名。这个代理负责运行实际的JUnit测试程序并将结果返回到本地。现在,一旦我们能运行一个包装在本地测试中的远程测试程序,我们就能通过组合几个这样的测试来创建一个更为复杂的场景。
  [[The No.3 Picture.]]
  图3, 由几个远程测试组成的测试单元
  
  改变默认输出
  
  每个代理运行一组测试程序,而每个测试程序都可能写信息到默认输出。因为保证测试人员或开发人员在测试过程中得到这些信息很重要,所以默认输出被拷贝到本地测试单元的控制台中。这样,便可以避免在测试单元中查看每个代理的控制输出。
  
  Pisces的可扩展通信层
  
  在各个代理及本地主测试程序之间的通信是件复杂的事情,因为Pisces必须能在各种不同的环境以及网络配置下正常工作。为了解决这一问题,Pisces有一个可以扩展的通信层。它的每一个实现解决一个指定的网络环境下的问题。
  
  Pisces提供两个默认的基本通信层,一个是易于配置但只能工作在局域网内的multicast实现,另一个是JMS实现。它需要安装面向消息中间件/消息导向中间件(MOM, Message-Oriented Middleware),可以应付大多数网络环境。
  
  配置并运行Pisces测试
  
  1.配置并运行Pisces代理
  
  正如前面所提到的,Pisces测试单元是由几个运行在远程代理之上的Junit测试程序组成的。每个代理都是一个Java应用程序,它根据从主测试程序接收的指令来运行JUnit测试,并将结果及默认输出返回到主测试单元。
  
  运行代理程序最简单的方式是在Pisces提供的脚本文件夹中配置并运行相关的可执行脚本。此外,你也可以在已经提供的脚本的基础上构建你自己的脚本。脚本文件容许用户配置代理的通用参数,例如唯一标识符,为通
【责编:admin】

--------------------next---------------------

阅读(177) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~