直销银行使传统银行测试走向何方

直销银行是指银行不通过传统的营业网点和柜台，而是通过电话、信件和ATM，以及后来通过互联网和移动终端来提供的银行服务，它的发展是银行利率市场化和互联网技术发展直接导致的产物。近年来，随着互联网金融的深入发展，互联网直销模式已成为各商业银行抢占发展机遇的重要利器，在互联网直销模式下的测试工作，也需改弦易辙，才能在抢占发展机遇中拔得头筹。

　　据统计，从2013年中国第一家互联网直销银行成立到2017年底，我国采取独立直销银行移动客户端服务模式的银行已达120家左右，短短4年时间，互联网直销银行犹如雨后春笋般快速发展，为此“原型模型、敏捷开发、快速迭代”已成为互联网直销银行系统的开发标签。在该开发标签下的测试工作也要做到与时俱进。

DevOps模式下CI/CD的测试转变

　　传统银行业务系统开发模式，大部分都为瀑布模式，基于该模式下的测试工作，也是从拿到业务需求书或软件需求规格说明书后，从上至下依次开展测试工作，而且大部分都是从系统测试阶段才开始入手后续的测试工作。如果需求较明确，且需求较稳定，没有特别大或者特别快的变化，这种测试模式是可以满足传统的银行业务系统开发模式。然而目前大多互联网直销银行的系统开发是在DevOps模式下并应用CI/CD来开展，在CI/CD下的测试工作就需要做到快速且可持续，如果把测试工作放在时间轴上，那么首先需要转变就是测试时间窗口上的测试左移和测试右移。

　　1.测试左移

　　一般狭义上认为CI/CD是指“持续集成/持续交付”，而更加广义的理解是“持续集成/持续测试/持续交付/持续部署”，这里所指的“持续测试”是指在开发阶段所开展的单元/集成测试和接口测试，所以需将测试时间窗口左移到开发阶段，才能在DevOps模式下实现CI/CD测试的可持续且快速的目标。

　　（1）提前分析需求和系统设计

　　测试左移不仅仅是提前开始测试，还需要提前参与需求的评审和系统的设计分析工作。提前参与需求评审工作，对需求可以达到准确的分析，从而可以减少后期测试分析资源的投入；提前参与系统设计分析工作，可以更细致的了解到具体某一个功能实现的方式，从设计上不仅要分析出显式设计，还可以主动思考该设计是否会出现其他问题，通过与设计人员沟通，还会得到一些隐式设计，这些都可以帮助我们增加测试的覆盖面。

　　（2）利用工具自动化开展持续测试

　　测试左移后的测试工作需满足可持续且快速测试的目标，这就需要借助工具自动化开展持续测试工作。

　　首先，针对单元/集成的自动化测试。可利用CI工具Jenkins和代码管理工具GitLab相结合的方式，自动化开展单元/集成测试。具体实现过程为每次开发人员本地更新被测代码或测试脚本后，推送到GitLab，Jenkins通过webhooks检测到GitLab上被测代码或测试脚本更新后，触发一个构建Job，测试人员将测试脚本Clone到本地并执行测试，然后在页面视图上显示测试的结果；如果测试失败，开发人员需要重新修改被测代码并再次提交测试。这样，每更新一次被测代码或测试脚本都可以触发一次测试，从达到了单元/集成自动化测试的效果。

　　其次，再看接口自动化测试。如果是单纯的接口测试工具，则提供的功能相对简单，可以模拟和发送HTTP请求，并显示返回接口结果。例如HttpRequester、Postman等。相比接口测试工具，接口自动化测试工具则功能更加强大，一般和Python相结合可提供接口测试用例的批量执行、接口返回结果的断言以及测试报告的生成等，如JMeter、soapUI、Robot Framework等。

　　最后，是针对UI的自动化测试。开展UI自动化测试的工具有很多，如Selenium、QTP等，不管是用哪种UI自动化测试工具，都需要将其自动化组成部分作组建化剥离，如将测试脚本、测试数据、业务流程及页面对象剥离成互相独立的组件部分，这样如果其中一个组件发生变化，只需单独维护变化部分即可，提高了UI自动化测试的可维护性和执行效率。

　　（3）每日构建和每日测试

　　每日构建在反应速度上没有CI快，它更强调的是通过每天（通常是晚上）自动部署当天开发所累积的代码，并结合每日测试方法进行自动化回归测试，用于评估和衡量项目的进度。

　　测试左移的思想是“尽早发现缺陷，尽早解决”，目的是在DevOps模式下实现CI/CD快速且可持续开展测试，虽不能消除缺陷，但能让缺陷非常容易被发现和改正，降低缺陷修复的成本，在正式系统测试阶段所测试的版本也相对较为稳定，可以更好的再分配后期测试资源。在完成正式的系统测试阶段后，还需要再引入测试右移措施。

　　2.测试右移

　　测试右移就是在完成正式的系统测试阶段后，再引入准生产用户体验测试环节，该测试环节在时间上可与业务验收测试同步开展，但在测试环境上业务验收测试是在验收测试环境开展，而用户体验测试是在准生产环境开展，所以这两类测试又是相互独立的。

