初识银行软件测试

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

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

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

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

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

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

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

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

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

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

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

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