我先坐个沙发

在测试这一行，走得越久越感觉技术的重要性，不再是当初的多少年转管理，而是你到了那个层次，自然会有机会。

板凳

沙发没了，就蹲着看完，给个赞！！！

啥也不说了，先点个赞

我这里也是直接招开发来做自动化、接口、平台等测试工作。

测试水太深了，而我还在岸边徘徊😔

—— 来自 TesterHome 官方 安卓客户端

老司机懂得就是多，坐等下篇

一个连面向对象是什么的测试，通过《演员的修养》，成功进入世界 500 强某东管理层，目前正在研习《溜须深入思考 v2.0》。

希望更多关于测试行业介绍的文章

先点个赞，期待下篇

期待下一篇

现在就是一脸迷茫，不知道下一步怎么走

坐等下篇。

—— 来自 TesterHome 官方 安卓客户端

先点赞，期待下一篇。

赞一个 等下篇

老司机带路

看前辈自传的心态开始阅读，到最后文风俨然国内测试的浪潮之巅

又该学习了.

#10 楼 @sidaofeng 是谁啊？

对自己要学什么, 如何发展,太有指导性了!

#19 楼 @morgen 陆陆续续的写的. 很乱. 将就着看吧. 这是我写帖子以来最不满意的一个. @safe 催了很久. 索性就先开放出来.

深度好文，学习了，感谢~！

微软引领的大测试时代中：比如一度是两个测试对一个开发, 甚至是一个开发对两个测试 ，感觉哪里不对 ，还没看完，先谢谢思寒大神

已赞，等下篇

思寒现在不是在美团么

这个话题确实很大，里面很多观点和方法都想深入了解一下，呵呵

先说一个问题，移动互联网 + 创业大潮：从而催生了异常席卷全球的创业浪潮.
大概整个行业里面只有测试工程师会认为自动化测试是鸡肋. 这句话我很认同，我也感觉目前所在公司自动化很鸡肋，业务变化太快，动不动就新增系统，不断的挖坑填坑，自动化做不起来，可能是因为在小公司
少数技术入门了但是根底不扎实的人会误导并传递错误的信号. 总感觉是在说我这种
已经入行五年，但是目前在技术方面基本为 0，不知道还能不能赶上时代的步伐，感谢思寒大神，等有时间我在多读两遍，期待下篇

#30 楼 @safe 现在的自动化策略需要调整 比如推分层自动化, 这块有几个方向.
第一个是用自动化保证回归. 尝试用分层自动化避免用最后的 UI 自动化.
第二个是不断的调整架构, 找出更多的稳定的接口层去保证. 比如 app 本身其实也能分成 MVC 架构的.
第三个等别人出更好的实践. 比如测试左移. 在研发开发的时候, 就能识别出自动化的流程. 测试团队资源多放到业务测试和探索性测试上.

这块是行业埋的坑, 小公司的确难搞. 所以不用自动化也是对的.
包括 google 自己也在努力的推出新的测试框架也是为了大家能够更好的用自动化. 需不需要采用需要看具体的形式.

#28 楼 @mads 是的. 因为刚入职所以不想挂这个 title 引人误解. 这些理念是之前形成的.

#25 楼 @safe 打字打的快, 错别字太多了, 思维也秀逗了.

#30 楼 @safe
#31 楼 @seveniruby
我感觉自动化做不起来跟公司大小好像没有决定性的联系。我见过一些公司，包括我现在的公司，虽然公司小，QA 人数少，例如我们只有 4 个 QA。但自动化依然有声有色的。应该是跟业务种类，公司的重视程度和 QA 人的技术水平有关系更大

深深的危机感袭来。。。

#34 楼 @ycwdaaaa 跟开发水平关系也很大, bug 多, 整天都沉溺在 bug 中了.

#36 楼 @michael_wang 我们 bug 也多，但很多跟我们没啥关系。提测准入标准是跑过自动化测试。 测试失败了开发自己去修了。不需要我们 QA 管

#34 楼 @ycwdaaaa @safe 跟业务形态和技术架构有关. 如果产品能做好分层. 比如包括 app 自身都能清晰的分出 mvc 结构. 那自动化是可以的. 再一个是以各种电商活动为主的 app, 活动几乎一周一变, 也的确做不起来. 但是回归测试自动化是肯定能做起来的. 需要推动研发提升可测性, 推动分层自动化. 和一些专项测试的自动化.

大部分人容易在错误的基础上做自动化, 古人也说过"勿在浮沙筑高台", 架构的可测性和技术选型很关键. 不然就会失败.

#38 楼 @seveniruby 恩 ，对的，所以我说跟业务种类相关么。 不管产品架构如何，回归自动化这种一般都是搞的出来的。分层自动化在 UI 层和接口层也不难搞。 专项测试方面我不太清楚移动端怎么定义的。如果意思是更深入的测试，找出 bug 的原因等。那么是需要了解产品架构的。想自动化就需要能够操控各个组件 fake 一些状况。例如我们公司用 etcd 作为服务发现和负载均衡。那测试的时候就自己去 etcd 上 hack 一些操作。或者故意 kill 掉摸个某块的核心进程等等。不知道理解的对不对。 总的来讲，感觉只要不是产品业务上因素的制衡。总是能找到办法去自动化的。

老司机开车啦

