Selenium 與自動化測試 —— 《Selenium 2 自動化測試實戰》讀書筆記

背景

---

最近在弄 appium，而後順便發現了 Selenium 框架和這本書，剛好這本書也介紹了一些軟件測試&自動化測試的理論知識，遂拿過來學習學習。因此本文幾乎沒有實踐內容，大多都是概念和工具的 mark，後續如有實踐，我會來補充的。

1、軟件測試 分類

---

一、根據項目流程階段劃分

• 需求分析

• 設計

• 編碼

• 單元測試

• 集成測試

• 系統測試

• 驗收測試

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

白盒測試的意義：有時候輸出是正確的，但內部其實已經錯誤了，這種狀況很是多。

灰盒測試的意義：若是每次都經過白盒測試來操做，效率會很低，黑盒又太過籠統，所以折中的灰盒測試比較適合。

三、功能測試與性能測試

功能測試主要檢査實際功能是否符合用戶的需求。

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

性能測試主要有時間性能和空間性能兩種。

時間性能：主要是指軟件的一個具體的響應時間。

空間性能：主要指軟件運行時所消耗的系統資源。

四、手工測試與自動化測試

自動化測試不能徹底地替代手工測試，自動化測試的目的僅僅在於讓測試人員從煩瑣重複的測試過程當中解脫出來，把更多的時間和精力放到更有價值的測試中，例如探索性測試。而自動化測試更多的是用來進行冒煙測試和迴歸測試。

自動化測試是本文要探討的重點。

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

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

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

隨機測試

探索性測試

安全測試

六、正向測試與逆向測試

正向測試用例 (Positive Test Case) 和反向測試用例 (Negtive test Case) 是對測試用例的一種分類。

例如：一個輸入只能接受輸入數字0-9，那麼正向用例能夠爲:0,1,2,3,4,5,6,7,8,9，反向用例能夠爲：其它值。

反向測試用例一般指，系統不支持的輸入或則狀態，這類用例能夠檢查系統的容錯能力、健壯性和可靠性。

2、何爲自動化測試

---

自動化測試的概念有廣義與狹義之分：廣義上來說，全部藉助工具來輔助進行軟件測試的方式均可以稱爲自動化測試：狹義上來說，主要指基於 UI 層的功能自動化測試。

注意：若是沒有特別說明，則本文所說的「自動化測試」均指「基於 UI 的功能自動化測試」。

3、自動化測試 與 分層模型

---

一、測試金字塔

不一樣測試階段所投入的自動化測試的比例：Unit > Service > UI。

二、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

目的：

一、改善代碼質量

一些很基礎的，好比縮進空格什麼的，就交給 eslint 什麼的去解決吧。

二、保證團隊代碼規範

三、提升代碼性能

四、預防 bug

五、加深技術團隊成員溝通，營造技術氛圍

六、老帶新互助成長

實踐建議：

一、全部代碼都必須通過 Review 才能 merge。

二、批評的時候最好同時給解決方案

三、每次 review 至少給一條正面評價，提升對方信心

四、不要在 review 中討論需求

五、不要在 review 中討論太多的架構或者設計模式，這個應該是在前期設計時解決的事

普及狀況：

Code Review 作得好的廣泛是一些比較偏技術的團隊，而偏業務的技術團隊比較少。

咱們公司也不多作其實。

三、Service 層

接口測試：也有相應的類庫或工具，例如測試 HTTP 的有 Httpunit、Postman 等。

四、UI 層

UI 自動化測試：目前主流的測試工具備 UFT、Watir、Robot Framework、Selenium 等。

JS 自動化測試：Qunit 就是針對 Javascript 的一個強大的單元測試框架，由jQuery團隊的成員所開發，而且用在jQuery，jQuery UI，jQuery Mobile等項目。

其實這個也是單元測試，可是由於是前端，因此歸到了 UI 這邊。

4、什麼樣的項目適合自動化測試

---

（1）軟件需求變更不頻繁

或者一種折中的作法是先對系統中相對穩定的模塊與功能進行自動化測試，而變更較大的部分用手工進行測試。

（2）項目週期較長

（3）自動化測試腳本可重複使用

（4）等等

5、自動化測試模型

---

一、線性測試

最原始的方法，測試用例之間可能會存在重複的操做，會致使開發成本和維護成本都很高。

二、模塊化驅動測試

很好地解決了腳本的重複問題。

三、數據驅動測試

由於輸入數據的不一樣從而引發輸出結果的不一樣。實現了數據與腳本的分離。

四、關鍵字驅動測試

理解了數據驅動後，無非是把「數據」換成「關鍵字」，經過關鍵字的改變引發測試結果的改變。

好處：

