首先我要说的是：培训已经有很多优秀的毕业生，我不希望因为培训这个标签，导致用人单位和求职者无法实现双向匹配，那将是非常可惜的。

最近在网上看到一条这样的消息，在程序员圈里引起了不小的轰动。

“我帮公司面试过一个32岁的程序员，就因为这一个细节，我一眼就看出来他是培训班毕业的，没什么工作经验……”

受过训练的程序员总是被误伤

不知道从什么时候开始，人们越来越看不起经过培训的程序员，主要原因是看不惯：基础差、学历低、水平差、学习能力弱、简历造假。

一些从培训机构出来的程序员确实存在问题，但我们不能因为“很多表现不佳的程序员恰好有过培训经历”就一概而论所有从培训机构出来的程序员。

其实，很多软件、互联网公司都有从培训机构毕业的程序员，而且很多都干得很好。

我是一个受过训练的前端人，并不会盲目地鄙视后端人。上面说的“鄙视”准确来说应该这样描述：

人们并不是瞧不起从培训机构走出来的程序员，而是瞧不起那些培训出来后没学好，基础差，做事不力，上进心不强，甚至还会作弊的程序员。

毕竟，想要通过努力工作赚取更高的收入、追求更好的生活并没有错。

但作为第一波程序员，我们也不能忽视年轻一代的缺点，我自己就很不能忍受一些训练有素的程序员的做法。

就拿简历、项目造假来说吧，我面试过很多人，包括很多经过专业训练的程序员，有时候面试官真的让人无话可说。

你只有半年的工作经验，却非要包装成两年的工作经验，你每天都加班，加班的时间算工作年限吗？

他们从来没有做过项目，却执意要编一个项目。很多人简历上的项目大同小异，甚至一模一样。比如很多人说自己做过电商项目，介绍的很溜，乍一听很有道理。但你不能问细节，比如数据库有多少个表？用了哪些开源jar包？日志是怎么写的？这些最基本的细节一问出来就会露出破绽。

明显是培训老师在帮学生准备面试稿，让学生提前背……这样的程序员谁敢雇？

你骗我骗他骗，大家都骗。骗人一时是开心的，但俗话说得好：好事不远传，坏事千里传。慢慢地，人们就会觉得培训机构的程序员都是假的，招聘的时候就不愿意录用了。

有些公司不再愿意雇佣受过培训的程序员。为什么？

每个人都想聘请一名优秀的程序员，对吧？但招聘一名优秀的人才需要花费大量的时间和精力。

假设30个专业程序员中可以选出1个优秀程序员，而由于能力、造假等原因，50个培训程序员中只能选出1个优秀程序员，那么大家都愿意节省时间和精力，从前者中招人。

IT行业最火爆的时代已经过去，程序员已经不那么稀缺了，一个岗位几百人竞争，这种情况下雇主本来就不缺简历，肯定会优先考虑高学历、受过专业培训的，这样既省时间，又能提高收益率。

作为程序员，最重要的是你的学习能力和技术水平，英雄出身并不重要。

不管你是北大、清华，还是北大青鸟。

如果你是一名训练有素的程序员，既然选择了一条路，就坚持下去。一开始可能会很坎坷，所以不要太在意别人对你的看法。

同时也警示我们：这个时代，没有什么是确定的，没有什么是容易的，只有努力工作，走出舒适区，才能获得真正稳定的工作。

如果你想知道如何自学自动化测试，那么首先要明白它是否值得学习？

我讲几点，如果你是从事这个行业的，你一定会明白我说的对不对。

1. 看似“衰落”的检测行业在过去发生了巨大变化

不懂技术的测试工程师会逐渐被淘汰。

测试工程师失业潮不可避免。虽然早期我也劝身边的人赶紧摆脱落后的业务体系和落后的测试技能，但看到很多人的日子越来越难过，也让人心痛。测试工程师的需求越来越少，招聘岗位也越来越少。典型的新兴巨头公司，比如早期是没有QA的，几年前甚至还闹过QA团队是否值得拥有的争论。表面看来，测试行业在没落。有意思的是，大家讨论QA团队是否值得拥有的初衷，是为了更好地保证质量，挺耐人寻味的。

大多数公司都非常支持QA部门的存在。问题在于QA团队的存在是否有价值。过去过时的测试体系、落后的测试人员能力、冗长的测试流程被整个IT行业所诟病。随着研发生产力逐渐提升、运维部署逐渐自动化，QA的价值和成本已经不容忽视，甚至成为了一个项目最大的成本。这是任何一家公司都无法忽视的问题。

