首先,我说一句:培训出来的,优秀学员大有人在,我不希望因为带着培训的标签而无法达到用人单位和候选人的双向匹配,是非常遗憾的事情。
最近,在网上看到这样一个留言,引发了程序员这个圈子不少的轰动。
“帮公司面试了一个32岁的程序员,只因这一个细节,被我一眼看穿是培训班出来的,没啥工作经验...”
不知道从什么时候开始,大家是越来越看不上培训出来的程序员了,主要是嫌弃他们:基础不行、学历低、水平不行、学习能力弱、简历造假。
有些培训机构出来的程序员确实有问题,但是不能因为“只是很多表现不好的程序员恰好都有过培训经历”,就一棍子打死所有培训出来的程序员。
其实在很多软件、互联网公司里都有培训机构出来的程序员,这其中很多人干的还是不错的。
我自己就是培训出来的前浪,我不会跟风无脑的嫌弃后浪,上面说的那些“嫌弃”,准确的说应该是:
大家不嫌弃培训机构出来的程序员,而是嫌弃那些参加了培训没好好学、基础差、干活不行、不上进还造假的程序员。
毕竟想通过努力获得更高的收入,追求更好的生活,这没毛病。
但是呢,作为前浪也不能无视后浪们的缺点,对一些培训出来程序员的做法,我自己也看不下去。
就拿简历造假、项目造假来说吧,我面试过不少人,这里边包括很多培训出来的程序员,有的时候面试真的很无语。
明明只有半年工作经验,非得包装写成 2 年工作经验。你是天天加班,把加班时间都算成工作的年头了吗?
明明没做过项目,非要虚构项目。很多人简历中的项目都大同小异,甚至一模一样。比如不少人说做过电商项目,介绍的时候非常流畅,乍一听说的头头是道。但是不能问细节,比如问数据库大概多少张表?都用了哪些开源 jar 包?日志是怎么写的?这种最基础的细节,一问就露出破绽了。
这一看就是培训老师帮着准备面试的话术,让学员提前背熟练的……这种程序员谁敢招啊?
如果你造假,我造假,他也造假,大家都造假,造假一时爽。但是老话说得好:好事不出门,坏事传千里。慢慢的大家就会认为培训机构出来的程序员都是水货,招聘的时候都不愿意要。
现在已经有一些公司不愿意招聘培训出来的程序员了。为什么?
谁都想招聘一个优秀的程序员对吧,但是想招到一个优秀人才要花很多时间精力。
假设从 30 个科班程序员里能挑出一个优秀程序员来,由于能力和造假的原因,从 50 个培训程序员里才能挑出一个优秀程序员,谁都愿意节省时间精力,从前者里面招人
现在 IT 行业最火热的时候已经过去了,程序员没那么紧缺了,恨不得几百个人竞争一个岗位,这种情况下,用人单位反正也不缺简历,肯定优先从高学历、科班的人里选了——既省时间,良品率又高。
作为程序员来说,最重要的还是你的学习能力和技术水平,英雄可以不问出处,
不管你是来自于北大清华,还是来自于北大青鸟。
如果你是培训出来的程序员,既然已经选择了一条道路就坚持走下去,可能初期会坎坷一些,别太在意大家怎么看你。
同时,也是在警醒我们:这个时代,没有什么是确定的,也没有什么是容易的,我们只有努力奋斗,跳出舒适区,能能获得真正意义上的铁饭碗。
我谈一下几点,如果你处在这个行业,一定能体会到我说的对不对。
1、表面"衰落"的测试行业鉴于过去的大形势变化
不懂技术的测试工程师会逐渐被淘汰出局。
一波测试工程师的失业潮是在所难免的.虽然早期我也呼吁身边的人赶紧脱离落后的业务体系, 脱离落后的测试技能, 但是看到很多人越来越生活艰难, 也是挺心痛的。包括测试工程师的需求越来越少, 招聘职位也越来越少, 典型的新崛起的巨无霸公司比如facebook早期都没有QA。甚至前几年一度有QA团队是否值得存在的争论。表面看起来是测试行业衰落了。有趣的是大家讨论QA团队是否值得存在的初衷, 是为了更好的保证质量,这还是挺耐人寻味的。
绝大多数的公司, 都是非常支持QA部门的存在的, 问题在于QA团队的存在的价值到底是大还是小. 过去陈旧的测试体系, 落后的测试人员能力, 冗长的测试流程是被整个IT行业诟病的一个关键.当研发的生产力在逐渐的提升, 运维的部署在逐渐的自动化, QA所带来的价值和耗费的成本就越来越不能忽视了。 甚至成为了一个项目的最大的成本. 这是任何一家公司都无法忽视的问题。
早年阿里巴巴的高管曾经集体去硅谷拜访新崛起的巨无霸, 得到的结论就是他们的流程和执行力比国内强很多. 甚至facebook早年都没有QA就成长为大公司了,所以阿里就迅速推动了流程的裁剪,这部分包括裁撤SQA, 裁撤需求分析师, 裁撤项目经理, 削减QA名额。进入产品, 研发, 测试三足鼎立的最简模式。QA会不会被撤掉也取决于这个部门的价值,所以不要想当然的觉得"存在即合理",
现在部分的公司已经在试验"无QA"的模式了,互联网唯一不变的就是变化比如一个典型的例子, 在搜索, 推荐, 机器学习等方向的算法测试是很重要的领域, 是需要专业的测试工程师参与的。这个行业能容纳很多的测试团队。但是测试行业这些年就没形成对这个领域的正确测试方法, 结果最后丢失了这个市场。
现在都是研发自己保证了. 因为找不到合格的测试工程师去保证这个业务.同样在性能测试领域也是如此, 随着性能测试平台, 全链路压测, 性能监控, AB Test, 云压测这类技术和服务的出现, 性能测试工程师的需求也会缩小. 越来越多公司里的性能测试都已经变成研发主导了. 丢失了这块的业务, 性能测试QA的需求量自然会受影响。
一定要记住, 业务空间决定QA的生存空间, 这是所有行业都通行的道理. 如果你不能满足业务需求, 就会被淘汰出局, 要么选择退守防御要么选择勇于接受挑战。
那测试行业的未来是什么样的呢, 很多人会担心. 不过我还是整体乐观的.因为我喜欢整个行业, 这些年也一直在进行不断的思辨. 说下我的看法
2、测试从业人员的规模
从业人员规模跟生产力负相关, 跟业务规模正相关. 以后能有多大取决于技术和业务规模的双重因素.
首先是大环境因素, 随着各种行业的互联网化, IT行业在扩大, 外卖, 美甲, 甚至是无人机汽车航天产业都将成为科技公司. 研发的队伍会扩大, QA的队伍自然也会整体扩大.
前提是QA自己要跟得上时代.其次是随着生产力提升自然就不会需要这么多人的. 哪个行业都这样, 测试行业并不特殊. 就跟汽车行业一样. 早年堆人, 然后堆工具, 堆技术, 上机器人, 改进流程. 行业技术改进, 测试技术改进, 测试工具和测试服务的改进, 都会一定程度提高了测试效率, 减少了成本.
这种改进会导致QA的团队更精炼高效. 人数多意味着大家的价值跟富士康工厂里的工人一样廉价. 追求高附加值才是正确的路. 这对公司和测试团队都是双赢的.
第三个因素是行业地位, devops的流行是推动了研发和运维的密切合作. 一旦这个阶段完成, 产品的生产部署会非常的流畅. 随之而来的就是问题会越来越早的暴露, 大家对质量会更加的重视. 到时候就会进入一个新的时代, DevQA运维逐渐会管道化, Dev和QA会成为新的主角. 只是到时候能撑大局的不一定是现在的软件测试工程师了 会是新时代的测试工程师.测试行业会越来越专业. 人才, 技术, 工具, 开源平台, 服务会越来越多. 越来越完善. 术业有专攻, 专业化分工仍然是大趋势. 技术层面上也会有创新. 以前的测试只能留下测试用例和业务知识文档 没有什么连续性积累. 随着接口测试, 质量监控, 覆盖率分析, 业务建模等技术的突破, QA也会形成自己稳定可积累的业务数据, 并逐渐形成自己的平台和业务. 业务空间+技术门槛的双重因素是我坚信QA部门能长期存在的一个核心因素.
3、测试行业的管理会逐渐扁平化
几乎大部分的互联网公司都在分拆业务和QA团队从而提高执行力. 所以管理上百人的总监职位会越来越少, 而管理百人以下的总监会越来越多. 不排除少量的巨无霸仍然没有改变. 或者有些烧钱的初创公司倒行逆施. 其中这些测试管理者会遇到一些新的挑战, 比如更高层是研发出身居多. 不懂研发体系几乎没有发展空间了. 测试管理体系失去了上层建筑, 对未来的影响还是深远的. 会有阵痛, 但是结果肯定会是好的
4. 测试技术人才需求增多原因是多方面的
大公司因为分拆的问题. 不再有统一的测试技术支撑部门, 所以分拆之后的每个团队都需要组建对应的职能团队, 对测试技术人员的需求反而会增多. 中小型公司也苛求质量保证效果, 不止是要好, 而且要求更快, 也需要大量的技术人才。 这几年通过各种招聘网站的招聘job的描述也能看得出来
5. 外包测试的灾难和新生
原来做欧美日韩外包业务的公司会因为国内互联网的发展逐渐式微, 他们需要转型做国内.但是国内对外包业务也大多排斥, 而且外包业务在效率沟通管理上都有诸多弊端. 其自身也无法承载对测试工程师的培养和长期发展. 所以这几年会有大量的外包测试工程师转型. 这方面需要有新的优秀的外包服务公司.能做到有自己的测试服务, 测试技术和高级的测试研究工程师才行. 比如东软也开始做自己的各种云测平台之类的, 就是一种为了迎合新时代的变更.
6、不懂开发的测试工程师已经是新时代的文盲
第一个是工作上已经没有太大的晋升空间. 第二个是也很难跳槽. 最好的结果是凭借多年的经验转管理. 我跟行业的很多测试经理交流过, 大部分工作超过6年的人, 在测试执行上会倦怠, 在测试技术的改进上已经无法入门, 还不如招实习生. 相对来说, 有技术基础的人在工作8年以上仍然会保持自己的学习热情.所以未来测试团队的架构基本会是多数业务测试工程师+少数测试专家+测试经理的管理模式. 以前不识字的是文盲, 后来是不识英文的是文盲, 在继各国呼吁加强对IT技术的重视后, 新时代的文盲就已经快是不懂开发的人了.testerhome社区的成立的初衷就是希望唤醒整个行业对测试技术的重视.
7、测试行业的门槛增加以前处于发展期
行业对人才的苛求是第一位的. 现在随着大公司发展稳定, 招人已经稳定了.他们基本只在211院校校招. 社招也看学历. 初创公司多是融资烧钱为主, 在学历上和阅历上也是看的很高. 能够不拘一格降人才的公司会越来越少. 我之前推荐了不少同学去其他优秀的公司, 其中有一部分同学就是技术不错, 但是学历未过关. 所以希望大家技能和学历上能够好好的重视这个问题. 除了学历门槛, 如上一条所说技术门槛也存在. 所以加油吧, 少年!
8、测试行业的薪资在提高
测试行业经过自身的净化洗涤会有新生.典型的变化就是薪资从以前的3k-15k的范围, 整体提升到1w-3w之间. 技术含量的提升, 责任的提升必然会带来整体的回报. 现在只要技术好, 学历没问题. 工作3年拿个两三万的月薪是很平常的.后面会详细说薪资的方面。
9、研发工程师进入测试领域
这些年整个行业对测试行业的发展非常不满意, 通俗点讲, 大家都觉得测试很Low, 但是又不能没有。研发提交项目给测试的心情就跟以前过年要去火车站排队买票一样. 要申请测试资源, 给测试讲解业务和实现, 遇到比较low的或者新入职的, 连搭建环境都不会还得手把手教. 研发只是修改一行代码, QA或者测试那边就炸锅了.各种流程足以让研发头发都能掉好几根. 作为参考对比, 再思考下运维. 当年部署个环境跟提交测试很像. 要申请运维的介入, 要申请机器资源, 然后提交部署文档, 还要明确基础环境, 依赖库等各种细节的版本号. 遇到本地行发布环境不行之类的问题还得跟运维撕逼. 当年运维行业还流行着一句, "人"才是最关键的发布保证者. 而现在随着持续交付和devops的流行. 发布都已经做到"丝般柔滑"了, 一键发布,自由选择灰度,平时的发布甚至都不需要运维参与. 尝试了新模式的甜头后, 对测试行业的弊端已经很难忍受了. 所以在优秀的测试工程师和架构师难找的情况下, 已经有越来越多的公司选择直接用研发工程师来顶了. 他们的追求很简单. 单测->接口测试->基础的冒烟测试, 能够做到自动化就可以了. 如果能像运维那样做成测试即服务就更完美了.搞明白了测试行业的现状,明确了前景,那就要详细说说要学习哪些内容了。
首先,自动化测试,很好学!但是要记住,一定要明确学习的方向,不要剑走偏锋,白花力气。
第一,学习一门语言,至于学习什么语言的话,很简单,不用纠结,第一看你是否有编程基础,没有/编程能力弱选python,有的话选java(难度较高)、python都可。
第二,需要看你们的开发用的什么语言,和开发用同一门语言能在学习自动化测试的同时,降低你和开发之间沟通的门槛,提升你在公司的话语权。
第三,学习哪个方向?我建议:web ui自动化=》接口自动化=》App自动化/小程序自动化,当然,着重学习接口自动化,ui自动化要学,但是没太大必要深究。
1、盖楼之前先打好地基,首先需要学习一门语言
在上面我们也提到了,自动化要想做得好,必须要学习至少一门编程语言。当然至于学习语言要到什么程度了?我不可能一直学下去吧?答案是,会用就行!
掌握大部分的语法基础,已经能够满足你的自动化的日常需求了,因为我们写脚本并没有像开发那么难!
语言你需要学习,for循环,if判断,数据类型,运算符,面向对象编程等等,不管是java还是python,这些都是需要的,其实也差不多,会一门语言,其他的都类似。
2、语言入门后,正式踏上开始自动化成神之路,入门篇Selenium
selenium作为自动化的老祖宗,已经被玩烂了,基本上只要是做自动化的,无人不知无人不晓。为什么要先学习selenium?
它能帮助你快速理解,自动化到底是个什么东西,并且能直观的在页面上面反馈给你。咱当初也是,看着selenium的api,一点一点啃下来的,几乎每个方法都去尝试了一下。
selenium有1.0 2.0 3.0,建议你学习之前,先去了解以下它的历史,以及它的运行原理,这样可以勾起你的学习兴趣。你学习selenium,需要去安装浏览器,强烈建议使用Chrome而不是FireFox,前者兼容的更好。
安装好Chrome,你需要去安装驱动,恭喜你,这时候你就会踩到自动化的第一个坑了!大部分原因还是因为你的驱动版本和浏览器版本对不上。等能访问百度后,这里印象很深的su和kw(具体是什么等你学了就知道了)
你会再去尝试各种selenium的方法,去操作浏览器,这时候仿佛打开了新世界的大门,奥!原来自动化测试是这么个东西!真神奇!
3、玩腻了Selenium
等你玩了几天,或者几个星期之后,你好像对Selenium提不起什么兴趣了,脚本也写的越来越6,能写出一些线性的自动化脚本了,这个时候,有点骄傲自满,自动化不过如此,就这?
我想说的是,不要高兴的太早,你仅仅只是刚跨入自动化测试的大门,走了一小步而已。此时,你可以开始尝试,把项目中一些重复的操作,写成脚本去跑,满满的成就感有木有!自动化的成效初步形成,仿佛你开始懂得如何用自动化提升效率了。
4、开始接触自动化框架unittest/testNG
等你学会单元测试框架unittest/testNG,当你学会了selenium后,你会发现大部分的线性脚本,很难去管理,并且每个脚本需要去一个个run,而且还无法统计测试结果,这个时候,就需要单元测试框架登场了!
你会开始学习,单元测试框架的用法,如何创建一个测试类,如何写测试方法,如何把你的脚本写成测试用例,如何校验测试是否通过,用例的执行顺序怎么去控制,断言怎么去写,这些都是你要去探究学习的。
5、不满足于单元测试框架的功能
等你脚本写的很6,用例也会组织了,然后每次领导告诉你,跑一下测试,然后把测试结果发给他,要总结成测试报告的形式。
你这时候,屡次打开你的编辑器,run test,然后刷刷刷的跑完测试,一条一条的统计测试结果,累得半死,发给了领导。
第二天领导又说,下班前你再跑一下测试,给我份报告,想死的心都有了。那么你开始去逛百度,逛论坛,想要得到解决方法,那么“框架”一次就会映入眼帘。
6、学习自动化框架
此时,你已经开始琢磨如何写一个自动化框架出来了,那么说明你的自动化已经开始入门了,并且往着中级的方向发展,你开始研究框架的结构,发现有用例管理,日志,测试报告,邮件,基础封装类等等,还有一种框架的设计模式(经典PO模式)
你开始对你的用例进行整理,封装基类,编写页面类,封装日志,邮件模块等等,经过了几个星期的打磨,你的第一个自动化框架诞生了!
此时你可以去各个技术群去炫耀了,自动写出了一个自动化框架,很多小白也开始吹捧你,叫你大神了。
7、初始接口测试
以上结束了UI自动化的学习,那么下面到接口这边。一般公司用的都是http接口,那么你就从http协议开始学习了,了解它的结构,请求头,请求参数,请求地址,请求方式等等等,尝试学习一些抓包工具
如fiddler,chales,wireshark或者浏览器的开发者工具等等,去抓包获取一些接口,慢慢的观察它的请求构造,但是这时候还是云里雾里,对接口一知半解。于是下载了一个接口测试工具,尝试把参数录入到工具中,手动发起调用。
当工具返回200 code时,奥,原来是这么回事。好像就是和服务端来传递和接受数据的,然后前端页面会把数据展示到前台!
8、尝试学习Request/HttpClient库发起请求
在用完postman后,就会想到,那么我怎么用代码去发起一个请求呢?这时候就需要去学习这两个东西。pip install & import requests后,就开始了你的接口自动化之旅。
你尝试也是把之前ui自动化的增删改查,用接口来实现,你把抓包的请求参数拿过来,一个一个方法的调用,然后一键运行!一绿三红!为什么?然后发现接口返回了401,无权限!奥!我没有登入啊,那么怎么才能登入呢??
抱着很多的疑惑开始研究,这时候你需要去了解cookie和token的工作机制,再配合你的代码,去缓存cookie,达到登入。等解决了这个问题,但是接口还是报错了啊,删除接口提示我没有这条数据!
查来查去,原来是我那条数据已经用掉了,那么怎么可以保证我每次录入的参数都是新的呢?这时候就需要去了解接口关联,如何把参数从上个接口的响应提取出来,给下个接口用。
9、request/HttpClient结合unittest/testNG+allure
一样的,等你学会了 request/HttpClient,自然也会想到用单元测试框架把他们集成起来,然后又发现了一个高大上的allure测试报告,再结合一些日志模块打印参数,轻车熟路的这么一个接口框架就出来了,和之前的差不多!小意思。
10、尝试用yaml/Excel管理测试用例
等你拿自己的框架,重复枯燥的写着测试用例,这时候你想了,我为啥每次都要request.post,方法都是一样的,只是数据不一样,为什么我要一直写代码呢,很累啊!为什么不用一些文件来读取测试数据,做参数化呢?
这时候你开始研究读写excel/yaml了,你想把所有的测试用例都放在文件里管理,就不用每次去写代码了,然而事情并没有那么简单!那么我在文件里如何去处理关联数据呢?如何去缓存cookie呢?如何做断言呢?如果做一些动态的输入呢?
11、高级货?git?jenkins?docker容器?分布式?
走到这一步,你已经写过好几个框架了,并且基于自己的框架做了优化,那么你此时发现一个很严重的问题,我的代码居然只能在我本地运行,如果要给别人用,还需要去别人电脑上配置环境,copy代码给他。
那么为什么不用一些代码管理工具去管理我的脚本呢?那么就会需要去学习git,了解如何add commit push推送我的代码到公司的gitlab,这样别人也可以使用,那么有了gitlab,我想做一些定时任务,让它自动执行呢?
学jenkins。再更多,要是我想多个用例一起跑呢?学习selenium grid,docker等等
12、自动化顶端之测试平台/工具开发
等你搭建好公司的自动化生态,你还是不满足,我为什么不把这些东西可视化管理呢?做个平台?管理用例,管理任务,管理测试报告?我还可以把公司的一些部署任务也集成过来?
想法很好!此时的你已经不仅仅是一名优秀的自动化工程师了,已经迈向了测试开发的道路!开始学习,了解了测试框架httprunner,开发框架django/flask/springboot,懂得了接口开发的流程,了解了mybatis,shiro,quartz等等,开始学习前端
vue/react,懂得了什么是组件开发,父子组件传值,开始了解很多东西,甚至运维方面的知识,开始了解k8s docker,微服务。。那么你越来越往着大神的方向去了,希望你还没有秃头,此时的你可以骄傲的称自己为一名合格的测试开发,或者叫全栈开发了有木有!到此告一段落。
以上就是我个人,也相信是大部分学习自动化测试的一个学习路线,当然本次没提到一些App端/小程序端的自动化测试,其实也都大致类似。
软件测试是IT相关行业中最容易入门的学科~不需要开发人员烧脑的逻辑思维、不需要运维人员24小时的随时待命,需要的是细心认真的态度和IT相关知识点广度的了解,每个测试人员从入行到成为专业大牛的成长路线可划分为:软件测试、自动化测试、测试开发工程师 3个阶段。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取