全业务接口平台POC测试

2015-05-13

信息通信技术 2015年3期

中国联通研究院北京 100032

引言

全业务服务接口平台由中国联通总部接口平台和省分接口平台组成，主要负责总部BSS系统内部的横向集成，以及总部BSS系统与省分BSS系统间的纵向集成。基于这样的设计理念，其主要建设目标是完成一个架构、一套服务、一点接入、一个标准，切实贴近联通总体发展思路。

POC(Proof of Concept，概念验证)主要是为观点提供证据，是根据电信行业特定业务需求而设计的软件、硬件原型的解决方案。POC的目的是确定合适的系统组成、软件产品版本、方案的服务需求，验证识别出关键技术点是否适合本系统业务的要求，能否达到预期性能指标和可靠性的要求。POC不仅能确定应该做什么，也能确定不应该做什么，它最大的价值在于能在大规模正式实施方案以前，确定该方案是否可行，这对于电信运营商来说具有重要的意义。

1 全业务服务接入平台总体架构

中国联通全业务服务接口平台的总体架构由四部分组成[1]，见图1。

1) 总部业务系统。作为服务消费系统，根据业务需要，发送服务调用消息，调用总部接入平台发布的标准/组合服务；作为服务提供系统，向总部接入平台发布标准服务，供总部其他业务系统使用。

2) 总部接入平台。对中国联通的组合/标准服务进行统一管理，接收总部业务系统的服务调用请求，根据内容进行服务代理和组合，向总部业务系统和省分接口平台发起服务调用请求，并返回调用结果。

3) 省分接入平台。将省分BSS域各子系统提供的多种格式的基础服务封装成标准服务，代理省分业务系统提供的标准服务。

4) 省分业务系统。作为服务提供系统，为省分接口平台提供标准服务和基础服务。

图1 总体架构示意图

2 全业务接口平台POC测试方法

2.1 POC测试环境

本文全业务接口平台POC主要通过模拟搭建测试环境，包括ESS系统(包括Web服务器和数据服务器)、总部全业务接口平台(包括数据库服务器和应用服务器)、省分全业务接口平台及BSS系统(包括Tuxedo应用服务器和数据库服务器)，验证全业务接口平台的核心功能是否满足系统需求。具体环境拓扑见图2。

图2 全业务接口平台测试环境拓扑图

2.2 全业务接口平台核心功能测试方法

总部全业务接口平台主要由服务层、管理层、传输层组成。服务层主要完成服务封装、服务控制、服务路由、超时处理等功能；管理层主要完成提供服务注册、服务更新、服务监控、服务告警、服务部署等功能。对省分接口平台进行监控和管理，了解各系统的运行状态，及时发现异常情况；传输层主要完成通过多种消息传输协议发送和接收服务消息，并提供对消息传输的管理功能[2]。

本次全业务接口平台POC功能验证主要是贯穿核心业务场景进行端到端测试，验证全业务接口平台的核心功能，包括全业务接口平台的服务路由功能、报文格式校验功能、同步处理功能、超时控制功能、重发控制机制、服务异常处理、接入控制机制等功能。测试方法主要在前台ESS进行人工操作，或者通过SoapUI工具模拟发起错误报文进行端到端的验证测试，选择的核心业务包括2G/3G开户业务、固网开户业务、账单查询业务、产品变更业务、缴费业务等，验证全业务接口平台是否能满足核心业务场景端到端处理的架构需求[3]。全业务接口平台主要验证点见表1。

表1 全业务接口平台核心功能验证点

1) 端到端业务贯通测试场景[4]。总部全业务接口平台应能根据接入服务的请求信息，按照预先配置的规则，将此服务请求路由到相应的省分接口平台做进一步的处理。

在此功能验证点中，通过修改全业务接口平台route type字段信息(主要是选择按手机号码或者省分代码路由)，并在ESS侧模拟发起请求，实现全业务接口平台按照手机号码或者省分代码等不同路由方式进行路由。测试方法见图3。

图3 端到端业务贯通场景测试方法

