在我实施移动应用自动化测试的过程当中，我思考最多的倒不是技术实现上面的问题，而是：
- 面对迭代周期短的应用，自动化的开发维护成本实在太高，那是否有必要做自动化？
- UI 的自动化的产出是很少的，发现不了什么问题，是否有必要自动化？ 我始终在思考 UI 自动化的意义，UI 自动化产生的价值有多少？ 我目前的想法是前端 UI 和功能的测试全部手工执行，接口的测试实行自动化 对于上面的 2 个问题，期望移动应用测试大神来释疑，谢谢！
增加 ut 环节，其次稳定模块可以加入 ui
分层自动化
把接口测试做好, 这个可以很好的保证后端质量. 而且最不易变. 自动化价值高
UT 单测交给研发. 监督他们搞好. 保证一定的覆盖率,
UI 测试小部分业务要自动化, 保证质量还是有用的, 大部分是易变的, 手工测试即可. 我不看好 UI 自动化
充分利用云服务
兼容性测试 (Testin MTC)
众测服务 (花钱也不多, 值得尝试, 发众测任务, 比如把游戏打通 N 关, 注册 N 个帐号之类的, 发动少量群众可以发现更多问题)
安全测试 (类似乌云. 可能稍贵. 测试行业暂时还没有这种服务)
性能测试 (云服务目前还不太好用, 还得靠自己)
降低自动化的维护成本
比如录制回放技术, 不过这个录制回放工具的好坏很大程度决定了效率和成本
和研发约定规则 自动生成自动化测试用例
改善自动化的架构, 比如使用关键词驱动框架来维护. 这样贴近业务. 而且业务是基本不变的
成本太大的话不走自动化也是一条路.
#3 楼 @seveniruby 释然，顿时就有了执行步骤了，非常感谢！
很多时候我们想了很多我们自动化的意义。有多少含金量。 领导说： 这个是项目指标， 需要一份数据。需要的只是一个报告数据。 这也是自动化的作用。。 自动化对于主要功能的回归质量保证还是很有用处的。保证基本功能，快速的发现主要功能存在的问题。
成本太大的话不走自动化也是一条路
大家想法都是一样的，不赚钱的买卖都是没有必要的～ *
说说我们的经历吧。
三年前
背景：一个传统软件做 UI 层面的自动化测试
没有 CI，手工打包，没有 UT，jquery4 个版本混用....
开始做自动化测试，前先花了三个月左右（中间还有其他事情）的时间，使用 jenkins＋ant 实现自动打包，不能算 CI
然后一个月左右开始给大领导和其他利益相关群体做 “洗脑” 工作。半个月之后，得到结果开始执行，但是必须要有可量化的指标:
- 自动化测试覆盖率＝ 自动化测试覆盖的手工测试用例／手工测试用例总数 这其中有很大的问题，之前的用例根本就不是良好的用例。没有上下文，没有数据，
- 自动化测试的价值＝自动化测试执行的时间／自动化测试代替手工测试的时间 这个还算客观，但是它依赖前一个指标
好了开始做了，
第一个问题：没有环境
怎么办？折腾以前淘汰的机器定制环境（先是 xp，后来统一升级到 win7）
第二个问题：环境不能自动部署
工程是跟 tomcat 耦合在一起的；而且 linux 部署还不成功！！
折腾 autoit，实现 windows 上的自动更新，自动部署（后台跟 webqq 做关联，qq 上发个消息就能自动部署了，还能查询状态和系统信息）
第三个问题：没有测试用例，也没有可使用的数据，这是一个大坑
又话费了接近三个月的时间，才梳理出来一个关键模块的测试用例（基于 BDD 的）跟它的数据。中间还返工了一次，因为版本更新，用例重构了。
然后陆陆续续花费了接近两个月的时间才准备好了相关数据。制定了以后数据准备的方案
第四个问题：人员能力差
这个问题从开始就很明显！没办法，招人，一边独自做，一边招人，来来回回折腾了 5 个人，最后一个人稳定了两年多。中间做了不下十次培训，文档写了至少三遍
第五个问题：版本也在更新，前台重构，对应的底层控件经常出妖怪问题
这些问题，有产品自身的可测性问题；也有 webdriver 的妖怪问题。
导致我们架构重构了两次，并分别做了针对不同版本的适配（主要是前台控件的操作适配）
简单来说是这些，还有很多与其他利益相关体的扯皮的因素（你懂得，有人的地方就有江湖）。这样一晃接近两年的过去了。
最终我们达到一个什么效果，不到 20% 的覆盖率，但是效果很明显。最先实现的那个模块（功能逻辑相对固定），从两年前开始到现在都是 bug 最少的！
现在
虽然换个团队，换个产品，以互联网的方式设计产品，设计架构。但是考虑到成本问题，毅然决然的抛弃了 UI。到目前为止只做接口测试。
啰啰嗦嗦写了不少，目的只有一个，别做收益不够的投资！
#9 楼 @kevin_xu_v
其实最到最后，基本上除了真实的开发业务逻辑之外，整个架构从硬件到软件，从与 boss 谈判到动手搬机房，从人员招聘到团队稳定建设，真真的统统摸索了一遍。在国内来说，团队不够成熟的话，ui 自动化测试没有半年以上的迭代周期，可以先别碰了。
@mic, 赞有人的地方就有江湖。
赞同：自动化一定要证明有其存在的价值。
从我的个人实践上来说： UI 自动化一定要从最简单的做起，不一定是一定要 cover 一个主流程。常常见到一些测试经理说，自动化 cover 了几个主流程（外行话）。如果主流程太长（10 多个子模块交互），我想基本上一个主流程就搞死你。
我推荐的做法是：分拆，分拆成一个个颗粒度很细的小测试。
在这方面投点资还是可以的。
看到大家的讨论受益匪浅，自动化还是很有价值的，但是我这边的测试现在是分层来测试的，基本的套路是底层的单元测试，然后是接口的自动化测试和一点点 ui 的自动化测试以及最上层的验证测试。移动互联网迭代太快了，刚开始做比较费劲，也比较难推进一些思想的实现，不过还是坚持下来。做出了一些成果。
很多时候做 ui 自动化不是为了测试 ui，而是为了 endtoend 的模拟用户行为，以此曝露用户路径会发生的问题。
