《軟件測試52講》——GUI自動化測試篇

《軟件測試52講》

一、測試基礎知識篇——（0~11講）

二、GUI自動化測試篇——（12~21講）

 持續更新中~

GUI自動化測試篇

12——從0到1：你的第一個GUI自動化測試

Selenium的實現原理

　　Selenium2.0的工做原理，又稱Selenium WebDriver，它利用的原理是：使用瀏覽器原生的WebDriver實現頁面操做。下圖爲Selenium WebDriver的執行流程。

　　一、當使用Selenium2.0啓動瀏覽器Web Broser時，後臺會同時啓動基於WebDriver Wire協議的Web Service做爲Selenium的Remote Server，並將其與瀏覽器綁定。

綁定完成後，Remote Server就開始監聽Client端的操做請求。

　　二、執行測試時，測試用例會做爲Client端，將須要執行的頁面操做請求以Http Request的方式發送給Remote Server。該HTTP Request的body，是以WebDriver Wire

協議規定的JSON格式來描述須要瀏覽器執行的具體操做。

　　三、Remote Server接收到請求後，會對請求進行解析，並將解析結果發給WebDriver，由WebDriver實際執行瀏覽器的操做。

　　四、WebDriver能夠看作是直接操做瀏覽器的原生組件（Native Component），因此搭建測試環境時，一般都須要先下載瀏覽器對應的WebDriver。

13——效率爲王：腳本與數據的解耦

測試腳本和數據的解耦

　　數據驅動（Data-driven）測試

　　」測試腳本和數據解耦」的本質是實現了數據驅動的測試，讓操做相同可是數據不一樣的測試能夠經過同一套自動化測試腳原本實現，只是在每次測試執行時提供不一樣的測試輸入數據。 

頁面對象（Page Object）模型

　　頁面對象模型的核心理念是，以頁面（Web Page 或者 Native App Page）爲單位來封裝頁面上的控件以及控件的部分操做。而測試用例，更確切地說是操做函數，基於頁面封裝對象來完成

具體的界面操做，最典型的模式是「XXXPage.YYYComponent.ZZZOperation」。 

14——更接近業務的抽象：讓自動化測試腳本更好

　　業務流程抽象是，基於操做函數的更接近於實際業務的更高層次的抽象方式。基於業務流程抽象實現的測試用例每每具備較好的靈活性，能夠根據實際測試需求方便地組裝出各類測試用例。

　　業務流程的核心思想是，從業務的維度來指導測試業務流程的封裝。因爲業務流程封裝一般很貼近實際業務，因此特別適用於組裝面向終端用戶的端到端（E2E）的系統功能測試用例，

尤爲適用於業務功能很是多，而且存在各類組合的 E2E 測試場景。

爲了加深印象，我再來總結一下業務流程的優勢：

　　1. 業務流程（Business Flow）的封裝更接近實際業務；

　　2. 基於業務流程的測試用例很是標準化，遵循「參數準備」、「實例化 Flow」和「執行Flow」這三個大步驟，很是適用於測試代碼的自動生成；

　　3. 因爲更接近實際業務，因此能夠很方便地和 BDD 結合。BDD 就是 Behavior Driven Development，即行爲驅動開發，我會在後續文章中詳細講解  

15——聊聊GUI自動化過程當中的測試數據

從建立的技術手段上來說，建立測試數據的方法主要分爲三種：

　　（1）API 調用；

　　（2）數據庫操做；

　　（3）綜合運用 API 調用和數據庫操做。

從建立的時機來說，建立測試數據的方法主要分爲兩種：

　　（1）測試用例執行過程當中，實時建立測試數據，咱們一般稱這種方式爲 On-the-fly。

　　（2）測試用例執行前，事先建立好「開箱即用」的測試數據，咱們一般稱這種方式爲 Out-ofbox。

在實際項目中，對於建立數據的技術手段而言，最佳的選擇是利用 API 來建立數據，只有當API 不能知足數據建立的需求時，纔會使用數據庫操做的手段。

實際上，每每不少測試數據的建立是基於 API 和數據庫操做二者的結合來完成，即先經過 API建立基本的數據，而後調用數據庫操做來修改數據，以達到對測試數據的特定要求。

