CN105701005B - 基于osgi的应用框架测试方法和系统 - Google Patents

Abstract

本申请公开了一种基于OSGI的应用框架测试方法和系统，通过应用本申请实施例的技术方案，通过新的OSGI测试框架理论，更好的动态控制细粒度测试范围，在OSGI环境某些场景下，通过应用框架在启动脚本中传入的细粒度‑Dunittesting参数，通过增加MF文件新的标签，动态控制OSGI MF文件的导入导出类，最终从单元测试(集成单元测试)角度编写集成测试脚本测试，最终逐步完善测试场景，并逐步增加遗漏的测试场景范围，可以更好提升OSGI应用框架程序的覆盖率。

Description

基于OSGI的应用框架测试方法和系统

技术领域

本申请涉及通信领域，尤其涉及一种基于OSGI的应用框架测试方法、设备和系统。

背景技术

OSGI是一个基于Java的，提供动态模块加载和管理的运行时框架，运行时可以动态安装、更新OSGI bundle，该运行时框架有整套的标准环境组件，主要包含运行时环境、模块化(类装载策略)、生命周期管理、服务注册等组件。

其中，模块化具体表现为bundle形式作为OSGI的部署单元，通常以jar包的形式封装业务逻辑，提供给各个bundle部署时各单元使用的类

现有OSGI测试框架的基础原理如下：

首先，针对Test Suite(测试包)中包含了所有的测试代码，测试代码编写可以基于JUnit或TestNG等其他自定义测试框架封装的测试代码。在基于OSGI开发的应用框架，通过启动脚本或其他形式在初始化应用程序时，现有编写好的每个Test Suite都会注册到Test Framework Manager Center Bundle(测试框架管理中心Bundle)，其中注册测试用例相关的信息，包含测试用例名称、测试描述、测试类、测试方法、测试步骤描述、测试预期结果，当应用框架启动成功后，所有相关测试实例都已经被注册到了Test FrameworkManager Center Bundle；在OSGI框架运行时阶段针对这些存储好的测试用例，可以通过用例唯一标识(用例名称或用例ID号)触发对应的测试用例执行，最终将获取的测试用例返回结果同预期结果比对后存储DB(Data Base，数据库)，或展示在web页面，框架原理图如图1所示。

Test Framework Manager Center Bundle在OSGI测试体系中控制每个TestSuite初始化的测试用例，并统一注册到测试运行时框架中，在测试报告上可以指定用户输入的单个测试脚本、分功能批次或指定所有测试脚本运行产出，通过运行期控制每个测试脚本对应的Test Suite，从Bean实例层面执行Test Suite中对应方法进行框架功能验证，最终Test Framework Manager Center Bundle会将每个测试脚本指定的结果存储到DB中，并在web UI中展示给测试用用户。

OSGI框架是面向服务架构，系统bundle之间对象交互、服务的发布、引用方式是测试中需要着重突破点。这两部分在OSGI下bundle逻辑可以通过配置MANIFEST.MF文件，主要配置Import-Package、Export-Package、DynamicImport-Package等配置项来实现。

在OSGI测试体系建立过程中，现有的基于OSGI或Eclipse Equinox的研发的应用框架或应用程序，主要有三类测试框架设计理念来实现测试体系，最为常用的是基于OSGIbundle Layer service的理念、基于fragment-host片段bundle理念、基于扩展点extension point并结合Fragment理念，还有部分测试框架采用基于Event Admin服务的Bundle间通讯机制，OSGI的Event Admin服务规范提供了研发同学基于发布/订阅的模型，通过事件机制实现Bundle间协作的标准通讯方式(特定场景测试)。

下面将着重其中OSGI Service Layer和Fragment两种通用OSGI测试框架理论，其他测试理论(扩展点或事件通知)仅仅为特殊框架领域测试理论。

方式一、基于OSGI Layer service/bundle MF的测试理论。首先通过利用服务层(service layer)提供的机制来实现模块间的松耦合，将Junit或TestNG测试框架实现为基于OSGI的测试框架Bundle，将相关的Junit相应服务或接口通过Bundle/OSGI MF文件、OSGIservice方式提供给测试脚本编写者编写Test Framework Manager Center Bundle。实现上通过BundleActivator接口，在MANIFEST.MF中指定Bundle-Activator配置(图2)；另一种是通过Declarative Services的方式实现，需要在MANIFEST.MF中指定Service-Component配置，此方式也是推荐使用的方式，通过DS提升了Service发布和使用的简便性，可以很好的将Moudle分解为Component+Service的模式，并且无需编写java代码，所有的配置通过xml文件即可实现(图3)，图4为该测试框架原理。

