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

第一大类：影响自动化执行（操作）准确性
h5技术运用越来越多
h5技术的诞生，给开发者带来了福音，却给自动化开发者带来了强烈的冲击。许多原本已经做好app自动化框架大公司也不得重新考虑。而不管选择哪种机制都必然会遇到一些意外：
采用非原生webview控件
为了使产品更加完美，开发人员使用了各种非原生的webview控件，示例：这是开发人员在页面设计时调用了腾讯x5的内核浏览器，就无法用统一的技术获取到页面layout
使用了iframe标签
诸如此类的问题还有很多，h5的layout获取不到、不准确，都将导致自动化执行失败和预期结果检查出错。键盘加密、验证码获取
乱序加密键盘
这是金融行业最一致的问题，为了让每用例脚本互不影响，初始状态都从登录开始。这些乱序加密键盘不可能获取到layout，那必须采用特定算法精确找到数字区域并自动点击。手势密码
还有银行通常使用的手势密码
验证码获取
部分金融企业采用了验证码方式：正常验证码、艺术验证码
都需要用特定技术手段获取到准确的验证码内容，同时自动化工具有灵活机制实时填入。1、日期控件，不同系统版本、不同手机厂商、不同app开发团队
不管是银行还是证券，对历史记录的查询是不可缺少的测试案例。例如测试前几年某个月的记录，那就需要滑动、点击很多次。这就导致执行准确度低、用例执行效率低。这需要定制化研发一整套（两套系统，多个版本，多种机型）日期自动化设置小工具，才能实现这些用例的自动化。第二大类：阻塞结果校验正确行
提取控件部分内容
示例：如图所示的alert内容，需要提取作为预期结果检查，但合同号“5”是变化的。则只能检查“您的申请已提交，合同号为：”。“5”则要单独提取作为查询的索引。安卓提示采用toast机制
toast提示难以抓取，就无法从app端验证流程正确性。这是评价app自动化工具强大的一个标准。特殊计算
示例：需要计算持仓1/4、1/3的整数份。例如：持仓800股（每手为100股），卖出1/3，则卖出数量为：800/3（取整）=200股（2手）。如何有效应对版本更新带来的批量脚本更新问题
以上问题都建立在app的页面layout信息不变的情况，而实际上是可能变化的，即使是以稳定为主的金融企业，也会因为创新业务需求，改变页面设计。这就导致一个问题，现在已有大量的测试脚本，这种基于layout的录制方式，页面设计改动后，如何高效更新大量的测试脚本，让自动测试真正的快起来？test bird眼中的ui自动化（轻量、简单、高效率）
不写脚本
用例的自动化率达到一定高的程度才能获得收益
维护成本一定要降低到可接受范围
app的自动化是适配多终端、多系统的