api 可以做，就是我们老大眼里，api 没法模拟用户行为。 个人一直觉得移动端的自动化，api 才是王道。

板凳已端好

#1 楼 @anonymous api 不是王道。。。

你这个不是自动化的前景啊，你就一直在做 UI 自动化啊喂

自动化只能是补充，手动永远都取代不了。
ui 的自动化和接口的自动化需要按照自己项目的情况裁剪。

嗑着瓜子等待结果

大规模 UI 自动化 纯粹就是为了 KPI

开始喷！！！！

具体问题具体分析吧，私以为自动化测试是窥入测试开发的一个踏板

选对工具，指定正确的策略，前期投入足够人力，自动化还是有用的。

如果不是大公司，功能和用户数不到一定的数量级，说实话，转开发或者转其他岗，自动化基本没有什么意义。

我这 ui 自动化是辅助

UI 自动化只是一个手段，达成需要的目的即可

同感, UI 自动化只是领导用来宣扬政绩的工具.

个人观点，欢迎拍砖：

1、自动化没有银弹，也不是银弹。不要以用自动化代替手工作为出发点，你会发现自动化的成本很有可能比手工更高。

2、不明白为何做完 UI 自动化还不能降低手工测试量？至少能减少一部分回归测试的工作吧，除非你们的自动化用例本来手工也不会执行。不过从成本角度和投入产出比角度，即使是比较熟练的 UI 自动化工程师， 保守估计编写一个用例使用的时间（包括查资料、封装代码、学习相关知识、调试用例等）约等于手工执行这个用例 10~20 遍。所以如果这方面期望太高（能达到手工编写用例的速度，或者能快速替代大部分手工测试的工作量）肯定会失望。

3、不要把自动化等同于 UI 自动化。不要随随便便把 UI 这个字眼省掉，两者之间差异太大了。如果只是做完了 UI 自动化，你会发现还有很多问题。例如：为啥这个用例跑 5 遍会有 1 遍 fail？为什么点了这个按钮有一定概率没有相应效果？这些问题手工测试时感觉不太严重的问题（测试人员很有可能会多执行几遍，有一遍 pass 就算通过了）在 UI 自动化测试中就会暴露出来，并影响你的测试结果可信度。所以你得收集日志，得收集更多的运行时数据来便于找出失败原因（ 无法定位出错原因或者忽略 fail 都会逐步扩展并最终让你的 UI 自动化变得不可信，然后就没有然后了。。。），所以要做的事情不仅仅是让程序帮你点就够了。

4、UI 自动化本来应该是金字塔的上层，占比最少。如果想往自动化，或者说往测试方向深入发展，要多扩展，例如了解一些灰盒/白盒的东西（这方面的自动化投入产出比相比 UI 自动化可能大一些，你也可以看看一些开源项目是怎么做测试的），了解开发（这点很重要），了解项目的整个过程而不只是关注其中自己负责的点（个人觉得无论你是项目里的哪个角色，这点都应该有基本的了解）。

学习学习。

#15 楼 @chenhengjie123 有道理啊。其实最简单省事的就是 monkey。。。。但是领导们觉得不够高大上，我们就是要模拟用户操作，我们就是要智能化，我们就是要节省人力，给我搞~~~呼呼哈希

确实觉得 UI 自动化在实际生产中起到的作用有限

第一句：不能提高测试效率，无法减少手工测试工作量的一切自动化都是耍流氓！
第二句：绝大多数的 UI 自动化都是在装 B！
补一句：其实我就是 UI 自动化测试工程师！
补充两句：其实自动化还有很多很多

有兴趣可以联系我。我们还在自动化的路上。

#20 楼 @anonymous 同学，你至少说下你的联系方式吧。。。匿名状态下谁知道你是谁。。。

ui 自动化做冒烟，用例少。
ui 自动化做稳定性测试，包括收集各种性能指标，日志。
无。。。

不能一棍子打死 其实 UI 自动化可以节省好多重复工作~

#15 楼 @chenhengjie123 app 端的 api 自动化我是非常推崇，但是尽管我来这时间很短，我已经不止一次提出，也描述了这的效果。但是总是被一句话干死，这东西就没办法模拟用户操作了啊。 所以。。。。。可悲的我们 app 的 ui 自动化如果可能需要用到很多 web 后台 CUD 时，我们还得调用 web 去模拟用户操作数据，再回来 app 端查看。

#15 楼 @chenhengjie123 1. 我们这么想的，自动化是手工测试的一个补充，无法替代手工测试 。 头不这么想，目标 70% 的 UI 自动化覆盖率。
2.通常移动互联网需求变化是很快的，很难一个脚本能活几个迭代。
3.知道 UI 自动化！= 自动化。 感谢提到，一些容易被忽略的点。
4.越底层越稳定。

#24 楼 @anonymous 这个很正常，我们也在这么做。。。app 操作完看 web，web 操作完看 app。好处是如果 pass 能证明 web，app，接口三者都没问题（至少正常使用没问题，覆盖率相比单独测试肯定低很多），坏处是如果 fail 比较难定位具体原因（要配合日志分析）。

个人觉得，这个其实应该做分层的自动化。api 是一部分（mock app 来发请求，看 web 是否正确处理），app 是一部分（ UI 操作后是否有相应的请求发出），web 后台是一部分（后台数据是否正确更新）。当然最后也是需要整体做一下测试的（这样可以最真实模拟用户操作，有点类似验收测试，虽然覆盖率低，但不可省略）。不过资源受限的情况下，大部分人应该偏向于直接做整体的测试吧。

#25 楼 @anonymous 我觉得其实也要看实际情况。

1. 既然需求变化快，那么应该只对相对稳定的模块（最好也同时是核心模块）进行自动化，否则无论是哪个级别的自动化（UI，接口，单测），维护成本都比手工高很多。
2. 是不是越底层越稳定我不确定（也有不少变更是 UI 不变，底层变的，如性能优化），但越底层代码覆盖率正常来说代码覆盖率越高。
3. @lihuazhang 之前说过，好的团队测试不会只是某个人/某个职位做的，而是所有人一起做。用代码做测试还是人工做都只是手段，要高质量还需要全团队一起努力。

我只用它来做日常主要业务服务的巡检，另外拿它来做 smoke，其余的测试项不涉及，代价太大了