可视化技术是我们在测试工具的世界中取得大进展的领域之一。这是一个只需要短短几年可以实现的领域。软件测试再过两到五年将会变成像玩电子游戏一样。

　　可视化。

　　软件是什么样子的？如果在构建软件或测试软件时能看出它的使用情况，对我们岂不有益？如果能做到这样，只要瞟一眼，我们能看到软件中没有完成的部分。我们也将很容易看出其中的关联、接口和数据，正如我们所希望的那样，它在测试过程中是如何通过输入同上下文环境进行交互的。

　　其他工程学科都有这样的可视化效果。比如制造汽车的伙计们。在装配生产线上的每一个人都能够看到汽车。他们可以看到，车上还没有安装保险杠或方向盘。他们可以看到汽车在生产线上的整个装配过程，从一个空壳直到所有功能完备，可以径直开到经销商那里。汽车下线后还要等多久才算是装配完毕呢？嗯，从生产线的末尾开始四十英寸吧！

　　所有参与制造汽车的人们都共享产品的视觉效果，这对汽车的生产很有帮助。生产者使用所有人都能够理解的术语，这是因为每一个部件，每一个连接，每一个接口再他们共享的汽车效果图中，都在它们应该在的地方，不可能产生歧义。

　　不幸的是，测试世界并不是这样的。前面问到的问题，诸如“等多久才算装配完毕呢？”或“哪些任务还没有完成？”都在困扰着我们。这是21世纪测试人员要解决的问题。

　　架构师和开发人员已经在解决可视化这个问题。Visual Studio 充满了图例和可视化元素，从执行序列图到依赖关系图都有。测试人员也正在解决这个问题。在微软帝国的城墙内，已经出现了可视化的解决方案，比如通过观察看Xbox标题中的代码改动（修改过的代码对象会呈现绿色，测试完之后才变成正常），来判断未测试代码在Windows代码库中的复杂行（代码覆盖的热图与代码复杂性热图的比对，将以三维的形式表现出来，供测试人员直接找到问题区域）。这种可视化的效果是惊人的、优美的，它使测试人员一眼看出那些地方需要测试。

　　我们需要更多这样的东西来解决可视化问题，但是我们需要认真地对待他们。我们不能简单的接受UML和模型生成器提供的试图。那些图画是用来解决其他问题的，他们不一定适合我们面临的问题。现有的很多视图是为架构师和开发人员的不同要求服务的。我们需要从测试人员的角度看待可视化。我们需要的视图要能够映射软件需求到对应到代码、测试用例到对应的接口、代码改动到对应图形用户界面，以及代码覆盖到对应的控件。如果我们在测试环境下执行应用程序时，能够看到控件闪烁着不同程度的光，这些光的强度反映了代码覆盖的程度，或者是与之相关的测试用例的数量，这难道不好吗？如果我们可以把网络利用率或是数据库通信的实际时间，用图形动画的方式显示出来，这难道不好吗？为什么我们不应当看到即时发生的网络流量和SQL查询？在应用程序的表面下隐藏了许多看不到的东西，现在是时候把他们挖掘出来并加以利用了，他们将有助于我们提高代码质量。

　　这是一个可以短期解决的问题，很多聪明人正在努力解决它。这是具有生动色彩的软件测试。

　　测试文化

　　几个月前我参加了一个讲座，它由一名技术院士（也许是一名杰出工程师，我觉得这两者之间没什么不同）主讲，他是微软帝国里为数不多的精英之一。像所有的技术院士一样，这个家伙聪明得有些邪门，在介绍他和他们的团队正在构建的某个新产品的设计时，我突然觉得自己领悟到了什么。

　　很明显，这个顿悟使我的面部表情像正在排肾结石。这名技术院士注意到了（坐在我前面的女孩也一样，但我不想岔开话题），然后他在讲座结束后找到我。以下是我们谈话的原文：

　　“詹姆斯，”（他知道我的名字！）“你看起来像是对我的设计或是产品有些问题。我很乐意听听你的意见。”

　　“不，我对你的产品或是设计没有问题。我的问题在于你自己本身。”

　　“哦？”

　　“像你这样的人把我吓到了。“我告诉他，”你把时间都集中于构思系统功能，实现用户场景和设计用户界面和协议。你处在一个重要的位置，人们会听你的话去构建你所设想的东西。但你做的所有这些都没有从测试的基本角度考虑一下。”

　　在那个时候他开始试图做正确的事情……把注意力转移到测试上来。他邀请我审查讲座里涉及到的设计。这正是你期望他做的。

　　但是对于测试而言，这也正是错误的反应。

　　让测试人员参与设计肯定要好的多。但是这样做的好处也有限。测试人员只寻找可测试性（testability）问题。开发人员寻找应用方面的问题。谁兼顾这两个方面呢？谁能决定这两者之间的正确取舍？测试人员和开发人员都无法做到，让测试人员参与设计仅仅表明有所改善；让设计者（以及其他的软件开发周期里的角色）参与测试才是我们的将来。