随着银行业务不断增加，业务模式不断复杂化，对我们的银行软件也要求越来越高，产出高质量的产品也非常重要，下面对银行软件测试进行分析总结。

  银行软件集中度高，规模庞大，往往是以系统群的方式存在，每个系统之间相互关联，相互依赖；业务复杂，需求变化快。如何保**质量在行业内有严格的要求。例如，银行都有核心系统、涉及到账务处理、清算、计息等都是核心系统的基础功能，其他系统网银、二代支付、手机银行、ATM等都通过某种方式跟核心系统关联，涉及到入账等核心的交易，就会调用相应的接口进行操作。所以我们在测试的过程中就要测试相应的通讯、接口、基础功能、兼容性等。

银行业务系统群，就算是中小行也有个百八十个，银行的科技部门面对较快的需求变更，会产生人测试人力不足，测试不充分的情况，面对这种情况，一个是增加人力，另一种也要掌握好测试方法。

  一个重要系统上线投产前，一般要经过如下测试（暂时不介绍单元、白盒测试）

数据移植测试、功能测试、接口测试、性能测试、安全性测试、兼容性（终端）、风险监控测试、文档审核等验证，后续介绍主要是为了让大家更清晰的了解以上所包含的范围。

 

  数据移植测试：对于银行系统来说新老系统更替，新系统的环境、数据库等与老系统的数据库及应用都有很多不同，为了保证新系统能够有效的支撑老系统（客户、签约、）的相关协议，就需要将老系统的数据转移到新系统里，转移后新系统可以**存量用户的业务。给客户的感觉，不管是老系统还是新系统都是没有区别的。

为了保证数据移植的正确性，测试人员需要对新库和旧库的数据进行比较，检查其映射关系是否正确，通常采用人工比对和工具比对的方式进行检查。

  记得笔者当时核对时是采用excel的表格，通过编写一些简单公式来检查是否一致，不过这种方式适用于数据较少的情况。数据多的时候往往就把excel卡死了。

  举个小例子，比如旧系统为oracle，新系统用的DB2，旧系统数据库表存在60个，新系统100个表，两系统的数据结构也不一样，这样需要把两系统的数据库表的映射关系梳理好，测试人员需要知道表与字段的对应关系，才能保证测试时正确。

  移植后，对表进行核对，记录数、字段数、交易连续性等逐个检查。数据移植需要测试人员有足够的耐心、细心。有的数据对着对着就烦了，还是要坚持。

  功能测试：主要对软件的功能进行验证，对于银行的系统来说，主要根据需求来检查功能的正确性。

包括：验证业务流程的准确性，业务流程测试，业务流程合理，需要测试人员有一定的金额和技术知识，能够更好的判断出业务是否合理，是否真正的体现出客户的需求，对流程的完整性、连贯性进行检查，也要重点对账务的处理进行验证，涉及到账务处理的模块不能出任何问题。

  接口测试：对于银行来说，行内接口与行外接口都是相对独立的，往往一个项目包含通讯、行内外接口的调试，有的时候一个系统的项目包含多个系统的接口调试工作，而且存在先后顺序。所以我们在测试系统的时候要模拟系统的环境、数据、业务来进行数据的下发或者上传等工作。

  通常接口测试需要构造一些接口的测试工具，模拟发送报文，或者设置一些挡板，进行相关返回信息的检查；比如支付中的人行仿真系统，是模拟人行返回报文对接口进行验证。接口测试往往是多个系统并行开发，上游系统或下游系统没有真正的开发完成。没有客户端的操作界面。属于提高效率，开发小组或测试小组进行验证。接口测试中需测试人员对接口更新的表非常熟悉，比如某一个交易调用某一个接口，更新两个表，那接口程序执行完成之后，要检查表更新的是否正确，接口测试完成后，对后续通过客户端的测试提高了效率，并且有的逻辑通过客户端测试是覆盖不到的。