银行测试 http://blog.csdn.net/stillming/article/details/42275251

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

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

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

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

银行主要使用的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统计和发布的每人每天的测试执行量。而测试执行人员每天的追求也是完成这些任务。

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

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

一、银行测试工作的特点

与专业测试公司不同，银行软件测试由于受组织结构、人力资源管理模式、系统的复杂程度以及银行业务的特殊要求等因素的影响银行软件测试工作与专业测试公司的测试工作差别较大。

三、测试工作定额评估法

测试工作定额评估法就是将测试任务分解为不可拆分的活动。通过工作日写实或模拟操作换算出每项活动的定额工时，编制工时定额表。将活动与工时定额建立对应关系最终汇总计算出测试工作量的一种工作量评估方法。

1、将测试任务分解为具体活动根据项目管理的WBS方法将测试项目分解为各项测试行动再将测试行动细分成不可划分的活动。银行的适应性测试项目大致分解为以下几项行动。

1）测试前移行动。了解项目的设计、研发、编码以及单元、集成和系统测试的情况详细研究业务需求和软件需求根据应用改造、接口改造情况，编写测试案例。这几项行动可以分解为以下几项活动：一是项目开发情况调研：二是需求分析和评价：三是案例设计和编写，案例编写可以根据具体交易编写单个案例等。

2）测试计划行动。对项目进行详细的规划，编写测试计划，对方案进行讨论、评审并发布实施。可分解的活动有：一是各套环境的统筹规划；二是各套环境的计划编制：三是计划的讨论和修订：四是计划的推进和实施等。

3）测试准备行动。测试文档的编写和评审，测试环境准备和配置，参数安装和数据移行。可分解的活动有：一是测试案例的编写：二是测试案例的评审和培训：三是测试环境的配置和调试：四是参数文本的编制、检查和安装：五是移行文本的编制、移行和移行结果的检查等。

4）测试实施行动。这是测试过程中用时最多、也是最核心的行动维护测试环境，包含功能测试、非功能测试、回归测试、例行化测试、补丁测试等。测试实施可以分解的活动按测试案例或交易分解为单个的活动。

5）项目投产行动。项目投产行动是测试项目的收尾阶段是测试项目的最关键的行动可分解的活动有：一是投产方案的编制：二是投产文档的编写：三是投产验证方案及实施验证：  四是投产支持等。

UT = unit testing 单元测试
IT = integration testing 集成测试
ST = system testing 系统测试
UAT= User acceptance testing 用户接受测试(俗称:验收测试)

UT是单元测试，Unit Test；

单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。；

IT是集成测试，Integration Test；

集成测试阶段是以黑盒法为主，在自底向上集成的早期，白盒法测试占一定的比例，随着集成测试的不断深入，这种比例在测试过程中将越来越少，渐渐地，黑盒法测试占据主导地位。

ST是系统测试，System Test；

从技术角度看，系统测试是整个测试阶段的最后一步，所有的开发和测试在这一点上集中表现为生成一个具有一定功能的软件系统。该阶段主要对系统的准确性及完整性等方面进行测试。主要进行：功能确认测试、运行测试、强度测试、恢复测试、安全性测试等。系统测试的测试人员由测试组成员（或质量保证人员）或测试组成员与用户共同测试。在整个系统开发完成，即将交付用户使用前进行。在这一阶段，完全采用黑盒法对整个系统进行测试。

UAT是验收测试，User Acceptance Test；

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。