作者：James A. Whittaker

翻译：汪啸

译者前言：本文摘自其所著的《探索式软件测试》一书附录A。本文流传很广，在国内影响颇深。但网络流传的中文翻译一言难尽（可能是中文扫描版OCR得来的；翻译太生硬，错误较多）；作为一个职业指导性文章，容易误人子弟。我基于英文原文，增补遗漏、修改错误、重新润色后完成。译文中带括号中的内容基本都是我添加的译者注。

1、你是如何进入测试行业的？ （How Did You Get into Testing?）

1989年，我在田纳西大学读研究生的时候，完成了从软件开发人员到软件测试人员的转型。而这一转型并非出于我自己的选择。我命运的改变发生在一个早晨，我的教授质问我为什么缺席那么多开发会议。我解释说因为会议被安排在星期六早上，很不方便。（因为作者当时的女朋友，后来的老婆觉得周末不应该加班）

而作为一个生平第一次离开家的新入校的研究生，这个时间段有些麻烦。有意思的是，等待我的并不是一纸解聘通知书，而是被判罚为该小组的唯一一个测试人员，且不能与开发团队有任何交流。（作者所在的软件项目经济来源稳定，由其本校教授Jesse Poore带领和佛州理工的Harlan D. Mills的督导。后者发明了”净室软件工程”方法：Cleanroom Software Engineering。而“净室软件工程”要求测试与开发人员完全独立工作）

对于我的职业生涯来说，这是一个多么关键的决定啊！正是这个决定，产生了几十篇关于测试的论文，构建了多得连我自己也记不清的各种工具，出版了五本书，带来了数不清的快乐工作时间。测试于我来说，已经是一份具有创造性、技术挑战性和成就感的职业。但并不是所有测试人员和我感受一样。我承认，我入行时在学校进行的集中地浸入式学习让我在测试行业取得了一些优势。更多的，我认为测试人员从新手到专家之间存在着一个“测试山丘”(testing hump，下文会出现多次。英文中“over the hump”一般指“度过最困难阶段”，属于一语双关)，人们需要通过一系列培训指导、信息获取来越过。成为一个测试初学者是很容易的，成为熟练的测试人员也不难。本文的重点正是讨论如何越过那座位于熟练测试人员和测试专家之间的山丘。

2、回到未来（Back to the Future）

在软件测试领域，时间似乎已经停滞了。我们在21世纪做事的方法与上个世纪几乎没什么不同。Bill Hetzel在1972年出版的测试知识丛书（书籍信息：W. Hetzel (editor), Program Test Methods, Englewood Cliffs, NJ: Prentice-Hall, 1972.）至今仍相当有价值。而我自己所写，于2002年首次出版的How to Break Software(如何搞挂软件)系列丛书，到今天仍被作为实用软件测试技术的主要参考资料。

确实，如果我们可以把20世纪70年代的测试人员转换时空用在今日，我猜想他们的技巧足够应付现代软件的测试。当然，他们需要学习网络和各种网络协议，但是他们拥有的实际测试技术将能得到很好的应用。如果从20世纪90年代找一个测试人员，则几乎不需要任何训练。

对于开发人员来说，却不是这样，他们所掌握的那些上世纪的技巧几乎已经完全过时。比如让一个有一段时间不写代码的人重新开始编程，看看会有什么样的反应。

让我感到很不安的是，我们可以从马路上找来几个人，而这些人从第一天起就能够测试，就能够有收获。事情真的有那么简单吗？或者是我们的期望值只有那么低？让我更加不安的是，我们没有任何比较成功的方式将体面的测试人才从高效率测试人员训练为专家。测试真的就那么困难吗？

又回到那个测试山丘的比喻：入场券很便宜，但通往精通的道路却很艰难。

在通往测试山丘的道路上，有这样一个共识：测试的很多方面都很容易掌握。大多数人都可以学得有模有样。甚至只要用一点点常识进行不同输入的尝试，就可以找到缺陷（bug）。这个层次的测试就如同在桶里钓鱼，简单到足以让任何人都认为自己很聪明。然而到达山丘入口后，道路迅速陡峭起来，而测试知识变得越来越晦涩难懂。我们发现有人擅长于此，我们称这些人为“有天赋的人”，并欣赏他们的直觉。

难道一定要依靠直觉么？对于不是“老天爷赏饭吃”的那部分人来说，是否存在一条可以登顶的路径？是否能通过传授测试技能以培养出更多的专家呢？我认为翻越这座山丘是可以行得通的，而这篇文字正是我关于应该如何走这条路的笔记，你也可以在自己的职业生涯中加以应用。这并不是一份测试提升的检查列表，因为测试职业不会像划对勾那样简单；不过你可以做一些事情来加速你的职业成长。但是，正如你可能已经猜到的：说起来容易，做起来难。

