首先呢，我狠喜欢这个帖子，上下文写的很清楚。
但是我想问的是作者怎么得出 “实践的人很少，甚至有抵触这个结论的？“

另外没有说 UI 自动化占主导，只不过大家平时看到比较多的是 UI 自动化，不代表占主导

#1 楼 @monkey 面试的时候，还有周围的人。。。

#3 楼 @quqing 这不代表全部。。。。我表示我要燃烧小宇宙了。。。。

#4 楼 @monkey 谢谢，能早点遇到伯乐就好了

一个一个回答吧。

为什么现在占主导的还是 UI 自动化

首先，这个只不过是大部分人看到的。我为什么一直强调的是大家要提升自己，不要老水 QQ 群，不要老混自己的圈子就是这个道理。测试大部分圈子是一个鱼龙混杂的圈子，有的人真的认真的在做 UI 自动化，有的人什么都不懂就只会扯皮 UI 自动化。那么久而久之就会有作者这样迷茫的人，或者造成假象，就是 UI 自动化好像占据主导。

如果你们愿意去上一个 level 去接触另外一个圈子，去站在更高的高度看问题，那么你们就会觉得其实不是这样的。UI 占主导的原因无非就是：

• UI 自动化说的人最多，入门最简单，扯淡或者不扯淡的人都在扯，自然大部分人就觉得 UI 占主导，甚至很多测试觉得自动化就是 UI 自动化
• 大部分公司的测试为了有 KPI，那么只能从 UI 自动化入手，原因见第一条
• UI 自动化是最直观的，往往很多公司的老板也只能看得懂这一层的东西
• 圈子限制了个人的视野，原因见第一条

结论就是并非 UI 占了主导，只不过你所在的圈子让你觉得占了主导

分层测试效果好，为什么实践的人少，甚至有抵触呢

就如我上面回复的，我不明白怎么得出这样的结论的，但是我猜测了一下

• 大部分人不在实践多的圈子里，或者没有接触到
• low level 的圈子很多人不知道怎么做，自然不愿意做，自然就会用各种理由去不做，可能让人觉得抵触
• 循环见第一条

是否有更好的解决方案呢

分层已经是最好的解决方案了，但分层也好，工具也罢都是死的，主要看面对怎么样的产品，怎么去分析，怎么去落地。就好比大家都用 Appium，大家都用 OCUnit，为什么有的人效果很好，有的人用的效果很差，或者用不来，这就是差距。

总而言之，如果想看看别的圈子的，下次我什么时候出去，谁自己出资承担自己的差旅跟着我出去一次就明白平时你们看到的测试圈子太 low

最后感谢楼主写了那么一个好帖，以后这种描述清晰的帖子要多多益善

#6 楼 @monkey 非常感谢这么详细的解答，去心中之惑

#6 楼 @monkey 求带⊙▽⊙！

—— 来自 TesterHome 官方 安卓客户端

就拿阿里巴巴和支付宝来说好了。

阿里内部的 api level 的测试可谓是非常全面的，支付宝后台的资金相关的服务器链路从前期的 mock 到后期的压测简直说是面面俱到的。支付宝甚至在接口测试这个 level 定了质量红线的死线，在 UI 自动化上从来不会有这样的事情，无论是 selenium 时代还是 appium 时代都一样。

而且其实一个优秀的测试活动远远比不上一个优秀的产品的架构设计，质量不是靠测试出来的。模块的划分，风险的把控都是可以很完善体现在产品的架构上。

做过测试开发的都知道分层其实是目前比较好的解决方案；

YY 下：

• 更好的解决方案应该是人工智能；

为什么一些公司不愿意实施

• 单测：
  • 大部分公司没有强制要求去做；
  • 开发自己的需求都得加班加点，理所当然排斥；
  • 大部分开发基本没从事过类似工作，也不知道该怎么做；（主要还是责任心）
• UI 自动化本身：
  • 入门简单；
  • 执行过程与结果脱离代码层容易理解，与其它层数据结果形成对比；
  • 模拟操作毕竟对于上层比较新奇，且能看到具体的执行过程；
• 老大的方向问题：
  • 认为所有的验证能都应该在 UI 自动化中完成，包含数据验证，殊不知 UI 其实是路径最多的，逻辑最复杂的，条件最苛刻的；
  • 保留着黑盒测试的思路：认为测试应该非侵入式的去做；
  • 急功近利，不愿意使用线上开发平台，而更愿意投入人力自己造轮子，便于出绩效；

#8 楼 @xubin98246 好呀好呀。今天飞北京，估计你来不及了。下次你和我一起呗。培训啥的都免费

#9 楼 @monkey 小白求带旁听，见见世面

看这个帖子，测试的主要作用和必要体现在哪？，有没有觉得 UI 层不是主流？
如果你的自动化测试的服务对象是客户、产品、运营之类的非技术伙伴，UI 层容易被他们理解。
如果测试的服务对象是开发、运维之类的技术伙伴，UI 层很可能被认为慢、不容易定位问题、维护成本高等等

