微軟在自己的園區修建了一個非常酷的未來之家，在那里展示了未來科技和軟件將如何改變家庭
生活和 通訊方式。如果你曾參觀過迪斯尼樂園的“旋轉的進展”，你就會對微軟的未來之家有個大致的印象，但微軟的更先進。（迪斯尼樂園的展示是從上世紀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