包装了原生的Junit和TestNG接口生成OSGI Service，通过Bundle MF文件方式导出Junit相关的接口和类给测试脚本编写者使用，建立Test Suit Bundle进行测试脚本编写，将实际的Target应用框架OSGI Bundle逻辑代码和同测试脚本分离，通过OSGI Servicelayer对测试脚本运行期依赖的OSGI环境和真实运行时环境一致，保证各个Bundle在测试环境依赖关注和导入导出逻辑测试正常。

方式二、基于Fragment Bundle的测试理论。

Fragment Bundle可以作为多个主体Bundle的片段Bundle，Fragment Bundle和主体Host Bundle是依附关系，首先Fragment Bundle本身无自己的Class loader，需要HostBundle被框架追加到Host Bundle作为Host Bundle后再去做框架解析，总之，FragmentBundle存在自身保护域但不存在自己的类加载系统Class loader。若片段Bundle和主bundle之间的类命名空间不一致会产生冲突，存在Fragment bundle类冲突后则无法附加到Host Bundle。

Fragment bundle增加了现有Host Bundle的类加载路径或范围，例如，需要使用不同数据库的驱动，可以将这些不同驱动作为Fragment Bundle。

因此，在测试OSGI过程中需要依赖Junit和TestNG提供的接口或服务，首先将其转换为OSGI Junit/TestNG Bundle，并封装为Test Framework Manager Center Bundle，并将相应的接口通过OSGI Service Layer方式发布出来提供给测试脚本编写者使用，而编写的测试用例Test Suit Bundle作为Fragment Bundle，在框架解析时附加到TestFramework Manager Center Bundle中，最终由Test Framework Manager Center Bundle同OSGI应用框架运行时进行交互，真正运行期的Test Suit Bundle脚本作为片段Bundle同测试框架Test Framework Manager Center Bundle合为一体，减少了测试Bundle的维护成本，也做到了测试代码和应用框架逻辑分离，以及模拟了真正OSGI运行时环境。图5为该测试框架原理。

在实现本申请的过程中，本申请的申请人发现现有技术存在以下缺陷：

方式一所对应的测试方式面临的问题在于，需要测试人员维护编写的多个测试bundle，通过采用OSGI service interface方式作为测试粒度需要进行优化，有些OSGI环境下测试很难模拟的场景导致代码覆盖率难以提升。

方式二所面临的问题在于，测试脚本Test Fragment维护后越来越庞大时会面临片段Bundle在运行时加载体积过大难以拆分为多个Fragment Bundle，同时难以解决OSGI运行时模拟异常或特殊场景的细粒度测试，例如，一般单元测试可以很好的模拟主机host获取和连接异常时对返回信息的判断，因此需要考虑更好OSGI的细粒度测试方案。

基于上述的缺陷，如何更好的在OSGI运行时中进行细粒度测试成为了现有技术方案亟待解决的重要问题。

发明内容

本申请提供了一种基于OSGI的应用框架测试方法和设备，能够解决现有技术中，无法在OSGI运行时中进行细粒度测试的问题。

为达到上述目的，本申请实施例一方面提供了一种基于OSGI的应用框架测试方法，应用于包括测试组件配置包Test Assembly Config Bundle的OSGI测试框架中，所述Test Assembly Config Bundle中至少包括一个测试框架管理中心包Test FrameworkTrigger Center Bundle，所述方法包括：

所述Test Assembly Config Bundle根据通过启动脚本传入的D参数，确定应用框架OSGI Bundle的软件架构MF文件的导入导出类；

所述Test Assembly Config Bundle与OSGI运行时交互隔离测试代码和所述OSGIBundle逻辑代码；

所述Test Assembly Config Bundle通过所述Test Framework Trigger CenterBundle，按照测试用例标识触发相应的测试用例的执行，并按照所述MF文件的导入导出类，通过所述OSGI Bundle输出相应粒度的测试结果。

