猎头公司，以及市面上的培训机构（实在不行就博为峰吧，哈哈哈哈哈哈），反正都说要退休了，就不嫌弃了

35 岁，半管理半技术。
考虑转纯管理，转产品，或者退休做讲师。

年薪这东西，你总要说城市吧，不同城市的标准差的非常多。
在一线城市，35 岁左右的话，年薪 25w 也不少见；如果真没有达到，也未必混不下去。

工作还是要图一个开心，不管是工作内容，还是回报本身，有一样让你开心就行了。
人一天的活跃时间大约 16 个小时，IT 行业普遍工作时间 10 小时，这占人生的一大半了，这段时间不开心，你的人生怎么开心的起来？

手工测试 -》手动使用扫帚扫地
自动化测试 -》使用扫地机器人，其中扫地的方式和逻辑需要自己编程
测试开发 -》做扫地机器人，甚至做铺地板，洒水，涂蜡，烘干等机器人

我理解了，不过有几点要说一下：
1 一般只在一组自动化测试之前，进行一次初始化数据库动作。所以这次自动化过程中，每一个 case（需要中间数据的），都会被准备一个数据；换句话来说，case 1 和 2，即使需要的数据完全相同，也要准备两份，因为这个中间数据用完就没有了，再用要重新生成。（这也是为什么 dump 数据库不是好的方案）

2 看你说的类似于手工测试要用？手工测试要用的话，也是建议不要用 dump 数据库的办法，还是走正常的准备。只不过，你可以把数据准备的过程脚本化掉，然后教会手工的同学怎么执行。这样他们在手动跑 case 前，可以用自动过程准备数据，其实很方便。

理论上不需要独立，你有这个疑问是因为自动化测试思路有问题

以单个模型的增删改查为例，创建时接口必须返回 id，之后你的删改查都是基于该 id 的，所以不会跟其他任何数据相互干扰；
如果你要测的是列表接口，你不能保证在准备数据过程中，其他手工动作对你的干扰。你就要准备足量的数据，而降低验证阈值。例如，你制造一条数据，验证这个数据在列表 top 100 中返回（而不能是 top 1）。

确实有两种实现方案，如你所说。
第一种，抽象 1-7 步的步骤，然后再测试第 8 步的时候，调用 1-7 步。
第二种，mock 出 1-7 步的中间数据，而后直接进行第 8 步的测试。

第一种显然是更合理的，因为测试应该尽量不 mock，你可能漏掉 1-7 步的测试能发现的 bug。如果这种做法从前端太慢，或者前端操作不稳定容易出错，合理的做法应该是采用接口自动化。

dump 数据库的方案中，你的思路很奇怪，或者是我没有理解你的逻辑。
理论上应该是找一个干净的数据库，然后你进行 1-7 步的过程，然后 dump 数据库，该数据库为标准数据准备的数据库；这样你甚至可以为每个测试用例的数据准备，定下固定的业务 id。我没理解这个和并发有什么关系，以及为什么要研发给接口。