金 华, 贾怡菁, 陈懿渊
(中海信息系统有限公司,上海200135)
迄今,越来越多的企业开始采用分布式系统架构来构建自己的关键企业应用系统。此趋势是若干因素共同促进的结果。
1.依托多年来软件工程发展所积累的经验、方法及各种架构模式。(如OO/MDD/MDA等),飞速发展变化的企业生产模式需要新的方法论来促进更加高效的应用系统构建模式。
2.互联网技术的迅猛发展带来了前所未有的分布式系统的交互能力,也逐渐成为了信息系统建设标准化的基础。
分布式系统往往具有交互依赖复杂、交互消息协议类型众多及消息中间件种类繁多等特点(见图1)。
因此,针对采用分布式系统进行集成测试时会面临无可操作的图形用户界面、模块接口关系及消息格式复杂、缺乏统一有效的测试手段、单元测试和集成测试之间存在鸿沟以及测试环境构建费时费力难以平衡质量和进度等诸多问题,在分析分布式系统集成测试复杂性的基础上,通过深入研究IBM Rational集成测试工具套件,给出了符合航运信息系统应用特点的系统解决方案。
图1 分布式系统特点
集成测试(也叫组装测试或联合测试)是指在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行集成测试。实践表明,一些模块虽然可以单独工作,但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题,很可能在全局上暴露出来,影响系统整体功能的实现。与传统的信息系统集成测试不同,采用全新的分布式体系架构的信息系统在集成测试过程中通常会遇到以下问题。
与传统的集成测试过程不同,分布式应用系统的测试是重点围绕系统底层各个组件、模块及子系统间的接口关系进行的,通过消息传递判定接口间的通信是否正确。这些接口无法直观地通过系统界面的操作进行测试。因此,如果不能对模块接口之间复杂的接口关系进行高覆盖率的测试,那么测试结果所能发现的缺陷只是浮在问题表面的冰山一角(见图2)。
分布式应用系统的各个模块之间通信的消息的格式复杂多样,常见的有HTTP、X ML、SOAP、File、JSON、REST、二进制、JMS、Base64等几种类型。这就要求测试人员必须熟悉每种消息的格式以及针对此类消息特有的测试方法;必须为每种消息构建独立的测试脚本。因此,测试工作难度大、复杂性高,不利于统一有效的执行和管理。
在分布式应用系统的测试过程中,往往会碰到这样的问题:各子系统和模块在独立开发与单元测试阶段进行的都十分顺利,模块本身的质量也可以保证,但进行到集成测试阶段,由于各模块和组件之间的消息契约十分复杂、依赖关系众多,系统与系统之间在做联调测试时容易出现各种各样的问题,导致集成后的软件系统质量不可控,在运行期间持续暴露各种各样的缺陷。不可否认,采用传统集成测试方式进行分布式系统测试,会导致单元测试和集成测试之间存在一条不可逾越的“鸿沟”(见图2)。
分布式应用系统采用的技术种类众多,包含各种类型的操作系统、中间件、数据库、通信协议等。为了测试一个端到端的业务场景,往往需要耗费大量的人力、物力和时间来重复搭建测试环境,且十分容易出错。据统计,搭建测试环境一般会耗费掉测试周期30%~50% 的 时间。
此外,针对特定条件的测试,需要定制的和额外的软件支撑,往往花费很多的人力、物力也很难构建理想的测试运行环境。这导致了测试工作效率低、质量不可控,从而大大增加了应用系统交付的风险,系统的质量也难以得到保证。
目前市场上流行的集成测试解决方案主要有HP Ser vice Virtualization和IBM Rational集成测试与虚拟化解决方案。
1.HP Ser vice Virt ualization服务虚拟化解决方案通过模拟生产环境中服务的行为,使得开发和测试团队能始终跟上进度,无须考虑后端与诸多生产系统的集成,用户将有更多的精力放在开发和测试本身之上。
2.IBM Rational是一种专门用于测试分布式复杂应用系统的自动化测试工具,无论是遗留系统还是现代应用,其具有无需编码的测试、测试虚拟化、丰富的可扩展性、持续测试和验证、多协议支持等优势。
通过对HP Ser vice Virtualization解决方案和IBM Rational集成测试工具套件进行深入研究和大量实践,最后选取IBM Rational集成测试工具套件来进行分布式系统集成测试。提出了基于Rational的分布式系统集成测试解决方案,该方案可以较好地解决传统集成测试过程面临的诸多问题。该测试工具套件由Rational Integration Tester和Rational Test Virtualization Server两大产品构成。
Rational Integration Tester是一种全面支持面向服务的体系架构,且具有领先集成技术的集成测试工具,可以在可视化的测试设计器中对数据交换进行建模并创建基于服务,级别的测试。其具有以下特点:
1)功能强大的集成测试环境:能够以易于理解的方式构建系统之间接口的消息调用,能够创建验证点,并根据消息的模式对测试结果进行判定。
2)完整的协议支持:提供了完整的协议支持,几乎覆盖了业界所有的协议和消息格式。
3)可持续递增地进行集成测试:与其在各个子系统开发好之后再进行接口的联调和集成测试,不如从一开始就根据消息契约把集成测试脚本定义好,然后在各个子系统的迭代实现过程中,持续、回归、递增式地执行集成测试。这样一来,单元测试结束之后,集成测试也基本结束了,有效地降低了系统集成时的复杂度以及缺陷出现率(见图3)。
图2 单元测试和集成测试的“鸿沟”
图3 持续递增的集成测试
Rational Test Virtualization Server是一组相关集成工具的集合,测试人员可以通过该工具为测试环境的相关依赖创建“桩”模块,从而使得测试工作不会因为系统某个部分功能的不可用而停滞(见图4)。
图4 测试虚拟化流程
采用测试虚拟化给客户带来的收益包括:
(1)减少甚至消除了测试环境的基础架构的投入,包括软件、硬件和配置的费用;
(2)更多灵活的虚拟测试环境使在独立的测试团队之间的并行开发更有效率;
(3)简化了测试数据管理:把从目标系统建立和抽取测试数据的过程自动化;
(4)减少了测试环境的对第三方系统的License使用。
某航运信息系统开发中,有很大一部分工作是基于各个口岸的业务规则开发出相应的接口程序,接口产生对应的EDI报文并通过FTP或E-Mail的形式发送到口岸端。口岸端接收到报文之后进行业务规则校验,如果校验成功,则进行业务处理;如果校验失败,将以FTP或E-Mail的形式发送回执(EDI报文或者邮件)到航运信息系统,开发人员再根据回执中的错误说明修改接口程序,并重新发送(见图5)。
图5 航运系统接口程序工作流程
通常,航运信息系统需要与众多的口岸系统交互,而各口岸的EDI报文格式又千差万别,这都给开发和测试人员的日常工作带来了极大的困难,严重影响了团队开发和测试的效率,具体表现在以下几个方面:
(1)不同口岸的业务规则不同,通常规则分析需要一周;
(2)口岸的数量较多,开发工作需要二周;
(3)口岸端校验并回执周期较长,通常需要1-2天,开发人员无法及时得到响应并进 行修改;
(4)开发效率较低,无法在早期对报文接口执行验证;
(5)EDI报文格式复杂且冗长,很难依靠人工的方式逐条比对,对测试人员来说耗时耗力;
(6)报文种类繁多,格式规则繁多,为自动化的回归测试带来了困难;
(7)测试依赖口岸端系统的处理和响应,开发人员需耗费大量的时间等待,无法持续地进行集成测试。
针对上述分析,考虑在实际工作中引入基于IBM Rational服务虚拟化工具套件的集成测试解决方案。
通过Rational Integration Tester,可以记录和捕获航运企业应用发送给口岸的报文和响应报文,形成报文基础模板,针对不同的口岸校验规则开发出不同的报文“挡板”运行在Rational Test Virtualization Ser ver上。
通过在Rational Test Virtualization Ser ver上运行各种报文“挡板”,能够截获住通过航运信息系统发送到口岸端系统的所有报文请求、自动进行规则校验,并将校验结果返回给航运信息系统(见图6)。
3.3.1 创建报文“挡板”
Rational Integration Tester能够支持包括EDIFACT、X12在内各种国际标准的EDI协议,能够创建报文模版并支持模版内容的一键导入。报文模版能成为报文系统开发测试及构建“挡板”的基础(见图7)。
图6 EDI报文测试“挡板”
图7 Rational Integration Tester对EDIFACT协议的支持
Rational Integration Tester采用规则和模版分离的方式,有效地实现了规则和消息直接“解耦合”;解决了无图形用户界面,模块接口关系和消息格式复杂,缺乏统一有效的测试手段的问题。通过Rule Cache的机制,将报文的校验规则进行统一处理(见图8)。
图8 通过Rule Cache实现校验规则的统一管理
校验的方式十分灵活,支持诸如比较、长度验证、正则表达式匹配、XPath验证等多种常见方式。
对于不同的报文模版,只需要将Rule Cache中的规则应用到响应的字段就能够实现规则与模版的绑定。
3.3.2 将“报文”部署到虚拟化服务器
Rational Test Virt ualization Ser ver提供了统一的中央存储库,用于集中管理和维护测试“挡板”。团队的成果能够通过“一键上传”的方式进入到Rational Test Virtualization Server中。所有在Rational Test Virtualization Server中发布的“挡板”都可以通过统一的控制台进行维护。同时,其他解决了测试环境构建费时费力、难以平衡质量和进度的问题。
3.3.3 运行测试
通过启动部署在Rational Test Virt ualization Ser ver中的各类报文“挡板”,开发和测试人员能够以两种方式执行测试:
(1)通过航运企业应用以原始的方式发送EDI报文,报文“挡板”将自动截获住发送端报文,并根据定义在“挡板”中的校验规则将结果返回给航运企业应用,以供开发人员快速响应,并进行应用程序的修改。
(2)通过在Rational Integration Tester中定义各类自动化测试脚本,回归测试各类口岸的校验规则,并将测试结果进行统一管理和缺陷提交;通过这种方式,就能在开发的更早期持续地验证应用所发送的各种报文的正确性,而不必依赖后端的口岸系统是否正在运行,从而能够更好地保证应用的质量。
3.3.4 测试结果
运行结束后,会显示出验证成功(Log:成功)和验证失败(Fail:失败)两种结果(见图9)。
图9 测试结果
3.3.5 测试总结
通过引入“挡板”这种虚拟化技术,能以在本地搭建虚拟化口岸的方式有效地屏蔽掉口岸端规则校验的复杂性和延迟性,化被动为主动,使测试人员不必关注于口岸端的可用性和规则的复杂性,以尽可能早地对报文接口进行测试,从而有效提升整个信息系统开发的效率,并充分保证系统的质量。
详细分析了分布式应用系统集成测试现状和所面临的诸多问题,通过对IBM Rational集成测试工具套件进行深入研究和大量实践,提出了基于Rational的分布式系统集成测试解决方案,并已将其成功应用于航运信息系统的集成测试中。通过虚拟口岸端的Portal系统进行业务规则校验,充分证明了Rational Integration Tester结合Rational Test Virt ualization Ser ver工具套件构建测试“挡板”的能力,有效解决了当前分布式系统集成测试中存在的问题,从而有效提高了测试工作的劳动生产率,降低了成本并充分保证了系统的交付质量。目前,该方案还处于使用的初期,软件产品本身的购买费用及测试人员的学习成本相对较大。今后,随着该方案大范围地推广应用,其优势将会更加明显。
[1] 于秀山,于洪敏.软件测试新技术与实践[M].北京:电子工业出版社,2006.
[2] 杨杰荣.软件测试过程的研究与应用[D].西安:西北工业大学,2007.
[3] 戴希里.软件测试过程改进方法的研究[D].武汉:华中师范大学,2006.
[4] 朱少民.软件质量保证和管理[M].北京:清华大学出版社,2007.
[5] 杨利.分布式系统测试技术研究及其应用[D].河北:河北工业大学,2007.