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

我很负责任的说。。。。这可能是个 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 的我都见过。 你觉得纯功能测试能拿这个数么？

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

首先回答一下楼主觉得没技术含量的事

我给楼主提供几个场景。

• 产品微服务架构下使用 k8s 管理。做调度测试的时候，调完接口难道验证个 response 就结束了么？当然要去 k8s 上验证调度是否正确。
• 大数据模块的功能测试，我们存储一个文件到 hdfs 上，难道验证个 response 就结束了么？当然要去 hdfs 上查看一下文件和文件内容，统计和分析数据分布
• ai 平台的测试，平台支持集成 tensorflow。难道直接在 UI 上点默认模板，或者调个接口跑通了就行么？ 当然要构建各种 tf 代码，测试 dnn，cnn，rnn，tensorboard，分布式，GPU，模型导出，模型上线。

就不扯设计模式，代码架构这些容易让人觉得是在务虚的东西了，虽然那个很重要。 我们就说实打实的技术。 楼主觉得调个 http 接口很 low 很没技术含量。 那楼主觉得我上面说的 k8s 技术，大数据技术，tensorflow 技术还 low 么？ 是，自动化手段就那么几样，也玩不出什么花来，但是自动化手段向来也不是重点。 而是根据你的产品特性，架构特性你能做出什么样的事情来。 这也是为什么做底层测试会比业务测试有技术含量，虽然他们都是在调接口。测试人员不要局限于自动化手段上，而要对我们所处的领域有更深的研究。这建立在你对产品业务和产品架构的专业度上。专业度上去了，没有人觉得你 low，不管你是研发还是产品还是测试。 我们的 PM 设计某些涉及到底层调度的功能的时候会来问问我的意见， 设计 hadoop，机器学习算法相关模块的时候会拉上我评审一下。甚至做 K8S 相关项目的时候产品 leader 指明要我来做 owner。 测试 tensorflow 的时候大家也是第一个想到我。 我们这的资深 QA 每一个都有一手绝活，我们这里没人轻视 QA.

回答一下楼主觉得自动化没用的事

关于质疑自动化质疑技术的言论有很多， 但是你发没发现这几年质疑的声音越来越小了。 其实不是技术没用，只是技术不好，或者不懂得把技术转换生成产力才给人一种好像没什么用的错觉。 但既然有用的不好的，那就有用的好的。 只是可能很多人没去过像样的厂子所以没见过。 这方面我不多说了，免得又撕上逼了。 可以跟楼主举个我自己应用的例子， 我在我们团队使用 k8s 做自动化部署和 CICD 流程，支撑日千级的构建次数和超过 60 套环境的自动化运维， 这种量级的测试环境你让我人肉维护我要招聘多少个人？ 就算是大家最看不起的 UI 自动化测试，都是放在 K8S 里分布式执行，40 个浏览器并发都要跑半个小时。 这种量级的测试用例你让我手工执行我要招聘多少个人？ 所以我不劝别人怎么怎么样了， 我觉得技术和自动化很有用。

总结

如果觉得现在做的事情没什么技术含量就多出去看看。大厂核心部门，独角兽核心部门的测试还是很有技术含量的。另外学无止境，只有持续不断的学习，才能去做更有技术含量的事情。 我现在越学习，越觉得自己无知。

不撕~ 不撕~ 不撕~ 不撕~

有，只要是分类问题，就有阈值。

我做了快 8 年测试了。现在还真没觉得腻歪，总感觉有无穷无尽的动力和学习欲望。 总感觉有学不完的东西。

关于自动化

关于质疑自动化质疑技术的言论有很多， 但是你发没发现这几年质疑的声音越来越小了。 其实不是技术没用，只是技术不好，或者不懂得把技术转换生成产力才给人一种好像没什么用的错觉。 但既然有用的不好的，那就有用的好的。 只是可能很多人没去过像样的厂子所以没见过。 这方面我不多说了，免得又撕上逼了。 可以跟楼主举个我自己应用的例子， 我在我们团队使用 k8s 做自动化部署和 CICD 流程，支撑日千级的构建次数和超过 60 套环境的自动化运维， 这种量级的测试环境你让我人肉维护我要招聘多少个人？ 就算是大家最看不起的 UI 自动化测试，都是放在 K8S 里分布式执行，40 个浏览器并发都要跑半个小时。 这种量级的测试用例你让我手工执行我要招聘多少个人？ 所以我不劝别人怎么怎么样了， 我觉得技术和自动化很有用。

