（计算机应用技术专业论文）基于消息的接口测试平台的研究与实现.pdf

摘要 软件测试是在软件投入生产性运行前，对软件需求分析、设计规格说明和编 码的最终复审，它是软件质量保证的关键步骤。而各种各样的软件测试技术在确 保软件质量方面发挥着不可替代的作用。 随着分布式计算技术的发展，应用系统的规模日益庞大，并逐步向分布式发 展。应用系统分布在网络上的各部件在遵循统一规范的基础上松耦合互联。这种 方式增强了系统的灵活性与可扩展性，同时也对测试人员提出了新的挑战。在电 信领域，电信业务运营支撑系统就是一个典型的分布式系统。 本文研究了分布计算环境下的软件测试方法，以及软件测试技术在电信业务 运营支撑系统中的应用。并根据目前接口测试的现状与需求，对可用于接口测试 的测试平台进行框架性研究，提出一个面向消息交互的接口测试平台的总体结 构，并对电信业务运营支撑系统软件消息接口的x m l 规范化表示进行了研究。 最后通过原型系统的实现验证了接口测试平台总体结构的可行性。 关键词：软件测试，分布式系统，接口，咀。s c h e m a a b s t r a c t s o f t w a r et e s ti saf i n a lr e v i e wt ot h es o f t w a r er e q u i r e m e n ta n a l y s i s ，d e s i g n s p e c i f i c a t i o n ，a n dc o d eb e f o r es o f t w a r eb ep u ti n t oa c t u a lr u n n i n g i t sak e yp r o c e s s o fs o f t w a r eq u a l i t ya s s u r a n c ei nw h i c hv a r i o u st e s t t e c h n o l o g yp l a y sa ni m p o r t a n t r o l e a l o n g w i t ht h e d e v e l o p m e n t o ft h ed i s t r i b u t e d c o m p u t i n gt e c h n o l o g y , a p p l i c a t i o n sb e c o m el a r g e s c a l e a n dd i s t r i b u t e d g r a d u a l l y e a c hc o m p o n e n to f a l l a p p l i c a t i o ni s i n t e r l i n k e dl o o s e l yc o u p l e do nt h eb a s i so fau n i t e dc d t e r i o n t h i s s t r e n g t h e n st h ef l e x i b i l i t ya n de x t e n s i b i l i t yo fa p p l i c a t i o n s t h es a m et i m e ，i t san e w c h a l l e n g et ot h et e s t e r i nt h et e l e c o ma r e a ，t h eb u s i n e s sa n do p e r a t i o ns u p p o r t i n g s y s t e m i sa t y p i c a ld i s t r i b u t e ds y s t e m t h i st h e s i ss t u d i e st h es o f t w a r et e s tm e t h o di nt h ed i s t r i b u t e d c o m p u t i n g e n v i r o n m e n ta n dt h et e s tt e c h n o l o g y su s ei nt h eb u s i n e s sa n do p e r a t i o n s u p p o r t i n g s y s t e m 。t h et h e s i ss t u d i e st h ef r a m e w o r ko fat e s tp l a t f o r mu s e df o rt h ei n t e r f a c e s t e s t i n g ，c a r r yo u t t h e g e n e r a ls t r u c t u r eo f t h e t e s tp l a t f o r m ，d e s c r i b et h ei n t e r f a c ei nt h e b u s i n e s sa n do p e r a t i o ns u p p o r t i n gs y s t e mi nx m ls c h e m a i nt h ee n d ，t h et h e s i s v a l i d a t e st h e f e a s i b i l i t yo f t h eg e n e r a ls t r u c t u r eb y t h er e a l i z a t i o no f a p r o t o t y p e k e y w o r d s ：s o f t w a r et e s t ，d i s t r i b u t e ds y s t e m ，i n t e r f a c e ，x m ls c h e m a 基于消息的接口测试平台的研究与实现 1 1 课题背景 第一章绪论 随着中国电信改革的逐步深化及电信行业的不断开放，电信市场的竞争越来 越激烈。各大电信运营商为了保持和扩大相对的竞争优势，纷纷引入电信业务运 营支撑系统来支撑电信业务的运营流程。目前，支撑系统的建设正在向集中化的 方向发展，规模越来越大、功能越来越复杂，同时面向多层次多业务。传统的软 件结构和设计已很难适应支撑系统不断发展的现状。 在新一代支撑系统的建设过程中，大量的新思想和新技术得到采用，比如软 件总线、多层结构、面向对象、中间件、数据仓库等。新技术的采用提高了电信 业务运营支撑系统的水平同时也对支撑系统的质量提出了新的挑战。在建设电 信业务运营支撑系统的过程中，软件测试技术提供了必不可少的质量保证和信心 保证。 中国联通组织开发的电信业务运营支撑系统的实施思路是“一个体系结构， 多个子系统”【l 】，其中包括客户资料管理、营业、帐务、信用管理、缴费等多个 子系统。为规范电信业务运营支撑系统的建设，中国联通发布了支撑系统的接口 规范，对各子系统之间以及支撑系统与其它系统之间的交互内容和接口格式作了 较详尽的规定。该接口规范有一定的抽象性，并不限制各软件厂商采用何种技术 路线来实现系统接口。测试这样复杂的系统难度很大，尤其是各个子系统之间的 接口如何测试更是难点所在。 目前，国内软件厂商基本上还是采用手工测试的方法来进行功能测试，对于 接口测试还没有一个统一的、严格的测试方法。 1 2 论文主要工作和成果 本论文的目标是研究软件测试技术，并根据目前接口测试的实际需求设计一 个面向消息交互的接口测试平台。 本论文的研究内容主要包括以下四个部分： 对分布计算环境下的软件测试方法进行研究，并研究软件测试技术在电 信业务运营支撑系统中的应用。 研究电信业务运营支撑系统软件消息接口的x m l 规范化表示方法。 对面向消息交互的接口测试平台进行框架性研究，提出一种基于x m l 技术的接口测试平台的总体结构。 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 按照上述总体结构，设计并实现接口测试平台的原型系统，验证上述总 体结构的可行性。 通过以上研究，本论文取得的主要成果包括： 研究了分布计算环境下的软件测试方法。 研究了软件测试技术在电信业务运营支撑系统中的应用。 对电信业务运营支撑系统软件消息接口的数据结构用x m l s c h e m a 进行 了规范化描述。 设计了一个基于x m l 技术的接口测试平台的总体结构，给出了系统的 基本设计思路和技术实现方案。 基于上述总体结构，设计并实现了一个接口测试平台原型系统。 1 3 论文结构 本论文按以下章节组织： 第一章是绪论部分，简要介绍本论文的有关背景、工作内容及成果。 第二章介绍软件测试技术的基础知识，研究分布计算环境下的软件测试方 法，以及软件测试技术在电信业务运营支撑系统中的应用。 第三章对面向消息交互的接口测试平台进行框架性研究，提出一个基于 x m l 技术的接口测试平台的总体结构，并对电信业务运营支撑系统软件消息接 口的x m l 规范化表示进行了研究。 第四章介绍基于上述总体结构的一个接口测试平台原型系统。 第五章对本文作简单总结，指出论文存在的不足以及将来需要做的工作。 文章的最后是术语表、参考文献列表和致谢。 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 第二章软件测试技术及其在电信领域的应用 随着中国电信改革的逐步深化及电信行业的不断开放，电信市场的竞争越 来越激烈。国内各大运营商为了保持和扩大相对的竞争优势，不断引入新业务 和新技术，这就使电信业务运营支撑系统始终处于不断变化、不断发展的状态。 在建设电信业务运营支撑系统的过程中，软件测试技术提供了必不可少的质量 保证和信心保证。 2 1 软件测试技术 2 1 1 软件测试的概念及历史 所谓软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和 编码的最终复审，它是软件质量保证的关键步骤。i e e e 对软件测试的定义是： “使用自动或人工的手段来运行或测定某个软件系统的过程，其目的在于检验 它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。gj m y e r s 认 为“程序测试是为了发现错误而执行程序的过程”1 5 。 软件测试的概念来自于程序正确性测试，但是软件测试与程序测试是有区 别的。因为软件文档也是软件产品的重要组成部分，也是检验软件质量的重要 对象。广义的测试是贯穿于整个软件开发过程各个阶段的复查、评估与检测活 动，统称为确认、验证与测试活动。 最早的软件测试方面的文章见于二十世纪五十年代。二十世纪七十年代， 程序设计方法学的发展促进了软件测试的研究与进展，软件测试的理论基础初 步建立，各种软件测试技术和方法蓬勃发展，并日趋成熟。二十世纪七十年代 以来，软件测试的理论和技术在应用的广度和深度方面都获得了巨大的进展， 特别在工程化、标准化和规范化方面有了很大的发展，使软件测试成为改进和 提高软件质量的有效和不可缺少的方法。 2 1 2 软件测试的目的 软件测试的首要任务是发现错误。软件测试是检查被测软件中是否存在错 误的过程，其目标在于以最少的时间和人力找出软件中潜在的各种错误和缺陷。 如果在测试中发现了错误则表明程序存在错误，如果没有发现错误也不能说明 程序没有错误，但是可以提高人们对程序的信赖程度。软件测试的第二个目的 是对于给定的测试包，说明被测系统是符合规约所描述的需求的。 当测试的目的是从测试失败中发现故障时，测试是故障导向( f a u l t d i r e c t e d ) 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 的。当其目的是证明符合要求的能力时，测试是符合性导向 ( c o n f o r m a n c e d i r e c t e d ) 的。单元测试和集成测试通常更趋于故障导向，而系统 测试则更趋于符合性导向。但这两种e t 标并不是相互排斥的，许多测试设计技 术是二者兼顾的。 2 1 3 软件测试分类和软件测试技术 软件测试可以按照不同的原则来分类。按实施步骤测试可分为单元测试、 集成测试、系统测试、验收测试等，上述测试阶段构成了软件开发过程中完整 的软件测试工作。按测试对象测试可分为软件单元测试、软件部件测试、软件 配置项测试和系统测试。按软件的组装策略测试可分为增量测试、非增量测试， 其中增量测试又分为自顶向下、自底向上等。按测试项目测试可分为功能测试、 性能测试、接口测试、界面测试、安装测试、强度测试、可靠性测试、安全性 测试、可恢复性测试等。根据是否需要实际运行被测程序，常用的软件测试技 术可分为静态测试和动态测试两类，动态测试又可分为黑盒测试和白盒测试。 下面对各种软件测试技术作简要介绍。 2 1 3 1 静态测试技术 静态测试的基本特征是在对软件产品进行分析、检查和测试时不实际运行 被测程序。静态测试包括主要由人工进行的代码审查、代码走查以及主要由软 件工具自动进行的静态分析，广义的静态测试还包括需求分析阶段和软件设计 阶段的技术评审。 静态测试的对象包括需求文档、设计文档、以及程序代码。静态测试可以 完成代码审查和走查、一致性检查、错误检查、接口分析、输入输出规格说明 分析、控制流分析、数据流分析、类型分析、单元分析等职能。 2 1 3 2 动态测试技术 动态测试通过实际运行被测程序来检验软件的动态行为和运行结果的正确 性。动态测试的三个基本要素是被测程序、测试数据、软件需求和功能规约。 根据测试理论，如果测试数据满足一定要求，通过测试可以发现程序中的大多 数错误，并且可以评估程序的质量。 动态测试的核心内容有三部分：测试用例( 含测试数据) 生成、测试执行、 测试结果评价。围绕核心的其它工作还有文档编制、数据管理、操作规程化、 测试环境配置与管理、工具应用、测试的组织与管理等。其中，测试用例生成 是动态测试能否成功的关键所在。生成测试用例的基本策略有黑盒测试和白盒 测试。 北京邮电大学硕士学位论文 4 基于消息的接口测试平台的研究与实现 黑盒测试也叫数据驱动测试和功能测试，是一种按照需求规格说明设计测 试用例的测试方法。它把程序看成是内部不可见的黑盒，完全不需要考虑程序 的内部结构和编码结构。测试人员只需了解程序输入与输出之间的关系或仅仅 是程序的功能，根据需求规格说明来设计测试用例和评价测试结果。黑盒测试 比较容易生成测试用例，适用于程序测试的各个阶段。黑盒测试技术包括功能 分解、等价类划分、边界值分析、因果图、随机测试等。 自盒测试也叫逻辑驱动测试和结构测试，是一种按照程序内部的逻辑结构 和编码结构设计测试用例的测试方法。自盒测试包括控制流测试、数据流测试、 域测试、符号测试、程序插装、程序变异测试等。白盒测试生成测试用例比较 困难，通常仅用于单元测试。控制流测试用控制流程图来检查程序的控制结构。 控制流测试策略包括语句覆盖法、分支覆盖法、条件覆盖法、条件组合覆盖法、 路径覆盖法等。数据流测试用控制流程图来分析数据异常，并从揭示数据异常 的角度来选择测试路径，它通过检查程序中每个数据对象赋值和引用间的各种 次序以期找到可能的错误。数据流测试策略包括全定义一使用路径、全使用策略 等。 2 1 4 软件测试自动化与软件测试工具 软件测试是一项繁琐和复杂的工作。同时，软件测试的许多操作是重复性 的、非智力创造性的、需求细致注意力的工作，非常适合用计算机代替人去完 成这些任务。有效地利用测试工具进行软件测试自动化可以减轻软件测试人员 的工作量，提高测试的效率和质量，从而降低软件的开发成本、缩短开发周期、 提高软件质量。 软件测试自动化是与手工测试相对应的一个概念，指的是自动化的测试执 行技术，它对测试的经济性和可修改性有很大影响。为了实现高效的自动化测 试，必须借助于软件测试工具，并在好的测试软件的基础之上应用自动化技术。 软件测试活动不仅仅是运行测试本身，软件开发生命周期的v 模型强调了 软件开发过程中的各个测试阶段，并明确表示了软件开发过程中各个中间产品 之间的关系。成功应用v 模型的关键是何时设计测试用例发现缺陷的效果最好， v 模型中软件开发过程的每个阶段都有相对应的测试工具来支持，见图2 1 。其 中，测试设计工具有助于准备测试输入或测试数据，逻辑设计工具用来生成测 试用例，物理设计工具操作已有的数据或产生测试数据，静态分析工具用于分 析程序代码、检测程序缺陷，覆盖工具用于评估被测软件被测试执行的程度， 动态分析工具用于动态评估被测系统，性能测试工具用于性能测试和压力测试， 测试执行和比较工具用于测试的自动执行和测试结果的比较，测试管理工具帮 助测试人员完成测试计划、跟踪测试运行结果。而调试工具并不是真正的测试 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 工具，它常被用于定位被测软件中的错误和缺陷。 图2 1 软件开发的v 模型及软件测试工具 图2 1 中，测试设计工具、逻辑设计工具和物理设计工具属于测试数据生成 器的范畴；测试管理工具、测试执行和比较工具、覆盖工具属于测试辅助支持 工具的范畴；测试数据生成器、动态分析工具、性能测试工具、测试辅助支持 工具统称为动态测试工具。 与手工测试相比，自动化测试有很多优点。测试人员可以在较短的时间里 运行更多更频繁的测试，且测试具有一致性和可重复性。测试人员可以很方便 地进行回归测试，执行一些难以进行手工测试或无法用手工测试来实现的测试。 测试人员可以更快地进行错误定位，对整个测试过程和所有的测试资源进行有 效管理。有效运用软件测试自动化技术可以缩短软件产品的测试时间，更快地 将软件推向市场。 一些适于考虑进行自动化测试的操作有： 夺测试用例的生成( 包括测试输入、标准输出、测试步骤、测试操作指令 等) 。 夺测试的执行写控制( 包括单机与网络多机分布运行；夜间及假日运行； 测试用例调用控制；测试对象、范围、版本控制等) 。 夺测试结果与标准输出的对比。 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 夺与标准输出不吻合的测试结果的分析、记录、分类、和通报。 夺总测试状况的统计，统计报表的产生。 虽然自动化测试有很多优点，但它并不能解决所有的测试问题。自动化测 试不能提高测试的有效性，只能减少测试的开销和时间。进行自动化测试需要 耗费大量的计算机资源，且自动化测试需要维护。自动化测试不能取代手工测 试，很多情况下的测试不适合进行自动化测试，例如：很少运行的测试、运行 结果很难定量衡量的测试、涉及物理交互的测试，以及软件的版本更替很频繁、 功能和界面的变化都很大时。 由此可见，手工测试与自动化测试各有所长。在着手制定测试策略时就应 该弄清哪些部分进行手工测试，哪些部分可以进行自动化测试，即使在使用自 动化测试的部分也要考虑用手工测试加以补充。 2 2 分布计算环境下的软件测试 分布计算环境下的软件测试指的是对分布计算环境下的应用软件进行的测 试。分布式应用系统( 以下简称为分布式系统) 是指由相互连接的分布在网络 上的各部件组成的应用系统，分布在网络上的各部件可以相互通信和协作以完 成一个共同的任务。它是一些独立的应用系统的集合，但对其用户来说又是一 个单一、完整的应用系统。目前，人们构造的各种分布式系统已广泛应用于各 个领域，如电信业务运营支撑系统、各种w e b 应用等。 分布式系统的主要特征有：资源共享，包括软、硬件资源的共享；透明性， 包括访问透明性、位置透明性、并发透明性、副本透明性、故障透明性、迁移 透明性等：开放性，包括系统的可扩展性、可移植性和互操作性；并发性，一 种是多个用户同时发出命令并与机器交互；另一种是多个服务进程并发运行， 分别响应不同的客户请求：没有全局性的时钟，各软件部件通过交互信息来协 调各自行为。 2 2 1 分布式系统的体系结构模型 由于分布式系统结构多样，涉及不同的系统体系结构，异构是不可避免的。 为了在异构环境下实现信息和软件资源的共享，先后发展形成了几种主要的分 布式系统体系结构模型。 客户机服务器模型是最简单的分布式模型。在这种模型下，多台客户机都 能够访问服务器。服务器是单一进程，多个数量不确定的客户机进程要求服务 器提供服务。在基本的客户机服务器模型中，当服务器出现问题时，所有的客 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 户机都会受到影响。为了消除这一缺陷，在体系结构中引入多台服务器。多台 服务器提供相同的服务，客户机可以同任意一台服务器进行通信。 随着面向对象技术的发展及其与分布式技术的结合，出现了分布式对象技 术。分布式对象技术在分布式异构环境下建立应用系统框架，支持对象跨越不 同的软硬件平台进行互操作。目前，主要的分布式互操作标准有o m g 组织的 c o r b a ( 公共对象请求代理体系结构) 标准、m i c r o s o f t 的d c o m ( 分布式组件 对象模型) 标准、s u n 的j a v ar m i ( 远程方法调用) 标准。c o r b a 是o m g 组 织开发的分布式对象系统的标准架构，这种体系机构的中心元素是对象请求代 理( o r b ) 。一个对象通过o r b 与系统中的另一个对象进行通信。由符合c o r b a 的系统提供的标准基础结构也能提供这样的服务，它允许一个对象找到其它被 请求、定位或加载的对象。这种“标准体系结构”并没有详细指明实现，不同 厂商提供的组成这种模型的基础结构的软件产品也有很大的不同，因此c o r b a 在灵活性上有很大的优势。c o r b a 标准建立在下面的假设上：与基础结构联系 的机器可能有不同的操作系统和不同的存储设计；构成分布式系统的组件可以 用不同的语言编写：根据对象的分布性和网络中机器的类型，基础结构可以改 变它自身的配置。d c o m 是m i c r o s o f t 开发并鼓励的一种标准。它的每个标准接 口都提供了一套特定服务。j a v a 中的r m i 提供一种简化的分布式环境，该环境 假定不论连接的是什么类型的机器，它们都能够运行j a v a 虚拟机。r m i 提供一 个注册对象，参与分布式系统的所有对象必须知道该注册对象监听到哪个端口 的消息。r m i 的最新版本使用o r b 之间的i n t e m e t 协议( i i o p ) 来使r m i 对象 和c o r b a 对象共同工作。 2 2 2 一般分布式模型 图2 2 分布式系统的一般体系结构 图2 2 是分布式系统的一般体系结构，其主要活动就是服务请求方给服务提 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 供方发送消息。请求首先被发送到请求方本地的代理对象，所以请求方不会对 任何分布式本身的语义进行处理。代理方联系通信基础结构并传送请求。通信 基础结构可能实际上不得不实例化服务提供方，但它最终将从对象定位器( o b j e c t l o c a t o r ) 的服务中获取服务方的引用，并将请求传递给它。请求代理方( r e q u e s t s u r r o g a t e ) 可以引导请求，所以提供方并不知道分布的细节。如果存在任何结果 的话，这些结果就按照原路径被返回。从这个层次上来说，c o r b a 、d c o m 、 r m i 这三种模型是相同的。 在该模型中，提供方是分布式系统的中心，它执行一系列活动，并在某些 情况下将信息返回给请求方。提供方需要注册它的基础结构，同时还要注册它 所能提供的服务。存根( s t u b ) 是请求方进程中的提供方代理，它使得请求方不 需要了解基础结构的语义。而请求方是作为一种刺激因素参与在分布式系统中 的，大纲( s k e l e t o n ) 是请求方的代理。 2 2 3 一般分布式模型的测试 上述每种模型都产生了一套自己的设计模式，反过来这也导致出现了相应 的测试方法。下面介绍一般分布式模型的测试要点。 对提供方组件的测试： 夺检查提供方的一整套服务是否完整。 夺对提供方的每个对象迸行充分彻底的测试。 夺对提供方的服务进行测试时，提供方应该与请求服务且具有代表性的请 求方交互。每个主要的协议都应得到测试，且至少有一个请求方参与到 这个协议中。 夺对提供方的对象朋艮务进行生命周期测试。 对请求方组件的测试： 夺检查请求方是否能够访问它所需的全套服务。如果请求方会同时用到多 个提供方，那么就必须确定不同的提供方就同一个服务来说是否会提供 相互一致的结果。 夺检查每个请求方方法会在正确的时间调用正确的服务。 夺测试请求方与每个提供方之间的完整协议。 夺对请求方进行生命周期测试。 分布式的不同模型对应用类型和发布环境做出了不同的假设，这些都应该 北京邮电大学硕士学位论文9 基于消息的接口测试平台的研究与实现 是测试的焦点。对分布式系统的测试还必须考虑语言依赖问题和平台独立问题。 另外，分布式系统测试的重点是提供方与请求方之间的协议，也就是需要重点 测试提供方与请求方之间的消息传送是否满足协议要求，比如消息交换的顺序 等等。 2 3 软件测试技术在电信业务运营支撑系统中的应用 电信业务运营支撑系统是电信运营商为支持电信业务的经营活动而构造的 管理系统。目前，国内新兴的电信运营商大多数采用集中化的思路建设支撑系 统，一些传统的电信运营商也在向集中化过渡。集中化的发展方向决定了支撑 系统在规模越来越大、功能越来越复杂的同时向多层次多业务的方向发展，传 统的软件结构和设计已很难适应支撑系统不断发展的现状。 在新一代支撑系统的建设过程中，大量的新思想和新技术得到采用，比如 软件总线、三层结构、面向对象、中间件、数据仓库等。新技术的采用提高了 电信业务运营支撑系统的水平，同时也对支撑系统的质量提出了新的挑战。虽 然目前有很多方法可用于软件质量保证，但软件测试技术在确保支撑系统软件 质量方面仍然发挥着不可替代的作用。 2 3 1 联通电信业务运营支撑系统简介 中国联通是目前国内唯一一家对多种电信业务拥有经营权的电信运营商， 拥有全国范围内相当规模的公用电信网，经营多种基础电信业务和增值电信业 务，形成g s m 、c d m a 、长途、互联网、p 、市话、寻呼并存共同发展的格局。 为了发挥其综合业务的优势，中国联通正在致力于建设综合的业务运营支撑系 统。新的电信业务运营支撑系统将成为联通综合的电信业务运营管理平台，为 客户提供统一化的服务。 联通电信业务运营支撑系统由各专业计费系统、综合帐务系统、综合结算 系统、综合营业系统、缴费系统、信用防欺诈系统、统一客户资料系统、综合 客服系统和大客户管理系统等多个应用系统组成。其中，综合营业系统、综合 帐务系统、统一客户资料系统、缴费系统、信用，防欺诈系统又构成了联通综合 营帐系统。支撑系统的总体结构如图2 - 3 所示。上述各应用系统中，专业计费系 统实现各业务的数据采集预处理、一次批价；综合帐务系统实现各业务详单级 优惠、单业务合帐的功能，并将各业务帐务数据进行合帐出帐及交叉优惠，实 现多项业务的“一单清”；综合结算系统实现各业务国内、国际结算及各业务间 结算；综合营业系统实现多业务营业受理、营业收费和综合查询的“一台清”； 缴费系统实现完善、方便、全方位的缴费服务；信用防欺诈系统实现信用管理 和防欺诈控制：统一客户资料系统实现各业务客户资料的沉淀及整合，并与各 北京邮电大学硕士学位论文 0 基于消息的接口测试平台的研究与实现 相关系统客户资料进行数据交换；综合客服系统实现多业务的查询、投诉处理 及业务受理：大客户系统实现大客户的信息管理、业务、投诉的受理及辅助的 决策分析功能。 客户服务层 业务支撑层 资源层 网络网元层| 交换机，网关，路由器 h l r接入设备 ! lg s mc d m a长途市话寻呼互联网 图2 3 联通电信业务运营支撑系统的总体结构 联通电信业务运营支撑系统遵循“一个体系结构、多个子系统”的一体化 原则。这里，“一个体系结构”指的是统一的电信业务运营支撑系统，即采用统 一的业务支撑平台；“多个子系统”指的是在一个电信业务运营支撑系统中的各 应用系统；“一个体系结构”下的“多个子系统”通过标准规范的接口进行互操 作。支撑系统采用以省为中心的集中处理模式，将业务数据和客户数据等各种 数据的处理与存储集中在省中心。 为规范电信业务运营支撑系统的建设，中国联通发布了支撑系统的接口规 范，对支撑系统中各应用系统之间的交互内容和接口格式作了较详尽的规定。 支撑系统中各应用系统之间的接口实现机制分为文件方式和消息包方式两大 类。接口规范分别对这两种实现方式的格式作了明确详尽的规定。 2 3 2 联通电信业务运营支撑系统的特点 作为一个多业务的电信业务运营管理平台，联通电信业务运营支撑系统具 有以下特点： 北京邮电大学硕士学位论文 基于消息的接口澳0 试平台的研究与实现 规模庞大，物理上分布，是一个典型的分布式系统。支撑系统中的各应 用系统均基于u n i x 操作系统和大型数据库平台，普遍采用了组件化技 术和基于中间件的三层或多层结构。 体系结构具有高可扩展性，易于对新增业务进行支撑。 存在大量的遗留系统。由于联通公司早期的电信业务支撑系统建设没有 一个整体框架的指导，每个专业系统都建立了一套业务支撑系统，并拥 有独立的客户数据和业务数据。而新的支撑系统采取平滑过渡、分步实 施的方式进行建设。系统中不可避免的存在着大量的遗留系统。 业务流程比较复杂，一个流程的执行往往涉及到多个应用系统。以业务 的开通流程为例，客户通过客服系统、大客户系统或者综合营业系统提 出业务开通申请，综合营业系统根据相应的业务逻辑办理业务，修改统 一客户资料系统中的客户数据，成功后通过联机指令系统向交换机发指 令开通业务，并通知计费系统开始计费。 高安全性要求。支撑系统是联通公司电信业务的核心系统，其安全性对 联通公司的整个业务经营具有至关重要的意义，任何形式的系统失效及 信息非法访问都将造成无可挽回的损失。支撑系统中的各应用系统对不 同角色的业务人员应赋予适应本业务的特殊权限，对业务权限可以动态 分配及动态组合，对业务人员的任何操作均记入操作日志。 除上述共同特点外，支撑系统中的专业计费系统、综合结算系统、综合帐 务系统、综合营业系统与统一客户资料系统还具有一些与应用相关的特点。 ( 1 ) 专业计费系统 计费系统完成原始话单数据文件的采集，按照不同的业务类型把原始话单 数据文件转换成各种不同业务类型对应的通话记录、信息流量或服务记录的标 准话单格式，对通话记录、信息流量或服务记录按照相应的计费规则进行计费， 形成一次批价详单数据文件，最后将一次详单数据文件传送给综合帐务系统、 综合结算系统或信用防欺诈系统。由于计费系统是整个支撑系统中业务数据的 源头，系统失效将造成话单丢失，使联通蒙受巨大的经济损失，因此系统的可 靠性至关重要。 计费系统的关键业务包括原始话单数据采集、话单预处理、话单一次批价 和一次批价记录入库。计费系统的特点是： 夺原始话单数据文件的格式因由不同的交换机产生而不同。 夺原始话单数据量很大，对计费处理的性能要求很高。 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 夺支持计费的计费规则很复杂，且经常需要修改。 夺对话单计费的准确性要求很高。 夺系统的可靠性要求很高。 ( 2 ) 综合结算系统 综合结算系统实现各业务国内、国际结算及各业务间结算。结算系统的关 键业务包括结算数据采集、结算数据预处理、结算批价、结算记录入库。 与计费系统类似，结算系统的特点是： 夺结算的数据量很大，对结算处理的性能要求很高。 夺支持结算的结算规则很复杂。 夺对结算的准确性要求很高。 ( 3 ) 综合帐务系统 综合帐务系统接收来自各专业计费系统的一次详单数据文件，根据用户资 料完成与用户资料相关的详单优惠处理，形成二次批价数据文件；按照不同的 业务类型形成不同业务的单业务帐单；根据各单业务帐单和综合业务相关用户 资料，完成业务间交叉优惠，产生综合业务帐单；客户缴费后，系统对已交费 的账单进行销账；对欠费账单生成催缴数据文件。帐务系统还需要对预付话费、 无主话单、呆坏账进行管理，以及进行帐务统计。 帐务系统的关键业务包括数据采集、二次批价、单业务累帐、出账、调账、 销帐反销帐、呆坏帐处理、欠费管理、无主话单管理、帐务统计，且在出账过 程中实现帐务级交叉优惠。帐务系统的特点是： 夺累帐、出帐和帐务统计是大批量数据的处理过程，对性能要求很高。 夺优惠规则灵活而复杂。 夺帐务处理和帐务统计的正确性和准确性。 ( 4 ) 综合营业系统 客户通过营业厅、代理商、客服系统、大客户系统、电话等接入手段向综 合营业系统发起业务受理请求，综合营业系统实现多业务营业受理的处理、以 及综合查询的处理。资源管理、代理商管理也是综合营业系统的一部分。 营业系统的关键业务包括营业受理与资源管理。营业系统的特点是： 夺营业业务的流程性比较强，且一个流程的执行往往涉及到其它应用系 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 统。 夺营业受理的绝大多数业务流程会造成客户资料的变动，营业系统与统一 客户资料系统的交互比较频繁。 夺高并发性。 ( 5 ) 统一客户资料系统 在联通电信业务运营支撑系统中，客户资料是所有业务处理的基础，不论 任何业务都涉及到客户资料的管理。统一客户资料系统对各业务客户资料进行 沉淀和整合，形成符合统一客户资料信息模型规范的具有内在一致性的客户数 据，并通过接口服务与支撑系统中的其它应用系统进行数据交换，向其它应用 提供一致的客户资料信息。统一客户资料信息模型是统一客户资料系统的核心， 客户资料对支撑系统的支持是通过接口服务进行的。 客户资料系统的特点是： 夺客户资料的数据量很大。 夺接口服务单元调用的高并发性。为保证综合营业、综合帐务、缴费等系 统的正常业务操作，统一客户资料系统的接口服务单元必须能够快速响 应，并支持大量的并发调用。 夺系统的可靠性要求很高。 2 3 3 联通电信业务运营支撑系统的测试 联通电信业务运营支撑系统的结构是以网络计算为中心的分布式多级结 构，同一个网络上可能有不同厂家的产品。支撑系统中的各应用系统普遍采用 基于中间件的三层或多层结构，使用不同的数据库系统，通过专有网络进行互 联，通过各应用系统之间的接口进行互操作。笔者在中国联通总部信息系统部 的工作研究期间，有幸参与了支撑系统中大客户系统、c d m a 专业计费系统、 统一客户资料系统、综合营业系统、以及综合帐务系统的认证测试工作。 整个测试工作分为文档评审和软件测试两个部分。下面以大客户系统的测试 和综合帐务系统的测试为例介绍软件测试技术在联通电信业务运营支撑 系统中的应用。 2 3 3 1 大客户系统的测试 大客户系统完成大客户群体的营销管理、客户管理和服务管理功能。大客 户系统在功能上包括信息管理、流程管理、统计报表、辅助决策分析和系统管 理五个功能子系统；信息管理子系统完成与大客户市场营销有关的各种静态信 北京邮电大学硕士学位论文1 4 基于消息的接口测试平台的研究与实现 息的管理功能；流程管理子系统主要完成与大客户服务有关的绿色、黄色和红 色三个通道的流程管理功能；统计报表子系统完成对大客户发展中心的经营状 况、服务状况和大客户发展等方面的统计与报表功能；辅助决策分析子系统完 成对大客户市场营销的辅助决策分析功能；系统管理模块完成对系统数据安全、 系统安全、系统参数、系统用户、系统权限、预报警和系统故障处理等方面的 管理。 大客户系统需要测试的功能点包括：信息模型的一致性检查；员工信息、 代理商信息、代理商合同、资源、大客户资料等各种静态信息的增删改查；员 工的奖金绩效管理、代理商的佣金绩效管理；统计报表的模板定制；经营状况 统计、服务状况统计、客户发展统计；员工奖金计算模型、代理商佣金计算模 型、员工绩效考评模型、代理商绩效考评模型等计算模型的管理；流程的定制、 修改和执行；用户权限管理等。大客户系统需要测试的接1 3 包括：与综合营业 系统之间的消息接口，包括新大客户信息查询、大客户信息同步、大客户标志 更新、经营资源信息同步、信用度变更等；与综合帐务系统之间的消息接1 3 ， 包括账单查询、实时话单查询、信用信息查询、账户余额查询、欠费信息查询 等；与客服系统的消息接口等。大客户系统还需要测试业务受理的响应时间、 三个通道的流程处理时间、以及数据统计的性能与准确性。 大客户系统的测试难点有两个：一是流程方面的测试，包括流程的执行、 流程的配置、配置的有效性这三方面；二是计算模型的测试，包括模型中的参 数设置、计算公式的配置、配置的有效性这三方面。流程的测试要以该流程要 完成的主要功能为主线，同时分析流程中所有可能的分支，找出会导致流程不 能执行成功的所有可能情况，对这些情况分别准备相应的测试用例和测试数据 进行测试。对流程进行测试时，先测试默认流程，然后对流程进行适当程度的 修改，如增加或减少某个环节、改变某环节的处理时间等，在对修改的流程进 行验证。在流程的执行过程中要特别注意系统有无流程处理进度监控以及历史 查询功能。计算模型的测试要以模型的配置以及配置的验证为核心。计算模型 中的参数依据大客户中心的文件来设置，包括目标达成率、回款率、客户开拓 达成率、净销售额、新客户开拓数等；计算公式则通过加权的参数组合相加得 到；一个模型由若干个计算公式组成。对模型进行测试时，首先设置新的参数 和计算公式，验证新配置的计算公式，然后修改计算公式，对修改后的公式再 次进行验证。 大客户系统的测试采用黑盒技术，其策略包括 夺用等价类划分法和边界值分析法提出基本的测试用例。 夺用错误推测法补充新的测试用例。 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 测试用例的好坏决定着测试的有效性和测试工作的效率，大客户系统测试 用例的设计原则概括如下： 夺测试用例要具有代表性。测试用例要能够代表各种合理和不合理的、合 法的和非法的、边界和越界的以及极限的输入数据、操作和环境设置等。 夺测试结果具有可判定性。即测试用例的执行结果是可判定或可评估的。 夺测试结果具有可再现性。即被测软件运行同样的测试用例，其执行结果 应当是相同的。 对大客户系统测试的质量的控制通过评审和测试实施监督来进行。测试评 审文档包括测试计划、测试用例和测试报告。测试实施监督的任务包括测试计 划的实施、测试资源的落实、测试环境的建立、测试用例和测试数据的准备、 测试结果的真实性等，其目的在于监督并控制测试按批准的计划执行。同时， 为了高质高效地完成软件测试工作，需要对测试过程、测试人员和测试文档进 行有效管理。 2 3 3 2 综合帐务系统的测试 综合帐务系统是联通电信业务运营支撑系统的核心应用系统。综合帐务系 统在功能上包括详单采集、详单级优惠、累帐、帐务级优惠、出账、销账、调 账、欠费处理、呆坏账处理和帐务统计等部分。其中，累帐、出帐和帐务统计 是大批量数据的处理事务，对性能的要求很高。 综合帐务系统需要测试的功能点包括：信息模型的一致性检查；数据采集、 预处理、及采集过程中的异常处理；详单优惠；累帐；帐务级优惠；出帐；调 账；销账、反销账；欠费处理、呆坏账处理；帐单管理；无主话单管理；帐务 统计；用户管理、权限管理、操作日志管理；系统监控。综合帐务系统需要测 试的接口包括：与统一客户资料系统之间的消息接口，包括综合帐单、付款、 销账、预存款、业务参数等相关接口；与综合营业系统之间的接口，包括客户 资料、账单数据、详单数据、欠费数据、销账数据等相关接口：与缴费系统之 间的消息接口，包括销账数据、帐务信息、缴费信息等相关接口；与信用防欺 诈系统之间的文件接口，包括详单数据、欠费信息、实时帐务信息、预存款信 息、呆坏账数据；与专业计费系统之间的一次批价详单数据文件接口；与综合 结算系统之间的漫游数据文件接口。在性能测试方面，主要测试帐务系统批处 理的效率，以及大用户量并发查询请求的响应时间。 准确和账目平衡是一个好的帐务系统所应达到的目标。综合帐务系统的测 试重点在于测试帐务系统对各种优惠规则的支持和正确处理，以保证帐务处理 结果的准确性和帐务统计中的账目平衡。帐务系统中的优惠规则分为详单级优 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 惠和帐务级优惠两类，帐务级优惠又分为单业务优惠和多业务优惠。在设计详 单优惠规则时，主要考虑时段优惠、主被日q 关系优惠、局向优惠、用户闭合群 优惠和基站优惠；在设计帐务级优惠时，主要考虑总量优惠、连续在网优惠、 包月优惠、时段优惠、特定用户群优惠、主被叫关系优惠和积分优惠。设计优 惠规则时，要覆盖到联通所经营的所有业务。对上述设计好的优惠规则分别准 备相应的测试用例和测试数据进行测试。为了测试帐务处理的准确性，首先要 设置优惠规则，然后系统在详单级优惠、累帐和出账的过程中，按照设置好的 优惠规则进行帐务处理，处理完成后通过查询来检查优惠处理是否正确，通过 执行帐务统计来检查账目是否正确和平衡。 2 3 3 3 支撑系统测试小结 联通电信业务运营支撑系统中应用系统的测试分为文档评审和软件测试两 个部分。文档评审的目的是评估企业的软件开发能力、企业对支撑系统相关规 范的理解程度、以及待测产品与支撑系统相关规范的符合程度。软件测试的目 的是实际检测被测产品在总体上是否符合联通支撑系统相关各项规范的要求， 即其主要功能是否完备、可靠，主要性能指标是否满足要求。 在软件测试的准备过程中，除了需要设计测试用例、准备测试数据、组织 测试流程外，测试平台的搭建也是非常重要的一个环节。在支撑系统各应用系 统的测试中，测试平台的搭建主要包括u n i x 环境的建立、数据库系统的安装、 中间件环境的建立、基础数据环境的准备、应用系统互操作环境的准备、测试 局域网的搭建、测试客户机的准备等。目前，应用系统互操作环境是由真实的 应用系统来构成的。 为了高质高效地完成软件测试工作，需要对测试过程、测试人员和测试文 档进行有效管理。同时，需要通过测试评审和测试实施监督来对测试的质量进 行控制。 北京邮电大学硕士学位论文 基于消息的接口测试平台的研究与实现 第三章接口测试平台的框架性研究 3 1 接口测试平台项目的研究背景 随着中国电信改革的逐步深化及电信行业的不断开放，电信市场的竞争变得 愈发激烈。要想在竞争中立于不败之地，提供优质服务是唯一的选择，而先进的 电信业务运营支撑系统( b u s i n e s sa n do p e r a t i o ns u p p o r t i n gs y s t c m ) 是提供优质服 务的重要保证。电信业务运营支撑系统的功能涵盖了网络管理、业务管理和客户 管理，它是一个支持以客户为中心、面向电信业务的经营流程的管理系统，它的 目标在于支撑电信业务的运营流程，满足电信运营商的运营需求。 中国联通组织开发的电信业务运营支撑系统的实施思路是“一