2) 全业务接口平台异常处理测试场景。总部全业务接口平台应提供对接收消息和应答消息的格式校验功能，对ESS系统的请求报文格式及BSS返回的报文格式进行校验，当校验错误时，应返回错误代码给ESS系统。

在此功能验证点中，通过使用模拟测试工具SoapUI模拟发送异常报文，如详单查询异常等，全业务接口平台对异常报文进行校验，返回报文请求错误代码，以此来验证全业务接口平台支持异常处理功能。测试方法见图4。

图4 全业务接口平台异常处理测试场景

3) 并发拥堵处理测试场景。总部全业务接口平台应具有流量检测和拥塞处理的能力，当判断自身过载时能自我保护，当判断拥塞或故障时，能及时减少或停止向省分接入平台发送服务请求，减轻省分接口平台负荷。

在此测试场景中，通过使用压力测试工具Loadrunner对ESS模拟发起并发业务操作，制造全业务接口平台中心拥塞，当总部全业务接口平台检测到流量超过舍弃阀值时，及时采取自我保护措施，拒绝处理新收到的服务请求，避免由于处理能力下降造成瘫痪，并通知ESS系统不再向其发送服务请求。测试方法见图5。

图5 全业务接口平台并发拥堵处理场景测试方法

4) 服务监控测试场景。全业务接口平台的服务监控功能主要包括服务统计、SLA告警管理、告警规则配置功能，通过对全业务接口平台的服务监控界面，验证是否满足服务监控功能要求。

2.3 全业务接口平台性能测试方法

本次全业务接口平台性能测试方法主要对服务的吞吐能力进行测定，利用Loadrunner测试工具模拟ESS发送请求报文，制造总部全业务平台的请求压力，并设定业务集合点并发提交，记录各个系统处理时间及处理能力[5]。

1) 评估全业务接口平台并发量及处理能力。在此性能测试场景中，将详单查询、缴费业务、开户业务按比例设计成混合场景，以逐次增加并发用户数量的方式，利用测试工具模拟操作ESS系统，直至被测系统CPU达到阀值或事物处理成功率低于95%之前一次的并发用户数作为系统可处理最大并发数，具体方法见图6。

图6 全业务接口平台处理能力评估测试方法

2) 评估全业务接口平台各系统间的处理时延。以单个vuser(虚拟用户数)顺序执行多次的操作方式，利用测试工具模拟营业员操作ESS系统，设定集合点提交并发。记录各个系统处理时间、处理效率及系统的网络延时。具体方法见图7。

图7 全业务接口平台各系统的处理时间示意图

全业务接口平台处理时间：(t8-t3)-(t7-t4)

BSS 处理服务时间：t6-t5

ESS处理服务时间：(t10-t1)-(t9-t2)

服务处理平均总时间：T

网络总延迟：T-[(t8-t3)-(t7-t4)]-(t6-t5)-[(t10-t1)-(t9-t2)]

3 结论

3.1 功能测试结果

在目前的测试环境下，ESS侧选取的2G/3G开户业务、缴费业务、产品变更等主要业务均能通过ESS、总部全业务平台、BSS端到端贯通测试，基本满足POC的目的；从全业务平台自身功能来看，具备了超时、重发、数据报文格式容错能力，在处理并发拥塞时，能通过拒绝过载请求，保护自身稳定运行，达到本次POC的目的。

3.2 性能测试结果

本次性能测试主要验证指标为最大并发用户数、最大吞吐量、各系统的时延，验证系统的性能是否满足运行要求。从测试结果来看，事务处理能力随着并发数增加而增加，在并发用户数达到60笔时，系统的事务处理能力开始震荡。这表明，在测试环境下，系统的最大并发用户数为60笔，平均事务数为50笔/秒。具体见图8。

从各系统的时延测定结果来看，本次时延测定主要在ESS侧模拟主要核心业务2G/3G开户、缴费、产品变更、详单查询等主要业务进行测试，分析各系统间的处理时间，如图9所示，BSS对各业务的处理时间较长，全业务接口平台单次服务调用时间绝对时间约在0.1～0.2秒之间，对业务的感知无影响，基本满足本次POC的性能测试要求。具体见图9。