本文主要是介绍银行业务测试【自用】,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
银行业务测试
- 银行测试的主要任务
- 银行业务测试的分类
- 功能测试
- 性能测试
- 安全测试
- 自动化测试
- 接口测试
- 银行测试业务流程
- 需求分析
- 测试方案编写
- 测试案例编写
- 测试方案、测试案例评审
- 集成测试
- 冒烟测试
- 功能测试
- 测试完成
银行测试的主要任务
测试方式:
一个银行至少有上百个业务系统,无论是新系统的建设,还是已上线系统的业务迭代,这些业务系统的测试方式基本上以手工测试为主,主要目的是验证业务功能逻辑的正确性。
由于银行业务逻辑复杂,系统众多,所以银行的手工测试并不简单,那么自然而然的薪资待遇也比较高。
保障银行业务系统质量的前提是测试,所以测试在银行业务系统生命周期中占有重要的地位。
银行测测试的分类
银行业务测试的分类
功能测试
功能测试可以分为业务功能模块测试、场景功能测试。我们以手机银行整存整取功能为例:
业务功能模块测试,主要是对整存整取的业务流程、业务规则进行业务逻辑进行分析,然后对于分析的功能点进行业务逻辑正确性验证;场景功能测试,进行整存整取一万元、提前部分支取五千元、提前全部支取,其实场景功能测试也是业务功能模块测试的一部分,通过场景推功能
性能测试
性能测试主要为对常用接口,用Jmeter进行并发压力测试,这是最常用的性能测试手段。
安全测试
安全测试主要为通过安全扫描工具,对重要系统进行安全漏洞扫描,一般找第三方机构进行安全漏洞的扫描,等开发修复漏洞后,测试人员进行功能回归测试。
自动化测试
银行测试开展自动化测试的主要目的用于回归测试,避免因为修改某个业务模块,对其它模块功能影响,通过手工进行回归测试比较繁琐,但是自动化测试是交给电脑进行跑脚本,效率会高很多。
接口测试
银行业开展接口测试,更多的是将常用的功能进行接口封装,比如开户功能,这为功能测试人员准备数据提供了便利。
银行测试业务流程
需求分析
对拿到的需求文档进行业务逻辑分析,对于需求中不明确的功能点,总结后通过邮件与开发项目组、业务人员进行确认。
测试方案编写
1)测试范围与测试点: 锁定测试范围根据需求文档,运用测试案例设计方法拆解功能测试点,测试点的描述主要以各级模块需要验证哪些功能点为主。
2)测试方式与工具: 手工还是自动化。
3)测试资源
- 人力资源
- 测试环境:一般情况银行至少有3套环境:开发环境、sit测试环境、uat测试环境。
4)版本质量要求主要内容是,为了提高测试效率,约定每天发版时间,以及缺陷修复周期
5)应交付的测试工作产品
- 测试案例
- 测试案例执行记录
- 缺陷记录
- 测试日报/测试周报
- 测试报告
测试案例编写
根据测试方案中的测试点,进行案例细化编写,基本上是1个测试点对应5条测试案例。
测试方案、测试案例评审
现在基本上是以会议的形式,对于测试方案中的测试点进行宣讲,宣讲过程中项目经理、业务人员会对遗漏点、错误点进行修正说明,测试人员宣讲过程中对于编写过程中的疑问点可以提出。
最终根据评审会的会议记录,对测试方案、测试案例进行修改后,以此落地的测试方案测试案例未经特殊说明,测试人员不接受修改和变化。
集成测试
开发联调测试通过
冒烟测试
选取测试案例中主流程的测试案例,进行冒烟测试,冒烟测试通过才可以进行下一流程测试,冒烟测试未通过应退回至开发项目经理进行重新流程审批。
功能测试
冒烟测试通过后,导入全部测试案例进行测试,验证点与预期结果一致标为通过,不一致标为失败并提缺陷,某些案例无测试数据或无测试环境经项目经理与测试经理达成一致的,可以标为无测试条件。
测试完成
待测试案例全部标为通过,除了少部分测试案例由项目经理、测试经理沟通后达成一致,标为无测试条件、不适用后,缺陷全部修复后,这个阶段的测试任务算是完成。
这篇关于银行业务测试【自用】的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!