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

可以当跳板吧。 我是从外包跳出去的。 那时候我啥也不会， 没有像样的甲方公司要。 就去了外包。 后来才跳槽去了 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 多了能累死人。 一个测试人员追求技术是没毛病的。

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

关于思维

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

你真把我当算法工程师了 。

对了，算子的测试一般不是要高并发的~~ 一般不会这么测的。 就是单个算子在环境里跑。 这样能测出这个算子的 baseline

基本上机器学习的所有测试类型都跟数据有关。 所以做性能测试最关注的是数据的构造。 不同的模型对不同的数据有着不同的性能表现。 最简单例子比如你可以把高维特征 (海量离散特征，比如 1 亿维) 喂给 LR 算法也没什么问题。但是喂给 GBDT 几百维都能慢的像蜗牛一样，几万维特征给 GBDT 能把集群撑爆了。 所以要构建不同数据规模，数据分布，数据类型的数据。 同时算子运行的参数也很重要。 最常见的影响参数是 batch size，learning rate， 训练轮数等。

所以我一直在说这些根咱们讨论的有什么关系么？这个帖子在讨论的，还有我在说的一直都是有很多地方测试很有技术含量。有很多测试类型值得去研究，我列举了很多会用到的技术点。但你选择忽视所有你不想听的。一直反复的说测试 low 测试没技术测试在骗人。如果你不是来讨论的，只是单方面的在诋毁一个职业。 那咱们没必要聊下去了

这个例子跟讨论的主题有什么关系么？跟测试有没有技术含量有关系么？跟自动化测试有什么关系么？

我司成立三年多，只是个 300 多人的小厂子，不是大厂不是独角兽，docker 技术在 QA 团队刚组建，只有 2 人的时候我就在学习使用了，那时候公司只有 30 人。 我提到的这些，只要是这个方向的公司，都会涉及到，跟公司规模没关系。 你指的小公司会用的可能性为 0 是什么概念？ 我司是小公司，我司 QA 起码一半很熟悉 docker，另一半多少也会用点。 我认识的其他的公司的， 不管是 bat，还是快手头条美团这个级别的，还是专门做容器的公司比如七牛，灵雀，众人，甚至是像我司这种小厂。会用 docker 的也不少。

会和使用是两码事，那你为什么觉得我们只是会个皮毛呢？ 我们 10 个人的小 team 里有 3 个是能自己搭建 k8s 集群并维护并开发应用的？我们虽不敢说精通，但我们起码都是日常跟 k8s 打交道的。

你说自动化和功能测试的工资差不了多少，那给我举几个纯功能到 30k 以上的例子。 你知道我司多少 QA 在 30k 以上么？你知道我上面列举的这些公司中有多少 QA 30k 以上么 (有些公司甚至不可以用月薪来衡量了)？ 甚至 40 的我都见过。 你觉得纯功能测试能拿这个数么？

我承认我说的这些都是集中在北上广深的精英群体。但这个群体已经不是个小数目了。 不要总向下看，人往高处走，水往低处流