论Web UI自动化测试的不稳定性（一）

Web UI自动化测试的不稳定性有两个层面：

技术层面–没有构造健壮的能稳定运行的脚本

非技术层面–项目原因或者用Web UI自动化企图达到不合适的目标，造成脚本频繁改动，维护成本高

今天先说第一点。

首先，Web UI自动化测试是不稳定的，哪怕脚本写的很棒！为什么？因为Web应用本身就有不稳定的情况存在。以下这些情况想必我们都经历过：

点击网页上的按钮或者菜单没有响应（有时候第二次点击才有响应…）

网络延迟严重，页面响应慢

面对本身就不是100%稳定的Web UI，怎样构造高质量的自动化脚本？我的建议如下：

【关于控件定位】

定位条件多用组合，多留冗余，不要写死，比如：class包含form-arrow-button并且id以GroupName开头并且子节点数量大于1

如果写成id=GroupName-1024，那就很危险，下次在其他的测试用例里，先去某个也有类似控件的页面做一些事情再来这个页面找这个控件，那这个页面的控件可能就不是GroupName-1024了，可能是GroupName-1448。当然这不是绝对的，这是由前端代码和项目特质来决定的。

有时候控件也定位到了，但是操作它就是没有响应，那么，请检查下它的可见性，很可能我们定位到了一个很类似的控件上，而且这个控件当前是不可见的。一般是否可见放在了控件的style属性里。

构造脚本时考虑要全面，举个例子，下拉菜单当前只有3个元素，都是可见的，我们的测试用例选最后一个，执行起来没有问题。但是如果将来下拉菜单里的元素增加到100个，我们当前的代码能否成功选中最后一个？是不是在选中这个元素前加一行scroll to visible然后再点击比较安全？！一般自动化测试人员也是属于测试人员，那么多方面考虑应该是必备的职业素质。然而这个也急不来，工作的年限越久，踩的坑越多，自然就会越全面了。

关于脚本录制，我插播一句，那就是个笑话！大家玩玩就好了，别当真。如果Web UI自动化是基于脚本录制来构建的，那简直就是找死。页面稍稍有个变动，脚本就挂了。

【关于控件操作】

UI自动化测试就是仿照人的操作，确保系统可用。所以鼠标键盘事件还是必不可少的。

但是，这些是不稳定的，就如上面所说的，我们自己手点操作，有时候都是没反应的，更何况代码去模拟！所以在能达到测试目标的前提下，少用MouseClick, typetext之类的，用Click, SetValue来代替。

【关于测试用例构成】

我认为测试用例应该尽量短，一个动辄需要执行30分钟或者一个小时的测试用例就应该考虑优化，或者拆分。

如何优化？举个例子，这个用例主要测试在job里面加入报表：帐号登录系统 > 配置一个符合测试要求的报表 > 最后在job里面加入这个报表。如果用例执行时间很长。那么配置报表的过程就应该考虑提前做好setup，代码里用现成的即可。

做好用例的优化和拆分，能很明显提高我们用例执行的稳定性！

【关于页面加载】

不要随便在代码里面写sleep(5s), delay(5s)，这是非常不好的习惯。这次等5s行得通，下次网络不好，可能得改到10s，某一天系统状态更差，直接改20s。时间久了，测试用例里面随处都要等，执行起来很慢。

等待页面加载应该调用框架的wait until page ready/wait for ajax loading/wait for element appear/wait for element disappear. 一般的Web UI自动化框架都有这些方法的，实在没有的话，自己封装。

另外，一定要记得给测试用例设置时间限制，如果在某一步僵死，超出一定时间限制，就强制结束。根据具体情况，一般设置几十分钟应该足够了。

【关于重试机制】

正因为Web UI测试自动化的不稳定性，很多CI工具提供了重试机制。我对此抱中立态度。在某些情况下，重试可能就通过了，也可能照样失败。重试机制并不是一个非常重要的策略，所以我把它放最后。

总之，Web UI自动化测试不可能不需要人照看。重试机制大概只是早看还是晚看的区别…

这才是周末的正确打开方式 :-D