寫在前面
上個星期分享了《基于Sikuli GUI圖像識别架構的PC用戶端自動化測試實踐》,但sikuli看起來怎麼都像是上個世紀的界面風格,且功能過于簡陋。而同樣基于圖像識别架構的Airtest,則無疑強大了許多,本次分享的内容是基于Airtest實作Windows應用的自動化測試,内容大綱:
- Airtest架構介紹:Airtest适用項目、Airtest特點、Airtest的優勢
- Airtest架構組成、原理
- Airtest環境搭建及IDE的簡單使用
-
Airtest開展Windows應用自動化測試實踐:
連接配接Windows應用
Windows常用API
編寫測試代碼
設計測試用例
運作效果
檢視測試報告
- 總結與思考
一、Airtest架構介紹
1.Airtest介紹
Airtest是網易出品的一款基于圖像識别和Poco控件識别的一款UI自動化測試工具。這個架構設計來源于新穎的圖形腳本語言Sikuli,關于Sikuli架構可見上一篇分享《基于Sikuli GUI圖像識别架構的PC用戶端自動化測試實踐》。和Sikuli架構的原理一樣,使用者不需要一行行的去寫代碼,而是用螢幕截屏的方式,用截出來的圖形擺列組合成神器的程式,這是Airtest的一部分。另外,Airtest也可以基于poco這個UI控件搜尋架構,通過控件的名稱、id之類的來定位目标控件,原理類似于 appium。官網:http://airtest.netease.com/
2.Airtest适用項目
- 遊戲
- Android
- iOS
- Web
- Windows
3.Airtest特點
- 跨平台
- 易操作
- 可擴充
- 支援GUI編輯器
4.Airtest的優勢
相比于其他的自動化測試架構,Airtest主要有如下兩個優勢:
- 大幅度降低自動化腳本的編寫和維護成本
- 解決遊戲測試的痛點
二、Airtest架構組成、原理
1.Airtest架構組成
- Airtest:是一個跨平台的、基于圖像識别的UI自動化測試架構,适用于遊戲和App,支援平台有Windows、 Android和iOS;
- Poco:是一款基于UI控件識别的自動化測試架構,目前支援Unity3D/cocos2dx/Android原生app/iOS原生app/ 微信小程式,也可以在其他引擎中自行接入poco-sdk來使用;
- AirtestIDE:跨平台的UI自動化測試編輯器,内置了Airtest和Poco的相關插件功能,能夠快速簡單地 編寫Airtest和Poco代碼;
- AirLab:真機自動化雲測試平台,目前提供了TOP100手機相容性測試、海外雲真機相容性測試等服務;
2.Airtest工作原理
三、Airtest環境搭建及IDE的簡單使用
官方文檔:https://airtest.doc.io.netease.com/IDEdocs/getting_started/AirtestIDE_install/
1.下載下傳安裝
1)安裝python
由于Airtest架構是基于python語言開發,本地需要搭建python相關環境,建議使用python3,Python 下載下傳位址:https://www.python.org/downloads/
2)下載下傳AirtestIDE用戶端
AirtestIDE用戶端下載下傳:
Windows系統使用者在官網上下載下傳對應32位或是64位版本的zip包,解壓後得到AirtestIDE檔案夾,輕按兩下AirtestIDE/AirtestIDE.exe即可啟動
2.Airtest IDE使用
1)生成報告
Airtest運作完成後,會自動生成一份報告,通過下圖按鈕可以檢視,點選後會自動啟動浏覽器檢視報告
2)圖檔/代碼模式切換
Airtest IDE中右鍵,即可兩種模式互相切換
切換後的效果如下:
四、Airtest開展Windows應用自動化測試實踐
1.連接配接Windows應用
連接配接Windows應用有三種方法,分别是:
1)通過搜尋視窗連接配接
裝置窗-Windows視窗連接配接-搜尋視窗,選擇視窗後,點選連接配接
2)通過句柄連接配接
(由于句柄容易發生變化,是以不推薦此連接配接方式):下圖的67330即為企業微信的句柄
3)通過正則比對應用應用标題進行連接配接
if not cli_setup:
auto_setup(__file__, logdir=True, devices=["Windows:///?title_re=.*閱雲*"])
2.Windows常用API
官方文檔:https://airtest.readthedocs.io/zh_CN/latest/all_module/airtest.core.win.win.html
源碼:https://airtest.readthedocs.io/zh_CN/latest/_modules/airtest/core/win/win.html
- connect:連接配接裝置
- shell:執行cmd指令
- snapshot:截圖
- keyevent:執行鍵盤事件
- text:輸入文本
- key_press:按下某個按鍵
- key_release:釋放某個按鍵
- touch:滑鼠點選事件
- double_click:滑鼠輕按兩下
- swipe:滑動
- move_mouse:移動滑鼠
- mouse_down:按下滑鼠(左/右)鍵
- mouse_up:釋放滑鼠(左/右)鍵
3.編寫測試代碼
先看下待測試的windows應用的頁面布局:
1)代碼構成
- 導入核心api和初始化用戶端的方法
__author__ = "Administrator"
import random
from airtest.core.api import *
from airtest.cli.parser import cli_setup
- 連接配接windows應用
if not cli_setup:
auto_setup(__file__, logdir=True, devices=["Windows:///?title_re=.*閱雲*"])
- Airtest IDE遵循python編碼風格,是以可以将各個測試動作/場景封裝成一個一個的函數,當然也可以封裝在其他檔案裡,然後導入引用
2)案例
- 發送文本消息:
操作步驟為:進入聊天視窗>輸入文本内容>發送
def send_text(time):
setup_send_msg()
for i in range(time):
text("這是AIRTEST發送的第%s條消息"%str(i))
keyevent("{ENTER}")
keyevent("{ENTER}")
- 截圖發送
點選截圖按鈕>滑動滑鼠拉取截圖區域>确認發送截圖
操作步驟為:進入聊天視窗>點選截圖按鈕>滑動滑鼠拉取截圖區域>确認發送截圖
def send_screenshot():
setup_send_msg()
touch(Template(r"tpl1656061157595.png", record_pos=(-0.028, 0.138), resolutinotallow=(959, 654)))
sleep(1)
swipe((300,400), (600,800), duratinotallow=0.8, steps=2)
keyevent("{ENTER}")
4.設計測試用例
GUI自動化測試并不适用于發現bug,更多的是将重複性高的、簡單的手工操作場景轉換為自動操作,用于回歸測試,或是用于一些資料的構造模拟上。
将一些基本操作封裝為一個個函數以後,就可以進行組合、設計測試用例了,如:
① 場景一:發送不同類型的消息
分别調用以下函數:
- 調用發送文本函數
- 調用發送表情函數
- 調用發送圖檔函數
- 調用發送截圖函數
- ......
當然,以上各個函數也可以單獨作為一個個測試用例,進而用于回歸測試;
② 場景二:持續發送文本/圖檔消息
将上述函數,加上循環,便可實作持續發送xx類型的消息;不過與其說是一條測試用例,倒不如說是為了模拟人工長時間操作運作下程式的穩定性,亦或是輔助其他特殊測試場景,比如:
- 去年我在測試移動端時、通過自動化模拟一端持續發送大量圖檔消息,進而測試出【iOS移動端在弱網情況下接收大量離線檔案消息程式會core掉】的bug。
- 今天在利用Airtest模拟持續發送文本消息、測試程式穩定性時,發現【單聊發送消息傳錯類型參數,發送給群聊,導緻發送消息失敗,且無任何消息發送記錄】的bug,很奇怪,我手工發送的就沒任何問題,暫時還沒找到規律,研發還在定位中。雖然Airtest并沒有直接發現bug,但卻給發現bug創造了更多可能。
5.運作效果
6.檢視測試報告
Airtest運作完成後會自動生成測試報告,通過控制台菜單欄的檢視報告按鈕,即可自動在浏覽器打開測試報告:
五、總結與思考
- Airtest也可以用于pycharm編輯器下,需要手動提前安裝airtest庫:pip install -U airtest,安裝後即可建立airtest腳本,文法和在Airtest IDE中編寫時一緻。另外,pycharm編輯器也可以直接打開airtest腳本;
- 對于web、APP自動化主要用該端特定的自動化架構,如selenium、appium,而此類測試架構無法實作的Windows應用的操作,則可以借助Airtest實作,進而打通端到端自動化測試流程;
- 自動化測試編碼實作僅僅是自動化測試流程中一個小環節,更重要的是場景設計、用例實作以及如何發揮自動化測試的價值;
- 自動化測試可能不會發現多少bug,但卻給發現bug創造了更多可能;