有这么个普遍现象
测试招聘者，特别是一、二线互联网公司的招聘者最苦恼的事儿就是招人。找到一个合适的人，难于上青天，每天各种撒网，简历看几百份，面大几十人，能捞到一个中意的小伙伴就谢天谢地了。很多测试小伙伴发现找工作很难，特别是进大一点的厂，他们特别挑：代码要会写，要有软件架构能力，问一大坨平时根本用不到的技术问题，还挑经验，挑沟通能力，挑这挑那，有时候还特么挑学历、挑年龄。。。 供求总难以匹配起来，造成了双方都很痛苦。
Why？
能力要求不匹配是最核心的问题。软件、互联网近20年来飞速成长，其实也经历了很多阶段。行业软件兴盛阶段和外包兴盛阶段行业进入了大量的测试人员，当时最主流的测试实践是：重心基本放在系统验收阶段。测试人员的工作重心基本放在了基于业务的黑盒测试上，对代码能力、系统理解的能力要求不多。2010年后，互联网行业的真正兴起让国内软件开发模式开始缓慢掉头，快速迭代的模式逐步兴起，开发周期越来越短，迭代越来越快。原来的测试工作模式和工作范围越来越无法满足要求了。但大量从业人员技能范围转变是一件很难的事情，行业是有巨大惯性的，从宏观上看大量QA技能转变跟不上需求转变是造成市场供求不匹配的主要原因。
So What?
三个观点：
1. 只做手工测试，不懂系统实现的测试工程师的职业发展会越来越受限。
2. 能够转型成适应市场需求的同学能够在近几年的时间内获得超额回报（因为市场供不应求，企业不得不抬高价格来寻找这样的人）。
3. 对于个体来说，自我成长永远最重要，自己永远要对自己的发展负责，别依赖外部环境，自己想办法变成市场的香饽饽才靠谱。
到底什么样的人抢手？
按照我一点理解说一下什么样子的人会抢手吧，偏重技术角度来讲。个人之见，欢迎讨论和拍砖。
•测试的底子-项目经验
有比较复杂系统的测试实战经验，你就超过了50%以上的应聘者。什么叫做比较复杂系统呢？投入50人年开发出来的系统就可以称作一个复杂系统了。因此，复杂系统并不是很罕见。但是，如果你只接触一个简单的模块，甚至只是测试一个稳定模块的维护性开发，而不是通盘理解，不能说是测试过复杂系统。
•测试的底子-基础知识
对照三本书：《ISTQB基础教程》 《ISTQB高级测试设计》 《ISTQB高级测试管理》。这里边的内容你都能熟练应用（真的是熟练应用，而不只是有概念），你就能超过80%以上的应聘者了。面试过数百人，我经常会问几个问题：如果测试时间不够，你会怎么办？ 如果让你去测试一个你完全不熟悉的系统，你会怎么办？你平时会使用那些测试设计方法？ 看似很稀松平常的问题，非常考验人。因为大部分从业者，都没有经受过系统训练和学习，工作多年，依然技能不足，意识跑偏。
•熟练使用一门主语言
满足这条，你就超过了70%的应聘者。什么叫做熟练呢？拿Java来说吧：系统学习过Java的教程，高频面试50题 这样的题可以自测一下，可以回答上35个以上；熟悉最主流的Spring框架，能够写出一个简单的网站，实现基础的rest 服务；读懂过一个测试框架，如mockito或者Junit的源码；能够熟练实施接口测试（基于一些测试框架 rest-assured+Junit）；能够读懂开发的业务代码，对他们的代码进行Code Review。
•对一门语言有比较深入了解
满足这条，你就超过了90%的应聘者。什么叫有深入了解呢？还拿Java来说吧：熟悉Java的常见API；深入理解基于语言特性/系统特性的知识，如Collections的实现机制、类型系统、I/O、网络、多线程等；熟知设计模式（广义范围的设计模式，不局限于GOF的设计模式）；熟悉JVM的工作模式；熟练使用调试排查工具解决性能问题；熟练掌握市面上常见的脚手架；熟练掌握周边知识（OPS相关，网络知识相关）有不错的实战开发经验（做过真正被生产检验的东西）；对于测试开发，AOP，Java字节码技术是很重要的知识。。。 这是一个很长的学习list，需要几年时间来养成。做到这点，你可以通过一个普通的开发岗位了，这也是一个高级测试开发岗位的技术底子。
•在一个领域知识有不错的了解
人不可能什么都懂，但工作几年之后，会在工作的域内一定要有积累才行。
例如，你测试一个核心电商系统的交易模块三年了，业务上你一定要熟练讲出来：商品列表、购物车、下单、退单、废单、支付、发货、库存、退款、优惠使用等等一坨业务流程，和可能出现的常见的坑（各类问题产生的资损、各类问题产生的服务不可用、逻辑矛盾），不然根本无法体现你经验沉淀和深入思考；从技术山你要能够画得出来系统的交互图，熟悉最核心的接口和最核心的参数，能够读懂开发的代码，熟练使用trace和监控工具，诊断定位线上问题到代码行。
•用技术保障质量的能力
测试开发岗一定会问到一个问题：你能够举一个你用技术手段提高测试效率，增强测试能力的例子么？这是面试时最大的一个坎。 很多人会讲一些自动化测试回归的例子，但是真正成功的例子非常少，因为为什么做，怎么做都没有想好就照网上一个教程攒了一个，结果变成了玩具。 做好自动化，不仅仅是会使用工具、框架，其实要对被测物特性，软件生命周期有很深的理解并且有很强的开发知识才行。其实在 环境、CI、数据、测试用例生成、数据比对的很小的一些点上，都能有不错的提效产出，从这些点能够做得好，会得到不错的加分。有一个不错的成功案例，你胜出的几率就超过了80%，没有短板，就十拿九稳了。
•技能以外的东西- 实战案例
以前的工作印证了你的能力。能够讲清楚一项特别拿得出手的工作，证明你能力的工作。一般有如下特质会大大加分：快速学习、系统性学习、学以致用、系统性思考、强大的推动力、技术思维、突出的沟通能力、条理性、抗压性、抗挫折能力、迅速调整的能力、迭代改进的意识、wonership、愿景和规划。 这些特性体现人的内核，有强大内核的人，做什么都行，技能暂时不足，也一定能补足。所以，在招聘的时候往往对是否录用的判断起决定性作用。
高段位要求（高级职位需求）
•计算机领域知识的通盘理解
这条范围非常大，人不可能什么都懂。但最最基础的知识是不能有盲点的：
操作系统工作基础原理与基础操作：如linux，要通读过linux操作系统的书，熟悉最基本的概念，基本命令要熟悉，shell要能写和读；
网络知识特别是TCP/IP, HTTP知识：推荐两本书 《图解tcp/ip》 《图解Http》这两本书里的东西要懂。
数据库知识：市面常见数据库（redis，mysql，oracle）的常见OP操作，问题排查；SQL的熟练使用；
Web及移动端知识：能够懂HTML，CSS，能够读懂Javascript代码，能够读懂android或者iOS的代码，做简单开发最好。
安全知识：常见的安全防护方法、工具使用；基本的安全攻防原理；
软件工程/开发过程管理：实战中各种磨练，建议系统的学习PMP，敏捷开发的一些认证课程。
•在一个域的深耕
人不可能什么都懂，但在一个领域是需要深耕的。比如，在做了四、五年移动端测试以后。基本上android和iOS都要具备一定的开发能力了，能读懂开发的业务代码是最基础的，能够代替开发实现部分业务功能，完成部分组件开发是个自检点。能够对移动端自动化工具栈、监控工具栈（如友盟、bugly、newrelic等）、内存泄露检测、卡顿检测、耗电量、弱网、流量、埋点、灰度、版本控制、兼容性、用户体验、安全等等的质量保障方案有通盘搞定能力。
什么叫搞定呢？举个例子：比如，使用多种手段把崩溃率降低到千分之一以下。对于一个小团队，这是个很不容易实现的坎。做到这点，你需要了解如何收集崩溃率，如何使用一系列工具来定位核心问题，如何推动开发改动，并且预防（静态代码扫描工具引入，阻止乱用第不成熟的第三方插件，代码reivew防止常见pattern如空指针引发的崩溃，推动开发养成良好的log习惯，推动移动端防御性编程编程开发习惯，推动后端开发按照规范吐接口，帮助开发引入内存泄露、卡顿工具，趋势报表，警钟长鸣，各种灰度方式设置，线上监控。。。一个数据的改观，背后要有大量的质量相关工作）。
•使用综合手段来保障软件质量提升效能的能力。
听起来很抽象，举几个例子吧。
例子1：你所在的team总在被开发抱怨测试用的时间太长。你想，如何能缩短一下测试时间呢？
通过调研，发现测试小伙伴诟病的最多的就是环境不可用。环境到底多不可用呢？
你基于Grafana和Prometheus做了一个环境可用的监控报表，使用后，发现环境在工作日整体可用时间为35%左右，主要原因是：2个核心热点应用经常挂了没人管。
你拉了整个team，明确了部署责任人，约定了部署规则：只能中午饭和晚饭时间部署，并且部署后要自己看一下是不是OK。
一周后，环境可用度上升到了65%。再深入分析，发现2个同学不守规矩，总是他们在破坏规则，你去找他们单独谈话。
一周后，环境可用度上升到了80%。还是有少量人不守规矩。
你找SRE的同学提需求，做了部署卡点，非部署时间部署必须TL审批。
一周后，环境可用度上升到了85%。有些TL也不守规矩。
你建了个报警，环境乱部署，坏掉了，在大团队的群里@全体，告知谁搞坏了环境。
一周后，环境可用度达到了92%。
你加了一段时间无人响应，自动重启服务功能，仍然有问题，自动回滚上一版本功能。
你推动了开发解决了某个应用启动时间过长的问题。
你推动了环境分组。
你推动了测试环境版本上线的规范流程实施。
你推动了冒烟自动化用例卡点。
你推动了环境部署人备份机制。
你推动了全员基础环境部署培训。
你总结了部署手册。
你做了。。。。。
最后，环境可用度稳定到了97%以上。你为测试节省了60%以上block时间（原来可用度未35%）。
例子2：上面的问题，除了环境，还有一个槽点：开发提测质量不高。测试的头几天，很多主流程都走不通，导致测试总是在等待，或者是跟着开发一起联调。而这段时间，已经被习惯性的认为是测试时间了，因为：提测了。
你推动了：测试提供冒烟用例，开发必须完成一定程度的自测才能提测。
你推动了：测试和开发做自动化同期共建，在开发过程中，核心功能就被自动化用例保护起来了。
你推动了：开发切分feature提测，而不是攒一个大招一下子提一坨。
你推动了：代码Codereview变成团队常规活动，QA在早期跟进核心代码，把问题坑杀在萌芽阶段。
你推动了：外部资源联调非常早的进行，不会让它在测试后期成为测试blocker。
。。。
例子3：你发现测试时间长，测试自己也有问题。
你推动了：测试依据风险测试，最大的风险得到最快的cover，科学分配时间，明显缩短bug反馈时间弧。
你推动了：bug严格管理，所有bug都及时修复。
你推动了：良好的沟通和汇报机制，每天让团队主要干系人清晰的知道，距离发布还差多远。
你推动了。。。。
你能讲出自己做过5个以上这样的成功例子，我敢保障，你会被1线大厂疯抢。职级基本都是专家起。
•持续学习能力和复杂问题解决能力
例子1：
你近期的工作是帮助团队提升后台服务稳定性。你看到了netflix内部使用一个叫做ChaosMonkey的东西来随机对生产服务期进行攻击，而逼迫工程师提高稳定性，所以，你也实现了类似（更温和）的内部机制，推动团队稳定性的提高。
你怎么知道这个叫做ChaosMonkey的东西呢？ 因为你会习惯性浏览一线厂商的技术博客，参与行业大会，关注各类新技术。持续性的养成习惯。
例子2：
做大规模接口自动化好难，外部数据依赖太难搞，参数构造太费劲，assert太难写。如果能够简单的录制回放就好了。
但是，外部依赖是个天坑，写操作mock也是个天坑，assert也是个天坑。
实际的案例是，经过几年多个团队持续不屑的填坑，阿里内部已经有应用级的录制回放工具了，数百个应用成功的是用了它，把不可能回归的任务变成了可能（上万数量级的case当天生成，当天投入使用，并可以分析覆盖率），自动化测试实施需要付出的工作时间革命性降低（不足原来付出时间的10%）。
你能讲出自己做过5个以上这样的成功例子，我敢保障，你也会被1线大厂疯抢。职级基本都是专家起。
•其它能力
测试是个万金油，高阶一些的职位需要什么都要会一些， ，因为越高阶的职位需要解决的问题越综合，需要打交道的人的种类越多。不然很容易变成你职业短板，做个list吧：
很好的项目管理能力，至少与开发经理能力同级，甚至要强于他。
一定的软件架构能力。
一定的产品sense：可以跟一个资深的产品经理能够顺畅的交流，明白知道他为什么会这么想，所要实现产品的意义，路径；从产品质量方面的考虑要超过产品经理，给他输出。
极好的沟通能力。
团队管理能力（这个太重要）
目标管理能力
有一个好的内核（上面提到过）
怎么转型/怎么进阶？
其实不难，没有什么高端的方法。下面这4条就够了，核心秘密就是坚持不懈。
•熟悉你的被测系统，熟悉你的被测系统，熟悉你的被测系统。能够从技术、业务角度做到对被测系统熟悉是做一个好QA的最基本职业素养，也是能力提升的最主要源泉。
自检点：我能够画出系统的架构图么？我能够读懂开发的代码么？我熟悉常见的业务监控系统么？熟悉日志系统么？知道开发是如何调试和定位问题的么？给你一个线上问题，你能定位么？能给别人完整的介绍这个域的核心业务么？你能发布上线一个系统么？知道如何回滚么？灰度是如何做的？ 我知道一些关键的技术点：一个交易的幂等性是如何实现的？我在团队中有：“这家伙对系统最熟”的口碑么？
如果自检点全部是否定答案。。。 花一年时间把它全变成肯定答案。这一过程，你一定被迫学到了很多很多。 如果说做不到，后面不用看了，前面的也全部忘掉吧。
方法：通读所有文档，强迫自己读代码，积极参与开发所有讨论，不懂的狂问，观察开发如何上线，如何排查问题，模仿，学习，善用搜索引擎，总结。。。
•找到问题解决问题，找到问题解决问题，找到问题解决问题。你一定有一堆问题，如果你觉得自己做得挺好，没有问题要解决，那一定是你自己有巨大的问题！
自检点：找一支笔，写出你觉得质量刚面，你的team的10个问题，做排序。排出最重要的3个。
方法：如果找不出来，使劲去观察，然后去看看做的好的同行，比比你比人家差在哪里。尝试去解决这些问题，从小问题，能够见到效果的问题入手，设置一个时间点。你真正解决了5个以上问题以后，感觉一定会有。
•系统学习，系统学习，系统学习
自检点：我系统的学过一门知识么？我能讲清楚我这么操作，我写的这行代码的原理么？
方法：从工作出发，确认你需要补足什么知识。从网上找一个某个具体知识的学习路线图，订个计划，照着来。 参加学习小组，找到帮你解决难题的人，多请他吃饭，多请教他。获取知识后，马上回到工作中做检验。还是学以致用才能。
•选择有挑战的团队，选择有挑战的团队
自检点：在团队里有很多人比我强么？周围的同事都是我佩服的么？
方法：如果这两点都是否定的，并且你处于职业生涯的早期。也许（只是也许），你该考虑一下换个团队了。
总结
偏重技能角度讲了讲市场的需求和QA如何做如何满足市场需求。行文仓促，认识有限，其实也并没有什么新东西。欢迎讨论拍砖啊：）
