万事开头难，然后中间难，最后结尾难 开个玩笑了哈。
一般技术是要为业务服务的，自动化也是，所以你做这个项目或者说事情的时候就要好好考虑，为什么要做。现在是讲究效益的时代，都会考虑投入产出比 (你如果是自已做着玩玩就无所谓了)。从你的描述来看是为了解决提升自身技能的问题，这确实是个驱动方向，但这个作用范围有点窄，这样的话很容易陷入孤军作战的境地。
另外，目前市面上有很多自动化工具，鳞次栉比，不胜枚举。但是总的来说适合自己的才是最好的。一般都是要看目前公司项目业务的情况及成员水平。可以看看我写的这个，基于在 pytest 编写的一款自动化工具。支持 api 及 ui 自动化。希望可以给你带来一些启发。

内部转岗的成本最小,如果你刚好有做产品的想法,这会是一个不错的机会。但是从另一方面来看这也是给你增加了工作量，是机遇也是挑战。

你这个场景看起来有点冗余了，自动化的一个目的之一就是提效，如果后台框架本身是支持配置化参数校验的话，你就没必要一个参数一个参数的验证有效性，更多的应该把精力放在业务逻辑和整体流程治理上，边角的异常场景虽然也可以做，但从投入产出比上看收效不大，而且写了这种用例后期的维护工作是不是也要同样的有付出。所以建议你先把流程建立，把 0 到 1 搭建完成。

哈哈,你的内容看起来更丰富,关键看推广落地吧

应用场景不一样哈,编写的脚本可以放在服务器执行,postman 的 mock 服务只能本地调用,别人用不了吧 :(

让 GPT 帮你

登录页面有个演示账号,可以体验 4.0 的功能哈

现在还有这个问题嘛,我没看到有异常登录的报错呢

你再试试呢,是有一个 bug,我已经连夜起床修复了

你这个验证码还是比较清晰，没有多余的干扰字符，ddddocr 这个库应该可以 hold 住，当然最简单的方式还是走挡板验证，即后台写死一个万能验证码。

报错提示很明显哦，地址已被使用你的 9100 端口是不是被其他程序占用了，换个端口试试