第二种的话，尝鲜可以，要做到收益会比较难。

这里一般有 2 种做法：

• 第一种就是我前面提到的，生成自动化代码。但生成后的代码还需要人去调试修正，且还是得要有代码基础的。用 trae 之类的 AI 代码编辑器就可以做。

• 第二种是 AI 自主执行，相当于基于你给的一句话或一条用例，自行去尝试执行你的用例，并进行校验。这个今年 MTSC 有一些相关议题分享，需要做 3 个子 agent。
  一个基于应用地图（类似于知识库）做路径规划，把你的 新建工单 转换为 到 xx 页面点击 xx 按钮 ；
  一个做动作执行，操作浏览器/app，识别界面内容，找到要操作的控件进行操作。这块也许有现成的 MCP 工具可以直接使用。
  一个做实时纠正，发现找不到想要操作的控件时，自行想招去解决

个人建议，可以尝试第二种，做个 demo 让老板看看，交个差还是可以的。
但要提效，这个会很难，一个是不稳定（可能第一次跑成功，第二次失败，第三次又成功；而且可能因为自行扩展的检查点不够细致，可能有些 bug 会被放过）；一个是跑得慢（截图、AI 思考都需要时间，比人执行要慢不少）；还有一个是成本高（token 消耗如流水）。至少以现阶段的 AI 能力，个人觉得用外包会比用这个更香。

从一般的 AI 结合测试且产出会比较有保障的角度，有几个方向：
1、AI 基于需求文档生成测试用例
2、AI 基于测试用例，生成自动化测试代码

考虑到你们组内没代码基础，建议可以先尝试第一个，做 demo 尝试啥的比较容易，纯调整提示词就可以，你们也比较好辨别结果是否合适。不过要提高准确率啥的，得弄 RAG，并规范需求文档格式，否则 AI 很容易幻觉或者看不懂需求内容。

不知道你这个 “工具” 是用来干啥的，建议先和领导确认清楚？领导不一定知道具体工具怎么做，但应该至少能说明为啥要做这个工具。

有几个可能的方向，供参考：

1. 解决没有联动 app 打包后自动执行，研发没感觉。那用 jenkins 就好了，app 打包后触发脚本运行，并运行结束后自动发报告。界面想要好看，也可以自己弄个前端界面包一下，背后调用 jenkins api 来触发任务。

2. 解决现在用例数量增加后，每个用例都是面条代码难以维护问题。那可以看看 page object，代码里做一下封装。（但也看 roi，封装不好可能比面条代码还难维护）

3. 解决想让大部分测试人员去写自动化，但他们不会写代码的问题。这个工作量就比较大了，建议直接调研比较流行的开源 app 自动化平台，选一个内部落地和二次开发好了。

相比于自动生成，我觉着自动分析自动化失败原因，并能自行提交 MR 进行维护优化，这个用处更大。

自动化长期跑起来，维护和解决误报，这个才是日常投入最多的，尤其是 UI 自动化。

看着你这个报错不像是 python 自身报错，像是服务器 response 本身报错

你先抓个包，看看请求服务器的参数和你现在用脚本请求的参数，格式和内容是否一致？

打回第二回后，把用例也给研发，让研发自己自测好没问题再给你验证吧。

他们研发是照搬老系统的逻辑，一点业务逻辑都没改变，而且研发也不熟悉系统里面的业务逻辑，show case 是不可能的

这个听着风险就很高了。重构但又不了解业务逻辑，这是怎么敢去做重构的？不同语言之间语法有差异，且有些语言特性可能另一个语言没有，得 workaround 处理，这种谁敢保证 “一点业务逻辑都没改变”？

PS：试着问了下豆包 把一个程序从使用.net重构成使用 java spring boot ，会有什么坑，需要怎么防范？，看着可能存在的坑还不少：

分析：将程序从.NET 重构成 Java Spring Boot 时，会面临技术栈差异、架构适配、数据处理等多方面的 “坑”，需针对性防范。主要包括语言特性差异导致的逻辑实现问题、框架生态不同引发的集成适配难题、数据访问层转换中的兼容性问题、部署与运维环境的迁移挑战等。
答案：