最近一直在问自己一个问题，自己还会测试么，看了之后真心觉得不会做测试了。。。或者说是以前的测试思维已经远远落伍了。期待下篇~

#37 楼 @ycwdaaaa 新的需求也能写出自动化脚本来跑吗?

第一次留言，感谢老司机的文章。我个人觉得把技术基础打牢，测开和新型测试工程师互转的空间很大。技术的学习提升，个人感觉还是从代码开始比较好点，虽然学习成本大，但对底层原理的理解会更深。

啥也不说了，先点个赞👍👍

#34 楼 @ycwdaaaa 我们公司很多都是市场主导技术部，而且很多发展方向都在摸索，很多时候都是 boss 决定需求，拍板发版时间，然后产品开发测试各种疲于奔命 自动化做出来以后可能用完一次就废弃了，完全没有价值，很多时候我们自己都无所适从，现在慢慢在转变，希望后面会稳定点

#31 楼 @seveniruby 我们公司之前也推过接口自动化，但是由于业务变更太频繁，接口参数也跟着变更，然后是数据库，推行了一段时间，成本太高，疲于应付新需求功能测试，完全推不起来，最后废弃了
感谢你的建议，近期打算先把代码捡起来，然后慢慢尝试下各种类型的自动化，慢慢找自己的路

#46 楼 @safe 这个事情有点像设计模式和架构要解决的问题。变化是主旋律，架构，设计模式，版本管理做了这么多的改进其实就是为了分离变化和固定的东西，让变化更快更容易维护，让不变的东西更稳固可复用。这个问题不仅是 app 端存在，接口存在，甚至单元测试也存在。这种对变化的抱怨很多年前在代码层面就有人吐槽了，也有了很完善的解决方案。以你们的接口为例，你们需要分离做可测性提升，构建两层接口体系，对基础接口做自动化回归，对不断变化的新接口做人工测试，或者借助类似自动生成用例的工具做快速的接口测试用例编写。这样才能构建基础稳定的质量防护网。底层稳定了变化就可控，业务压力就会下来。现在测试的一个痛点就是没有积累性，对产品反复测试很多次就因为一行代码变更还得大部分回归，这是不合理的，也跟不上业务发展的需求，ui 自动化也是错的。没有可测性提升和分层的自动化保证，这种痛苦就无法终结。

首先 思寒写的还是那么的务实，没有太多的空头大道理，赞一个。

：性能指标度量和监控
第一层的同学在使用 ps netstat vmstat top nmon 等工具.
第二层的同学在使用 ganglia zabbix 等工具做监控
第三层的同学在使用 profile 工具. 比如 VisualVM JConsole ByteMan BTrace AOP
第四层的同学在使用 trace 工具. 比如 systemtap dtrace perf 等.

这段我个人存在不同的看法：
ps、top、nmon 等是作为资源监控工具，而 ganglia、zabbix 等更多偏向于运维方面的服务器监控（灵敏度差个人不觉得适合用于性能测试监控）。
profile 类型工具用于针对应用程序自身或者 JVM 等监控，perf、sysmatap 等用于系统自身的监控以及调优。
这些工具更多应在排查定位问题时根据情况使用，而不会随着性能测试工程师的技能水平提升而取代。

看到思寒的文章，深有体会，我经历外企，测试开发占比 2:1，到传统企业，独立测试部门，瀑布流开发方式，只有业务没有代码的测试，到现在互联网企业做测试开发，只能说世界变化很快，要积极拥抱变化

—— 来自 TesterHome 官方 安卓客户端

#48 楼 @r455678 多谢提建议, 这块可以交流下. 我举个例子, 如果你的后台服务器有一百台, 你是没法去 top 或者用 nmon 的.
ganglia 之类的系统是监控大量服务器的, 他的指标和绘图一般会延迟一分钟, 这在性能测试上是足够用的. 使用监控系统最大的好处是可以把 qps 和 cpu mem 的指标关联起来进行更好的对应分析. 比如 gatling 和 jmeter 都支持同步把结果发送给监控系统. 就是为了能更好的分析.

至于那几个层次, 你可以看下我一开始的注明.

我简单分了下层次. 层次没有高低 只是在满足第一层后人们会逐渐的开始探索更高的层次.

这是一个工程师成长的若干阶段, 不存在替代关系. 分别对应的是工具, 平台, 应用问题定位和平台问题定位几个方向.
多一层少一层, 甚至跨层成长的也很多.

看后，压力山大，但对以后的职业规划也有了更具体地规划，谢谢思寒！！！

—— 来自 TesterHome 官方 安卓客户端

感慨良多，欲言又止。。。期待下篇，感谢思寒！2017 加油！

感谢思寒让我看清了测试开发这个岗位，不过遗憾的是那些真正需要看清测试行业在发展与变化的测试工程师们却永远都可能看不到这篇文章，很多测试工程师都活在自己的世界里，每天点点点，没有自己的思想！

—— 来自 TesterHome 官方 安卓客户端

#47 楼 @seveniruby 这话太能理解了，我们这边固件团队，加个小功能，每次都要全面测试，一测就 2 个多星期，虽说固件影响面会比较大，但这样的测试效率太低

—— 来自 TesterHome 官方 安卓客户端

#47 楼 @seveniruby 感谢你的分析，你说的这些最近我也在思考，但是目前我的能力可能只能从业务方向去做部分的可测性提升，无法从接口等其他层面去把控，先学习下，再试着去摸索，最近由于工作变动，有更多自己的时间了，可以多去学学

