OSGI组件自动化测试的一种方案

素颜马尾好姑娘i 2022-02-03 07:21 288阅读 0赞

**1. 背景介绍**

OSGi称做Java语言的动态模块系统，它为模块化应用的开发定义了一个基础架构。在产品设计中，OSGI是一种规范或者是一种基础结构，以OSGI的形式设计出产品的工作单元。在企业实际的应用中，也会采用spring DM框架来开发OSGI程序，通过maven管理OSGI组件的结构，并且也有多样的设计模式。  
本文在介绍OSGI，maven，spring DM的基础上，引入pax-exam对组件进行代码级自动化case的实施方案，并且就其中的优点与不足展开讨论

**2. 基础知识**

**2.1 OSGI**

**2.1.1 什么是OSGI**

OSGi(JSR 291)亦称做Java语言的动态模块系统，它为模块化应用的开发定义了一个基础架构。简单的说，通过OSGi可以在后台对设备组件进行安装、升级或卸载而无需打断该设备的正常运行.  
OSGi规范的核心组件是OSGi框架。这个框架为bundle提供了一个标准环境。整个框架可以划分为一些层次：  
L0：运行环境——是Java环境的规范  
L1：模块——模块层定义类的装载策略，OSGi模块层为一个模块增加了私有类同时有可控模块间链接  
L2：生命周期管理——增加了能够被动态安装、开启、关闭、更新和卸载的bundles  
L3：服务注册——服务注册提供了一个面向bundles的考虑到动态性的协作模型。  
  
**2.1.2 OSGI的特点**

1. 模块化  
在实际产品设计中，各种模块化设计各有特色，OSGI针对模块化提出一个标准，期望能形成一个市场规范。模块化的具体体现就是bundle的形式，bundle是osgi的部署单元，以jar包的形式封装业务逻辑，对外提供可使用的类，在代码复用、重构方面更有优势。  
2. 动态性  
bundle的状态有installed，resolved，active三种。这几个状态的含义可理解为：install是bundle能被正确编译，编译完毕之后被OSGI容器解析正常后为resolved，在容器内启动后为active状态，如下图：

[![220719273.jpg][]][220719273.jpg]

Bundle的启动、卸载可以在服务运行时进行，这便是它的动态性。

**2.1.3 OSGI的classloader**

Osgi容器为bundle创建classloader，每一个bundle都有独立的classloader，class loader之间形成一个依赖关系图：

[![220728714.jpg][]][220728714.jpg]

