微软在自己的园区修建了一个非常酷的未来之家，在那里展示了未来科技和软件将如何改变家庭
生活和 通讯方式。如果你曾参观过迪斯尼乐园的“旋转的进展”，你就会对微软的未来之家有个大致的印象，但微软的更先进。（迪斯尼乐园的展示是从上世纪60年代的 观点来描述未来，它过时了。）我有一天偶然发现，微软也制作了一系列的录像，来描述未来的零售业、医疗保健、工业、制造业以及其他各行各业。就像录像本身 制作精美一样，它们所描述的将来非常令人着迷，那里充满了计算机、射频卡和各式各样的软件。作为一名
测试人员，我吓坏了，不禁想到，如今软件的质量如此糟糕，我们怎样才能测试好未来的应用程序呢？
就这样，我开始了自己的未来探索。我跟公司的几十人交谈，然后开始做很多演示以便收集数百人的意见。其成果就是在Euro STAR的主题演讲和这一博客系列。我在本书中对这一愿景又加以更新，这可以帮助你看到该想法逐步完善的整个过程。
外包。这是一个令人眼熟的术语，微软在2008年利用这种方式完成了很多测试。但是，事情并不总是如此，而且这种方式将来也并不可靠。在这篇文章里，我会谈论测试将来会以什么形式完成，外包作为软件测试的商业模式，会发生哪些根本性的改变。
在一开始的时候，外包出去的测试很少。测试是由内部人力资源（即由编写软件的开发人员同一公司的雇员）来完成的。开发人员和测试人员（通常是同一批人执行两样任务）并肩工作，一起编写、测试并发布软件。
在这种内包时代，供应商的角色是提供支持这种自助测试工具。但是，随着对工具之外的要求付出水面，供应商的角色很快就发生了改变。他们开始提供测试服务 本身，而不仅仅是提供工具给内部人力资源。我们将这一现象称为外包，他仍然是开发主顾们接触测试的基本模式，租用测试服务。
因此，前两代的测试如下所示。
时代 | 供应商角色 |
（第一代）内包 | 提供工具 |
（第二代）外包 | 提供测试服务（包括工具在内） |
对于测试的这种改变，合乎逻辑的下一个步骤就是供应商们提供测试人员，这正是我们进入众包（crowdsourcing）的时代。昨天，软件测试外包公 司Utest的公告标志着这一时代的来临，观察它将如何发展会很有趣。众包模式未来会超过外包模式并赢得市场吗？显然，市场经济和提供众包服务的公司的能 力将会为这一问题提供答案，我个人的观点是众包模式的胜率较高。这并不是一个非此即彼的情况，而是测试领域的一种自然演变。较为陈旧的模式将随着时间的推 移，为新的模式让开道路。众包取代外包，将会成为达尔文自然选择的一个实例，只是它会在短短的几年就可以看出结果罢了。在由经济和质量约束共同决定的时间 范围内，适者生存。
第三代的测试模式如下所示。
时代 | 供应商角色 |
（第三代）众包 | 提供测试人员（包括工具、测试服务在内） |
未来是怎么样的呢？在我们测试领域的DNA深处，是否埋藏有一个进化基因，它会使众包演变成更好的东西呢？我认为尽管可能需要几年时间和一些技术上的跨 越，它的确是这样的。现在我将衍生出一个新术语，这只是为这一概念取一个名字：测包（testsourcing），如下所示。
时代 | 供应商角色 |
（第四代）测包 | 提供测试工件（包括工具、测试服务和测试人员在内） |
没有跨越未知的关键技术，就无法解释什么是测包。这个技术就是虚拟化。
为了让测包掌握未来的测试必须打破两个关键的技术壁垒：测试中产生的人工产品的重用性以及用户环境的可达性。让我解释一下这两个概念。 重用性：得益于20世纪90年代面向对象及其衍生技术的普及，软件开发所产生的人工产品实现了重用。我们今天开发的大部分软件都是由预先写好的库拼接在一 起所构成的一个整体。不幸的是，测试还没有这样做。写一个测试用例并简单的传递给另外一名测试人员让他重用，这样的想法在实践中很罕见。测试用例过于依赖 测试平台：他们是特定于某个待测的应用程序的；他们依赖于一些其他测试人员没有的工具；他们需要一个自动化测试架构、软件库以及网络配置等，而这些东西很 难被潜在的重用用户所复制。
用户环境：全面测试需要针对不同的用户环境，这些用户环境的绝对数量让人生畏。假设我编写了一个应用程序打算让它在各种各样的手机上运行。我可 以从哪里得到这些电话来测试自己的应用程序呢？我如何配置这些手机，才能把它们看作是自己心目中客户所拥有的手机呢？其他类型的应用程序也会遇到同样的情 况。如果我写了一个web应用程序，我如何才能把这些不同的因素考虑进去：操作系统、浏览器、浏览器设置、插件、注册表配置、安全设置、机器设定和存在潜 在冲突的应用程序类型？
对于这两个问题，目前浮现的答案是虚拟化技术，它正在有条不紊地变得更便宜、速度更快、功能更强大，它正在被应用于从实验室管理到IT基础设施部署的整个应用领域当中。
虚拟化具有很大的潜力，使“众包者“能够提供众包服务。专业的测试套件、测试平台和测试工具都可以被一键化到虚拟机中，供任何人在任何地方使 用。正如今天的软件开发人员人员能够重用同事和前辈们的代码一样，众包者中的测试人员也可以通过这种方式，来重用测试套件和测试工具。重用让一个给定的开 发人员能够可靠地扩展应用程序的范围，同样地，它也会增加一个应用程序测试人员可以测试的类型。虚拟化使得重用复杂精密的测试框架能够在将来成为可能。
对于用户环境的数量问题，虚拟化同样帮了测试人员的大忙。用户只需一键就可以将他们的整个计算机传到虚拟机，并通过云端计算提供给测试人员。如 果我们能够存储世界上所有的影片，给任何人在任何地方即时查看，我们为什么不能对虚拟用户环境做同样的事呢？虚拟化技术已经存在（对于个人电脑而言），或 者是近乎存在（对于移动设备或是其他特殊设定的用户环境而言）。我们只需要简单地将它应用到测试问题。
最终这样做的结果是，任何测试人员，在任何地点，都可以广泛利用一个多样化的、可重用的自动化测试平台和用户环境。这样有助于众包者更好地提供 服务，并从技术角度来看，他们甚至可以和有特殊才能的外包者媲美，由于他们的人数远远超过外包者（至少在理论上，如果不是在实践中的话），这种新模式的优 势显而易见。
市场也青睐那些得到虚拟技术支持的众包模式。用户环境将具有经济价值，众包测试人员人员为了获得竞争优势会对这些用户环境垂涎三尺。他们会激励 用户点击那些一键化按钮来虚拟并共享用户自己的环境（是的，这一模式会受到隐私问题的影响，但是那些问题都是可以解决的）。由于存在问题的环境比那些工作 良好的环境更有价值，假设遇到停工的驱动器和应用程序错误，此时，用户的态度将会完全颠倒过来：因为这意味着他们创造的虚拟测试更具有金钱价值……在那些 错误中有黄金！同样地，人们激励测试人员共享他们的测试宝藏，并使他们尽可能的被重用。市场力量的作用使得未来将是可重用测试产品的天下，而虚拟化使得这 一未来成为可能。
那么，这个有着虚拟化技术支持的未来对测试人员本身意味着什么呢？嗯，让我们快进20~30年（或更长的时间，如果你对此表示怀疑），在那个时 候将会有以百万（或更多？）计的用户环境被收集、克隆、存储并共享。我能想象这些环境就像公共图书馆一样可以让测试人员可以免费浏览，或者像私人图书馆似 的进行订阅。测试用例和测试套件可以如法炮制，视其价值和可用性进行收费。
也许，随之未来的时代将只有很少的人类测试人员，只有少数的东西和特质的产品（或者是像操作系统一样的极端复杂性的产品）需要他们进行干预。对 于大多数的开发者来讲，可以雇佣一名测试设计者从海量的可用虚拟测试环境中挑出所需要的，然后并执行他们：由于所有的自动化和最终用户配置已经设好并随时 可用，以百万人年计的测试将在几个小时内结束。这就是测包的世界。
这是我们目前所知道的，软件测试的最后结局，但对于从事测试工作的人员来说，要对付其他有趣的挑战和问题，这只是一个全新的开端。这样的将来是 能够实现的，它并不需要除了虚拟化之外的以外的东西，其他所需要的那些技术要么已经存在，要么已经呼之欲出。这也意味着，随着我们转变成了设计人员（也就 是执行测试），或者担任开发人员的角色（也就是编写和维护可重用性产品），测试人员需要付出更加倍的努力。我们不要成为在软件开发晚期的“英雄”，测试人 员在虚拟化的未来世界中，应该是一等公民。
这是我最钟爱的一个预测，THUD（ THUD 是Tester's Head UP Display的缩写，测试人员的平视显示器，平视显示器（HUD）是将资讯投射于飞行员正前方玻璃上的飞行辅助仪器）是我们正在积极建造的一个工具。
这是我们对于软件测试未来预测的第三部分，它要讨论的主题是信息的未来，测试人员在未来如何利用信息使他们的测试做得更好。
预测1：测包
预测2：虚拟化
预测3：信息
你使用哪些信息来帮助自己测试软件？测试规范？用户手册？在此之前（或与之竞争）的版本？源代码？网络协议分析器？进程监控器？这些信息是否有用？它们拿来就可以直接使用吗？
信息是所有软件测试工作的核心。作为测试人员，对软件应该有哪些功能，它是如何实现的，了解的越多，我们的测试就会做的更好。如果测试人员对于 他们测试的软件知之甚少，并且了解到的信息都不是专门针对测试工作的，让它做的更加容易，这样的情况是不能接受的。我可以高兴的说，这样的局面正在迅速地 发生改变……并且在短期内，我们一定会实现在正确的时间，获得正确的信息。
我从电子游戏中获得了测试信息的这些想法。在电子游戏中，我们在桌面上显示着相关信息并近乎完美地运用着它们。关于游戏、玩家、对手和环境的资 料，你了解得越多，你就会玩得更好，获得更好的分数。在电子游戏中，它们都显示在一个叫HUD或者成为平视显示器的玩意儿里。一个玩家的能力、武器和健康 值都显示在一个迷你地图中，对手的类似资料也可能会有（我儿子过去玩Pokemon时，他可以在游戏中通过访问Pokedex，了解他可能遇到的所有 Pokemon怪物）。这些游戏的思想很简单：你拥有并且可以使用的信息越多，你就越有机会在游戏中通关。
我非常想把这个思想原封不动地转给软件测试人员，给他们更多的信息来增加他们成功的机会。但是，在测试世界里，由于缺乏这种丰富的信息基础构 造，所以大部分测试都陷入黑盒测试，哪里是我们的迷你地图，可以指出当前正在测试哪一个屏幕，它是如何使系统其它部分连接起来的？为什么我不能将鼠标悬停 在一个图形用户界面控件上以看到源代码，设置这个控件所包含的（以及我们可以测试的）属性列表？如果我在测试一个API，为什么我不能看到我和我的测试伙 伴们已经测试过的参数组合呢？我需要迅速得到所有这些信息，并以简洁易用的格式来帮助我进行测试，而不是去某些SharePoint站点或是数据库中乱翻 一气，因为那些地方充满了其他项目中的各种人为产品，与我的测试毫无关联。它们只会让我分心，我需要一个平视显示器。
我在微软的同事乔艾伦穆哈尔斯基（Joe Allan Muharsky）把我渴望的这些信息称为THUD——测试人员的平视显示器——将测试人员找出软件缺陷并验证功能所需要的信息格式化，使之成为向其服务 的一种即时可用资料。你可以讲THUD看作是一层表皮，它将正在进行测试的应用程序包裹起来，随着应用程序的上下文环境，浮现出对其测试有用的资料和工 具。目前，THUD用的很少，甚至有的THUD没有包含正确信息。正如在游戏中，没有玩家会想着不用THUD就穿越不可预知的危险世界一样，到了将来，没 有测试人员会想着不用THUD就进行测试。
如果这听起来有点像作弊的话，就随便你怎么向了。玩家通过HUD进行欺骗，相对那些没有这样做的，的确可以给他们带来更大的优势。由于内部测试 人员可以访问源代码、协议、后端、前端和中间件，所以我们确实可以进行这样的“欺骗”。我们可以利用这些欺骗获得的巨大优势，比普通黑盒测试人员和用户更 好地寻找软件缺陷。这正是我们想要的情形：比其他任何人更快、更有效地找到自己的软件缺陷。这是我全心全意认同的欺骗，可是目前，我们却没有利用这些欺骗 所需要的信息。
在未来我们会这样做，与我们现在的信息饥渴相比，那样的未来将完全不同。
回顾过去，显示世界并不是完美无缺的，我们无法预测未来是美好的，所以，这个预测显得令人迷惑不解。但是，由于这是对未来的预测，我们不知道未来会 怎样，就还算过得去。许多人谈论着软件开发周期里的测试前移。据我所知，我们使测试人员参与规范审查等等已经几十年了。这是测试人员前移，而不是测试前 移。我们真正应该做的是，在软件开发周期中，尽早获得可测试的东西，使我们尽快开始测试。
测试前移
在测试中存在一个鸿沟，它在整个软件开发周期中蚕食着软件的质量、生产效率和其他可控特性。这个鸿沟就是从软件缺陷产生直到它被发现的时间鸿 沟。这个鸿沟越大，软件缺陷在系统中停留的时间就会越长。显然，这是很糟糕的，但是，我们过去所做的，仅仅是指出软件缺陷在系统中待的时间越长，清楚它的 代价也就越大。
在将来，我们要做的是：消除这个鸿沟。
但是，消除这个鸿沟意味着对我们目前测试方式的根本转变。在2008年，一名开发人员，完全是处于偶然，就可以引入一个软件缺陷，这一现象提醒 着你——我们的开发环境没有什么办法阻止它发生，直到二进制代码构建好以后，开发h饿测试人员很少会协调一致的努力寻找软件缺陷。我们引入软件缺陷并让它 们自由蔓延，直到在开发周期的最后阶段，依靠那些善于在软件开发后期寻找软件缺陷的英雄们，将我们带出困境。
作为软件测试人员，我们提供了宝贵的软件缺陷寻找和分析技术，所以在今后，我们所要做的是，在软件开发周期中尽早应用这些技术，远远早于我们目 前所处的阶段，我预见有两种主要的方法会帮助我们达到这个目的。一个是不等二进制运行代码构建好，直接将测试应用于软件开发周期的早期开发阶段。第二个是 尽早地构建二进制运行代码，使我们能够尽快地测试。
下面让我们从’早期开发阶段测试‘开始，就这两种方法逐个进行讨论。在开发周期的后期英雄主义阶段里，我们运用所有的软件缺陷寻找方法，在可运 行的二进制代码中根据发布的接口寻找软件缺陷。我们把编译好的二进制代码、程序集合和字节代码等拿来放到测试沙袋中，用数据和输入反复击打它，直到我们挖 出足够的软件缺陷病确定待测目标的质量足够好（在将来的博客里，我也许会介绍测量和发布标准）。但是为什么要等到二进制代码准备好呢？为什么我们不能应用 这些测试技术在产品架构阶段？……或是分析用户需求和场景阶段？……或是规范和设计阶段？莫非在过去半个世纪积累起来的所有测试技术，测试工艺和测试智 慧，只能用于软件运行阶段？为什么系统架构不能用同样的方法进行测试呢？嗯，答案是没有好的理由让我们不这样去做。事实上，我认为微软有很多先进的团队的 确将测试技术应用到早期开发阶段，在将来我们会找到这样做的系统方法。测试将会开始于，不像现在这样，当某样东西可测的时候，而是当某样东西出现了而需要 测试的时候。这是一个微妙但是重要的区别。
“尽早构建二进制运行代码”是要讨论的第二部分，但是这样做代表我们需要克服一个技术上的障碍。在2008年的时候，我们一个接一个的编写软件 模块，如果缺乏所有模块中的其中之一，我们就不能构建出一个整体。这意味着，测试工作必须等到所有的模块完成到某种程度才能进行。软件缺陷可以存活几天或 者几周，知道测试开始并发现它们。我们可以用虚拟的模块来替代哪些部分完成的模块吗？或是用适配器来模仿外部的行为？我们能够构建通用的变色龙组件，让它 改变自己的行为去配合它们（暂时）嵌入的系统？我预测会的……因为我们必须这样做。虚拟组件和变色龙组件将可以使测试人员，在紧接着一个软件缺陷产生出来 后，就施展它们的检测手艺。这些软件缺陷将很少有机会在露面之后还能劫后余生。
测试工作相当重要，不要等到开发周期结束才开始进行。是的，目前交互式开发和敏捷开发较早地创建了可测试代码（尽管功能较小，功能不完整），但 是发布软件后，我们仍然有很多的软件缺陷。我们现在所做的远远不够。未来必定会将测试应用到软件开发的早期阶段，使我们在代码完全建立之前就搭建好可行 的、可测试的环境。
本文摘自James Whittaker所著《探索式软件测试》附录3