能接口自动化搞定的不要做 UI 自动化。。。

赞同用数据说话，UI 自动化有其存在的理由，如何运用恰当是需要思考的

倒金字塔

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

求解，在分层测试体系中，对于 API 这层的代码稳定性 一般采用什么样的测试策略去保证呢？

不是应该从给项目/公司带来的实际收益来评判吗?

标题应该改为 “用数据说明为什么要减少持续集成中 UI 自动化的比例”。楼主这样说有以偏概全之意。

#4 楼 @alfor 你指的不稳定如果是发生变更的话，通常情况的接口都是增量变更，改逻辑通常情况下都是新起接口，老接口仍然要向旧版本兼容，所以通常 api 自动化只需要跟随新版本补充新接口即可。

#2 楼 @quqing 赞同，存在即合理，但我个人觉得 UI 自动化测试不适合接入快速迭代的 CI 中，目前我们的做法是通过友好的前端，让响应变更速度更快，成本更低，然后交给业务测试团队自己按需去跑。

所以异步才是正途（滑稽脸

能不能对失败的原因做一下总结？

#6 楼 @uncleleung ，我这没有减少持续集成中的 UI 自动化；最早 UI 自动化是测试用例能自动的都自动，那样比例可能会到 80% 甚至更高，目前我们选取 p0/p1 的用例来做自动化，大概是 30% 的比例，加入到持续集成后，发现 UI 自动化运行的时间过长 (在 google 每个项目持续集成的时间会有一个限制)，从失败原因可以发现元素找不到和超时是 2 大主要原因。现在我们的做法是分成 2 个持续集成，1 个是非 UI 的另一个是 UI 的。

#10 楼 @actionwind ，直接看图片，很直观。

#12 楼 @oscarxie 是什么造成了这些问题？是测试代码没写好呢，还是被测程序存在 bug，不能说测试不通过就怨到自动化测试的头上吧

#13 楼 @actionwind ，API 的没什么问题，是一些资源上的。Webdriver 的我们统一用 Byid 的方法，每个元素都有固定的 debugid，偶尔才会有元素定位不到的问题，主要是在 timeout 方面，目前我们在分离一些 cases，过去一些 case 写得比较大，另外 webdriver 从 15 年开始已经都由开发自己编写，但是 UI 碰到年度的改版就会出现大面积失败，所以我们减少 UI 自动化的投入。
另，我的帖子没有任何地方提到怨自动化测试的方面，不知道哪里看出的，自动化测试包括了所有测试，不仅仅是 UI 的，我贴图里的 Failure reason 很直观。

#14 楼 @oscarxie 比如说那个排第一的失败原因，看它写的大意是找不到断言中所规定的元素，也就是说测试的实际结果和期望结果不符，如果不是测试脚本写的有问题的话，那应该就是这种 ui 自动化测试在被测程序中找出大量的问题来了，那么恰恰说明这种 ui 自动化测试是很有必要的吧。看你的解释说主要是 timeout 方面的问题，那是不是说明被测程序在性能上跟不上？还有 ui 改版的时候出现这样的大面积失败，那还是回到那个问题：到底是 ui 测试脚本没跟着改好呢，还是被测程序改版的时候改出问题了？如果是前者，那就应该追究脚本编写者的责任，如果是后者，那应该给脚本编写者记上一功了，呵呵。总之，不论是以上哪种情况，好像都不应该说通过减少 ui 自动化来解决吧

#15 楼 @actionwind ，你提到的这些在理论上都对，但实践起来却不是这么回事，考虑下维护成本吧。

#16 楼 @oscarxie 其实，软件测试的目的之一就是为了降低总体的开发成本，因为问题越早发现，它的解决成本就越低，所以尽早的测试是必要的。现在你所遇到的问题是：你认为 UI 自动化测试给你的工作造成了巨大的麻烦（看你整篇文章的论调大致是这样子的）。但实际上，给你造成麻烦的根源其实是被测程序所存在的问题过多，而 UI 自动化测试找到了那些问题。从这个看来，应该说你们公司的 UI 自动化测试做得相当的好了，很多公司的自动化测试工作基本找不出什么问题来的。看来，软件质量保证工作独立成体系是很必要的，否则，如果让开发人员主导的话，测试做得好反而会被认为是 “麻烦制造者” 而被削弱甚至砍掉。

#17 楼 @actionwind 我觉得你应该了解下 flaky 的意思。

