一、测试生涯的起点

1989年，我在田纳西大学攻读研究生时，意外地从软件开发人员转行成为一名软件测试工程师。这并非我主动选择，说起来还有些戏剧性——某个早晨，教授质问我为何缺席那么多开发会议，我解释说这些会议总是安排在周末早上，对我这个第一次离家、刚入学的学生来说实在不便。结果呢？等待我的不是解聘通知书，而是被“判”为团队唯一的测试人员，并且禁止与开发团队有任何交流。

回过头来看，这个决定对我的职业生涯产生了深远影响。正是它，最终催生了几十篇关于测试的论文、数不清的工具、五本书，以及无数充满快乐的工时。软件测试一直是我充满创造性和技术挑战的快乐职业。不过，并非每个人都这么觉得。可以说，我在研究生期间的高强度学习与工作让我受益匪浅。从初学者到专家之间，存在着一座“测试的山峰”，需要依靠个人辅导、信息获取和常规指导才能翻越。成为一名测试初学者很容易，成为职业测试人员也不难，但本章的重点，就是如何翻越那座横在职业测试人员与测试专家之间的山峰。

二、回到未来

在软件测试领域，时光仿佛停滞了。我们在21世纪做的事情，与上个世纪几乎一模一样。Bill Hetzel在1972年出版的测试知识丛书，至今仍有参考价值。我自己写的《How to Break Software》系列，虽然首版于2002年，到今天仍然是实用测试技术的主要资源。

如果把20世纪70年代的测试人员直接放到今天，我猜他们的技能也完全够用。当然，他们需要学习网络协议，但实际的测试技术仍然能大显身手。如果从90年代找一位测试人员，那几乎不需要任何额外培训。可对于开发人员来说，情况完全不同——他们那些旧技巧基本已经过时了。让一个长时间不写代码的人重新开始编程，看看会是什么反应？

让我有些不安的是，我们可以直接从马路上招人，而这些新手从第一天起就能测试、就能发现问题。事情真的这么简单吗？还是说，我们的期望值太低了？更令人忧虑的是，我们缺乏一种可预测的方法，把称职的测试人才训练成专家。测试真的就那么难吗？

这正是那座山峰的写照——入门门槛很低，但通往精通的路上却充满了艰难。在入口处，我们依赖的事实是：测试的许多方面很容易掌握，大多数人都能学得有模有样。甚至只要把常识用在对输入的选择上，就能发现缺陷。这个阶段就像在桶里钓鱼，简单到让每个人都觉得自己很聪明。但过了入口，道路迅速陡峭起来，测试知识也变得晦涩难懂。有人擅长于此，我们称他们为“有天赋的人”，并欣赏他们的本能。

难道只能靠本能吗？对于那些看起来不具备这种天赋的人，是否有一条翻越山峰的路径？能否通过某种方法传授测试技能，培养出更多专家？这座山峰是可以通行的，而这一章正是我关于这条路如何走的笔记，你可以应用到自己的测试职业生涯中。它并非一份烹饪食谱，但你可以做一些事情来加速自己的职业成长。不过，正如你可能猜到的——说起来容易，做起来难。

三、上山

测试职业的早期，主要是为征服测试山峰的漫长攀登做准备。最好的建议是从两个方面来看待问题：对于你参与的每一个项目，都有两部分任务——第一部分是保证当前项目的成功；第二部分，是学习你应该做什么，以便让下一个项目更轻松。

我把它称为“测试今天的项目，准备明天的项目”。如果你能把每个项目都分成这两半，几乎可以保证你持续进步，随着每一个项目逐渐成长为更优秀的测试人员。

现在聚焦于第二部分——为下一个项目做准备。有三大要点值得关注：重复、技术和漏洞。

3.1 重复

做任何一件事，绝不要重复两次却不意识到或质疑这是个问题。我希望所有年轻的测试人员都牢记这一点。见过太多新手在单调的任务上浪费大量时间，比如设置测试机器、配置测试环境、安装待测应用、选择产品版本……这个列表可以很长，最后你发现真正花在测试软件上的时间少得可怜。

这是许多新手常犯的错误——没能看到日常工作重复的本质，等意识到时，几个小时已经过去了，而这几个小时没有做任何实际的测试工作。关注这些重复劳动，留意由此造成的真正测试时间的流逝。为了翻过测试的山峰，必须做测试人员该做的事，而不是实验室管理员或测试机管理员的工作。测试自动化正是解决重复劳动的方案。

3.2 技术

测试人员常常分析软件失效。分析缺陷时，我们从开发人员的失败中学习如何编写可靠代码；也分析那些被我们忽略的缺陷。应用上市后，客户报告的每一个缺陷都说明我们的流程有问题、测试知识还不够完善。

但分析成功同样重要——许多新手却没利用这个唾手可得的资源。每一个在测试中找到的缺陷，都说明流程正在有效工作，都是一次成功。我们需要抓住这种机会，让成功不断复制。运动队会观看比赛录像，分析每个动作为什么奏效或不奏效。记得一个小故事：朋友拍下了我儿子踢足球的照片，其中一张记录了她踢球的瞬间，球越过守门员成功进球。当我拿给她看时，指出她那条站立腿的姿势非常完美，脚尖紧绷、出球点在鞋带间恰到好处的位置。她盯着那张照片很久，从那以后很少用错误姿势踢球。那次可能只是碰巧做对，但从此她有意识地运用这些技术接近完美。

