dle把复杂的应用程序模块化后，在OSGI的框架中，Bundle的生命周期由OSGI运行环境进行管理；Bundle之间以松耦合的形式相互依赖；而OGSIBundle有严格的访问安全限制，为了最终完成细粒度的单元测试和集成测试，本文提供的新的测试体系去解决Bundle访问权限的限制，测试脚本与被测Bundle及其依赖的Bundle同时运行于OSGI环境中；同时完成将测试代码和业务代码分离。
[0094]基于OSGI的Equinox为Java程序在模块化管理和开发提供了优势，在OSGI中以Bundle作为程序编写的模块,每个Bundle包含相关Java逻辑类和相关Bundle的附加的Manifest.MF描述信息文件，OSGI运行时框架维护了每个Bundle的生命周期，以及各个Bundle的启动中相互依赖和运行期调用关系。因此在OSGI框架体系下，编写的测试脚本需要运行在OSGI的运行时Runtime中，且每个单元测试或集成测试脚本需要多个OSGIBundle相互依赖调用。针对现有的普通的JUnit、TestNG测试理论和方法，并没有针对OSGI体系在Bundle模块化和隔离机制提供相应的测试方法。
[0095]同时Bundle模块化管理和隔离各个Bundle的限制，也会使得现有的Java测试Junit/TestNG无法直接应用于OSGI运行时框架。OSGI Plug In/Bundle对其包含的Java包有严格的访问限制，仅在MF文件中定义的少数的接口包能够被其他的Bundle加载依赖至IJ。在公司基础框架和容器测试时需要测试Bundle内非Public的包对应的框架实现。
[0096]在编写测试代码需要避开Bundle的访问限制,测试Bundle内部非public包的单元测试(Bundle之间单元测试)成为测试中一个新的难点，QA同学需要实现运行测试用例过程后完全不需要额外工作来去除测试代码，不影响运行期基础框架和容器的功能。
[0097]在OSGI基础上的容器框架分离测试代码和基础框架和容器代码，同时保证测试代码访问框架逻辑进行测试时又不影响框架逻辑，在业界有很多的OSGI测试解决方案。本文将针对现有存在的测试OSGI解决方案之上提出一套新的测试理论方法
[0098]现有OSGI测试框架基础原理介绍，首先针对Test Suite中包含了所有的测试代码，测试代码编写可以基于JUnit或TestNG等其他自定义测试框架封装的测试代码。在基于OSGI开发的应用框架，通过启动脚本或其他形式在初始化应用程序时，现有编写好的每个TestSuite都会注册到测试框架管理中心Test Framework Trigger Center Bundle,其中注册测试用例相关的信息，包含测试用例名称、测试描述、测试类、测试方法、测试步骤描述、测试预期结果，当应用框架启动成功后，所有相关测试实例都已经被注册到了测试框架管理中心；在OSGI框架运行时阶段针对这些存储好的测试用例，可以通过用例唯一标识(用例名称或用例ID号)触发对应的测试用例执行，最终将获取的测试用例返回结果同预期结果比对后存储数据库DB，或展示在web页面，框架原理图如图7所示。
[0099]Test Framework Trigger Center Bundle 在 OSGI 测试体系中控制每个 TestSuite初始化的测试用例，并统一注册到测试运行时框架中，在测试报告上可以指定用户输入的单个测试脚本、分功能批次或指定所有测试脚本运行产出，通过运行期控制每个测试脚本对应的Test Suite (类对象)，从Bean实例层面执行Test Suite中对应方法进行框架功能验证，最终Test Framework Trigger Center Bundle会将每个测试脚本指定的结果存储到DB中，并在web UI中展示给测试用用户。
[0100]OSGI框架是面向服务架构，系统bundle之间对象交互、服务的发布、引用方式是测试中需要着重突破点。这两部分在OSGI下bundle逻辑可以通过配置MANIFEST.MF文件，主要配置 Import-Package、Export-Package> DynamicImport-Package 等配置项来实现，服务service的交互可以有两种方法实现:
[0101]一种是通过实现 BundleActivator 接口，在 MANIFEST.MF 中指定Bundle-Activator配置,如之前的图2所示；
[0102]另一种是通过Declarative Services的方式实现，需要在MANIFEST.MF中指定Service-Component配置,此方式也是推荐使用的方式,通过DS提升了 Service发布和使用的简便性，可以很好的将Moudle分解为Component+Service的模式,并且无需编写java代码，所有的配置通过xml文件即可实现。配置文件大致如之前的图3所示。
[0103]在具体的应用场景中，在引用策略的定义上可有两种方式static(默认)、dynamic,若设置成static, —旦引用的服务发生变动整个Compont便会重启，设置成dynamic,服务发生变动只是调用其中的bind和unbind方法，cardinality的值主要是
O,1，N三个数的组合。
[0104]如果系统中存在多个可引用的服务，但cardinality规定至多引用一个服务，这种情况下，一旦component所引用的服务stop,该component首先执行的并不是其unBind方法，而是继续寻找新的可用服务调用其bind方法进行绑定，然后才会调用其unBind方法对之前引用的服务进行解绑户。
[0105]综合考虑上述因素，本申请提出相应的解决方案，如图8所示，为本申请实施例所提出的一种具体应用场景下的基于OSGI的应用框架示意图。
[0106]这块内存区域与现有技术中所提到的测试框架有所区别，具体说明如下:
[0107]首先，重构Junit原生框架或重写一套新的测试框架，提供类似Junit的基本的测试接口或服务，尽量简单化和轻量化，提供基本的用例ID、用例描述、用例过程信息、用例结果等接口；其次，OSGI测试框架管理中心Bundle-Test Framework Trigger CenterBundle,将根据每个用例的ID进行Trigger触发用例执行，最终将执行结果存储到DB，另一方面，通过OSGI Layer service/bundle MF方式，OSGI测试框架管理中心Bundle控制同OSGI运行时交互，将每个用例运行时加载的框架业务逻辑同测试代码分离；再次，由于公司是基于Eclipse Equinox OSGI开发的应用技术框架，在OSGI运行时控制加载OSGIBundle下export哪些Package,初始化和动态运行加载的类最终提供给上层应用框架使用者(或测试脚本编写者)，最终export给用户的osgi Package或ap1、OSGI注册表中心发布和订阅服务关系都是固定的，为了更细粒度的测试，我们需要在这个新的OSGI测试体系下，控制export给用户的Package,以及需要测试Bundle在测试过程中Import哪些Package。
[0108]基于Eclipse Equinox OSGI 开发的应用技术框架，基于 OSGI Layer service/bundle MF来编写新的OSGI测试方案，将测试中的service或实例对象注册到OSGI运行时中，通过实现 Bundle Activator 接口，在 MANIFEST.MF 中指定 Bundle-Activator 配置(图
2);或通过Declarative Services的方式实现(图3),将运行时测试脚本服务或测试对象注入到OSGI中。
[0109]新的测试框架中Test Framework Trigger Center Bundle 作为 Test AssemblyConfig Bundle多个Package形式存在,主要为原生测试框架提供的服务或Interface、TestSuit编写维护、测试脚本触发和测试结果DB落地、以及测试结果展示，
[0110]OSGI 测试框架方案中 Test Framework Trigger Center Bundle 部分,测试用例触发逻辑部分是启动server以及打开响应的端口，接收测试用户输入的测试脚本信息，触发执行对应的测试脚本并存储测试结果到DB中，具体如图9所示。
[0111]另一部分是在Junit或自定义测试框架部分，提供给测试用例Test Suit编写者一些测试框架接口或服务，是封装或重写的Junit类似功能的测试接口或服务部分，给每个测试Test Suit的每个测试方法提供用例的描述、指定过程和执行结果记录，此部分用例相关信息会在用例触发执行时存储到DB中，具体如图10所示。
[0112]新的测试框架中Test Assembly Config Bundle部分可自定义测试本Bundle的MF文件导入导出的类、通过启动脚本传入的-D参数，控制应用框架OSGI Bundle的MF文件的导入导出类、以及负责OSGI运行时交互隔离测试代码和应用框架逻辑代码，由于OSGIBundle类加载体系隔离特性，使得部分类在测试过程中不可见，通过控制OSGI Bundle的导入导出类，可以在OSGI环境下，针对不同测试脚本标识，更好的进行细粒度测试类或代码逻辑的测试，具体如图11所示。
[0113]最后，给出基于上述策略的测试实现和相关测试结果，如图12所示。
[0114]测试用例触发逻辑部分相关代码和实现，如图13所示。
[0115]与现有技术相比，本申请实施例所提出的技术方案具有以下优点:
[0116]通过应用本申请实施例的技术方案，通过新的OSGI测试框架理论，更好的动态控制细粒度测试范围，在OSGI环境某些场景下，通过应用框架在启动脚本中传入的细粒度-Dunittesting参数，通过增加MF文件新的标签，动态控制OSGI MF文件的导入导出类，最终从单元测试(集成单元测试)角度编写集成测试脚本测试，最终逐步完善测试场景，并逐步增加遗漏的测试场景范围，可以更好提升OSGI应用框架程序的覆盖率。
[0117]为了实现上述的技术方案，本申请实施例提供了一种OSGI测试框架，其结构示意图如图 14 所不，至少包括 Test Assembly Config Bundle 141、0SGI Bundle 142 和 OSGI 运行时 143,其中，所述 Test Assembly Config Bundle 141 中至少包括一个 Test FrameworkTrigger Center Bundle 144:
[0118]所述Test Assembly Config Bundle 141,具体用于:
[0119]根据通过启动脚本传入的D参数，确定所述OSGI Bundle 142的MF文件的导入导出类；
[0120]与所述OSGI运行时143交互隔离测试代码和所述OSGI Bundle 142逻辑代码；
[0121]通过所述Test Fr