优选的，所述Test Assembly Config Bundle通过所述Test Framework TriggerCenter Bundle，按照测试用例标识触发相应的测试用例的执行，并按照所述MF文件的导入导出类，通过所述OSGI Bundle输出相应粒度的测试结果，具体包括：

所述Test Framework Trigger Center Bundle加载OSGI运行时下的各测试用例信息；

所述Test Framework Trigger Center Bundle根据通过启动脚本传入的D参数所确定的OSGI Bundle MF文件的导入导出类，控制所有的测试数据包；

所述Test Framework Trigger Center Bundle测试OSGI Bundle MF文件中新增的标签；

所述Test Framework Trigger Center Bundle通过测试接口控制与OSGI BundleMF文件的导入导出类相对应的测试过程范围，并存储相应的测试结果到数据库DB中；

所述Test Assembly Config Bundle通过所述OSGI Bundle输出相应粒度的测试结果。

优选的，所述方法，还包括：

所述Test Framework Trigger Center Bundle通过新建Socket Accepter，以及Accepter端口绑定，实现服务Server的启动和响应端口的开启；

所述Test Framework Trigger Center Bundle接收输入的测试脚本信息。

优选的，所述方法还包括：

所述Test Assembly Config Bundle通过OSGI Layer service/bundle MF方式，控制所述Test Framework Trigger Center Bundle同OSGI运行时交互，将每个测试用例在运行时所加载的框架业务逻辑同测试代码分离。

优选的，所述OSGI测试框架通过封装或重写的Junit类似功能的测试接口或服务部分，提供给测试用例编写者测试框架接口或服务，为每个测试脚本的每个测试方法提供用例相关信息，其中，所述用例相关信息包括测试用例的描述、指定过程和执行结果记录；

所述Test Framework Trigger Center Bundle在测试用例的触发执行过程中，将所述用例相关信息存储到DB中。

另一方面，本申请实施例还提出了一种OSGI测试框架，至少包括Test AssemblyConfig Bundle、OSGI Bundle和OSGI运行时，其中，所述Test Assembly Config Bundle中至少包括一个测试框架管理中心包Test Framework Trigger Center Bundle：

所述Test Assembly Config Bundle，具体用于：

根据通过启动脚本传入的D参数，确定所述OSGI Bundle的MF文件的导入导出类；

与所述OSGI运行时交互隔离测试代码和所述OSGI Bundle逻辑代码；

通过所述Test Framework Trigger Center Bundle，按照测试用例标识触发相应的测试用例的执行，并按照所述MF文件的导入导出类，通过所述OSGI Bundle输出相应粒度的测试结果。

优选的，所述Test Framework Trigger Center Bundle，具体用于：

加载OSGI运行时下的各测试用例信息；

根据通过启动脚本传入的D参数所确定的OSGI Bundle MF文件的导入导出类，控制所有的测试数据包；

测试OSGI Bundle MF文件中新增的标签；

通过测试接口控制与OSGI Bundle MF文件的导入导出类相对应的测试过程范围，并存储相应的测试结果到DB中。

优选的，所述Test Framework Trigger Center Bundle，还用于：

通过新建Socket Accepter，以及Accepter端口绑定，实现服务Server的启动和响应端口的开启；

接收输入的测试脚本信息。

优选的，所述Test Assembly Config Bundle，还用于：

通过OSGI Layer service/bundle MF方式，控制所述Test Framework TriggerCenter Bundle同OSGI运行时交互，将每个测试用例在运行时所加载的框架业务逻辑同测试代码分离。

优选的，所述OSGI测试框架，还用于：

通过封装或重写的Junit类似功能的测试接口或服务部分，提供给测试用例编写者测试框架接口或服务，为每个测试脚本的每个测试方法提供用例相关信息；

其中，所述用例相关信息包括测试用例的描述、指定过程和执行结果记录；

所述用例相关信息被所述Test Framework Trigger Center Bundle在测试用例的触发执行过程中存储到所述DB中。

与现有技术相比，本申请所提出的技术方案至少具有以下优点：

通过应用本申请实施例的技术方案，通过新的OSGI测试框架理论，更好的动态控制细粒度测试范围，在OSGI环境某些场景下，通过应用框架在启动脚本中传入的细粒度-Dunittesting参数，通过增加MF文件新的标签，动态控制OSGI MF文件的导入导出类，最终从单元测试(集成单元测试)角度编写集成测试脚本测试，最终逐步完善测试场景，并逐步增加遗漏的测试场景范围，可以更好提升OSGI应用框架程序的覆盖率。

