1、元素属性的细微变化导致定位语句失效
比如，“登录”按钮的 ID 从“Button_Login_001”变成了“Button_Login_888”，那么如果 GUI 自动化测试脚本还是按照原来的“Button_Login_001”来定位“登录”按钮，就会因为 ID 值的变化，定位不到它了，自动化测试用例自然就会失败。
建议优先使用 xpath轴定位或者xpath contains模糊定位，这样就算 id、clases、name 等控件属性改变，只有不是页面改版，应该不会影响自动化稳定性
2、随机的页面延迟造成控件定位失败
一个屡试不爽的办法就是，加入重试（retry）机制。重试机制是指，当某一步 GUI 操作失败时，框架会自动发起重试，重试可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的。
3、浏览器版本升级
禁用浏览器自动升级
4、页面异常属性
- disable
- readonly
使用模拟操作消除异常属性，或者使用js代码移除异常属性
5、页面元素在iframe中（新手坑）
操作iframe里边的元素，要切入iframe。操作iframe外的元素，要切出iframe
6、非预计弹框
- GUI 自动化测试用例执行过程中，操作系统弹出的非预计对话框， 有可能会干扰 GUI 测试的自动化执行。
比如，GUI 测试运行到一半，操作系统突然弹出杀毒软件更新请求、病毒告警信息、系统更新请求等对话框。这种对话框的弹出往往是难以预计的，但是一旦发生就有可能造成 GUI 自动化测试的不稳定。
解决方案：使用无头浏览器来运行用例
- 被测软件本身也有可能在非预期的时间弹出预期的对话框， GUI 自动化测试有可能会因此而失败。
比如，被测软件是一个电子商务网站，你在网站上进行操作时，很可能会随机弹出“用户调查”对话框。虽然这种对话框是可知的，但是具体会在哪一步弹出却是不可预期的。而这，往往会造成 GUI 自动化测试的不稳定。
解决方案：
当自动化脚本发现控件无法正常定位，或者无法操作时，GUI 自动化框架自动进入“异常场景恢复模式”。
在“异常场景恢复模式”下，GUI 自动化框架依次检查各种可能出现的对话框，一旦确认了对话框的类型，立即执行预定义的操作（比如，单击“确定”按钮，关闭这个对话框），接着重试刚才失败的步骤。
7、测试数据问题
测试数据问题，也是造成 GUI 自动化测试不稳定的一个重要原因。
比如，测试用例所依赖的数据被其他用例修改了；再比如，测试过程中发生错误后自动进行了重试操作，但是数据状态已经在第一次执行中被修改了。
解决方案：
On-the-fly 方法又称为实时创建方法，指的是在测试用例的代码中实时创建测试用例所要使用到的测试数据，具有数据可靠性高的优点，但是会比较耗时。
而 Out-of-box 方法又称为开箱即用方法，指的是在准备测试环境时就事先准备好测试需要用到的全部数据。这样可以有效缩短测试用例的执行时间，但是存在“脏”数据的问题。
在实际的测试项目中，我们可以根据测试数据的特性，把它们分为两大类，用业内的行话来讲就是“死水数据”和“活水数据”。
“死水数据”是指那些相对稳定，不会在使用过程中改变状态，并且可以被多次使用的数据。比如，商品分类、商品品牌、场馆信息等。这类数据就非常适合采用 Out-of-box 方式来创建。
这里需要特别说明的是，哪些数据属于“死水数据”并不是绝对的，由测试目的决定。
比如，用户数据在大多数的非用户相关的测试用例中基本属于“死水数据”，因为绝大多数的业务测试都会包含用户登录的操作，而且并不会去修改用户本身的数据属性，所以这时我们就可以将用户数据按照“死水数据”处理，也就是采用 Out-of-box 的方式创建。
但是，对于那些专门测试用户账号的测试用例来讲，往往会涉及到用户撤销、激活、修改密码等操作，那么此时的用户数据就不再是“死水数据”了，而应该按照“活水数据”处理。
“活水数据”是指那些只能被一次性使用，或者经常会被修改的测试数据。最典型的数据是优惠券、商品本身、订单等类似的数据。这类数据通常在被一次性使用后状态就发生了变化，不能反复使用。那么这类测试数据，就更适合采用 On-the-fly 自维护的方式。
同时，由于有 Out-of-box 数据的支持，这类数据往往不需要从最源头开始创建，而是可以基于已有的 Out-of-box 数据生成。
比如，在使用 On-the-fly 方式创建订单数据时，你可以直接使用 Out-of-box 的用户数据来作为买家数据。
由此可见，综合运用这两类方法，可以以互补的方式解决测试数据准备的很多痛点，比如测试数据准备比较耗时、测试数据存在“脏”数据的可能，以及测试环境不稳定造成的测试数据无法创建等问题。
8、代码复用性差，维护成本高(传统的流水账式写法)
使用po设计模式，对页面进行分层封装和设计。
