金融行业的软件测试分析

发布于 2021-05-09 23:31 ,所属分类:软件测试工程师学习资料

       随着⾦融⾏业的业务不断增加,⾦融交易模式的不断变化,⾦融机构对信息化的要求也越来越⾼,⾼质量的⾦融软件对于⾦融机构来说显得尤为重要。如何保证⾦融⾏业软件的质量,对⾦融⾏业软件的测试⼈员来说,也提出了更⾼的要求。以下针对⾦融⾏业软件的测试做出了具体的分析

1. ⾦融⾏业软件特征分析

  ⾦融⾏业软件系统具有集中度⾼、规模庞⼤、数量多、系统之间关联性强、业务复杂、需求变化快等特点,如何有效可⾏的实现软件测试和软件质量控制,是对⾦融⾏业软件测试⼈员提出的基本要求。

1.1⾦融⾏业软件的业务特点

  以⾦融⾏业软件的典型代表银⾏系统软件为例:⼀般的银⾏系统软件都有一个核⼼系统,核⼼系统主要涉及账务的处理、清算、计息等。银⾏的其它业务系统都会直接或间接的与核⼼系统进⾏交互,主要处理⼀些涉及业务的流程以及系统管理、⽤户管理等辅助功能。

  此外,银⾏的业务系统也种类繁多。⽐如:ACE/柜⾯、⽹上银⾏、电话银⾏、呼叫中⼼、信贷、资产托管、资⾦风险分析及风险控制系统、外汇买卖、基⾦、期货、黄⾦、汇票、信⽤卡业务以及其它衍⽣业务等等。各个系统之间都可能有着密切的联系,之间也会涉及到不同系统之间的接口。

  因此,在测试过程中,除了对银⾏的核⼼系统、业务系统进⾏测试之外,还会涉及对接口的测试,⽽接口测试往往需要测试⼈员构造⼀定的测试环境与测试数据来模拟各系统之间的交互。

1.2⾦融⾏业软件的复杂性特点

  就银⾏系统软件来说,本⾝就具有复杂性的特点。⾸先,银⾏软件具有不同的客户群,如个⼈⽤户、企业⽤户、银⾏内部管理⼈员、业务⼈员等,因此,银⾏软件会有针对不同客户所使⽤的版本或权限控制。此外,对于不同的服务⽅式,如柜台、电话银⾏、⽹上银⾏等,都必须开发出不同的软件。其次,银⾏业务种类繁多,业务逻辑也⾮常复杂,对业务处理要求有很⾼的安全性和实时性,这些都要借助复杂的技术才能实现。因此,对于测试⽽⾔,软件的复杂性也增加了测试的复杂性,对测试者来说要求有相当的经验和测试技术的⽀持。

  另外,由于银⾏业务的快速发展,当旧的银⾏软件系统⽆法满⾜业务处理的要求时,就必须开发新的系统,对于重新开发的新系统来说,旧系统的⽤户数据必须保证能在新系统中正常使⽤,这就涉及到了新旧版本的数据移植问题,由于新旧系统之间数据字典存在差异,数据移植后能否正常,就需要对新旧数据进⾏⽐对性测试。⽐对测试过程往往会涉及数据库的应⽤及⽐对⼯具开发使⽤。

2. ⾦融⾏业软件测试的现状

  根据某项调查,⾦融企业应⽤系统的数量,中⼩银⾏应⽤系统数量普遍在100个左右,有⼀半银⾏超过100个应⽤系统;虽然保险⾏业应⽤系统数量相对较少,但⼤部分保险公司拥有10―50个应⽤系统;⽽且这些数量还有进⼀步上涨的趋势。调查数据也表明,⾦融⾏业IT部门的测试能⼒⽬前远远低于⾦融机构对测试的要求[3]。即使是IT成熟度⽐较⾼的企业,也难以覆盖所有应⽤系统的测试需求。⾦融企业的测试需要和信息科技部门的测试能⼒之间存在⼀定的差距。

3. ⾦融⾏业软件测试⽅法及范围分析

  以下主要从功能测试、接⼜测试、数据移植测试、性能测试、安全性测试、 风险监控测试、⽂档审核⼏个⽅⾯来阐述⾦融⾏业软件的测试⽅法及范围[4]。以下划分主要为了更清晰了解⾦融⾏业软件测试所包含的范围,本次分析不涉及⽩盒测试的内容,主要针对涉及⾦融⾏业软件业务特性的测试⽅法及范围进⾏阐述。

   

    3.1功能测试

  功能测试,主要是对软件的功能进⾏的验证,对于⾦融⾏业软件来说,功能测试主要进⾏以下功能的验证:

3.1.1业务验证测试

  验证业务系统的功能是否正确实现,测试其业务处理的准确性。

  1)业务流程测试

  ⾦融⾏业软件测试⾸先的是业务的正确性,业务流程要合理、业务处理正确⽆误,这些往往需要测试⼈员具备⼀定的⾦融软件测试经验,才能更好的判断业务流程设计是否合理,是否满⾜客户实际需求,以及业务流程处理过程中可能会涉及到的异常,通常通过正常案例和异常案例来验证业务流程的完

