初识银行软件测试

从一家工作了五年的软件公司的测试管理者跳槽到**银行软件测试,短短两个月,对银行测试有了初步认识,总结和记录下来,加深个人的理解,同时也共享给各位。

银行作为大家的理财顾问,对金钱非常敏感,频繁甚至偶尔出现的软件故障都会打击顾客的信心,如果来个黑客攻击,个人财产受到威胁,银行也必然蒙受损失。所以银行对软件的质量要求非常高,这也是银行软件测试的一大特点。接下来从多个角度来谈谈银行的软件测试。

首先,谈谈相关业务和技术。 

由于很多内容怕涉及到银行商业机密,这里就简单地聊一下。

银行主要使用的IBM的服务器技术,我从未接触过DB2,习惯用Oracle的我,实在是适应了相当长一段时间,才接受了DB2这个完全没有前台图形界面的东东。但是数据库的原理是相同的,只要弄清了路径,同样能够完成所需数据的查询和筛选。所以大家遇到Db2时,可以静下心来研究一下它界面上的提示,每个功能都去碰一下,慢慢地就熟悉了它。

银行的系统是相当复杂的,我所拥有的银行相关业务知识也仅限于个人的相关存取款、网银支付。而我所测试的内容是非常庞大的业务体系,大部分业务是无法直接看到的,只能靠自己去理解。例如我要测试某一个业务,我发现我操作的根本不是用户界面,而是开发提供的接口数据提交界面。对于这种情况在银行非常多,所以我们用到的模拟器也非常多。但是对于这些复杂而又看不到用户界面的软件测试,我个人有一个非常好的方法,就是通过梳理业务流程和数据流程,从这里入手,慢慢地通过测试用例扩展自己的业务知识,总结每类业务流程需要覆盖的功能点,最后再整理出本条业务流程需要覆盖的所有场景和检查点。

另外,非常有帮助的就是技术文档。我只要有时间就去看相关相关的设计文档,包括业务需求、整体架构设计、数据库设计、测试计划、测试需求、高手整理的汇总性文档等等(测试用例非常多,我们所测试的项目就以万计,所以未做推荐),通过这些内容,我的知识面会得到很大的扩展,同时不懂的时候可以请教高手,这样,人际关系网络也建立起来了。加上频繁地发问,大家对我的认可度也提高了。我想这也是一种推销自我的手段。一方面获取了知识,一方面同大家建立起了非常不错的关系,一箭双雕呀!

其次,谈谈管理流程和人员。我所在的这家银行将软件测试分为两部分,ST测试和UAT测试,我属于ST功能测试,所以本文谈论也以此为主。ST内部的管理流程是按照非常传统的测试管理方法,制定测试计划-->分析测试需求-->编写测试用例-->执行测试(包括执行测试用例和bug分析)-->总结并编写测试报告。整个过程都有资深测试人员审核和把关,且要求通过评审。测试执行分多轮,一般情况是ST两轮,UAT测试两轮,每轮完成后,会进行交叉测试。测试环境有专人负责,测试过程中开发会频繁修复问题,打版本到测试环境上(这里的术语好像叫倒带)。而测试执行人员一般只在bug修复后去验证,其他时候不太关注测试环境的版本。

而测试管理分了两条线。以我们现有项目为例,测试人员大于50人。一个负责人员管理的大组长A,管理所有测试人员,包括人员协调,业绩跟踪。一个负责技术管理的B,负责制定测试计划、组织分析测试需求和设计测试用例。另外在AB旗下,又分了多个组,有一个测试设计组a,五个测试执行组bcdef,且这六个组每组多名人员,每组再设一个小组长。bcdef组的小组长负责收集每天组员无法判断的问题,去协助解决,对于组内不能解决的,要寻求其他高手或是开发的帮助。我就是某一个执行组的测试执行人员o(_)o。管理者A要求测试执行组的执行人员每天要执行不少于*0个用例。每天的群里第一个消息就是A统计和发布的每人每天的测试执行量。而测试执行人员每天的追求也是完成这些任务。

偶尔还是有培训的,我参与了两次,一次是系统架构的培训,一次是某一部分的业务培训。收获比较多,至少认识了相关的人员,并且遇到对应问题可以请教他们。当然也遇到了不公的待遇。例如我去要系统架构的设计文档,被告知这是内部资料,不方便发给我。就是说,这是内部资料,不能给你这个非内部人员〒_〒。

总之,对比我以前的工作,以追求快速和低成本,验收为“王”。银行项目追求的是功能稳定,性能可靠,安全性高,最终达到客户信任,保证银行和个人的财产完全正确。那么整个测试过程都是环环相扣,每个过程都非常认真对待,影响到的每条业务流程都尽可能地覆盖全面,逻辑严谨。从这个角度,我们测试人员应该多去理解整个测试过程,提升自己的测试水平,不断地进步,才能真正在银行测试方面有所造诣。

我个人的总结作为银行测试从业者的一点忠告,也是对自己的要求,希望能跟大家互勉。仅个人愚见,请大家多多指正。抛砖引玉,希望大家积极发表自己的真知灼见。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页