另外，建议读下 http://article.yeeyan.org/view/66324/453360/。case 不稳定不代表被测软件有问题。我觉得这个才是 @oscarxie 想说的吧？

#17 楼 @actionwind ，

1. 元素变更并不能说明被测程序的不好也不说明测试脚本不好，恰好说明维护成本高。我们让开发来参与 webdriver 的编写可以让开发了解 UI 自动化，提高可测试性，比如过去开发对元素不命名或不给 ID，通过编写 webdriver，有了开发的配合，加上 debugid，可以让元素定位更便利，但这种行为并不是每个开发都能做到或者说一直坚持。
2. timeout 正好说明 webdriver 不好的一面——耗时，也无法体现被测程序的好坏以及测试脚本的好坏。UI 自动化可以很好的模拟用户行为，但是在前端很多关联依赖的情况下，一个用例跑完用时很长，可以增加等待时间，不过会极大的消耗硬件成本。
3. 关于 Flaky，@chenhengjie123 已经提到，在做浏览器兼容性测试会经常碰到，各个浏览器速度不一样。
4. 测试团队如何在资源有限的情况下更高效，比如我的测试团队只有 3 个人 (Google 里开发测试比 10 比 1 很常见)，测试团队参与各种类型的测试，那么在 UI 自动化应该投入多少呢，在实践中需要不断调整，你是愿意让你的团队成员每天陷入维护 UI 自动化还是做更多其他类型的测试。
5. 软件质量是一个全员的工作，不是独立的，测试无法保证质量，测试提供及时的反馈和警示风险，开发才能保证质量，在明确的需求下，开发的代码质量是最关键的，如何让开发认识到质量的重要性，推动开发的质量意识，是一个长期的工作。

UI 自动化的 case 维护成本是比较高，那么应该思考下如何降低 case 的维护成本了。可以看看 https://testerhome.com/topics/3394 海豚的思路，基于录制，自动生成测试脚本，对于小白用户可以基于录制去完成，对于高级用户可以更深层次的写测试 case。
现在我们遇到最大的问题，是由于数据上的不稳定性（随机）导致 UI 的变动，使得录制的 pagediff diff 差异比较多。现在过渡的办法是做测试桩，将接口返回的数据固定化，达到 UI 界面的稳定。

1、脚本写太烂，现在 Framework 都是 wait for idle 的吧，何来延时一说
2、覆盖率，覆盖率，覆盖率！这玩意主功能回归覆盖一下就完事儿了。。 80% 您太开玩笑了
3、正确使用的话维护成本还行，凑合

ui 测试做得更轻，让它更专注在界面操作和渲染方面的验证，不要寄希望去用它检查后端功能，commen sense 吧，需要用数据来说话？

ui 自动化 也是有些必要性，咳咳看什么业务，某些消息是需要打开某个 ui 才可以下发（保存，读取，变更），直接接口测试当然也行，测试模拟真实操作。《---自动化考虑拆分业务吧
一些 ui 伸缩性测试，有必要性。
单纯读取元素就意义不大，不过还是需要的。
补充：如果按多少行用例产出 bug 数量，级别和 bug 类型重复来看，ui 产能就真不怎么样。

分层自动化测试

#19 楼 @oscarxie

大神们，其他我不敢妄言，但是关于 Flaky，你们的流程是怎样的呢？难道一旦 UI 级别的自动化报了错抛了异常，就直接丢给开发？例如 Web 的 UI 自动化，Chrome 和 Firefox 在表现上必定有差异，那么不同的浏览器执行的脚本必定是有细微差别的两套。假设用 Firefox 跑了 Chrome 的脚本导致失败，第一层次的把关人员应该是测试人员——去确定问题是由软件造成的（回归测试发现 Bug）还是 Case 本身的不稳定性。手工复现脚本中的步骤应该永远是第一步——打开 Firefox 确认 Bug。我相信作为测试人员——脚本的开发者应该很容易确定是否 flaky，对吧？

个人认为 UI 自动化绝对不适合所有的企业，当然也不是所有企业都不适合。是否开展 UI 自动化应该从一开始就有一个基本的判断；如果实施，重中之重就是不能有过于刻板的生产线。否则就会出现题主数据中所反应的问题。

团队里每个人都有机会做，没有只做自动化的人

这个你需要根据工作量来计算了，那么多客户端加上各种设备，几十号人至少了