30 而立。爱发火算性格缺陷吧。平时其实也容易暴躁。只不过一般我都能压下去。 但是面临高压的时候就控制不住自己

我尽量多更更

其实没必要总结一个职位的技能树，因为每个行业的测试开发应用的技能是不一样的。 我们也只是总结出自己所处环境的技能树。 代表不了所有人

有一句话叫：广度是深度的副产品。 我们都为此而努力吧

主要就看你要外派去的公司是什么，项目是什么。 工作内容是什么。

恩，项目组很重要。 碰见好的项目就能学到东西。

外包公司么？ 现在很少有公司还区分执行和写用例的人了

可以当跳板吧。 我是从外包跳出去的。 那时候我啥也不会， 没有像样的甲方公司要。 就去了外包。 后来才跳槽去了 58，后来又是现在的第四范式

不同的场景都有一些经典网络结构。 上网查查就好了。

你可以看一下我深度学习的第十三篇文章。 专门讲机器学习场景测试的。希望能对你有帮助

我了个去。。。。我是打算存草稿的。。。。这是手滑点了发布了么。。。 我就是想保存几个之后要看的文章

是的

找到能让自己干的开心的事情的同时还把钱赚了就好。 其他的都随意吧。 不论开发还是测试，干好了都是赢家。 重要的是在艰难的岁月里，你是否有毅力，扛得住压力坚持下去，而不是遇到困难就退缩不前。 人生中总有一些坎， 抗过去了就海阔天空， 挨不过去就原地踏步

发帖子的时候，上传任何图片都会自动被打上水印的。我控制不了

每次你们夸我，我都特心虚。

行业间互相鄙视算是挺常见的吧。 我都习惯了。 老在那技术约架，可能是太闲了。

恩恩，一起加油哈，这个行业里的人越多，行业才能蓬勃发展~~ 以后咱们跳槽加薪也容易 哈哈哈

我很负责任的说。。。。这可能是个 bug。。。

互联网前后的变化

楼主开篇也提到了在进入互联网前后经历的瀑布式和敏捷式的开发模式。 我也是工作了 7 年半的人了，经历过楼主描述的过程。 先讲述一段关于小故事吧。 小步快跑，试错迭代的思想在上个世纪漫威的崛起中就已经有成熟的应用了 (我是漫威迷 )，斯坦李可不是一口气直接创造了漫威宇宙。而是在一开始尝试性的创建了有性格缺陷的神奇四侠。在斯坦李的笔下，石头人敏感易怒、霹雳火轻佻自负……超级英雄终于不再是高高在上的神话故事，而是一群有血有肉的普通人。(不同于 DC 的超人蝙蝠侠神奇女侠，他们几乎是完美的) 这种设定迅速激起了年轻人的共鸣，《神奇四侠》大受欢迎，拯救了处于垂死边缘的漫威。随后，斯坦李用这种更加贴近人性的配方，开始用流水线大规模地生产超级英雄。斯坦李一个超级英雄一个超级英雄的试错，一点点找到大众更喜欢的角色。 然后 1940 年的一期漫画，海王和霹雳火在漫画 pk 了起来，漫威的超级英雄第一次有了交集，之后是美队和霹雳火和那摩等集结打纳粹。再然后漫威宇宙一发不可收拾，原著中的内战涉及的超级英雄之多令人咂舌。漫威宇宙 2000 多位超级英雄就是这么被创造出来的。 跟大家说漫威的故事就是想说明这个模式。这种小步快跑，试错迭代的思想被充分的利用在了互联网里。 因为它能更快，更有效率的找到用户更需要什么，如果漫威一开始就设计一个恢弘庞大的漫威宇宙，那它当初早就被 DC 干死了。 尤其是在互联网中竞争对手无处不在，抢时间抢用户抢地盘。慢一步，步步慢。 当初阿里云诞生之初把评估的工作排期直接压缩了 2 倍，誓师大会上所有人喝酒宣誓，3 月前必须上线。 所有杭州团队的人直接飞北京，光差旅费就花了百万以上，没需求文档没设计文档什么都没有，沟通全靠吼。就是要快，当初的目的就是赶在腾讯云之前上线。如果慢了，很可能就没有现在阿里云的传奇了。 所以在这种商业背景下，传统软件的研发模式必然是淘汰的结局。 这是互联网对传统研发模式的打击。 同时互联网对传统软件公司也造成了一种降维打击。即便是我们这种 TO B 业务的公司，也或多或少的走这种模式。因为你慢了，你就死了。