文章实在太长了，应该拆分。

怒赞 ，思寒老司机的车就是稳

很给力的文档，但是对部分表达方式并不赞同。比如 “ 分层 ”。 你这分层的概念很容易让人对号入座，尽管作者在阐述技术的深入层次，但有一个很重要的观点就是 现在的公司都是结果导向。白猫黑猫能抓住老鼠就是好猫，不能刻意的追求技术，而忽略测试本身的工作内容和公司赋予你的使命。
技术是测试工作非常重要的基础之一， 是之一。

#58 楼 @luxiaofeng 有道理，这点我也愿意深入交流。猜到会有这种观点出现了。我的理解是这样的，黑猫和白猫能抓到老鼠的都是好猫，但是你如何解释同样都能做测试的人，为什么大部分企业会更希望要学历阅历和技术较好的人？算盘和计算器都能算账为什么现在所有的小餐馆都用计算器或者电脑自动结算？用 asp 也能开发网站为什么却找不到工作？

当你选择了一个落后的工作方式，工具或者技术栈的时候，不仅公司会被拖累，连自己的发展都会被波及。如果不能持续的改进自己，就会被行业淘汰。

我列举的技术，每超过一层对公司的收益都会越大，也能提升工作效率。每深入一层对质量的理解也会深入，还能看到更大的发展空间。当技术做不到做不到就降纬用低级生产力解决问题，当有更好的方案就要及时升纬提升效率。

还有一点是这些年大家老是对立技术和业务，其实在一定的层次上业务和技术是有个非常有价值的结合点的，在这个结合点上能够非常完善的区分出代码的变更对业务变更的影响范围，能通过技术的方法判定基础功能的正确性。这一层在覆盖率的下一层。做到这点我们就能对业务建模，积累业务数据形成 QA 稳固的业务。这样才能让最后的手工测试压力降下来。

类似的技术和思维方式还包括全链路的压测，流量对比等专项手段，也能在很短的时间保证系统的质量，这样产出的产品质量会好很多，留给 qa 最后的质量保证压力就会小很多。

最后公司赋予你的使命你忽略了一点，除了让质量更好也要让质量保证的效率足够快。

怒赞，膜拜～

#56 楼 @Lihuazhang 我把技术单独拆分出来吧。以免讨论太多歪楼

#55 楼 @safe @hu_qingen 目前测试行业的现状不是我们自己造成, 相对于研发行业不断追求技术和架构的改进, 咱们测试行业对测试技术和测试架构的思考太少了. 目前受的累不过是前人不思进取埋的坑. 再不改进一旦业务发展平稳, 测试的地位和饭碗都不容易保住的.

在业务高速发展的时候, 企业会雇佣较多的人手做手工测试, 较少的人数做测试技术和架构改进, 一旦业务发展平稳, 首先被裁撤的是无法有自己业务和技术门槛的人. 手工测试的工程师群体首当其冲. 会裁撤大部分, 仍旧会保留少数的业务精英.

最近大佬们不是都在提互联网的下半场吗, 一般游戏结束大浪褪去, 就知道是谁在裸泳了.

看完，冒个泡。

喜欢这种务实、客观的观点文。
赞。

可以给自己加个精了

目前所呆公司 QA 部门正朝着测试开发方向走，领导现在已经不大谈测试质量了，只想着开发出工具或者平台。做好产品质量的回报不如做技术的回报大。似乎有点儿本末倒置

拜读大作，我是从传统行业转互联网，感触挺多的。形势逼迫你不断学习，进步

“” 早年对自己定过一个要求. 不做管理 “”，很想知道是居于什么考虑呢？
我也是偏技术，但是发现不做管理有时很难把自己的设计和想法通过技术实现，而只能按照管理的想法去做事。好的想法固然很好，但是明知道不行，还得去做，有时很无奈

#66 楼 @wixed 这也是典型的两大管理问题. 体力劳动为主的业务测试部门, 会倾向于多招人抬高和巩固自己的地位. 脑力劳动为主的部门, 会愿意多构造技术工具和平台创建自己的技术门槛和核心业务以树立起部门墙. 不能说一定是对还是错, 要看产出是不是足够有效, 足够大. 结果导向.

企业也不傻, 一般都是先找齐人手用低级的生产力快糙猛的拿到业务搭起来架子,然后再逐渐在"飞行中换引擎", 不断改进. 如果是纯做手工测试, 一般会出现平时很忙, 天天加班加点. 但是到了不忙的时候, 一半人就被裁撤了. 结果还是要忙起来. 业务是贪婪的, 他会不断的甩掉赘肉. 除非你运气好跳到什么垄断企业, 产品再差再慢也无人替代, 人再多再傻也有铁饭碗. 当然这就不是互联网行业了. 超出我的理解范围了.

#69 楼 @seveniruby 大神说得对！确实就是结果导向。

#68 楼 @fresh 我很多年前也遇到过, 不走管理的原因有多个.

