【AI测试技术扫盲+夯拉锐评】Trae和Maestro 这一套AI自动化测试技术真的好用么?

【你真以为这些新出的AI技术就可以让普通新手瞬间变大神了？理性看待这些技术，到底是昙花一现还是未来王道？到底是华而不实还是可靠好用？是拉完了还是夯爆了？身处波涛汹涌的技术浪潮下我们要做的该是稳如老狗，波澜不惊，择优而学】

首先，这个系列是理智的，既不盲目跟风吹嘘，也不恶意批判找茬。本系列文章会用我独特的通俗讲解风格给大家普及关于AI测试领域的各种新技术和知识点，旨在帮助所有还停留在传统测试领域的【测试工程师】【自动化测试工程师】【测试开发】【测试经理】等各工种用最低的学习成本来了解最近让你焦虑的那些AI技术，除了普及这些技术的使用和优点外！本文也会无情揭露这些技术的缺点，希望未来能得到改善和优化！而不是这类理性文章再被举报到下架限流甚至封号！

每篇文章没有顺序之分，都是独立的，各位按喜好选择阅读即可~

有想学习解决各种这些技术缺陷的同学可观看另一个专门解决这些技术问题的系列文章《AI测试技术-难题答案》

或者想学习连贯的实际工作运用打造AI测试平台咨询我的大型测开平台培训课程(之后课程内含所有相关技术和缺点解决方案)。

就说现在有个叫Maestro的工具，能让你不用写代码，就能做app或者网页的自动化测试，你只需要写个清单就可以了（这和几年前出现的关键字驱动原理差不多，但更简单）。然后吧，又出现个字节跳动公司出的编程助手Trae，好家伙，现在你连清单都不用写了，直接告诉AI你要测啥，这一套组合就能给你生成测试脚本，但是能不能运行顺畅，实际用起来有没有坑呢？你就得看我做这个文章了。

别着急，一点点了解。（如果你在公司想推广这一套技术，你得做ppt吧？你就可以参考我下面写的这些了）

背景和痛点：

几年之前开始，公司招聘测试都要求会自动化测试，但咱这行编程普遍不好，好的都去干开发了，没去做开发的，那也早都被各大公司高薪招走当测开专家去了，所以我们小公司就有点难搞，招不到大神。现在简单了，不用招了，自己公司的手工测试人员使用这套技术，代码都不用学，直接就能做自动化测试了。之前什么selenium,playwright,appium的，入门简单越学越难，实际场景各种不稳定，维护成本巨大，现在好了，啥也不用了。

新方案：Maestro

能帮你把你的指令，翻译成电脑能看懂的脚本。写个清单就能实现自动化了。清单主要是yaml格式哈。

- launchApp

- inputText:"账号"

- tapOn:"登录按钮"

- assertVisible:"欢迎页面"

（意思就是打开app，输入账号，点登录，断言是否进入到欢迎页面）

这个跟以前的关键字驱动比的一大好处就是，不用你去特意设置这些关键字的元素定位和各种操作封装，它会以AI的眼光去自动辨别页面找到符合的元素出来并自动生成实时的操作代码，那开发和维护成本基本就么有了。

如果再加上Trae...

那你连清单都不用写了，直接告诉Trae你要测什么，比如说“给我生成测登录页面的功能的Maestro清单”，Trae就能自动给你生成上面那一串yaml清单了，你最多就是扫一眼，看看哪里改一下就完活。

这套技术栈的优点：

门槛低：你不用学代码，甚至不用学selenium等自动化框架
AI提效：自动化测试的开发和维护效率直接起飞
多平台：安卓、苹果、网站，全都一样了，不用单独学各种不同框架

这套技术的缺点：

1. 贵，maestro好像还是按设备数量计费，大概率跑一次花一次钱

2. 网络慢，毕竟服务器在老美，速度快不起来

3. 运行慢，和传统手写的脚本比起来，每次都需要大量AI模型计算，速度必然会慢很多很多，而且多次运行也不会每次都完全一样，一点错不出，不稳定性相对较高。

3. 数据安全，还是那句话，没法本地部署的老板够呛支持你部署

4. 目前支持不了pc桌面软件，比如win32这种

需要未来优化地方：

1. yaml指令灵活度不够，如果你没做过自动化测试，你很难理解手写脚本的灵活度有多高，实际测试中可不是登录页面那么按部就班，各种不稳定、各种曲线实现，各种小问题，各种骚操作，各种复杂逻辑，嵌套循环判断等，你根本没办法用yaml指令表达出来，这得等人家官方以后出越来越多的指令逻辑了。

2. 生态系统不足，简单说你遇到问题可能搜不到解决方案

3. 集成能力不足，你想融合到什么CI/CD了，什么自己的测试平台了，什么线上监控轮询系统了，还需要自己额外去想办法写脚本接口等。

4. 可视化问题，yaml脚本的一些复杂逻辑，只靠人一眼很难读透，未来可以通过排版、注释、高亮颜色等方式更直观一些。

5. 首次运行需要人工反复调整优化提示词，甚至直接修改yaml指令。这是AI的通病。

6. 该技术栈的另一部分trae也可能会产生费用成本、时间、稳定性调试等成本，需要郑重考虑

7. 因为指令到实现操作这一块内的原理完全不可见，类似黑盒子，一旦产生问题，修复和排查都有一定难度，希望日后老美能给优化一下透视一下(虽然感觉不可能...)

8. 压测等大规模并发等场景下，又是网络又是接口又是智能体模型的，链路太长了，导致这种压测场景下估计撑不住，远不如原始的自动化脚本稳定。

9. 测试报告内置的后续应该可以自行定制化，不然无法满足各种团队的需求。

10.元素定位，虽然maestro可以自行定位，但速度和准确度都是不确定的，比如登录按钮，它会先匹配text，然后是id等。当这些都不够定位的时候，还需要人去写好定位代码。但更多情况是它给你匹配个错误的类似的元素上，然后人就去排查bug吧。这里面更多是靠trae去生成指令的时候要用更复杂一点的综合定位指令，不过这个需要人写的提示词就比较费劲了。

需要未来优化地方：

2. 生态系统不足，简单说你遇到问题可能搜不到解决方案

3. 集成能力不足，你想融合到什么CI/CD了，什么自己的测试平台了，什么线上监控轮询系统了，还需要自己额外去想办法写脚本接口等。

4. 可视化问题，yaml脚本的一些复杂逻辑，只靠人一眼很难读透，未来可以通过排版、注释、高亮颜色等方式更直观一些。

5. 首次运行需要人工反复调整优化提示词，甚至直接修改yaml指令。这是AI的通病。

6. 该技术栈的另一部分trae也可能会产生费用成本、时间、稳定性调试等成本，需要郑重考虑

8. 压测等大规模并发等场景下，又是网络又是接口又是智能体模型的，链路太长了，导致这种压测场景下估计撑不住，远不如原始的自动化脚本稳定。

9. 测试报告内置的后续应该可以自行定制化，不然无法满足各种团队的需求。

使用场景：

1. 测试团队整体编程基础薄弱，想快速短期引入自动化和快速迭代的，但有个别能力超强的测开大神能兜底，本地化定制化二开的手子坐镇。

2. 测试场景简单，线性业务流程为主的，逻辑复杂度不高，非特殊化项目的

3. 测试团队对测试工具的长期稳定和生态成熟，未来发展没有过高追求的

4. 团队没有已经成熟的selenium、appium等自动化框架，否则迁移重构成本太高，得不偿失。

5. 能接受对AI工具高度依赖，不怕未来被割韭菜卡脖子的。

粉丝新群专门讨论该系列技术群的二维码：