Python自動化測試框架--Woniu
阿新 • • 發佈:2020-10-22
一、如何評估框架和分層思想
1、為什麼要設計測試框架
- 產品或工具需要考慮開發效率和成本;
- 需要高效的框架;
- 框架,就是介於原生程式碼和最終產品之間的一個半成品;
2、如何評價一個框架的好壞?
從以下幾個方面來評估:
- 獨立於測試工具;如測試框架不受工具限制,測試工具如postman或jmeter只是測試框架某種支援功能的底層的一部分;
- 測試步驟可重用;
- 測試資產可重用;如測試指令碼,測試資料,測試環境等;
- 測試資料易定製;如頁面輸入測試資料,或上傳資料,自動生成特定條件的資料;
- 異常處理機制;如自動截圖,保留日誌和資料,提交bug,自動繼續執行等;
- 測試指令碼易開發;
- 測試指令碼易維護;
- 無人干預執行;如程式碼提交後可自動執行,半夜可定時執行等;bug修復後可自動進行迴歸驗證;
- 程式碼可移植性高;如從window移植到linux上;
- 適宜於團隊開發;如多人開發;
3、當前流行的框架設計思路
- 資料驅動測試DDT(Data-Driven Testing)
- 關鍵字驅動測試KDT(Keyword-Driven Testing)
- 業務流程測試BPT(Business Process Testing)
- 頁面物件模式POM(Page Object Model)
- 基於元件的測試CBT(Component-Based Testing)
4、分層思想
- 核心就是不同的操作,應該放在不同的類和不同的方法中,層與層之間互相依賴,互相呼叫,每一層都有自己的獨特的分工;
- 不會跨層呼叫;
指導原則:
- 上層
- 一切從系統需要提供的功能進行分析;
- 每個層的介面有明確的職責範圍;
- 只要介面規範無變化,介面的實現互不影響;
Woniu CBT框架的設計思想:
- 核心,基於產品業務和基於測試元件;
- 元件有幾大類:
- 公共元件
- 操作元件
- 測試元件
- 業務元件
- 模組元件
5、現在流行框架存在的問題
- 測試框架只針對某些特定領域;
- 測試框架試圖減少測試人員的編碼量,導致指令碼的各項操作被限制的恨死,無法進行深度開發和定製;
- 測試框架的通用性更強,試圖適用於各類測試,使得靈活性和可深度開發性大打折扣;
6、小結
- 測試框架,就是介於原生程式碼和最終產品之間的一個半成品;
- 測試框架的好壞,需要從獨立性,可重用性,穩定性,易開發,易移植,可團隊開發等多角度來衡量;
- 當前流行的框架設計,主要有資料驅動,關鍵字驅動,業務驅動,頁面物件模式,基於元件模式等;
- 框架設計和產品設計,一樣要遵循分層指導原則;
- 現有的框架,存在只針對特別領域,靈活性,可擴充套件性不強等多種問題;
二、影象識別和模版匹配演算法
1、影象識別匹配演算法
為什麼要做影象識別?
- 介面元素定位難題;
- SikuliX沒有專門的python介面,只能利用JPype進行跨語言呼叫;
什麼是影象識別?
- 核心本質,對影象輪廓的描述,變形後的容錯,畫素資訊的匹配處理等;
影象識別要怎麼做和做什麼?
- 在一個大的畫面中,查詢一個匹配某個小區域的畫面元素,然後定位到該元素上,再進行相應的操作(如點選),從而實現測試的目的;
模版匹配
- 對於要操作的畫面元素,進行單獨的截圖,這個截圖稱之為模版;(如要被點選的按鈕圖片)
- 利用這個模版,在整個當前螢幕或者當前視窗進行搜尋匹配,找到完全符合條件的區域的中心位置座標的過程,就是模版匹配;(如拿著按鈕的圖片,在頁面中按照畫素來查詢,找到了,就點選頁面中按鈕的中心位置,完成操作目的);
- 模版匹配的缺點:模版匹配具有一些侷限,只能進行平行移動,若原畫面中的匹配模版發生旋轉或大小變化時,模版匹配演算法無效;即識別不出來模版變形的情況;
滑動比對(RGBA比對)
匹配度(Similarity)
- 即相似度,主要用於解決影象匹配過程中的容錯問題;
- 考慮的角度有以下幾方面:
- 畫素數佔比;
- RGBA值佔比;(在正確的值的上下浮動10%範圍以內,都可以判斷為正確),如紅色取200為正確,180或220以內也可以算正確;
- 還可以採用預先轉換為灰度圖的方式,即圖片轉為白黑灰後比對;
影象識別匹配演算法--演算法思路
1)依據測試場景,對需要操作的元素截圖;
- 注意,截圖時最好確保圖片的中心位置與元素的中心位置一致;
2)依據需要對當前螢幕截圖;
3)獲取模版圖片和螢幕截圖的每一個畫素點的顏色值,並儲存到一個列表中,供後續滑動和遍歷對比;
4)通過迴圈在X和Y軸兩個方向上進行逐點判斷,如果沒有匹配就滑動到下一個點,直到找到匹配為止;
5)依據匹配的點的位置,獲取中心點的位置,並返回;
6)利用獲取到的座標,進行相應的滑鼠和鍵盤操作即可。