项目周期，前期为 4 个月，覆盖主流程和相关模块，项目是企业级核心项目，持续成长中。

深圳，工资算是行业垫底了，类似这样的职务起码 30W 起

匿名都是同一个用户，这个不是楼主真实的 ID

你也是 12 位

哪个城市 ，24W 不低啊，比我们这边高很多了

确定去外包公司后岗位地是一直离家近的? 因为有些外包项目没了被调到其他项目,距离就远了也有呢,外包公司干活地不定的.

看作者是 社区第 12 位 ，会员，技术应该不是问题，估计主要还是领导不认可这件事情上。讲真，做技术这块，领导的行政资源支持太重要了，领导愿意作为他的主要事务来完成，推动力相当高。如果没有资源倾斜，级别又不够，是无法推动到其他项目或者整个质量部门的。

这个项目的周期是多少?维护的是产品还是单个项目

点点点，肯定是需要得，但是例如主流程回归，和模块回归，就可以进行替代呀，这里节省了时间，这个时间省下来了，无论干什么不了，多休息下也好呀，特别是业务量大得时候，更能够体现，同时这些用例可以运用在线上监控，数据构造当中呀。这个才是我做自动化得目的，可能前期投入高点，后面重复运用就赚了。

不是很理解你的意思。

我说了呀，前期是真的全力支持来做这个东西呀，并且我制定了项目的排期，来完成呀。

问题出现就是，leader 不在的中空时间段，leader 没有和我持续走下去，不经历过程，直接面对结果，因为确实沟通，肯定是有分歧呀，现在看来这也很正常。

至于回来推翻了，我觉得#6 楼分析的有道理，有很多方面的原因。

你说我作，我是不懂了，我认认真真做项目，解放业务同学的点点点重复，这个就是我做自动化的目的呀，我不是错也不是作，是有一些东西，不是我自己能够把握住的。

我能做的事情就是对项目负责，对业务负责，从前期的志同道合到后来的分道扬镳，我也是不舍得，做了这么多毕竟是自己得心血。不到万不得已，谁又愿意呢。

敢问大佬，我真的是作吗？

业务同学也亲自感受了自动化的好处，不用重复点点点了嘛 ------------------------ 这个不行的吧，总归还是需要的，只是减少一部分

你这完全是自己作的。从你的描述来看，你推进自动化这件事，完全是你自己一个人搞的，但凡你和你的直属领导有过仔细的沟通，或者和再上一级的开发 Leader 有过仔细的沟通都不会是现在的效果。沟通过后，要么就是不做，要么就会给你一定的资源去做，而不会像现在这样，做了一部分了，上级回来直接给你推翻。

曾经做了一套 robotium 自动化脚本，刚完成才用了几遍（效果不太好，同样代码运行多次有一定几率运行失败），公司宣布开发新产品代替该产品了，导致整套还没有成长，就扼杀在摇篮中了。
那时很纠结，思考以下问题：
1.自动化是什么？为什么要进行自动化？
2.这套脚本能产生多大的效益？
3.目前的投入产出比怎样？
4.自己学到什么

最后 想到公司是有支付薪水让我在上班时间研究开发自动化脚本，瞬间觉得自己赚了，不但有了一次很好的练手机会，而且学习到不少的东西，我有信心在下一次做自动化脚本，我走的弯路会少些。

至于之后是走是留，看看后续的安排与自己的职业规划是否相符合了

怎么说呢，leader 和 leader 的差距还是比较大的吧，我是按照预期的理解来做自动化的提升效率，讲也讲过了，心累。遇到强势的 leader 想说服怕也不是一件容易的事情吧。因为 leader 的主观意见，是很难被推翻的。----不懂技术没办法呀！

更重要的是需要统一理念吧，分歧点太大，合作也很困难。

当前来说，我期望做技术推进业务的路线，leader 是希望业务堆切人力来完成，技术啥的暂时一边去。点点点才能发现 bug。

更多的是当前时机不对吧，也应该说业务量还不够大，见解也还不够深刻，没有在合适的时机做这个事情。

1、管理好你领导的预期，自动化这事显然你做失败了
2、你认为争取的东西就应该有能力说服你的领导，如果无法睡服，说明你也不确定，领导的确没义务拿资源来给你试错……

人和人的不同点，估计就是在这里，其实在你的理解已经知道自动化的目的是用来提升效率，但是在传统的测试 leader 眼中，只会关注 bug 的产出，我已经说明，我的自动化已经在团队内部平稳运行主流程和重点模块的回归，因为是逻辑回归，业务同学也亲自感受了自动化的好处，不用重复点点点了嘛，能够找到 bug 是附带属性呀。

我说出了我的想法需要复制经验到其他项目中来更大的体现效率，而 leader 就认为你根本没有发现 bug，我投入这么多没必要，让业务同学不用省那么点时间，多加班也可以获得同样的效果 ---- 人肉战术。

就次进入了我现在的境地，leader 的意思很明显，就是自动化你自己去搞，bug 率也要有产出，就是日常工作要做，自动化你可以加班做，如果你的自动化可以发现很多 bug 了，又可以节省时间，那么就用你的方案，注意哟，leader 是不会提高任何资源的哟，口头配合。----这样的话我还不如做一条咸鱼！

我觉得五六年应该是有点水分的

不会，我觉得你想的有点偏激了，或者是沟通哪儿出问题了，作为 leader 不至于不希望团队往好的方向发展，我觉得是你没说服他，举个简单的例子，实际的应用场景是不是更能说法他呢
假设一个版本的回归周期是 1 周左右，你在星期三之前测试的内容在后面 2 天一般是不会再手动去跑的，假设有紧急问题开发提交了文件导致了之前已测试模块出了问题，那么是不是就 cover 不到，这种时候自动化是不是就有效果了呢。
如果你做的自动化连主要流程和主要模块的功能都不能保障的话，那么我觉得你得想想自己的问题

最后一句话很有感触，测试工作单靠 bug 数量来量化产出也不合适，但你说不看 bug 数量又没有别的太多东西能看。自动化？脚本？覆盖率？没有直观成果感觉不好体现。

现在五六年的测试工程师，我去面他们，只要求会点编程语言、懂点网络协议、会用 linux、看得懂技术文档。遇到问题别老问我，能自己搜索解决。但实际上能达到第一点能写点代码的就已经是来面试的人里面算好的了……其实我看很多五六年的人和一两年没分别，招点有灵性的实习生都能在半年内超越他们。

偏偏还遇上不懂技术的领导，就算有产出，但是不是领导想要的也是凉凉哦....

这个局面怕是很难了。

样样都会，样样稀松。。需要找一个专精方向。

我觉得这就陷入了一个比较常见的死循环了，没有被认可的成果，就没有资源，没有资源就很难做出成果，这不管啥岗位都一样
你得评估下当前的公司成长和环境是否符合自己预期，如果符合，那么花点时间把东西做出来没什么不好，有产出肯定就会有资源了。主要蛋疼的是测试这鸟岗位不出问题就是没产出，出了问题就是大锅，怎么体现自己产出呢

悲哀的就是，领导其实根本不懂自动化的概念，还是传统思维，已经沟通过了，我认为自动化的目的还是覆盖率和效率，但是领导偏执的希望你去解决发现 bug 率，最大的分歧点就是这里，我感觉潜在含义是让我走了。