selenium2自動化測試實戰--基於Python語言
自動化測試基礎
一、 軟件測試分類
1.1 根據項目流程階段劃分軟件測試
1.1.1 單元測試
單元測試（或模塊測試）是對程序中的單個子程序或具有獨立功能的代碼段進行測試的過程。
1.1.2 集成測試
集成測試是在單元測試的基礎上，先通過單元模塊組裝成系統或子系統，再進行測試。重點是檢查模塊之間的接口是否正確。
1.1.3 系統測試
系統測試是針對整個產品系統進行的測試，驗證系統是否滿足需求規格的定義，以及軟件系統的正確性和性能等是否滿足其需求規格的要求。
1.1.4 驗收測試
驗收測試是部署軟件之前的最後一個測試階段。驗收測試的目的是確保軟件準備就緒，向軟件購買者展示該軟件系統能夠滿足用戶的需求。
1.2 白盒測試、黑盒測試、灰盒測試
白盒測試與黑盒測試，主要是根據軟件測試工作中對軟件代碼的可見程度進行的劃分。這也是軟件測試領域中最基本的概念之一。
1.2.1 黑盒測試
黑盒測試，指的是把被測的軟件看做一個黑盒子，我們不去關心盒子裏面的結構是什麽樣子的，只關心軟件的輸入數據和輸出結果。
它只檢查程序呈現給用戶的功能是否按照需求規格說明書的規定正常使用、程序是否能接受輸入數據並產生正確的輸出信息。黑盒測試著眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
1.2.2 白盒測試
白盒測試，指的是把盒子打開，去研究裏面的源代碼和程序執行結果。
它是按照程序內部的結構測試程序，通過測試來檢驗產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條邏輯路徑是否都能按預定要求正確工作。
1.2.3 灰盒測試
灰盒測試介於黑盒測試和白盒測試之間。
可以這樣理解，灰盒測試既關註輸出對於輸入的正確性，同時也關註內部表現。但這種關註不像白盒測試那樣詳細、完整，它只是通過一些表征性的現象、事件、標誌來判斷內部的運行狀態。有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多。如果每次都通過白盒測試來操作，效率會很低，因此需要采取灰盒測試的方法。
1.3 功能測試與性能測試
從軟件的不同測試面可以劃分為功能測試與性能測試
1.3.1 功能測試
功能測試主要檢查世紀功能是否符合用戶的需求，因此測試的大部分工作也是圍繞軟件的功能進行。設計軟件的目的就是滿足用戶對其功能的需求，如果偏離了這個目的，則任何測試工作都是沒有意義的。
功能測試又可以細分為很多種：邏輯功能測試，界面測試、易用性測試、安裝測試、兼容性測試等。
1.3.2 性能測試
性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行的測試。
軟件的性能包括很多方面，主要有時間性能和空間性能兩種。
- 時間性能：主要是指軟件的一個具體的響應時間。例如一個登陸所需要的時間，一個商品交易所需要的時間等。當然，拋開具體的測試環境，來分析一次事務的響應時間是沒有任何意義的，它需要在搭建好的一個具體且獨立的測試環境下進行。
- 空間性能：主要指軟件運行時所消耗的系統資源，例如硬件資源，CPU、內存、網絡寬帶消耗等。
1.4 手工測試與自動化測試
從對軟件測試工作的自動化程度可以劃分為手工測試與自動化測試。
1.4.1 手工測試
手工測試就是由測試人員一個一個地去執行測試用例，通過鍵盤鼠標等輸入一些參數，並查看返回結果是否符合預期結果。
手工測試並非專業術語，手工測試通常是指我們在系統測試階段所進行的功能測試，為了更明顯地與自動化測試進行區分，這裏使用了手工測試這種說法。
1.4.2 自動化測試
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計測試用例並通過評審之後，由測試人員根據測試用例中描述的規則流程一步步執行測試，把得到的世紀結果與期望結果進行比較。在此過程中，為了節省人力、時間和硬件資源，提高測試效率，便引入了自動化測試的概念。
自動化測試又可分為：功能自動化測試與性能自動化測試。
- 功能自動化測試：是把以人為驅動的測試行為轉化為機器執行的一種過程。通過測試工具（或框架）錄制/編寫測試腳本，對軟件的功能進行測試，並驗證測試結果是否正確，從而代替部分的手工測試工作，達到節約人力成本和時間成本的目的。
- 性能自動化測試：通過性能功能來模擬成千上萬的虛擬用戶向系統發送請求，從而驗證系統的處理能力。
1.5 冒煙測試、回歸測試、隨機測試、探索性測試和安全測試
這幾種測試出現在軟件測試的周期中，既不算具體明確的測試階段，也不是具體的測試方法。
1.5.1 冒煙測試
是指在對一個新版本進行大規模的系統測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測性。
引入到軟件測試中，就是指測試小組在正是測試一個新版本之前，先投入較少的人力和時間驗證一個軟件的主要功能，如果主要功能都沒有運行通過，則打回開發組重新開發。這樣做的好處是可以節省時間和人力投入到不可測的項目中。
1.5.2 回歸測試
回歸測試是指修改了舊代碼後，重新進行測試以確認修改後沒有引入新的錯誤或導致其他代碼產生錯誤。
回歸測試一般是在進行第二輪軟件測試時開始的，驗證第一輪軟件測試中發現的問題是否得到修復。當然，回歸也是一個循環的過程，如果回歸的問題通不過，則需要開發人員修改後再次進行回歸，直到所有問題回歸通過為止。
1.5.3 隨機測試
是指測試中的所有輸入數據都是隨機生成的，其目的是模擬用戶的真實操作，並發現一些邊緣性的錯誤。
隨機測試可以發現一些隱蔽的錯誤，但是也有很多缺點，例如測試不系統，無法統計代碼覆蓋率和需求覆蓋率、發現的問題難以重現等。一般是放在測試的最後執行。隨機測試更專業的升級版叫做探索性測試。
1.5.4 探索性測試
探索性測試可以說是一種測試思維技術，它沒有很多實際的測試方法、技術和工具，但卻是所有測試人員多應該掌握的一種測試思維方式。探索性測試強調測試人員的主觀能動性，拋棄繁雜的測試計劃和測試用例設計過程，強調在碰到問題時及時改變測試策略。
1.5.5 安全測試
安全測試在IT軟件產品的生命周期中，特別是產品開發基本完成至發布階段，對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的過程。
安全測試現在越來越受到企業的關註和重視，因為由於安全性問題造成的後果是不可估量的，尤其是互聯網產品，最容易遭受各種安全攻擊。
二、分層的自動化測試
我們應該有更多的低級別的單元測試，而不僅僅是通過用戶界面運行的高層的端到端的測試。
傳統的自動化測試我們可以理解為基於產品UI層的自動化測試，它是將黑盒功能測試轉化為由程序或工具執行的一種自動化測試。
但是在目前的大多數研發組織當中，都存在開發與測試團隊割裂（部門墻）、質量職責錯配（測試主要對質量負責）的問題，在這種狀態下，測試團隊的一個“正常”反應就是試圖在測試團隊能夠掌握的黑盒測試環節進行盡可能全面的覆蓋，甚至是盡可能全面的 UI 自動化測試。
這可能會導致兩個惡果：一是測試團隊規模的急劇膨脹；二是所謂的全面UI自動化測試運動。因為UI是非常易變得，所以UI自動化測試維護成本相對高昂。
分層自動化測試倡導的是從黑盒（UI）單層到黑白盒多層的自動化測試體系，從全面黑盒自動化測試到對系統的不同層次進行自動化測試。
2.1 單元自動化測試
單元自動化測試是指對軟件中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判斷其具體含義，如C語言中單元是指一個函數，Java中單元是指一個類，圖形化的軟件中單元是指一個窗口或一個菜單等。總的來說，單元就是人為規定的最小的被測功能模塊。規範的進行單元測試需要借助單元測試框架，如Java語言的Junit、TextNG，C#語言的NUnit，以及Python語言的unittest、pytest等，目前幾乎所有的主流語言都有其相應的單元測試框架。
Code Review中文翻譯為代碼評審或diamante審查，是指在軟件開發過程中，通過對源代碼進行系統性檢查的過程。通常的目的是查找系統缺陷、保證軟件總體質量以及提高開發者自身水平。與Code Review 相關的插件和工具有很多，例如Java語言中基於Eclipse的ReviewClipse和Jupiter、主要針對Python語言的Review Board等。
2.2 接口自動化測試
Web應用的接口自動化測試大體分為兩類：模塊接口測試和Web接口測試。
2.2.1 模塊接口測試
主要測試模塊之間的調用與返回。當然，我們也可以將其看做是單元測試的基礎。它主要強調對一個類方法或函數的調用，並對返回結果的驗證，所用到的測試工具與單元自動化測試相同。
2.2.2 Web接口測試
Web接口測試又可以分為兩類：服務器接口測試和外部接口測試。
- 服務器接口測試：指測試瀏覽器與服務器的接口。我們知道Web開發一般分前端和後端，前端開發人員用HTML/CSS/JavaScript等技術，後端開發人員用PHP/Java/C#/Python/Ruby等各種語言。用戶的操作是在前端頁面上，需要後端提供服務器接口，前端通過調用這些接口來獲取需要的數據，通過HTTP協議實現前後端的數據傳遞。
- 外部接口測試：指調用的接口由第三方系統提供。典型的例子就是第三方登錄，例如新上線的產品為了免於新用戶註冊賬號的麻煩會提供第三方登錄，納悶用戶在登錄的時候調用的就是第三方登錄的接口，用戶登錄信息的驗證由第三方完成，並返回給當前系統是否驗證通過。
當然，接口測試也有相應的類庫或工具，例如測試HTTP的有HttpUnit、Postman等
2.3 UI自動化測試
UI層是用戶使用該產品的入口，所有功能都通過這一層提供並展示給用戶，所以測試工作大多集中在這一層進行。為了減輕這一層的測試人力和時間成本，早期的自動化測試工具主要針對該層設計。目前主流的測試工具有UFT、Watie、Robot Framework、Selenium等。
除UI層所展示的功能外，前端代碼同樣需要進行測試。在前端開發中最主要的莫過於JavaScript腳本語言，而QUnit就是針對JavaScript的一個強大的單元測試框架。
下圖中的測試金字塔映射了不同測試階段所投入的自動化測試的比例，UI層被放到了塔尖，這也說明UI層應該投入較少的自動化測試。如果系統只關註UI層的自動化測試並不是一種明智的做法，因為其很難從本質上保證產品的質量。如果妄圖實現全面的UI層的自動化測試，那麽需要投入大量的人力和時間，然而， 最終獲得的收益可能遠低於所投入的成本，因為對於一個系統來講，越接近用戶其越容易變化，為了適應這種變化就必須要投入更多的成本。
既然UI層的自動化測試這麽勞民傷財，那麽我們是不是只做單元測試與接口測試就可以了呢？答案是否定的，因為不管什麽樣的產品，最終呈現給用戶的都是UI層的功能，所以產品才需要招聘大量的測試人員進行UI層的功能測試。也正是因為測試人員在UI層投入了大量的時間與精力，所以我們才有必要通過自動化的方式幫助測試人員解放部分重復的工作。所以，應該更多的提倡“半自動化”的開展測試工作，把可以自動化測試的工作交給工具或腳本完成，這樣測試人員就可以把更多的精力放在更重要的測試工作上，例如探索性測試等。
至於在金字塔中每一層測試的投入比例則要根據實際的產品特征來劃分。在《Google測試之道》一書中提到，Google對產品測試類型劃分為：小測試、中測試和大測試，采用70%（小），20%（中）、10%（大）的比例，大體對應測試金字塔中的Unit、Service和 UI 層。
在進行自動化測試中最擔心的是變化，因為變化會直接導致測試用例的運行失敗，所以需要對自動化腳本進行不斷調整。如何控制失敗、降低維護成本是對自動化測試工具及人員能力的挑戰。反過來講，一份永遠都運行通過的自動化測試用例已經失去了它存在的價值。
三、什麽樣的項目適合自動化測試
- 任務測試明確，不會頻繁變動。
- 每日構建後的測試驗證。
- 比較頻繁的回歸測試。
- 軟件系統界面穩定，變動少。
- 需要在多平臺上運行的相同測試案例、組合遍歷型的測試，大量的重復任務。
- 軟件維護周期長。
- 項目進度壓力不太大。
- 被測軟件系統開發較為規範，能夠保證系統的可測試性。
- 具備大量的自動化測試平臺。
- 測試人員具備較強的編程能力。
在我們普遍的自動化測試經驗中，一般滿足以下三個條件就可以對項目開展自動化測試。
1. 軟件需求變動不頻繁
自動化測試腳本變化的大小與頻率決定了自動化測試的維護成本。如果軟件需求變動過於頻繁，那麽測試人員就需要根據變動的需求來不斷地更新自動化測試用例，從而適應新的功能。而腳本的維護本身就是一個開發代碼的過程，需要擴展、修改、調試，有時還需要對架構做出調整。如果所花費的維護成本高於利用其節省的測試成本，那麽自動化測試就失去了它的價值與意義。
一種折中的做法是先對系統中相對穩定的模塊與功能進行自動化測試，而變動較大的部分用用工進行測試。
2. 項目周期較長
由於自動化測試需求的確定，自動化測試框架的設計、腳本的開發與調試均需要時間來完成，而這個過程本身就是一個軟件的開發過程，如果項目的周期較短，沒有足夠的時間去支持這樣一個過程的話，那麽就不需要進行自動化測試了。
3. 自動化測試腳本可重復使用
自動化測試腳本的重復使用要從三個方面來考量：一是所測試的項目之間是否存在很大的差異性（如C/S系統架構與B/S系統架構的差異）；二是所選擇的測試技術和工具是否適應這種差異；三是測試人員是否有能力設計開發出適應這種差異的自動化測試框架。
四、自動化測試及工具簡述
自動化測試的概念有廣義與俠義之分：廣義上來講，所有借助工具來輔助進行軟件測試的方法都可以稱為自動化測試；狹義上來講，主要指基於UI層的功能自動化測試。
目前市面上的自動化測試工具非常多，下面幾款是比較常見的自動化測試工具。
1.UTF
UTF有QTP和ST合並而來，有HP公司開發。它是一個企業級的自動測試工具，提供了強大易用的錄制回放功能，同時兼容對象識別模式與圖像識別模式兩種識別方式，支持B/S與C/S兩種架構的軟件測試，是目前主流的自動化測試工具。
2. Robot Framework
Robot Framework 是一款基於Python語言編寫的自動化測試框架，具備良好的可擴展性，支持關鍵字驅動，可以同時測試多種類型的客戶端或者接口，可以進行分布式測試。
3. Watir
Watir是一個基於Web模式的自動化功能測試工具。Watir是一個Ruby語言庫，使用Ruby語言進行腳本開發。
4. Selenium
Selenium也是一個用於Web應用程序測試的工具，支持多平臺、多瀏覽器、多語言去實現自動化測試。目前在Web自動化領域應用越來越廣泛。
當然，除上面所列的自動化測試工具外，根據不同的應用還有很多商業的或開源的以及公司自己開發的自動化測試工具。
五、Selenium工具介紹
5.1 什麽是Selenium？
Selenium主要用於Web應用程序的自動化測試，但並不局限於此，它還支持所有基於Web的管理任務自動化。
Selenium的特點如下：
- 開源、免費
- 多瀏覽器支持：Firefox、Chrome、IE、Opera、Edge
- 多平臺支持：Linux Windows MAC
- 多語言支持：Java Python Ruby C# JavaScript C++
- 對Web頁面有良好的支持
- 簡單（API簡單），靈活（用開發語言驅動）
- 支持分布式測試用例執行
5.2 Selenium IDE
Selenium IDE是嵌入到Firefox瀏覽器中的一個插件，實現簡單的瀏覽器操作的錄制與回放功能。官方定位：
快速地創建bug重現腳本，在測試人員測試過程中，發現bug之後可以通過IDE將重現的步驟錄制下來，以幫助開發人員更容易地重現BUG。
IDE錄制的腳本可以轉換成多種語言，從而幫助我們快速地開發腳本。關於這個功能在後面的章節中我們會著重介紹。
5.3 Selenium Grid
Selenium Grid是一種自動化的測試輔助工具，Gird通過利用現有的計算機基礎設施，能加快Web-App的功能測試。利用Grid可以很方便地實現在多臺機器上和異構環境中運行測試用例。
5.4 Selenium RC
Selenium RC是Selenium家族的核心部分。Selenium RC支持多種不同語言編寫的自動化測試腳本，通過Selenium RC的服務器作為代理服務器去訪問應用，從而達到測試的目的。
Selenium RC分為Client Libraries和Selenium Server。Client Libraries庫主要用於編寫測試腳本，用來控制Selenium Server的庫。Selenium Server負責控制瀏覽器行為。總的來說，Selenium Server主要包括三部分，Launcher/Http Proxy和Core。其中，Selenium Core是被Selenium Server 嵌入到瀏覽器頁面中的。其實Selenium Core就是一堆JavaScript函數的集合，即通過這些JavaScript函數，我們才可以實現用程序對瀏覽器進行操作。Launcher用於啟動瀏覽器，把Selenium Core加載到瀏覽器頁面當中，並把瀏覽器的代理設置為Selenium Server的Http Proxy。
5.5 Selenium 2.0
搞清了Selenium 1.0的家族關系，再來看看Selenium 2.0。Selenium 2.0就是把 WevDriver 加入到了這個家族中，簡單用公式表示為：
Selenium 2.0 = Selenium1.0 + WebDriver
需要強調的是，在Selenium 2.0中主推的是WebDriver，可以將其看做Selenium RC 的替代品。因為Selenium為了保持向下的兼容性，所以在Selenium 2.0中並沒有徹底地拋棄Selenium RC。如果是初次使用Selenium開發一個新的自動化測試項目，那麽可以直接使用WebDriver。
Selenium RC與WebDriver的區別？
Selenium RC是在瀏覽器中運行JavaScript應用，使用瀏覽器內置的JavaScript翻譯器來翻譯和執行selenese命令（selenese是Selenium命令集合）。
WebDriver是通過原生瀏覽器支持或者瀏覽器擴展來直接控制瀏覽器。WebDriver針對各個瀏覽器而開發，取代了嵌入到被測Web應用中的JavaScript，與瀏覽器緊密集成，因此支持創建更高級的測試，避免了JavaScript安全模型導致的限制。除了來自瀏覽器廠商的支持之外，WebDriver還利用操作系統級的調用，模擬用戶輸入。
Selenium 與 WebDriver 合並原因？
部分原因是WebDriver 解決了Selenium存在的缺點（例如能夠繞過JavaScript沙箱，我們有出色的API）。部分原因是 Selenium 解決了WebDriver存在的問題（例如支持廣泛的瀏覽器），部分原因是因為Selenium的主要貢獻者和WebDriver的主要貢獻者都覺得合並項目是為用戶提供最優秀框架的最佳途徑。
selenium2自動化測試實戰--基於Python語言