James Whittaker：一个成功的测试者应该具备怎样的品质

回到未来

在软件测试领域，时间似乎已经停滞了。我们在21世纪做事的方法与上个世纪几乎完全相同。Bill Hetzel在1972年出版的测试知识丛书至今仍然相当有价值。而我自己所写，于2002年首次出版的How to Break Software(如何攻破软件)系列，到今天仍被作为实用软件测试技术主要资源的代名词。

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

对于开发人员来说，却不是这样，他们所掌握的那些上世纪的技巧几乎已经完全过 时。让一个有一段时间不写代码的人重新开始编程，看看会有什么样的反应。让我感到很不安的是，我们可以从马路上直接雇用人手，而雇来的这些人从第一天起就能够测试，就能够有收获。事情真的有那么简单吗？或者是我们的期望值只有那么低？让我更加不安的是，我们没有任何可预测的方式将合适的测试人才从胜任工作状态训练为测试专。测试真的就那么困难吗？（更多精彩内容请戳：你离一名优秀的测试经理，只有这8个问题的距离）

这又是那个山峰了。门槛很低，但通往精通的道路却很艰难。

在通往测试山峰的入口，我们倚仗的是这样一个事实：测试的很多方面都很容易掌握。大多数人都可以学得有模有样。甚至只要将一点点常识应用于输入的选择,就可以，我出缺陷。这个层次的测试就如同在桶里钓鱼，简单到足以让任何人都认为自，自己很聪明。然而过了入口以后，道路迅速陡峭起来，而测试知识变得越来越晦涩难懂。我们发现有人擅长于此，我们称这些人为“有天赋的人”，并欣赏他们的本能。

难道一定要依靠本能么？对于那些看起来不具备特长的人们，是否存在着一条翻越山峰的途径？是否可以以某种方法传授测试技能以培养出更多的专家呢？为认为这座山峰是可以通行的，而这一章正是我关于应该如何走这条路的笔记，你可以在自己的职业生涯中加以应用。这并不是一份食谱配方，一份职业生涯烹调书。不过你可以做一些事情来加速你的职业成长。但是，正如你可能已经猜到的，真正是说来容易，做起来难。

上山

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

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

重复

做任何一件事，绝不要重复两次而不意识到或质疑这其实是个问题。我希望所有年轻的测试人员都牢记这一点。我见过很多初学者，他们在单调的任务上浪费了太多的时间，比如，设置测试机器，配置测试环境，在实验室里安装待测试的应用程序，选择一个产品版本来测试-这些任务列表可以变得很长，最后你会发现真正花在测试软件上的时间少得可怜。

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

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



技术

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

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

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

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

你必须一直寻找更好的方法。有意识地去确定那些限制能力、阻碍前进、减缓速度的东西。就像缺陷限制了软件满足用户需求的能力一样，是什么限制了测试的能力？使用你拥有的测试能力来最优化自己的测试流程，这会帮助你在测试的山峰上快速攀登并增加你翻越山峰后成为专家的机会。

测试山峰的巅峰处是一个美好的地方。如果你成功地到了那里，恭喜你．但这并不是最终日标。这表示你已经成为一个杰出的测试人员。而此时的下坡路就是用你的洞察力和专家知识来帮助周围的人也成为优秀的测试人员。自己一个人登顶是一回事，帮助其他人（那些能力不如你的人）登顶却完全是另外一回事。

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

熟练掌握信息，指理解有哪些信息，这些信息将如何影响测试，保证最大限度地利用这些影响。有几类信息是测试登顶者必须关注的。这里我要谈的是其中两种：来自应用程序的信息和来自之前测试的信息。

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

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

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

下山

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

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