?? 自 動化測試 是我從進入這個行業開始，聽到最多的詞匯之一了。大家，特別是手工測試工程師，很多都想了解自動化測試，學習工具，并以此提高自己的收入。 今天 我不講工具 。而是講講這個詞背后的原理，為讀者從事自動化測試工作打一個理論基礎。如果打算從事專職自動化測試工作，不論是你原來是開發人員，還是手工測試人員，都必須了解這個基礎。以我實際上的工作中遇到的新人來看，最缺的就是這個理論基礎，而工具大家都能學會。我下面用自頂向下的方式來解釋自動化測試的原理，從高度抽象講到具體內容。當然這些只是我的個人理解，整理這些也是為了明確我對職業發展路線的思考。

??

　首 先，自動化測試只有三個核心步驟：1.獲取預期結果；2.獲取實際結果；3.比較1和2的結果以判斷測試是否通過。下面我先舉一個最簡單的三步走例子：

　　 第一步，獲取預期結果的方法：直接知道。

　　 比如說，我測試一個網站的用戶登錄模塊，當我要測成功登錄的情況時，我的預期結果就是登錄成功。

　　 第二步，獲取實際結果的方法：編寫和執行測試，再獲取執行結果。

　　 知道預期結果之后，我就去編寫自動化測試腳本，操作瀏覽器，然后做登錄，最后根據頁面上顯示的文字或數據庫里的信息，得知用戶是否登錄成功。

　　 第三步，比較第一步和第二步的結果。

　　 第一步里，我預期登錄成功，第二步里我知道了登錄實際上成功了，那么第三步對比結果是相同，測試通過。假如第二步里實際上登錄失敗了，則第三步對比結果是不同，測試失敗。

?

接 下來，實際上，我們會發現，這三個步驟可以擴展和細分，也都有相應的困難和解決的方案。

　　 比如說，第一步， 獲取預期結果的方法 ，有可能我們不知道。

　　 舉個例子，我們知道Java語言有sdk，sdk里有提供基本數學運算。那么假如要測試java sdk里兩個整數Int做乘法的結果是否正確。怎么確定預期結果？手工測試時，我可以每做一個乘法調用，然后拿出紙和筆，使用數學方法列豎式來做乘法。但自動化測試里，我們做不到這一點。然后通常有以下解決方法：

　　1.只測少量已知樣本：也就是我預先算好一些輸入值和輸出值，做一個表格，或者說測試數據和預期結果表。但這樣做，我的測試覆蓋率是比較低的。

　　2.用另一種算法重新實現程序：用這個算法的計算結果作為第一個待測算法的結果的預期結果。但這樣的局限性是，成本太高（我的測試程序等于是另一個獨立程序），可靠性存疑（測試程序可能自己出錯）

　　3.從已知的可靠程序里獲得結果：比方說我把這個待測程序跟某個正規通用的商業計算器連接起來，用這個計算器的結果來做為我的待測程序預期結果。局限性自然是受限于這個商業計算器本身

　　4.編寫一些已知的規則來做不完全的校驗：比方說我兩個正整數相乘結果應該是一個正整數而是不會是負數。那么我把這個定義為一條規則，然后跑很多組測試，每組測試的結果里都去判斷是否符合這個規則。假如正數相乘乘出一個負數結果來，那就是BUG了。

　　其中最常用的是1和3，然后4也可以跟1、3一起用。在某些測試領域獲取預期結果是難題，特別是方法4是用來解決難題的，另一些領域則經常是直接知道預期結果。

　　再比如說，第二步，獲取實際結果的方法，這一步也就是我們在網上看到過無數的工具使用的講解，都是為了獲得實際結果。你看到的大多數資料都是講這一步驟。

　　舉個例子，你要用selenium操作瀏覽器做網頁測試。那么獲取實際結果這個步驟再次劃分為兩個小步驟：1.定位頁面元素；2.操作頁面元素；

　　1.定位頁面元素，就是selenium里的WebElement.findByxxxx,通過dom對象里的一些屬性或xpath等定位方法來定位元素，找到我要操作的頁面元素，比如某個按鈕或者某個文本框。

　　2.操作頁面元素，則是使用selenium的api提供的方法對按鈕作出點擊，對文本框輸入文字等。

　　在做第一步定位頁面元素的時候，有時你定位不到，這時就要想辦法去定位或者繞過這個難點。

　　在做第二步操作頁面元素的時候，我們根據實際情況，可能要先做數據準備再來操作，比方說我填表單要填哪些數據進去，要先確定，也就是做數據準備。

　　數據準備又可以細分下去有很多方法來準備。

　　1.最簡單的就是預先定義好有限的樣本，順便還可以把預期結果也定義好

　　2.也可能要從數據庫里實時去查詢我要用的數據

　　3.也可能我的數據要來自外部的其他系統或系統內部的其他模塊，比方說某個web服務接口，如果這個接口實際不存在而需要自動化測試人員寫一個代替品，那么這個代替品我們叫他 樁（Stub） 。

