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

　　重复

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

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

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

　　技术

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

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

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

　　现在回到新手测试人员的课程上来。我们每一个人都会有得意的时刻。我们找到重要的漏洞或发现优先级很高的缺陷，并为此雀跃不已。不过先花点时间考虑一下整体状况。我们使用什么技术找到了那个缺陷?我们是否可以创建一种方法来找到更多这类缺陷?我们是否可以记住…些实际的测试经验并不断地加以应用来帮助提高我们的工作效率?软件的哪些症状可以提示我们它具有缺陷?我们将来能否从那些症状中得到更多的警示?换句话说，这不仅仅是一个缺陷或是一次成功，这个缺陷教会了我们什么，是否使得我们将来成为更好的测试人员正如我儿子的进球一样，尽管第一个缺陷是偶然间发现的，但它不代表其余的成功都是偶然。理解我们成功的原因很重要，只有这样做，成功才能被复制。对于测试人员来说，这种保证成功的原因是一系列的测试技术、建议和工具，它们可以提高我们在未来项目中的工作效率。

　　漏洞

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

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

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

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

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

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

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

　　在微软，我们有一个游戏测试组织(Games Test Organization，GTO)，负责Xbox和PC游戏的测试。谈到利用应用程序的信息，他们是的。游戏是难以想象的丰富，测试起来非常复杂。游戏中很多可测试的内容都是隐藏的(因为让那些玩家找寻可以交换的物品正是游戏的乐趣之一)o如果GTO的测试人员所做的仅仅是玩游戏，那么他们找到的问题不会比终用户更多。为了能做得更好，他们与游戏的开发人员合作创建了一些信息控制板，这些控制板暴露了一些基本上可以算得上作弊的信息给测试人员。这样，测试人员能提前知道怪物会被投放在何处、物品被隐藏在哪里，他们可以看到墙的另一边，可以控制敌方的某些行为。他们的作弊工具(即测试上具)基本上使他们成为游戏里的神，让他们可以控制看到的信息以便更快更巧妙地测试。这个例予给有测试人员都上了一课。