一、前言
UI自动化测试真的比较难以实施吗？ROI真的比接口自动化测试低吗？从哪里得出如此结论？得出结论的人是否有真正实施过UI自动化测试呢？这些问题的答案可能不是绝对的，但是有一点可以肯定：得出如此结论的人绝对没做过UI自动化测试！为什么题主敢这么说呢，且听题主娓娓道来！
1.1、UI自动化测试
咱先以实现web自动化为例，这里面涉及的核心工具就是selenium，当然或可有其他工具代替，那么掌握了selenium工具的使用就代表自己会web自动化了吗？我看未必！再说一般人真的会在公司主推UI自动化测试吗？不会，因为单看投入成本、ROI都不可能有效的保障项目质量，一般有实力的公司都会UI+接口自动化实现全覆盖，多一重保障！所以结论是都没有实施过，怎么能说它难？说他ROI低呢？
1.1.1、那么谈谈什么样的项目适合UI自动化？
- 项目周期长，表示需要长期维护
- 需求相对稳定，代表功能稳定、易测试
- 团队成员也要具备一定的测试脚本开发能力
这里可以很负责的说，对于一个新项目不要一上来就实现UI自动化，这有点本末倒置，对于新研发的web系统，应优先保障它的功能正确，适当可以实现接口测试、自动化测试，待他逐渐稳定后再结合实际评估是否可以介入web自动化！否则负责人过来跟你说这个项目就到这了，那你还需要继续实现web自动化吗？题主相信读者心中自然有了答案。
1.1.2、先思考一个问题：功能测试和接口测试有什么区别？
这里捡重点说，功能测试的侧重点是UI及交互、用户体验，更多关注功能的实现本身是否满足用户需求；反观接口测试呢，更关注程序本身的内部实现(参数校验、逻辑处理、数据交互等等)，是否满足业务需求。前者用户体验更直观使用的系统是什么样的、有什么样的功能，后者呢，是一般用户不会去关注的，他可能不懂内部逻辑。
1.1.3、再思考一个问题：为什么从现场(生产)反馈的问题都是前端？
因为用户是通过前端直观反馈的，他并不会去怀疑自身环境或者是程序内部错误，所以说前端才是用户的入口(眼睛)，加上那不可揣摩的用户行为，谁也不知道用户会在什么样的环境下操作系统！而前端又是用户接收信息的第一窗口，他不可能会去考虑后台服务怎么了。
1.2、接口自动化测试
这里的接口自动化咱们需要分两种情况来介绍！一是单接口的入参覆盖，也就是一个接口的用例个数是由参数个数、类型、数据限制所决定的，毫不夸张的说：少则几个多则大几十，但是这类自动化测试一般不会投入到生产上去，那是因为它会给服务器造成系统压力，如果不巧还会影响正常用户的使用，这样的无差别攻击是没有必要的；再说以核心业务场景设计的接口自动化测试，无疑减少了投入，也可以高频高效的反复使用，这样一看它的ROI就比较高了。
接口自动化测试没有项目适不适合的困惑，只是因为它的投入相对低、产出相对较高，这里咱们不考虑它是编码实现自动化测试解决方案，而是引入开源的自动化测试平台，一来就不会对团队成员有编码的要求，二来也易于学习和使用。
1.2.1、再来battle一下UI自动化测试ROI
可以总结前面提到过的经验，比如项目投入周期长(超过1年\长久维护)，或者说它已经趋于成熟，然后需求变更稳定(大多会是新增)，用户反馈大多是从前端、视觉分析得到的问题，经过分析：有些是因为前端功能失效，有些真的是由于应用服务业务处理失败，但这个并不妨碍实现UI自动化，反而更能直接回归发现问题。
谁告诉你它的ROI比接口自动化测试低了？他都没有实施过，怎么能这样断言？很明显得到这些结论的人都是人云亦云，实践出真知，哪怕UI站在金字塔尖、比重小，也不能忽略它的地位。唯一的诟病就是前端开发的页面元素不够规范，让实现UI元素定位的人苦不堪言。
二、总结
日拱一卒无有尽、功不唐捐终入海！
在没有实践之前，都没有发言权，更不能武断出结论，在一方不能完全保障或覆盖的同时，应该要有更多解决方案来落地实施，这样才能有效的对比出结论，回头再说一句，如果一家公司没有专职转岗来做自动化，那么任何自动化都是需要投入成本，然后再来看ROI其实差距并不大。但是不能否认自动化存在的意义，它主要的目的用来做两件事：冒烟测试、回归测试，保障项目迭代不会影响历史功能。维护旧脚本、开发新脚本都不影响它的价值体现。