• 想多点时间去研究和做事. 做管理的变化是很多事情不能亲力亲为, 你的业绩取决于别人. 这样不仅会导致自己不能深入的做事打好基础, 还会导致陷入对外部不可控因素的依赖. 在早期我觉得自己上阵解决问题更快.
• 预料到测试行业会整体做技术专项. 在五年前测试行业最大的瓶颈不是缺管理角色, 而是缺好的技术型测试工程师和架构师, 这个时候选择了去做管理无疑是进入一个一潭死水竞争激烈的红海. 测试架构师这个词语这几年很火, 其实是我七八年前自己创造的一个词语. 也不排除更早是有前人提过
• 管理逐渐会扁平化, 做管理要晋升的话, 需要熬的. 如果我有车有房我会心平气和的等待机会. 但是没有的话 ,就得选择一条更快的路. 而且做管理不一定非要有管理的职位,在平常的角色上也能得到锻炼. title 随时都是可以改的. 但是能力一旦错过最佳的锻炼机会, 就再也难弥补了. 所以我宁可累点.
• 以前也是小黑客, 所以对技术更偏爱.
• 一度因为追求管理, 心态有个不好的变化. 所以我也尽量避而远之.

不做管理的缺点也很大.

• 会错过获得最大回报的好机遇. 如果我 5 年前不离开阿里, 待遇和职位都会很不错.
• 做技术岗位的薪资始终是低于管理岗位的. 大公司相对有成熟的技术和管理体, 不会有这个问题.
• 如你所说如果遇到领导发出错误的决策的确会很痛苦, 不过我很幸运我的领导都很不错. 而且一些决策我也能跟他们协商

对于你的问题 ,我建议是沟通解决, 如果沟通不了. 你可以记录下自己的意见和看法, 让团队和领导知晓你的担心, 然后再跟团队和领导非常快速的"错"下去.

跟着团队一起错, 也是一种值得尊敬的心态. 况且对错不一定是绝对的. 有可能你的想法也是错的.
这种叫试错. 试错不仅是表明你愿意跟领导和团队一起成长, 也能尽快的验证可行性, 从而更早的止错.
我以前也知道一些事情做错了最后还拿奖的团队, 以及个人做错了领导也要强行颁奖挽回面子的事情.
试错也是一种有担当的行为, 这也是不错的经历, 走过的弯路也是一种人生财富.

#70 楼 @wixed 别喊我大神, 我也是小弟. 你喊多了会导致我被人误解成沽名钓誉害我被喷的. 根据你的年龄, 喊我思寒, 思寒哥, 思寒叔都行.

值得反复阅读的好文

#72 楼 @seveniruby OK，我叫思寒哥好了

想要跟着你走入测试的一条明路，而不是歪门邪道

思寒去的上海美团？继续做测试开发还是？

已经是大神了、接过吧：纯粹的、落地的、实践化的美

#59 楼 @seveniruby 这就是问题的所在，我承认技术是必备的技术，但是不能忘记我们是测试工程师，能解决实际问题的才是工程师。不准确的理念容易误导一部分同行，甚至面试的时候 经常听过的问题是： 你会不会这个工具，用没用过 XXX 框架。反倒没人问我们为什么选择这个工具，测试过程中遇到哪些问题，最后如何解决的？
不得不说，国内工程师也是应试教育的产物

#59 楼 @seveniruby 我是认同你的文章的，但是这个观点可能导致：很多人按照你的分层学完了，就觉得自己是大神了。但实际就是一个只会工具的技工而已。
我觉得我们除了推崇技术之外，更应该推广解决实际问题的理念，不要被工具牵着鼻子走。

#78 楼 @luxiaofeng 按照你的逻辑, 以后大家是不是提一个工具的时候都要先说几万字用的理由. 我只是罗列公司内经常用到的一些工具, 让大家看到现状. 过几年可能一些工具也会被行业淘汰了. 这个没包含什么价值观和人生观. 说实话用过相关的工具, 想不懂都难. 对于新人来说就已经可以为公司做服务了. 至于有没有深入的理解, 这决定一个人能走多高, 那就是个人的事情了. 但是如果没接触过相关的技术栈, 连面试都进不去的.

面试官大多都是实用主义, 他们需要 spring 的人, 你说没用过 java 只懂 asp, 他们不会问你为什么会选择 asp, 只是把简历扔进垃圾桶.
只要你的确用过相关的技术栈, 他们才会开始问你的解决问题的思路. 没有这个基础就没有公共语言了.

受教了，黄叔叔

#79 楼 @luxiaofeng 太虚的文章我不会写. 别人自称大神, 我也拦不住. 这个锅不要让我背啊.
在我没写文章之前, 懂 monkey adb appium, 会写 if else 的不少人都自称大神了.
如果早晚都要自称大神, 我宁愿那些人能按照我说的多学点. 知道的越多会越谦逊的.
我列举了这些工具其实也是增加了这群人装逼的成本. 其实也是好事吧.

工具和技术栈上就是解决问题理念的最成熟体现. 接触的工具越多, 越能深入理解解决问题的理念的. 量变会有质变.
本质上测试, 研发, 产品都是一定程度的技工. 既然同是技工, 为什么不选更好的工具那.
所以研发们从 eclipse 倒腾到 IDEA, 从 svn 折腾到 git. 看起来是工具升级成为高级技工了. 实际上是解决问题的理念更好了.
工具并不简单是一个物品和技术, 也深藏了很多解决问题的方法和模式.

写的挺好，希望可以转载

#83 楼 @zailushang 谢谢. 我只是分享给社区的同学, 辩论交流下. 没必要跟社区外的人陷入什么口舌之争. 还是不要转了.

