第一条看你领导还是挺支持的，已经让返工了

第二这个是哼多企业的常态，只能适应不然为甚么这么多人喊 UI 自动化不好做!!

第三这个有的人验证有的不验证，根据你自己的需求来，换句话说如果你不验证根本就无法保证你自动化的有效性，那么就要验证

第四 这是通病，估计有人会给你推荐 PO 模式，至于 PO 能否让你提高效率你可以评估，再者需要做减法，如果把所有用例都自动化那么就太大任务 维护起来也费力，可以主要放在核心业务 主流程 以及减少逆向场景等，看领导是否同意

第五肯定是接口更成熟，收益更高所以很多人看不起 UI，以上!!!

但是接口测试不是比 UI 自动化容易吗？

接口自动化投入产出比高一点，而且运行起来比 UI 自动化更快速稳定

• 需求经常变动还必须要做 UI 自动化的话，团队最好是采用敏捷开发。除此之外提供一些减轻重复工作的建议：

  • 先写测试用例再开展编码和测试工作，让产品、开发和测试人员共用一种 “语言”，减少 Bug 和对需求的理解不一致，从根源上避避免需求的不停变动。
    
  • 对于经常变动的 UI 界面，学会使用 Selenide 而非 Selenium，使用 Selenide 的 $("页面元素定位符").find(byText("你要搜索的页面元素")); 去搜索页面上的元素会更高效，代码可读性更高。对于主力是测试前端 Web 页面的公司，那么 Taiko 比 Selenide 还要好一些。可以尝试使用 Taiko 去编写测试脚本。
  • 采用 Gauge+Selenium（或者 Selenide）去做测试，测试用例可读性高，测试报告清晰可见，测试代码复用率高，减轻重复工作量。
  • 需求变动导致工作量增加的本质是以前的代码会废弃，除了上述提到框架工具之外，阅读《Clean Code》这本书对你的帮助会很大，学习重构你的代码，减少代码中的耦合，归并功能一致的代码，抽取公共方法，适当构造静态类便于直接调用。还有清晰可见的方法名、代码即注释的命名习惯，可以很好地抵御频繁变动的需求，尽可能保证代码的可用性。

• 虽然人们总说改变不了别人，就去改变自己，但是对于团队开发而言，这句话并不是那么妥当。

  • 测试人员最好要求开发人员做好单元测试，如果论收益而言，单元测试的收益是最高的。简单应付了事的单元测试也不行，应要求开发人员单元测试的代码覆盖率达到 95% 或者 100%。

最后针对你提出的问题：

• 1.项目规定有统一的 id,前端不加 id 用其他元素定位项目经理会让反工
  • ✔
• 2.界面需求随时新增没有稳定的需求
  • 减少 XPath 和 CSSSelector 的使用，尽可能使用 byText() 的方法去搜寻元素。
• 3.接口验证数据库后 UI 自动化也验证数据库???
  • UI 自动化是有预期的，如成功或失败，准备好数据集然后开展自动化测试会更方便一点，即先从数据库里面把数据拉出来，放到 Excel 或者其他可以被编程语言读写的文件里面，然后在开展 UI 测试时去验证即可。当然你连通了数据库再去做测试应该也可以吧。
• 4.自动化维护成本太高了效率也不怎么样
  • 自动化测试属于敏捷开发中的一环，团队的开发模式有很多种，比如野路子开发、遵循 DevOps 的开发等等，团队的交付有很多种，比如差不多就能上线了，也有遵循 CI/CD 的交付，理想的自动化测试应该是项目交付中的一环，以 Jenkins 为例，开发人员把写好的代码推送到 Git 上，运维人员在 Jenkins 点击构建，Jenkins 自动去 Git 上拉取最新的代码并且把项目打包好，然后上线到测试环境，然后测试人员写的自动化测试脚本（包括单元、集成、接口、UI）会自动执行，自动产出测试报告，如有问题会向开发人员发送邮件，有些做得比较好的测试平台可以自动提 Bug，如果没问题产品会自动上线。所以从总的情况上来看，自动化测试是效率高，收益好且易于维护的。

以职业发展而论，UI 测试、接口测试、压力测试、性能测试和抓包分析都是基本功，真正体现你测试能力的是参与产品的需求讨论、做好产品的缺陷预防工作，精准把控产品上线后可能会发生的异常，保证测试部门和其他部门的沟通顺畅，同时把控需求的合理性。做测试是容易做到管理岗的，这源自于测试岗位需要保证产品质量坚如磐石这一特性决定的。

目前正在封装的框架就是采用 POM 模式上面也同意了,最重要的是项目经理规定自动化要覆盖 70%.很多需求刚写一半用例流程就变了.所以最近就一直纠结于这个自动化有必要没有了

公司接口测试用的 Yapi 都是模拟的 Mock 数据

是这么个道理但是现在自动化被说得很厉害

感谢大佬的耐心回复!
仔细阅读了回答也去看了 Selenide 这个二次封装的框架,后面看看能不能用在项目上
开发的单元测试是有单独的人做单元测试覆盖率在 100% 后端 但是前端只有自测
验证数据库这个环节具体资料还在查看中也谢谢提供的思路

个人观点：

比较稳定且需要重复测试的，可以用自动化。

不稳定但自动化测起来比人工快的（比如各种字段校验），也可以用自动化。

这两天我也在用 YAPI，已经搭建起来了，想结合 Jenkins 做 CI，定时啥的，但是没搞起来。

项目周期不长 界面不稳定的话 不建议做 UI 自动化 费效比太低

接口自动化和 UI 都重要 不存在向哪个方向发展 都需要掌握

如果说用例写一半，需求就变了，只能说是自动化团队能力还有所不足，测试产出效率需要提高
就拿第二点来说，界面需求变了，在 PO 模式下，也就是元素定位发生变化了或者方法的流程变了，这个变动的影响范围应该只是页面级的，为什么会没有开发改得快呢？

另外接口自动化、UI 自动化完全是两套东西，也不具备可比性。
接口自动化无法替代任何手工功能测试，而 UI 自动化是可以解放部分手工工作，就冲这一点，UI 自动化会一直是效率追求的目标
接口自动化技术太成熟了，很难再玩出什么新花样出来。