附图说明

图1为现有技术中一种框架原理的示意图；

图2为现有技术中通过BundleActivator接口实现场景的示意图；

图3为现有技术中通过Declarative Services的方式实现场景的示意图；

图4为现有技术中另一种框架原理的示意图；

图5为现有技术中另一种框架原理的示意图；

图6为本申请实施例提供的一种基于OSGI的应用框架测试方法的流程示意图；

图7为现有技术中另一种框架原理的示意图；

图8为本申请实施例提供的一种基于OSGI的应用框架的示意图；

图9为本申请实施例提供的一种处理流程示意图；

图10为本申请实施例提供的一种处理流程示意图；

图11为本申请实施例提供的一种测试实现示例的示意图；

图12为本申请实施例提供的一种测试实现和相关测试结果的示意图；

图13为本申请实施例提供的一种测试用例触发逻辑部分相关代码和实现的示意图；

图14为本申请实施例提供的一种OSGI测试框架的结构示意图。

具体实施方式

为了解决现有技术中存在的问题，本申请提出了一种基于OSGI的应用框架测试方法，通过新的OSGI测试框架理论，更好的动态控制细粒度测试范围。

如图6所示，为本申请实施例提供的一种基于OSGI的应用框架测试方法的流程示意图，应用于包括Test Assembly Config Bundle(测试组件配置包)的OSGI测试框架中，所述Test Assembly Config Bundle中至少包括一个Test Framework Trigger CenterBundle(测试框架管理中心包)，本方法包括：

步骤S601、所述Test Assembly Config Bundle根据通过启动脚本传入的D参数，确定应用框架OSGI Bundle的MF(软件架构)文件的导入导出类。

步骤S602、所述Test Assembly Config Bundle与OSGI运行时交互隔离测试代码和所述OSGI Bundle逻辑代码。

步骤S603、所述Test Assembly Config Bundle通过所述Test FrameworkTrigger Center Bundle，按照测试用例标识触发相应的测试用例的执行，并按照所述MF文件的导入导出类，通过所述OSGI Bundle输出相应粒度的测试结果。

在具体的应用场景中，本步骤的执行过程具体包括：

所述Test Framework Trigger Center Bundle加载OSGI运行时下的各测试用例信息；

所述Test Framework Trigger Center Bundle根据通过启动脚本传入的D参数所确定的OSGI Bundle MF文件的导入导出类，控制所有的测试数据包；

所述Test Framework Trigger Center Bundle测试OSGI Bundle MF文件中新增的标签；

所述Test Framework Trigger Center Bundle通过测试接口控制与OSGI BundleMF文件的导入导出类相对应的测试过程范围，并存储相应的测试结果到DB(Data Base，数据库)中；

所述Test Assembly Config Bundle通过所述OSGI Bundle输出相应粒度的测试结果。

进一步的，上述的过程中还包括：

所述Test Framework Trigger Center Bundle通过新建Socket Accepter，以及Accepter端口绑定，实现服务Server的启动和响应端口的开启；

所述Test Framework Trigger Center Bundle接收输入的测试脚本信息。

进一步的，本方法还包括：

所述Test Assembly Config Bundle通过OSGI Layer service/bundle MF方式，控制所述Test Framework Trigger Center Bundle同OSGI运行时交互，将每个测试用例在运行时所加载的框架业务逻辑同测试代码分离。

另一方面，所述OSGI测试框架通过封装或重写的Junit类似功能的测试接口或服务部分，提供给测试用例编写者测试框架接口或服务，为每个测试脚本的每个测试方法提供用例相关信息，其中，所述用例相关信息包括测试用例的描述、指定过程和执行结果记录；

所述Test Framework Trigger Center Bundle在测试用例的触发执行过程中，将所述用例相关信息存储到DB中。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，通过新的OSGI测试框架理论，更好的动态控制细粒度测试范围，在OSGI环境某些场景下，通过应用框架在启动脚本中传入的细粒度-Dunittesting参数，通过增加MF文件新的标签，动态控制OSGI MF文件的导入导出类，最终从单元测试(集成单元测试)角度编写集成测试脚本测试，最终逐步完善测试场景，并逐步增加遗漏的测试场景范围，可以更好提升OSGI应用框架程序的覆盖率。

