在金融APP做自动化这条路上，我们填过哪些坑？

从市场上金融企业对app的重视程度，自然看出其在市场、用户和企业眼中的重要性。甚至有测试部门要求拿着圆规比对icon圆是不是正圆，拿着尺子去量icon尺寸是不是正确！软件质量要求最高的的金融行业，在对待app自动化这件事自然是走在业内前列。

而当前金融行业app做自动化的问题已经不是是否用UI自动化的方式，也不是说是录制、回放还是写脚本的方式。答案很明显：app最注重用户体验，自然要做UI自动化，不能让测试人员写脚本。写脚本对测试人员要求极高，也增加了企业成本。

世人眼中的UI自动化
手工测试人员：UI自动化实现了，测试就可以不用测了自动工程师：最大的难点是维护成本极高，验证功能而非UI，能获得多少收益关键看被测系统本身的稳定性以及自动化技术能力


今天就来说说，为了达到一定高的自动化率，我们都遇到过哪些坑。

在做app自动化过程中，有两大通用性问题不可回避；

1、 屏幕分辨率和系统差异

业内人士一定知道，做app的自动化一定不能依靠坐标，最多作为辅助手段。图像识别也被人诟病，极客们通常是“从入门到放弃”。原因是大家用的开源算法，或许做了点优化，但仍然不能适应多样化的app以及app版本的迭代。

示例：采用坐标点击方式不能适配不同机型



因此这种方式必不可取。

2、 iOS&Android两套完全不同的系统

用例几乎不分两套系统，可是这两套系统却决定了自动化脚本必须是两套。

[img][/img]

对金融企业科技部来讲，要自研这两套系统的app自动化系统，投入太大时间太久，更不用说操作系统升级后的更新（要知道乔爸爸血统一次更新可能就是换血）。


第一大类：影响自动化执行（操作）准确性

H5技术运用越来越多

H5技术的诞生，给开发者带来了福音，却给自动化开发者带来了强烈的冲击。许多原本已经做好app自动化框架大公司也不得重新考虑。而不管选择哪种机制都必然会遇到一些意外：

采用非原生webview控件

为了使产品更加完美，开发人员使用了各种非原生的webview控件，示例：这是开发人员在页面设计时调用了腾讯X5的内核浏览器，就无法用统一的技术获取到页面layout



使用了iframe标签



诸如此类的问题还有很多，H5的layout获取不到、不准确，都将导致自动化执行失败和预期结果检查出错。

键盘加密、验证码获取

乱序加密键盘



这是金融行业最一致的问题，为了让每用例脚本互不影响，初始状态都从登录开始。这些乱序加密键盘不可能获取到layout，那必须采用特定算法精确找到数字区域并自动点击。

手势密码

还有银行通常使用的手势密码

验证码获取

部分金融企业采用了验证码方式：正常验证码、艺术验证码

都需要用特定技术手段获取到准确的验证码内容，同时自动化工具有灵活机制实时填入。

3、 日期控件，不同系统版本、不同手机厂商、不同app开发团队

不管是银行还是证券，对历史记录的查询是不可缺少的测试案例。例如测试前几年某个月的记录，那就需要滑动、点击很多次。这就导致执行准确度低、用例执行效率低。

这需要定制化研发一整套（两套系统，多个版本，多种机型）日期自动化设置小工具，才能实现这些用例的自动化。


第二大类：阻塞结果校验正确行

提取控件部分内容

示例：如图所示的alert内容，需要提取作为预期结果检查，但合同号“5”是变化的。则只能检查“您的申请已提交，合同号为：”。“5”则要单独提取作为查询的索引。

安卓提示采用Toast机制

toast提示难以抓取，就无法从APP端验证流程正确性。这是评价app自动化工具强大的一个标准。

特殊计算

示例：需要计算持仓1/4、1/3的整数份。例如：持仓800股（每手为100股），卖出1/3，则卖出数量为：800/3（取整）=200股（2手）。

如何有效应对版本更新带来的批量脚本更新问题

以上问题都建立在app的页面layout信息不变的情况，而实际上是可能变化的，即使是以稳定为主的金融企业，也会因为创新业务需求，改变页面设计。这就导致一个问题，现在已有大量的测试脚本，这种基于layout的录制方式，页面设计改动后，如何高效更新大量的测试脚本，让自动测试真正的快起来？


TestBird眼中的UI自动化（轻量、简单、高效率）

不写脚本
用例的自动化率达到一定高的程度才能获得收益
维护成本一定要降低到可接受范围
app的自动化是适配多终端、多系统的