而對於建立數據的時機，在實際項目中，每每是 On-the-fly 和 Out-of-box 結合在一塊兒使用。

對於相對穩定的測試數據，好比商品類型、圖書類型等，每每採用 Out-of-box 的方式以提升效率；而對於那些只能一次性使用的測試數據，好比商品、訂單、優惠券等，每每採用 On-thefly 的方式以保證不存在髒數據問題。  

針對應該選擇什麼時機建立測試數據，結合多年的實踐經驗，我爲你總結了如下三點：

　　（1）對於相對穩定、不多有修改的數據，建議採用 Out-of-box 的方式，好比商品類目、廠商品牌、部分標準的賣家和買家帳號等。

　　（2） 對於一次性使用、常常須要修改、狀態常常變化的數據，建議使用 On-the-fly 的方式。

　　（3）用 On-the-fly 方式建立測試數據時，上游數據的建立能夠採用 Out-of-box 方式，以提升測試數據建立的效率。以訂單數據爲例，訂單的建立能夠採用 On-the-fly 方式，

　　　　而與訂單相關聯的賣家、買家和商品信息可使用 Out-of-box 方式建立。  

16——GUI測試還有這麼玩

頁面對象自動生成

　　頁面對象自動生成技術，屬於典型的「自動化你的自動化」的應用場景。它的基本思路是，你不用再手工維護 Page Class 了，只須要提供 Web 的 URL，它就會自動幫你生成這個頁面上全部

控件的定位信息，並自動生成 Page Class。 

　　可是，須要注意的是，那些依賴於數據的動態頁面對象也會被包含在自動生成的 Page Class裏，而這種動態頁面對象一般不該該包含在 Page Class 裏，因此，每每須要以手工的方式刪除

　　Katalon Studio自動化測試工具

　　https://cloud.tencent.com/developer/article/1457742

GUI測試數據自動生成

　　（1）根據GUI輸入數據類型，以及對應的自定義規則庫自動生成測試輸入數據。

　　（2）對於須要組合多個測試輸入數據的場景，測試數據自動生成能夠自動完成多個測試數據的笛卡爾積組合，而後再以人工的方式剔除掉非法的數據組合。

無頭瀏覽器

　　Handless Browser，是一種沒有界面的瀏覽器

　　無頭瀏覽器主要應用場景，包括GUI自動化測試、頁面監控以及網絡爬蟲三種。

　　使用無頭瀏覽器的好處主要體如今四個方面：

　　　　（1）測試執行速度更快。

　　　　（2）減小對測試執行的干擾

　　　　（3）簡化測試執行環境的搭建

　　　　（4）在單機環境實現測試的併發執行

　　可是，無頭瀏覽器並不完美，它最大的缺點是，不能徹底模擬真實的用戶行爲，並且因爲沒有實際完成頁面的渲染，因此不太適用於須要對於頁面佈局進行驗證的場景。同時，業界也一直缺少理想的無頭瀏覽器方案。 

目前，Headless Chrome結合Puppeteer

17——精益求精：聊聊提升GUI測試穩定性的關鍵技術

五種形成GUI測試不穩定的因素

一、非預計的彈出對話框

　　當自動化腳本發現控件沒法正常定位，或者沒法操做時，GUI 自動化框架自動進入「異常場景恢復模式」。

　　在「異常場景恢復模式」下，GUI 自動化框架依次檢查各類可能出現的對話框，一旦確認了對話框的類型，當即執行預約義的操做（好比，單擊「肯定」按鈕，關閉這個對話框），接

着重試剛纔失敗的步驟。  

二、頁面控件屬性的細微變化

　　採用「組合屬性」定位控件會更精準，並且成功率會更高，若是能在此基礎上加入「模糊匹配」技術，能夠進一步提升控件的識別率。

三、被測系統的A/B測試

四、隨機的頁面延遲形成控件識別失敗

五、測試數據問題

根據個人實踐經驗，我概括了五種形成 GUI 自動化測試不穩定的主要因素，並給出了對應的解決思路。

　　一、對於非預計的彈出對話框引發的不穩定，能夠引入「異常場景恢復模式」來解決。