#9 楼 @monkey 怪不得阿狸撤了那么多功能测试，看来测试的技能必需在开发、架构之上啊，以测试主导开发的时代慢慢接近了 ^{—^}

#11 楼 @monkey 上海可有培训，求带

#14 楼 @kinget007 额。。撤不撤和咱这个主题没有直接的因果关系。。。这个不在这儿讨论哈

#15 楼 @quqing 上海直接出来见面就好啦。。。不用带啦。＝ ＝

#17 楼 @monkey 找不到 p2p 的联系方式，我的微信：quq0930

之前看过阿里一篇关于分层测试的文章

这篇文章是网上的吗？能否贴下链接？

#19 楼 @chenhengjie123 http://wenku.baidu.com/link?url=GggGkaSIqt2_NBBCwQ7BgirMNjuNdnOLFbA9_NSFdWqFbPJCesVFxUPFz4IKrMLHKX80zSc0K2SQJhWHpSXnTX3PqB6iLjSyxK0n7zGjVh_

#11 楼 @monkey 好啊，最好是杭州的^{。^}

楼主上面的说的那 2 个，也可以支持非 UI 层 应用层的。没有经过单元测试走自动化，可测试性就不发表评价了。
关于单元测试 其实怎么说呢，插桩这个基本每个开发都会去做，看你如何定义单元测试，桌面飞检和动态检查这种很多互联网公司是没的，游戏公司我更没见到过。其他的，譬如盛大过去有代码互相备份和静态的，现在应该也是没有了。

分层测试 是必须的，自动化也不一定要把分层的全集成起来，当然最好是这样。反正我个人在游戏行业是从来没有集成过，因为没足够资源，分层到时实现过。

#18 楼 @quqing 可以分享下你的分层测试框架吗？

#21 楼 @xubin98246 我也是杭州的，同求大神

请问作者，你讲到的这几个层级，UI 层 Web 层 Data 层 接口层 业务层，都是在一个框架里面实现？

#26 楼 @momoyue UI 层 Web 层 Data 层在一个框架实现，原理是 httpclient 模拟发请求，截取未渲染前的响应内容（作为 web 层校验），同时由爬虫类获取 css、js、图片等静态资源到本地（可作为 UI 层校验），一般都是有登录态的请求流模拟业务流操作（此时数据库会产生数据，可同时进行 Data 层校验）。当然，我设计时考虑到了既支持耦合执行，也支持分层解耦（每一层可有独立脚本），业务层是白盒测试范畴，一般 Junit 结合 Mock 工具执行，其实我觉得白盒并不是最难，最难的还是 UI 层的最佳实践

#24 楼 @xiaoluosun 目前框架 UI 层设计并不完美，等成熟些再分享

#27 楼 @quqing 解析 UI 的内容, 你最好用 phantomjs 这类的带 js 解析器的工具.

#29 楼 @seveniruby 我现在的卡点不在 web 层内容的解析，而是 UI 层展现的测试，假设预期结果是一个图片基线库，考虑的因素包括：执行机的分辨率、屏幕大小、色彩和亮度、兼容性（各种类型的浏览器），如何解决这些不确定因素？
另，PhantomJS 很好，CasperJS 也不错，依赖于 PhantomJS，同样支持无浏览器的 Web 测试，但截图功能更强大

自动化测试能深入到什么程度，取决于公司的管理层和 cost。大公司注重这块，就可以招人来深入自动化，从单元测试开始，QA 会针对每个 function 进行测试，与此同时还开发的有相应的测试平台，针对测试管理分析监控，确保代码覆盖率和相应的性能。集成测试层面，开发辅助做一些接口 QA 针对接口设计自动化测试，而这些接口是为了测试不同模块功能是否正常，稳定，经过优化，也会有测试平台对不同时期的测试进行管理，追踪，数据分析。然后就是系统测试和 UAT 层面，初步进入 UI 自动化使用相关 UI 自动化测试工具进行测试。也会使用测试平台并结合手工测试完成。针对 UI 测试的一些常见问题进行有针对性的解决：业务变化频繁的可以交给手工；不稳定尝试重构自动化框架和添加被测产品的性能监测功能相结合，确保被测系统稳定后介入自动化，并能实现 retry 机制。

综上所述，我理解的分层测试是真的开发模型的分层，不同时期做不同的事。当然，也可以理解为测试框架的分层。

#27 楼 @quqing

请教，用爬虫单独抓去，css，js，图片，怎样做校验？
图片验证文件名？
css 和 js 呢？ 请教！

#32 楼 @recluse6860 类似于浏览器把网页下载到本地，如要正常打开，这些资源文件是必不可少的，然后就可以用图片对比工具进行校验。当然，个人觉得这并不是最佳方案，还在考虑怎么做更好

在分层测试体系中，对于 API 这层的代码稳定性，特别是对于一些没有 UI 层的 Android SDK 项目（如业界的友盟统计 SDK，TalkingData SDK），我们可以利用 JUNIT 框架直接在 API 层做测试，但是接口的稳定性我们一般采用什么样的测试策略去保证呢？