#71 楼 @seveniruby 感谢这么详细的回答。确实如你所讲，技术岗位在薪资和决策力上都存在不足，所以最近在思考是否要转向管理岗位

怒赞! 等下篇~

#85 楼 @fresh 随心就好.

持续关注中，期待下篇，特别想知道老司机对于各种网络培训、网络视频有什么 样的看法

不错不错！

#62 楼 @seveniruby 嗯。其实我对咱们测试挺伤心，上次开发问我，你看的懂开发代码？我挺无语的，可能他们之前接触的测试只是简单的点点点。我真是情何以堪；侧面来说，测试必须要看的懂开发代码，不求懂太多设计模式，但至少能从开发代码中找到功能实现逻辑，不然真不知道啥时候被淘汰了

—— 来自 TesterHome 官方 安卓客户端

加精理由: 借着热度宣传下社区的微信号

已封神

认真的看完了，字字玑珠，对我这样的新人很有帮助。

BTW：为什么大家在讨论自动化测试的时候，不自觉的就往 UI 自动化上靠呢？按照思寒的说法，自动化应该采取分层的办法，尽可能的往上游去推进，这不但要求测试人员有足够的技术基础，还需要在项目团队上有一定的要求，比如研发团队本身对自己的代码质量就有一定的要求，这样对测试人员的沟通技巧和执行力、推动力就有一定的要求。
自动化测试可涉及的方面从代码底层到最后的线上监控整个链路，有很多方面可以入手，测试人员本身的质素非常关键。
另外赞成 @ycwdaaaa 的说法，自动化做的好不好，其实和公司规模没太大关系。

很赞的经验分享

感谢叔的文章受益匪浅。感觉测试已经不是狭义上的确保产品质量。而是在有限时间内确保产品有更高的质量，同时长时间给予产品质量反馈来改善优化产品。技术能实现测试的测试策略和想法，同时也能扩展测试的广度和深度。但测试思维和业务能力也是必不可少的利器。然后，就会发现好多要学习的，不多说了，搬砖去了。PS:为什么没有赞赏入口？

#96 楼 @xwgoss 你够了.

期待下篇~

这是因为他们做的事情脱离业务目标太远. 一旦完成目标, 他们也容易被"管道化", 成为边缘角色.
这个行业除了极少数技术的狂热爱好者, 能够找到自己在行业的技术地位外, 大多数人都应该去追随业务的发展. 业务才是测试的根基.

强烈共鸣，业务才是测试的根基，把这个观点明确出来真是造福刚入行测试三观还没形成的同行了。单纯的追求工具平台而忽视其对于业务的实际意义，真的是有点本末倒置。与其追求别人眼中的高大上，还不如利用很多已有的工具来实打实的提升测试效率，用已有的工具、平台，如果架构的好，设计的好，不管是成本还是对业务的质量保证意义应该比自己去开发工具平台都要好很多了，开发的不好还得改自己的 bug 不是？

@seveniruby 没必要把之前提到的工具编辑掉啊，可以作为附录给人参考嘛，最多去掉第 x 层的说法，改成序号，再加 1 句 “排列顺序不代表更难或更先进、各个工具都有自己的适用场景、将来可能过时、重要的是背后的思想” blahblahblah

难得有大公司的老司机出来提几个名词，对大家选型肯定有帮助的。真的一个不漏查过资料的人是不怕被 “误导” 的，有这个视野有对比要找到适合自己项目的花不了太多时间，倒是完全不知道有更好的才很可能在不合适的技术上浪费时间，“在屎上雕出花来”

都 2016 年了，很多童鞋不想一直做纯手工，但听说过的全是 n 年前的名词如 QTP、loadrunner、winrunner 之类……多数人这个阶段最需要的是知道去哪里找枪，不能一直拿小刀甚至空手，被人虐成渣

至于拿了枪会不会开，打不打得准，以后人人动力甲了会不会去找新装备，那都是活过今天之后的事了

感谢前辈的分享文章，让我了解了一些关于测试行业的历史，现状、以及未来测试行业的发展；现在的我对测试这个职业有时候也会感到迷茫，也会常常去思考自己的职业发展...

黄老师新作，拜读啦：）大大的赞。

测试行业经过自身的净化洗涤会有新生. 典型的变化就是薪资从以前的 3k-15k 的范围, 整体提升到 1w-3w 之间. 主要是房价也涨了很多倍，然后公司的业绩也增大了很多倍

#103 楼 @cobbxia 你可以统计下除去测试开发工程师群体之后的薪资水平.

深度好文，受教了

通读全篇，受益匪浅！感谢黄老师经验分享！

#104 楼 @seveniruby 不少大厂喜欢从小厂里面找开发，让他们做测试倒是真的。互联网企业测试技术发展和人员发展也是挺快的，未来人只会越来越贵。记得十年前狼厂主推自动化测试的时候，就由 cto 发表了一系列言论，意思是公司 QA 只会做手工测试，测试周期太长，以前招聘的门槛太低，要提高招聘门槛要提高测试待遇。公司业务的发展，也是有生老病死的过程，业务启动的时候做为一个 demo 可能就不需要测试，发展到一定程度用户激增的时候产品体验就很重要测试的价值也很明显，到了产品的稳定器，测试框架本身都固定，添添补补用例的事情，自然是谁可以做。专职测试投入。测试和产品一样存在生老病死的周期。测试这个事情本质上是怎么根据业务发展阶段，去针对性的制定质量保证的解决方案，选择用人去堆业务，还是选择自动化的层次用技术方式实现，都是具体测试策略，策略本身也依赖技术选型和技术工具，依赖于团队的技术实力。

