django 开箱即用，前端 vue 拿模板修修改改，不是走纯开发路线差不多了

产出结果就是能拿来水，并且 AI 现在真的赚钱的点就是卖课，深入研究除非从业人员不然没意义。

你做的事情基本是大厂才需要的，小作坊要执行要自动化，大厂你学历绝对被卡的死死的，因为人太多了。

狼多肉少不知道你是以什么样的心情转行的，一般转行就彻底转掉了。

工作 2,3 年的小坤子们时无法体会到的，估计还在死背八股文和刷 leetcode

看你的描述感觉 20k 应该不难，广州现在这么拉了吗

1. 我们的人员配置是 4 个常驻 1 个不稳定就是 5 个人。我是主要负责自动化等工具。其他人功能：自动化基本在 8:2，所以不可能强求他们自动化产出有多高。
2. 我这边是需求和自动化并行进行的，其他人基本是自动化在需求完成之后，这就导致了其他人员的自动化产出效率不足。项目基本也是 2-3 天一个测试需求，很多时候还是 2-3 天测 2 个需求。
3. 项目配置，基本 1 个人一条线，我这边是游走，所以主要负责自动化的转化。
4. 你说的合理不合理问题这个就很玄了测开比基本是 1:10 以上。 5.6 合并说吧，数据驱动是肯定的根据场景进行参数化，测试用例是通过 pytest 框架编写 python 代码的。毕竟代码的继承复用和维护是平台比不了的速度就不是一个量级的只是要求会高点。

会持续迭代的需求都会转自动化，不持续迭代的末端业务就不写。用例多的地方主要是功能庞大所以复用了，不然一个小功能写 34 十条自动化测试用例的写一年都写不了那么多。另外你说的工作很多年还写自动化，单纯搭框架都 25 年了会缺框架吗？你不写测试用例工具上的优化能优化多少总会到头的。完全的测开工程师都是大厂并且岗位极少，我是没认识几个只写框架不写用例了。说白了还是个体力活

1 年多时间 8000 多了

按功能或者按需求等类型存，只是一个分组分类的过程。关键的当你的测试用例体量增长到 1000,2000....之后你的维护新增速度时候还是能保持 100 用例阶段的维护速度和新增速度，其中最关键的因素就是当你的用例越多你用例受到需求迭代的影响面就越广。这就涉及到你工程的数据维护（静态的动态的），工程的结构设计。以及出现异常情况比如环境数据破坏了恢复到正常状态等等情况后你的维护效率会不会受到影响。