随着移动互联网的发展，手机银行凭借低成本、操作简单、不受时间空间约束等优势，正逐步替代传统的网银交易方式。越来越多的银行开始了“业务移动化”转型之路，“手机APP”已经成为企业价值传递和关系维护的关键纽带，客户争夺的主战场已转向移动端，事实上手机银行的用户比例早已超越了网银用户。
但是伴随着银行APP承载的业务需求日益增多、版本迭代速度不断加快，以“手工测试”为基础的测试体系，已很难满足业务对测试效率和质量的要求。APP 测试急需完成从“纯人工”到“人机协同”的范式转换。
一、银行 APP 的质量挑战
银行类APP所承载的业务，都是围绕“钱”展开，比如转账、理财、支付等核心功能，都不开“钱”。而在实际研发过程中，在确定的发版时间约束下，版本实际开发完成后，往往留给测试团队的时间很短，加上使用人工测试，功能覆盖面难以保障，且人工测试效率低下，导致版本发布后问题频出。Top 10 金融APP测试通过率仅52%，无响应、白屏、显示异常现象频出，导致用户体验差。
总结来说，银行在APP测试中，主要面临两大挑战：
（1）功能测试场景：脚本自动化难、脚本维护复用难、参数管理难
（2）兼容性测试场景：没有足够多的机型覆盖
1.1、功能测试场景
1.1.1、“手工”测试难以应对业务快速迭代的挑战
• 业务需求多，发版节奏快
银行业务转型到手机APP后，APP 成为企业“链接”用户的主要载体，原有PC承载的业务，都需要在短时间内迁移到APP，对研发和测试资源带来很大的压力。同时，市场快速变化，存量业务调整和新业务创新探索，也需要保障好质量。为了快速满足业务诉求，将需求拆分为多个版本，快速发版，已经成为企业的刚需。一个月发一次版本，甚至几个月才发一次版本，已经无法跟上市场的节奏。
• “人工”测试效率低，覆盖不够
传统模式下，APP上线前主要依托于测试工程师规划、设计测试用例，然后手动完成测试。但是，银行业务，通常都是跟“钱”相关，对质量要求很高，业务需要更全面的覆盖。
银行类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的兼容问题。
相关资料：
（1）EMAS 移动测试官网：https://www.aliyun.com/product/mqc
（2）EMAS 移动测试业务说明地址：https://help.aliyun.com/document_detail/93530.html
（3）EMAS 专家测试服务：https://www.aliyun.com/service/mobiletesting
