【原创】那些定位不到的元素
UI自动化核心部分应该就是元素定位，很多时候会因为元素ID动态变化、不可编辑不可见的状态以及复杂的控件元素等使得元素定位总是失败。
1、元素ID动态变化
正常思路就是层层向上找到不变的元素然后通过相对路径加绝对路径的方式定位元素
举例：今晚帮网络上的同学解决的网易邮箱写信按钮无法定位的问题
html代码如下：
直接获取需要定位元素的xpath为//*[@id="_mail_component_61_61"]/span[2]，_61_61为动态变化的直接使用必然会失败
向上查找非动态变化最近的一个父元素：//*[@id="dvNavTop"] 然后通过绝对路径进行拼接，拼接后的xpath为//*[@id="dvNavTop"]/ul[1]/li[2]/span[1]
使用RFW进行测试：
*** Settings *** Library Selenium2Library Library AutoItLibrary Library DatabaseLibrary *** Test Cases *** 126write open browser http://email.163.com/ FF ff_profile_dir=C:\\Users\\spook.zhang\\AppData\\Roaming\\Mozilla\\Firefox\\Profiles\\xwi2y76s.default sleep 3 click element //*[@id="tab126Link"]/div[2] sleep 3 input text //*[@id="userNameIpt"] maple42 #//*[@id="idPlaceholder"] input password //*[@id="pwdInput"] 马赛克 #//*[@id="pwdPlaceholder"] sleep 3 click element //*[@id="btnSubmit"] sleep 10 click element //*[@id="dvNavTop"]/ul[1]/li[2]/span[1] sleep 10 page should contain 主题 [Teardown] close all browsers
运行结果：
小插曲：测试过程中发现第一次定位登陆用户名与密码两个元素时报错：元素无法编辑，使用的元素定位xpath分别为//*[@id="idPlaceholder"]与//*[@id="pwdPlaceholder"]
观察真实用户操作时的页面元素变化发现网易邮箱登陆页用户名与密码两个元素使用了一种框架或控件，元素被编辑与没有被编辑时定位到的元素不同（给网易点个赞，细节决定成败···） 再填写了用户名与密码后再进行定位得到的元素为//*[@id="userNameIpt"]与//*[@id="pwdInput"]，替换再次运行成功。
2、复杂的控件但对业务测试并没有影响的元素
时间选择控件是新手在做UI自动化时比较头疼的事情，百度到的方法一般都是用JS remove掉readonly后进行sendkey的操作、若是RFW的话正常思路是select iframe然后进行click等操作···亦或是通过一些其他的方法来实现
发现的一个速度最快的方法就是选中控件元素然后模拟回车（在想明白真正的UI自动化后）
举例：
RFW的实现
press key xpath=//*[@id="main-container"]/div/div[4]/div[2]/div/div[2]/div/input \\13
只有一行： press key [locator] \\13
3、缺少必要用户操作
之所以报错不可见不可编辑是因为当前场景元素确实不可见不可操纵
上文中的网易邮箱登陆名与密码两次元素定位不同也可以归属这一类
其他常见的场景有
（1）有些元素只有当鼠标悬浮在一些依赖元素时才会可见
举例：
不可见时
添加一个鼠标悬浮的操作后
RFW实现：
添加鼠标悬浮操作
（2）当前框架大小限制导致元素不可见
举例
展示内容较多，提交按钮不可见
滚动滑轮操作后
RFW实现
多次向下滚动滑轮
（3）其他一些元素不可见不可编辑的情况···需要我们去探索缺少了哪些必要的用户操作
总结：那些我们定位不到或者定位失败的元素很多时候是因为浏览器当时状态该元素的确不可见，此时需要我们做的是模拟用户真实的操作，将缺少的操作补充后使元素可见。一些通过JS的方法来修改元素熟悉或者状态的方法现在看来应该已经偏离了UI自动化的设计理念···
PS: press key [locator] \\13 也是一种用户真实操作
