【1】第1章 自動化測試基礎 （測試分類+分層的自動化測試）

1.測試自動化意味着使用一個軟件工具, 對被測試的應用程序運行可重複的測試. 爲迴歸測試提供響應能力。

2.優勢：

    頻繁地迴歸測試

    提供開發者快速地回饋

    幾乎沒有限制測試案例的迭代執行

    支持敏捷和極限開發方法

    測試案例的文檔化

    自定義缺陷報告

    查找手工測試遺漏的缺陷

3.自動化測試並不老是有益的；若是一個應用程序有很是緊的時間期限，沒有現成的、可獲得的測試自動化，並且測試必須在 給定的時間範圍內完成，顯然手工測試是最佳的解決方案。

4.Selenium IDE（集成開發環境）是一個用於構造測試腳本的原型工具，是個FireFox插件；有錄製功能；

 

1.1 軟件測試分類

根據項目流程階段劃分軟件測試

1） 單元測試：單元測試（或模塊測試）是對程序中的單個子程序或具備獨立功能的代碼段進行測試的過程。

2） 集成測試：集成測試是在單元測試的基礎上，先經過單元模塊組裝成系統或子系統，再進行測試。重點是檢查模塊之間的接口是否正確。

3） 系統測試：系統測試是針對整個產品系統進行的測試，驗證系統是否知足需求規格的定義，以及軟件系統的正確性和性能等是否知足其需求規格的要求。

4） 驗收測試：驗收測試是部署軟件以前的最後一個測試階段。驗收測試的目的是確保軟件準備就緒，向軟件購買者展現該軟件系統可以知足用戶的需求。

 

白盒測試、黑盒測試、灰盒測試

根據軟件測試工做中對軟件代碼的可見程度進行的劃分。

1）黑盒測試。

只關心軟件的輸入數據和輸出結果，檢查程序呈現給用戶的功能是否按照需求規格說明書的規定正常使用。

眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。

2）白盒測試。

研究裏面的源代碼和程序執行結果。

按照程序內部的結構測試程序，檢驗程序中的每條邏輯路徑是否都能按預約要求正確工做。

3）灰盒測試。

灰盒測試既關注輸出對於輸入的正確性，同時也關注內部表現。

不像白盒測試那樣詳細、完整，它只是經過一些表徵性的現象、事件、標誌來判斷內部的運行狀態。

 

功能測試與性能測試

1）功能測試。

功能測試主要檢查實際功能是否符合用戶的需求，所以測試的大部分工做也是圍繞軟件的功能進行。

功能測試又能夠細分爲不少種： 邏輯功能測試、界面測試、易用性測試、安裝測試、兼容性測試等。

2）性能測試。

性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。

時間性能：主要是指軟件的一個具體的響應時間。例如一個登陸所須要的時間，一個商品交易所須要的時

間等。固然，拋開具體的測試環境，來分析一次事務的響應時間是沒有任何意義的。須要搭建一個具體且獨立

的測試環境下進行。

空間性能：主要指軟件運行時所消耗的系統資源，例如硬件資源，CPU、內存，網絡帶寬消耗等。

 

 

手工測試與自動化測試

1）手工測試。

手工測試就是由測試人員一個一個地去執行測試用例，經過鍵盤鼠標等輸入一些參數，並查看返回結果是否符合預期結果。

一般是指咱們在系統測試階段所進行的功能測試。

2）自動化測試。

自動化測試是把以人爲驅動的測試行爲轉化爲機器執行的一種過程。一般，在設計測試用例並經過評審以後，由測試人員根據測試用例中描述的規則流程一步步執行測試，把獲得實際結果與指望結果的比較。在此過程當中，爲了節省人力、時間和硬件資源，提升測試效率，便引入了自動化測試的概念。

 

自動化測試又可分爲：功能自動化測試與性能自動化測試。

功能自動化測試：它是把以人爲驅動的測試行爲轉化爲機器執行的一種過程。

經過測試工具（或框架）錄製/編寫測試腳本，對軟件的功能進行測試，並驗證測試結果是否正確，從而代替部分的手工測試工做，達到節約人力成本和時間成本的目的。