下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

发明人发现，由于采用了Eclipse的OSGI实现Equinox为基础，研发了新的应用框架与容器基础组件，由于OSGI框架使用Bundle把复杂的应用程序模块化后，在OSGI的框架中，Bundle的生命周期由OSGI运行环境进行管理；Bundle之间以松耦合的形式相互依赖；而OGSIBundle有严格的访问安全限制，为了最终完成细粒度的单元测试和集成测试，本文提供的新的测试体系去解决Bundle访问权限的限制，测试脚本与被测Bundle及其依赖的Bundle同时运行于OSGI环境中；同时完成将测试代码和业务代码分离。

基于OSGI的Equinox为Java程序在模块化管理和开发提供了优势，在OSGI中以Bundle作为程序编写的模块，每个Bundle包含相关Java逻辑类和相关Bundle的附加的Manifest.MF描述信息文件，OSGI运行时框架维护了每个Bundle的生命周期，以及各个Bundle的启动中相互依赖和运行期调用关系。因此在OSGI框架体系下，编写的测试脚本需要运行在OSGI的运行时Runtime中，且每个单元测试或集成测试脚本需要多个OSGI Bundle相互依赖调用。针对现有的普通的JUnit、TestNG测试理论和方法，并没有针对OSGI体系在Bundle模块化和隔离机制提供相应的测试方法。

同时Bundle模块化管理和隔离各个Bundle的限制，也会使得现有的Java测试Junit/TestNG无法直接应用于OSGI运行时框架。OSGI Plug In/Bundle对其包含的Java包有严格的访问限制，仅在MF文件中定义的少数的接口包能够被其他的Bundle加载依赖到。在公司基础框架和容器测试时需要测试Bundle内非Public的包对应的框架实现。

在编写测试代码需要避开Bundle的访问限制，测试Bundle内部非public包的单元测试(Bundle之间单元测试)成为测试中一个新的难点，QA同学需要实现运行测试用例过程后完全不需要额外工作来去除测试代码，不影响运行期基础框架和容器的功能。

在OSGI基础上的容器框架分离测试代码和基础框架和容器代码，同时保证测试代码访问框架逻辑进行测试时又不影响框架逻辑，在业界有很多的OSGI测试解决方案。本文将针对现有存在的测试OSGI解决方案之上提出一套新的测试理论方法

现有OSGI测试框架基础原理介绍，首先针对Test Suite中包含了所有的测试代码，测试代码编写可以基于JUnit或TestNG等其他自定义测试框架封装的测试代码。在基于OSGI开发的应用框架，通过启动脚本或其他形式在初始化应用程序时，现有编写好的每个TestSuite都会注册到测试框架管理中心Test Framework Trigger Center Bundle，其中注册测试用例相关的信息，包含测试用例名称、测试描述、测试类、测试方法、测试步骤描述、测试预期结果，当应用框架启动成功后，所有相关测试实例都已经被注册到了测试框架管理中心；在OSGI框架运行时阶段针对这些存储好的测试用例，可以通过用例唯一标识(用例名称或用例ID号)触发对应的测试用例执行，最终将获取的测试用例返回结果同预期结果比对后存储数据库DB，或展示在web页面，框架原理图如图7所示。

Test Framework Trigger Center Bundle在OSGI测试体系中控制每个TestSuite初始化的测试用例，并统一注册到测试运行时框架中，在测试报告上可以指定用户输入的单个测试脚本、分功能批次或指定所有测试脚本运行产出，通过运行期控制每个测试脚本对应的Test Suite(类对象)，从Bean实例层面执行Test Suite中对应方法进行框架功能验证，最终Test Framework Trigger Center Bundle会将每个测试脚本指定的结果存储到DB中，并在web UI中展示给测试用用户。

OSGI框架是面向服务架构，系统bundle之间对象交互、服务的发布、引用方式是测试中需要着重突破点。这两部分在OSGI下bundle逻辑可以通过配置MANIFEST.MF文件，主要配置Import-Package、Export-Package、DynamicImport-Package等配置项来实现，服务service的交互可以有两种方法实现：

一种是通过实现BundleActivator接口，在MANIFEST.MF中指定Bundle-Activator配置，如之前的图2所示；

