我想说的是，想要做 UI 测试的前提，是项目的开发和测试选取框架，先做好底层的单元测试和接口测试，然后我得理解里，应用的大部分流程和功能比较稳定了，UI 测试才比较可行。 UI 测试在迭代里扮演着验证的角色，初期的版本改动过大就建立 UI 测试，成本太高了，个人愚见

这个感觉是老问题了，我个人感觉，引入自动化测试的目的在于，把枯燥的重复的手工操作进行脚本化，所以我一直认为，不要为了自动化而自动化，自动化测试引入是有前提条件的，1、版本周期不能太短 2、版本主要主流程要基本稳定。so
第一个问题：并不是每个 case 都可以把它脚本化的，主要针对一些基础用例，在版本回归测试阶段，把主流程的一些基础 case 自动化掉，大大解决了重复的手工劳动力，还有，自动化测试目的并不是在于发现更多的 bug，而是为了产品质量的保证，其实更多的 bug 还是需要手工测试去发现的。
第二个问题：在版本快速迭代的过程中，它又扮演一种什么角色？充当版本质量的守门神，不是为了发现更多 bug，而是为了保证版本没有问题。
第三个问题：同二
第四个问题：我感觉没有意义，因为功能自动化测试和性能测试关注点不同，自动化主要校验功能性是否完整，而性能更多的是关注这个系统在多并发情况下，能否出现问题、响应时间，更多的是检验这个系统架构缺陷所在以及性能优化点

UI 自动化投入产出比不是太高。之所以大部分人喜欢用是因为它可以直观地看到执行过程。
从你的描述来看，你的问题在于软件更新太快（特指 UI 层面），导致维护成本高。

对于这种问题，建议你找个可以录制的 UI 测试框架（如 MonkeyTalk）来做半自动化（不是全自动化，要有人在那里看着的，因为录制的结果大多不带有校验，不过你录脚本的时候其实也把测试用例执行完了。。。），达到尽量降低自己的劳动量的目的。

纯 UI 自动化其实和单元测试差不多，只是 UI 自动化只关注 UI，单元测试关注功能实现。目的都是保证版本没被改坏。自动化最大的意义就是以最快速度验证功能的正确性，并以最低成本定位问题代码，就如软件工程里所说，一个 bug 在刚出现的时候被发现的话，修复成本最低，越到后面修复成本越高。

举个例子：
开发提交了代码，然后 CI 上跑一下测试用例，发现这个版本的一些基本功能被改坏了，开发赶紧再去 review 一下刚提交的代码哪里有问题，赶紧 fix。否则一个包含了数十个提交的版本在手工测试的时候发现 bug，然后开发还得从几十个提交中慢慢找是哪次变更导致这个问题出现。

#1 楼 @davidyang 业务发展飞快，很多流程推倒了一遍又一遍。基本流程和功能暂时都没看到稳定的迹象，但是自动化又不能等很久以后才开始去做，所以我选了一个相对稳定的线上版本做的自动化。但是感觉孤零零一个在弄- -！

#2 楼 @cpfeng0124 我觉得这句话 “自动化测试目的并不是在于发现更多的 bug，而是为了产品质量的保证，其实更多的 bug 还是需要手工测试去发现的。” 说的挺好，之前一个面试问我自动化到现在发现了几个 BUG?我都不知道该怎么回答- -

#3 楼 @chenhengjie123 可以录制的 UI 测试框架，听起来是不错。不过我现在的情况是领导基本很少给我需求去写用例和去测试，基本上我现在主要的工作就是把整个自动化整起来，包括代码框架，我现在是针对线上之前的一个版本写的，写了一半，新的应用更新了很多有一些我都不太清楚了。一个人在那写 UI 自动化代码，学习 Android 开发基础知识。对于我这种现状不知道还有什么好的建议给我一个方向什么的？