语言特性差异坑
坑点：C# 的委托、事件、LINQ 等特性在 Java 中无直接对应，如 LINQ 的链式查询需用 Stream API 替代，且语法和功能有差异。
防范：前期梳理.NET 特有语法和类库的使用场景，用 Java 等效方案替换，如用 Google Guava 库补充集合操作能力，通过单元测试验证逻辑一致性。

框架生态适配坑
坑点：.NET 的ASP.NET MVC 与 Spring Boot 的 MVC 架构虽相似，但依赖注入、拦截器、过滤器等实现方式不同；第三方组件（如 ORM 框架）需替换，如 Entity Framework 换成 MyBatis 或 JPA。
防范：深入对比两者框架组件的生命周期和配置方式，逐步替换组件，例如用 Spring 的@Autowired替代.NET 的依赖注入，确保权限控制、事务管理等核心功能逻辑一致。

数据访问层转换坑
坑点：SQL Server 特有的 T-SQL 语法（如TOP、OUTPUT）在 MySQL 等 Java 常用数据库中不兼容；存储过程迁移复杂。
防范：梳理数据库脚本，替换数据库特有语法为标准 SQL，用 MyBatis 的动态 SQL 替代复杂存储过程，通过数据库迁移工具（如 Flyway）管理版本，确保数据迁移后完整性。

部署与运维坑
坑点：.NET 依赖 IIS 部署，Spring Boot 常用 Docker 或 Jar 包部署，环境变量、配置文件（如 appsettings.json vs application.yml）处理方式不同。
防范：重构配置中心，统一用 Spring Cloud Config 或 Nacos 管理配置，通过 Docker 容器化保证部署环境一致性，编写部署脚本自动化迁移流程。

性能与并发坑
坑点：两者线程模型、内存管理机制不同，如.NET 的异步async/await与 Java 的 CompletableFuture 实现逻辑有差异，可能导致性能问题。
防范：对高并发模块进行压力测试，用 Java 并发工具（如线程池、CountDownLatch）优化异步逻辑，借助 JProfiler 等工具排查内存泄漏和线程阻塞问题。
总之，需通过充分的技术调研、分模块逐步迁移、完善的测试覆盖（单元测试、集成测试、性能测试）来防范风险，确保重构后系统功能和性能稳定。

1、你如果要离职了，你会主动进行挖掘性的输出，进行交接吗？

挖掘性说不上，但总结文档或者一些代码交接（说明下各个模块作用啥的，对方有个印象）还是会做的。如稀饭所说，还是要保持好自己的口碑，这样以后前同事有好机会还会想起你。维护好人脉还是挺重要的。

2、你会主动对接替者进行交接吗？还是被动等着他来问

我会主动找，反正也比较闲，交接好可以减少交接后找我的次数。被交接的人一般都比较忙，而且不熟悉，完全被动的话，交接效果会不大好，最后就变成离职后还得来经常问，背后可能还会在公司里吐槽我没做好交接，给别人留下差印象，没必要。

3、你不会担心由于交接有问题，导致后续给你打电话吗？

这个没啥好担心的，有就解答就好了，一般也不会很久。

恭喜恭喜！

建议先准备一些简单的小的点的思路（如楼上说的优化流程、增加基建等，最好是你自己测试时就觉得是个需要优化的痛点的，这样优化后效果有保障；举个例子，某个流程的测试，每次造数据都要 10 分钟以上走各种流程，这时候如果有个脚本可以一键造数据，提升就会很直接明显），然后找你的上级沟通下，了解他的想法吧。

上级提升你上来，一般内心都会有一些希望你去做的想法的。要获得上级认可，首先要了解上级的想法，确保方向不要走歪。

不好意思，我这边已经 5 年多没有碰过这个了，估计没法回答你这个问题。

建议你到官方的沟通群里反馈下？

PS：建议把相关报错截图信息也附上，光一个 “回放失败”，信息有点少。

