在网上看到一个朋友为了这个问题很使劲很着急，其实个人觉得这个问题还是有很多坑的，一不小心把自己带进去了，还顺便把自己给埋了，搞不好这个表面看起来是个技术问题可能慢慢的恶化成软技能问题甚至管理问题！
　　浅谈个人拙见：
　　高效嘛，当然可以从代码中做一部分改变，去掉不需要的等待时间，但是有些地方还是需要等待的，如果加载过快，有些target还没出现直接跳过了那是给自己找事了，还有真的不是你想快能快，还要看看你测试的应用程序，你的网速，如果本身慢得一米，你是神一样的操作也白搭，总之测试代码的执行不是要人一直看着的，如果一直盯着，那也许要想想当初引入自动化测试的初衷了。。。
　　靠谱嘛，这要看个人能力了，够不够smart。。。
　　1. 自动化测试用例是怎么筛选出来的？是否典型？是否值得自动化？复杂的逻辑是否可拆？coding成本大不大，是否易于实现？
　　2. locate 元素的时候能否准确找准必要的属性？而且这个属性不轻易变化！
　　3. 自己加检查点是否根据实际情况？是否写得够聪明？
　　4. 代码架构是否好？别人能看懂吗？别人能维护么？是不是还在写好多hard code呢？
　　5. 有没有自己的idea，遇到挑战是不是能很快的克服，如果瞎扯淡，自己把自己往坑里带，那埋得是自己。
　　6. 是否可以做成框架？哪怕只是浅浅的封装也可以试试
　　可容错嘛，我想每个人都喜欢，毕竟代码是死的，你不告诉它怎么做，它什么都不错，不像人如果测试时遇到一些异常会尝试一些其他的操作，在测试中加入一些场景恢复是很有必要的，这样可以充分的发挥无人值守的特点。
　　举个例子，比如我们必须登录才能有下步操作，如果登录时因为测试数据的问题导致很多测试用例不能执行，这时肯定特委屈，那我们是不是能在登录出错时做一些其他操作呢？根据不同的出错信息加上不同的恢复场景呢？
　　如果用户不存在或者错误，我们是否可以在登录失败时转而直接去注册呢？完成注册后我们不是一样可以继续操作么？（或者在开始时去数据库检查用户是否存在，不存在直接去注册）
　　如果提示密码不对，是否可以尝试直接重置密码呢？（直接连接数据库操作更新你的密码）然后再尝试登录
　　如果页面直接down 了，当某一特性出现时是否可以直接退出呢，然后执行特殊脚本重启服务呢？
　　后想说，自动化测试也只是“一副药”也不是包治百病，是药也三分毒，大多数时候别那么使劲，别那么执着。放自动化一马，也放自己一马。人生是一种折腾，别折得自己浑身疼！