最近有小伙伴留言说「想了解核心系统建设中，冒烟、SIT、UAT、回归测试的重点，如何设计测试案例，或相关的资料推荐等」。
这个话题很笼统，测试这一块儿除了业务测试，还有性能测试、安全测试等；以及不同的角色对案例的要求也是不一样的，比如：行方业务人员喜欢写将交易从头到尾全部跑一遍的案例，而测试公司的人员喜欢写的很细碎等等。
对此，因为没有经过正规的测试方法训练，主要是说说我的个人理解或感受吧。顺带总结了一些最关键的基础知识和朋友的实际经验，分享给大家，让更多人能够找到方向。
- 此文适合人群：
银行从业人员、业务人员、测试人员。
- 此文解决问题：
对刚接触银行业务的测试人员来说，通过学习有助于系统的理解银行系统相关的测试知识，对日后的工作有一定帮助。
- 此文分为四大部分：
一、银行测试的主要任务
二、银行测试的分类和依据
三、银行测试的案例设计
四、银行测试执行要求及准则
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）。
接着我们聊聊测试的依据。
测试的依据可以分为六点：
- 银行业务规则，如《银行支票中关于中文大写的相关规定》；
- 业务场景要求，如转账业务场景；
- 会计记账规则，如借贷记账法；
- 中央银行下发的各种文件，如人行《关于落实个人账户分类管理制度》；
- 各需求文档输入，如定期存款功能书；
- 其他，如系统原型等。
3 银行测试的案例设计
（1）案例设计分类
（2）要求及准则
（3）注意事项
4 银行测试执行要求及准则
（1）测试执行要求及准则
执行要严格依照业务场景和业务流程进行。
所采用的测试数据一定是可靠的、完整的数据。
测试执行结果数据一定是正确存储，且计算正确的。
执行后特别注意证迹的核对及保留。
测试执行过程中一定需要考虑不同用户实际操作情景，且一定需要在执行时涉及不同机构、岗位、密码等权限控制的控制情况。
（2）执行注意事项
严格依照案例执行，保证测试和案例内容的一致性。
测试数据是依照业务流程做出来的可靠、有效的数据，非手工添加的随意性数据。
批处理交易重点在于被处理的批量数据的状态变化、计算变化以及迁移正确性等。
特别注意与案例中的预期结果不一致的问题。
尽可能的安排交叉测试。
结束语
早前还有小伙伴提出想从测试转开发岗或需求岗，我觉得主要还是要看自己擅长或喜欢哪方面。比如擅长沟通或协调，那做需求比较好；再如喜欢转眼技术，那转到开发岗能更好的施展拳脚；又如擅长逆向思维、善于发现主干之外的异常和分支，那么做测试就非常好。关于测试的话题就先聊到这，感兴趣的小伙伴可以关注，有机会可以扩展一下。
参考文献及注释：
《测试用例设计总结》
《测试大佬对功能测试的总结和反思 》
《ATesting 分享会-银行业测试 》
作者 代堂鸣
转自公众号：小代嘚吧嘚
原文链接：https://mp.weixin.qq.com/s/kwfJXT9IjIOM-cKOxyNNuw