目前市面上典型關鍵字驅動工具以 QTP（目前已改名爲 UFT- Unified Functional Testing）、Robot Framework (RIDE）工具爲主。這類工具封裝了底層的代碼，提供給用戶獨立的圖形界面，以「填表格」的形式免除測試人員對寫代碼的恐懼，從而下降腳本的編寫難度，咱們只需使用工具所提供的關鍵字以「過程式」的方式來編寫用例便可。

壞處：

關鍵字驅動也能夠像寫代碼同樣寫用例，在編程的世界中，沒有什麼不能作：不過這樣的用例一樣須要較高的學習成本，與學習一門編程語言幾乎至關。這樣的框架越到後期越難維護，可靠性也會變差，關鍵字的用途與經驗被侷限在本身的框架內，你所學到的知識也很難重用到其餘地方。因此，從測試人員的經驗與技術積累價值來說，筆者更傾向於直接經過編程的方式開發自動化腳本。

6、自動化測試工具 - selenium 2（UI層）

---

本章實操部分省略，後續如有實踐，會適當補充。

有人說咱們公司的軟件是用某語言開發的，因此自動化測試也要選某語言：其實軟件開發語言和軟件自動化測試語言沒有必然聯繫。也就是說，基於 Python (+ Selenium）編寫的自動化測試腳本既能夠測試基於 Java 開發的 Web 項目，也能夠測試基於 PHP 開發的 Web 項目。因此，在選擇 Selenium 自動化測試語言時不須要考慮與開發語言的一致性。

一、什麼是 selenium 2

selenium 2 是 web 瀏覽器自動化測試框架。

下文的 selenium 默認都指 selenium 2。

雖然 selenium 支持 Android 自動化測試，但更推薦 Appium, Appium 是 selenium 的延伸，基本上能夠視爲 「Selenium for Apps」，由於它也是基於 Selenium 的 Webdriver 技術開發的。

二、selenium 歷史

selenium (selenium 1) 和 webdriver 原來是兩個不一樣的開源項目，但在 selenium 2 的時候，將selenium 與 webdriver 合併了，即：

selenium 2 = webdriver + selenium 1

因此 selenium 2 能夠等價爲 webdriver ，對於 Selenium 2 的學習，實際上是對 WebDriver API 的學習。

三、selenium 的支持模式

selenium 支持 HtmlUnit 和 PhantomJS 兩個模式。

Phantom JS 是一個擁有 Javascript API 的無界面 Webkit 內核，與 Htmlunit 相似，但比它更高級一些。

經過 HtmlUnit 或 Phantom JS 進行的自動化測試運行不會真正打開一個瀏覽器，在咱們看來，可見的東西纔會以爲是真實的，須要的時候，能夠調用截圖的 api。

四、安裝 selenium

pip3 install selenium

五、經常使用功能

• 控制瀏覽器：如調整窗口大小

• 找元素（定位）

• 操做元素

• 鼠標事件

• 鍵盤事件

• 設置元素等待

• 多 frame、iframe 切換 / 多窗口切換

  調用switch_to.frame() 和 switch_to.window()

• 處理警告框
  如接受警告框：driver.switch_to_alert().accept()

• 上傳/下載文件
  更復雜的上傳/下載須要編寫 Autoit 腳本

• 操做 Cookie

• 調用 JS
  調用 execute_script()

六、Selenium IDE

經過瀏覽器插件的形式提供。

功能點備註：

一、斷言和驗證的區別：與斷言相比，當執行驗證命令失敗後不會終止測試。

二、pause 和 waitfor 的區別： pause 來設置固定時間的體眠，而 waitfor 則用於在必定時間內等待某一元素顯示。

三、支持將錄製內容導出爲代碼，支持類型以下：

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

七、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 實現分佈式並行地執行測試用例。

7、 自動化測試工具 - unittest（python單元測試框架）

---

在 Python 語言下有諸多單元測試框架，如 doctest、unittest、pytest、nose 等，unittest 框架（原名 Pyunit 框架）爲 Python 語言自帶的單元測試框架，Python2.1 及其之後的版本已將 unittest 做爲一個標準模塊放入 Python 開發包中。

一、概念

單元測試自己就是經過一段代碼去驗證另外一段代碼。

（1）Test Case

一個 Testcase 的實例就是一個測試用例。

• 一個用例爲一個完整的場景，從用戶登陸系統到最終退出並關閉瀏覽器。

• 一個用例只驗證一個功能點，不要試圖在用戶登陸系統後把全部的功能都驗證一遍。

• 用例與用例之間儘可能避免產生依賴。

• 一條用例完成測試以後須要對測試場景進行還原，以避免影響其餘用例的執行。

（2）Test Suite

一個功能的驗證每每須要多個測試用例，能夠把多個測試用例集合在一塊兒來執行，這就產生了測試套件Testsuite 的概念。

（3）Test Runner

包含執行策略和執行結果。

（4）Test Fixture

對一個測試用例環境的搭建和銷燬，就是一個 fixture。

二、使用

待寫

三、生成 HTML 測試報告

HTMLTestRunner 是 unittest 的一個擴展，它生成易於使用的 HTML 測試報告。

待寫

四、缺點

跟上面說的 Selenium Gird 同樣，unittest 單元測試框架自己並不支持多線程技術，它不能像 Java 的 TESTNG 框架同樣經過簡單的配置就可使用多線程技術執行測試用例。

8、自動化測試高級應用

---

一、自動發郵件功能

SMTP (Simple Mail Transfer Protocol）是簡單郵件傳輸協議。

Python 的 smtplib 模塊提供了一種很方便的途徑用來發送電子郵件。

可用於如測試時結果的告知。

二、Page Object 設計模式

Page 對象（Page Object）的一個基本經驗法則是：凡是人能作的事，page 對象經過軟件客戶端都可以作到。所以，它也應當提供一個易於編程的接口並隱藏窗口中底層的部件。因此訪問一個文本框應該經過一個訪問方法（accessor method）來實現字符串的獲取與返回，複選框應當使用布爾值，按鈕應當被表示爲行爲導向的方法名。page 對象應當將在 GUI 控件上全部查詢和操做數據的行爲封裝爲方法。一個好的經驗法則是，即便改變具體的控件，paee 對象的接口也不該當發生變化。

也能夠創建一個 base 的 Page 對象，讓別的 page 繼承它。

很像面向對象編程思想裏的接口與實現。

9、自動化測試項目實戰

---

待寫