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

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

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

　　我以前曾在微软的Visual Studio的一个小组工作过，我们大量使用代码改动量（由于添加新特性或修复缺陷而改变的代码）和代码覆盖来影响我们的测试。我们花了很大的力气将代码覆盖和代码改动量通知测试人员，帮助他们理解哪些测试用例对覆盖率有贡献，帮助他们测试改动过的或修改过的组件。终的结果是在代码确实被改动时，我们清楚地知道哪些测试会被影响而只重新运行那些测试。我们还知道每个新的测试用例是如何对总体的接口，特性和代码覆盖率产生作用的，从而指导我们的测试人员，让团队中的每个人在他们所创建的所有测试用例基础上，写出更有意义的测试。

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

　　下山

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

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