3、上山（The Ascent）

测试职业的早期阶段主要是为征服测试山丘的漫长攀登做准备。我所能给出的最好的建议是从两个方面来思考问题。对于你参与的每一个项目，都有两部分（不一定相等）的任务。第一部分的任务是保证当前的测试项目获得成功。而第二部分的任务是从中学习使下一个测试项目更加容易进行的方法。我把它称为“测试今天的项目并为明天的项目作准备”（testing for today’s project while preparing for tomorrow’s）。如果你做每一个项目把它都分割成为上述的两部分，那么几乎可以保证你能持续获得进步。这样，你就可以随着每一个参与的项目逐渐成长为更优秀的测试人员。

现在就让我们来关注第二部分的任务，为下一个项目作准备。我们需要注意三个概念：重复、技巧和坑。

3.1 重复（Repitition)

不要盲目的做重复的事情，要有发现和质疑重复做事的精神（Never do anything twice without realizing it and questioning it）。我希望所有新手测试人员都牢记这一点。我见过很多初学者，他们在乏味的任务上浪费了太多的时间，比如，设置测试机器，配置测试环境，在实验室里安装待测试的应用程序，选择一个产品版本来测试… 这些重复的任务列表可以变得很长，最后你会发现真正花在测试软件上的时间少得可怜。

这是许多新手常犯的错误。他们没能看到他们日常重复工作中的本质；而当他们意识到这种重复时，几个小时已经过去了，而在这几个小时内他们没有做任何实际的测试工作。关注这些重复劳动，并且留意由此造成的真正测试时间的浪费。为了能越过测试的山丘，必须做一个测试人员应该做的工作，而不是实验室管理员或者测试机管理员的工作。

测试自动化是解决重复劳动的方案，也是本章稍后的主题。

3.2 技巧（Technique）

测试人员常常会对软件缺陷进行分析。分析缺陷时，我们从开发人员的失败中学习如何编写可靠的代码。我们也分析那些被我们漏测的缺陷。在应用上线以后，客户就会开始报告缺陷，我们将要处理一大堆问题反馈并寻找其中的重要缺陷。用户报告的每一个缺陷都说明，我们的流程有问题、我们的测试知识不够完善。

但是分析我们的成功也同样重要，而许多新手测试人员却没能利用这个唾手可得的资源。我们在测试中找到的每一个缺陷都说明我们的的测试流程正在有效工作，都是一次成功。我们需要紧紧抓住这种绝好的机会，只有这样才能使成功不断的重复下去。

运动队就常常这样做。他们会观看比赛录像，并分析每一个动作为什么奏效或者为什么不奏效。我清楚地记得一个小故事，我的一个朋友拍下了我儿子踢足球的一些照片。其中一张照片记录了他踢球的瞬间，那个球越过对方守门员进了。当我把它给我儿子看时，我指出他站立的那条腿的姿势非常完美，他踢球的脚尖紧绷且出球点在鞋带间恰到好处的位置上。他盯着那张照片看了很长时间，从那以后他很少用不正确的姿势踢球。他那次得分可能只是碰巧做对了，但从此以后他有意识的运用这些技术使之接近完美。

现在回到对新手测试人员的指导上来。我们每一个人都会有得意的时刻。我们找到重要的漏洞或发现优先级很高的缺陷，并为此雀跃不已。不过先花点时间考虑一下整体状况。我们使用什么技术找到了那个缺陷？我们是否可以创造一种方法来找到更多同类缺陷？我们是否可以把一些真正有用的测试经验记在心里并不断地加以应用来帮助提高我们的测试效率？软件的哪些表象可以提示我们一个缺陷的存在？我们将来能否从那些软件表象中得到更多的警示？换句话说，这不仅仅是一个缺陷或是一次成功发现。这个缺陷教会了我们什么，是否能让我们将来成为更好的测试人员？

正如我儿子的进球一样，尽管第一个缺陷是偶然间发现的，但它不代表其余的缺陷发现都是偶然。理解我们成功发现缺陷的原因很重要，只有这样做，成功才能被复制。对于测试人员来说，这些成功发现缺陷的原因就是有一系列的测试技术、测试建议和测试工具组成的，它们可以提高我们在未来项目中的测试效率。

3.3 坑（Holes）

测试人员最终都会变得很擅长寻找缺陷，但是要翻过测试的山丘，我们必须更快并且更有效率：即高速与低阻力。换句话说，我们必须拥有一种本身不含缺陷的缺陷查找技术！

我喜欢这样来考虑问题：测试人员检视自己的工作时也需要发挥那种寻找项目产品缺陷的能力。我们必须使用与测试软件时相同的流程，来寻找我们自己测试流程中的缺陷。我的测试流程是不是出问题了？这里面是否有缺陷？这里是否存在着妨碍我提高效率的障碍？

