今天完成的事情：

UI自动化测试的优缺点，如何规避

明天计划的事情：
遇到的问题：暂无
收获：

UI层是用户使用产品的入口，所有功能通过这一层提供给用户，测试工作大多集中在这一层。

UI自动化测试（GUI界面层），即通过模拟手动操作用户UI界面的方式，以代码方式实现自动操作和验证的一种自动化测试手段。主要应用于冒烟测试、回归测试。

在实际应用中，UI自动化可以帮助我们节省人工测试成本，提高功能测试的测试效率。缺点也是比较明显，随着敏捷迭代的速度越来越快，UI控件的频繁变更导致控件定位不稳定，提高了用例脚本的维护成本，同时定位的不稳定导致用例的可信度降低。

优势：

提高测试执行效率，节约时间成本；

解放人力去做更重要的工作；

可重复利用，建设对人的依赖；

可大幅度减少兼容性测试的工作量；

有些测试工作必须依靠自动化实现来完成；

劣势：

开发测试脚本需要花费较大的时间成本，拉长周期;

产品的快速迭代，自动化脚本也将不断迭代，时间成本很高;

不同的项目之间自动化脚本的复用度很低;

对短期型项目产品实现自动化价值不高;

自动化无法完全代替手工测试找到bug，实现100%覆盖;

自动化更多的适用于回归测试;

自动化开发过程对软件测试团队的技术有更高的要求;

解决方法：

1.在自动化测试中，引入了Page Object Model（POM） 页面对象模式来解决。

采用PageObject设计模式是将某个页面的所有"元素（包含控件）属性"及"元素操作"封装在1个类(Class)里面，目的是为了将测试代码与被测页面对象代码分离，后期如果有页面元素发生更改，只需要修改相应页面对象的代码（即对应class文件），而不需要修改测试代码。也是为了进一步降低后续因页面变化带来的维护成本。

2.失败重试机制，提高用例稳定性

由于用例执行的稳定性直接决定用例在业务落地时的可信度，所以提高用例稳定性是必要的，框架提供了失败重试的机制来间接保证稳定性。即当监听到用例执行失败异常时，重新执行当前用例逻辑，如果执行成功，覆盖当前用例的执行结果；如果失败，重新执行，直到超过重试次数。

3.定位元素的方式 + 等待方式的优化

A.实际写脚本的时候，尽量少使用xpath绝对路径方式来定位元素

B.元素等待少用implicitly_wait 、sleep，可以多使用 WebDriverWait + expected_conditions做新的方法封装