在进入移动互联网时代之前那些年，GUI 自动化测试火了一阵子，老 QA 基本都听过 QTP，后来进入移动互联网时代后，前后端分离，微服务等框架出现，API 自动化测试随着几篇科普文以及改写转发的软文火起来了，直到现在，做没做过自动化测试的 QA，开发，CTO 都统一口径的说 GUI 自动化测试不行，UI 不稳定经常改动，写完的自动化测试投入成本太高......google 搜索 GUI 自动化测试基本都是提缺点的，元素定位难，操作某元素失败，执行 GUI 自动化测试慢等等，可是 selenium 和 webdriver 一直没有停的不断更新着....

一直期待听到不同的声音和新的实践，但是寥寥无几，像这篇《测试人员必看：传统测试向工程效能转型的最佳实践》提到 “自下而上依次是 unit test、API test、GUI test。在转型之后 unit test 减少，API test 增多，GUI test 依旧，上方多了一层 Exploratory test，这一层是真正的基于测试的理念和探索式方法来尽可能多的发现软件系统潜在的缺陷。从人员的角度来看，无论是转型之前还是之后 unit test 都是开发来做，但是 API test 和 GUI test 在转型之后从测试转向了开发，原来团队的业务测试人员现在专注于 Exploratory test。” 好像并没有得到太多的支持和采纳。

正题

1、怕 testcase 因前/后端程序变更而失败吗?
2、写出来好几百个接口测试用例，回归执行通过率平均 99.99%，维护脚本的投入很小，说明自动化测试做的很成功吗？
3、GUI 自动化测试用例编写难度比 API 测试用例大吗？写好 GUI 自动化测试对 QA 要求更高吗？
4、是否分析过缺陷发生在 API 还是前端更多一些，再考虑投入在 API 自动化多些还是 GUI 多一些呢?
5、如果遇到接口参数多数据依赖复杂的应用，业务流程和场景的测试是否通过 GUI 进行测试才是最好的选择？
6、API 自动化测试能对流程场景进行覆盖，那么对于支持定制的流程、复杂的数据关系的应用程序能通过串联起来 API 实现流程场景覆盖，编写这样的用例投入的成本是不是太高？

以上问题如果在一些 2c 的小程序，小 app，小电商应用上讨论答案可能很容易得出。如果是一些 Saas 平台 2b 的企业级应用呢？

参考贴:
搜索了论坛关于 “UI 自动化” 的搜索结果, 共 1411 条
《关于 UI 自动化的前途》https://testerhome.com/topics/16015