自动化测试框架有分为数据驱动、业务逻辑、测试分数据分离（分层），但大部分人还是趋向于基于UI的解决方案：
§ 运行不稳定：session超时、元素找不到、易受外部因素干扰等，容易造成误报；
§ 维护成本高，特别是界面频繁变动，需求迭代快导致自动化得不偿失，可借鉴投入产出比公式，满足收回成本的条件：（手工运行时间 -自动化运行时间）*执行次数 > 开发脚本的时间；
§ 脚本的运行效率低；
§ 定位问题粒度大，只停留于表象。
§ UI层：效费比最低，按优先级和重要程度，把主流程覆盖即可，数据隔离，无需校验，解决方案有图像对比技术等，例如：sikuli
§ Web层：截取未渲染前的响应内容，对其内容设置检查点校验，解决方案有httpclient向Controller发送模拟请求，截取response
§ Data层：可单独调用存储过程、package进行校验，也可耦合Web层模拟操作后进行校验；
§ 接口层：可参考Web层的方案，也可用市场上的开源工具；
§ 当然，还有业务层，该层属于白盒测试范畴。
优点在哪里呢
§ UI层以目前的技术无法脱离人工测试介入，其他层是完全能自动化的；
§ 越是底层，覆盖率越高，测试效费比越高；
§ 越是底层，执行效率越高；
§ 定位问题的粒度更细。
UI占主导的原因无非就是：
§ UI自动化说的人最多，入门最简单，扯淡或者不扯淡的人都在扯，自然大部分人就觉得UI占主导，甚至很多测试觉得自动化就是UI自动化
§ 大部分公司的测试为了有KPI，那么只能从UI自动化入手，原因见第一条
§ UI自动化是最直观的，往往很多公司的老板也只能看得懂这一层的东西
§ 圈子限制了个人的视野，原因见第一条
结论就是并非UI占了主导，只不过你所在的圈子让你觉得占了主导
§ 单测：
o 大部分公司没有强制要求去做；
o 开发自己的需求都得加班加点，理所当然排斥；
o 大部分开发基本没从事过类似工作，也不知道该怎么做；（主要还是责任心）
§ UI自动化本身：
o 入门简单；
o 执行过程与结果脱离代码层容易理解，与其它层数据结果形成对比；
o 模拟操作毕竟对于上层比较新奇，且能看到具体的执行过程；
§ 方向问题：
o 认为所有的验证能都应该在UI自动化中完成，包含数据验证，殊不知UI其实是路径最多的，逻辑最复杂的，条件最苛刻的；
o 保留着黑盒测试的思路：认为测试应该非侵入式的去做；
o 急功近利，不愿意使用线上开发平台，而更愿意投入人力自己造轮子，便于出绩效。
本文出自 “史上最强SB” 博客，转载请与作者联系！
原文：http://10672221.blog.51cto.com/10662221/1895738