微軟在自己的園區(qū)修建了一個非常酷的未來之家，在那里展示了未來科技和軟件將如何改變家庭
生活和 通訊方式。如果你曾參觀過迪斯尼樂園的“旋轉(zhuǎn)的進展”，你就會對微軟的未來之家有個大致的印象，但微軟的更先進。（迪斯尼樂園的展示是從上世紀60年代的 觀點來描述未來，它過時了。）我有一天偶然發(fā)現(xiàn)，微軟也制作了一系列的錄像，來描述未來的零售業(yè)、醫(yī)療保健、工業(yè)、制造業(yè)以及其他各行各業(yè)。就像錄像本身 制作精美一樣，它們所描述的將來非常令人著迷，那里充滿了計算機、射頻卡和各式各樣的軟件。作為一名
測試人員，我嚇壞了，不禁想到，如今軟件的質(zhì)量如此糟糕，我們怎樣才能測試好未來的應(yīng)用程序呢？
就這樣，我開始了自己的未來探索。我跟公司的幾十人交談，然后開始做很多演示以便收集數(shù)百人的意見。其成果就是在Euro STAR的主題演講和這一博客系列。我在本書中對這一愿景又加以更新，這可以幫助你看到該想法逐步完善的整個過程。
外包。這是一個令人眼熟的術(shù)語，微軟在2008年利用這種方式完成了很多測試。但是，事情并不總是如此，而且這種方式將來也并不可靠。在這篇文章里，我會談?wù)摐y試將來會以什么形式完成，外包作為軟件測試的商業(yè)模式，會發(fā)生哪些根本性的改變。
在一開始的時候，外包出去的測試很少。測試是由內(nèi)部人力資源（即由編寫軟件的開發(fā)人員同一公司的雇員）來完成的。開發(fā)人員和測試人員（通常是同一批人執(zhí)行兩樣任務(wù)）并肩工作，一起編寫、測試并發(fā)布軟件。
在這種內(nèi)包時代，供應(yīng)商的角色是提供支持這種自助測試工具。但是，隨著對工具之外的要求付出水面，供應(yīng)商的角色很快就發(fā)生了改變。他們開始提供測試服務(wù) 本身，而不僅僅是提供工具給內(nèi)部人力資源。我們將這一現(xiàn)象稱為外包，他仍然是開發(fā)主顧們接觸測試的基本模式，租用測試服務(wù)。
因此，前兩代的測試如下所示。
時代 | 供應(yīng)商角色 |
（第一代）內(nèi)包 | 提供工具 |
（第二代）外包 | 提供測試服務(wù)（包括工具在內(nèi)） |
對于測試的這種改變，合乎邏輯的下一個步驟就是供應(yīng)商們提供測試人員，這正是我們進入眾包（crowdsourcing）的時代。昨天，軟件測試外包公 司Utest的公告標志著這一時代的來臨，觀察它將如何發(fā)展會很有趣。眾包模式未來會超過外包模式并贏得市場嗎？顯然，市場經(jīng)濟和提供眾包服務(wù)的公司的能 力將會為這一問題提供答案，我個人的觀點是眾包模式的勝率較高。這并不是一個非此即彼的情況，而是測試領(lǐng)域的一種自然演變。較為陳舊的模式將隨著時間的推 移，為新的模式讓開道路。眾包取代外包，將會成為達爾文自然選擇的一個實例，只是它會在短短的幾年就可以看出結(jié)果罷了。在由經(jīng)濟和質(zhì)量約束共同決定的時間 范圍內(nèi)，適者生存。
第三代的測試模式如下所示。
時代 | 供應(yīng)商角色 |
（第三代）眾包 | 提供測試人員（包括工具、測試服務(wù)在內(nèi)） |
未來是怎么樣的呢？在我們測試領(lǐng)域的DNA深處，是否埋藏有一個進化基因，它會使眾包演變成更好的東西呢？我認為盡管可能需要幾年時間和一些技術(shù)上的跨 越，它的確是這樣的?，F(xiàn)在我將衍生出一個新術(shù)語，這只是為這一概念取一個名字：測包（testsourcing），如下所示。
時代 | 供應(yīng)商角色 |
（第四代）測包 | 提供測試工件（包括工具、測試服務(wù)和測試人員在內(nèi)） |
沒有跨越未知的關(guān)鍵技術(shù)，就無法解釋什么是測包。這個技術(shù)就是虛擬化。
為了讓測包掌握未來的測試必須打破兩個關(guān)鍵的技術(shù)壁壘：測試中產(chǎn)生的人工產(chǎn)品的重用性以及用戶環(huán)境的可達性。讓我解釋一下這兩個概念。 重用性：得益于20世紀90年代面向?qū)ο蠹捌溲苌夹g(shù)的普及，軟件開發(fā)所產(chǎn)生的人工產(chǎn)品實現(xiàn)了重用。我們今天開發(fā)的大部分軟件都是由預(yù)先寫好的庫拼接在一 起所構(gòu)成的一個整體。不幸的是，測試還沒有這樣做。寫一個測試用例并簡單的傳遞給另外一名測試人員讓他重用，這樣的想法在實踐中很罕見。測試用例過于依賴 測試平臺：他們是特定于某個待測的應(yīng)用程序的；他們依賴于一些其他測試人員沒有的工具；他們需要一個自動化測試架構(gòu)、軟件庫以及網(wǎng)絡(luò)配置等，而這些東西很 難被潛在的重用用戶所復(fù)制。
用戶環(huán)境：全面測試需要針對不同的用戶環(huán)境，這些用戶環(huán)境的絕對數(shù)量讓人生畏。假設(shè)我編寫了一個應(yīng)用程序打算讓它在各種各樣的手機上運行。我可 以從哪里得到這些電話來測試自己的應(yīng)用程序呢？我如何配置這些手機，才能把它們看作是自己心目中客戶所擁有的手機呢？其他類型的應(yīng)用程序也會遇到同樣的情 況。如果我寫了一個web應(yīng)用程序，我如何才能把這些不同的因素考慮進去：操作系統(tǒng)、瀏覽器、瀏覽器設(shè)置、插件、注冊表配置、安全設(shè)置、機器設(shè)定和存在潛 在沖突的應(yīng)用程序類型？
對于這兩個問題，目前浮現(xiàn)的答案是虛擬化技術(shù)，它正在有條不紊地變得更便宜、速度更快、功能更強大，它正在被應(yīng)用于從實驗室管理到IT基礎(chǔ)設(shè)施部署的整個應(yīng)用領(lǐng)域當(dāng)中。
虛擬化具有很大的潛力，使“眾包者“能夠提供眾包服務(wù)。專業(yè)的測試套件、測試平臺和測試工具都可以被一鍵化到虛擬機中，供任何人在任何地方使 用。正如今天的軟件開發(fā)人員人員能夠重用同事和前輩們的代碼一樣，眾包者中的測試人員也可以通過這種方式，來重用測試套件和測試工具。重用讓一個給定的開 發(fā)人員能夠可靠地擴展應(yīng)用程序的范圍，同樣地，它也會增加一個應(yīng)用程序測試人員可以測試的類型。虛擬化使得重用復(fù)雜精密的測試框架能夠在將來成為可能。
對于用戶環(huán)境的數(shù)量問題，虛擬化同樣幫了測試人員的大忙。用戶只需一鍵就可以將他們的整個計算機傳到虛擬機，并通過云端計算提供給測試人員。如 果我們能夠存儲世界上所有的影片，給任何人在任何地方即時查看，我們?yōu)槭裁床荒軐μ摂M用戶環(huán)境做同樣的事呢？虛擬化技術(shù)已經(jīng)存在（對于個人電腦而言），或 者是近乎存在（對于移動設(shè)備或是其他特殊設(shè)定的用戶環(huán)境而言）。我們只需要簡單地將它應(yīng)用到測試問題。
最終這樣做的結(jié)果是，任何測試人員，在任何地點，都可以廣泛利用一個多樣化的、可重用的自動化測試平臺和用戶環(huán)境。這樣有助于眾包者更好地提供 服務(wù)，并從技術(shù)角度來看，他們甚至可以和有特殊才能的外包者媲美，由于他們的人數(shù)遠遠超過外包者（至少在理論上，如果不是在實踐中的話），這種新模式的優(yōu) 勢顯而易見。
市場也青睞那些得到虛擬技術(shù)支持的眾包模式。用戶環(huán)境將具有經(jīng)濟價值，眾包測試人員人員為了獲得競爭優(yōu)勢會對這些用戶環(huán)境垂涎三尺。他們會激勵 用戶點擊那些一鍵化按鈕來虛擬并共享用戶自己的環(huán)境（是的，這一模式會受到隱私問題的影響，但是那些問題都是可以解決的）。由于存在問題的環(huán)境比那些工作 良好的環(huán)境更有價值，假設(shè)遇到停工的驅(qū)動器和應(yīng)用程序錯誤，此時，用戶的態(tài)度將會完全顛倒過來：因為這意味著他們創(chuàng)造的虛擬測試更具有金錢價值……在那些 錯誤中有黃金！同樣地，人們激勵測試人員共享他們的測試寶藏，并使他們盡可能的被重用。市場力量的作用使得未來將是可重用測試產(chǎn)品的天下，而虛擬化使得這 一未來成為可能。
那么，這個有著虛擬化技術(shù)支持的未來對測試人員本身意味著什么呢？嗯，讓我們快進20~30年（或更長的時間，如果你對此表示懷疑），在那個時 候?qū)幸园偃f（或更多？）計的用戶環(huán)境被收集、克隆、存儲并共享。我能想象這些環(huán)境就像公共圖書館一樣可以讓測試人員可以免費瀏覽，或者像私人圖書館似 的進行訂閱。測試用例和測試套件可以如法炮制，視其價值和可用性進行收費。
也許，隨之未來的時代將只有很少的人類測試人員，只有少數(shù)的東西和特質(zhì)的產(chǎn)品（或者是像操作系統(tǒng)一樣的極端復(fù)雜性的產(chǎn)品）需要他們進行干預(yù)。對 于大多數(shù)的開發(fā)者來講，可以雇傭一名測試設(shè)計者從海量的可用虛擬測試環(huán)境中挑出所需要的，然后并執(zhí)行他們：由于所有的自動化和最終用戶配置已經(jīng)設(shè)好并隨時 可用，以百萬人年計的測試將在幾個小時內(nèi)結(jié)束。這就是測包的世界。
這是我們目前所知道的，軟件測試的最后結(jié)局，但對于從事測試工作的人員來說，要對付其他有趣的挑戰(zhàn)和問題，這只是一個全新的開端。這樣的將來是 能夠?qū)崿F(xiàn)的，它并不需要除了虛擬化之外的以外的東西，其他所需要的那些技術(shù)要么已經(jīng)存在，要么已經(jīng)呼之欲出。這也意味著，隨著我們轉(zhuǎn)變成了設(shè)計人員（也就 是執(zhí)行測試），或者擔(dān)任開發(fā)人員的角色（也就是編寫和維護可重用性產(chǎn)品），測試人員需要付出更加倍的努力。我們不要成為在軟件開發(fā)晚期的“英雄”，測試人 員在虛擬化的未來世界中，應(yīng)該是一等公民。
這是我最鐘愛的一個預(yù)測，THUD（ THUD 是Tester's Head UP Display的縮寫，測試人員的平視顯示器，平視顯示器（HUD）是將資訊投射于飛行員正前方玻璃上的飛行輔助儀器）是我們正在積極建造的一個工具。
這是我們對于軟件測試未來預(yù)測的第三部分，它要討論的主題是信息的未來，測試人員在未來如何利用信息使他們的測試做得更好。
預(yù)測1：測包
預(yù)測2：虛擬化
預(yù)測3：信息
你使用哪些信息來幫助自己測試軟件？測試規(guī)范？用戶手冊？在此之前（或與之競爭）的版本？源代碼？網(wǎng)絡(luò)協(xié)議分析器？進程監(jiān)控器？這些信息是否有用？它們拿來就可以直接使用嗎？
信息是所有軟件測試工作的核心。作為測試人員，對軟件應(yīng)該有哪些功能，它是如何實現(xiàn)的，了解的越多，我們的測試就會做的更好。如果測試人員對于 他們測試的軟件知之甚少，并且了解到的信息都不是專門針對測試工作的，讓它做的更加容易，這樣的情況是不能接受的。我可以高興的說，這樣的局面正在迅速地 發(fā)生改變……并且在短期內(nèi)，我們一定會實現(xiàn)在正確的時間，獲得正確的信息。
我從電子游戲中獲得了測試信息的這些想法。在電子游戲中，我們在桌面上顯示著相關(guān)信息并近乎完美地運用著它們。關(guān)于游戲、玩家、對手和環(huán)境的資 料，你了解得越多，你就會玩得更好，獲得更好的分數(shù)。在電子游戲中，它們都顯示在一個叫HUD或者成為平視顯示器的玩意兒里。一個玩家的能力、武器和健康 值都顯示在一個迷你地圖中，對手的類似資料也可能會有（我兒子過去玩Pokemon時，他可以在游戲中通過訪問Pokedex，了解他可能遇到的所有 Pokemon怪物）。這些游戲的思想很簡單：你擁有并且可以使用的信息越多，你就越有機會在游戲中通關(guān)。
我非常想把這個思想原封不動地轉(zhuǎn)給軟件測試人員，給他們更多的信息來增加他們成功的機會。但是，在測試世界里，由于缺乏這種豐富的信息基礎(chǔ)構(gòu) 造，所以大部分測試都陷入黑盒測試，哪里是我們的迷你地圖，可以指出當(dāng)前正在測試哪一個屏幕，它是如何使系統(tǒng)其它部分連接起來的？為什么我不能將鼠標懸停 在一個圖形用戶界面控件上以看到源代碼，設(shè)置這個控件所包含的（以及我們可以測試的）屬性列表？如果我在測試一個API，為什么我不能看到我和我的測試伙 伴們已經(jīng)測試過的參數(shù)組合呢？我需要迅速得到所有這些信息，并以簡潔易用的格式來幫助我進行測試，而不是去某些SharePoint站點或是數(shù)據(jù)庫中亂翻 一氣，因為那些地方充滿了其他項目中的各種人為產(chǎn)品，與我的測試毫無關(guān)聯(lián)。它們只會讓我分心，我需要一個平視顯示器。
我在微軟的同事喬艾倫穆哈爾斯基（Joe Allan Muharsky）把我渴望的這些信息稱為THUD——測試人員的平視顯示器——將測試人員找出軟件缺陷并驗證功能所需要的信息格式化，使之成為向其服務(wù) 的一種即時可用資料。你可以講THUD看作是一層表皮，它將正在進行測試的應(yīng)用程序包裹起來，隨著應(yīng)用程序的上下文環(huán)境，浮現(xiàn)出對其測試有用的資料和工 具。目前，THUD用的很少，甚至有的THUD沒有包含正確信息。正如在游戲中，沒有玩家會想著不用THUD就穿越不可預(yù)知的危險世界一樣，到了將來，沒 有測試人員會想著不用THUD就進行測試。
如果這聽起來有點像作弊的話，就隨便你怎么向了。玩家通過HUD進行欺騙，相對那些沒有這樣做的，的確可以給他們帶來更大的優(yōu)勢。由于內(nèi)部測試 人員可以訪問源代碼、協(xié)議、后端、前端和中間件，所以我們確實可以進行這樣的“欺騙”。我們可以利用這些欺騙獲得的巨大優(yōu)勢，比普通黑盒測試人員和用戶更 好地尋找軟件缺陷。這正是我們想要的情形：比其他任何人更快、更有效地找到自己的軟件缺陷。這是我全心全意認同的欺騙，可是目前，我們卻沒有利用這些欺騙 所需要的信息。
在未來我們會這樣做，與我們現(xiàn)在的信息饑渴相比，那樣的未來將完全不同。
回顧過去，顯示世界并不是完美無缺的，我們無法預(yù)測未來是美好的，所以，這個預(yù)測顯得令人迷惑不解。但是，由于這是對未來的預(yù)測，我們不知道未來會 怎樣，就還算過得去。許多人談?wù)撝浖_發(fā)周期里的測試前移。據(jù)我所知，我們使測試人員參與規(guī)范審查等等已經(jīng)幾十年了。這是測試人員前移，而不是測試前 移。我們真正應(yīng)該做的是，在軟件開發(fā)周期中，盡早獲得可測試的東西，使我們盡快開始測試。
測試前移
在測試中存在一個鴻溝，它在整個軟件開發(fā)周期中蠶食著軟件的質(zhì)量、生產(chǎn)效率和其他可控特性。這個鴻溝就是從軟件缺陷產(chǎn)生直到它被發(fā)現(xiàn)的時間鴻 溝。這個鴻溝越大，軟件缺陷在系統(tǒng)中停留的時間就會越長。顯然，這是很糟糕的，但是，我們過去所做的，僅僅是指出軟件缺陷在系統(tǒng)中待的時間越長，清楚它的 代價也就越大。
在將來，我們要做的是：消除這個鴻溝。
但是，消除這個鴻溝意味著對我們目前測試方式的根本轉(zhuǎn)變。在2008年，一名開發(fā)人員，完全是處于偶然，就可以引入一個軟件缺陷，這一現(xiàn)象提醒 著你——我們的開發(fā)環(huán)境沒有什么辦法阻止它發(fā)生，直到二進制代碼構(gòu)建好以后，開發(fā)h餓測試人員很少會協(xié)調(diào)一致的努力尋找軟件缺陷。我們引入軟件缺陷并讓它 們自由蔓延，直到在開發(fā)周期的最后階段，依靠那些善于在軟件開發(fā)后期尋找軟件缺陷的英雄們，將我們帶出困境。
作為軟件測試人員，我們提供了寶貴的軟件缺陷尋找和分析技術(shù)，所以在今后，我們所要做的是，在軟件開發(fā)周期中盡早應(yīng)用這些技術(shù)，遠遠早于我們目 前所處的階段，我預(yù)見有兩種主要的方法會幫助我們達到這個目的。一個是不等二進制運行代碼構(gòu)建好，直接將測試應(yīng)用于軟件開發(fā)周期的早期開發(fā)階段。第二個是 盡早地構(gòu)建二進制運行代碼，使我們能夠盡快地測試。
下面讓我們從’早期開發(fā)階段測試‘開始，就這兩種方法逐個進行討論。在開發(fā)周期的后期英雄主義階段里，我們運用所有的軟件缺陷尋找方法，在可運 行的二進制代碼中根據(jù)發(fā)布的接口尋找軟件缺陷。我們把編譯好的二進制代碼、程序集合和字節(jié)代碼等拿來放到測試沙袋中，用數(shù)據(jù)和輸入反復(fù)擊打它，直到我們挖 出足夠的軟件缺陷病確定待測目標的質(zhì)量足夠好（在將來的博客里，我也許會介紹測量和發(fā)布標準）。但是為什么要等到二進制代碼準備好呢？為什么我們不能應(yīng)用 這些測試技術(shù)在產(chǎn)品架構(gòu)階段？……或是分析用戶需求和場景階段？……或是規(guī)范和設(shè)計階段？莫非在過去半個世紀積累起來的所有測試技術(shù)，測試工藝和測試智 慧，只能用于軟件運行階段？為什么系統(tǒng)架構(gòu)不能用同樣的方法進行測試呢？嗯，答案是沒有好的理由讓我們不這樣去做。事實上，我認為微軟有很多先進的團隊的 確將測試技術(shù)應(yīng)用到早期開發(fā)階段，在將來我們會找到這樣做的系統(tǒng)方法。測試將會開始于，不像現(xiàn)在這樣，當(dāng)某樣?xùn)|西可測的時候，而是當(dāng)某樣?xùn)|西出現(xiàn)了而需要 測試的時候。這是一個微妙但是重要的區(qū)別。
“盡早構(gòu)建二進制運行代碼”是要討論的第二部分，但是這樣做代表我們需要克服一個技術(shù)上的障礙。在2008年的時候，我們一個接一個的編寫軟件 模塊，如果缺乏所有模塊中的其中之一，我們就不能構(gòu)建出一個整體。這意味著，測試工作必須等到所有的模塊完成到某種程度才能進行。軟件缺陷可以存活幾天或 者幾周，知道測試開始并發(fā)現(xiàn)它們。我們可以用虛擬的模塊來替代哪些部分完成的模塊嗎？或是用適配器來模仿外部的行為？我們能夠構(gòu)建通用的變色龍組件，讓它 改變自己的行為去配合它們（暫時）嵌入的系統(tǒng)？我預(yù)測會的……因為我們必須這樣做。虛擬組件和變色龍組件將可以使測試人員，在緊接著一個軟件缺陷產(chǎn)生出來 后，就施展它們的檢測手藝。這些軟件缺陷將很少有機會在露面之后還能劫后余生。
測試工作相當(dāng)重要，不要等到開發(fā)周期結(jié)束才開始進行。是的，目前交互式開發(fā)和敏捷開發(fā)較早地創(chuàng)建了可測試代碼（盡管功能較小，功能不完整），但 是發(fā)布軟件后，我們?nèi)匀挥泻芏嗟能浖毕?。我們現(xiàn)在所做的遠遠不夠。未來必定會將測試應(yīng)用到軟件開發(fā)的早期階段，使我們在代碼完全建立之前就搭建好可行 的、可測試的環(huán)境。
本文摘自James Whittaker所著《探索式軟件測試》附錄3