另一种是通过Declarative Services的方式实现，需要在MANIFEST.MF中指定Service-Component配置，此方式也是推荐使用的方式，通过DS提升了Service发布和使用的简便性，可以很好的将Moudle分解为Component+Service的模式，并且无需编写java代码，所有的配置通过xml文件即可实现。配置文件大致如之前的图3所示。

在具体的应用场景中，在引用策略的定义上可有两种方式static(默认)、dynamic，若设置成static,一旦引用的服务发生变动整个Compont便会重启，设置成dynamic,服务发生变动只是调用其中的bind和unbind方法，cardinality的值主要是0,1,N三个数的组合。

如果系统中存在多个可引用的服务,但cardinality规定至多引用一个服务,这种情况下，一旦component所引用的服务stop,该component首先执行的并不是其unBind方法,而是继续寻找新的可用服务调用其bind方法进行绑定，然后才会调用其unBind方法对之前引用的服务进行解绑户。

综合考虑上述因素，本申请提出相应的解决方案，如图8所示，为本申请实施例所提出的一种具体应用场景下的基于OSGI的应用框架示意图。

这块内存区域与现有技术中所提到的测试框架有所区别，具体说明如下：

首先，重构Junit原生框架或重写一套新的测试框架，提供类似Junit的基本的测试接口或服务，尽量简单化和轻量化，提供基本的用例ID、用例描述、用例过程信息、用例结果等接口；其次，OSGI测试框架管理中心Bundle-Test Framework Trigger CenterBundle，将根据每个用例的ID进行Trigger触发用例执行，最终将执行结果存储到DB，另一方面,通过OSGI Layer service/bundle MF方式，OSGI测试框架管理中心Bundle控制同OSGI运行时交互，将每个用例运行时加载的框架业务逻辑同测试代码分离；再次，由于公司是基于Eclipse Equinox OSGI开发的应用技术框架，在OSGI运行时控制加载OSGI Bundle下export哪些Package，初始化和动态运行加载的类最终提供给上层应用框架使用者(或测试脚本编写者)，最终export给用户的osgi Package或api、OSGI注册表中心发布和订阅服务关系都是固定的，为了更细粒度的测试，我们需要在这个新的OSGI测试体系下，控制export给用户的Package，以及需要测试Bundle在测试过程中Import哪些Package。

基于Eclipse Equinox OSGI开发的应用技术框架，基于OSGI Layer service/bundle MF来编写新的OSGI测试方案，将测试中的service或实例对象注册到OSGI运行时中，通过实现Bundle Activator接口，在MANIFEST.MF中指定Bundle-Activator配置(图2)；或通过Declarative Services的方式实现(图3)，将运行时测试脚本服务或测试对象注入到OSGI中。

新的测试框架中Test Framework Trigger Center Bundle作为Test AssemblyConfig Bundle多个Package形式存在，主要为原生测试框架提供的服务或Interface、TestSuit编写维护、测试脚本触发和测试结果DB落地、以及测试结果展示，

OSGI测试框架方案中Test Framework Trigger Center Bundle部分，测试用例触发逻辑部分是启动server以及打开响应的端口，接收测试用户输入的测试脚本信息，触发执行对应的测试脚本并存储测试结果到DB中，具体如图9所示。

另一部分是在Junit或自定义测试框架部分，提供给测试用例Test Suit编写者一些测试框架接口或服务，是封装或重写的Junit类似功能的测试接口或服务部分，给每个测试Test Suit的每个测试方法提供用例的描述、指定过程和执行结果记录，此部分用例相关信息会在用例触发执行时存储到DB中，具体如图10所示。

新的测试框架中Test Assembly Config Bundle部分可自定义测试本Bundle的MF文件导入导出的类、通过启动脚本传入的-D参数，控制应用框架OSGI Bundle的MF文件的导入导出类、以及负责OSGI运行时交互隔离测试代码和应用框架逻辑代码，由于OSGI Bundle类加载体系隔离特性，使得部分类在测试过程中不可见，通过控制OSGI Bundle的导入导出类，可以在OSGI环境下，针对不同测试脚本标识，更好的进行细粒度测试类或代码逻辑的测试，具体如图11所示。

最后，给出基于上述策略的测试实现和相关测试结果，如图12所示。