感觉测试行业的管理基本是打杂的，说起来是个管理，实际上并没有做真正跟管理有关的事情，但是技术又被耽搁了，因为杂事太多。而高层测试管理，老实说，管人的时候还行，千万不要开口聊技术聊业务，真心肉食者鄙。

说得蛮多的，很多挺有道理的，但是测试重要还是开发重要这个问题总体上来看，当然是开发。而做测试开发的真是高不成低不就，门槛低的方面，没法接触具体业务流程，学不到业务相关知识，除非刚好参与一个大平台的开发，会有机会了解。门槛高的技术方面，又不好突破，比如我坐 iOS 的自动化，做 UI 工具的自动化，这些东西底层无非是调用接口，真正比较复杂的是构架和封装，然而学完这些又要学啥呢。出去跳槽的话，开发方面业务肯定要东，测试开发不懂，技术方面又要结合业务，测试开发不懂，所以测试开发真实坑，大坑，做测试开发的同学，如果是技术方面转过来的，尽量不要脱离之前方向，然后趁早别在测试开发待太久，不然会废，这是我的观点。

写的非常棒，提到的两点表示非常赞同：
1、关于测试人员的技能之一，要懂架构. 能够跟研发和产品进行正常的交流, 保证产品需求和实现都没问题. 能带团队走上更好的发展，现在测试部门被打散，为了效率，测试被分到各业务线上，这个技能就显得非常重要，通过测试 + 其他附加属性，能然测试如虎添翼，将岗位价值最大化，达到最终带领整个项目的目的；

2、关于测试开发岗位的发展，具体做测试工具工作的岗位会开始衰落， 因为他们做的事情脱离业务目标太远. 一旦完成目标, 他们也容易被"管道化", 成为边缘角色。在一个公司的部门工作，一定要具体参与部门核心产品的工作，脱离业务就意味着个人发展的偏航。

#23 楼 @seveniruby 我一直不知道如何更好地发展测试，在我们公司 UI 层，接口，集成等自动化测试都尝试过，但我没觉得这些测试策略给我的测试工作带来了多少便利，没给我找出多少 bug。目前找 bug 主要还是手工点点，性能压测。想请问下像我这样的，该如何寻找出路？怎样找出更多的 bug

#111 楼 @xiaoli
自动化测试的最主要目的不是找问题吧，主要是节省人力和保证系统稳定性

#112 楼 @carl 我想如何能找到更多的 bug 呢？我们现在 99% 的 bug 就是手动点点点

#112 楼 @carl @xiaoli 自动化测试目前的用途主要是用于回归测试. 发现 bug 他不胜任. 目前后端测试可以做到用自动化发现新需求的 bug. 但是前端和移动端还是要靠手工测试来发现 bug. 将来监控可能会代替一部分手工.

问下有涉足 单元测试 和 安全性测试的不？单元测试的用例如何设计执行？安全性测试，我知道 SQL 注入，还有什么更好的测试方法不

#114 楼 @seveniruby 我们后端是没有 UI 界面的，那么该如何自动化测试呢

#113 楼 @xiaoli
这个比例太高了吧，我之前做移动端自动化测试，自动化发现问题比例在 5%~10% 之间一般。

#115 楼 @xiaoli 你这是打算把我当保姆啊. 要自己研究探索. 你问的问题都有解决方案的.

思寒大大，都在谈业务能力，那么什么才是测试应该具备的业务能力？

@seveniruby 不止是保姆啊

我就跟喜欢做跟业务有关的测试，甚至校验异常数据单纯做 sql 校验也可以，但是真的不喜欢整天存跟代码打交道，虽然我自己也接触过一段时间的代码，发现真的不适合；做管理吧又不喜欢整天乱七八糟的事情打扰到自己 也挺纠结了

文盲定义的很精辟

叔（划掉）哥，测试需要掌握的技术主要有哪些方面？要深入到什么程度？有书单吗？

老司机就是有墨水

最近一直都想来论坛看看每个人 2016 的经历和总结，以及对未来行业发展的讨论，今天看到你写了这么多感觉写的很实在，看后受益匪浅，我觉得测试还是把技术做好事关键，因为现在大多数公司要求普遍较高，动不动都是招聘测试开发的，即便不是测试开发你面试的时候也要考你编程的题，要不然你就没机会进入该公司了，至于更好的公司就更需要好的技术支撑，如果没有好的技术一直在小公司混感觉就看不到前景了

#125 楼 @SkyFly_006 你这句话说的很实在, 这就是我为什么回复 #58 楼 @luxiaofeng 黑猫和白猫理论不合适的原因. 笔试都过不去一切就免谈了.

要学的东西很多，感觉这也是为什么踏上测试之路的原因，希望能够不断学习，技术带给人的愉悦感真心很赞，但是不会的挫败感也是非常的强烈，愿新的一年好好学习，不断进步，一小步也可以

@seveniruby 你的文章写的很不错，值的深思。 文章中你提到了学历很重要，像我们这种学历一般，学校也一般的人来说，有什么提升的办法吗？ 例如在职研究生是否也是被很多大公司认可的？

