作为一名 10 年测试老鸟，新技术的狂热者，最近在思考这个问题。
近 5 年来，分别开发了三大端的自动化测试框架，并在公司进行持续化落地及演进。
基于测试场景越来越多，需要运用的技术越来越多，对于自动化框架代码在做不断的更新。
经过 5 年的技术沉淀，框架逐渐成型，对于项目中自动化测试的需求都能满足，健壮性、复用性、功能性不断提高，但在这些更新上，仅限于独立的分支，代码的结构上、需求的满足上都接近做到了极致，接下来，如何继续提高呢？
这个时候从大的层面来考虑，在测 UI 的时候，对 UI 框架进行更新，测接口的时候，又要对 API 框架进行更新，比如 APP 测试比较少，可能长时间不做维护有些地方都忘记了，做不同测试类型时又要不断切换项目，构建用例，成为了目前的瓶颈问题。
思考几个问题：
- 有没有办法进行框架级别的整合，不管是测 UI 还是接口还是 APP，都采用同一套框架，减少对于框架的维护工作量？
- UI 测试构建元素定位信息的过程太繁琐了，也容易出错，能不能跳过？
- 如果某产品有多端，需要进行联合测试，比如说一个用例，在 web 上修改一个参数，在 APP 端验证是否修改成功，这样类似的需求在框架层面好像无法实现？
- 如何避开复杂环境搭建的过程，减轻使用代码构建测试用例的场景，如何让更多的人投入自动化测试的实施？
目前初步的思路：
- 重写三大端的底层封装设计，用一套底层架构来实现多个不同类型的自动化测试，比如测 UI 时构建元素定位信息等参数即可、测接口的时候构建接口请求参数即可，但最终的框架代码使用同一套，减少对于不同测试框架的维护成本，同时满足多端联合测试。
- 在 UI 自动化中，结合 AI 进行元素定位信息的生成，在构建用例时不再需要构建及维护。
- 将测试框架打包成工具，跳过环境限制，测试机有 python 环境即可运行。
- 开发自动化平台，整合框架，加入定时执行机制做线上环境巡检，swagger 接口直接导入到平台并实现在线调试、用例任务执行分析以及图表展示分析等等，实现全栈、全业务、全场景下的自动化测试开发。
经过第一轮技术分析，我认为以上想法都可以实现，我预计耗时一年，对我的自动化工具能力做一次质变。
不知道大家对这个问题有什么更好的见解，可以分享一下。
可以采用自定义 pttest.mart.app/api/pc 标签的形式来维护多端
工作 10 年了说明你也差不多 30 多岁了，说实话这些东西都是比较常规的测试方案和技术栈。如果没实践过可以试试吧。至于我为什么开头说你差不多 30 岁了，因为我想说就算你弄出来了也没啥用。30 还在想技术太晚了这些东西应该在 5 年左右就积累出来的。
流马测试平台除了第二点搞 ai 进行元素定位，其他的都有。三年前就搞完了，对个人提升还是不错的，但是在工作中落地还是需要更多的定制化
我不吃香菜
回复
我觉得你说的挺多，作为这么多年经验的测试，这些技术基本成为基础项，现在更多的应该是项目协调能力什么的，还有一点，测试这行干不了太久，多思考一些别的出路
你的技术热情和持续改进的思考值得赞赏，但属于南辕北辙，陷入了"技术完美主义"的陷阱
-
第一，追求大一统框架反而会增加复杂性，就像想把螺丝刀、钳子、焊枪合成一个工具，结果可能哪个都不好用
- 试图用一个抽象层完美适配 Web UI 控件交互、HTTP API 请求/响应处理、移动端 (Android/iOS) 特有操作 (手势、权限、通知、应用生命周期等)，会导致这个抽象层变得极其复杂和臃肿。你需要为每种测试类型定义通用接口，并在底层实现差异巨大的适配器。这本身就是一个巨大的、易出错的设计和高成本维护负担
- 当 Web、API、APP 任一端的底层技术发生变化时，你都需要修改这个统一的框架。一个地方的修改可能会意外影响其他类型的测试，调试和回归测试成本极高
- 使用者需要理解这套庞大的通用框架概念，才能编写特定类型的测试，增加了上手难度。维护者也需要精通所有领域才能修改这个 “巨无霸”
-
第二，AI 生成定位看似美好，但实际应用中元素动态变化会导致维护成本不降反升
- 元素属性模糊、页面结构变化、存在遮挡或动态内容时，生成的定位器不稳定或易失效
- 当 AI 识别失败或给出错误/不稳定的定位器时，你仍然需要人工干预去修正
- 当测试失败时，排查是定位问题、AI 模型问题还是应用逻辑问题会变得困难
-
第三，平台化建设容易陷入功能堆砌，反而偏离测试本质
- 构建一个功能完备、稳定、易用的自动化平台是一个极其庞大的工程，远比你想象的要复杂得多。它会消耗巨大的开发、测试、运维资源。你预计的一年时间可能连一个基本可用的核心版本都难以完成，更别提达到 “全栈全业务全场景” 的目标。这容易变成一个长期投入巨大却难以产生预期 ROI 的 “黑洞”
- 市面上已有非常多优秀的开源和商业测试管理、执行、报告工具，完全自研所有功能是否必要？能否基于现有工具进行集成和二次开发？
- 平台本身也需要持续开发新功能、修复 Bug、升级依赖、保障安全性和性能，这又是一个长期且沉重的负担
- “让更多人参与”，目标用户是谁？是业务测试？开发？PO？不同角色需求差异巨大。一个试图满足所有人的 “全栈全场景” 平台，往往谁也服务不好
- 计划投入一年时间做重构，这个成本可能远高于收益
我建议你最好拉你们产品经理进去讨论，别让技术思维完全主导了需求定义阶段
你们需要有跨角色协同验证，否则投入产出比严重存疑，风险巨大
你这里的槽点太多了，再说都可以写篇水帖了
最后
测试架构的最高境界应该是：在满足业务需求和质量目标的前提下，保持足够的简单、灵活和可维护性，并能快速适应变化
Chras
回复
感觉提升是提升，就是感觉平台能干的活自动化都行，并且自动化代码方式还灵活。但是咋说呢 能写个平台 自己写前后端 做一些兼容前端的判断 也是一种能力吧
（1）实施前的考量：这取决于你在公司能调动的资源，包括人力资源、管理协调能力、上下支持力度等等；
（2）预期结果负面效果的处理：以及最重要的是投入的时间与预期产出不符时如何收场；
（3）技术与业务的导向：这一切计划的技术导向与目前公司业务发展是否相匹配，对公司项目是否有短期内可见的提升；
（4）体系搭建后续的维护：另外，假设确实花费了一年时间完成了这些设想，后续的维护又如何调整，能跟得上业务发展吗，还是说只是要这个 KPI？
- 有没有办法进行框架级别的整合，不管是测 UI 还是接口还是 APP，都采用同一套框架，减少对于框架的维护工作量？
我先质疑一下 “采用同一套框架” 是不是真的能带来 “框架维护工作量的减少”。从开发者视角看可能维护两套东西很麻烦，但是两套变一套不代表维护工作量除以 2，就像 5 楼鸡哥说的，硬凑在一起会带来更多复杂度，可能排个 bug 的耗时变成了之前的 3 倍？换个角度，从落地视角，已实现的老脚本要怎么支持，是要求用户从老脚本全部切到新脚本吗？那这个事情必然做不成（如果不是公司实践，那个人过过技术瘾无可厚非）
- UI 测试构建元素定位信息的过程太繁琐了，也容易出错，能不能跳过？
明确可以用 ai 去解决，业界已经有实践。我个人使用下来觉得很不错，对比原先要理解 xpath、控件 id 等概念，直接用自然语言描述/操作元素显然成本更低，还能让更多人参与进来。我是支持用 ai 解决的。
- 如果某产品有多端，需要进行联合测试，比如说一个用例，在 web 上修改一个参数，在 APP 端验证是否修改成功，这样类似的需求在框架层面好像无法实现？
这个真没必要去解决。你先想想这种联合场景多不多，人工测试覆盖需要多少人天成本再考虑。其次这种跨端联合场景，如果是跨服务端到移动端还稍微好一点，而跨 web 端到移动端就更麻烦，中间需要控制的变量/不稳定因素数不胜数。可能最后做是做出来，要不稳定性像屎一样，要不测试脚本配置编写巨麻烦。
- 如何避开复杂环境搭建的过程，减轻使用代码构建测试用例的场景，如何让更多的人投入自动化测试的实施？
问题 4 没看明白，问题大而泛，没理解希望解决什么问题。是成本问题还是效率问题？复杂环境搭建前后端可以用 docker 等成熟技术解决，移动端不了解。【减轻使用代码构建测试用例的场景，如何让更多的人投入自动化测试的实施】，是指类似低代码的思路吗？现在是有不少团队在探索通过和 ai 聊天结合线上流量抓取、代码分析生成一系列接口自动化测试用例这种事情，不知道你是不是想表达这些。
最后，一个大的自动化测试平台，重要的不仅仅是自动化技术，数据看板运营，上下游套件，排查定位方便度等都很重要，可以考虑这些维度的效率提升。
如果不是老板从上往下推的，建议还是不要做这种费力不讨好的事情。技术更迭非常快，哪怕按照你的想法做出来了，你很难保证这东西可以简单的迭代并且在新技术出来的时候你能很好的兼容。多做点项目可能才是你能站稳脚跟的最大助力
林月
回复
不管是测试还是开发，终究都是项目 + 技术维度的复盘和演进，沟通、协调、项目流程、质量体系固然也重要，但在这里我们讨论的主题已经框定了技术的范围。
王稀饭
回复
大佬 这个回复你是怎么做的呢，用到了新工具？想要了解下谢谢！ 明确可以用 ai 去解决，业界已经有实践。我个人使用下来觉得很不错，对比原先要理解 xpath、控件 id 等概念，直接用自然语言描述/操作元素显然成本更低，还能让更多人参与进来。我是支持用 ai 解决的
阿祖收手吧
回复
技术都是为项目服务的，新技术更新对于底层架构的影响肯定是有，作为一名效能工具开发者，要结合业务需求、公司流程、现状等不断更新工具能力，抛出这个问题，是因为考虑到在长时间的演进中，需求能满足了，代码优化了，贴合业务实质了，那还有哪些地方可以提高呢？
pp1
回复
比如，https://www.53ai.com/news/OpenSourceLLM/2024121816054.html。
MTSC 大会和 QECon 这一类大会应该有相关课题的 ppt，需要自行去搜索一下
ALLEN
回复
我们现在已经抛弃原有的架构了，就是觉得框架扩展麻烦，还有数据库管理用例也繁杂
现在直接让 AI 重写框架，基于业务场景直接生成测试用例。虽然代码可读性不高，但是 AI 可以直接把 UI 自动化、接口自动化这些东西集成到一份测试用例代码里，一个文件就是一个业务场景。调通就可以直接使用了。后续扩展就是基于 AI 生成的框架写一个个业务场景测试用例，调通就行了。
但是我们的做法与你的想法完全是反过来的，是因为我们的产品线不多，业务也没那么繁杂。用 AI 反而解放了我们开发框架的时间，更专注于业务场景自动化的快速实现与部署。
ps：Cursor 这种对于体量不大、自动化不深入的公司是真好用，现在简历上写自己会自动化都不算亮点了，Cursor 写的又好又快。突出点反而是你如何使用这些工具，对业务的理解是否深刻。
change
回复
可以网上找找 MTSC 或者 QCon、QECon 最近一两年的 ppt，应该已经有类似的方向，我司的 UI 自动化框架团队也做了这种 ai 找控件再点击的能力，虽然有局限性但感觉已经能覆盖 80% 以上的常规自动化场景，大体来说长得像这样：
ui.action('点击页面右上方圆形蓝色的“搜索”按钮')
ui.action('点击搜索结果列表中第二条数据')
风子
回复
他说的没有任何问题，那些技术本来就是没有任何壁垒，看你的过往评论有一些” 工作多年还是技术能力不够，工作年限跟技术不对等，又很焦虑 “，你早日抛弃坚持技术唯一切的观念会好很多
下边是我的观点：到了现在这行情还在坚持技术唯是自己一切根本，测试为自己一切根本的人
到后边这种想法生活终归会给自己迎头一击，如果没有这方面钻研技术的心态（这部分人很少）
就早日把技术当成自己工作的需求，把测试当成自己的一份临时工作，后边遭到挫折的时候还会好一些
测试一定要把思维打开，不要与研发一样局限于技术，局限于测试，就是一份工作而已，给自己积累第一桶金的途径
多投入到投资、生活、爱好这些方面，祝好
兰陵笑笑生
回复
哈哈哈
工作多年还是技术能力不够，工作年限跟技术不对等，又很焦虑
这个就是我，虽然我很菜，但我从来不认为作为一个测试（属于技术岗）会认为技术无用。
我还是看不惯一些人冷嘲热讽说别人工作那么多年还在研究这，什么时候虚心学习都不晚呐，不知道为什么总有人认为某个年龄就一定该干啥事，过了某个年龄就 “晚了”。
风子
回复
首先我猜测你应该是一个感性的女生，而且没必要看不惯一些人冷嘲热讽这种观点，论坛有不同的观点很正常，每个人的认知和经历都是不一样的，多听到不同的声音是很好的，开拓自己的思维
说会测试，你还在把自己作为一个测试的思维来看，首先测试这个 title 你能干多久，测试技术你能学多久呢
我上边说了：” 如果没有这方面钻研技术的心态（这部分人很少）“，如果不是这部分人，就不要这么执着于技术，我也没说技术不重要，是说不要把一切放在技术，以现在的大环境，投入技术的成本回报率就是很低
我的最优解是：普通人做好本职工作的前提下（不摆烂不卷），积极探索其他的
我最开始也是想将两个 APP 的接口 和 APP 的 UI 自动化放在一个框架里。我是刚开始没多久就放弃了，还是挨个挨个重新创建了项目。
如果楼主有落地，期望能分享出来，参考参考。
44岁的测试小学生
回复
因为我这是应用方，所以具体准确率数据只能给定性的判断，超过 85%（90% 应该也有）。
局限性有，但整体利大于弊：
- 控件搜索由控件树直接定位，变成大模型搜索控件树，定位时间有增加，但常规定位时间就是秒级，再增加影响不大。
- 原本的代码控制点击，变成让大模型通过 function call 完成点击，依然是耗时的增加。
- 多了大模型的处理，多加了一个不稳定的因素，也增加机器成本。
- 大模型多次调用在返回上的不稳定，好比相同问题多次问大模型，给的答案不完全一样，有时同一个控件定位多次会有小概率定位失误，具体数据应用方视角不清楚。
故整体的局限是耗时和机器成本上的增加，但是人力等到较大节约，编写成本是一方面，长期维护成本也是一方面（谁顶得住一两周就变一下的控件 id 和控件树结构）