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

这里一般有 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 分钟以上走各种流程，这时候如果有个脚本可以一键造数据，提升就会很直接明显），然后找你的上级沟通下，了解他的想法吧。

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