银行类软件测试概述及流程简介

银行类软件测试概述及流程简介

★名词解释

冒烟测试(Smoke Test)：可以理解为该测试耗时短，仅用一袋烟功夫足够了。也有人任务是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟。

UAT(User Acceptance Test)：用户接受度测试。当然，更好的做法是直接让用户来测试。

验收测试(Acceptance Test)：指除了把系统所有功能、性能概要测试一遍之外，还需要检查项目交付物，比如项目阶段文档、用户手册等是否齐全、是否符合规范。

回归测试(Regression Test)：修改的代码部署版本后，复测之前的出现的BUG、验证版本的正确性。往往一个系统上线，都要经过多次回归，有的公司采取多轮次，第一轮、第二轮、第三轮等，都是回归测试的展现形式，只不过每轮次（回归）的测试重点不一样。

Bug：指缺陷或故障，区别在于项目上线之前发现的叫缺陷，项目上线之后发现的叫故障，通常故障会对用户造成伤害，团队里也针对故障制定了分级制度，针对责任人制定了相应的惩罚制度。

银行测试的分类

在计算机行业，开发人员在实际的开发工作中会有自己涉及的主要领域，cobol,java,python,php,C等。测试人员也一样，因此银行测试的分类是有很多种的，按测试的内容可以分为：功能测试、性能测试、安全测试和其他性质。

（1）功能测试

功能测试可以分为模块功能测试、业务功能测试、场景功能测试和报文功能测试。我们继续以手机银行整存整取功能为例：

模块功能测试，如增删改查、下拉框的选择、值域的输入、点击按钮后的反应；业务功能测试，如定期转活期功能测试；场景功能测试，如定期存款流程、提前销户、提前部分支取，将业务功能串成一条；报文功能测试，如与支付系统或核心系统交互报文测试。

（2）性能测试

功能测试可以分为大容量场景测试、端对端并发测试、加挡板测试、业务压力测试。

（3）安全测试

安全测试可以分为报文加密测试、密码安全测试、穿透测试（防火墙）、通道传输安全性测试。

（4）其他性质

其他性质分为系统测试、硬件测试（POS机，智能柜台）、周边测试（ATM）。

银行测试执行要求及准则

（1）测试执行要求及准则

1.执行要严格依照业务场景和业务流程进行。

2.所采用的测试数据一定是可靠的、完整的数据。

3.测试执行结果数据一定是正确存储，且计算正确的。

4.执行后特别注意证迹的核对及保留。

5.测试执行过程中一定需要考虑不同用户实际操作情景，且一定需要在执行时涉及不同机构、岗位、密码等权限控制的控制情况。

（2）执行注意事项

1.严格依照案例执行，保证测试和案例内容的一致性。

2.测试数据是依照业务流程做出来的可靠、有效的数据，非手工添加的随意性数据。

3.批处理交易重点在于被处理的批量数据的状态变化、计算变化以及迁移正确性等。

4.特别注意与案例中的预期结果不一致的问题。

5.尽可能的安排交叉测试。

银行类软件测试的基本流程

银行作为大家的理财顾问，对金钱非常敏感，频繁甚至偶尔出现的软件故障都会打击顾客的信心，如果来个黑客攻击，个人财产受到威胁，银行也必然蒙受损失。所以银行对系统的质量要求非常高，追求功能稳定、性能可靠、安全性高、最终达到客户信任，保证银行和个人的财产的完全。

而保障系统高质量的前提是测试，测试是整个核心项目中非常重要的一个阶段，所以测试人员的角色很重要。就先从测试阶段的主要任务说起。

（1）测试范围编写

测试范围是通过分析需求得出来的，是对原始需求进行分析找到需要测试的范围，是测试工作的第一步。一般由中、高级测试人员编写测试范围，写的

越详细越精准，就表明对所测业务越了解，更容易发现系统问题和业务问题，更能把握测试的质量和进度。

若是测试需求分析的不明确，那么测试范围的要点就不清晰，测试案例的编写更是毫无根据。可能会造成时间或资源的浪费、测试工作量评估不准确，导致项目延期。那么，该如何提升需求分析能力？

首先，通过阅读需求文档了解需求的实现背景、了解需求的目的和用户使用的场景，在这过程中遇到疑惑先记下来，与业务多交流从而尽快熟悉业务知识；其次是分析需求的合理性，站在用户或业务的角度进行分析、理解、思考，给需求或开发人员一些设计上的建议，避免被惯性思维束缚；最后，充分利用身边或网络上的学习资源，比如好的博客或公众号，学习前辈的经验并运用到实际工作中去。

我们再回到小标题，关于测试范围的编写，对于初级测试人员来说，前面是模仿，照着有经验的人写出来的案例跟着写。后续加上多学习、多思考、多总结和分享，需求分析能力会有非常大的提升，后面慢慢也就能流畅的编写测试范围了。

（2）测试案例编写

早在开发人员在设计和编码的同时，测试人员就已经在不断的细化和调整测试计划，并完成测试案例的编写。测试案例的编写其实就是根据上述的测试规则，细化出具体的测试案例，包括测试目标、测试环境、输入数据、测试步骤、预期结果等。

但关于测试要点细化到什么程度，是一个度的问题，我们要把握好测试点细化的一个度的问题，太粗的测试点没有指导意义，太细的测试点容易让我们

纠的太细，忽略整体的测试，反而也起不到一个指导的效果，所以一定要把握好测试点细化的度。那作为新手入门，都会遇到哪些问题呢？

比如，很对人不知道如何开始书写测试案例，但迟迟不敢下手写测试案例的话，又担心影响整体的测试计划因为自己的延误而受影响。对于前怕狼后怕虎的心态，建议是不要顾虑自己的案例好与不好，先写下来；或者是参考以前写好的公共测试案例，甚至直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。

其次，测试案例都会参加案例评审，有资深测试人员和业务人员进行把关，测试案例中的问题会被发现，评审人都会给每个人修改意见。所以，安下心来写出自己想到的测试案例，这样才能帮助发现问题从而更好地解决。

还有就是，每个人的测试案例都不能说完美全面，都是在不断地评审过程中尽量的做到全面一些，覆盖率高一些。不过老员工毕竟经验和阅历要比小白多，所以在写测试案例的过程中，肯定有一套合适的方法。

（3）测试案例评审

测试案例编写完成后，测试经理就会组织测试案例评审，也就是对测试案例进行检查。时间一般在开发人员将交易或功能送测之前，行方业务或科技的主要干系人都要参与评审，一条一条的过案例，再次确认大家对需求的理解是否一致。测试案例评审是测试流程中极为关键的一环，案例评审何为如此重要？

首先，通过测试案例的评审不仅可以消除产品、开发、测试三方对需求文档理解的偏差，还可以保证测试内部人员，即测试执行者和测试案例设计者在测试质量保障方面保持一致性；