With the development of mobile Internet, mobile banking with low cost, simple operation, without time and space constraints and other advantages, is gradually replace the traditional online banking transactions. More and more banks began a "mobile business" of transformation of the way, "Mobile APP" has become a key link business value delivery and relationship maintenance, the customer compete for the main battlefield has shifted to move the end, in fact, the proportion of users of mobile banking It goes beyond the online banking user.
But along with the bank APP carrying business needs growing, the iterative version continues to accelerate, with "manual test" based test system has been difficult to meet the business requirements of the test efficiency and quality. APP test the urgent need to complete the conversion from "purely artificial" to "man-machine cooperation" paradigm.
First, the bank APP quality challenge
Banking APP carrying business, all around "money" to start, such as transfer, financial management, payment and other core functions, do not open "money." In the actual development process, under certain time constraints issued version after version of the actual development is completed, often left to the test team for a short time, coupled with the use of manual testing, functional coverage is difficult to guarantee, manual testing and low efficiency, resulting in after the release frequent problems. Top 10 financial APP test rate by 52%, no response, black and white, show frequent anomalies, resulting in poor user experience.
In summary, the bank APP test, faces two major challenges: (1) functional test scenarios: automation scripts difficult, script maintenance reuse difficult, difficult parameter management (2) Compatibility test scenario: not enough models cover
1.1, functional test scenarios
1.1.1 "manual" test is difficult to meet the challenges of rapid iteration of business
-
Business needs more, faster-paced version of hair
After the transition to mobile phone banking APP, APP become "the link" the main carrier of the user, the original bearer of the PC business, will need to be migrated in a short time to APP, development and testing resources of a great deal of pressure. At the same time, rapid changes in the market, the stock of business restructuring and innovation to explore new business, but also the need to guarantee good quality. In order to quickly meet business demands, the demand is split into multiple versions, Express version hair, has become a business just to be. Hair once a month version, or even months to send a version, it has been unable to keep up with the rhythm of the market.
-
Low "artificial" test efficiency, insufficient coverage
Under the traditional model, the front line is mainly relying on the APP test engineers plan, design test cases, and then manually complete the test. However, banking, usually with "money" relevant, high quality requirements, business needs a more comprehensive coverage.
银行类APP，每次需要投入几十个测试人员来进行测试验证。一些银行，在引入阿里云 EMAS 自动化测试平台以前，用例自动化覆盖率只有10%左右，甚至完全没有自动化，主要依靠人工的方式进行测试，用例多，测试周期长，发版周期也直接受到影响。
1.1.2、模拟业务场景困难
银行业务链路通常都很长，不是一两步就能完成，而且实际业务流程中，涉及到的测试参数多达几百个。另外，传统接口测试无法模拟真实场景，导致测试结果和实际情况有较大偏差，上线后出问题也是情理之中的事。
1.1.3、业务覆盖率不够，上线后问题频出
实际研发过程中，测试工程师所测试的版本并不是固定不变的，尤其是进入到发版阶段后，几小时就有一个新版本。面对这种情况，测试工程师测试重点保障核心业务功能，无法保障整体用例覆盖率，这就给版本发布埋下了隐患，导致版本上线后出现问题。
1.1.4、测试知识缺乏数据化、资产化
传统手工测试方式，主要依靠个人的主观能动性和过往的经验积累，实际测试过程中，一些成功的测试用例场景、测试方法缺乏沉淀，难以完成从“个人能力”到“组织能力”的升华，进而无法完成组织效能的跃升。
1.2、机型兼容性测试场景
1.2.1、机型多、分辨率多、系统版本多
国内手机厂商，一般每年都有两次新品发布会，即春季和秋季发布会，每年累计有上百款机型发布，几年下来，累计的主要机型有上千款。以一个百万月活的APP为例，iOS 和 Android 两个平台一起，通常需要覆盖Top 150 款以上的机型，才能覆盖自身80%以上的用户，而如果想要确保覆盖95%以上的用户，则通常至少需要覆盖Top 500 款以上的机型。
而且，不同的机型、不同的分辨率、不同的系统版本，也会引发更多的兼容性风险。这也是导致金融类Top 10 APP 整体机型通过率不足50%的重要原因。
1.2.2、机型采购有限
作为银行，不可能购买全量机型，并经常更新，通常是购买主流旗舰机型，大概在50款以内。这样的机型覆盖度，可以规避50%左右的用户兼容性风险，但相对高质量的 APP 还存在很大的差距。
二、阿里云 EMAS 解决方案
阿里云 EMAS 移动测试平台，针对银行的「功能」和「兼容」两种场景，都有成熟的解决方案。
-
EMAS 提供私有部署的测试平台解决功能测试的问题 ，提升脚本生产效能，保障业务覆盖率
-
EMAS 提供48小时一站式专家测试服务，APP上线前，650款主流机型全量回归测试，解决机型兼容问题
2.1、功能测试场景
阿里云 EMAS 移动测试平台提供私有部署输出服务，主要解决银行功能测试场景的诉求。私有部署不仅满足银行安全、政策合规的要求，而且，独享的自动化测试平台，还可以基于OpenAPI 联动 DevOps等其它系统平台。
【图1】EMAS 移动测试系统架构图
2.1.1、强大的用例库
【图2】EMAS 移动测试平台，用例库立体结构
功能测试的重点在于用例库，而用例库的核心在于如下4点：
-
用例设计
-
用例脚本化
-
参数管理
-
脚本的高可复用
【用例设计】 做事之前，先规划。用例设计就是进行测试之前的整体规划，会涉及到不同的项目组，不同的业务线。EMAS 测试平台提供了“项目组”的概念，可以有效解决多项目组协同的问题。同时，用例设计落到具体的业务功能上，就要求测试人员在进行整体“用例脚本化”之前，从更高的层面设计整体用例结构，明确规范。阿里云 EMAS 平台可以输出对应方法论，指导具体实践。
【用例脚本化】 脚本化即程序化。EMAS 移动测试平台，提供了在线录制脚本的能力，可以不用学习 Appium 框架、Python 或 Java语言，就可以完成基本用例的程序化，极大降低上手成本。同时，由于是基于开源的测试自动化框架 Appium 作为基础升级改造而成，可用于原生,混合和移动Web应用程序测试，兼容性好。
【图3】在线录制脚本-左侧是APP页面，右侧是录制的步骤
【图4】录制完成后，可以录制回放步骤，左侧手机可以看到实时效果
自身业务常用能力，也可以自己封装为固定步骤，变成一个菜单，需要的时候，直接点击生成脚本。
【图5】常用步骤菜单
【参数管理】 银行业务，由于参数有几百个之多。EMAS 移动测试平台在数据管理上，主要由两个大的突破： （1）在参数传递上，支持按变量传递，也支持直接传固定参数值； （2）为了解决多数据管理复用问题，提供了三层数据管理能力，即：
-
APP 全局参数集：例如服务器 ip 地址
-
用例集参数：多用例公用的参数
-
用例参数：单个独立用例使用的参数
【脚本的组合复用】 为了避免同样的功能，重复录制成多份脚本导致的资源和人力的浪费，平台提供了用例的高可复用能力。
例如，登录功能，录制完成一份脚本后，可以作为单步骤，插入到其它业务脚本流程里，极大提升复用率。同时，由于可以控制传递的参数，可以在正常和非正常的测试用例中复用，进一步扩大脚本的复用场景。
【图6】“登录”脚本，可以被复用两次。如果业务功能不变，可以一直复用，跟其他脚本组合，覆盖更多场景。
2.1.2、特殊场景覆盖
银行业务里面，还有很多特殊场景，比如随机密码键盘、验证码处理、还有一些文字的识别、上传身份证处理等
【图7】随机密码键盘
针对这些特殊场景，阿里云也提供对应的解决方案，保障脚本自动化的时候，不被打断。
2.1.3、测试方法论
为了确保平台能发挥出最大的效能，基于阿里多年的经验积累，输出EMAS 测试平台最佳实践方法论。
【图8】“平台能力”+“人工”的最佳实践，提升效能
2.2、机型兼容性测试场景
私有部署的 EMAS 移动测试平台，侧重在功能场景的覆盖，但是由于机型有限，也不太可能同时购买几百款机型。为了解决机型覆盖兼容的问题，阿里云 EMAS 提供了一站式48小时的专家测试服务，可以覆盖安卓Top 600款机型，iOS top 70款项机型。
【图9】48小时一站式专家测试服务
三、总结
银行类APP，在版本快速迭代中，面临功能和兼容两个维度的挑战，阿里云 EMAS 提供了两个场景的解决方案 （1）功能覆盖场景：阿里云 EMAS 平台可以提供在线录制、用例管理、参数管理等能力，降低用例脚本化和维护成本； （2）兼容覆盖场景：阿里云 EMAS 提供一站式专家测试服务，覆盖650款以上主流机型，解决APP的兼容问题。
本文为阿里云内容，未经允许不得转载。