整性和正确性。业务流程除了验证流程的正确性,通常对于涉及⾦额、资⾦、库存等数据及业务流程中⽣成的记录是否正确性也是测试的重点。

  2)账务处理

  对于银⾏来说,账务处理为核⼼系统功能,也是这类软件测试的重点,账务处理不仅涉及到资⾦,还与交易过程相关,在测试系统对账时,必须对账务处理流程有清晰的认识,对于账务处理过程中账务是否处理正确、是否出现错账、是否需要进⾏调账等案例都要能进⾏完整的案例设计来覆盖测试点,这⼀块的测试⼀般需要有经验的测试⼈员来进⾏测试。

  3)清算

  银⾏系统清算过程涉及的东西较多,如资⾦清算、库存清算、计费、计息、对账、登帐、报表⽣成等复杂的过程,同时涉及的数据量也是⾮常的⼤,对于大型系统来说更是如此数据检查的⼯作量也很⼤,同样测试⼈员需要对清算的全过程有清晰的了解。

  4)报表

  对于银⾏系统来说,报表是直接呈现给⽤户最直接的结果,⽽对⼀个银⾏系统来说,报表的数量⼀般都较庞⼤,很可能涉及到⼏⼗张报表,因此对报表的检查也是测试的重点,这需要测试⼈员对银⾏系统涉及的业务⾮常熟悉,能判断报表的设计是否合理,报表数据是否正确等。

  3.1.2客户端测试

  客户端主要针对的是软件界⾯功能的测试,根据功能划分⼀般涉及以下⼏类:

  1)系统管理类

  系统管理主要包括系统参数管理、⽤户管理、⾓⾊管理、权限分配等,测试也包含相应的业务逻辑及页⾯测试,如查询功能的测试、显⽰风格、验证客户端页⾯显⽰数据是否正确等。

        2)数据查询类

  主要验证数据查询结果客户端显⽰是否正确。

  3)其它涉及业务操作的功能界⾯

  主要针对客户端界⾯的录⼊、查询等功能进⾏测试。

  客户端测试还会对界⾯的友好性、提⽰信息的合理性等进⾏测试。

    3.2接口测试

  对于银⾏来说,通常⾏内系统和与银⾏外对接的系统是独⽴开发的,⾏内与⾏外系统采⽤的数据库、通讯协议等都可能存在差异;并且对于银⾏来说,还可能存在多个系统,如:⽹上银⾏、ACE/柜⾯、电话银⾏、呼叫中⼼、信贷、资产托管、资⾦风险监控分析系统等,并且各个系统之间可能关联特别紧密,存在许多交互;因此,在测试中会涉及到相关系统接⼜的测试,这时通常需要构造对接系统的测试环境、数据、业务等来模拟对接系统。

  接口测试中,由于⼀⽅系统在测试过程中不可见,因此通常需要进⾏环境的模拟,⽐如开发模拟软件来模拟被测试系统与所交互的系统之间的通讯,并且在测试过程中通常需要测试⼈员⾃⼰组报⽂,通过模拟发送器收发发送报⽂来进⾏测试,并通过后台检查报⽂转换是否正确,通过数据库来验证数据是否正确。通常来说,接口的测试测试⼈员主要跟后台和数据库打交道,⽽很少通过客户端来操作,因此要求测试⼈员对数据库知识、对应的操作系统命令以及一些中间件具有⼀定的熟悉程度才能更好的进⾏测试。

  接口测试⼀般在功能测试阶段完成,功能测试计划中应包含接口测试。

 3.3数据移植测试

  对于银⾏来说,软件产品经常存在更新换代或升级的情况,新系统的运⾏环境和旧系统可能不⼀致。因此,为了保证系统的顺利运⾏,在新系统研发出来,准备上线之前,需要把原来旧系统的客户历史数据移植过来,这就涉及到了数据移植问题。数据移植并不是简单的数据迁移,因为新旧系统之间数据字典是不同的,为了保证移植结果的正确性,需要对新旧数据库的数据进⾏⽐对,通常可以通过⼈⼯⽅法或开发⽐对⼯具进⾏⽐对。

  举例来说,旧系统采⽤的SQLSERVER的数据库,⽽新系统采⽤Oracle的数据库;并且就系统可能存在50张数据表,新系统可能有200张数据表,⽽且,新系统的数据表结构与旧系统可能完全不⼀样,或者新旧系统的某张表能对应另⼀个系统的⼏张表,这样在数据移植测试中就要进⾏⼏⽅⾯的测试。⽐如,两个数据库可能存在有差异的地⽅,如数据类型不同,位数不同,在数据移植过程中对这部分就应该做详细的检查。此外,表结构的不同,在做数据移植检查时,需要获得新旧版本的数据字典,并且对移植过来对应的所有字段数据是否移植正确做检查。

  数据移植测试往往需要测试⼈员有⾜够的耐⼼,能仔细进⾏⽐对,发现存