关于学习编程

这个我感同身受，以前没有目的的学习，大概也跟楼主是一样的。 学完了发现也没啥用，而且没有应用场景的学习基本也就是学个皮毛。 我现在只学能用的上的，尤其是能用在项目里的。 这时候就会发现学的有动力，而且应用场景越复杂，学的就越深。 有那么一句话是这么说的，技术的高低取决于问题的复杂度。这也就涉及到了我一直坚信的一个理念 ---- 抛离了业务的技术都是在耍流氓。

关于重复造轮子

这个我同样感同身受，有时候就是为了那点 KPI，为了晋升。各个大厂里晋升项目多的是，晋升了以后项目就没人维护了。 这个没办法，只能说有人的地方就有江湖吧。 这个我们只能严格律己，自己别这么搞就行了。 我现在做框架基本都是大杂烩，能用开源的就用开源的，很少自己造轮子。 顶多就是 2 次开发。 一个是因为没时间，事情太多，也没工夫装那个逼。 因为我们这里是结果导向，不管有没有造出特别牛逼的轮子，产品质量不行，什么都是扯淡。 再一个是因为我自己造的轮子也没人家开源的好啊，人都是好多个大牛共同开发出来的东西。我还真比不上。

关于测试组长只动嘴

一个合格的管理者确实有很多事情要忙，关注的东西很多，他确实没什么时间去做具体的事情了，这确实是跟技术人想象的不一样的，管理者不是只拍脑袋动嘴皮子，有很多时候是他帮手底下的人档住了很多锅和压力。 但那是基于管理一个有规模的团队和一个有规模的业务的前提下。 一个小测试组长手底下就那么几个人，对接的就那么点业务。这种规模的就别称自己是管理岗了，这么点东西有啥好管理的。这个确实是一个不好的风气。 我以前也碰见过不少这样的，都是在混日子的，我们不要学他们就好了。 不过就像我一开始说的，管理岗确实还是有很多事要忙的。 我现在的工作算半技术岗半管理岗吧， 我自己有测试任务，owner 了好几个模块。带着几个人一起做事。 同时我是公司 CICD 小组的 owner， 测试架构的 owner，自动化测试的 owner。 所以除了干活， 还要设计流程，搭建框架，组织会议，协调资源， 出规范出计划，还有几乎每天都有的面试。 我还带着几个新人，每周的培训也得有。 我甚至忙的有些框架都没法自己写了， 让同事写，但是我要 review 他的设计和代码。 我组内的新人我还要 review 测试用例，review 需求评审。 所以虽然一个测试小组长不干活是不对的，但也千万别觉得管理岗真的就整天无所事事了。

关于白盒测试

这是一个误区，白盒测试是最高大上的，其他的都是垃圾。。。这是一个最最最最大的误区。 就算是我们这些搞过白盒的人都不会有这个想法。。。 在一个庞大的系统中，某个模块的白盒实在是太渺小了。举个例子，白盒这是一个点或者线上的打击方式。关注面较窄，但很精。 但还有一种面上的或者说立体上的打击方式。 涉及一个产品生命周期的各个方面。测试里比如调度，数据等测试，或者 工程效率方面比如自动化运维，CICD 等等。 只能说工种不同，并没有高低之分。

升职加薪是我最大的动力哈哈哈哈。

求 testlink API 的介绍

网易云课堂中的吴恩达视频

这就是 selenide 的 python 版本~~~

这个我还真没用过~ 之后可以看看

是吧~ 哈哈， 所以我一直安利这个框架

推荐 selenide+docker gird 架构， 最好跑在 k8s 里。 自动化运维和执行效率杠杠的。 我再我们这 40 浏览器并发，速度飞起

其他的没太用过不敢评价， 比较火的比如 macaca，rf

移动端的我没研究过了~~ 反正 web 端我觉得这玩意最好用了。听说 python 也支持 selenide 了

开源要向公司申请的。 不能私自开源