　　二、對於頁面控件屬性的細微變化形成的不穩定，可使用「組合屬性」定位控件，而且能夠經過「模糊匹配技術」提升定位識別率。

　　三、對於 A/B 測試帶來的不穩定，須要在測試用例腳本中作分支處理，而且須要腳本作到正確識別出不一樣的分支。

　　四、對於隨機的頁面延遲形成的不穩定，能夠引入重試機制，重試能夠是步驟級別的，也能夠是頁面級別的，甚至是業務流程級別的。

　　五、對於測試數據引發的不穩定，我在這裏沒有詳細展開，留到後續的測試數據準備系列文章中作專門介紹。

18——GUI自動化測試報告

　　理想中的 GUI 測試報告應該是由一系列按時間順序排列的屏幕截圖組成，而且這些截圖上能夠高亮顯示所操做的元素，同時按照執行順序配有相關操做步驟的詳細描述。

19——如何在大型項目中設計GUI自動化測試策略

GUI 自動化的測試策略

　　一、首先，要從前端組件的級別來保證質量，也就是須要對那些自定義開發的組件進行完整全面的測試。

　　最經常使用的方案是：基於 Jest 開展單元測試，並考量 JavaScript 的代碼覆蓋率指標

　　二、其次，每個前端模塊，都會構建本身的頁面對象庫，而且在此基礎上封裝開發本身的業務流程腳本。這些業務流程的腳本，能夠組裝成每一個前端模塊的測試用例。

　　三、最後，組合各個前端模塊，並站在終端用戶的視角，以黑盒的方式使用網站的端到端（E2E）測試。

測試腳本管理

　　對各個前端業務模塊的頁面對象庫和業務流程腳本，實施版本化管理機制

20——淺談移動應用測試方法與思路

　　移動應用根據技術架構的不一樣，主要分爲 Web App、Native App 和 Hybrid App 三大類

移動應用的專項測試

　　一、交叉事件測試

　　二、兼容性測試

　　　　基於 Appium + Selenium Grid + OpenSTF 去搭建本身的移動設備私有云平臺

　　　　第三方的移動設備雲測平臺，國外最知名的是 SauceLab，國內主流的Testin。

　　三、流量測試

　　　　tcpdump、Wireshark、Fiddler

　　　　Android的輕量級性能監控小工具：Emmagee

　　　　iOS 系統，可使用 Xcode 自帶的性能分析工具集中的 Network Activity

　　四、耗電量測試

　　　　Android 經過 adb 命令「adb shell dumpsys battery」來獲取應用的耗電量信息；

　　　　iOS 經過 Apple 的官方工具 Sysdiagnose 來收集耗電量信息，而後，能夠進一步經過Instrument 工具鏈中的 Energy Diagnostics 進行耗電量分析。

　　　　Google推出的history batterian工具很好分析耗電狀況

　　五、弱網絡測試

　　　　移動網絡測試工具：Facebook 的 Augmented TrafficControl（ATC）

　　六、邊界測試

21——移動測試神器：Appium

Appium 的實現原理

　　Appium 做爲目前主流的移動應用自動化測試框架，具備極強的靈活性，主要體如今如下 5 個方面：

　　　　一、測試用例的實現支持多種編程語言，好比 Java、Ruby、Python 等；

　　　　二、Appium Server 支持多平臺，既有基於 Mac 的版本，也有基於 Windows 的版本；

　　　　三、支持 Web App、Native App 和 Hybird App 三大類移動應用的測試；

　　　　四、既支持 iOS，也支持 Android；

　　　　五、既支持真機，也支持模擬器。

Appium內部原理

 　　Appium 的內部原理能夠總結爲：Appium 屬於 C/S 架構，Appium Client 經過多語言支持的第三方庫向 Appium Server 發起請求，基於 Node.js 的 Appium Server 會接受Appium Client 發來請求，接着和 iOS 或者 Android 平臺上的代理工具打交道，代理工具在運行過程當中不斷接收請求，並根據 WebDriver 協議解析出要執行的操做，最後調用 iOS 或者Android 平臺上的原生測試框架完成測試。

　　WebDriverAgent（WDA） 是由 Facebook 開源的支持 iOS 自動化的代理工具，其底層經過 XCUItest 實現自動化。