《OSSBSS测试方法》由会员分享，可在线阅读，更多相关《OSSBSS测试方法（9页珍藏版）》请在金锄头文库上搜索。
1、OSS/BSS综合测试方法与实践 摘要 本文分析了对OSS/BSS进行综合测试的意义，重点描述了验证实际系统与设计方案架构一致性的方法；定义了接收测试的范围、目标，介绍了OSS/BSS测试模型和方法。 关键词 OSS/BSS 测试1问题1.1建设情况 OSS/BSS建设朝着集中化、一体化和标准化的方向发展。通过标准的建设，最终能够实现即插即用的目标。符合规范的新系统可以无缝集成到OSS/BSS中，而不会影响系统其它部分。这样，增加新业务，只需要增加新的模块，可以做到标准化的升级，加快了对市场的响应和降低系统开发方面的风险。 从建设方法论方面看，更多的情况是由各有所长的专业厂商共同合作来建设OS
2、S/BSS系统，这样既可以充分发挥各家的特长，又能保证良好的开放性。在国内外多年的建设实践中，开放性、稳定性、伸缩性、扩展性平台化技术体系的思想逐渐形成。主要技术特点如下： 具有良好接口定义的分布式组件、基于已发布接口规范的组件基本属性（信息）交换、共享信息服务、技术规范实施与公共基本架构分离、具有良好接口定义的松耦合分布式组件框架、根据标准参考模型（TMF的相关规范）划分跨组件的业务功能、业务过程控制与组件操作分离、跨组件的共享信息服务和不绑定单一的技术。1.2面临的问题 从OSS/BSS开发实践看，各家厂商共同建设系统，在保证良好开放性的同时，也带来了一些问题，典型的是各厂家的系统差异性较
3、大，数据模型不统一，缺少公共组件，需要重复实现的部分较多；由于分布式软件本身的复杂性，在关注业务的同时，还要考虑复杂的技术问题。 为了全面客观的评价OSS/BSS系统，除了测试系统的业务功能外，还必须对系统的架构、接口规范和数据模型，以及为了保证可扩充性对所使用的组件注册服务等功能进行测试，以保证系统符合设计规定的结构，数据模型符合共享核心数据的要求，满足即插即用的可扩展性要求。 OSS/BSS系统的建设在国内起步较晚，关注的焦点还集中在业务分析、系统建设上，如何测试系统是否符合规划时定义的核心数据模型、业务流程、系统间接口规范以及对实现COTS式组件架构的适应性方面，目前还没有得到足够的重视
4、。缺少这一环节，会增加了投资方的风险，可能使系统的建设达不到预期的效果。那么，如何对OSS/BSS系统进行综合测试？本文将根据电信OSS/BSS实验室的工程经验，从系统、策略和方法的角度进行探讨。2测试方案2.1范围 测试主要涉及5个方面 ： 核心数据模型； 公共通讯平台； 组件接口规范； 外部工作流管理系统； 应用系统集成规范。2.2评定标准 核心数据模型符合性：各应用系统的数据与核心数据模型一致，无歧义，如果有不符合的数据定义，需要使用数据映射、转换等手段，保证经过处理的数据符合核心数据模型。通用通信平台：使用总线架构的模型实现信息交换，支持发送/接受、出版/订阅、广播等消息交换以及支持事
5、务等。 外部的工作流控制平台：保证系统有公共的、在具体应用外部的工作流管理系统来实现对应用流程的调度、配置和调整、版本管理等。组件接口规范：确保组件提供服务和使用服务按照接口规范的定义执行，服务的注册、发布和查找平台符合组件接口规范定义的组件管理平台。应用系统集成规范：各应用组件与应用承载平台以及其它组件间的通讯、管理与被管理，必须符合应用系统集成规范定义的方式和具体平台，是提供组件重用性和保证应用组件能够快速加入系统的关键。2.3测试体系 主要组成：知识库、测试团队、专家组、测试工具、第3方测试认证 图1 测试体系图 知识库是OSS/BSS测试知识的集合，主要包括测试方法、历史数据、专家经验
6、、规范文档、行业资源等。 测试团队：测试管理者、系统分析师、架构设计师、需求分析师、行业专家、测试工程师、文档管理员。 专家组：更强调经验和实践。使来自电信行业、软件技术、软件工程、数据库方面的行业专家、学者。 测试工具：包括通用工具和专用工具。 第3方测试认证：通过实验室测试认证许可的第3方测试的结果，被OSS/BSS实验室认可。2.4模型2.4.1测试环境测试环境由应用承载平台、公共通讯总线、测试工具、测试数据库和分析工具组成。 图2 测试环境组成图2.4.2电信应用承载平台 电信OSS/BSS应用承载平台是我们根据OSS/BSS系统建设实践的需要和参照TMF和NGOSS的相关理论，提出的
7、电信业务组件的运行环境和开发/集成规范，主要包括核心数据、流程管理、系统通信、系统配置、系统管理（监控）、系统安全性、业务组件开发/集成规范等内容，应用承载平台的应用，提高了系统的可扩展性和通用性、伸缩性，保证了快速开发新的业务模块和快速发布以及与第三方软件的集成，使OSS/BSS系统组件开发接近“即插即用”的理想目标。 下图是应用承载平台的结构图。 图3 电信应用承载平台结构图2.4.3测试组件 测试组件是独立的软件组件，属于OSS/BSS解决方案的一部分，在测试时连接到公共通讯总线上；测试组件的主要作用就是收集测试信息，并写入日志，并够生成测试报告。测试组件主要分以下几种类型： 监听器（L
8、istener）监听器就是以非强迫的方式记录事件（如功能调用，消息传递等），它的唯一目的就是记录事件。 装饰器（Facade）装饰器是一类特殊的监听器，区别是装饰是器接受事件，然后把事件传给约定的事件容器，主要作用是对多个测试组件封装。 流程引擎跟踪器（Process Flow Engine Tracer）流程引擎跟踪器和流程引擎交互，生成反映流程引擎实例的生命周期过程信息，如创建的开始、流程的步骤转移以及其它需要完成的各种方式。 组件生命周期管理（Component Life-cycle management） 包括三种功能： 组件查找（Look-up）查找贯穿OSS/BSS解决方案的全部。
9、这步的工作是在OSS/BSS测试时查找系统所有的组件。 组件发现（Component discovery）该功能只能运行在OSS/BSS系统中，当新的组件进入OSS/BSS系统时，发现平台必须能够发现新组件。 组件失效（Component unavailability）发现事件对应的组件卸载或处于非激活状态，该功能是可选的。2.5方法2.5.1核心数据模型 测试方法 专家组评审应用系统数据模型设计文档，考核数据模型的逻辑关系是否与核心数据模型的定义一致，包括属性、组件间的逻辑关系、扩展规则等。 测试组件 通过核心数据模型的接口，获得应用系统提供的数据，与标准数据比较属性类型、字长等，并给出比较
10、结果。 异常 不能返回符合条件的属性，或字长不一致等。2.5.2公共通讯平台 测试方法 在系统级全网络范围检查通讯机制是，由于系统一般有多个消息源和不止一个消息，因此要求系统的所有组件应该共享相同的通讯架构。 具体的实现可以有多种通讯架构，如细粒度的组件内部也可以有通讯架构。所有的组件应该对信息有共同的解释，如消息、事件的定义以及警告的组成等。 前面提到的测试组件都可以用于该项测试：监听器主要用在测试publish/subscribe 通讯平台，该组件可以.订阅并记录所有的消息，如：组件发布消息和消息的格式； 装饰器组件用于测试 request/response 类型的通讯平台，功能与监听器类
11、似，如：组件发布请求、消息路由以及请求和相应响应的格式。 注册查找组件用于搜索系统组件的注册信息。 测试组件 OSS/BSS组件间的通讯必须使用语义一致的消息，但是我们无法限制在组件的生命周期中只用一种方式I/O，如GUI接口可能不使用信息总线，组件启动时的配置夜可能是直接读文件的方式。全部组件通讯均通过公共通讯平台是很必要的，可能的测试方式就是我们捕获系统的全部I/O，然后进行校验。 异常 如果测试中发现组件的通讯未通过公共通讯平台，则应作为异常报告。典型的情况如：组件不使用公共通讯平台（Components not talking to the Common Communications
12、Vehicle）、旁路公共通讯平台（Bypassing the Common Communications Vehicle）和跨接（Bridging即跨越几种通讯机制的通讯，这种异常要具体分析）。2.5.3组件接口规范 测试方法 测试全部组件接口的规范性，必须保证组件的接口与规范文档一致。测试标准是定义一组清晰的数据集合，数据在组件中传输并处理，输出应该是校验过的正确数据。 测试组件 定义了OSS组件提供服务的高层抽象。通过独立的OSS组件可以对接口规范进行试验和测试。 首先进行的测试是在独立的组件级通过检查组件设计文档来检查接口规范的设计。这样的做的目的是确保接口规范设计符合正规的设计规范。
13、符合规范的定义和使用，主要表现在通过组件提供服务，包括前置条件、后置条件和异常等。 推荐使用 DTD or XML Schema 和自动化测试工具，以确保系统符合架构设计规范。在检查接口规范设计之后，使用自动化测试工具测试OSS组件，进行实际接口实现的功能校验。组件测试必须强调在符合前置条件，如果超出前置条件，可能会遇到或产生不一致的状态。任何自动测试工具应该确保对给定服务在规定前置条件下完成测试。当然，对于不需要任何前置条件的服务的测试，则需要前置条件。 同样需要确保符合后置条件的规范，这种测试通常在系统测试中要多于一致性测试。组件如果不能生成期待的后置条件，通常认为不符合接口规范定义规范。
14、 需要说明的是：任何自动化测试工具都应能够保证在规定的前置条件下进行测试。异常 自动化测试工具应该能够主动产生异常，以测试接口规范中定义的异常。2.5.4外部工作流管理系统 测试方法 必须测试流程计划通过注册在流程引擎中生效的过程。该测试确保过程流可以独立于软件实现进行修改。因为有多种方式注册流程计划和规范流程计划，所以该项测试是技术独立的。当前我们是通过描述文件来实现流程计划注册的。 确保在解决方案中流程引擎根据流程计划选择请求类型的接口规范，然后搜索符合流程每个步骤的商业接口规范实现，该步骤保证在业务组件撤除/替换/安装情况下，流程引擎能够整常运行。 装饰器（Facade）组件对象将用于流程引擎测试，该对象能够记录每个商业接口规范的调用以及调用的输出同时提供任意点的全局解决方案状态视图。主要测试点是：支持商业流程的变化、支持多个商业流程的变化和通过几个商业场景的服务/接口规范重用。 测试组件 通过分析fa?ade object 跟踪记录的流程引擎日志来实现组件测试。该对象也连续记录系统的全局状态信息，这些状态信息可以和流程引擎记录的状态信息进行比较，通过这些工作确保过程引擎在运行时任何时刻拥有系统的全局状态信息。异常 流程引擎测试的异常类型很多，
