基于 UI 的自动化不稳定是常态~蛋定

#1 楼 @weamylady 而且控件多了，找到元素特别慢- -#

#2 楼 @ceshichen 你看看源码就知道为啥了，每次都会获取页面源码，解析所有元素放到一个哈希表里面，然后通过哈希表找到某个元素返回进行操作~所以控件多了就会慢~

#3 楼 @weamylady 主要 iOS 获取的是可见和不可见的所有控件...

#4 楼 @ceshichen 这是当然咯~ 你可以自己去改改源码，只获取可见的控件，看看能不能提高速度~

UI 测试稳定性是最大的挑战，这种情况也很正常。元素没有加载，元素加载缓慢，程序 bug 跟本就没有该元素。很多原因，Native，Hybrid 或 H5 还有一定的差别。跟控件显示的时间，控件是否显示，控件是否可用有关系。另外，第一次没有找到，是否需要显示等待。我有部分代码会封装成延迟初始化的形式，页面不对其进行初始化。等到需要使用该元素的时候，才进行查找，查找使用 WebDriver 的显示等待；当然，问题也很明显，当元素明显不存在的时候，代码还是会执行一段等待时间。当然，从整体的角度来考虑已经提高了一定的稳定性。我们碰到的，多是不稳定，尤其是测试版本的软件问题相当多。自动化很神秘，用其来不容易，盲目使用不讨好，不使用又不忍。用在刀刃上吧。

#5 楼 @weamylady 只获取可见的控件，这个是是要改 webdriver 里的东西了么

#7 楼 @ceshichen 该 bootstrap 里面的东西

#8 楼 @weamylady 没找到这个包...通过 dmg 文件安装的 Appium，是有这个问题么

#9 楼 @ceshichen 加头像

#9 楼 @ceshichen 加头像啊

那是因为需要执行 Server-Client Call，再 call 浏览器抽象层，再 call 浏览器 dom，当然很慢了。
能说一下你使用的场景么？
查询多少个元素?都干些啥？

#12 楼 @lucasluo 场景是类似微信的聊天界面，有几百条消息，发送一条，需要找到这条消息的发送状态。目前是通过 xpath 去寻找，原因是 xpath 可以唯一定位到一条消息。结果是信息多了，通过 xpath 去寻找元素就会特别慢。正考虑用 automation 去获取控件名称，通过这个寻找可能会快点，这个还没测试；或者通过只遍历界面上的元素，这个需要改底层代码，没找到@weamylady 说的 bootstrap

#9 楼 @ceshichen 当我没说……那个是 Android 的~

#14 楼 @weamylady - -#，Android Appium 提供的接口，就是在屏幕上查找啊

@ceshichen 如何通过 automation 去获取控件名称，获取的名称唯一能定位这个控件吗？

#16 楼 @crease 嗯，可以，点一下那个控件，就能知道那个控件的名称了