目前的方案
- 使用开源框架 appium、calabash、monkeytalk、uiautomator 等工具
- 代码基本采用分层思想（控件层、业务公共方法层、case 层）
- 多线程运行已实现并发测试
缺陷
- 维护成本很高（无论怎样的分层都需要修改 case 来适应版本的迭代变化）
- 接口层的不稳定性、终端的不稳定性、业务流程中的不稳定性等会导致 UI 自动化用例稳定性大打折扣
- 由于是通过控件去实现 case，而控件的遍历耗时很大，导致 30min 内的自动化用例超不过 50 条
- UI 自动化并未真正解决目前测试中所遇到的由于项目的迭代导致测试任务加大的问题
UI 自动化到底该怎么做（只能假象下，说的不对一起讨论下）
-
我们的 case 是怎么来的
- PRD 能否模版化
- 对应 APP 的文档是否可以作为对应 APP 的一门专业语言
- 界面中的文档能否自动识别（有人会说截图太慢，可以去玩下 stf 设备管理平台）
-
APP 中的大部分控件都存在埋点
- UI 自动化为什么不能通过坐标点的点击来执行，从而提高执行效率
- 控件的位置能否通过埋点数据获取（埋点 log 中添加对应分辨率的坐标点）-> 通过大数据解析需要的数据
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
@kinget007 你在干嘛啊？
#1 楼 @lihuazhang 打酱油
太理想化了. 真实的场景要复杂的多.
#3 楼 @seveniruby
（这么晚还看帖<比咱 nb 的人都这么努力，压力山大啊>）
万一实现了呢 _；不过这些都有对应的解决方案，不是纯 yy 的，关键是怎么去实施。
有会为了测试方便去加代码输出控件坐标的开发么。。。。
项目经理这关都过不了。。。
#5 楼 @yangchengtest
那得看具体的情况了；（你得制定一整套项目计划）
1、如果你准备好了所需的基本材料；（实现方式与具体能达成的目标）
2、功能测试这块耗费人力真的很多（主要指重复劳动）；
3、功能测试测试周期很长；
4、小规模实现；（用来尝试：互联网思维就是不断的试错，如果连这勇气的没有那就更别谈创新了）
这样的解释不知道能否赞同 …Y(_) Y
UI 自动化执行速度慢是老问题，不好搞
ui 自动化执行慢一般是 dump 界面控件信息慢导致的，提供给你个我使用的思路，主要提高点击，滑动等触摸操作的效率，适用于 case 重复执行的场景
1.首次调用业务 api 使用用数组保存获取到的一系列坐标
2.再次调用业务 api 时判断数组元素是否有坐标值，有就直接点击，省去 dump 的过程
亲测脚本首次运行 20S 完成的话，每多运行一次都能节省至少 5，6S 的时间，case 量大，重复多的时候效果最好
#9 楼 @kinget007 保存在数组中的坐标值肯定是根据 id 等属性动态获取的哦，不需要维护此类坐标数据，可忽略分辨率的变化的