小公司的目标是活下去而不是流程化，你的想法都对，但世界就是一个巨大的草台班子，我们大部分的产出实际上都是粑粑，除了满足领导或者特定用户的诉求外一无是处，大公司这套流程玩儿的贼溜，产出也没啥区别。
我觉得你不妨考虑在无法改变现状的前提下变更你的工作方法，比如站在测试角度精炼需求，测试左移提前发现问题，测试主动增加沟通，多了解为什么要这么做，为什么不能这么做，给出自己的意见，主动去收集会议上你觉得重要的点，当你主动去做一些有利团队的事情并且不需要团队内个人花费大量时间时，你的地位自然而然就提升了，团队也会参考你的意见，毕竟大家虽然都是草台班子，但只要正常上线，提前减少 bug，项目顺利上线就相当于给整个团队减负，自然没有人会对你的这些操作恶语相向，但与之相对的就是你的工作量激增，需要你学习的更多，不仅局限于测试，要了解需求背景，了解功能实现，了解系统历史遗留问题，了解系统当前现状，能够说清此种实现可能的后果或收益，你这样做地位提升了，但背锅的可能性也大了。
看个人抉择吧，如果你只是想按规范标准去增加团队的工作量（即使它是正确有益的），也会遭到别人抵触还排斥的，因为你再要求别人增加工作量，尤其你还不是领导。

id > link_text > css >> xpath

嗯，不大范围改动代码的情况下这样处理是最优解了

没法事前删，数据都是按照 ‘功能名称’+ 随机字符串写的，如果根据名称正则匹配的，则不知道是不是以前 case 遗留的数据，有些数据是全局影响的，所以实际上 case 之间会有依赖的

单线程可以，并发的话一旦初始化不就影响其他并发的 case 了么

事前处理是什么意思呢？提前建好么？

好的，谢谢，我再想想怎么做

初始化不了，因为并发的时候会有多个 case 一起建数据，一旦初始化了，其他并发 case 可能受影响；sleep 的话我看好多人都说不要写 sleep，但是真的找不到更好地解决方法啊，唉

刚刚跟负责 DBA 的同事沟通了一下，这个方案给否了，说风险太大，为了自动化测试做这么个功能不值当，他提出可以单独在 SQL 上切个 shard 出来，这个 shard 上给自动化测试专用，但是需要 money，我司扣得一匹，批钱这条路可太难了

测试环境可以这么做，生产环境数据回滚肯定不让操作

想过，但是我没想好怎么告诉 teardown 方法我要删除那条数据，传参给 teardown 么？我不能直接删除最新的一条数据，这样就会给后续的并发埋坑

你需要把下拉框的元素截取出来，也许选项元素接收的不是 click 操作

可惜很多公司招来了自动化测试，到公司还是相当于功能测试