首页 >> 新闻 >> 科技 >> 互联网 >> 正文
  • ZStack——自动化测试系统1:集成测试

  • 时间:2018-03-05 新闻来源: 北京热线
    •     测试,对于一个IaaS软件的可靠性、成熟度和可维护性而言,是一个重要的因素.测试在ZStack中是全自动的。这个自动化测试系统包括了三个部分:集成测试,系统测试,基于模块的测试。其中集成测试构建于Junit之上,使用了模拟器。通过这个集成测试系统提供的各种各样的功能,开发人员可以快速的写出测试用例,用于验证一个新特性或者一个缺陷修复。

          概述
          这个关键因素,在构建一个可靠的、成熟的和可维护的软件产品中,就是架构;这是我们自始自终相信的设计原则。ZStack已经付出了大量的努力,以设计这么一个架构:始终保持软件稳定,无论是添加新特性,常规的操作错误,还是为特殊目的裁剪;我们之前的文章:ZStack—进程内微服务架构、ZStack—通用插件系统、ZStack—工作流引擎、ZStack—标签系统,已经表现了我们的一些尝试。然而,我们也充分理解测试在软件开发中的重要性。ZStack,从第一天开始,设定了这么一个目标:每一个特性都必须有测试用例保证,测试必须是全部自动化的,写单元测试应该是验证一个新特性或任何代码改变的唯一方式。
       
          为了实现这个目标,我们把我们的测试系统分成了三个组件:集成测试,系统测试,模块测试。分类方式是通过它们的关注点和功能。
          l  集成测试系统构建于Junit,全部使用模拟器;测试用例存放在ZStack的Java源代码中;开发人员可以轻松地使用常规的Junit命令来启动测试套件。
          l  系统测试系统是一个独立的Python项目,称之为zstack-woodpecker,基于ZStack的API;在一个真实的硬件环境中测试一切。
          l  基于模块的测试系统构建于基于模块的测试这么一个理论,是zstack-woodpecker中的一个子项目。这个系统中的测试用例将会持续地,以随机的方式,执行API,直到一些预定义的条件被满足。
          从这篇文章开始,我们将会有一系列的,共计三篇文章,来详细阐述我们的测试架构,以向你展示我们保证ZStack每一个特性的方式。
       
          单元测试的几句话
       
          好奇的读者可能已经在他们的心中问了这么一个问题,为什么我们没有提到单元测试,这么一个可能是最著名的,也是每一个冷静的测试驱动的开发人员会强调的测试概念。我们确实有单元测试。如果你看到了后续的章节:测试框架,你可能会困惑,为什么用在命令中的命名类似于:UnitTest balabala,但在这篇文章中被命名为集成测试。
          一开始,我们认为我们的测试就是单元测试,因为每一个用例都是用于验证一个独立的组件,而不是整个软件;例如,这么一个用例:TestCreateZone,只测试Zone服务,其他的组件,像VM服务、存储服务将甚至不会被加载。然而,我们做测试的方式确实和传统的单元测试概念有所不同,传统的方式是测试一小段代码,通常是针对内部结构的白盒测试,使用mock和stub的方法论。当前的ZStack有大概120个测试用例满足这个定义,而剩下的500多个并不。大多数的测试用例,甚至关注于独立服务或组件的,都更像集成测试用例,因为会加载多个依赖的服务、组件用以执行一个测试活动。
          另一方面,我们大多数的,基于模拟器的测试用例,都实际上在API层面进行测试,这对单元测试的定义而言,这就是倾向于集成测试的黑盒测试。基于这些事实,我们最终改变了我们的主意,我们将要做的是集成测试,不过保留了大量的旧的命名方式,类似UnitTest balabla。
          集成测试
          从我们先前的经验中,我们深刻地意识到,开发人员持续忽视测试的一个主要原因是:写测试太难了,有的时候甚至比实现一个特性还要难。当我们设计这个集成测试系统的时候,一个反复考虑的地方便是尽可能地从开发人员那边卸下负担,让系统自身做绝大多数无聊、繁杂的工作。
          对于几乎所有的测试用例而言,有两种重复性的工作。其中一个是准备一个最小的但是可以工作的软件;例如,为了测试一个zone,你只需要核心的库和zone服务被加载,没有必要加载其他的服务,因为我们不需要它们。另一个是准备环境;例如,一个测试VM创建的用例,会需要这么一个环境,有一个zone、一个cluster、一个host、存储、网络和所有的其他必须的资源准备就绪;开发人员不会想去重复无聊的事情,像创建一个zone,添加一个host,在他们能够真正开始测试自己的东西之前;理想的情况是,他们可以以最小的努力便获得一个准备就绪的环境,以集中精力与他们想测试的东西。
          组件加载器
          我们解决了所有的这些问题,通过一个构建于JUnit之上的框架。在一切开始之前,由于ZStack通过使用Spring管理着所有的组件,我们创建了一个BeanConstruct,这样测试人员可以按需指定他们想要加载的组件:
       
          在上面这个例子中,我们添加了三个Spring配置到BeanConstructor,它们的名字暗示了将会为账户服务、zone服务和其他包括在PortalForUnitTest.xml中的库加载组件。通过这种方式,测试人员可以把软件定制成一个最小的尺寸,仅包含需要的组件,以便加速测试过程和使东西易于调试。
           环境部署器
          为了帮助测试人员准备一个环境,包含将被测试的活动的所有必须依赖,我们创建了一个部署器,可以读取一个XML配置文件以部署一个完整的模拟器环境:
          在上面这个TestCreateVm的用例中,部署器读取了一个配置文件,存放在deployerXml/vm/TestCreateVm.xml,然后部署了一个完整的,准备好创建新的VM的环境;更进一步,我们事实上让部署器创建了这个VM,正如你并没有在test方法看到任何代码调用api.createVmByFullConfig();测试人员真正做的事情是,验证这个VM是否按照我们在deployerXml/vm/TestCreateVm.xml中指定的条件正确地创建。现在你看到了这一切是多么的容易了,测试人员只写了大概60行代码,然后将一个IaaS软件中最重要的部分——创建VM,测试好。
          这个在上面例子中的配置文件TestCreateVm.xml看起来像:
       
       
       
          模拟器
          大多数集成测试用例都构建于模拟器之上;每一个资源,只要它需要和后端设备通信,都有一个模拟器实现;例如,KVM模拟器,虚拟路由虚拟机的模拟器,NFS主存储的模拟器。因为现在的资源后端都是基于Python的HTTP服务器,大多数模拟器通过嵌入了HTTP服务器的Apache Tomcat被构建。KVM模拟器的一小段代码看起来像:
          每一个模拟器都有一个配置对象,像KVMSimulatorConfig,可以被测试人员用于控制模拟器的行为。
          测试框架
          由于所有的测试用例都事实上是Junit测试用例,测试人员可以使用通常的Junit命令单独地跑每一个测试用例,例如:
      [root@localhost test]# mvn test -Dtest=TestAddImage
          而且一个测试套件中的所有用例可以用一条命令执行,例如:
      [root@localhost test]# mvn test -Dtest=UnitTestSuite
          用例也可以在一个组里被执行,例如:
      [root@localhost test]# mvn test -Dtest=UnitTestSuite -Dconfig=unitTestSuiteXml/eip.xml
      一个XML配置文件列出了一个组里的用例,比如,上面的eip.xml看起来像:
          多个用例也可以在一条命令中执行,只要填充它们的名字,例如:
      [root@localhost test]# mvn test -Dtest=UnitTestSuite -Dcases=TestAddImage,TestCreateTemplateFromRootVolume,TestCreateDataVolume
          总结
          在这篇文章中,我们引入了ZStack自动化测试系统的第一部分——集成测试。通过它,开发人员可以以100%的信心写代码。而且写测试用例也不再是一个令人气馁和无聊的任务;开发人与可以以少于100行的代码来完成大多数的用例,这是非常容易和有效率的。

       

      网站首页 | 关于我们 | 联系方式 | 招聘信息 | 版权声明 | 网站地图 | 北京热线
      地址:北京市海淀区永泰园14号楼 投稿QQ:1914290061 投稿邮箱:bjrenews@126.com
      Copyright © 2010 www.bjrxnews.com Inc. All Rights Reserved. 北京热线 版权所有