早些年，阿里巴巴的高管曾到硅谷参观那些新兴巨头，得出的结论是他们的流程和执行力比国内强很多。甚至早些年，他们成长为一个没有QA的大公司，所以阿里巴巴迅速推行流程切割，包括取消SQA、需求分析师、项目经理、QA岗位，进入产品、研发、测试最简单的模式。QA会不会去掉，也要看这个部门的价值，所以不要想当然地认为“存在就是合理的”。

现在有些公司正在尝试“无QA”模式。互联网唯一不变的就是变化。比如搜索、推荐、机器学习等领域的算法测试是一个非常重要的领域，需要专业的测试工程师参与。这个行业可以容纳很多测试团队。但测试行业这几年一直没有形成针对这个领域的正确测试方法，最终失去了这个市场。

现在这个责任都落在了研发身上，因为很难找到合格的测试工程师来保障这个业务。性能测试领域也是一样，随着性能测试平台、全链路压测、性能监控、AB 、云压测等技术和服务的出现，性能测试工程师的需求也会萎缩，性能测试在越来越多的公司已经变成了研发主导，没有了这个业务，性能测试QA的需求自然会受到影响。

大家一定要记住，业务空间决定QA的生存空间，这是各行各业的共同道理，不能满足业务需求就会被淘汰，你要么选择退守，要么选择勇敢接受挑战。

测试行业的未来会是怎样的？很多人都在担心。但我总体上还是很乐观的。因为我喜欢整个行业，而且这些年来我一直在思考这个问题。我来告诉你我的看法。

2. 测试人员的规模

劳动力规模与生产率负相关，与企业规模正相关，未来到底有多大，取决于技术和企业规模的双重因素。

首先是宏观环境因素，随着各行业互联网化，IT行业在扩大，外卖、美甲，甚至无人机、汽车、航天等行业都成为科技公司，研发团队扩大，QA团队自然也会整体扩大。

前提是QA本身要与时俱进。其次，随着生产力的提高，自然就不需要那么多人了。每个行业都是如此，测试行业也不例外。就像汽车行业一样，早年是人堆起来的，后来是工具和技术堆起来的，用了机器人，改进了流程。​​行业技术、测试技术、测试工具、测试服务的改进，都会在一定程度上提高测试效率、降低成本。

这样的改进会让QA团队更加精简和高效，人多意味着每个人的价值都跟富士康工厂里的工人一样廉价，追求高附加值才是正道，这对公司和测试团队来说都是双赢。

第三个因素是行业地位。软件的火爆促进了研发和运维的紧密配合，这个阶段一旦做完，产品的生产部署就会非常顺利，问题暴露出来也会越来越早，大家也会更加注重质量。那时候我们会进入一个新的时代，运维会逐渐流水线化，Dev、QA会成为新的主角。但是到时候能撑起大局的可能不是现在的软件测试工程师，而是新时代的测试工程师。测试行业会越来越专业，人才会越来越多，技术、工具、开源平台、服务会越来越完善。每个职业都有自己的专长，专业分工还是大趋势。技术层面也会有创新，以前的测试只能留下测试用例、业务知识文档，没有任何持续的积累。 随着接口测试、质量监控、覆盖率分析、业务建模等技术的突破，QA也会形成自己稳定积累的业务数据，逐渐形成自己的平台和业务。业务空间+技术门槛的双重因素，是我坚信QA部门能够长久存在的一个核心因素。

3.检测行业管理将逐步扁平化

几乎所有的互联网公司都在拆分业务和QA团队，以提高执行力。因此，管理几百人的总监岗位会越来越少，管理不到100人的总监岗位会越来越多。不排除少数巨头还是不改初衷。又或者一些烧钱的创业公司逆势而行。这其中，这些测试经理会遇到一些新的挑战，比如大部分高层管理者都是研发出身，如果不懂研发体系，几乎没有发展空间。测试管理体系失去了上层建筑，对未来的影响还是深远的。阵痛会有，但结果一定会好。

测试技术人才需求增加的原因是多方面的。

由于拆分的问题，大公司不再有统一的测试技术支持部门，所以拆分后的每个团队都需要组建相应的职能团队，对测试技术人员的需求就会增加。中小型公司也要求质量保证的结果，不仅要更好，还要更快，也需要大量的技术人才。从近年来各招聘网站的职位描述中就可以看出这一点。

外包测试的灾难与重生