每一个测试人员都会有得意时刻：找到重要漏洞或高优先级缺陷时，我们雀跃不已。但先花点时间思考整体状况——用了什么技术找到那个缺陷？能否创建一种方法找到更多同类缺陷？能否记住这些经验并不断应用来提升效率？软件的哪些症状提示了缺陷？能否从那些症状中得到更多警示？这不仅仅是一个缺陷或一次成功，它教会了我们什么，能否让我们将来成为更好的测试人员？正如那个进球，虽然第一个缺陷可能是偶然，但其余的成功不全是偶然。理解成功的原因很重要，只有这样才能复制成功。对于测试人员来说，保证成功的原因就是一系列的测试技术、建议和工具。

3.3 漏洞

测试人员最终都会很擅长寻找缺陷，但要翻过测试的高峰，必须更快、更有效率——高速低阻。换句话说，我们需要一种本身不含缺陷的缺陷查找技术。

我喜欢这样理解：测试人员检视自己工作时，也需要发挥那种寻找缺陷的能力。必须用寻找产品缺陷的流程，来寻找我们自己的测试流程中的缺陷。我的测试流程有没有问题？这里面是否有缺陷？是否存在影响效率的障碍？你必须一直寻找更好的方法，有意地确定那些限制能力、阻碍前进、减缓速度的东西。就像缺陷限制了软件满足用户需求的能力一样，是什么限制了测试的能力？用你拥有的测试能力来优化自己的测试流程，这会帮助你在测试的山峰上快速攀登，增加你翻越山峰后成为专家的机会。

四、巅峰

测试山峰的巅峰处是一个美好的地方。如果你成功到了那里，恭喜——但这并非终点。它只意味着你已经成为一个杰出的测试人员。而下坡路，就是用你的洞察力和专家知识来帮助周围的人也成为优秀的测试人员。一个人登顶是一回事，帮助那些能力不如你的人登顶，却是另一回事。

通常，成功登顶的人会成为工具使用的大师。商业工具、开源免费工具、自己写的工具——这些都是提高产出和成效的好方法。但工具只是实现目标的一种方式，反而可能成为一种限制，因为太多人只看到工具的功能之外的东西。他们被束缚在工具能做什么的范围内，看不到还有更多需求。登顶真正需要掌握的，是信息。很多工具能处理信息、让信息更容易获取，所以测试人员变得过度依赖工具。但信息本身以及如何利用信息，才是成功的关键。

熟练掌握信息，意味着理解有哪些信息、这些信息如何影响测试、保证最大限度地利用这些影响。测试登顶者必须关注几类信息：来自应用程序的信息，和来自之前测试的信息。

来自应用程序的信息包括需求、架构、代码结构、源代码，甚至是应用在执行时做了什么的运行信息。编写和执行测试用例时需要考虑这类信息，但信息的多少很大程度上取决于测试人员的能力——这是一种能让测试更高效的能力。在测试中使用这类信息越多，测试就越偏向工程而不是猜测。

在微软，有一个游戏测试组织（GTO），负责Xbox和PC游戏的测试。在利用应用程序信息方面，他们是最优秀的。游戏内容极为丰富、测试起来非常复杂，很多可测试的内容都是隐藏的——让玩家寻找交互物品正是游戏乐趣之一。如果GTO的测试人员只是“玩游戏”，他们找到的问题不会比最终用户更多。为了做得更好，他们与开发人员合作创建信息控制板，暴露了几乎可以算作作弊的信息给测试人员。这样，他们能提前知道怪物会被投放在何处、物品被隐藏在哪里，可以看到墙的另一边，控制敌方的某些行为。这些作弊工具（测试工具）让他们成为游戏里的神，能控制看到的信息以便更快更巧妙地测试。这个例子对所有测试人员都是一课。

来自测试的信息，意味着你必须关注测试时做的一切，并用获得的信息影响今后的测试。你是否知道测试是如何与需求结合的，知道何时特定需求已经测试充分？你是否用代码覆盖率影响未来的测试？你知道当代码更新或缺陷修复时哪些测试会受影响，还是只是重新运行所有测试？理解测试进展到什么程度，并根据测试调整策略，这是测试成熟的标志。

我曾在一个Visual Studio小组工作，大量使用代码改动量和代码覆盖来影响测试。我们花大力气将代码覆盖和代码改动量通知测试人员，帮助他们理解哪些测试用例对覆盖率有贡献，帮助他们测试改动过的组件。最终，当代码确实被改动时，我们能清楚哪些测试会受影响，只重新运行那些测试。我们还知道每个新测试用例如何对接口、特性和代码覆盖率产生作用，从而指导测试人员写出更有意义的测试。

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

五、下山

到达测试山峰的顶峰时，你已经成为一个能力极强的测试人员，可能相当于整个团队成员能力的总和。但无论你在做什么，请不要试图做得比整个团队都好——不管你自己感觉有多好，或者老板逼得有多紧。一旦你走在“下坡”的路上，就别再追求“找到最多缺陷”或“找到最有意义缺陷”的荣誉。相反，减少花在测试上的时间，把创新作为首要任务。

在测试上创新，意味着不急于向前，而是仔细观察、洞察先机、找到瓶颈，并改进团队中所有人的工作方式。你的工作变为帮助他人进步。在微软，有一个专门为此而设的正式职位——测试架构师。不过，别因为没有这个头衔就泄气。无论别人怎么称呼你，当你在“下坡”的路上，你能做的最好的事，就是尽量保证更多人能成功爬上山峰的另一侧。