#128 楼 @ivy520 我学历也一般. 能力同等重要的看学历. 学历弱点就只能靠能力来补充了. 除非是特殊情况, 比如一定要进名企国企什么的, 那学历还是要针对性的补充下.

#116 楼 @xiaoli 后端说的应该是后端 API 测试，API 自动化是可以做的

@seveniruby get it . 非常感谢。

还是说点吧，看了 5 遍，感觉就像是远处有盏指路明灯，无奈自己找不到现在的路。现在上班 2 个月了，公司不大，研发 13 测试就我一个，没人带，基本靠自己学，像很多刚毕业的大学生一样迷茫，不知道前方的路怎么走，看别人说测试要懂业务，于是开始学习公司业务，尝试融入流程，从需求开始，想融入研发，学习单元测试，看代码和练习数据库，按照我的性格，是既不愿意跟外人交往的，但是毕业后就尽量让自己去融入圈子，去多讲话，多交流，你说的闭门造车，见识短浅，也许因为年龄太小，也许因为资历太短，提出的意见，说过的话也基本是付之东流，我是极其不喜欢点点点的，我喜欢代码，但是面对看不懂的代码，我也是无计可施，开始学 python,也只是能简单的写个小爬虫，最近在学 unittest，论坛里看了不少帖子，也犹如观望大神一样，门童望而止步，做不到借鉴，更做不到建议，有朋友建议先学一年的功能测试，再慢慢转性能或者自动化方向，对于性能我也只是粗浅的了结吞吐量，延迟等，会使用一点 ADB 命令，会查看日志，简单的使用 MAT 分析，虽然目前的点点点可以满足公司的基本业务要求，但还是不满足，思寒老大，这两年我该怎么去打好自己的基础呢，我真得特别反感天天熬日子，但现在的我基本天天熬日子

#132 楼 @B1ackcat 年后社区会加大教育投入. 开设更多的免费公开课, 教程和商业课程出来. 把 BAT 的知识总结梳理出来传授给更多人.

@seveniruby 思寒哥 努力转型中，痛并满怀期望。。。
还是非常认可你的说法，坚决转技术路线，前一年多做了较多的业务，技术本来就不好，这下落的更多了 ，后面要多向各位技术大牛交流取经

小公司搜索测试，测试研发比 1:15

—— 来自 TesterHome 官方 安卓客户端

还会有下篇吗？

看收入，害羞的退了

看完了，入行已有两年，已经感觉到瓶颈了，也想更深入的在这个行业发展，奈何自学能力不好，有时候挺迷茫的

#132 楼 @B1ackcat 准备转测试行业，可以聊聊你最初怎么入手测试的吗？

写得太好了

学习了，有见解。

受教了！

赞赞赞

思寒哥，请教个问题啊。我是测试业务功能方面比较多的，去年这一年自动化这方面比较感兴趣，也自学了 java 写了一些自动化的脚本，但是编程水平较低写的自动化脚本也不是很好只是能用在简单的业务场景中，也没用什么高大上的框架（而且有的实现还是找开发帮的忙...）。看了你上面写的技术路线的建议还是有点迷茫，想去提高自己又有点无从下手，感觉只是看那些编程的书籍都是开发看的啊，对于我有点大海捞针的感觉啊 ，实际中能用到的点不会很多吧？（不知道这么说合适不合适..）。能不能在这里给推荐一些比较好偏向测试这方面的书或者视频什么的啊？对了还说件事，我年前换了家公司，来了这边目前负责的主要是 IOS APP 的测试，我之前没怎么接触过移动端的测试 而且上来没多久让我测播放器的 SDK，我又不懂 OC，当时真的是无从下手，别的同事是测 pc 端的业务的，问他们也没用，在网上查播放器 SDK 的测试方法也没看到什么有用的。最后开发给我写了一个调用 SDK 的 demo，结果又回归功能测试去了。

#145 楼 @yefnegjun 技术发展路线和参考资料, 我年后写吧.

#146 楼 @seveniruby 好的，辛苦了！发现这个社区以后对我的帮助确实挺大的。本来身边能答疑解惑的人就比较少，有一两个关系比较好的同事，但是我们水平都差不多。在这个社区问了几个问题都有兄弟帮忙解决了，期待你后面的文章。

还是习惯叫 seveniruby。。几年前就在各种论坛看见你了 还关注了－ －

#69 楼 @seveniruby 看到你后面两句，感觉就是说的我的现状，我现在在 Nokia 做嵌入式软件测试，属于通信圈和 IT 刚刚沾点边，
我们组 20 人左右，只有我一个测试的，虽然我们这有 CI 的概念，但是大部分还是依靠手动或者我自己开发的（python 脚本）半自动化的工具来做。最近刚刚有几个新手加入，但是年龄比我还大（我 86），都有娃娃（女），平时生产力就是半个人，我们这因为外企嘛，CI 的核心团队在国外，我这算是一个 mini 分部（全靠自己学习，总结，改进），我也尝试把自己的工作用各种框架或者更加自动化的东西优化下，但是没有一个给力的搭档，一个人干太不爽，其他新手还是维持着 oprator 的思维，一合作就变成我单方面的教，他们没有探索的内驱力就想吃现成的，这样挺没有意思的。并且外企的总部的人处处防着你学习他们的核心的部分，所以我们现在大部分工作还是处于手动的低端阶段。我总感觉我们这里做这个软件测试 low 出行业平均水平了，想过跳槽出去。老板给我说让我做 Test Leader，做管理. 我却感觉是个深深的坑，因为本身自己技术能力就很有限，同时薪水就没给够，说这些大饼的东西是很无聊而且流氓的。最近想跳槽，为的是自己一颗做技术的心在这里无法发展应用，同时我发现外面的测试 Job 大多是 WEB 产品，或者大数据产品，看着都很不错，面了几个, 发现要求的技能很多，我短时间内不能 fit. 现在深深地苦恼中，担忧未来的发展之路，同时我也在加班学习些东西。唉，入了通信测试这个坑，出来不容易啊

