自动化用例执行效率，想到哪写到哪

说说以前的一个app自动化项目的情况吧，按照功能点来组织用例目录，查找用例很方便。

最大的缺点：执行起来超级慢，差不多3000条用例，18个仿真机，执行起来5小时。领导要求必须要把这个时间降下来。

分析原因：

1. 用例基数大

2. 用例目录的初始化设计基本没设置。

3..用例的设计不合理

第一个原因没有办法改的。 

针对第二个原因进行了非常大的改动。 把很多初始化条件相同，用例之间也不会相互影响放在一个目录下，再设置目录的初始化和清除操作。举一个最简单的例子：

－目录　
    －init.robot　　初始化，打开app启动页
    －xx用例目录1 
    －xx用例目录2
    －xx用例目录3
        －init.robot  用户已登录
        －xx用例  评论
        －xx用例  个人用户页面
    －xx用例目录4
        －init.robot  用户未登录
        －xx用例  评论
        －xx用例  个人用户页面
   
           

这样可以减少初始化的次数，提供执行的效率（app每次初始化，启动也要耗费好多时间>_<），例子虽简单，但是实际操作起来，还是有很多要权衡的。

这个也有不好的地方，比如哪天评论的功能修改了，leader要求你把涉及评论的功能先执行下（如果是接口测试，这个要求更频繁），肿么办？robot framework里有个功能--打标签，给个人用户的用例都打上某个标签，执行时指定标签就可以了。。。　

第三个问题：

1. 因为有少数元素加载得比较慢，所以隐式等待设置的很长，但是绝大多数元素很是较快的。这其实也是很浪费时间的。　

解决办法：

一是可以对那少数元素用显示等待，其他继续用隐式等待（两种等待都存在时，取其时间长的那个）

二是在定位那少数加载慢的元素前，先将隐式等待时间改大，之后再将它改回来。以前同事问我，为什么不所有的都用显示等待。 额，当然可以了， 只是你不觉得太难写了吗？

另外，我给他们培训时说最好不要用sleep，要用前面说的那两种等待方式。有人就又指着我的用例说，不是还有sleep吗？不要觉得sleep很low，二次渲染时，还是要用到sleep的。

特别是写web的自动化时常常遇到，在增加，删除，修改数据提交后，会再次发起查询请求，然后列在页面上。这时通常就需要sleep一下了，因为原来的数据也是符合你find_element的条件的，这样很有可能在数据重新渲染前，查找到原来的数据。

改好的用例一直运行得很好，突然有一天通过率下降得很厉害，看日志，很多找不到元素的错误。原来公司网络整改，整个网络变慢了>_<。怎么办？ 后来我把sleep(x)和等待的时间都做成全局变量了，网络要是敢再坏一些，那么直接设置更大一些。 

3.最直接，最有效的方法，加仿真机同时跑。。