@monkey 求带见世面 嘿嘿

为了模拟用户的操作，一切测试都要追溯到用户需求

#36 楼 @actionwind 模拟用户操作是测试的一种手段，达到测试的目的有很多手段，至于哪种手段效果好，还是用数据说话。这就涉及到了测试数据入库的原因之一，以便于做数据挖掘和分析，为以后的持续改进提供依据

#11 楼 @monkey 我也要和你出去看世界

#38 楼 @book 加我微信，一起走走走，monkey15chen

#39 楼 @monkey 我已经加你很久了，我叫不迷糊，你还给我点过赞，我也给你点过赞~~~~~

@monkey 在上海的一定要带上我！！monkey 大神求带见见世面~

#41 楼 @verainmay 在上海的少。。＝ ＝。不过都 ok

#42 楼 @monkey 大神只要带上我，哪里都无所谓~

#43 楼 @verainmay 好的。明年走起的时候你关注我微信信息

#37 楼 @quqing 还有就是考虑到易用性的问题，因为很多测试人员的编程能力相对比较差，所以方便易用的测试工具更加受欢迎。如果要涉及比较深的编程知识的话，还不如去做开发呢。

#42 楼 @monkey 求见世面。。。

#45 楼 @actionwind 就目前来说，你说的没错。就我个人接触到的，缺少这么一类慢工出细活的，或者做基础研究的人。就好比中国可以设计先进发动机，但基础材料不过关，基础才是一切的根本。很多知名的开源框架或技术概念都是国外的，不是老外比我们聪明，还是和大环境有关。
个人觉得往后公司对测试的要求只会越来越高，居安思危，最近就在恶补 Java 的基础：设计模式、内部类、如何变通实现多继承、泛型的使用、抽象类和接口的合理使用、考虑时间成本和空间成本的算法、内存管理和垃圾回收等等。
说到这我不得不引申一下：

1. 测试需要比较深的编程知识，这是精确定位问题的一项重要技能；
2. 开源的工具确实好，但不要成为思维方式的紧箍咒，可以借鉴和启发，尽信书不如无书； 3.新的技术层出不穷，大多数人都不是天才，根本来不及学，不要盲目追求时尚，学会独立思考，学会取舍，能解决问题就好；
3. 做技术要实事求是的态度，千万不要装，特别是代表公司面人的时候，不要放过一个人才，也不要被忽悠招入庸才。

#47 楼 @quqing 赞同~

@monkey 上次你来微影没赶上，下次来喝酒~

看大牛吹牛真带劲，冒个泡。

monkey 说的好呀，虽然我是小菜鸟，但是我想学习

其实就是一句话。兵熊熊一个，将熊熊一窝。取决于有拍板权的人的思维高度。

#6 楼 @monkey 自费差旅，愿随行

#20 楼 @quqing 不错，但是 UI 和 Web 是啥区别？

#54 楼 @jiangboyang222 😄

#55 楼 @jiangboyang222 当初设计这个框架还未涉足 app 测试，主要基于 web 测试做的，所以分开说吧。
先说基于 b/s 的 web 的测试，页面是从服务端获取的，UI（展现给用户的页面）都是通过浏览器发送请求>>获取的 response（页面结构）>>加载渲染后呈现给用户。所以在此基础上还可以把广义的 UI 再细分成渲染后展现给用户的纯 UI 和未渲染前的页面结构，后者的就是我所说的 web 层。
然后再说 app 测试，其类似于 c/s 架构，界面是在客户端生成的，所以渲染后界面和渲染前的层次结构都只能从客户端获取，所以我认为 app 的 UI 层无法细分。虽然从层次结构下手非常类似于前面所说的 web 层，但从我掌握的知识面（本人知识面有限）还需依赖于 appium 等基于 e2e 的框架实现界面之间的跳转才能获取该界面的层次结构。

#57 楼 @quqing 我也在困惑这点，先入手的 app 自动化测试，都是基于 UI 搞，感觉接口自动化测试只适合于服务器和无 UI 的 SDK 之类的

#6 楼 @monkey 你啥时候出去啊，我自费跟你去转一圈

就那百度，接口自动化测试为例哈，从写用例就有自动生成用例的工具，有调试工具，有管理用例与持续集成管理工具，发现问题后有报警与日志分析。全方位的解决问题。所以想做好一个简单的接口测试 不光光是你把 httpclient 这层写好了就完事了，需要相应配套的工具。

#60 楼 @zhangxiaoxin
全方位的解决方案属于应用层范畴；基于 httpclient 的通用化封装，属于插件服务；两个是不同维度的产物。
打个比方，一个是汽车，一个是汽车部件，而汽车部件适用于所有汽车。

#61 楼 @quqing 维度是不一样，所以才要跳出这个维度去解决问题呀

#11 楼 @monkey 小白求旁听 见见世面