看完很受启发，本来就是技术人员，不懂技术肯定会被时代抛弃，所以跪求技术篇，现在 25 岁，入行测试 1.7 年。现在努力，大不了大器晚成！

有帮助

注册第一次评论，看到这样的文章，三年半手工测试渣渣，都快落泪了，大神，请收下我的膝盖

新的一年新的迷茫，我还是先减个肥吧

#152 楼 @pai_sen 实习 + 正式，我也是三年半手工测试渣渣，找工作被鄙视好多次了，不知道该好好学技术还是转个行呢

读完之后对测试行业的发展又有了新的认识！以前只知道是同路人，这才发现我们还是同龄人，很佩服你在这个行业的成就，也给自己在这个行业继续发展增强了信心，希望有机会可以共事！

斯寒，我想听一下你对关键字驱动的理解 (提问背景：数据驱动的 UI 自动化投入太大，想节省开发成本)，在线求助

加油~！大大的赞， 坐等下篇~

受教，学习了。没人带，成长慢

这篇文章得多读几遍，我也进测试五年了，总找不到前方的路在哪里

同不看好测试开发工程师，
一直区分不出测试开发工程师和二线开发的区别。
做内部工具项目混吃等死。

感谢分享。向楼主多学习，感觉还得多看两遍包括评论。

值得学习，给个赞

可惜现在大家都不重视业务，觉得做业务测试没前途，只有做工具做平台才能晋升，老板也只看重这个。

在一家类似国企的公司做了 5 年测试，因为公司效益不好，迫不得已出来重新寻找机会。才发现自己的技术和思维已经脱节。在后续的职业发展考虑是否该转管理而迷茫的时候，看到思寒的文章，顿时有如醍醐灌顶。想起当时很多朋友转市场时，只有自己坚持从事技术岗位的初心，感慨不已。舒适的生活会让自己停滞不前，重新拾起当年的 java 教材，坚持初心，与君同行。

—— 来自 TesterHome 官方 安卓客户端

过一段时间又来看看，每次感受都不一样。。。

在一家类似国企的大公司温水煮了 N 年（N>=10），现在要重新开始定义自己的职业了。
以前每天都忙于加班，加班，加班，觉得自己把测试工作（也就是认真的点点点）做好，尽量多发现 bug 就足够了。
但是半年考核老大明确的说：你多发现几个 bug，还不如弄一下别的东西，比如想办法让开发进行单元测试（我们的开发不单元测试的）。。。
我也觉得如果出来会混不走，幸好虽然年老，但仍然觉得自己还想学习，不怕学习。。。

好棒的文章！！！膜拜
努力向你学习

看完整篇，有种柳暗花明又一村的感觉。对后面的路有了一个模糊的轮廓。感谢！
坚信，测试这个大浑水终有清澈的一天。

今天无意中看到这篇文章，感觉思寒哥对测试行业的发展理解非常深刻。后悔没有早点看到这篇文章。又庆幸今天看到这篇文章。对我自己以后的发展方向有了一个大题的指引。感谢感谢！！

一字一句看完了，水都没喝一口，手机都没看一眼。。谢谢@seveniruby

站的高度比较高

最近一次偶然的机会，了解到了有这个社区，看到了你的文章，如果在 2 年前看到，该多好，感觉自己这 2 年在走弯路，无长进，但是同时也庆幸，此时看到了，以后多多逛社区

原来您也是中软外包入行哇，前辈很厉害

真真是让我等后辈佩服~

我想请问下，最近一直想提高 python 编程水平，测试的话学 python 大概要学到什么水平？和开发差不多吗？还是可以实际解决问题就行

回头再看看，实在受用。

这文章还是需要多读，每次都会有不同感悟，谢谢思寒

再来看看

3 年后，这篇文章仍然那么欠赞~~~

怎么说呢，做英语培训的会夸大强调英语的作用，做考研培训的人也会先贩卖学历焦虑再来和你讨论考研培训的事情，所以做测试培训的人也会夸大测试的作用和未来的发展空间，可以理解。

学习了，继续思考

每次读 会有不同的收获

2022 年底读，还是非常有收获的。

16 年的文章，22 年底看仍有不小的收获，特意实名来点个赞。

收获颇多，引起再次思考。赞

六年前的文章，放在今天看仍然觉得分析的很到位，太牛逼了

几年前刚创建论坛的时候，还说过跟思寒大大打几把 dota，如果这几年早点卷出去小城市，是不是比现在混的强一点。

非常感谢，受教了。

感谢，很受启发

认真地看完了，认同度很高。

考古