所以在这种背景下，像以前一样那么长周期的测试活动肯定是不会存在的了。TO B 企业还好一些，互联网就完全是快节奏。 所以才需要大量的自动化来缩短测试周期，也许这时候的测试是不完全的，但这时候的测试是能满足用户需要的。测试人员需要转换一种思维，就是我们的目的是做一个能满足用户需求的产品，而不是一个完美的产品。 经常能看到一些开发吐槽，比如都什么时候了还在这跟我提这些无关痛痒的 bug。这就是测试人员还活在自己世界中的表现，也是没有产品意识的表现。 一个成功的技术团队 (包括产品，研发，测试，设计等) 要有一个共同的目的，在这个共同的目标下，所有人都要互相妥协。 最后的产出，就是各方为了这个目的互相妥协出来的。 所以像以前那样，质量部门产品部门研发部门互相独立的团队很难存活下去。 现在已不是单打独斗的时代。 相比测试思维，我们更加需要团队思维，整体思维和产品思维。

关于测试人员规范流程的事

根据之前说的，测试人员要跳出纯测试的框框来，从整个团队考虑。 测试人员介入流程规范，约束开发这个事其实没毛病。 有能力就可以做。 我的测试 manager 现在兼职管着 PMO 的事，管着 TS(技术支持) 的团队。而我现在是 CICD 的 owner，老大了我一帮子比我技术好的研发人员做为我的资源让我搞。 产品上，所有关于 k8s 的需求和设计由我组织，甚至好多需求是我本人提的。 运维上，一些 k8s 和 hadoop 集群也是我和我同事在维护。 你看我们的工作涉及到了多少非测试的事？ 不止是 QA，我们的研发多少跨界客串一把产品人员的， 客串一把交付人员的。 我觉得一个好的团队是不会给团队划分固定角色的，谁有能力做，谁有时间做，谁愿意去做，那谁就可以去做。 每个人都有自己擅长的领域。 那在自己擅长的领域里跨一把界，是对团队有好处的。 比如我们这种技术架构这么复杂的产品， 有些模块，让研发人员去做产品的角色就是比产品人员自己搞来的高效，正确。

关于测试人员背锅

关于线上出问题了以后让 QA 背锅，这个是要分情况的，要 case by case 的分析，但这种无脑背锅的事倒是存在的，一个不成熟的团队会有这种不成熟的思维。 质量是所有人的，不是 QA 的，有时候该怼就怼。 做 QA 要是还怕得罪人，还玩个蛋了。

关于测试人员的技术

这个楼主去面试的时候是碰到不太好的团队了。 做到不懂代码的人员也可用的这种思维是无奈之举，一定是团队中不会写代码的人太多了。 没办法而为之的。 但基本上这种关键字驱动框架我就没见过有人做好的。 最后规模大了都是维护噩梦。 只能测测业务层，而且是小规模的。 case 多了能累死人。 一个测试人员追求技术是没毛病的。

至于开发人员吐槽你一个测试跟我们聊什么技术。 那还是因为测试的技术没有给他们带来价值，不信你来我们公司看看，会有人吐槽测试的技术么？ 技术不在于有多高明，而是它能为你带来多少价值。 当你的技术能力，产品能力，团队能力达到了一个点的时候，就会呈现出爆发的姿态。

关于思维

我一直建议测试人员跳出测试活动这个小框框来，往整体上看，往产品上看，往团队上看。 思维跳出来以后就会发现，你可以为了产品质量做很多很多事。 不要为自己设限。