作者：James Bach，
審稿人：Tim ，Alan Page， Keith Klain， Ben Simo，Paul ， Alan ， ， Noah ...
在這篇白皮書中，我們提供了一個測試自動化的遠景，它將測試人員置于測試的中心，同時促進一種為有可以解決我們許多事情的工具而開心的思考方式，并且，我們積極使用工具而不放棄我們作為技術人員的職責依然在測試工作的主導地位。
工具是很強大的，而且我們可以說出有關它們的激動人心和有用的東西。但“自動化”會暗藏危機、不可信任——不僅僅是因為標簽”自動化”指的是一堆不一樣的東西。因此，我們必須從清醒的角度來看清一些對“自動化”的基本誤解?！白詣踊焙芸赡芙o困難的工作、甚至最好的時光帶來可怕的浪費、混亂和痛苦。如果您需要好的測試，那么好的工具支持將是測試藍圖的一部分，這意味著您必須理解為什么我們的工具出了問題。
機器人，幫幫忙！
我們可以將測試自動化的主要觀點概括為“通過使用戶自動化操作來完成自動化測試”。 我們并沒有聲稱人們真的會這樣做，只是他們試圖去做。我們在簡化測試上發現至少三個重大問題：
“自動化”這個詞是有誤導性的。我們不可能使用戶自動化。我們將他們做的一些行為進行自動化處理，用戶實際上做得比這多得多。
輸出檢查可以自動進行，但測試人員做的遠不止這些。
自動輸出檢查很有意思，但是工具的功能遠不止于此。
自動化帶來了易于接受和易理解的事：用可靠、快速、高效的機器人取代凌亂、復雜的人力！考慮旁邊的圖片，它完美地總結了令人印象深刻的愿景：“自動化完成無躁乏味的事物”。好，那么圖片給我們帶來什么啟示？
它向我們展示了一臺旨在當作人的機器。機器人被構造成人形機器人。它正在使用一種通常由人類操作的工具，其方式與人類操作它的方式完全相同，而不是通過更適合機器人的方式。圖片里沒有描述對機器人進行編程或控制機器人的過程，或者在發生錯誤時糾正機器人的過程。背景中沒有毀壞的的機器人，沒有人的角色，即使在背景中也沒有人出現。圖片傳遞的信息是：機器人在不改變過程本身的情況下，取代人類無趣的任務，并且沒有任何人類存在、指導或表達工作意圖的痕跡。那這是什么自動化？它是如何工作的？沒有！
當然，這是一幅輕松的漫畫，不太需要認真對待。問題是，在我們遍布整個行業的觀察中，我們看到客戶用這個卡通里的形式看待真正的測試、真正的自動化以及真正的人。因此，來自這方面有著非常深的誤解。
有多嚴重？在作者的經驗中，觀察80年代的項目，我們發現，很常見到對自動化嘗試檢測瑣碎且明顯的GUI級錯誤上浪費了他們的預算，浪費了許多時間和精力本應該用來尋找其他嚴重而微妙的問題——我們稱之為深層問題。此外，典型的自動化方法具有Rube 機器的特點。非常需要依賴關系，
并且很容易崩潰。這種自動化幾乎成為項目的一個新的利益相關者；就像某些特別愛干凈的強迫癥女患者，如果房間不是一塵不染，她是不會進入房間。我們相信，在大多數情況下，相對直接投資給以復雜和社會的方式與產品交互的人們(也發現了淺層的bug)，或投入到更便宜的支持工具中幫助測試人員更好地測試，投資于自動化是更好。
沒有人能否認自動化工具用于銷售的演示令人印象深刻。我們所否認的是，人們對“自動化”的理解，應該是什么，以及這些用來銷售的樣品演示如何轉化為可被大眾用在普通項目里的實用價值。
“自動化”的麻煩
“測試自動化”的問題始于單詞本身。測試是在“設計工作室”中發生的創造性和關鍵的工作中的一部分，但是“自動化”鼓勵人們去思考在“工廠的地板”上完成機械化裝配線的工作。
“測試自動化”這個術語的含義也不明確。聽到有人說像“運行自動化測試”這樣的句子是很常見的，其實這個術語是專門指測試工具的。像“測試自動化是值得去做的”這樣的句子不僅是對工具，也對創建、維護、測試和操作那些工具的企業是成立的。在第一層意義上，測試自動化根本不像人類的行為。它非?？於冶阋?，因為你不用支付給電腦費用。在第二種意義上，測試自動化是一種由編寫和操作軟件的人在數小時、幾天或幾周內完成的技術性活動——你必須為這些人的時間付費。
我們觀察到，按照一般的說法，“測試自動化”的驅動策略是編寫產品使用者的普通的、機械的行為，并且那個使用者是一個相當自滿的、缺乏想象力的用戶，然后讓機器以令人眼花繚亂的速度敲擊鍵盤，然后檢查指定的動作和輸入是否產生指定的輸出。由此得出，開始將“測試自動化”看作是一種測試人員的測試工具只是一小步。但即使是一個低技能的人類測試人員做的也遠遠多于盲目遵守規定的這些動作，而且觀察到的也遠遠超過某些功能的輸出。人類有復雜的生活、議程、天賦、想法和問題。雖然可以模擬某些用戶和測試人員的操作，但用戶和測試人員自己卻不能在軟件中被復制。未能理解這一點簡單的事實將會使測試變得瑣碎，并且會讓許多bug逃過我們的注意。
我們怎么能更清楚地思考這些呢？
第一：稱它們為工具（而不是“測試自動化”）
我們將工具定義為任何有助于實現人類目的的人類發明。一個測試工具可以是軟件、硬件、地圖、文件或工件，或者其他一些輔助實現測試目的的啟發式方法。在此，我們主要關注的是基于軟件的工具。
“測試工具”一詞讓我們與普通的日常理解聯系起來，即這些發明在沒有人類指導的情況下是無法工作的，他們擴展了適當技能的人類的能力。此外，“工具”打開了許多可以減輕負擔和增強測試人員能力的方法的大門。
與此同時，“測試自動化”這個術語可能會使人們脫離工作。要理解為什么，你必須考慮測試是什么。測試是去尋找產品的真實狀態，而在復雜的產品中，它是隱藏在隨意的視圖中。測試人員這樣做是為了發現問題。一個測試人員，在有限的資源下工作，必須在期限之前找出問題。這需要在快速和持續的學習過程中，仔細注意產品行為中的微妙線索。測試人員所從事的意識形成、批判性思考和實驗，這些都不能通過機械手段完成。然而，在我們的長期訪問中，訪問了數百家公司和團隊，我們發現那些將自動化測試當口頭禪一樣經常說的測試經理和技術專家，經常忽略這些知識過程。我們試著提醒他們——以及他們的同事——有時這些關鍵元素不能編碼到測試用例或測試軟件中。“哦我們同意，”他們可能會說，但是馬上又回到了講話中，就好像測試的本質在某種程度上表現在他們的“測試自動化”中一樣。經過多年的斗爭，我們得出結論，這個詞本身就是一種麻醉劑。
計算機軟件嚴格地由顯式編碼的模式組成。任何有價值或重要的行為模式都不會發生，除非它是用代碼來表達的。這是顯而易見的。不太顯而易見的是，告知人類測試人員行為的大部分都是隱性知識。（然而，顯性知識是指任何被表示為一串比特的知識，隱性知識是指沒有或不能被這樣代表的知識。）
當一個測試人員與產品交互時，他自發地對各種令人驚訝和錯誤的事件做出反應，卻不會意識到對它們的期望。例如，如果一個窗口變為紫色，或者一根額外的線出現了，或者一個過程在十次中有一次花了更長的時間來完成，他幾乎毫不費力地就會注意到并有所反應。但是當這個測試員講述這個測試的故事時，也許通過寫下它的步驟和預期的結果，只有一小部分真實的期待被表達出來了。沒有測試人員會編碼無意識的期望或意料之外的行為。因為既然測試是人類實際上無法用語言來表達的，那么它們也不能被編碼，不能被自動化。我們不應該使用一種術語暗示它可能可以。
每個人都知道編程不能自動化。盡管許多早期的編程語言被稱為“自動編碼”，早期的編譯器被稱為“自動編碼”，這種說法在1965年前后的3年時間達到高峰?！熬幾g器”一詞變得更加流行。換句話說，當軟件開始被編碼時，他們將該活動的名稱改為編譯、匯編或解釋。這樣一來，程序員就成了一個總是坐在所有技術之上的人，沒有一個經理會說“我們什么時候可以自動化所有這些編程？”
為了生產高質量的產品和服務，我們需要有技術的人使用合適的工具來完成測試的任務。使用術語“手動測試人員”或“自動化測試人員”來區分測試人員是一種誤導驅動級腳本能被檢測嗎，因為所有有能力的測試人員都使用工具。程序員和研究人員也使用工具，但是沒有人提到“自動編程”或“自動化研究”。沒有哪個經理會要求自動化測試來自動化代替他的管理。人們認為自動化測試很有趣的唯一原因是，他們真的相信測試不需要技巧或判斷。
由于所有的測試人員都使用工具，我們提議一個更有趣的區別是，一些測試人員也會編寫工具——編寫代碼并開發工具來幫助測試。我們建議將這些技術測試人員稱為“（工具匠？）”。盡管和他們的工具有助于擴展、加速，并加強測試中的某些活動，但它們不會自動進行測試。 因此，從這一點就可以說明，我們將盡量避免使用術語“測試自動化”。
第二：認為測試遠遠好過輸出檢查
我們說：測試是通過探索和實驗來了解產品的評估，這在一定程度上包括：質疑、研究、建模、觀察和推斷等。
我們用詞必須謹慎。測試必然是一個人類執行的過程，只有人類才能學習，只有人類才能決定價值。價值是一種社會判斷，不同的人對事物價值的看法是不同的。技術人員可能認為他們可以通過將需求編碼為腳本來自動評估需求，但是評估是直到它被人類審查前都是臨時和不完整的。幾乎總是有這樣的情況，經理說“該工具報告了一個錯誤，但在這種情況下確實不是問題。”
探索是我們對測試的定義的核心，因為我們在找到bug之前都不知道bug在哪里。的確，對于任何新產品，我們都必須找到可以尋找到問題的地方，而還有太多地方需要我們去檢查全部。我們甚至不知道什么算是bug，這是一個在項目過程中會改變和轉換的判斷過程。我們強調實驗，因為好的測試實際上是科學意義上的實驗。在任何人都不知道軟件會是什么，或者是什么的300年以前，“自然哲學家”會通過他們的實驗系統地測試自然?？茖W家的實驗的意義正是我們所說的測試。測試必然是一個漸進的、投機性的、自我導向的搜索過程。
最后，在文章最后的“等等”是一個信號，意味著——測試包含了許多其他與分析相關的活動和學科。那些不是測試自身的活動，比如研究規范，會在測試目的完成時進行測試。
讓我們進一步分解測試。當測試的時候，我們具體做什么？測試是一種包括幾種正在進行的并行活動的性能：
所有這些活動都可以通過工具得到幫助。
區分檢查和測試
我們發現有必要來區分檢查（check）和測試（test）。檢查是一個通過將算法決策規則應用于產品的具體觀察來進行評估的過程。這與測試的其余部分是不同的：它可以是完全自動化的。因此檢查是可以使用“自動化”這個詞的。
在測試中，設計和執行幫助我們理解產品的狀態的實驗。這種理解是一種解釋、一個評估，但不是事實。簡單的事實可以說是“可證實的”，但質量絕不是一個簡單的事實。質量是一個正在工作的假設。當你使用軟件并沒有發現某個具體問題時，你沒有證明或證實“它成功運行了”。你所知道的只是你還沒有遇到到失敗。你所證明的就是產品能運行。這項產品可能會以一種你沒有或無法察覺的微妙方式失敗。也許現在還行，但十分鐘后就不行了。那么，它真的，可以，深入地工作嗎？沒有輸出檢查可以告訴你如此。沒有輸出檢查的收集可以告訴你如此。
事實上，任何廣告商、深夜電視廣告員或者舞臺魔術師都可以向你展示某些東西似乎在起作用。作為測試人員，我們的工作不是服從廣告，直接接受這個結論，或者相信戲法。我們的工作是找出廣告遺漏了什么產品不符合要求的地方，或者魔術師是如何欺騙我們的。雖然例行的輸出檢查是我們工作的一部分，我們不斷地重新進行非常規的、新奇的觀察。我們的態度一定是尋找問題，而不是核實問題的缺失——否則我們只能以淺薄的方式進行測試并使我們對產品的本質視而不見。
評估質量是一項需要熟練，復雜驅動級腳本能被檢測嗎，非算法性調查和判斷的任務。這個任務可以通過工具來支持和加速，但是不能由工具本身來執行。
檢查是很重要的
良好的檢查是測試的一個子集。檢查和測試不一樣就好像咬人和吃東西，輪胎和汽車是不一樣，拼寫和編輯是不一樣的。良好的檢查始終是設計、實施和解釋這些人為活動檢查過程中的產物，這些構成了測試。測試給了檢查價值和意義。然而，檢查保持測試的基礎。
自動檢查是測試的一種策略，并且相當具有價值。對自己的代碼采用自動檢查的程序員可以提供快速、低成本的反饋。通過圖形用戶級別下的API進行檢查是非常有用的。在設計這種低級別的檢查中，程序員和測試人員可以在一起進行有益的工作。
我們更懷疑在GUI級別自動檢查。在圖形用戶層面上測試是出了名的挑剔，因為非技術人員可以看到并討論它們，GUI比只有程序員看到的底層接口更容易變化，這可能導致巨大的、高成本的只是為了保持簡單的檢查運行維護工作。此外，圖形用戶界面的設計是為了讓人們感到自然和舒適，而不是為了其他軟件。您可能需要一名熟練的全職程序員來維護所有嘗試模擬快速但不熟練的人體測試人員所需的代碼。這可能不是一個省錢的辦法。
第三：探索使用工具的多種方法！
單獨測試人員的技能集和思維方式是負責工具使用的核心。然而，當我們說到這一點時，一些人似乎以為聽到我們說工具不重要，或者上下文驅動的測試人員討厭工具。沒有什么比這更偏離真相了。