测试招聘者，特别是一、二线互联网公司的招聘者最苦恼的事儿就是招人。想找到一个合适的人难于上青天，每天各种撒网，简历看几百份，面大几十人，能捞到一个中意的小伙伴就谢天谢地了。但同时很多测试小伙伴发现找工作很难，特别是进大一点的厂，他们特别挑：代码要会写，要有软件架构能力，问一大坨平时根本用不到的技术问题，还挑经验，挑沟通能力，挑这挑那，有时候还特么挑学历、挑年龄。。。 供求总难以匹配起来，造成了双方都很痛苦。
能力要求不匹配是最核心的问题。软件、互联网近 20 年来飞速成长，其实也经历了很多阶段。行业软件兴盛阶段和外包兴盛阶段（2000-2010 年）行业进入了大量的测试人员，当时最主流的测试实践是：重心放在系统验收阶段。测试人员的主要工作基本都投入在了基于业务的黑盒测试上，对代码能力、系统理解的能力要求不多。2010 年后，互联网行业的真正兴起让国内软件开发模式开始缓慢调头，快速迭代的模式逐步兴起，开发周期越来越短，迭代越来越快，但系统越来越庞大、复杂。原来的测试工作模式和工作范围越来越无法满足要求了。但大量从业人员技能范围转变是一件很难的事情，行业是有巨大惯性的。从宏观上看大量 QA 技能转变跟不上需求转变是造成市场供求不匹配的主要原因。
三个观点：1. 只做手工测试，不懂系统实现的测试工程师的职业发展会越来越受限。2. 能够转型成适应市场需求的同学将在近几年的时间获得超额回报（因为市场供不应求，企业不得不抬高价格来寻找这样的人）。3.对于个体来说，自我成长永远最重要，自己永远要对自己的发展负责，别依赖外部环境，自己想办法变成市场的香饽饽才靠谱。
按照我一点理解讲一讲什么样子的人会抢手吧，限于篇幅会偏重技术角度来讲。个人之见，欢迎讨论和拍砖。
测试的底子 - 项目经验
有比较复杂系统的测试实战经验，你就超过了 50% 以上的应聘者。什么叫做比较复杂系统呢？投入 50 人年开发出来的系统就可以称作一个复杂系统了。因此，复杂系统并不是很罕见。但是，如果你只接触一个简单的模块，甚至只是测试一个稳定模块的维护性开发，而不是通盘理解，不能说是测试过复杂系统。有从头到尾接触一个完整项目的经历很宝贵。
测试的底子 - 基础知识
对照三本书：《ISTQB 基础教程》《高级软件测试设计》《高级软件测试管理》（后两本是 ISTQB 的高级认证教程）。这里边的内容你都能熟练应用（真的是熟练应用，而不只是有概念），你就能超过 80% 以上的应聘者了。面试过数百人，我经常会问几个问题：如果测试时间不够，你会怎么办？ 如果让你去测试一个你完全不熟悉的系统，你会怎么办？你平时会使用那些测试设计方法？ 看似很稀松平常的问题，非常考验人。因为大部分从业者都没有经受过系统训练和学习，工作多年，依然技能不足，意识跑偏。
熟练使用一门主语言
满足这条，你就超过了 70% 的应聘者。什么叫做熟练呢？拿 Java 来说吧：系统学习过 Java 的教程，高频面试 50 题 这样的题可以自测一下，可以回答上 35 个以上；熟悉最主流的 Spring 框架，能够写出一个简单的网站，实现基础的 Restful 服务；读懂过一个测试框架，如 mockito 或者 Junit 的源码；能够熟练实施接口测试（基于一些测试框架 如：rest-assured+Junit）；能够读懂开发的业务代码，对他们的代码进行 Code Review；
对一门语言有比较深入了解
满足这条，你就超过了 90% 的应聘者。什么叫有深入了解呢？还拿 Java 来说吧：熟练使用 Java 的常见 API；深入理解基于语言特性/系统特性的知识，如 Collections 的实现机制、类型系统、I/O、网络、多线程等；熟知设计模式（广义范围的设计模式，不局限于 GOF 的设计模式）；熟悉 JVM 的工作模式；熟练使用调试排查工具解决性能问题；熟练掌握市面上常见的脚手架；熟练掌握周边知识（OPs 相关，网络知识相关）有不错的实战开发经验（做过真正被生产检验的东西）；对于测试开发，AOP，Java 字节码技术是很重要的知识。。。 这是一个很长的学习 list，需要几年时间来养成。做到这点，其实你可以胜任普通的开发岗位了，这也是高级测试开发岗位的技术底子。
在一个领域知识有不错的了解
人不可能什么都懂，但工作几年之后，会在工作的域内一定要有积累才行。
例如，你测试一个核心电商系统的交易模块三年了，业务上你一定要熟练讲出来：商品列表、购物车、下单、退单、废单、支付、发货、库存、退款、优惠使用等等一坨业务流程，和可能出现的常见的坑（各类问题产生的资损、各类问题产生的服务不可用、逻辑矛盾），不然根本无法体现你经验沉淀和深入思考；技术角度上，你要能够画得出来系统的交互图，熟悉最核心的接口和最核心的参数，能够读懂开发的代码，熟练使用 trace 和监控工具，诊断定位线上问题到代码行。
用技术保障质量的能力
测试开发岗一定会问到一个问题：你能够举一个你用技术手段提高测试效率，增强测试能力的例子么？这是面试时最大的一个坎。 很多人会讲一些自动化测试回归的例子，但是真正成功的例子非常少，因为为什么做，怎么做都没有想好就照网上一个教程攒了一个，结果变成了玩具。 做好自动化，不仅仅是会使用工具、框架，其实要对被测物特性，软件生命周期有很深的理解并且有很强的开发知识才行。实际上，在环境、CI、数据、测试用例生成、数据比对的很小的一些点上，都能有不错的提效产出，从这些点能够做得好，会得到不错的加分。有一个不错的成功案例，你胜出的几率就超过了 80%，没有短板，就十拿九稳了。
技能以外的东西- 实战案例
以前的工作印证了你的能力。能够讲清楚一件特别拿得出手的工作，证明你能力的案例是面试时候最有用的投名状。
技能以外的东西 - 你的个人特质
一般有如下特质会大大加分：快速学习、系统性学习、学以致用、系统性思考、强大的推动力、技术思维、突出的沟通能力、条理性、抗压性、乐观精神、抗挫折能力、迅速调整的能力、迭代改进的意识、ownership、团队合作、愿景和规划。 这些特性体现人的内核，有强大内核的人，做什么都行，技能暂时不足，也一定能补足。所以，在招聘的时候往往对是否录用的判断起决定性作用
计算机领域知识的通盘理解
这条范围非常大，人不可能什么都懂。但最最基础的知识是不能有盲点的：
操作系统工作基础原理与基础操作：如 linux，要通读过 linux 操作系统的书，熟悉最基本的概念，基本命令要熟悉，shell 要能写和读；
网络知识特别是 TCP/IP, HTTP 知识：推荐两本书《图解 tcp/ip》《图解 Http》这两本书里的东西要懂。
数据库知识：市面常见数据库（redis，mysql，oracle）的常见 DBA 操作，问题排查；SQL 的熟练使用；
Web 及移动端知识：能够懂 HTML，CSS，能够读懂 Javascript 代码，能够读懂 Android 或者 iOS 的代码，做简单开发最好。
安全知识：常见的安全防护方法、工具使用；基本的安全攻防原理；
软件工程/开发过程管理：实战中各种磨练，建议系统的学习 PMP，敏捷开发的一些认证课程。
在一个域的深耕
人不可能什么都懂，但在一个领域是需要深耕的。比如，在做了四、五年移动端测试以后。android 和 iOS 都要具备一定的开发能力了，能读懂开发的业务代码是最基础的，能够代替开发实现部分业务功能，完成部分组件开发是个非常好的自检点。能够对移动端自动化工具栈、监控工具栈（如友盟、bugly、newrelic 等）、内存泄露检测、卡顿检测、耗电量、弱网、流量、埋点、灰度、版本控制、兼容性、用户体验、安全等等的质量保障方案有通盘搞定能力。
什么叫搞定呢？举个例子：比如，使用多种手段把崩溃率降低到千分之一以下。对于一个小团队，这是个很不容易实现的坎。做到这点，你需要了解如何收集崩溃率，如何使用一系列工具来定位核心问题，如何推动开发改动，并且预防（静态代码扫描工具引入，阻止乱用第不成熟的第三方插件，代码 reivew 防止常见 pattern 如空指针引发的崩溃，推动开发养成良好的 log 习惯，推动移动端防御性编程编程开发习惯，推动后端开发按照规范吐接口，帮助开发引入内存泄露、卡顿工具，趋势报表，警钟长鸣，各种灰度方式设置，线上监控。。。一个数据的改观，背后要有大量的质量相关工作）。
使用综合手段来保障软件质量提升效能的能力。
听起来很抽象，举几个例子吧。
例子 1：你所在的 team 总在被开发抱怨测试用的时间太长。如何能缩短一下测试时间呢？
通过调研，发现测试小伙伴诟病的最多的就是环境不可用。环境到底多不可用呢？
你基于 Grafana 和 Prometheus 做了一个环境可用的监控报表，使用后，发现环境在工作日整体可用率只有 35% 左右，主要原因是：几个核心热点应用经常挂了没人管。
你拉了整个 team，明确了部署责任人，约定了部署规则：只能中午饭和晚饭时间部署，并且部署后要自己看一下是不是 OK。
一周后，环境可用度上升到了 65%。再深入分析，发现 2 个同学不守规矩，总是他们在破坏规则，你去找他们单独谈话。
一周后，环境可用度上升到了 80%。还是有少量人不守规矩。
你找 SRE 的同学提需求，做了部署卡点，非部署时间部署必须 TL 审批。
一周后，环境可用度上升到了 85%。有些 TL 也不守规矩。
你建了个报警，环境乱部署，坏掉了，在大团队的群里 @ 全体，告知谁搞坏了环境。
一周后，环境可用度达到了 92%。
你加了一个 feature：应用挂了一段时间无人响应，自动重启服务功能，仍然有问题，就自动回滚上一版本。
你推动了开发解决了某个应用启动时间过长的问题。
你推动了环境分组。
你推动了测试环境版本上线的规范流程实施。
你推动了冒烟自动化用例卡点。
你推动了环境部署人备份机制。
你推动了全员基础环境部署培训。
你总结了部署手册。
你做了。。。。。
最后，环境可用度稳定到了 97% 以上。你为测试节省了 60% 以上 block 时间（原来可用度为 35%）
例子 2：上面的问题，除了环境，还有一个槽点：开发提测质量不高。测试的头几天，很多主流程都走不通，导致测试总是在等待，或者是跟着开发一起联调。而这段时间，已经被习惯性的认为是测试时间了，因为：提测了。
你推动了：测试提供冒烟用例，开发必须完成一定程度的自测才能提测。
你推动了：测试和开发做自动化同期共建，在开发过程中，核心功能就被自动化用例保护起来了。
你推动了：开发切分 feature 提测，而不是攒一个大招一下子提一坨。
你推动了：代码 Codereview 变成团队常规活动，QA 在早期跟进核心代码，把问题坑杀在萌芽阶段。
你推动了：外部资源联调非常早的进行，不会让它在测试后期成为测试 blocker。
。。。
例子 3：你发现测试时间长，QA 自己也有问题。
你推动了：有明确的测试计划，并让所有干系人都有明确的预期。
你推动了：测试依据风险测试，最大的风险得到最快的 cover，科学分配时间，明显缩短 bug 反馈时间弧。
你推动了：bug 严格管理，所有重要 bug 都及时修复。
你推动了：良好的沟通和汇报机制，每天让团队主要干系人清晰的知道，距离发布还差多远。
你推动了。。。。
你能讲出自己做过 5 个以上这样的成功例子，我敢保障，你会被 1 线大厂疯抢。职级基本都是专家起。
例子 1：
你近期的工作是帮助团队提升后台服务稳定性。你看到了 netflix 内部使用一个叫做 ChaosMonkey 的东西来随机对生产服务期进行攻击，而逼迫工程师提高稳定性，所以，你也实现了类似（更温和）的内部机制，推动团队稳定性的提高。
你怎么知道这个叫做 ChaosMonkey 的东西呢？ 因为你会习惯性浏览一线厂商的技术博客，参与行业大会，关注各类新技术。持续性的养成习惯。
例子 2：
做大规模接口自动化好难，外部数据依赖太难搞，参数构造太费劲，assert 太难写。如果能够简单的录制回放就好了。
但是，外部依赖是个天坑，写操作 mock 也是个天坑，assert 也是个天坑。
实际的案例是，经过几年多个团队持续不懈的填坑，阿里内部已经有应用级的录制回放工具了，数百个应用成功的是用了它，把不可能回归的任务变成了可能（上万数量级的 case 当天生成，当天投入使用，并可以分析覆盖率），自动化测试实施需要付出的工作时间革命性降低（不足原来付出时间的 10%）。
你能讲出自己做过 5 个以上这样的成功例子，我敢保障，你也会被 1 线大厂疯抢。职级基本都是专家起。
其实不难，没有什么高端的方法。下面这 4 条就够了，核心秘密就是坚持不懈。
熟悉你的被测系统，熟悉你的被测系统，熟悉你的被测系统。 能够从技术、业务角度做到对被测系统熟悉是做一个好 QA 的最基本职业素养，也是能力提升的最主要源泉。
自检点：我能够画出系统的架构图么？我能够读懂开发的代码么？我熟悉常见的业务监控系统么？熟悉日志系统么？知道开发是如何调试和定位问题的么？给我一个线上问题，我能定位么？我能给别人完整的介绍这个域的核心业务么？我能自己直接动手发布上线一个系统么？知道如何回滚么？灰度是如何做的？ 我知道所有关键的技术点么，如一个交易的幂等性是如何实现的？我在团队中有：“这家伙对系统最熟” 的口碑么？
如果自检点全部是否定答案。。。 花一年时间把它全变成肯定答案。这一过程，你一定被迫学到了很多很多，并且获得了极为长足的成长，这是进阶的必由之路，也是卡了很多人的地方。 如果说做不到，后面不用看了，前面的也全部忘掉吧。
方法：通读所有文档，强迫自己读代码，积极参与开发所有讨论，不懂的狂问，观察开发如何上线，如何排查问题，模仿，学习，善用搜索引擎，总结。。。
找到问题解决问题，找到问题解决问题，找到问题解决问题。 你一定有一堆问题，如果你觉得自己做得挺好，没有问题要解决，那必然是你自己有巨大的问题！
自检点：找一支笔，写出你觉得质量方面，你的 team 的 10 个问题，做排序。排出最重要的 3 个。
方法：找到 top3 的问题，选一个，列个接话，去解决。如果找不出来，使劲去观察，然后去看看做的好的同行，比比你比人家差在哪里。尝试去解决这些问题，从小问题，能够见到效果的问题入手，设置一个时间点。你真正解决了 5 个以上问题以后，感觉一定会有。
系统学习，系统学习，系统学习
自检点：我系统的学过一门知识么？我能讲清楚我这么操作，我写的这行代码的原理么？
方法：从工作出发，确认你需要补足哪些知识。从网上找一个具体知识的学习路线图，订个计划，照着来。 参加学习小组，找到帮你解决难题的人，多请他吃饭，多请教他。获取知识后，马上回到工作中做检验。还是学以致用才能有所增长。结合工作来系统学习的效果是最好的。
再举个例子：
上家公司有个小伙伴（他应该也会泡这个社区），开始应聘的时候，他说熟悉 jenkins，用的很多。所以第一份工作是：把所有 CI 的日常工作交给了他，并告知 2 个月内要全部搞定。 他一下懵逼了，原来那些不深入的理解支撑不了工作要求。后来他每天死磕，看了 jenkins 所有的文档（对，几乎所有文档通读了一遍），翻了无数问题的解决帖子，记录了上百个问题解决的过程，写了上百篇 jenkins 的小 blog（现在还没公布出来）。几个月以后，他比我熟了，他的一项基础能力成长为：可以独自给一个小公司完整的搞定前端、后端、移动端的一整套 CI 解决方案。其实单凭这一套，就能找到不错的工作了。这是依托工作，系统性学习的结果。
看到有同学说要裸辞，去接受培训。我的建议是，别这样。裸辞你就失去了学以致用的阵地，失去了真正解决问题的机会，还失去了资金来源。依托工作，自主学习是王道。自己饶过不去坎，其实有很多网上教程和非脱产培训班啊。
偏重技能角度讲了讲市场的需求和 QA 如何做如何满足市场需求。行文仓促，认识有限，其实也并没有什么新东西。欢迎讨论拍砖啊：）
最后放一篇老文，前 google 测试总监写的，写了快 10 年了，但我觉得常读常新。
我的 team 在招聘 QA 小伙伴。地点北京，技术职级 P6 或者 P7 。 P8 也有可能（只要你足够强悍）
偏后端测试，有意者请邮件我啊 daohe.lxg@alibaba-inc.com
-----------------------------------------------------------我是分割线--------------------------------------------
(James A. Whittaker）
你是如何开始做测试工作的？
1989 年，我在田纳西大学读研究生的时候，完成了从软件开发人员到软件测试人员的转型。而这一转型并非出于我自己的选择。我命运的改变发生在一个早晨，我的教授质问我为什么缺席那么多开发会议。我解释说因为会议被安排在星期六早上，很不方便。
而怍为一个生平第一次离开家的新入校的研究生，这个时间段有些麻烦。十分有意思的是，等待我的惩罚并不是一纸解聘通知书，而是被判罚为该小组的唯一一个测试人员，且不能与开发团队有任何交流。
对于我的职业生涯来说，这是一个意义多么重大的决定啊！正是这个决定最终成就了几十篇关于测试的论文，构建了多得连我自己也记不清的各种工具，出版了五本书，带来了无尽的快乐工作时间。测试一直就是我拥有的那份具有创造性和技术挑战性的快乐职业。不过，并不是所有人都喜欢这样。可以说我最早接触测试是在攻读研究生期问，不可否认，那时的高强度学习和工作确实让我受益匪浅。另外，我认为从初学者阶段到专家阶段之间存在着一个 “测试的山峰”，人们需要通过一系列个人辅导、获取信息和接受常规指导来翻越山峰。成为一个测试初学者是很容易的，成为职业的测试人员也并不艰难。本章的重点正是讨论如何翻越那座位于职业测试人员和测试专家之间的山峰。
回到未来
在软件测试领域，时间似乎已经停滞了。我们在 21 世纪做事的方法与上个世纪几乎完全相同。Bill Hetzel 在 1972 年出版的测试知识丛书至今仍然相当有价值。而我自己所写，于 2002 年首次出版的 How to Break Software(如何攻破软件) 系列，到今天仍被作为实用软件测试技术主要资源的代名词。
确实，如果我们可以把 20 世纪 70 年代的测试人员转换时空用在今日，我猜想他们的的技巧足够应付现代软件的测试。当然，他们需要学习网络和各种网络协议，但是他们拥有的实际测试技术将能得到很好的应用。如果从 20 世纪 90 年代找一个测试人员，则不几乎不需要任何训练。
对于开发人员来说，却不是这样，他们所掌握的那些上世纪的技巧几乎已经完全过 时。让一个有一段时间不写代码的人重新开始编程，看看会有什么样的反应。让我感到很不安的是，我们可以从马路上直接雇用人手，而雇来的这些人从第一天起就能够测试，就能够有收获。事情真的有那么简单吗？或者是我们的期望值只有那么低？让我更加不安的是，我们没有任何可预测的方式将合适的测试人才从胜任工作状态训练为测试专。测试真的就那么困难吗？
这又是那个山峰了。门槛很低，但通往精通的道路却很艰难。
在通往测试山峰的入口，我们倚仗的是这样一个事实：测试的很多方面都很容易掌握。大多数人都可以学得有模有样。甚至只要将一点点常识应用于输入的选择,就可以找出缺陷。这个层次的测试就如同在桶里钓鱼，简单到足以让任何人都认为自己很聪明。然而过了入口以后，道路迅速陡峭起来，而测试知识变得越来越晦涩难懂。我们发现有人擅长于此，我们称这些人为 “有天赋的人”，并欣赏他们的本能。
难道一定要依靠本能么？对于那些看起来不具备特长的人们，是否存在着一条翻越山峰的途径？是否可以以某种方法传授测试技能以培养出更多的专家呢？为认为这座山峰是可以通行的，而这一章正是我关于应该如何走这条路的笔记，你可以在自己的职业生涯中加以应用。这并不是一份食谱配方，一份职业生涯烹调书。不过你可以做一些事情来加速你的职业成长。但是，正如你可能已经猜到的，真正是说来容易，做起来难。
上山
测试职业的早期阶段主要是为征服测试山峰的漫长攀登做准备。我所能给出的最好的建议是从两个方面来思考问题。对于你参与的每一个项目，都有两部分（不一定相等）的任务。第一部分的任务是保证当前的测试项目获得成功。而第二部分的任务是学习你应该做些什么以便使下一个测试项目更加容易。我把它称为 “测试今天的项目，准备明天的项目”。如果你做每一个项目把它都分割成为上述的两半，那么几乎可以保证你能持续获得进步。这样，你就可以随着每一个参与的项目逐渐成长为更优秀的测试人员。
现在就让我们来关注第二部分的任务 ------ 为下一个项目做准备。我们需要注意三个概念：重复、技术和漏洞。
重复
做任何一件事，绝不要重复两次而不意识到或质疑这其实是个问题。我希望所有年轻的测试人员都牢记这一点。我见过很多初学者，他们在单调的任务上浪费了太多的时间，比如，设置测试机器，配置测试环境，在实验室里安装待测试的应用程序，选择一个产品版本来测试 - 这些任务列表可以变得很长，最后你会发现真正花在测试软件上的时间少得可怜。
这是许多新手常犯的错误。他们没能看到他们日复一日所做的工作的重复本质，儿当他们意识到这种重复时，几个小时已经过去了，而在这几个小时内他们没有做任何实际的测试工作。关注这些重复劳动，并且留意由此造成的真正的软件测试工作时间的流逝。为了能翻过测试的山峰，必须做一个测试人员应该做的工作，而不是实验室管理员或者测试机管理员的工作。
测试自动化是解决重复劳动的方案，也是本章稍后的主题。
技术
测试人员常常会对软件失效进行分析。分析缺陷时，我们从开发人员的失败中学习如何编写可靠的代码。我们也分析那些被我们忽略的缺陷。在应用程序上市以后，客户就会开始报告缺陷，我们将要面对处理一大堆失效的情形并寻找其中的重要缺陷。用户报告的每一个缺陷都说明我们的流程有问题，我们的测试知识还不够完善。
但是分析我们的成功也同样重要，儿许多新入职的测试人员却没能利用这个唾手可得的资源。我们在测试中找到的每一个缺陷都说明我们的的测试流程正在有效工作，都是一次成功。我们需要紧紧抓住这种绝好的机会，只有这样才能使成功不断的重复下去。
运动队常常这样做，他们会观看比赛录像，并分析每一个动作为什么奏效或者为什么不奏效。我清楚地记得一个小故事，我的一个朋友拍下了我儿子踢足球的一些照片。其中一张照片记录了她踢球的瞬间，那个球超过对方守门员成功进球了。当我把它给我儿子看时，我之处他站立的那条腿的姿势非常完美，他踢球的脚尖紧绷且出球点在鞋带间恰到好处的位置上。他盯着那张照片很长时间，从那以后他很少用不正确的姿势踢球。他那次得分可能只是碰巧做对了，但从此以后他有意识的运用这些技术使之接近完美。
现在回到新手测试人员的课程上来。我们每一个人都会有得意的时刻。我们找到重要的漏洞或发现优先级很高的缺陷，并为此雀跃不已。不过先花点时间考虑一下整体状况。我们使用什么技术找到了那个缺陷？我们是否可以创建一种方法来找到更多这类缺陷？我们是否可以记住…些实际的测试经验并不断地加以应用来帮助提高我们的工作效率？软件的哪些症状可以提示我们它具有缺陷？我们将来能否从那些症状中得到更多的警示？换句话说，这不仅仅是一个缺陷或是一次成功，这个缺陷教会了我们什么，是否使得我们将来成为更好的测试人员正如我儿子的进球一样，尽管第一个缺陷是偶然间发现的，但它不代表其余的成功都是偶然。理解我们成功的原因很重要，只有这样做，成功才能被复制。对于测试人员来说，这种保证成功的原因就是一系列的测试技术、建议和工具，它们可以提高我们在未来项目中的工作效率。
漏洞
测试人员最终都会变得很擅长寻找缺陷，但是要翻过测试的高峰，我们必须更快并且更有效率：高速低阻。换句话说，我们必须拥有一种本身不含缺陷的缺陷查找技术！
我喜欢这样来考虑问题：测试人员检视自己的工作时也需要发挥那种寻找缺陷的能力。我们必须使用和寻找产品缺陷一样的流程来寻找我们自己的测试流程，测试过程中的缺陷。我的测试流程是不是有问题？这里面是否有缺陷？这里是否存在着妨碍我提高效率的障碍？
你必须一直寻找更好的方法。有意识地去确定那些限制能力、阻碍前进、减缓速度的东西。就像缺陷限制了软件满足用户需求的能力一样，是什么限制了测试的能力？使用你拥有的测试能力来最优化自己的测试流程，这会帮助你在测试的山峰上快速攀登并增加你翻越山峰后成为专家的机会。
测试山峰的巅峰处是一个美好的地方。如果你成功地到了那里，恭喜你．但这并不是最终日标。这表示你已经成为一个杰出的测试人员。而此时的下坡路就是用你的洞察力和专家知识来帮助周围的人也成为优秀的测试人员。自己一个人登顶是一回事，帮助其他人（那些能力不如你的人）登顶却完全是另外一回事。
一般来说，那些成功登上测试巅峰的人会成为使用工具的大师。那些商业工具、开开源免费工具,和自己写的工具（我个人最喜欢的工具）是极好地提高工作产出、增加工作成效的方法。不过，工具只是实现该目标的一种方法，但在许多其他方面它反而是一种限制，因为太多的人看不到工具的功能之外的东西。他们被限制在工具能为他们所做的事情中，没能看到或理解对工具还有更多的需求。登顶需要真正掌握的是 “信息”。因为很多工具能处理信息，并使得信息的获取更加容易，所以测试人员变得过于依赖于他们的工具。但是信息本身以及如何利用这些信息才是真正的成功关键。
熟练掌握信息，指理解有哪些信息，这些信息将如何影响测试，保证最大限度地利用这些影响。有几类信息是测试登顶者必须关注的。这里我要谈的是其中两种：来自应用程序的信息和来自之前测试的信息。
来自应用程序的信息包括需求、体系结构、代码结构、源代码……甚至是关于应用程序在执行时做了哪些事情的运行信息。在编写和执行测试用例时，需要考虑这类信息，但信息的多寡在很大程度上取决于测试人员的能力，这是一种能够使测试更高效的能力。在测试中使用这类信息越多，测试就越偏向于工程而不是猜测。
在微软，我们有一个游戏测试组织（Games Test Organization,GTO），负责 Xbox 和 PC 游戏的测试。谈到利用应用程序的信息，他们是最优秀的。游戏是难以想象的丰富，测试起来非常复杂。游戏中很多可测试的内容都是隐藏的（因为让那些玩家找寻可以交换的物品正是游戏的乐趣之一）o 如果 GTO 的测试人员所做的仅仅是玩游戏，那么他们找到的问题不会比最终用户更多。为了能做得更好，他们与游戏的开发人员合作创建了一些信息控制板，这些控制板暴露了一些基本上可以算得上作弊的信息给测试人员。这样，测试人员就能提前知道怪物会被投放在何处、物品被隐藏在哪里，他们可以看到墙的另一边，可以控制敌方的某些行为。他们的作弊工具（即测试工具）基本上使他们成为游戏里的神，让他们可以控制看到的信息以便更快更巧妙地测试。这个例子给有测试人员都上了一课。
来自测试的信息意味着你必须关注在测试时所做的一切，并使用获得的信息来影响今后的测试。你是否知道你的测试是如何与需求结合的，知道何时某一特定需求已经得到足够的测试？你是否使用代码覆盖率来影响未来的测试？你知道当代码更新或缺陷修复时那些测试会受到影响，还是知识重新运行所有的测试？理解测试进行到什么程度并随着测试调整测试策略，这是测试成熟的标志。
我以前曾在微软的 Visual Studio 的一个小组工作过，我们大量使用代码改动量（由于添加新特性或修复缺陷而改变的代码）和代码覆盖来影响我们的测试。我们花了很大的力气将代码覆盖和代码改动量通知测试人员，帮助他们理解哪些测试用例对覆盖率有贡献，帮助他们测试改动过的或修改过的组件。最终的结果是在代码确实被改动时，我们清楚地知道哪些测试会被影响而只重新运行那些测试。我们还知道每个新的测试用例是如何对总体的接口，特性和代码覆盖率产生作用的，从而指导我们的测试人员，让团队中的每个人在他们所创建的所有测试用例基础上，写出更有意义的测试。
你用哪些信息来指导你的测试？你如何保证信息是可获取的，以便在测试中随时可以得到？你如何使得信息变得有用，以便它能以良好的方式影响你的测试？这些问题的答案将决定你在走下专家测试山峰时的前进速度。
下山
到达测试山峰的顶峰的时候，你已经成为一个十分能干的测试人员了，能力也许相当于你组里所有同事能力的总和。无论你在做什么，请不要试图做得比你的整个团队都好，不管你对此感觉有多好，或是你的老板对你遏得有多紧。一旦你走在下坡的路上，就不要再去争取 “找到最多缺陷的人” 或是 “找到最有意义缺陷的人” 这样的荣誉头衔。反而我推荐你减少花在测试上的时间，而把创新作为你的首要任务。
在测试上创新指不急于向前，而是仔细观察、洞察先机、找到瓶颈并改进团队中所有其他人的工作方式。你的工作变为帮助其他人进步。在微软，我们有一个专门为此而设的正式职位——测试架构师。不过，不要因为缺少一个很酷的头衔而让你沮丧。无论别人怎么称呼你，当你在 “下坡的路上，你能做的最好的事就是尽量保证更多的人能成功地爬上山峰的另一侧。