回顾过去，显示世界并不是完美无缺的，我们无法预测未来是美好的，所以，这个预测显得令人迷惑不解。但是，由于这是对未来的预测，我们不知道未来会怎样，还算过得去。许多人谈论着软件开发周期里的测试前移。据我所知，我们使测试人员参与规范审查等等已经几十年了。这是测试人员前移，而不是测试前移。我们真正应该做的是，在软件开发周期中，尽早获得可测试的东西，使我们尽快开始测试。

　　测试前移

　　在测试中存在一个鸿沟，它在整个软件开发周期中蚕食着软件的质量、生产效率和其他可控特性。这个鸿沟是从软件缺陷产生直到它被发现的时间鸿沟。这个鸿沟越大，软件缺陷在系统中停留的时间会越长。显然，这是很糟糕的，但是，我们过去所做的，仅仅是指出软件缺陷在系统中待的时间越长，清楚它的代价也越大。

　　在将来，我们要做的是：消除这个鸿沟。

　　但是，消除这个鸿沟意味着对我们目前测试方式的根本转变。在2008年，一名开发人员，完全是处于偶然，可以引入一个软件缺陷，这一现象提醒着你——我们的开发环境没有什么办法阻止它发生，直到二进制代码构建好以后，开发h饿测试人员很少会协调一致的努力寻找软件缺陷。我们引入软件缺陷并让它们自由蔓延，直到在开发周期的后阶段，依靠那些善于在软件开发后期寻找软件缺陷的英雄们，将我们带出困境。

　　作为软件测试人员，我们提供了宝贵的软件缺陷寻找和分析技术，所以在今后，我们所要做的是，在软件开发周期中尽早应用这些技术，远远早于我们目前所处的阶段，我预见有两种主要的方法会帮助我们达到这个目的。一个是不等二进制运行代码构建好，直接将测试应用于软件开发周期的早期开发阶段。第二个是尽早地构建二进制运行代码，使我们能够尽快地测试。

　　下面让我们从’早期开发阶段测试‘开始，这两种方法逐个进行讨论。在开发周期的后期英雄主义阶段里，我们运用所有的软件缺陷寻找方法，在可运行的二进制代码中根据发布的接口寻找软件缺陷。我们把编译好的二进制代码、程序集合和字节代码等拿来放到测试沙袋中，用数据和输入反复击打它，直到我们挖出足够的软件缺陷病确定待测目标的质量足够好（在将来的博客里，我也许会介绍测量和发布标准）。但是为什么要等到二进制代码准备好呢？为什么我们不能应用这些测试技术在产品架构阶段？……或是分析用户需求和场景阶段？……或是规范和设计阶段？莫非在过去半个世纪积累起来的所有测试技术，测试工艺和测试智慧，只能用于软件运行阶段？为什么系统架构不能用同样的方法进行测试呢？嗯，答案是没有好的理由让我们不这样去做。事实上，我认为微软有很多先进的团队的确将测试技术应用到早期开发阶段，在将来我们会找到这样做的系统方法。测试将会开始于，不像现在这样，当某样东西可测的时候，而是当某样东西出现了而需要测试的时候。这是一个微妙但是重要的区别。

　　“尽早构建二进制运行代码”是要讨论的第二部分，但是这样做代表我们需要克服一个技术上的障碍。在2008年的时候，我们一个接一个的编写软件模块，如果缺乏所有模块中的其中之一，我们不能构建出一个整体。这意味着，测试工作必须等到所有的模块完成到某种程度才能进行。软件缺陷可以存活几天或者几周，知道测试开始并发现它们。我们可以用虚拟的模块来替代哪些部分完成的模块吗？或是用适配器来模仿外部的行为？我们能够构建通用的变色龙组件，让它改变自己的行为去配合它们（暂时）嵌入的系统？我预测会的……因为我们必须这样做。虚拟组件和变色龙组件将可以使测试人员，在紧接着一个软件缺陷产生出来后，施展它们的检测手艺。这些软件缺陷将很少有机会在露面之后还能劫后余生。

　　测试工作相当重要，不要等到开发周期结束才开始进行。是的，目前交互式开发和敏捷开发较早地创建了可测试代码（尽管功能较小，功能不完整），但是发布软件后，我们仍然有很多的软件缺陷。我们现在所做的远远不够。未来必定会将测试应用到软件开发的早期阶段，使我们在代码完全建立之前搭建好可行的、可测试的环境。

　　本文摘自James Whittaker所著《探索式软件测试》附录3