　　开展用户体验环节测试是在与生产环境配置、参数基本相同的准生产环境下，由潜在客户自主使用直销银行新上线的系统和产品，类似于β测试。其主要目的有如下：首先，在准生产环境下开展测试，可检验上线版本在正确性、完整性和唯一性；其次，由潜在客户在没有他人帮助下直接自主测试使用银行系统或产品，可以更贴近直销银行的真实场景；最后，也是最重要的一点，可以直接获取到潜在客户针对用户体验的真实反映。

测试角度的转变

　　传统银行系统除自助渠道外，大多数业务系统都是面对一线柜员或银行业务人员，测试角度都是站在银行自身的角度开展测试工作，主要是为了防范操作风险、资金账务风险和经营管理风险。很少站在客户角度去开展测试工作，客户体验不好甚至没有的问题，都可以由一线柜员或银行业务人员内部消化适应。所以测试直销银行系统首先要转变的是从客户角度出发开展测试。

　　1.从客户角度开展测试

　　互联网直销模式下的银行业务系统或产品都是直接面对客户，“简单易懂、门槛低、方便快捷”已成为直销银行系统或产品的标签，同时没有物理网点和大堂经理来协助推广和引导，这就需要转变测试的角度，切实站在方便客户使用的角度开展测试工作，才能扩大直销银行的拓客范围、提高客户粘性。同时横向对比互联网直销模式下银行间的竞争，如果在产品功能和价格没有太大差异的情况下，客户可以有更多的选择，最后直销银行业务系统和产品拼的就是客户体验上的谁更“好用”。

　　从客户角度开展测试，不仅要测试包括易理解性、易学性、易操作性，还要包括响应时间、兼容性等内容。同时也要参考Krug可用性三大定律来开展客户体验测试：（a）别让我思考；（b）每次点击都无思考；（c）去掉每个页面上一半的文字，然后把剩下的文字再去掉一半。例如“预约转账”这个功能，可能是传统银行下网银系统和手机银行最普遍的一个功能了，包括功能菜单的名字也都是叫“预约转账”，但这个功能到底能做什么，能为客户提供什么服务或者便利，都需要客户先点击“预约转账”这个功能菜单后，并且经过客户一番尝试和思考才能知道，这就与Krug可用性三大定律相违背，假如遇到了不愿做新尝试及思考的客户，仅通过“预约转账”这个菜单名称，这类客户可能永远都不会知道还可以利用这个功能定时给信用卡或房贷自动还款。于是在某宝的APP上直接将“预约转账”这个功能菜单的名称换成了“用它定时自动帮我还贷款”，首先这个菜单名称就非常的“接地气儿”，其次更是直接明了的概括了这项业务的功能和用途。

　　互联网直销模式下的银行业务系统和产品需要这种“接地气儿”的设计思维，从测试来说也需要站在客户角度多发现这种“不接地气”的设计缺陷。

　　2.提高客户体验缺陷的重视程度

　　在传统银行模式的系统中也有一定的用户体验测试，但大都没有把用户体验测试上升到较高的层次，在测试传统银行系统时也会提出一些用户体验上的问题，但由于在需求书中并没有可具体量化的客户体验需求指标，所以用户体验该类问题最高也就被定义为“建议级”缺陷，然而“建议级”缺陷的修复结果在测试通过标准上以及绩效考核上的占比又很小，所以开发人员和测试人员对该级别的问题都没有重视起来。

　　要想重视客户体验的缺陷，首先就要加强客户体验类的需求描述及体验类的测试需求分析，先从源头转变认知的角度；其次是将客户体验类的缺陷级别上升到与功能缺陷相同的“严重”级别，只要是合理、合规并确实有助于方便客户使用的体验类缺陷都可以定义为“严重级”缺陷，这样就可以从管理流程上、通过标准上以及开发测试人员的绩效考核上都可以提高对客户体验类缺陷的重视程度。

　　3.发挥众测和A/B测试

　　传统银行可发挥众测的优势，利用互联网和大众的测试能力和测试资源，从用户体验的角度出发，在短时间内完成大工作量的产品体验，对互联网直销模式下的业务系统和新产品提出改进建议，以及各种bug反馈，以便于及时地改善产品质量。

　　同时也可以发挥A/B测试的特点，将不同特性、不同版本的新产品发布给不同的用户使用，然后比较这些特性所造成的不同影响，从而选择出最受客户欢迎的软件特性和版本。

　　互联网和移动端正在改变人们的生活方式，互联网直销模式也正在悄悄转变着传统银行系统特点和经营模式，这种改变是大时代的潮流所驱。所以传统银行测试互联网直销模式下的业务系统，也必须做出适应性的转变，不管是测试时间窗口的位移还是测试角度的转变，只要是有助于适应这个大时代潮流的改变，都可以勇于尝试，在这个过程中唯一不变的可能就是改变。

（文章来源：金融电子化杂志）

扫码即可手机
阅读转发此文