在实际运行环境中，Bundle 的 Class Loader 根据如下规则去搜索类资源。规则简要介绍如下：  
1. 如类资源属于 java.\* 包，则将加载请求委托给父加载器；  
2. 如类资源定义在 OSGi 框架中启动委托列表（org.osgi.framework.bootdelegation）中，则将加载请求委托给父加载器；  
3. 如类资源属于在 Import-Package 中定义的包，则框架通过 Class Loader 依赖关系图找到导出此包的 Bundle 的 Class Loader，并将加载请求委托给此 Class Loader ；  
4. 如类资源属于在 Require-Bundle 中定义的 Bundle，则框架通过 Class Loader 依赖关系图找到此 Bundle 的 Class Loader，将加载请求委托给此 Class Loader ；  
5. Bundle 搜索自己的类资源 ( 包括 Bundle-Classpath 里面定义的类路径和属于 Bundle 的 Fragment 的类资源）；  
6. 若类在 DynamicImport-Package 中定义，则开始尝试在运行环境中寻找符合条件的 Bundle 。

**2.2 Spring DM**

Spring DM即Spring动态模型，允许开发者构建Spring应用程序，这种应用程序能够在osgi容器内进行部署。可以理解为spring与osgi的结合，带来的优点是：  
1. 使用spring框架在模块之间实例化、配置、集成组件  
2. 开发者使用熟悉的编程模型开发osgi平台程序，使编写osgi程序变得容易一些

[![220737414.jpg][]][220737414.jpg]

如上图解释下spring dm这个框架的一些功能特性：  
1. spring extender bundle：负责实例化业务组件的application context，并且这个过程是异步的，也就是说bundle可以先全部被置为active状态，但是实例化application context（即实例化配置文件中定义好的bean，导出可用service）这个过程是异步的，bundle的状态和application context是否实例化之间没有直接关联  
2. application context：对于传统的spring框架开发的程序就一个上下文文件，spring容器通过该文件配置的bean进行实例化，对于osgi的程序，每一个bundle可以有自己的application context，声明bundle本身的导入和导出的service  
3. 注册service：如下是application context中配置的bean与service信息，bean被实例化之后其中的接口被注册，被注册的service可以为其他bundle所访问。

[![220745210.jpg][]][220745210.jpg]

**2.3 Maven**

Maven是一个项目管理工具，它包含了一个项目对象模型 (Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。使用Maven的时候，用一个明确定义的项目对象模型来描述项目，然后Maven可以应用横切的逻辑，这些逻辑来自一组共享的（或者自定义的）插件。  
  
Maven的功能与Ant类似，管理项目而用，对于osgi项目，组件众多，依赖关系众多，通过mave的组织管理方式，能方便的处理这些问题

**2.4 Pax-exam**

说到测试框架，spring DM自带了一个集成junit的测试框架spring-dm test，在实际使用中，因为需要tester也要定义一大串的依赖关系，并且对组件的启动顺序有要求，提高了环境调试的工作量，转而调研了pax-exam这个框架。

Pax-exam是用来测试osgi框架和应用程序的工具。它负责的自动化case执行顺序大致如下：  
1. 启动一个OSGi的容器，比如equinox,flex，这是基础，因为所有的OSGI组件都要生存在一个OSGI容器之上  
2. 启动需要用到的所有bundle，包括被测bundle，以及被测bundle依赖的bundles  
3. 动态的将test代码project创建为一个bundle  
4. 把test bundle发布到已经启动了的OSGI容器内  
5. 执行test函数

Pax-exam由多个组件组成，如下图：

[![220755460.jpg][]][220755460.jpg]

**3 测试方案**

**3.1 测试开发环境**

**3.1.1 JDK**  
JDK：1.5以上，JDK需要配置环境变量

**3.1.2 Eclipse**  
Eclipse：笔者使用的版本3.5.1，所需安装插件有：svn，maven（详见下方）  
**3.1.3 Maven**  
Maven：2.2.1，安装与使用如下说明：

1. Maven的eclipse插件配置：  
第一：下载apache-maven-2.2.1-bin.zip

第二：在eclipse的window-preferences-maven-installation中add maven2.2.1如下并选择：

[![220808543.jpg][]][220808543.jpg]

第三：maven本地仓库配置，在eclipse的window-preferences-maven-user settings中配置如下

[![220842987.jpg][]][220842987.jpg]

Settings.xml中的两处配置注意为：  
一个是本地仓库的路径  
<localRepository>E:/maven\_eclipse/maven-repository</localRepository>  
另一个是线上仓库的地址  
<url>http://maven.scm.baidu.com:8081/nexus/content/groups/public</url>

**2. Maven的环境变量配置**  
想要在eclipse中执行junit的函数，需要从环境变量得到maven程序的路径，配置如下

[![220856286.jpg][]][220856286.jpg]

然后在Path环境变量中，增加%M2\_HOME%\\bin;如下：

[![220907264.jpg][]][220907264.jpg]

**3.1.4 Pax-exam**

Pax-exam：2.0.0-RC4

测试代码的pom.xml中需要配置以下对pax-exam的依赖关系

[![221010161.jpg][]][221010161.jpg]

[![221018582.jpg][]][221018582.jpg]

**3.2 测试思路**

**3.2.1 代码关系与管理**  
如2.4中提到的，osgi组件的代码级case，思路都是把测试代码发布为bundle，由osgi框架触发执行测试bundle中的test函数，而test函数的逻辑就是对被测bundle的接口进行调用，如下图所示：

[![221028426.jpg][]][221028426.jpg]

那被测代码、测试代码、被测和测试代码之间究竟是怎么样的组织关系？因为传统的方式是import jar包到build path下，使用maven是在pom.xml中定义对jar包的依赖。为了更好的说明maven组织管理bundle之间的依赖关系，可参考下图示例：

[![221041823.jpg][]][221041823.jpg]

说明：  
1. 左侧的parent，sub2，sub2/sub1是被测代码结构的示例，这是一种继承结构，parent也是maven模块，类似于面向对象语言中的父类。Parent一般定义了工程需要依赖的第三方的bundle，那么sub2以及sub2的子模块直接从parent继承下来这些第三方的依赖关系。  
2. 本地仓库的作用是从线上仓库download bundle下来，开发和执行case时都是到本地仓库去寻找bundle的。那么在定义parent的依赖组件关系后，编译parent时maven就会执行download的过程  
3. 被测代码通过mvn install的命令在开发环境下编译，编译后的jar包会存放至本地仓库；如果被测代码已经成熟，则可以直接发布到线上仓库  
4. 测试代码的结构可以简单的就是一个maven project或者仿照被测代码的集成结构  
5. 测试代码所依赖的第三方组件，被测代码的组件，都在本地仓库

**3.2.2 Pax-exam junit用法**

Pax-exam的几个主要的功能是：将所有的bundle解析、加载、启动，执行单测case。下面以一个单测用例的例子做说明。

[![221220785.jpg][]][221220785.jpg]

第一句@RunWith通过注解使得该class被Junit4TestRunner来驱动执行，Junit4TestRunner在2.4节中提到过，是封装了Juit4的TestRunner。做的事情就是在组件容器内找到TestClass和TestMethod，并且通过反射调用执行单测函数。

第二句的注解是pax-exam2才新升级的功能，2.4提到过pax-exam执行test case的流程，最开始就是要启动测试容器，然后启动所有的bundle，这个注解有两个class可选，分别为：  
AllConfinedStagedReactorFactory.class  
这个类使得test case执行时，每一个@Test函数都要启动一次容器，并且启动所有的bundle，开销较大。一般不建议这么做。  
EagerSingleStagedReactorFactory.class  
这个类是让每一个test class初始化时启动容器，并且启动所有bundle，class中的所有@Test函数就在这已经启动好的容器内执行了。这样减少了启动容器的次数，减少开销。

第三句@Configuration()这个注解是pax-exam本身所需设置一些配置项，包括了配置需要启动哪些bundle，所以这个是重点。以上述代码片段为例说明，都需要配置哪些内容：  
mavenBundle().groupId("javax.servlet").artifactId("com.springsource.javax.servlet").version("2.5.0"),  
这一句比较有代表性，用来配置pax-exam测试执行时所需启动的bundle信息。被测代码需要启动什么bundle，pax-exam测试时就需要在这里进行配置，否则容器启动就会失败。  
  
@Test注解就跟Junit4一样了，标明函数有Junit4来执行。其代码逻辑中，如何调用被测的接口呢？  
还得接2.2节来说，采用spring-dm开发，bundle之间互相通过接口来通信，那么接口就是通过spring来实例化的。BundleContext这个对象，能够获得组件容器内可访问的接口，因此调用被测接口时一般为：  
XService x = bundleContext.getServiceReference(XService.class)  
这里XService就是某个bundle在spring的applicationcontext文件中配置的bean，实例化之后，通过bundleContext就可以得到。

**3.2.3 测试执行**

有两种方法来执行pax-exam的junit case。  
第一是在开发环境下，使用eclipse的junit4和maven插件来执行。在test class上右键run as Junit test，当然要这么执行需要关注3.1.3中maven的环境变量配置，因为这么执行需要告诉junit，那些依赖的bundle去哪里能拿到。  
第二是在命令行环境下，使用maven的命令：mvn test执行。在2.3节中提到过，maven定义了一些插件的目标，所谓的插件就是具有特定功能的程序，能在maven中配置使用，比如要执行mvn test，需要有一个maven插件maven-surefire-plugin，在测试代码的pom.xml中配置为：

[![221255816.jpg][]][221255816.jpg] [![221255854.jpg][]][221255854.jpg]

如上，在pom中以plugins标签来配置maven-surefire-plugin，在configuration标签中有几项需要说明下：  
Parallel和threadCount配合使用，可用以多线程执行单测case，不过对于osgi组件级的测试，多线程的方式会明显加大开销，不建议这么做。如果是非osgi的程序，可以通过多线程方式加快单测执行时间。  
forkMode可以是once，pertest，与agrline配合起来可以为case执行时启动jvm传入参数，forkMode的含义是jvm初始化的机制，分别为：只初始化一次，每一个case初始化一次。  
Mvn test执行完毕的report就是junit的结果report，为xml格式。

**3.2.4 代码调试**

在单测实施中，如果抛出的异常还不够看出原因所在，可通过代码调试来跟踪执行情况，从而定位问题。  
Osgi组件，因为每一个组件都有自己的classloader，测试代码是一个组件，都是组件的话并不能直接调试，只能采用远程调试的方式。如下代码意思是在整个bundle容器的jvm启动后，开放一个监听端口以便远程调试：

new VMOption( "-Xdebug -Xrunjdwp:transport=dt\_socket,server=y,suspend=y,address=5005" ),  
new TimeoutOption(0),

在eclipse的debug configuration中新增一个remote java application，配置上面的地址和端口。设置断点之后执行单测case，就如同本地调试一样，可单步跟踪。

**3.2.5 覆盖率**

考虑到被测程序架构是maven+osgi，覆盖率可选的工具有多种：maven-emma-plugin，jacoco。  
Jacoco采用的是动态插桩方式，不会额外的输出一份插桩后的class，而是在jvm中载入class的时候做的插桩，它的使用过程如下：

[![221309717.jpg][]][221309717.jpg]

**4 持续集成方案**

进行持续集成之前，需要考虑到，程序架构为maven+osgi+pax-exam junit case+jacoco，各个环节都有自己的特别之处，先以一个流程图说明下，在如此架构下ci的执行过程：

[![221321992.jpg][]][221321992.jpg]

**5 小结**

Osgi组件的架构，初衷是引入模块化的设计理念，就好比搭积木一样，一块一块的垒起来。不过也带来一些问题就是框架重量级，初期开发难度大。随之而来的自动化测试或者单元测试也面临同样的问题。  
Pax-exam是一种osgi组件自动化测试的框架，上文都是基于这个框架设计的方案，它有哪些优势和不足呢？  
优势：比较于spring-dm自带的test框架，pax-exam不需要依赖一个庞大的pom.xml文件，而是自己配置，并且能自动理清各种bundle的前后依赖和启动顺序，这一点很重要，否则N多个bundle如何启动都是个问题。  
不足：开销较大，主要体现为执行测试时，需要把要依赖的bundle都配置并且启动，这个过程是比较花时间的，比如启动容器和组件需要7s，而执行case本身都是毫秒级。

后续的计划：pax-exam在实际的工作中带来一些便利，但是为了减少开销，也为了提高编写单测case的易用性，后续的方向会向spring容器偏移，spring容器与组件容器相比，确实是轻量级的。

**作者：xdwei**

【本文首发于： [百度测试技术空间】][Link 1] [http://hi.baidu.com/baiduqa/blog/item/9d257756074d8c43d1090643.html][http_hi.baidu.com_baiduqa_blog_item_9d257756074d8c43d1090643.html]

【 [关注百度技术沙龙】][Link 2]

本文转自百度技术51CTO博客，原文链接：http://blog.51cto.com/baidutech/743812，如需转载请自行联系原作者

[220719273.jpg]: /images/20220203/552aa94b465845adb258c2cc8a0abd07.png
[220728714.jpg]: /images/20220203/40f5505ed0d742b084cdbc7ea261f5f8.png
[220737414.jpg]: /images/20220203/d147439c8aa542eb83c41e8bcbea6ecc.png
[220745210.jpg]: /images/20220203/e290a0925bff441180ab5846b97632b8.png
[220755460.jpg]: /images/20220203/c14d581c5dda464f8d0115cb3390292a.png
[220808543.jpg]: /images/20220203/4e9f40462c6e418dbe43b53503b3be8e.png
[220842987.jpg]: /images/20220203/fc6d7916d2ac4315b62ce21e15a1d522.png
[220856286.jpg]: /images/20220203/e55ae4a630b4498f96136b88baeb74d2.png
[220907264.jpg]: /images/20220203/90ba5b7dcb414fbd90905206dc48f7ff.png
[221010161.jpg]: /images/20220203/9fbee5acc6fe48d9a47331ecd2b94348.png
[221018582.jpg]: /images/20220203/8f20e3cdb0f54398bbcfbf43ece9996f.png
[221028426.jpg]: /images/20220203/eba13aaf00224c779f88da09e5368226.png
[221041823.jpg]: /images/20220203/9b8c9e29d351459f8f2e7a08d352f7a5.png
[221220785.jpg]: /images/20220203/7a0c719588bd481fbbfb95e7402d8a47.png
[221255816.jpg]: http://blog.51cto.com/attachment/201112/221255816.jpg
[221255854.jpg]: /images/20220203/f7dfd2d4e6f9401eb74cbcd4b4634f0b.png
[221309717.jpg]: /images/20220203/26d9787a85134fa0bb44b679cc8977ab.png
[221321992.jpg]: /images/20220203/659cc25887ec4f688b68e599e63172bc.png
[Link 1]: http://hi.baidu.com/baiduqa/home
[http_hi.baidu.com_baiduqa_blog_item_9d257756074d8c43d1090643.html]: http://hi.baidu.com/baiduqa/blog/item/9d257756074d8c43d1090643.html
[Link 2]: http://weibo.com/baidutech