原来在欧美、日韩做外包业务的公司，会因为国内互联网的发展逐渐没落，需要转型来国内做业务。但是国内大部分公司也不愿意做外包业务，而且外包业务在效率、沟通、管理等方面都有很多弊端，无法支撑测试工程师的培养和长远发展。所以未来几年会有大量的外包测试工程师转型。这方面需要有新的、优秀的、能够有自己的测试服务、有自己的测试技术、有资深测试研究工程师的外包服务公司。比如东软也开始研发自己的云测试平台，这就是迎合新时代的转变。

6. 不懂开发的测试工程师在新时代已经是文盲了

第一是工作晋升空间不大，第二是跳槽难度大，最好的结果就是凭借着多年的经验跳槽到管理层。我跟业内很多测试经理交流过，大部分工作超过6年的人，都会对测试执行产生厌倦，在测试技术的提升上再也入不敷出，还不如招实习生，相对而言，有技术基础的人，工作8年以上，还是会保持学习的热情。所以未来测试团队的架构，基本就是大部分业务测试工程师+少数测试专家+测试经理的一个管理模式。以前看不懂字的就是文盲，后来看不懂英文的就是文盲，国家呼吁加强对IT技术的重视之后，新时代的文盲几乎就是不懂开发的人。社区成立的初衷，就是唤醒整个行业对测试技术的重视。

7. 检测行业门槛提高，此前处于发展阶段

行业对人才的苛刻要求是第一要务，现在大公司发展稳定了，招聘也稳定了，基本只招211高校的。社招也是看学历的，创业公司多是注重融资烧钱，对学历和经验也很看重。能无限制招到人才的公司会越来越少。我之前推荐过很多同学去其他优秀公司，有的技能不错，但是学历不够。所以希望大家能够重视这个技能和学历的问题，除了学历门槛，还有前面说的技术门槛。所以加油吧，小伙子！

8. 测试行业的薪资在增加

测试行业经过自身的净化后会重生，一个典型的变化就是薪资会从之前的3k-15k涨到1-3万之间，技术含量和责任心的提升必然会带来整体的回报，现在只要技术好，学历没问题，干3年拿两三万的月薪是常有的事，后面会详细说薪资问题。

9.研发工程师进入测试领域

这几年整个业界对测试行业的发展很不满，简单来说就是大家都觉得测试很低级，但是又不能没有测试。研发提交项目给测试的感觉就像过年在火车站排队买票一样，需要申请测试资源，给测试人员讲解业务和实现，遇到比较低级或者新进员工连环境都不会搭，还要一步步教。研发随便改一行代码，QA或者测试人员就炸了，各种流程足以让研发掉几根头发。作为参考和对比，想想运维，当年部署环境跟提交测试很像，要申请运维介入，申请机器资源，然后提交部署文档，还要明确基础环境、依赖库等各种细节的版本号。 遇到本地发布环境不行等问题，就得跟运维拼了。当年运维行业流行一句话，“人”才是最关键的发布保障。现在随着持续交付和运维的流行，发布变得“丝滑如丝”，一键发布、灰度自由选择，甚至正常发布都不需要运维的参与。尝到新模式的甜头后，测试行业的弊端也变得难以容忍。因此，在难以找到优秀的测试工程师和架构师的情况下，越来越多的公司选择直接用研发工程师，他们的追求很简单，单元测试->接口测试->基础冒烟测试，只要能自动化就行。如果能像运维一样做成测试即服务就更加完美了。了解了测试行业的现状，明确了前景之后，就要详细说说要学什么了。

我应该学习哪些有关自动化测试的知识？

首先，自动化测试很容易学！但是记住，一定要明确学习的方向，不要偏离轨道，白费力气。

第一，学一门语言。至于学什么语言，很简单，不用操心。首先看你有没有编程基础。如果没有/编程能力弱，有的话就选Java（难度比较大）。都可以。

第二，你要看看你的开发人员用什么语言，和开发人员使用同一种语言可以降低你和开发人员在学习自动化测试时的沟通门槛，增加你在公司中的话语权。

第三，学什么方向？我建议：web ui 自动化 => 界面自动化 => app 自动化/小程序自动化。当然重点学界面自动化。ui 自动化可以学，但没必要深究。

1. 盖楼必先打地基，首先要学一门语言。

正如我们上面提到的，要想做好自动化，你必须学习至少一种编程语言。当然，我应该学多少语言呢？我不能一直学下去，对吧？答案是，学会如何使用它！

掌握大部分基本语法就足以满足您日常的自动化需求，因为编写脚本并不像开发脚本那么困难！

需要学习语言，for循环，if判断，数据类型，运算符，面向对象编程等等，不管是Java也好，这些都是需要的，其实都差不多，懂一门语言，其他的也都差不多。

