老生常谈，再谈谈测试职业发展

老生常谈，再谈谈测试职业发展

这应该是第三篇写职业发展的文章啦。。。好像没啥新东西。

有这么个广泛现象

测试招聘者，特别是1、二线互联网公司的招聘者最苦恼的事儿就是招人。找到一个合适的人，难于上青天，天天各类撒网，简历看几百份，面大几十人，能捞到一个中意的小伙伴就谢天谢地了。不少测试小伙伴发现找工做很难，特别是进大一点的厂，他们特别挑：代码要会写，要有软件架构能力，问一大坨平时根本用不到的技术问题，还挑经验，挑沟通能力，挑这挑那，有时候还特么挑学历、挑年龄。。。 供求总难以匹配起来，形成了双方都很痛苦。

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，敏捷开发的一些认证课程。

• 在一个域的深耕
  人不可能什么都懂，但在一个领域是须要深耕的。好比，在作了4、五年移动端测试之后。基本上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如何作如何知足市场需求。行文仓促，认识有限，其实也并无什么新东西。欢迎讨论拍砖啊：）

最后放一篇老文，前google测试总监写的，写了快10年了，但我以为常读常新。

-----------------------------------------------------------我是分割线--------------------------------------------

经营成功的测试职业生涯

(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的一个小组工做过，咱们大量使用代码改动量（因为添加新特性或修复缺陷而改变的代码）和代码覆盖来影响咱们的测试。咱们花了很大的力气将代码覆盖和代码改动量通知测试人员，帮助他们理解哪些测试用例对覆盖率有贡献，帮助他们测试改动过的或修改过的组件。最终的结果是在代码确实被改动时，咱们清楚地知道哪些测试会被影响而只从新运行那些测试。咱们还知道每一个新的测试用例是如何对整体的接口，特性和代码覆盖率产生做用的，从而指导咱们的测试人员，让团队中的每一个人在他们所建立的全部测试用例基础上，写出更有意义的测试。



     你用哪些信息来指导你的测试？你如何保证信息是可获取的，以便在测试中随时能够获得？你如何使得信息变得有用，以便它能以良好的方式影响你的测试？这些问题的答案将决定你在走下专家测试山峰时的前进速度。

下山

到达测试山峰的顶峰的时候，你已经成为一个十分能干的测试人员了，能力也许至关于你组里全部同事能力的总和。不管你在作什么，请不要试图作得比你的整个团队都好，无论你对此感受有多好，或是你的老板对你遏得有多紧。一旦你走在下坡的路上，就不要再去争取“找到最多缺陷的人”或是“找到最有意义缺陷的人”这样的荣誉头衔。反而我推荐你减小花在测试上的时间，而把创新做为你的首要任务。



     在测试上创新指不急于向前，而是仔细观察、洞察先机、找到瓶颈并改进团队中全部其余人的工做方式。你的工做变为帮助其余人进步。在微软，咱们有一个专门为此而设的正式职位——测试架构师。不过，不要由于缺乏一个很酷的头衔而让你沮丧。不管别人怎么称呼你，当你在“下坡的路上，你能作的最好的事就是尽可能保证更多的人能成功地爬上山峰的另外一侧。