- 我上培训的时候,老师说测试工程师的职业寿命很长;现在发现,不是很长,是很烦;
- 等我干了些时间,有人问我,干自动化了么,我说没有;ta 说你要努力啊;看来大家都看不上手工;等 ziji 干上了自动化,发现这东西真解决不了什么问题;别和我抬杠,问问自己真心是怎么想的;
- 搞过 java,基本明白封装继承多态,public/private/protected, interface,然后不知道搞啥,卒;
- 然后开始搞 py,发现自封自己会 py 的测试太多了,这帮人连相对导入绝对导入都搞不清,除了会框架/调 api 其外啥也不灵；我 tm 还不会框架,但我能还能撸点源码看 doc 文档；
- 然后回过头发现,你和开发的语言不一样,就像鸡同鸭讲;人家搞 py,三天学会了，还超过你的水平，你就别得意了
- 我还会点 ruby,水平更菜
- 然后开始看到无穷无穷尽的重复接口测试轮子；
- 搞不清楚为什么不直接用代码请求做断言不就完了; 搞那么多 web 页面干啥；没见过哪个开发测试代码还自己做个后台的; 难道不知道 cli 最节约资源么
因为领导要求做个带页面的,便利,可以让非自动化测试工程师使用; -> 这让我想起了有的领导要求，用例写的要让任何一个人都能看懂； 任何一个人，任何一个单细胞动物好么，你以为我是白居易么？ 都能看的懂，那测试人员是不是找个一年级学生也能来干？现在的公司寿命很长么？不能我维护清楚也许就黄了；我把测试点列清楚不就完了么.
- 搞不清楚为什么不直接用代码请求做断言不就完了; 搞那么多 web 页面干啥；没见过哪个开发测试代码还自己做个后台的; 难道不知道 cli 最节约资源么
- 没见过开发组长不写代码的,但测试组长只动嘴的可真是不在少数
- 我还是努点力去搞搞白盒吧,其他的闹出天来来,也就那么回事
我们一方面在造着希望傻逼都会使的测试工具，一方面希望自己不至于被当做傻逼扫地出门。你甭管公司招不招傻逼，反正你做的东西就得满足傻逼的需求。
都是混口饭吃，面子工程有时候也要有
有趣有趣，思路很清晰
兄弟，你这政治很不正确啊。哈哈哈，瞎说什么大实话
没见过开发组长不写代码的,但测试组长只动嘴的可真是不在少数
不能同意更多了
现在在写傻瓜平台，加上我也不想写 testng 了，
有意思，吐的挺有水平，至少在我看来～
测试组长不写代码，真的是很普遍，不知道为何这样
匿名区一堆大佬
所有在你看来觉得特别傻逼的事，都是区分你与傻逼的证据
一切代码都是解决 “效率” 问题。
不然呢。。测试毕竟不是开发 不能一直摸代码的测试 代码水平大都比不上开发。。。
我觉能用第 3 方工具代替，就代替，别人工具成熟啊，拿来直接用。在业务测试繁忙，版本更新快的节奏，哪有那么多时间维护自己写的工具。用工具既能提高效率，又能减少维护，是不是把工具用好就可以了，偶尔看看源码也是可以的嘛 ，改进工具
还真是搞出天来都那么回事，没搞过的时候觉得牛逼，搞过了就觉得不过如此
工具开发者和使用者心态是不同的，开发者往往会自 high 到飞起，看老子开发的工具多么牛逼，提高了 xxx% 的效率，吊吊吊。。。使用者：这什么垃圾玩意儿
搞过 java,基本明白封装继承多态,public/private/protected, interface,然后不知道搞啥,卒;
没有明确应用目的的学习，学完用不上也正常。为了学 Java 而学 Java ，既痛苦又没收获。
搞不清楚为什么不直接用代码请求做断言不就完了; 搞那么多 web 页面干啥；没见过哪个开发测试代码还自己做个后台的; 难道不知道 cli 最节约资源么
搞 web 页面目的不就是为了分担压力，提高效率么。通过 web 页面或者规范的用例编写方法，什么自动生成用例呀，大家都可以维护的用例呀，才可以实现。当然，做的不好确实效率比写代码低得多，但这个就是能力问题了。
最后一点，平台、效率提升工具，都是在合适的场景、有需要的团队才有用武之地的。不要光顾着开发工具平台，忽略了团队的实际需要，不解决当前遇到问题的平台或者工具，除了高大上，都不产生价值。
楼主先看看自己喜不喜欢看代码。
养成用 api 的时候去看看源码实现。
如果能做到直接转开发，不能就继续做测试吧。
测试的价值跟你说的基本没关系，还没体会到测试的价值。
匿名
回复
- 那你抱着什么目的学习？都上过学,只有那些中途退学创业的才有权回答这问题.
- 现在有多少接口 web 测试工具? 如果真的有个像样的可以通用,为什么还要折腾,说白了都是练手为了填绩效，
都是应用层的东西,能出什么花样？
- 只有 postman 是通用的, postman 是为项目提测时用的；
- web 页面的接口测试工具,是为了项目都完了,搞回归用；
- 你非用在提测的时候用?加盐怎么处理？加密怎么处理？CSRF 怎么办？修改 response 支持么?
感觉像是什么都学精，然后吐槽整个测试不行，哈哈哈
别人可以持续集成起来，修改或者新增一个功能 2 天发布，你可以么？
接楼上，
别人可以自动截取线上错误日志自动生成用例再回归，你可以么？
别人可以统计测试用例覆盖率，你可以么？
别人可以在短时间内保证回归测试完功能点，保证发布质量，你可以么？
有很多事情去做，学艺不精就别说行业不行。
你再能耐一点把找 BUG 的工作也接过来呗。
新手去打篮球被虐了，说这个运动没意思，根本碰不到球。
匿名
回复
- 曾经听过一个 google 测试的分享，唯一能记住的就是 ta 每句话都是半句英文 半句中文；
- 自动截取线上错误日志自动生成用例再回归. 有截取线上流量数据进行备份然后在测试环境搞的；日志,那是错误场景,就没产生正确结果. 没有人工干预,预期结果在哪？难道用上 ai 了么
- 统计测试用例覆盖率 这事:领导:我用例覆盖率 98%,这怎么统计的？那 2% 为什么不补上？是评审完了之后发现是 98% 么？
- 短时间内保证回归测试完功能点，保证发布质量 , 是不加班实现的么？这不大家都在加班么,不都是短时间么；这是招聘条件；
匿名
回复
别说的太消极嘛。技术牛逼一点总是好的，更高的地方有更高的问题和困难在等着你。当然，班还是要加的。但是逼格上去了嘛，挣得更多了嘛，想开一点，都是资本主义被剥削的奴隶，为什么不往高处走呢？
功能测试是真的难。只好学些其他的技术辅助了……
我做了快 8 年测试了。现在还真没觉得腻歪，总感觉有无穷无尽的动力和学习欲望。 总感觉有学不完的东西。
关于自动化
关于质疑自动化质疑技术的言论有很多， 但是你发没发现这几年质疑的声音越来越小了。 其实不是技术没用，只是技术不好，或者不懂得把技术转换生成产力才给人一种好像没什么用的错觉。 但既然有用的不好的，那就有用的好的。 只是可能很多人没去过像样的厂子所以没见过。 这方面我不多说了，免得又撕上逼了。 可以跟楼主举个我自己应用的例子， 我在我们团队使用 k8s 做自动化部署和 CICD 流程，支撑日千级的构建次数和超过 60 套环境的自动化运维， 这种量级的测试环境你让我人肉维护我要招聘多少个人？ 就算是大家最看不起的 UI 自动化测试，都是放在 K8S 里分布式执行，40 个浏览器并发都要跑半个小时。 这种量级的测试用例你让我手工执行我要招聘多少个人？ 所以我不劝别人怎么怎么样了， 我觉得技术和自动化很有用。
关于学习编程
这个我感同身受，以前没有目的的学习，大概也跟楼主是一样的。 学完了发现也没啥用，而且没有应用场景的学习基本也就是学个皮毛。 我现在只学能用的上的，尤其是能用在项目里的。 这时候就会发现学的有动力，而且应用场景越复杂，学的就越深。 有那么一句话是这么说的，技术的高低取决于问题的复杂度。这也就涉及到了我一直坚信的一个理念 ---- 抛离了业务的技术都是在耍流氓。
关于重复造轮子
这个我同样感同身受，有时候就是为了那点 KPI，为了晋升。各个大厂里晋升项目多的是，晋升了以后项目就没人维护了。 这个没办法，只能说有人的地方就有江湖吧。 这个我们只能严格律己，自己别这么搞就行了。 我现在做框架基本都是大杂烩，能用开源的就用开源的，很少自己造轮子。 顶多就是 2 次开发。 一个是因为没时间，事情太多，也没工夫装那个逼。 因为我们这里是结果导向，不管有没有造出特别牛逼的轮子，产品质量不行，什么都是扯淡。 再一个是因为我自己造的轮子也没人家开源的好啊，人都是好多个大牛共同开发出来的东西。我还真比不上。
关于测试组长只动嘴
一个合格的管理者确实有很多事情要忙，关注的东西很多，他确实没什么时间去做具体的事情了，这确实是跟技术人想象的不一样的，管理者不是只拍脑袋动嘴皮子，有很多时候是他帮手底下的人档住了很多锅和压力。 但那是基于管理一个有规模的团队和一个有规模的业务的前提下。 一个小测试组长手底下就那么几个人，对接的就那么点业务。这种规模的就别称自己是管理岗了，这么点东西有啥好管理的。这个确实是一个不好的风气。 我以前也碰见过不少这样的，都是在混日子的，我们不要学他们就好了。 不过就像我一开始说的，管理岗确实还是有很多事要忙的。 我现在的工作算半技术岗半管理岗吧， 我自己有测试任务，owner 了好几个模块。带着几个人一起做事。 同时我是公司 CICD 小组的 owner， 测试架构的 owner，自动化测试的 owner。 所以除了干活， 还要设计流程，搭建框架，组织会议，协调资源， 出规范出计划，还有几乎每天都有的面试。 我还带着几个新人，每周的培训也得有。 我甚至忙的有些框架都没法自己写了， 让同事写，但是我要 review 他的设计和代码。 我组内的新人我还要 review 测试用例，review 需求评审。 所以虽然一个测试小组长不干活是不对的，但也千万别觉得管理岗真的就整天无所事事了。
关于白盒测试
这是一个误区，白盒测试是最高大上的，其他的都是垃圾。。。这是一个最最最最大的误区。 就算是我们这些搞过白盒的人都不会有这个想法。。。 在一个庞大的系统中，某个模块的白盒实在是太渺小了。举个例子，白盒这是一个点或者线上的打击方式。关注面较窄，但很精。 但还有一种面上的或者说立体上的打击方式。 涉及一个产品生命周期的各个方面。测试里比如调度，数据等测试，或者 工程效率方面比如自动化运维，CICD 等等。 只能说工种不同，并没有高低之分。
感觉可以补充一下下楼上的白盒测试，个人认为白盒测试更多的就是单元测试，他关注的是一个方法、一个模块是不是有问题，据说通过 28 原则，如果单元测试做得好可以找到 80% 的问题，但毕竟还有 20% 是需要集成测试和系统测试来测的。然鹅，老实讲单元测试做得好的，在国内测试行业还真少见……
一般测试赶个 5 年左右就有这种想法了，很正常，每个人学到一定程度都差不多，但是其实还是能更进一步的，行业都是没有尽头的，有尽头的只是你的思想和学习能力
腻歪的原因在于楼主到了一个成长的天花板了，就跟打游戏一样，level max 了不进化，经验值就不涨了，所以啊，想办法进阶呗
自动化可以减少人们的重复冗余工作，提高测试的技术和参与感，没有什么自动化好不好，它只是一种测试工具，测试方案，最终效果还是由实施的人决定的。
没有方向的时候，最愿意看看这样吐槽的帖子，总能感同身受，也总有大牛指一指方向，对于技术不行的我来说，只能先低头研究技术，偶尔抱怨测试工作不好做了，然后再继续学习吧，不站在一定的高度视角是不一样的。
孙高飞
回复
👍有兴趣来阿里一起做 devops 吗，我邮箱 jiaoba#alibaba-inc.com JD 参考 https://testerhome.com/topics/11978
吐的牛逼真相卡拉斯