工作内容除了日常的测试，还需要兼顾一定的测试管理，项目经理传达的意思是，之前的管理主要都是做一些资源的分配，想让通过推动例会复盘的形式，实现测试工作的提质和提效

这个目的，感觉怪怪的。一般复盘会应该是有明确的问题，要复盘根因，确认改进项，避免问题再次发生才开的，第一次听复盘会目的是 “实现测试工作的提质和提效”

我理解这个是不是应该是一个内部的定期例会，用于一起去 review 看整个 QA 的目标（OKR 或 KPI）的进度和困难，以及不同的组之间做一些信息同步和交流分享？

额，你这个不算单元测试吧。如果里面有一些上下游函数需要 mock 返回，你都不在同一个进程里，做不了，那你异常处理的代码会很难覆盖，行覆盖率会上不去。

建议花点时间去学下 java 和 javascript 的单元测试框架，比你这么折腾简单，而且现在有挺多能生成单元测试的 AI 工具，上手不难。

| 是否需要将 yaml 格式的用例，转换成页面组件的形式进行编写呢？

建议自己权衡吧。做成页面组件，好处是可以折叠省一些空间，以及对于小白友好，缺点是可能编写和查看效率降低（比如要知道某一步的参数，还得多展开一下）。

| 当前 yaml 内容步骤过多的时候，自己看的都有些费劲。不知道有什么好方法去改进这块。

做封装呀。参照 Page Object 把页面和页面上的常用操作封装一下，这样应该你的步骤应该就少很多了。

个人能想到的，仅供参考

1、换幻觉少一些的模型，比如最新出的 GPT5
2、调用多个模型，只取多个模型都一致的结果（基本不大会多个模型在同一个位置有一样的幻觉）
3、调整 prompt 及模型参数，减少模型自行发挥空间

如果是我，我会先问项目落地情况、实际收益、遇到的困难和解决方法，后面再进一步去深挖实现原理等细节。测开不像开发，落地会有产品 + 运营等负责，测开基本要自己负责落地，完成整体闭环的。

另外，这里的量化指标，说实话，太工整了，很明显不是统计出来，而是自己拍脑袋估算出来的。

34+

97 年，如果还想拼，能拼，建议选能走得更远的 B。
AI 目前在改变整个行业，甚至产品、业务本身都在适配改造，并且在一些业务上已经证明了其价值。虽然有一些吹的成分，但很多领域已经实打实地产生收益，甚至离不开了。

想延长职业生涯，走得更远，还是往这个方向靠吧。

打羽毛球，自驾游，打打游戏，补下觉

想问下，所以崩溃率大概是多高？百分之多少？

老功能不常用，所以没回归，但灰度或全量时用户会遇到，而且遇到得还不少导致你们崩溃率高。“不常用” 和 “崩溃率高” 两个有点矛盾。

没有移动办公的需求，就 mini 吧。同样价格 Mini 配置更高。

我很久以前第一个 mac 买的官翻版 air，主要是当年还有些热情带着 air 去图书馆啥的折腾技术，顺便骑自行车到处走走，在家里干扰会比较多。如果你没有类似情况，可以直接 mini。

mini 你还得算上显示器、键盘鼠标等配件的费用，air 就简单很多，还能带出去随时用。财力 ok 的话，建议 air。

我是

倒没有特别去挑选对比，只是这个最简单方便，题目也多。

个人经验，一般会逐级分类：

先按责任方分，主责事故（自己系统导致的问题）、非主责事故（其他系统出问题，连带影响到。比如机房网络挂了）
然后主责里面再分，具体的类型，比如代码问题、配置问题、数据问题、人为操作问题
根据具体类型，可以再进一步细分，比如代码问题，再细分为实现遗漏、实现不正确、健壮性不足等

一般统计分析，分到第二层就差不多了，到达这一层就足够去定一些比较通用的改进项，预防高频发生的事故。

我想到的也是截图对比。这块比较容易做自动化

如果不熟悉写对应的代码，可以用 cursor 辅助下