性能自動化測試：經過性能工具來模擬成千上萬的虛擬用戶向系統發送請求，從而來驗證系統的處理能力。

 

冒煙測試、迴歸測試、隨機測試、探索性測試和安全測試

1）冒煙測試。

是指在對一個新版本進行大規模的系統測試以前，先驗證一下軟件的基本功能是否實現，是否具有可測性。

指測試小組在正式測試一個新版本以前，先投入較少的人力和時間驗證一個軟件的主要功能，若是主要功能都沒有運行經過，則打回開發組從新開發。這樣作的好處是能夠節省時間和人力投入到不可測的項目中。

 

2）迴歸測試。

迴歸測試是指修改了舊代碼後，從新進行測試以確認修改後沒有引入新的錯誤或致使其餘代碼產生錯誤。

通常是在進行軟件的第二輪測試時開始的，驗證第一輪中發現的問題是否獲得修復。固然，迴歸也是一個循環的過程，問題通不過，則須要開發人員修改後再次進行迴歸，直到全部問題迴歸經過爲止。

 

3）隨機測試。

是指測試中的全部輸入數據都是隨機生成的，其目的是模擬用戶的真實操做，並發現一些邊緣性的錯誤。

優勢：能夠發現一些隱蔽的錯誤，

缺點：例如測試不繫統、沒法統計代碼覆蓋率和需求覆蓋率、發現的問題難以重現等。

通常是放在測試的最後執行。其實， 隨機測試更專業的升級版叫探索性測試。

 

4）探索性測試。

能夠說是一種測試思惟技術，它沒有不少實際的測試方法、技術和工具，可是倒是全部測試人員都應該掌握的一種測試思惟方式。

強調測試人員的主觀能動性，拋棄繁雜的測試計劃和測試用例設計過程，強調在碰到問題時及時改變測試策略。

 

5）安全測試。

安全測試是在IT 軟件產品的生命週期中，特別是產品開發基本完成到發佈階段，對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的過程。

安全測試如今愈來愈受到企業的關注和重視，安全性問題形成的後果是不可估量的，尤爲是互聯網產品，最容易遭受各類安全攻擊。

 

1.2 分層的自動化測試

基本觀點是：咱們應該有更多的低級別的單元測試，而不只僅是經過用戶界面運行的高層的端到端的測試。

傳統的自動化測試咱們能夠理解爲基於產品UI 層的自動化測試，它是將黑盒功能測試轉化爲由程序或工具執行的一種自動化測試。

分層自動化測試倡導的是從黑盒（UI）單層到黑白盒多層的自動化測試體系，從全面黑盒自動化測試到對系統的不一樣層次進行自動化測試：

 

單元自動化測試

單元就是人爲規定的最小的被測功能模塊。

一個函數、一個類、一個菜單、一個窗口；

範的進行單元測試就須要藉助單元測試框架，如java 語言的Junit、TestNG，C#語言的NUnit，以及Python 語言的unittest、pytest，目前幾乎全部的主流語言都會有其相應的單元測試框架。

Code Review：代碼審查、代碼評審，軟件開發過程當中，經過對源代碼進行系統性檢查的過程；

Java 語言中基於Eclipse 的Review Clipse 和Jupiter、主要針對Python 語言的Review Board。

 

接口自動化測試

可分類：模塊接口測試和Web 接口測試

（1）模塊接口測試，主要測試模塊之間的調用與返回。強調對一個類方法或函數的調用，並對返回結果的驗證，所用到的測試工具與單元測試相同。

（2）Web 接口測試又可分爲兩類：服務器接口測試和外部接口測試。

服務器接口測試：指測試瀏覽器與服務器的接口。Web 開發通常分前端和後端，把前端經過調用這些接口來得到須要的數據。

外部接口測試：指調用的接口由第三方系統提供。典型的例子就是第三方登陸，接口測試也有相應的類庫或工具，例如測試HTTP 的有HttpUnit、Postman 等。

 

UI自動化測試

主流的測試工具備UFT、Watir、Robot Framework、Selenium 等。QUnit 就是針對JavaScript 的一個強大的單元測試框架。