一、现象描述
运行PC端自动化用例时，执行结果不稳定。主要表现在：单个用例执行成功，但是运行全量用例时，总有一些用例执行失败，返回各种错误信息。
二、背景说明
PC端自动化脚本原先运行正常，出现不稳定时，主要改动内容如下：
2.1 取消重运行机制，所有的用例运行一次如果错误则断言错误。
2.2 所有的UI底层方法（如：基于selenium框架的二次封装方法，页面控件封装方法等）加入异常判断。
2.3 重构基于selenium框架的二次封装方法，改为显示等待查找元素。
2.4 删除脚本内强制等待时间（time.sleep）,减少用例的执行时长。
三、问题分析
3.1 重运行机制取消，导致运行失败的用例无法再次重新运行。
3.2 从Allure报告上分析，经常是页面未加载成功，就开始执行元素的查找、操作，导致元素查找失败。
3.3 从Allure报告上分析，元素定位成功，但是操作（如：点击，输入内容）无反应
3.4 删除脚本内原有的强制等待时间，导致页面加载缓慢与自动化脚本执行不一致。
四、解决过程
方案一 ：
切换回原来的selenium底层方法进行测试，运行效果也是不稳定。
测试结果：方案失败
方案二：
采用新版（基于selenium框架进行二次封装的方法）底层框架封装方法，进行脚本运行。针对失败的用例逐一进行结果分析和脚本修改。
主要修改内容包括：
4.2.1 完善脚本。页面加载时有等待界面，则加入等待界面；同时添加对页面内某个元素是否加载成功的判断。以此双重确认页面加载成功
4.2.2 动态等待元素加载。对页面内渲染比较慢的元素，采用循环（for）获取元素，给与充分时间渲染加载
4.2.3 更换元素定位方式（XPath和CSS元素定位，优先使用CSS元素定位）
测试结果：效果有提升，但是还是不稳定
方案三：
在方案二的基础上，对selenium的查找元素方法（find_element）加入2秒的强制等待时间，进行测试。
测试结果：整体稳定性提高，但是运行下来总有1-2个用例存在错误
方案四：
4.4.1 基于方案三的执行结果进行错误分析归类，基本是由查找元素引起的问题。
4.4.2 查看（查找元素）封装的方法，与之前方法比对，新方法主要采用了显示等待方式去查找元素（使用webDriverwait）。
基于此，对webDriverwait的底层方法进行调试，理解执行逻辑：当前时间加上等待时间，在这个时间内默认每隔0.5秒进行元素查找，如果未找到则返回超时。
4.4.3 基于方案二和方案三的结果，以及对webDriverwait的执行逻辑，与同事进行讨论：
猜测默认等待间隔是0.5秒，可能页面还没有加载完，但是后台在不停的查找元素，导致没有足够的时间去等待页面加载。所以尝试将间隔时间调整为2秒。
测试结果：用例整体稳定，成功。
五、结论
采用方案四问题解决
六、经验总结
技术经验（硬技能）：
6.1.1 编写UI脚本时，凡是页面可见的等待界面在脚本中都要实现
6.1.2 页面的等待界面消失，元素（页面控件）进行数据绑定的过程中，会有不到1秒的渲染（间隔）时间，
所以建议加一个页面判断：动态判断页面内某个元素的值是否加载成功，在开始业务操作，增加脚本的健壮性。
6.1.3 尽量用例实现过程中，不要写time.sleep()。
原因是：如果页面加载快，强制等待时间就显得过长；如果页面加载缓慢，强制等待时间又不足以支撑页面成功渲染。
建议采用动态判断，既有足够的时间渲染页面又不会空等太长时间。减少后期优化成本。
6.1.4 在新打开的页面上，建议都加页面断言：判断是否正确进入到该页面
如果未进入到期望页面直接断言失败；
从另一个角度，新打开页面直接进行元素操作（点击，输入，下拉框选择）时，容易操作失败。
工作经验(（软技能）：
6.2.1 先分析问题，将原因进行归类，对症下药。
6.2.2 大部分UI的问题都是页面加载慢，执行脚本快导致的问题。
6.2.3 尝试几种方案之后，效果不明显，可以将尝试的方案以及效果整理一下然后小组讨论，其他人的其他角度帮助很大。
