有这么个普遍现象测试招聘者特别是一、二线互联网公司的招聘者最苦恼的事儿就是招人。想找到一个合适的人难于上青天每天各种撒网简历看几百份面大几十人能捞到一个中意的小伙伴就谢天谢地了。但同时很多测试小伙伴发现找工作很难特别是进大一点的厂他们特别挑代码要会写要有软件架构能力问一大坨平时根本用不到的技术问题还挑经验挑沟通能力挑这挑那有时候还特么挑学历、挑年龄。。。 供求总难以匹配起来造成了双方都很痛苦。Why能力要求不匹配是最核心的问题。软件、互联网近20年来飞速成长其实也经历了很多阶段。行业软件兴盛阶段和外包兴盛阶段2000-2010年行业进入了大量的测试人员当时最主流的测试实践是重心放在系统验收阶段。测试人员的主要工作基本都投入在了基于业务的黑盒测试上对代码能力、系统理解的能力要求不多。2010年后互联网行业的真正兴起让国内软件开发模式开始缓慢调头快速迭代的模式逐步兴起开发周期越来越短迭代越来越快但系统越来越越庞大、复杂。原来的测试工作模式和工作范围越来越无法满足要求了。但大量从业人员技能范围转变是一件很难的事情行业是有巨大惯性的。从宏观上看大量QA技能转变跟不上需求转变是造成市场供求不匹配的主要原因。So What?三个观点1. 只做手工测试不懂系统实现的测试工程师的职业发展会越来越受限。2. 能够转型成适应市场需求的同学将在近几年的时间获得超额回报因为市场供不应求企业不得不抬高价格来寻找这样的人。3.对于个体来说自我成长永远最重要自己永远要对自己的发展负责别依赖外部环境自己想办法变成市场的香饽饽才靠谱。到底什么样的人抢手按照我一点理解讲一讲什么样子的人会抢手吧限于篇幅会偏重技术角度来讲。个人之见欢迎讨论和拍砖。测试的底子-项目经验有比较复杂系统的测试实战经验你就超过了50%以上的应聘者。什么叫做比较复杂系统呢投入50人年开发出来的系统就可以称作一个复杂系统了。因此复杂系统并不是很罕见。但是如果你只接触一个简单的模块甚至只是测试一个稳定模块的维护性开发而不是通盘理解不能说是测试过复杂系统。有从头到尾接触一个完整项目的经历很宝贵。测试的底子-基础知识对照三本书《ISTQB基础教程》 《高级软件测试设计》 《高级软件测试管理》后两本是ISTQB的高级认证教程。这里边的内容你都能熟练应用真的是熟练应用而不只是有概念你就能超过80%以上的应聘者了。面试过数百人我经常会问几个问题如果测试时间不够你会怎么办 如果让你去测试一个你完全不熟悉的系统你会怎么办你平时会使用那些测试设计方法 看似很稀松平常的问题非常考验人。因为大部分从业者都没有经受过系统训练和学习工作多年依然技能不足意识跑偏。熟练使用一门主语言满足这条你就超过了70%的应聘者。什么叫做熟练呢拿Java来说吧系统学习过Java的教程高频面试50题 这样的题可以自测一下可以回答上35个以上熟悉最主流的Spring框架能够写出一个简单的网站实现基础的Restful 服务读懂过一个测试框架如mockito或者Junit的源码能够熟练实施接口测试基于一些测试框架 如rest-assuredJunit能够读懂开发的业务代码对他们的代码进行Code Review对一门语言有比较深入了解满足这条你就超过了90%的应聘者。什么叫有深入了解呢还拿Java来说吧熟练使用Java的常见API深入理解基于语言特性/系统特性的知识如Collections的实现机制、类型系统、I/O、网络、多线程等熟知设计模式广义范围的设计模式不局限于GOF的设计模式熟悉JVM的工作模式熟练使用调试排查工具解决性能问题熟练掌握市面上常见的脚手架熟练掌握周边知识OPs相关网络知识相关有不错的实战开发经验做过真正被生产检验的东西对于测试开发AOPJava字节码技术是很重要的知识。。。 这是一个很长的学习list需要几年时间来养成。做到这点其实你可以胜任普通的开发岗位了这也是高级测试开发岗位的技术底子。在一个领域知识有不错的了解人不可能什么都懂但工作几年之后会在工作的域内一定要有积累才行。例如你测试一个核心电商系统的交易模块三年了业务上你一定要熟练讲出来商品列表、购物车、下单、退单、废单、支付、发货、库存、退款、优惠使用等等一坨业务流程和可能出现的常见的坑各类问题产生的资损、各类问题产生的服务不可用、逻辑矛盾不然根本无法体现你经验沉淀和深入思考技术角度上你要能够画得出来系统的交互图熟悉最核心的接口和最核心的参数能够读懂开发的代码熟练使用trace和监控工具诊断定位线上问题到代码行。用技术保障质量的能力测试开发岗一定会问到一个问题你能够举一个你用技术手段提高测试效率增强测试能力的例子么这是面试时最大的一个坎。 很多人会讲一些自动化测试回归的例子但是真正成功的例子非常少因为为什么做怎么做都没有想好就照网上一个教程攒了一个结果变成了玩具。 做好自动化不仅仅是会使用工具、框架其实要对被测物特性软件生命周期有很深的理解并且有很强的开发知识才行。实际上在环境、CI、数据、测试用例生成、数据比对的很小的一些点上都能有不错的提效产出从这些点能够做得好会得到不错的加分。有一个不错的成功案例你胜出的几率就超过了80%没有短板就十拿九稳了。技能以外的东西- 实战案例以前的工作印证了你的能力。能够讲清楚一件特别拿得出手的工作证明你能力的工作能力是面试时候最有用的投名状。技能意外的东西 - 你的个人特质一般有如下特质会大大加分快速学习、系统性学习、学以致用、系统性思考、强大的推动力、技术思维、突出的沟通能力、条理性、抗压性、乐观精神、抗挫折能力、迅速调整的能力、迭代改进的意识、ownership、愿景和规划。 这些特性体现人的内核有强大内核的人做什么都行技能暂时不足也一定能补足。所以在招聘的时候往往对是否录用的判断起决定性作用高段位要求高级职位需求计算机领域知识的通盘理解这条范围非常大人不可能什么都懂。但最最基础的知识是不能有盲点的操作系统工作基础原理与基础操作如linux要通读过linux操作系统的书熟悉最基本的概念基本命令要熟悉shell要能写和读网络知识特别是TCP/IP, HTTP知识推荐两本书 《图解tcp/ip》 《图解Http》这两本书里的东西要懂。数据库知识市面常见数据库redismysqloracle的常见DBA操作问题排查SQL的熟练使用Web及移动端知识能够懂HTMLCSS能够读懂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线大厂疯抢。职级基本都是专家起。其它能力 测试是个万金油高阶一些的职位需要什么都要会一些 因为越高阶的职位需要解决的问题越综合需要打交道的人的种类越多。不然很容易变成你职业短板做个list吧一定不全很好的项目管理能力至少与开发经理能力同级甚至要强于他。一定的软件架构能力。一定的产品sense可以跟一个资深的产品经理能够顺畅的交流明白知道他为什么会这么想所要实现产品的意义路径从产品质量方面的考虑要超过产品经理给他输出。极好的沟通能力。团队管理能力这个太重要目标管理能力有一个好的内核上面提到过怎么转型/怎么进阶其实不难没有什么高端的方法。下面这4条就够了核心秘密就是坚持不懈。熟悉你的被测系统熟悉你的被测系统熟悉你的被测系统。 能够从技术、业务角度做到对被测系统熟悉是做一个好QA的最基本职业素养也是能力提升的最主要源泉。自检点我能够画出系统的架构图么我能够读懂开发的代码么我熟悉常见的业务监控系统么熟悉日志系统么知道开发是如何调试和定位问题的么给我一个线上问题我能定位么我能给别人完整的介绍这个域的核心业务么我能自己直接动手发布上线一个系统么知道如何回滚么灰度是如何做的 我知道所有关键的技术点么如一个交易的幂等性是如何实现的我在团队中有“这家伙对系统最熟”的口碑么如果自检点全部是否定答案。。。 花一年时间把它全变成肯定答案。这一过程你一定被迫学到了很多很多并且获得了极为长足的成长这是进阶的必由之路也是卡了很多人的地方。 如果说做不到后面不用看了前面的也全部忘掉吧。方法通读所有文档强迫自己读代码积极参与开发所有讨论不懂的狂问观察开发如何上线如何排查问题模仿学习善用搜索引擎总结。。。找到问题解决问题找到问题解决问题找到问题解决问题。 你一定有一堆问题如果你觉得自己做得挺好没有问题要解决那必然是你自己有巨大的问题自检点找一支笔写出你觉得质量方面你的team的10个问题做排序。排出最重要的3个。方法找到top3的问题选一个列个接话去解决。如果找不出来使劲去观察然后去看看做的好的同行比比你比人家差在哪里。尝试去解决这些问题从小问题能够见到效果的问题入手设置一个时间点。你真正解决了5个以上问题以后感觉一定会有。系统学习系统学习系统学习自检点我系统的学过一门知识么我能讲清楚我这么操作我写的这行代码的原理么方法从工作出发确认你需要补足哪些知识。从网上找一个具体知识的学习路线图订个计划照着来。 参加学习小组找到帮你解决难题的人多请他吃饭多请教他。获取知识后马上回到工作中做检验。还是学以致用才能有所增长。结合工作来系统学习的效果是最好的。再举个例子上家公司有个小伙伴他应该也会泡这个社区开始应聘的时候他说熟悉jenkins用的很多。所以第一份工作是把所有CI的日常工作交给了他并告知2个月内要全部搞定。 他一下懵逼了原来那些不深入的理解支撑不了工作要求。后来他每天死磕看了jenkins所有的文档对几乎所有文档通读了一遍翻了无数问题的解决帖子记录了上百个问题解决的过程写了上百篇jenkins的小blog现在还没公布出来。几个月以后他比我熟了他的一项基础能力成长为可以独自给一个小公司完整的搞定前端、后端、移动端的一整套CI解决方案。其实单凭这一套就能找到不错的工作了。这是依托工作系统性学习的结果。看到有同学说要裸辞去接受培训。我的建议是别这样。裸辞你就失去了学以致用的阵地失去了真正解决问题的机会还失去了资金来源。依托工作自主学习是王道。自己饶过不去坎其实有很多网上教程和脱产培训班啊。选择有挑战的团队选择有挑战的团队 自检点在团队里有很多人比我强么周围的同事都是我佩服的么我做的事儿有挑战么 方法如果这三点都是否定的并且你处于职业生涯的早期。也许只是也许你该考虑一下换个团队了。总结偏重技能角度讲了讲市场的需求和QA如何做如何满足市场需求。行文仓促水平有限欢迎讨论拍砖~最后放一篇老文前google测试总监写的写了快10年了但我觉得常读常新。-----------------------------------------------------------我是分割线--------------------------------------------经营成功的测试职业生涯(By: 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的一个小组工作过我们大量使用代码改动量由于添加新特性或修复缺陷而改变的代码和代码覆盖来影响我们的测试。我们花了很大的力气将代码覆盖和代码改动量通知测试人员帮助他们理解哪些测试用例对覆盖率有贡献帮助他们测试改动过的或修改过的组件。最终的结果是在代码确实被改动时我们清楚地知道哪些测试会被影响而只重新运行那些测试。我们还知道每个新的测试用例是如何对总体的接口特性和代码覆盖率产生作用的从而指导我们的测试人员让团队中的每个人在他们所创建的所有测试用例基础上写出更有意义的测试。你用哪些信息来指导你的测试你如何保证信息是可获取的以便在测试中随时可以得到你如何使得信息变得有用以便它能以良好的方式影响你的测试这些问题的答案将决定你在走下专家测试山峰时的前进速度。下山到达测试山峰的顶峰的时候你已经成为一个十分能干的测试人员了能力也许相当于你组里所有同事能力的总和。无论你在做什么请不要试图做得比你的整个团队都好不管你对此感觉有多好或是你的老板对你遏得有多紧。一旦你走在下坡的路上就不要再去争取“找到最多缺陷的人”或是“找到最有意义缺陷的人”这样的荣誉头衔。反而我推荐你减少花在测试上的时间而把创新作为你的首要任务。在测试上创新指不急于向前而是仔细观察、洞察先机、找到瓶颈并改进团队中所有其他人的工作方式。你的工作变为帮助其他人进步。在微软我们有一个专门为此而设的正式职位——测试架构师。不过不要因为缺少一个很酷的头衔而让你沮丧。无论别人怎么称呼你当你在“下坡的路上你能做的最好的事就是尽量保证更多的人能成功地爬上山峰的另一侧。