2.入门语言之后，就正式踏上自动化之路了。

作为自动化的鼻祖，它已经玩得够多了，基本上做自动化的人都知道它，我们为什么要先学它呢？

它能让你快速理解什么是自动化，并能给你直观的页面反馈。我也一点一点地看了一下 API，几乎尝试了所有的方法。

有1.0 2.0 3.0，建议大家在学习之前先了解一下它的历史和运行原理，这样才能激起学习的兴趣。学习的时候需要安装浏览器，强烈建议使用 代替前者，兼容性更强。

安装完成后需要安装驱动，恭喜你踩到自动化第一个坑了！大部分原因是因为你的驱动版本和浏览器版本不匹配，可以百度后你对su和kw印象深刻（学了就知道是啥了）

你会尝试各种方法，再次操作浏览器。这时候，仿佛新世界的大门打开了。哦！原来自动化测试是这么回事！太神奇了！

3. 玩累了

当你玩了几天或者几周之后，你似乎对它失去了兴趣，而你的脚本编写能力却越来越好，甚至可以写出一些线性的自动化脚本了。这时候，你心里有点得意洋洋，以为自动化不过如此，仅此而已？

我想说的是，别高兴得太早，你才刚刚踏进自动化测试的大门，迈出一小步。此时，你可以开始尝试把项目中的一些重复操作写成脚本，运行起来。你会感觉到很有成就感！自动化的成果初步形成，仿佛你已经开始了解如何利用自动化来提高效率。

4.开始接触自动化框架/

当你学会了单元测试框架之后，你会发现大部分线性脚本很难管理，每个脚本都需要一个一个的运行，无法统计测试结果，这时候就需要单元测试框架了！

你将开始学习如何使用单元测试框架，如何创建测试类，如何编写测试方法，如何将你的脚本编写为测试用例，如何验证测试是否通过，如何控制测试用例的执行顺序，以及如何编写断言。这些都是你需要探索和学习的。

5. 对单元测试框架的功能不满意

一旦你写出了出色的脚本并组织好了用例，每次你的领导让你进行测试时，你都应该将测试结果发送给他并以测试报告的形式进行总结。

这时候你一遍遍地打开编辑器，运行测试，然后飞快地跑测试，精疲力竭地一个个数着测试结果，然后把它们发给你的领导。

第二天，老板让我下班前再跑一次测试，给他做个报告。我当时感觉自己要死了一样。于是我开始浏览百度和论坛，想找解决办法，这时“框架”这个词就映入我的眼帘。

6.学习自动化框架

到了这一步，你开始搞清楚怎么写自动化框架了，说明你的自动化开始入门了，正在向中级迈进，你开始研究框架的结构，发现里面有用例管理，日志，测试报告，邮件，基础封装类等等，还有框架设计模式（经典的PO模式）

你开始整理你的用例，封装基类，编写页面类，封装日志，邮件模块等等，经过几周的打磨，你的第一个自动化框架诞生了！

这时候你就可以去各种技术群炫耀自己写了一个自动化框架了，很多新手也会开始奉承你，称你为大神。

7. 初始界面测试

以上就是UI自动化的学习结束，下面我们进入接口部分，公司大部分都是使用http接口，所以应该从http协议开始学习，了解它的结构，请求头，请求参数，请求地址，请求方法等，尽量学习一些抓包工具。

比如说浏览器的开发者工具等，抓包获取一些接口，慢慢观察它的请求结构，但此时还是一团迷雾，对接口的了解还很模糊。于是下载了一个接口测试工具，尝试着把参数输入到工具里，手动发起调用。

当工具返回200代码的时候，哦，原来是这么回事啊，好像是跟服务端进行数据收发，然后前端页面把数据显示到前台去！

8. 尝试学习/图书馆发起请求

用完之后你会想，我怎么用代码发起请求呢？这时候你就需要学会这两个东西了。pip&之后，你的接口自动化之旅就开始了。

你尝试用接口来实现前面增删改查的UI自动化，你把抓包的请求参数拿过来，一个个调用方法，然后一键运行就好了！一绿三红！为什么？然后发现接口返回了401，没有权限！哎呀！我还没登录，那怎么登录呢？？

带着很多疑惑开始研究，这时候就需要了解and的工作机制，然后配合你的代码进行缓存和登录了，解决了这个问题之后接口还是报错，我删除接口的时候提示我没有这个数据！

检查之后发现我输入的数据已经被使用了，那怎么保证每次输入的参数都是新的呢？这时候就需要了解接口关联，如何从上一个接口的中提取出参数，用于下一个接口。