移动端自动化利器UIAutomator

本文章转载于搜狗测试

感谢“白天才痴”同学为我们投稿，今天在这里给大家介绍一下Uiautomator工具在控件定位和使用时的一些问题和经验总结，货真价实的干货、干货、干货。

直奔主题。

使用resourceid定位控件

UISelector提供的定位的方式很多，可以是类名，文本，资源id，索引值等，但是索引、文本很容易随版本变化，类名重复程度又太高，而资源id通常是不会变的，使用多种条件混合有时效果更好。

执行控件方法前判断是否存在

多使用clickAndWaitForNewWindow

对于有跳转的click，使用clickAndWaitForNewWindow会比直接点击更有效，这个方法等待新窗口的出现后才返回，降低了由于卡顿而导致跳转慢最终找不到控件的概率

查找控件失败的可能原因

有的控件设置了属性NAF=true,这个属性大概就是no access flag之类的，表示不能被自动化工具识别到，这种控件我一般用起父控件的坐标去点击。

资料：https://stuff.mit.edu/afs/sipb/project/android/docs/tools/testing/testing_ui.html

用一些重试机制使脚本更稳定

对于自动化，最关注的不是功能点击的实现，而是脚本的稳定性，兼容性，为了写把一个click写好，很可能要额外写10几行代码，下面写的是如何写一个兼容性强的apk安装脚本

takeScreenShot失败？

这两天写自动化时有时会截图失败，会提示device or resource is busy，后来发现是RootExplorer打开着没有完全退出，只是退到了后台，应该是RE打开时把文件系统重洗挂载了导致无法写入截图文件。

同时在实践也发现takescreenshot函数的重载版，设置图片质量和缩放时貌似是无效的，如果图片有传输要求还是自己写代码压缩吧

即使你了解了这些技巧，就目前来看，仍不建议去做功能自动化，脚本的稳定性保证需要很多额外的代码，提升却很有限