#6 楼 @azdbaaaaaa 如果领导指明要求搞自动化，我觉得你可以和领导私下交流一下，搞清楚领导搞自动化的真正目的是什么，然后对症下药。有些领导搞自动化是为了业绩，那你可以搞一个简单的自动化平台给他（推荐搞个比较成熟且领导容易体验的，能够快速录制来更新，例如 MonkeyTalk），能够以最快速度搞出一个看起来很牛的用例。如果真的是为了软件质量，那得先看看哪里稳定了（除了 UI，还有接口、单元测试等可以做自动化的），然后对稳定的模块做自动化。

自动化是为了减少重复劳动。没有重复劳动搞自动化没啥意义。自动化如果经常要维护，那你想通过自动化降低手工成本其实不可能（一个用例跑一次就得改一次，改完还得调整，还不如直接手工），至于维护质量就更加无从谈起了（自动化用例的质量都保证不了，怎么保证软件质量）。

其实自动化不一定是测试的自动化的。你能把打包、部署这些搞到全自动化（其实就是一键完成）其实帮助也很大的。因为这些基本都是重复劳动。

1.UI 自动化在整个项目中的意义何在？它到底要达到一种什么目的？（之前听 monkey 说的，UI 自动化是不能减少人力的）

这个吧。。嗯。。移动互联网中至少我是这样认为的。UI 自动化本身的意义怎么定义也看项目本身的。有的 UI 自动化是做回归的，有的 UI 自动化就是做替代了一部分核心基础的功能测试，这个说不好。但是最终减少人力的例子很少，非常之少。

2.在版本快速迭代的过程中，它又扮演一种什么角色？

快速的话，其实我觉得能做的就是所谓的老版本的回归，在本次的迭代中几乎很难去做什么。虽然很多人不认同，但是实际项目的确就是如此

3.各位在真实的项目中通过 UI 自动化能找出多少有意义的 BUG？

UI 自动化找到有意义的 bug 还是有的。但是看阶段。我的观点还是 UI 自动化其实在一些 smoke test 或者 regression test 中还是有一定的作用的

4.是否需要把性能的 case 和 UI 自动化结合在一起，才能使整个自动化变得有意义？

嗯，好问题。这个还是有意义的。但这个性能不是服务器的性能，而是 device app 本地的性能，这些是需要和自动化功能测试结合的，而且必须结合。但也不是所有的性能测试都需要自动化，需要有区别的去定义和设计。

#8 楼 @monkey 总结一下，UI 自动化主要还是的用处在于【冒烟测试/回归测试】，快速迭代情况下多用于老版本的回归，同时需要结合一些 app 本地的性能参数。至于你说的有意义的 BUG，能给我举个例子吗？谢谢

#9 楼 @azdbaaaaaa 嗯。比如说，我在项目中使用 BDD 的模式，对于每个新的应用都会做 smoke test。那么发现的应用的 crash 以及与 ux 稿不同的时候，case failed，那么就是有意义的：）

#7 楼 @chenhengjie123 快速录制（MonkeyTalk），在快速迭代过程中实现半自动化，节约劳动力；至于接口、单元测试，我在项目过程中测试了一些简单的接口，就是给我一个接口地址，然后我结合业务输入一些字段值，查看返回报文，过程中争取覆盖所有的返回码这一种，单元测试我还没接触过。我觉得对这两方面的测试都不是很了解，所以自动化的话还是不知道要如何着手，（但是不容置疑这 2 种测试都是非常重要的）。谢谢你的回答

#10 楼 @monkey 大概了解了，不过我们没在用 BDD 模式，百度了一下：）

据了解，目前已经越来越多的手游 CP 开始重视起游戏测试来了，2014 年整个手游市场达到了 274 亿，而因游戏兼容性问题造成的损失大约达到了 72 亿，CP 们意识到在现阶段手游产业人口红利消失的局面下，挽回这 72 亿可能是 2015 年的重要增长点。这也带动了整个行业越来越规范化的游戏测试标准出台，精品游戏开始逐渐被引起重视对于行业来说终究是好事儿。

自动化能不能发现 bug，要看自动化脚本对功能的覆盖度，覆盖到了，如果这里有问题，自动化脚本就能把这个问题暴露出来。

#14 楼 @huangyaoshiauto 哦哦，半个月前的帖子你都能找到