作为一名 10 年测试老鸟,新技术的狂热者,最近在思考这个问题。
近 5 年来,分别开发了三大端的自动化测试框架,并在公司进行持续化落地及演进。
基于测试场景越来越多,需要运用的技术越来越多,对于自动化框架代码在做不断的更新。
经过 5 年的技术沉淀,框架逐渐成型,对于项目中自动化测试的需求都能满足,健壮性、复用性、功能性不断提高,但在这些更新上,仅限于独立的分支,代码的结构上、需求的满足上都接近做到了极致,接下来,如何继续提高呢?
这个时候从大的层面来考虑,在测 UI 的时候,对 UI 框架进行更新,测接口的时候,又要对 API 框架进行更新,比如 APP 测试比较少,可能长时间不做维护有些地方都忘记了,做不同测试类型时又要不断切换项目,构建用例,成为了目前的瓶颈问题。
思考几个问题:
目前初步的思路:
经过第一轮技术分析,我认为以上想法都可以实现,我预计耗时一年,对我的自动化工具能力做一次质变。
不知道大家对这个问题有什么更好的见解,可以分享一下。
可以采用自定义 pttest.mart.app/api/pc 标签的形式来维护多端
工作 10 年了说明你也差不多 30 多岁了,说实话这些东西都是比较常规的测试方案和技术栈。如果没实践过可以试试吧。至于我为什么开头说你差不多 30 岁了,因为我想说就算你弄出来了也没啥用。30 还在想技术太晚了这些东西应该在 5 年左右就积累出来的。
流马测试平台除了第二点搞 ai 进行元素定位,其他的都有。三年前就搞完了,对个人提升还是不错的,但是在工作中落地还是需要更多的定制化
我觉得你说的挺多,作为这么多年经验的测试,这些技术基本成为基础项,现在更多的应该是项目协调能力什么的,还有一点,测试这行干不了太久,多思考一些别的出路
你的技术热情和持续改进的思考值得赞赏,但属于南辕北辙,陷入了"技术完美主义"的陷阱
第一,追求大一统框架反而会增加复杂性,就像想把螺丝刀、钳子、焊枪合成一个工具,结果可能哪个都不好用
第二,AI 生成定位看似美好,但实际应用中元素动态变化会导致维护成本不降反升
第三,平台化建设容易陷入功能堆砌,反而偏离测试本质
我建议你最好拉你们产品经理进去讨论,别让技术思维完全主导了需求定义阶段
你们需要有跨角色协同验证,否则投入产出比严重存疑,风险巨大
你这里的槽点太多了,再说都可以写篇水帖了
最后
测试架构的最高境界应该是:在满足业务需求和质量目标的前提下,保持足够的简单、灵活和可维护性,并能快速适应变化
感觉提升是提升,就是感觉平台能干的活自动化都行,并且自动化代码方式还灵活。但是咋说呢 能写个平台 自己写前后端 做一些兼容前端的判断 也是一种能力吧
(1)实施前的考量:这取决于你在公司能调动的资源,包括人力资源、管理协调能力、上下支持力度等等;
(2)预期结果负面效果的处理:以及最重要的是投入的时间与预期产出不符时如何收场;
(3)技术与业务的导向:这一切计划的技术导向与目前公司业务发展是否相匹配,对公司项目是否有短期内可见的提升;
(4)体系搭建后续的维护:另外,假设确实花费了一年时间完成了这些设想,后续的维护又如何调整,能跟得上业务发展吗,还是说只是要这个 KPI?
我先质疑一下 “采用同一套框架” 是不是真的能带来 “框架维护工作量的减少”。从开发者视角看可能维护两套东西很麻烦,但是两套变一套不代表维护工作量除以 2,就像 5 楼鸡哥说的,硬凑在一起会带来更多复杂度,可能排个 bug 的耗时变成了之前的 3 倍?换个角度,从落地视角,已实现的老脚本要怎么支持,是要求用户从老脚本全部切到新脚本吗?那这个事情必然做不成(如果不是公司实践,那个人过过技术瘾无可厚非)
明确可以用 ai 去解决,业界已经有实践。我个人使用下来觉得很不错,对比原先要理解 xpath、控件 id 等概念,直接用自然语言描述/操作元素显然成本更低,还能让更多人参与进来。我是支持用 ai 解决的。
这个真没必要去解决。你先想想这种联合场景多不多,人工测试覆盖需要多少人天成本再考虑。其次这种跨端联合场景,如果是跨服务端到移动端还稍微好一点,而跨 web 端到移动端就更麻烦,中间需要控制的变量/不稳定因素数不胜数。可能最后做是做出来,要不稳定性像屎一样,要不测试脚本配置编写巨麻烦。
问题 4 没看明白,问题大而泛,没理解希望解决什么问题。是成本问题还是效率问题?复杂环境搭建前后端可以用 docker 等成熟技术解决,移动端不了解。【减轻使用代码构建测试用例的场景,如何让更多的人投入自动化测试的实施】,是指类似低代码的思路吗?现在是有不少团队在探索通过和 ai 聊天结合线上流量抓取、代码分析生成一系列接口自动化测试用例这种事情,不知道你是不是想表达这些。
最后,一个大的自动化测试平台,重要的不仅仅是自动化技术,数据看板运营,上下游套件,排查定位方便度等都很重要,可以考虑这些维度的效率提升。
如果不是老板从上往下推的,建议还是不要做这种费力不讨好的事情。技术更迭非常快,哪怕按照你的想法做出来了,你很难保证这东西可以简单的迭代并且在新技术出来的时候你能很好的兼容。多做点项目可能才是你能站稳脚跟的最大助力
不管是测试还是开发,终究都是项目 + 技术维度的复盘和演进,沟通、协调、项目流程、质量体系固然也重要,但在这里我们讨论的主题已经框定了技术的范围。
大佬 这个回复你是怎么做的呢,用到了新工具?想要了解下谢谢! 明确可以用 ai 去解决,业界已经有实践。我个人使用下来觉得很不错,对比原先要理解 xpath、控件 id 等概念,直接用自然语言描述/操作元素显然成本更低,还能让更多人参与进来。我是支持用 ai 解决的
技术都是为项目服务的,新技术更新对于底层架构的影响肯定是有,作为一名效能工具开发者,要结合业务需求、公司流程、现状等不断更新工具能力,抛出这个问题,是因为考虑到在长时间的演进中,需求能满足了,代码优化了,贴合业务实质了,那还有哪些地方可以提高呢?
比如,https://www.53ai.com/news/OpenSourceLLM/2024121816054.html。
MTSC 大会和 QECon 这一类大会应该有相关课题的 ppt,需要自行去搜索一下
我们现在已经抛弃原有的架构了,就是觉得框架扩展麻烦,还有数据库管理用例也繁杂
现在直接让 AI 重写框架,基于业务场景直接生成测试用例。虽然代码可读性不高,但是 AI 可以直接把 UI 自动化、接口自动化这些东西集成到一份测试用例代码里,一个文件就是一个业务场景。调通就可以直接使用了。后续扩展就是基于 AI 生成的框架写一个个业务场景测试用例,调通就行了。
但是我们的做法与你的想法完全是反过来的,是因为我们的产品线不多,业务也没那么繁杂。用 AI 反而解放了我们开发框架的时间,更专注于业务场景自动化的快速实现与部署。
ps:Cursor 这种对于体量不大、自动化不深入的公司是真好用,现在简历上写自己会自动化都不算亮点了,Cursor 写的又好又快。突出点反而是你如何使用这些工具,对业务的理解是否深刻。