Appium Android Bootstrap之控件AndroidElement

* Return an elements child given the key (context id), or uses the selector * to get the element. * @param sel * @param key *          Element id. * @return {@link AndroidElement} * @throws ElementNotFoundException public AndroidElement getElement(final UiSelector sel, final String key) throws ElementNotFoundException { AndroidElement baseEl; baseEl = elements.get(key); UiObject el; if (baseEl == null) { el = new UiObject(sel); } else { try { el = baseEl.getChild(sel); } catch (final UiObjectNotFoundException e) { throw new ElementNotFoundException(); if (el.exists()) { return addElement(el); } else { throw new ElementNotFoundException();
如果是第1种情况就直接通过选择子构建UiObject对象，然后通过addElement把UiObject对象转换成AndroidElement对象保存到控件哈希表 如果是第2种情况就先根据appium传过来的控件哈希表键值获得父控件，再通过子控件的选择子在父控件的基础上查找到目标UiObject控件，最后跟上面一样把该控件通过上面的addElement把UiObject控件转换成AndroidElement控件对象保存到控件哈希表 4. 求证 上面有提过，如果pc端的脚本执行对同一个控件的两次findElement会创建两个不同id的AndroidElement并存放到控件哈希表中，那么为什么appium的团队没有做一个增强，增加一个keyMap的方法（算法）和一些额外的信息来让同一个控件使用不同的key的时候对应的还是同一个AndroidElement控件呢？毕竟这才是哈希表实用的特性之一了，不然你直接用一个Dictionary不就完事了？网上说了几点hashtable和dictionary的差别，如多线程环境最好使用哈希表而非字典等，但在bootstrap这个控件哈希表的情况下我不是很信服这些说法，有谁清楚的还劳烦指点一二了 这里至于为什么appium不去提供额外的key信息并且实现keyMap算法，我个人倒是认为有如下原因： 有谁这么无聊在同一个测试方法中对同一个控件查找两次？ 如果同一个控件运用不同的选择子查找两次的话，因为最终底层的UiObject的成员变量UiSelector mSelector不一样，所以确实可以认为是不同的控件 但以下两个如果用同样的UiSelector选择子来查找控件的情况我就解析不了了，毕竟在我看来bootstrap这边应该把它们看成是同一个对象的： 同一个脚本不同的方法中分别对同一控件用同样的UiSelelctor选择子进行查找呢？ 不同脚本中呢？ 这些也许在今后深入了解中得到解决，但看家如果知道的，还望不吝赐教 5. 小结 最后我们对bootstrap的控件相关知识点做一个总结 AndroidElement的一个实例代表了一个bootstrap的控件 AndroidElement控件的成员变量UiObject el代表了uiautomator框架中的一个真实窗口控件，通过它就可以直接透过uiautomator框架对控件进行实质性操作 pc端的WebElement元素和Bootstrap的AndroidElement控件是通过AndroidElement控件的String id进行映射关联的 AndroidElementHash类维护了一个以AndroidElement的id为键值，以AndroidElement的实例为value的全局唯一哈希表，pc端想要获得一个控件的时候会先从这个哈希表查找，如果没有了再创建新的AndroidElement控件并加入到该哈希表中，所以该哈希表中维护的是一个当前已经使用过的控件 相关文章： Appium Android Bootstrap源码分析之简介
Win10系统下基于Docker构建Appium容器连接Android模拟器Genymotion完成移动端Python自动化测试 Python自动化，大概也许或者是今年最具热度的话题之一了。七月流火，招聘市场上对于Python自动化的追捧热度仍未消减，那么Python自动化到底能帮我们做些什么呢？ 第一，Python自动化可以避免熟练工种的重复工作，对于功能相对完整和成熟的软件，每发布一个新的版本，无论是大版本还是小版本，其中大部分功能和界面都几乎和上一个版本相似或完全相同，但所谓向上兼容，你不能因为新功能的产生而不对老版本功能进行测试工作，而这些老功能又在上一个版本上线时测过，所以这部分功能特别适合于自动化测试，从而可以让测试达到测试每个特征的目的。
Python+Appium自动化测试(15)-使用Android模拟器（详细）（一） 做APP的UI自动化测试时，我们往往会使用真机跑自动化测试脚本，因为这样才是最真实的使用场景。但前期调试脚本的话，可以先使用模拟器，这样相对更加方便。 不推荐使用Android SDK里自带模拟器，太卡。 这里介绍两款我正在用于做自动化测试的模拟器：Genymotion 与 夜神模拟器。
Appium 是一个自动化测试开源工具，支持 iOS 平台和 Android 平台上的原生应用，web 应用和混合应用。 一、环境配置 1、安装Node.
Windows下Python3+nose+appium自动化测试之Android篇 [本文出自天外归云的博客园] 以下用来做自动化测试的这款app叫最爱抓娃娃，以后会改名为网易抓娃娃。 下文提到的appiumier项目里会包含用来测试的apk包以及自动化测试代码。 先说一个坑 随着Android机高度定制的大潮，有些手机是这样的，比如Vivo x9s，你在做测试调试的过程中最终会发现跳转到某些页面后driver却进不去这个页面，page_souce也没法打印，所以什么元素你都获取不到。
Appium+python自动化27-等待activity出现(android特有的wait_activity) 在启动app的时候，如果直接做下一步点击操作，经常会报错，于是我们会在启动完成的时候加sleep。 那么问题来了，这个sleep时间到底设置多少合适呢？设置长了，就浪费时间，设置短了，就会找不到元素报错了。