作为一名 10 年测试老鸟，新技术的狂热者，最近在思考这个问题。
近 5 年来，分别开发了三大端的自动化测试框架，并在公司进行持续化落地及演进。

基于测试场景越来越多，需要运用的技术越来越多，对于自动化框架代码在做不断的更新。
经过 5 年的技术沉淀，框架逐渐成型，对于项目中自动化测试的需求都能满足，健壮性、复用性、功能性不断提高，但在这些更新上，仅限于独立的分支，代码的结构上、需求的满足上都接近做到了极致，接下来，如何继续提高呢？

这个时候从大的层面来考虑，在测 UI 的时候，对 UI 框架进行更新，测接口的时候，又要对 API 框架进行更新，比如 APP 测试比较少，可能长时间不做维护有些地方都忘记了，做不同测试类型时又要不断切换项目，构建用例，成为了目前的瓶颈问题。

思考几个问题：

1. 有没有办法进行框架级别的整合，不管是测 UI 还是接口还是 APP，都采用同一套框架，减少对于框架的维护工作量？
2. UI 测试构建元素定位信息的过程太繁琐了，也容易出错，能不能跳过？
3. 如果某产品有多端，需要进行联合测试，比如说一个用例，在 web 上修改一个参数，在 APP 端验证是否修改成功，这样类似的需求在框架层面好像无法实现？
4. 如何避开复杂环境搭建的过程，减轻使用代码构建测试用例的场景，如何让更多的人投入自动化测试的实施？

目前初步的思路：

1. 重写三大端的底层封装设计，用一套底层架构来实现多个不同类型的自动化测试，比如测 UI 时构建元素定位信息等参数即可、测接口的时候构建接口请求参数即可，但最终的框架代码使用同一套，减少对于不同测试框架的维护成本，同时满足多端联合测试。
2. 在 UI 自动化中，结合 AI 进行元素定位信息的生成，在构建用例时不再需要构建及维护。
3. 将测试框架打包成工具，跳过环境限制，测试机有 python 环境即可运行。
4. 开发自动化平台，整合框架，加入定时执行机制做线上环境巡检，swagger 接口直接导入到平台并实现在线调试、用例任务执行分析以及图表展示分析等等，实现全栈、全业务、全场景下的自动化测试开发。

经过第一轮技术分析，我认为以上想法都可以实现，我预计耗时一年，对我的自动化工具能力做一次质变。
不知道大家对这个问题有什么更好的见解，可以分享一下。