《軟件測試52講》
《軟件測試52講》
GUI自動化測試篇
12——從0到1：你的第一個GUI自動化測試
Selenium的實現原理
Selenium2.0的工作原理，又稱Selenium WebDriver，它利用的原理是：使用瀏覽器原生的WebDriver實現頁面操作。下圖為Selenium WebDriver的執行流程。
1、當使用Selenium2.0啟動瀏覽器Web Broser時，后台會同時啟動基於WebDriver Wire協議的Web Service作為Selenium的Remote Server，並將其與瀏覽器綁定。
綁定完成后，Remote Server就開始監聽Client端的操作請求。
2、執行測試時，測試用例會作為Client端，將需要執行的頁面操作請求以Http Request的方式發送給Remote Server。該HTTP Request的body，是以WebDriver Wire
協議規定的JSON格式來描述需要瀏覽器執行的具體操作。
3、Remote Server接收到請求后，會對請求進行解析，並將解析結果發給WebDriver，由WebDriver實際執行瀏覽器的操作。
4、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測試不穩定的因素
1、非預計的彈出對話框
當自動化腳本發現控件無法正常定位，或者無法操作時，GUI 自動化框架自動進入“異常場景恢復模式”。
在“異常場景恢復模式”下，GUI 自動化框架依次檢查各種可能出現的對話框，一旦確認了對話框的類型，立即執行預定義的操作（比如，單擊“確定”按鈕，關閉這個對話框），接
着重試剛才失敗的步驟。
2、頁面控件屬性的細微變化
采用“組合屬性”定位控件會更精准，而且成功率會更高，如果能在此基礎上加入“模糊匹配”技術，可以進一步提高控件的識別率。
3、被測系統的A/B測試
4、隨機的頁面延遲造成控件識別失敗
5、測試數據問題
根據我的實踐經驗，我歸納了五種造成 GUI 自動化測試不穩定的主要因素，並給出了對應的解決思路。
1、對於非預計的彈出對話框引起的不穩定，可以引入“異常場景恢復模式”來解決。
2、對於頁面控件屬性的細微變化造成的不穩定，可以使用“組合屬性”定位控件，並且可以通過“模糊匹配技術”提高定位識別率。
3、對於 A/B 測試帶來的不穩定，需要在測試用例腳本中做分支處理，並且需要腳本做到正確識別出不同的分支。
4、對於隨機的頁面延遲造成的不穩定，可以引入重試機制，重試可以是步驟級別的，也可以是頁面級別的，甚至是業務流程級別的。
5、對於測試數據引起的不穩定，我在這里沒有詳細展開，留到后續的測試數據准備系列文章中做專門介紹。
18——GUI自動化測試報告
理想中的 GUI 測試報告應該是由一系列按時間順序排列的屏幕截圖組成，並且這些截圖上可以高亮顯示所操作的元素，同時按照執行順序配有相關操作步驟的詳細描述。
19——如何在大型項目中設計GUI自動化測試策略
GUI 自動化的測試策略
1、首先，要從前端組件的級別來保證質量，也就是需要對那些自定義開發的組件進行完整全面的測試。
最常用的方案是：基於 Jest 開展單元測試，並考量 JavaScript 的代碼覆蓋率指標
2、其次，每一個前端模塊，都會構建自己的頁面對象庫，並且在此基礎上封裝開發自己的業務流程腳本。這些業務流程的腳本，可以組裝成每個前端模塊的測試用例。
3、最后，組合各個前端模塊，並站在終端用戶的視角，以黑盒的方式使用網站的端到端（E2E）測試。
測試腳本管理
對各個前端業務模塊的頁面對象庫和業務流程腳本，實施版本化管理機制
20——淺談移動應用測試方法與思路
移動應用根據技術架構的不同，主要分為 Web App、Native App 和 Hybrid App 三大類
移動應用的專項測試
1、交叉事件測試
2、兼容性測試
基於 Appium + Selenium Grid + OpenSTF 去搭建自己的移動設備私有雲平台
第三方的移動設備雲測平台，國外最知名的是 SauceLab，國內主流的Testin。
3、流量測試
tcpdump、Wireshark、Fiddler
Android的輕量級性能監控小工具：Emmagee
iOS 系統，可以使用 Xcode 自帶的性能分析工具集中的 Network Activity
4、耗電量測試
Android 通過 adb 命令“adb shell dumpsys battery”來獲取應用的耗電量信息；
iOS 通過 Apple 的官方工具 Sysdiagnose 來收集耗電量信息，然后，可以進一步通過Instrument 工具鏈中的 Energy Diagnostics 進行耗電量分析。
Google推出的history batterian工具很好分析耗電情況
5、弱網絡測試
移動網絡測試工具：Facebook 的 Augmented TrafficControl（ATC）
6、邊界測試
21——移動測試神器：Appium
Appium 的實現原理
Appium 作為目前主流的移動應用自動化測試框架，具有極強的靈活性，主要體現在以下 5 個方面：
1、測試用例的實現支持多種編程語言，比如 Java、Ruby、Python 等；
2、Appium Server 支持多平台，既有基於 Mac 的版本，也有基於 Windows 的版本；
3、支持 Web App、Native App 和 Hybird App 三大類移動應用的測試；
4、既支持 iOS，也支持 Android；
5、既支持真機，也支持模擬器。
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 實現自動化。