在的问题。数据移植测试⼀般在功能测试阶段完成,功能测试计划中应包含数

据移植的测试。

  3.4性能测试

  性能测试的⽬的主要是验证业务系统是否满⾜业务需求的多⽤户并发操作,是否满⾜业务性能需求,评估压⼒解除后的⾃恢复能⼒,测试系统性能极限。

  随着⾦融⾏业软件的规模越来越⼤、处理能⼒要求越来越⾼,进⾏性能测试成为⾦融软件测试中必不可少的⼀个环节。⾦融⾏业软件⼀般在投⼊使⽤时,需要接受⼤批量的业务,并且对于业务的响应处理时间也有很⾼的要求,这对于应⽤程序本⾝、操作系统、中⼼数据库服务器、中间件服务器以及⽹络设备的承受⼒都是⼀个严峻的考验。任⼀个环节的问题都可能给⽤户带来巨⼤的商业损失。因此,如何保证在压⼒情况下系统能正常运⾏是⾦融⾏业软件质量保证的关键,同时也是测试⼈员最需的重点。

  在性能测试过程中,通过性能测试⼯具来模拟与真实环境接近的情况,如通过测试程序在同⼀时间内或某⼀段时间内,向系统发送预期数量的交易请求、测试系统在不同压⼒情况下的效率,获得⼀定的参数(如:(如内存、CPU、缓存、系统响应时间、最⼤吞吐率、事务平均处理时间),以及系统可以承受的压⼒情况,进⾏针对性的测试与结果分析,找到影响系统性能的瓶颈,以便对系统进⾏优化。

  3.5安全性测试

  安全性测试的⽬的主要是评估业务系统在⽹络安全、主机安全、应⽤安全、数据安全、运⾏维护安全、电⼦认证安全、业务连续性等⽅⾯的能⼒及管理措施,评价其业务系统的安全防控和安全管理⽔平。

  对于⾦融⾏业软件来说,安全性有着重⼤的意思,尤其对于⽹络⽇益发达的今天,⼤量的⾦融类交易都是通过⽹络来实现,确保信息的安全,对安全性测试提出了更⾼的要求。如客户数据的安全、资⾦的安全;银⾏主机的安全,应⽤程序的安全以及⽹络安全,某⼀个环节出现问题都会给系统带来巨⼤的风险。安全性测试主要检查出软件存在的安全隐患,确定安全等级,以期得到整改。

  通常⽤的安全性检查⼿段及检查点如:跨站攻击、弱点攻击、管理界⾯泄

露、敏感信息泄露、跨站点请求伪造、恶意上传等。

  对于安全性测试来说,⼀般需要专业的⼯具作为⽀持,因为,⼤多数的安全性测试都会交给具有⼀定资质的第三⽅评测机构来进⾏。

  3.6风险监控测试

  主要⽬的是评估业务系统的风险监控、预警和管理措施,测试其业务系统异常交易、⼤额交易、⾮法卡号交易、密码错误交易等风险的监测和防范能⼒以及系统资源占⽤的监控。

  对于银⾏的较⼤型系统来说,⼀般都会专门开发对应的风险监控系统,⼀类风险监控主要是对系统的交易、资⾦、等情况进⾏监控;另⼀类则是对主机资源情况进⾏监控,对于交易、资⾦类的风险监控测试时主要是根据风险监控需求来验证监控结果是否符合需求描述;对于系统资源类的测试主要被监控主机的资源占⽤情况是否合理。

  风险监控测试⼀般在功能测试阶段或性能测试阶段完成,功能测试或性能测试计划中应包含风险监控的测试。

  3.7⽂档审核

  ⽬的主要是验证业务系统的⽤户⽂档、开发⽂档、管理⽂档等是否完整、有效、⼀致,是否符合相关标准并遵从更新控制和配置管理的要求。

  ⽂档审核最基本的原则是软件实现必须按照⽤户需求⽂档来进⾏设计和实现。对于需求⽂档审核来说,⽂档必须覆盖⽤户所有需求点的描述;对于开发⽂档,如概要设计⽂档、数据库设计⽂档,设计和实现原则应根据需求⽽定;

此外各类管理⽂档审核包括对项⽬⼯期的定义、项⽬⼈员的安排与任务分配、项⽬具体执⾏的定义等等。在实际应⽤中,由于⽤户需求存在经常性的变动已经增加,⽂档也会存在相应的变更,审核部分也包括对变更部分内容的审核。

但是⽬前⾦融⾏业软件没有⼀个严格的规范来进⾏约束,因此,在⽂档审核和实际的开发、测试操作环节都不能得到真正的落实,对测试质量环节也造成了相应的影响。

  3.8⾃动化测试

  现阶段实施的⾃动化测试与⼿⼯测试相⽐较,就是采⽤程序模拟⼿⼯测试的过程。在⾃动化测试过程中,原来由⼿⼯控制的操作,现在由程序来控制,不再进⾏⼿⼯⼲预[5]。⾃动化测试主要⽤于功能测试,测试过程包括脚本的录制、编写及回放。

相关资源