不停歇的持续寻找更好的方法吧。有意识地去辨认、识别那些限制你的能力、阻碍你的前进、减缓你的速度…的东西。就像缺陷限制了软件本要交付的需求一样，是什么限制了测试的能力？使出你的浑身解数来优化你的测试流程，这会帮助你在测试的山丘上快速上升并增加你越过山丘成为专家的可能。

4、顶峰（The Summit）

测试山丘的顶峰是个好地方。如果你成功地到了那里，那恭喜你。但这并不是这趟旅程的终点。这只表明你已经成为一个杰出的独立测试人员。而此时的下山路则是通过你的洞察力和专业知识帮助周围的人也成为优秀的测试人员。独自登顶是一回事，帮助其他人（那些能力不如你的人）登顶却完全是另外一回事。

一般来说，那些成功登上测试顶峰的人是使用工具的大师。商业工具、开源或免费工具，以及自己写的工具（我的个人偏好），都是极好地增加测试产出、提高测试效率的方法。不过工具只是实现目的的一种方法，在其他许多方面它反而是一种限制，因为太多的人看不到工具之外的东西。他们沉浸在工具能为他们所做的事情中，没能看到或理解更重要的需求。登顶需要真正掌握的是“信息”（information）。因为很多工具能处理信息，使得信息的获取变得更加容易，所以测试人员变得过于依赖于他们的工具。但是信息本身以及如何利用这些信息才是真正的成功关键。

熟练掌握信息需要理解现在有哪些信息，这些信息如何影响测试，以及如何确保这些影响最大化。有几类信息是测试登顶者必须关注的。这里我要谈的是其中两种：来自应用程序的信息和来自测试的信息。

来自应用程序的信息包括需求、系统架构、代码结构、源代码，甚至是应用程序在运行时做了哪些事情的运行时信息。在编写和执行测试用例时，考虑这类信息的多寡在很大程度上取决于测试人员的自身能力。在测试中使用这类信息越多，测试就越偏向于系统工程而不是猜测。

在微软，我们有一个游戏测试组织（Games Test Organization,GTO），负责Xbox和PC游戏的测试。谈到利用应用程序的信息，他们是最优秀的。游戏本身难以想象的丰富，测试起来非常复杂。游戏中很多需要测试的内容都是隐藏的（因为发现那些可以互动的物品正是游戏玩家的乐趣之一），如果GTO的测试人员所做的仅仅是玩游戏，那么他们找到的问题不会比普通玩家更多。为了能做得更好，他们与游戏的开发人员合作创建了一些信息板，这些信息板暴露了一些必要的作弊信息给测试人员。这样，测试人员就能提前知道怪物在哪里刷新、隐藏物品在哪里；他们可以透视墙并控制对手的某些行为。他们的作弊工具（即测试工具）基本上使他们成为游戏里的上帝，让他们可以随心所欲的控制信息以便更快、更巧妙地测试。可以想想从这个例子中能学到什么。

来自测试的信息意味着你必须关注在测试时你所做的一切，并使用所学来影响今后的测试。你是否知道你的测试是如何与需求关联的，知道何时才算一个需求已得到足够的测试？你是否使用代码覆盖率来指导未来的测试？当代码更新或缺陷修复时，你是否知道哪些测试用例会受到影响，还是只是简单的重新执行所有的测试？理解测试进行到什么程度并随着测试调整测试策略，这是测试成熟的标志。

我以前曾在微软的Visual Studio的一个小组工作过，我们大量使用代码改动量（code churn，由于增加新功能或修复缺陷而产生的代码变更）和测试代码覆盖率来影响我们的测试。我们花了非常大的精力使得覆盖率和代码改动量暴露给测试人员，并在测试修改过的组件时，帮助他们理解哪些测试用例对测试代码覆盖率有贡献。最终效果则是，在代码被改动时，我们清楚地知道哪些测试会被影响而只重新运行那些测试。我们还知道每个新的测试用例是如何对整体的接口，功能和代码覆盖率产生作用的。从而指导我们的测试人员在此基础上写出更有意义的测试用例。

你用哪些信息来指导你的测试？你如何保证信息是可获取（available）的，以便在测试中随时可以访问？你如何使信息具有可操作性（actionable），以便它能以正向的方式影响你的测试？这些问题的答案将决定你在测试山丘的下山道路时的前进速度。

5、下山（The Descent）

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

在测试上创新意味着你置身于具体的测试事务之外，洞察先机、寻找瓶颈并改进团队中其他人的工作方式。你的工作变为帮助他人进步。在微软，我们有一个专门为此而设的职位名称：“测试架构师”（Test Architect）；不要因为缺少一个很酷的头衔而减缓你的行动。无论别人怎么称呼你，当你在下山的路上，你能做的最好的事就是尽量保证让更多的测试人员也能成功地爬到山丘的另一侧。