测试用例触发逻辑部分相关代码和实现，如图13所示。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，通过新的OSGI测试框架理论，更好的动态控制细粒度测试范围，在OSGI环境某些场景下，通过应用框架在启动脚本中传入的细粒度-Dunittesting参数，通过增加MF文件新的标签，动态控制OSGI MF文件的导入导出类，最终从单元测试(集成单元测试)角度编写集成测试脚本测试，最终逐步完善测试场景，并逐步增加遗漏的测试场景范围，可以更好提升OSGI应用框架程序的覆盖率。

为了实现上述的技术方案，本申请实施例提供了一种OSGI测试框架，其结构示意图如图14所示，至少包括Test Assembly Config Bundle 141、OSGI Bundle 142和OSGI运行时143，其中，所述Test Assembly Config Bundle 141中至少包括一个Test FrameworkTrigger Center Bundle 144：

所述Test Assembly Config Bundle 141，具体用于：

根据通过启动脚本传入的D参数，确定所述OSGI Bundle 142的MF文件的导入导出类；

与所述OSGI运行时143交互隔离测试代码和所述OSGI Bundle 142逻辑代码；

通过所述Test Framework Trigger Center Bundle 144，按照测试用例标识触发相应的测试用例的执行，并按照所述MF文件的导入导出类，通过所述OSGI Bundle 142输出相应粒度的测试结果。

优选的，所述Test Framework Trigger Center Bundle 144，具体用于：

加载OSGI运行时143下的各测试用例信息；

根据通过启动脚本传入的D参数所确定的OSGI Bundle MF文件的导入导出类，控制所有的测试数据包；

测试OSGI Bundle MF文件中新增的标签；

通过测试接口控制与OSGI Bundle MF文件的导入导出类相对应的测试过程范围，并存储相应的测试结果到DB中。

优选的，所述Test Framework Trigger Center Bundle 144，还用于：

通过新建Socket Accepter，以及Accepter端口绑定，实现服务Server的启动和响应端口的开启；

接收输入的测试脚本信息。

优选的，所述Test Assembly Config Bundle 141，还用于：

通过OSGI Layer service/bundle MF方式，控制所述Test Framework TriggerCenter Bundle 144同OSGI运行时143交互，将每个测试用例在运行时所加载的框架业务逻辑同测试代码分离。

优选的，所述OSGI测试框架，还用于：

通过封装或重写的Junit类似功能的测试接口或服务部分，提供给测试用例编写者测试框架接口或服务，为每个测试脚本的每个测试方法提供用例相关信息；

其中，所述用例相关信息包括测试用例的描述、指定过程和执行结果记录；