　　4.還有可能我的數據來自自動化測試人員寫的某一程序，比如我寫過一個插件用于生成符合數據類型定義的隨機數據。像用戶注冊規定用戶名是多少位的字符串，哪些符號不能出現，然后密碼要符合什么規則，出生年月要符合什么規則，我的插件就在規定的范圍內隨機生成合理的數據。

　　準備數據在很多項目中都是難點，有時獲取到的數據還需要進行轉換，此時又要寫程序，比如我們編寫一個插件把某web服務接口返回的二進制編碼轉換成另一個web服務接口需要的輸入數據的類型。

　　另外，除了selenium，還有很多其他層次的自動化測試，這一個步驟也會遇到其他很多難題，但至少這些原理定義是需要有個大概概念的。

　　題外話，請記得把自己寫的小程序/腳本都稱為"插件"（plugin），這樣聽上去專業而且高大上（笑）。

　　最后第三步，結果對比。

　　就是簡單對比第一步和第二步的結果。但是問題是要用何種方式組織第一步和第二步的結果，如何管理這些結果數據，并反映到測試報告中去。

　　以Java語言下的網頁自動化測試為例，和測試執行器結合起來做斷言是最常見的情況。

　　　　仍有很多種做法：

　　1.簡單對比， 比方說 assert（1+1 == 2），等于號左邊是實際結果，右邊是預期結果。

　　2.編寫靜態斷言類，如assert（xxxPage.userIsSignedIn（））這樣在XXXpage里自己寫一個 userIsSignedIn（）方法來判斷用戶有沒有登錄成功

　　3.封裝DSL做斷言，如mobilePhoneNumber.isNumbers().hasCorrectLength().notExistedInDataBase()這樣一個方法鏈來判斷某個文本框里輸入的電話號碼全由數字組成、長度正確、數據庫里無重復記錄。

　　等等

在 自動化測試這個話題的最后談一下我理解的自動化測試成功的前提： 產品適合自動化、技術基礎到位、成本估計充分

　　1.產品適合自動化：比如別人舉過的一個例子：某項目要做8年，主要內容是做某產品的40國語言本地化測試。這樣的項目很適合自動化

　　適合不適合自動化要綜合考慮，一般來說，要看

　　UI是否穩定、業務需求是否穩定、現存功能BUG多不多、待測程序是否具有可測性、項目周期夠不夠長、對質量要求高不高、可用資源夠不夠等等

　　2.技術基礎到位：有沒有招到自動化測試的專家，技術難題有沒有解決。自動化測試項目要當作一個開發項目來做，可想而知在沒有專家的情況下開發一個高難度的自動化測試項目想成功太難了。

　　3.成本估計是否充分：自動化測試項目通常要長期投入才可見效，小項目切勿輕舉妄動。

　　而且有一點就是，自動化測試和手工測試能發現的BUG是不同的。自動化測試做得好，不一定能減少手工測試的工作量，也不一定能夠在腳本執行時發現多少BUG。從技術負責人到上層管理需要對自動化測試有一個相對正確的認識，判斷好產品究竟是否做自動化，是否有錢搞自動化，是否招到了合適的人才來搞自動化。

　　實際上我面試過一些小單位，技術負責人說很重視自動化測試，希望搞100%的自動化測試，但他在技術面試時沒問我任何技術問題就爽快地給了offer，我不禁心里問，既然重視自動化測試技術，為什么不問技術問題。還有一些單位嘴上說以自動化測試為主，很少做手工測試，說測試經理很重視開發能力，但同樣在面試中沒有問我任何技術題。有時我們要鑒別一個單位是否真的適合做自動化測試，就從這些小細節上看出來。當然反過來，還有公司問一大堆用不到的技術的問題，最后進去了發現還是做手工測試為主，這也是很有可能的。

　　通常，自動化測試是否成功和具體的公司類型，如互聯網公司、傳統軟件公司、金融機構、通信公司這些關系不一定很大。但也不能說無關，通常我要考慮這些：

　　一個是軟件開發的節奏和項目周期的長短，比如互聯網公司的節奏比傳統軟件公司快得多。

　　一個是新技術的應用，比如很多銀行只使用商業工具，拒絕開源工具。

　　一個是對軟件質量的要求，比如造航天飛機的，對軟件質量要求會高于做游戲的。

　　一個是產品手工測試的難度，比如大量數據的測試，手工實在太累。

　　一個是資金的投入，比如巨頭級公司和小創業公司相比，前者的投入更大，后者往往沒有測試或剛招了一個初級測試。

　　一個是測試人員的平均技術水平，你千辛萬苦設計出技術很超前的工具、框架，普通小測試不會用，也是惘然。（最后成品超前一步就夠了，超前兩步就醉了）

　　所以我最后的擇業傾向是成熟的、質量占據重要地位的大公司，帶有一定技術壁壘和行業壁壘的偏技術的自動化測試崗位，一方面順著大公司大平臺能提供的方向發展，另一方面積累更通用的技術（如×nix、腳本語言等）保持不被業界淘汰。當然每年還都要閱讀足夠數量的技術文獻資料、保持對新技術的接觸、了解各種測試行業會議的業界新動態。重點則是通用的開發相關技術，彌補一開始缺少的開發經驗積累。

我對軟件測試行業的個人理解 6 - 淺談自動化測試原理