一、 軟件測試分類

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等

三、UI自動化測試

　　UI層是用戶使用該產品的入口，所有功能都通過這一層提供並展示給用戶，所以測試工作大多集中在這一層進行。為了減輕這一層的測試人力和時間成本，早期的自動化測試工具主要針對該層設計。目前主流的測試工具有UFT、Watie、Robot Framework、Selenium等。

　　除UI層所展示的功能外，前端代碼同樣需要進行測試。在前端開發中最主要的莫過於JavaScript腳本語言，而QUnit就是針對JavaScript的一個強大的單元測試框架。

自動化測試基礎