所述用例相关信息被所述Test Framework Trigger Center Bundle 144在测试用例的触发执行过程中存储到所述DB中。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，通过新的OSGI测试框架理论，更好的动态控制细粒度测试范围，在OSGI环境某些场景下，通过应用框架在启动脚本中传入的细粒度-Dunittesting参数，通过增加MF文件新的标签，动态控制OSGI MF文件的导入导出类，最终从单元测试(集成单元测试)角度编写集成测试脚本测试，最终逐步完善测试场景，并逐步增加遗漏的测试场景范围，可以更好提升OSGI应用框架程序的覆盖率。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备(可以是手机，个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本申请的保护范围。

Claims (10)

1.一种基于OSGI的应用框架测试方法，其特征在于，应用于包括测试组件配置包TestAssembly Config Bundle的OSGI测试框架中，所述Test Assembly Config Bundle中至少包括一个测试框架管理中心包Test Framework Trigger Center Bundle，所述方法包括：

所述Test Assembly Config Bundle根据通过启动脚本传入的D参数，确定应用框架OSGI Bundle的软件架构MF文件的导入导出类；

所述Test Assembly Config Bundle与OSGI运行时交互隔离测试代码和所述OSGIBundle逻辑代码；

所述Test Assembly Config Bundle通过所述Test Framework Trigger CenterBundle，按照测试用例标识触发相应的测试用例的执行，并按照所述MF文件的导入导出类，通过所述OSGI Bundle输出相应粒度的测试结果；

其中，所述D参数为：细粒度-Dunittesting参数；

所述MF文件为：Manifest.MF描述信息文件。

2.如权利要求1所述的方法，其特征在于，所述Test Assembly Config Bundle通过所述Test Framework Trigger Center Bundle，按照测试用例标识触发相应的测试用例的执行，并按照所述MF文件的导入导出类，通过所述OSGI Bundle输出相应粒度的测试结果，具体包括：

所述Test Framework Trigger Center Bundle加载OSGI运行时下的各测试用例信息；

所述Test Framework Trigger Center Bundle根据通过启动脚本传入的D参数所确定的OSGI Bundle MF文件的导入导出类，控制所有的测试数据包；

所述Test Framework Trigger Center Bundle测试OSGI Bundle MF文件中新增的标签；

所述Test Framework Trigger Center Bundle通过测试接口控制与OSGI Bundle MF文件的导入导出类相对应的测试过程范围，并存储相应的测试结果到数据库DB中；

所述Test Assembly Config Bundle通过所述OSGI Bundle输出相应粒度的测试结果。

3.如权利要求2所述的方法，其特征在于，还包括：

所述Test Framework Trigger Center Bundle通过新建Socket Accepter，以及Accepter端口绑定，实现服务Server的启动和响应端口的开启；

所述Test Framework Trigger Center Bundle接收输入的测试脚本信息。

4.如权利要求1所述的方法，其特征在于，还包括：

所述Test Assembly Config Bundle通过OSGI Layer service/bundle MF方式，控制所述Test Framework Trigger Center Bundle同OSGI运行时交互，将每个测试用例在运行时所加载的框架业务逻辑同测试代码分离。

5.如权利要求1所述的方法，其特征在于，

所述OSGI测试框架通过封装或重写的Junit类似功能的测试接口或服务部分，提供给测试用例编写者测试框架接口或服务，为每个测试脚本的每个测试方法提供用例相关信息，其中，所述用例相关信息包括测试用例的描述、指定过程和执行结果记录；

所述Test Framework Trigger Center Bundle在测试用例的触发执行过程中，将所述用例相关信息存储到DB中。

6.一种OSGI测试框架，其特征在于，至少包括Test Assembly Config Bundle、OSGIBundle和OSGI运行时，其中，所述Test Assembly Config Bundle中至少包括一个测试框架管理中心包Test Framework Trigger Center Bundle：

所述Test Assembly Config Bundle，具体用于：

根据通过启动脚本传入的D参数，确定所述OSGI Bundle的MF文件的导入导出类；

与所述OSGI运行时交互隔离测试代码和所述OSGI Bundle逻辑代码；

通过所述Test Framework Trigger Center Bundle，按照测试用例标识触发相应的测试用例的执行，并按照所述MF文件的导入导出类，通过所述OSGI Bundle输出相应粒度的测试结果；

其中，所述D参数为：细粒度-Dunittesting参数；

所述MF文件为：Manifest.MF描述信息文件。

7.如权利要求6所述的OSGI测试框架，其特征在于，

所述Test Framework Trigger Center Bundle，具体用于：

加载OSGI运行时下的各测试用例信息；

根据通过启动脚本传入的D参数所确定的OSGI Bundle MF文件的导入导出类，控制所有的测试数据包；

测试OSGI Bundle MF文件中新增的标签；

通过测试接口控制与OSGI Bundle MF文件的导入导出类相对应的测试过程范围，并存储相应的测试结果到DB中；

其中，所述DB为数据库。

8.如权利要求7所述的OSGI测试框架，其特征在于，所述Test Framework TriggerCenter Bundle，还用于：

通过新建Socket Accepter，以及Accepter端口绑定，实现服务Server的启动和响应端口的开启；

接收输入的测试脚本信息。

9.如权利要求6所述的OSGI测试框架，其特征在于，所述Test Assembly ConfigBundle，还用于：

通过OSGI Layer service/bundle MF方式，控制所述Test Framework TriggerCenter Bundle同OSGI运行时交互，将每个测试用例在运行时所加载的框架业务逻辑同测试代码分离。

10.如权利要求7所述的OSGI测试框架，其特征在于，所述OSGI测试框架，还用于：

通过封装或重写的Junit类似功能的测试接口或服务部分，提供给测试用例编写者测试框架接口或服务，为每个测试脚本的每个测试方法提供用例相关信息；

其中，所述用例相关信息包括测试用例的描述、指定过程和执行结果记录；

所述用例相关信息被所述Test Framework Trigger Center Bundle在测试用例的触发执行过程中存储到所述DB中。