您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

银行核心项目之测试阶段

发表于:2022-12-28 作者:代堂鸣 来源:小代嘚吧嘚

最近有小伙伴留言说「想了解核心系统建设中,冒烟、SIT、UAT、回归测试的重点,如何设计测试案例,或相关的资料推荐等」。

这个话题很笼统,测试这一块儿除了业务测试,还有性能测试、安全测试等;以及不同的角色对案例的要求也是不一样的,比如:行方业务人员喜欢写将交易从头到尾全部跑一遍的案例,而测试公司的人员喜欢写的很细碎等等。

对此,因为没有经过正规的测试方法训练,主要是说说我的个人理解或感受吧。顺带总结了一些最关键的基础知识和朋友的实际经验,分享给大家,让更多人能够找到方向。

1、此文适合人群:

银行从业人员、业务人员、测试人员。

2、此文解决问题:

对刚接触银行业务的测试人员来说,通过学习有助于系统的理解银行系统相关的测试知识,对日后的工作有一定帮助。

3、此文分为四大部分:

一、银行测试的主要任务

二、银行测试的分类和依据

三、银行测试的案例设计

四、银行测试执行要求及准则

1

银行测试的主要任务

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

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

(1)测试规则编写

测试规则是通过分析需求得出来的,是对原始需求进行分析找到需要测试的要点,是测试工作的第一步。一般由中、高级测试人员编写测试规则,写的越详细越精准,就表明对所测业务越了解,更容易发现系统问题和业务问题,更能把握测试的质量和进度。

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

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

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

测试文档不需要太复杂,直接使用excel编撰就可以了,我们以核心系统存款模块的定期部提交易为例,请看下图:

(2)测试案例编写

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

但关于测试要点细化到什么程度,是一个度的问题,我们要把握好测试点细化的一个度的问题,太粗的测试点没有指导意义,太细的测试点容易让我们纠的太细,忽略整体的测试,反而也起不到一个指导的效果,所以一定要把握好测试点细化的度。那作为新手入门,都会遇到哪些问题呢?

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

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

还有就是,每个人的测试案例都不能说完美全面,都是在不断地评审过程中尽量的做到全面一些,覆盖率高一些。不过老员工毕竟经验和阅历要比小白多,所以在写测试案例的过程中,肯定有一套合适的方法。接下来,我们以手机银行开立定期整存整取为例子,分享一下干货,让所有测试的“巧妇”有米为炊。

(3)测试案例评审

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

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

其次,通过测试案例评审,产品和开发可以通过对案例合理性和全面性进行评估,指出案例设计不合理或遗漏之处,以便更好的完善测试案例,提高测试案例的质量。

再者,如果囿于各种限制条件导致开发无法展开技术评审会议,那么在案例评审也可以和开发沟通确认实现方式,关注不同实现方式的测试点,以实现全面测试;

最后,常言道,测试人员是项目的前灯,是一个探路的角色,所谓良医治未病,那么测试人员就应该在项目前期多挖掘潜在的坑,并提醒开发注意,慎防掉坑,同时也降低了bug出现的概率,减少开发测试成本。

所以,因为很多需求的细节无法在需求阶段考虑完全,就会采用反复沟通的方式与相关人员不断细化,一般来说,这样评审会反复三次左右,以便完善案例。后面基本都会因为项目排期太紧或是需求变动次数过于频繁, 而对案例进行选择性的快速评审。

(4)冒烟测试

测试案例评审通过,待开发提交测试以后,测试人员迅速完成一轮“冒烟测试”。冒烟测试的目的是为了确认基本功能是否正常,可以进行后续的正式测试工作,将正式测试未知的风险降至最低,防止bug阻塞导致测试进度阻塞。不过也有项目是评审到一半的时候就会开始冒烟测试,边评审边冒烟。

站在核心开发组的角度,一般在通知测试人员冒烟测试之前,开发组内部会提前进行一些交易的验证,特别是在迁移冒烟测试阶段,各方领导都特别关注,因为迁移冒烟出现的问题直接影响到UAT的开始时间或是能否如期投产。所以基本都是发现如果存在问题,是要求即时解决,马上验证,或是当天内解决,并且会有项目助理持续跟进,逐个确认、收集反馈等。

另外,关于冒烟测试案例的建设,有两点建议:一是测试案例管理员与开发经理沟通确认新增功能点;二是确定原有案例中有哪些在新项目上仍然有效,删除不再适用的测试案例,由此建立一套新的测试案例。

(5)功能评审

在测试人员开始执行测试案例的同时,业务人员会组织一次“功能评审会”或是叫“演示会”,利用测试环境,把可以使用的功能在第一时间展示给相关干系人,更进一步确保做出来的东西就是大家想要的。

(6)测试

接下来,测试人员会做多轮测试,是一个“发现Bug,开发修复,复测,发现新Bug”的循环过程,从第二轮开始就可以叫做“回归测试”,经过多轮测试后,项目会要求行方各用户代表做更详细的UAT。

一般来说,在SIT末或进入UAT初期,是缺陷最多的时候,也是开发人员最难熬的时间段(个人感觉,不知道测试人员在此阶段是啥体会)。

在这段时期会遇到各种问题,比如参数不一致、功能反复修改后仍与需求不一致、打印输出字段不对、版本没管理好导致测试成功的案例出现复测失败、解决一个bug导致出现新的bug、解决时间超期、以及夜间批量各种报错、是不是有人催进度等等,让人应接不暇,手忙脚乱。

其实越来这种时候越不能急,越到淡定,天大的bug也得挨个处理。调整个人状态和做事的方法,挺过这段时期,后面就会好很多。当经过多轮UAT测试,在Bug都处理处理妥当之后,会进入UAT收尾、程序版本封板、参数核对及封板、演练及投产准备工作等。

此时,商业方面的准备工作也早已动起来了。业务人员可能要准备面向用户的功能、买点介绍的文档,产品更新的公告;培训服务人员和销售人员;运营人员可能已经在策划推广方案;销售人员可能在更新销售说辞······多个部门协同,很有大家在一起战斗的感觉。

★名词解释

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

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

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

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

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

2

银行测试的分类和依据

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

(1)功能测试

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

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

(2)性能测试

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

(3)安全测试

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

(4)其他性质

其他性质分为系统测试、硬件测试(POS机,智能柜台)、周边测试(ATM)。

接着我们聊聊测试的依据。

测试的依据可以分为六点:1.银行业务规则,如《银行支票中关于中文大写的相关规定》;2.业务场景要求,如转账业务场景;3.会计记账规则,如借贷记账法;4.中央银行下发的各种文件,如人行《关于落实个人账户分类管理制度》;5.各需求文档输入,如定期存款功能书;6.其他,如系统原型等。

3

银行测试的案例设计

(1)案例设计分类

(2)要求及准则

(3)注意事项

4

银行测试执行要求及准则

(1)测试执行要求及准则

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

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

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

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

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

(2)执行注意事项

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

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

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

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

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

结束语

早前还有小伙伴提出想从测试转开发岗或需求岗,我觉得主要还是要看自己擅长或喜欢哪方面。比如擅长沟通或协调,那做需求比较好;再如喜欢转眼技术,那转到开发岗能更好的施展拳脚;又如擅长逆向思维、善于发现主干之外的异常和分支,那么做测试就非常好。关于测试的话题就先聊到这,感兴趣的小伙伴可以关注,有机会可以扩展一下。

参考文献及注释:

1.《测试用例设计总结》

2.《测试大佬对功能测试的总结和反思 》

3.《ATesting分享会-银行业测试 》

文章转载自公众号 小代嘚吧嘚 , 作者 代堂鸣