基于金融(银行)行业的软件测试分析

上一篇 / 下一篇  2017-06-05 09:23:40 / 个人分类:金融证券行业测试

  随着银行业务不断增加,业务模式不断复杂化,对我们的银行软件也要求越来越高,产出高质量的产品也非常重要,下面对银行软件测试进行分析总结。
  银行软件集中度高,规模庞大,往往是以系统群的方式存在,每个系统之间相互关联,相互依赖;业务复杂,需求变化快。如何保**质量在行业内有严格的要求。例如,银行都有核心系统、涉及到账务处理、清算、计息等都是核心系统的基础功能,其他系统网银、二代支付、手机银行、ATM等都通过某种方式跟核心系统关联,涉及到入账等核心的交易,就会调用相应的接口进行操作。所以我们在测试的过程中就要测试相应的通讯、接口、基础功能、兼容性等。
银行业务系统群,就算是中小行也有个百八十个,银行的科技部门面对较快的需求变更,会产生人测试人力不足,测试不充分的情况,面对这种情况,一个是增加人力,另一种也要掌握好测试方法。
  一个重要系统上线投产前,一般要经过如下测试(暂时不介绍单元、白盒测试
数据移植测试、功能测试接口测试性能测试、安全性测试、兼容性(终端)、风险监控测试、文档审核等验证,后续介绍主要是为了让大家更清晰的了解以上所包含的范围。
  数据移植测试:对于银行系统来说新老系统更替,新系统的环境、数据库等与老系统的数据库及应用都有很多不同,为了保证新系统能够有效的支撑老系统(客户、签约、)的相关协议,就需要将老系统的数据转移到新系统里,转移后新系统可以**存量用户的业务。给客户的感觉,不管是老系统还是新系统都是没有区别的。
为了保证数据移植的正确性,测试人员需要对新库和旧库的数据进行比较,检查其映射关系是否正确,通常采用人工比对和工具比对的方式进行检查。
  记得笔者当时核对时是采用excel的表格,通过编写一些简单公式来检查是否一致,不过这种方式适用于数据较少的情况。数据多的时候往往就把excel卡死了。
  举个小例子,比如旧系统为oracle,新系统用的DB2,旧系统数据库表存在60个,新系统100个表,两系统的数据结构也不一样,这样需要把两系统的数据库表的映射关系梳理好,测试人员需要知道表与字段的对应关系,才能保证测试时正确。
  移植后,对表进行核对,记录数、字段数、交易连续性等逐个检查。数据移植需要测试人员有足够的耐心、细心。有的数据对着对着就烦了,还是要坚持。
  功能测试:主要对软件的功能进行验证,对于银行的系统来说,主要根据需求来检查功能的正确性。
包括:验证业务流程的准确性,业务流程测试,业务流程合理,需要测试人员有一定的金额和技术知识,能够更好的判断出业务是否合理,是否真正的体现出客户的需求,对流程的完整性、连贯性进行检查,也要重点对账务的处理进行验证,涉及到账务处理的模块不能出任何问题。
  接口测试:对于银行来说,行内接口与行外接口都是相对独立的,往往一个项目包含通讯、行内外接口的调试,有的时候一个系统的项目包含多个系统的接口调试工作,而且存在先后顺序。所以我们在测试系统的时候要模拟系统的环境、数据、业务来进行数据的下发或者上传等工作。
  通常接口测试需要构造一些接口的测试工具,模拟发送报文,或者设置一些挡板,进行相关返回信息的检查;比如支付中的人行仿真系统,是模拟人行返回报文对接口进行验证。接口测试往往是多个系统并行开发,上游系统或下游系统没有真正的开发完成。没有客户端的操作界面。属于提高效率,开发小组或测试小组进行验证。接口测试中需测试人员对接口更新的表非常熟悉,比如某一个交易调用某一个接口,更新两个表,那接口程序执行完成之后,要检查表更新的是否正确,接口测试完成后,对后续通过客户端的测试提高了效率,并且有的逻辑通过客户端测试是覆盖不到的。

TAG: 行业 软件测试 金融证券

Testing life of tengmy 引用 删除 tengmy   /   2017-11-09 11:29:32
我做了四年多外资银行的后台系统的UAT测试以及管理,对于系统群的复杂性还有上下游系统的联调测试,业务的复杂性有一定的理解,不过和你这边还略有区别。各有各的复杂和难度吧。不过金融系统的测试还是挺有意思的,因为复杂所以有趣。加油↖(^ω^)↗
 

评分:0

我来说两句

Open Toolbar