背景
最近在弄 appium，然后順便發現了 Selenium 框架和這本書，恰好這本書也介紹了一些軟件測試&自動化測試的理論知識，遂拿過來學習學習。所以本文幾乎沒有實踐內容，大多都是概念和工具的 mark，后續若有實踐，我會來補充的。
一、軟件測試 分類
1、根據項目流程階段划分
-
需求分析
-
設計
-
編碼
-
單元測試
-
集成測試
-
系統測試
-
驗收測試
2、白盒測試、黑盒測試、灰盒測試
白盒測試的意義：有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多。
灰盒測試的意義：如果每次都通過白盒測試來操作，效率會很低，黑盒又太過籠統，因此折中的灰盒測試比較適合。
3、功能測試與性能測試
功能測試主要檢査實際功能是否符合用戶的需求。
功能測試又可以細分為很多種：邏輯功能測試、界面測試、易用性測試、安裝測試、兼容性測試等。
性能測試主要有時間性能和空間性能兩種。
時間性能：主要是指軟件的一個具體的響應時間。
空間性能：主要指軟件運行時所消耗的系統資源。
4、手工測試與自動化測試
自動化測試不能完全地替代手工測試，自動化測試的目的僅僅在於讓測試人員從煩瑣重復的測試過程中解脫出來，把更多的時間和精力放到更有價值的測試中，例如探索性測試。而自動化測試更多的是用來進行冒煙測試和回歸測試。
自動化測試是本文要探討的重點。
5、冒煙測試、回歸測試、隨機測試、探索性測試和安全測試
冒煙測試：引入到軟件測試中，就是指測試小組在正式測試一個新版本之前，先投入較少的人力和時間驗證一個軟件的主要功能，如果主要功能都沒有運行通過，則打回開發組重新開發。這樣做的好處是可以節省時間和人力投入到不可測的項目中。
回歸測試：回歸測試是指修改了舊代碼后，重新進行測試以確認修改后沒有引入新的錯誤或導致其他代碼產生錯誤。
隨機測試
探索性測試
安全測試
6、正向測試與逆向測試
正向測試用例 (Positive Test Case) 和反向測試用例 (Negtive test Case) 是對測試用例的一種分類。
例如：一個輸入只能接受輸入數字0-9，那么正向用例可以為:0,1,2,3,4,5,6,7,8,9，反向用例可以為：其它值。
反向測試用例通常指，系統不支持的輸入或則狀態，這類用例可以檢查系統的容錯能力、健壯性和可靠性。
二、何為自動化測試
自動化測試的概念有廣義與狹義之分：廣義上來講，所有借助工具來輔助進行軟件測試的方式都可以稱為自動化測試：狹義上來講，主要指基於 UI 層的功能自動化測試。
注意：如果沒有特別說明，則本文所說的“自動化測試”均指“基於 UI 的功能自動化測試”。
三、自動化測試 與 分層模型
1、測試金字塔
不同測試階段所投入的自動化測試的比例：Unit > Service > UI。
2、Unit 層
單元測試：單元就是人為規定的最小的被測功能模塊。規范的進行單元測試需要借助單元測試框架，如 Java 語言的 Junit、TESTNG, C# 語言的 Nunit，以及 Python 語言的 unittest、pytest 等，目前幾乎所有的主流語言都有其相應的單元測試框架。
Code Review：與 Code Review 相關的插件和工具有很多，例如 Java 語言中基於 Eclipse 的 Review Clipse 和 Jupiter、主要針對 Python 語言的 Review Board 等。
現在因為 github/gitlab 的流行， 以前的工具用的很少了。不排除大廠用一些更專業的工具。
拓展：Code Review
目的：
1、改善代碼質量
一些很基礎的，比如縮進空格什么的，就交給 eslint 什么的去解決吧。
2、保證團隊代碼規范
3、提高代碼性能
4、預防 bug
5、加深技術團隊成員溝通，營造技術氛圍
6、老帶新互助成長
實踐建議：
1、所有代碼都必須經過 Review 才能 merge。
2、批評的時候最好同時給解決方案
3、每次 review 至少給一條正面評價，提高對方信心
4、不要在 review 中討論需求
5、不要在 review 中討論太多的架構或者設計模式，這個應該是在前期設計時解決的事
普及情況：
Code Review 做得好的普遍是一些比較偏技術的團隊，而偏業務的技術團隊比較少。
我們公司也很少做其實。
3、Service 層
接口測試：也有相應的類庫或工具，例如測試 HTTP 的有 Httpunit、Postman 等。
4、UI 層
UI 自動化測試：目前主流的測試工具有 UFT、Watir、Robot Framework、Selenium 等。
JS 自動化測試：Qunit 就是針對 Javascript 的一個強大的單元測試框架，由jQuery團隊的成員所開發，並且用在jQuery，jQuery UI，jQuery Mobile等項目。
其實這個也是單元測試，但是因為是前端，所以歸到了 UI 這邊。
四、什么樣的項目適合自動化測試
（1）軟件需求變動不頻繁
或者一種折中的做法是先對系統中相對穩定的模塊與功能進行自動化測試，而變動較大的部分用手工進行測試。
（2）項目周期較長
（3）自動化測試腳本可重復使用
（4）等等
五、自動化測試模型
1、線性測試
最原始的方法，測試用例之間可能會存在重復的操作，會導致開發成本和維護成本都很高。
2、模塊化驅動測試
很好地解決了腳本的重復問題。
3、數據驅動測試
因為輸入數據的不同從而引起輸出結果的不同。實現了數據與腳本的分離。
4、關鍵字驅動測試
理解了數據驅動后，無非是把“數據”換成“關鍵字”，通過關鍵字的改變引起測試結果的改變。
好處：
目前市面上典型關鍵字驅動工具以 QTP（目前已更名為 UFT- Unified Functional Testing）、Robot Framework (RIDE）工具為主。這類工具封裝了底層的代碼，提供給用戶獨立的圖形界面，以“填表格”的形式免除測試人員對寫代碼的恐懼，從而降低腳本的編寫難度，我們只需使用工具所提供的關鍵字以“過程式”的方式來編寫用例即可。
壞處：
關鍵字驅動也可以像寫代碼一樣寫用例，在編程的世界中，沒有什么不能做：不過這樣的用例同樣需要較高的學習成本，與學習一門編程語言幾乎相當。這樣的框架越到后期越難維護，可靠性也會變差，關鍵字的用途與經驗被局限在自己的框架內，你所學到的知識也很難重用到其他地方。所以，從測試人員的經驗與技術積累價值來講，筆者更傾向於直接通過編程的方式開發自動化腳本。
六、自動化測試工具 - selenium 2（UI層）
本章實操部分省略，后續若有實踐，會適當補充。
有人說我們公司的軟件是用某語言開發的，所以自動化測試也要選某語言：其實軟件開發語言和軟件自動化測試語言沒有必然聯系。也就是說，基於 Python (+ Selenium）編寫的自動化測試腳本既可以測試基於 Java 開發的 Web 項目，也可以測試基於 PHP 開發的 Web 項目。所以，在選擇 Selenium 自動化測試語言時不需要考慮與開發語言的一致性。
1、什么是 selenium 2
selenium 2 是 web 瀏覽器自動化測試框架。
下文的 selenium 默認都指 selenium 2。
雖然 selenium 支持 Android 自動化測試，但更推薦 Appium, Appium 是 selenium 的延伸，基本上可以視為 “Selenium for Apps”，因為它也是基於 Selenium 的 Webdriver 技術開發的。
2、selenium 歷史
selenium (selenium 1) 和 webdriver 原來是兩個不同的開源項目，但在 selenium 2 的時候，將selenium 與 webdriver 合並了，即：
selenium 2 = webdriver + selenium 1
所以 selenium 2 可以等價為 webdriver ，對於 Selenium 2 的學習，其實是對 WebDriver API 的學習。
3、selenium 的支持模式
selenium 支持 HtmlUnit 和 PhantomJS 兩個模式。
Phantom JS 是一個擁有 Javascript API 的無界面 Webkit 內核，與 Htmlunit 類似，但比它更高級一些。
通過 HtmlUnit 或 Phantom JS 進行的自動化測試運行不會真正打開一個瀏覽器，在我們看來，可見的東西才會覺得是真實的，需要的時候，可以調用截圖的 api。
4、安裝 selenium
pip3 install selenium
5、常用功能
-
控制瀏覽器：如調整窗口大小
-
找元素（定位）
-
操作元素
-
鼠標事件
-
鍵盤事件
-
設置元素等待
-
多 frame、iframe 切換 / 多窗口切換
調用
switch_to.frame()和switch_to.window() -
處理警告框
如接受警告框：driver.switch_to_alert().accept() -
上傳/下載文件
更復雜的上傳/下載需要編寫 Autoit 腳本 -
操作 Cookie
-
調用 JS
調用execute_script()
6、Selenium IDE
通過瀏覽器插件的形式提供。
功能點備注：
1、斷言和驗證的區別：與斷言相比，當執行驗證命令失敗后不會終止測試。
2、pause 和 waitfor 的區別： pause 來設置固定時間的體眠，而 waitfor 則用於在一定時間內等待某一元素顯示。
3、支持將錄制內容導出為代碼，支持類型如下：
Ruby/Rspec/Webdriver
Ruby/Rspec/Remote Control
Ruby/Test: Unit/ Webdriver
Ruby/Test: Unit/Remote Control
Python/unittest/Webdriver
Python/unittest/Remote Control
Java/Junit4/Webdriver
Java/Junit4/Webdriver Backed
Java/Junit4/Remote Control
Java/Junit3/Remote Control
Java/TESTNG/Remote Control
C#/Nunit/Webdriver
C#/Nunit/Remote Control
7、Selenium Grid 2
（1）介紹
利用 Selenium Grid 2 可以在不同的主機上建立主節點（hub）和分支節點（node），可以使主節點上的測試用例在不同的分支節點上運行。對不同的節點來說，可以搭建不同的測試環境（操作系統、瀏覽器），從而使一份測試用例得到不同環境下的執行結果。
（2）安裝
Selenium Grid 2 的時候，不再提供單獨的包，其功能已經集成到 Selenium Server 中，所以，需要下載和運行 Selenium Server オ可以使用 Grid 2 的功能。
下文中 Selenium Grid 2 都簡稱為 Selenium Grid。
（3）缺點與改進
Selenium Grid 只是提供多系統、多瀏覽器的執行環境，Selenium Grid 本身並不提供並行的執行測試用例。所以建議使用多線程技術結合 Selenium Grid 實現分布式並行地執行測試用例。
七、 自動化測試工具 - unittest（python單元測試框架）
在 Python 語言下有諸多單元測試框架，如 doctest、unittest、pytest、nose 等，unittest 框架（原名 Pyunit 框架）為 Python 語言自帶的單元測試框架，Python2.1 及其以后的版本已將 unittest 作為一個標准模塊放入 Python 開發包中。
1、概念
單元測試本身就是通過一段代碼去驗證另一段代碼。
（1）Test Case
一個 Testcase 的實例就是一個測試用例。
-
一個用例為一個完整的場景，從用戶登錄系統到最終退出並關閉瀏覽器。
-
一個用例只驗證一個功能點，不要試圖在用戶登錄系統后把所有的功能都驗證一遍。
-
用例與用例之間盡量避免產生依賴。
-
一條用例完成測試之后需要對測試場景進行還原，以免影響其他用例的執行。
（2）Test Suite
一個功能的驗證往往需要多個測試用例，可以把多個測試用例集合在一起來執行，這就產生了測試套件 Testsuite 的概念。
（3）Test Runner
包含執行策略和執行結果。
（4）Test Fixture
對一個測試用例環境的搭建和銷毀，就是一個 fixture。
2、使用
待寫
3、生成 HTML 測試報告
HTMLTestRunner 是 unittest 的一個擴展，它生成易於使用的 HTML 測試報告。
待寫
4、缺點
跟上面說的 Selenium Gird 一樣，unittest 單元測試框架本身並不支持多線程技術，它不能像 Java 的 TESTNG 框架一樣通過簡單的配置就可以使用多線程技術執行測試用例。
八、自動化測試高級應用
1、自動發郵件功能
SMTP (Simple Mail Transfer Protocol）是簡單郵件傳輸協議。
Python 的 smtplib 模塊提供了一種很方便的途徑用來發送電子郵件。
可用於如測試時結果的告知。
2、Page Object 設計模式
Page 對象（Page Object）的一個基本經驗法則是：凡是人能做的事，page 對象通過軟件客戶端都能夠做到。因此，它也應當提供一個易於編程的接口並隱藏窗口中底層的部件。所以訪問一個文本框應該通過一個訪問方法（accessor method）來實現字符串的獲取與返回，復選框應當使用布爾值，按鈕應當被表示為行為導向的方法名。page 對象應當將在 GUI 控件上所有查詢和操作數據的行為封裝為方法。一個好的經驗法則是，即使改變具體的控件，paee 對象的接口也不應當發生變化。
也可以建立一個 base 的 Page 對象，讓別的 page 繼承它。
很像面向對象編程思想里的接口與實現。
九、自動化測試項目實戰
待寫