作者華測知一
更多精彩內容關注 公眾號程序員一凡
目前測試平臺項目研發已經完成并且在Github開源，有興趣的朋友可以去Github下載https://github.com/ooqitech/ATP
大家有興趣可以下載來玩一玩
前言：
ATP(Auror Test Platform)是一個集成接口-UI自動化的一體化測試平臺，關于ATP和如何對服務端接口測試方案已介紹了，這篇推文將介紹ATP對于UI自動化測試的解決方案。
你是否曾想過，不使用任何自動化框架，不寫代碼的情況下，寫好功能測試用例后，點擊某個按鈕，一個web系統/app就自動點來點去；并能按你的思路，在線執行UI自動化測試、回歸測試；解決日常工作中一些重復繁瑣，無聊費事的工作。
沒錯，ATP已實現可在線執行web/手機的UI自動化測試。它讓測試工程師在做UI自動化測試時：
脫離測試框架、代碼、環境依賴在線運行
無需連接usb的在線真機運行
UI測試與api測試用例互相調用串場景運行
脫離Jenkins定時運行冒煙測試，測試計劃
先看一個移動端UI自動化用例運行效果：點擊執行按鈕→自動跳轉真機遠程控制界面，運行測試用例
本文將從以下幾點依次介紹：
UI自動化簡介與痛點所在
整理架構與設計思想
web端使用說明與開發思路
安卓端使用說明與開發思路
未來規劃路線
UI自動化測試簡介：
其實早在2004年ThoughtWorks公司，一個測試工程師就實現了基于JavaScript代碼庫的自動化測試工具，Selenium1.0誕生了。
誤區：UI自動化僅限對于界面的排版，按鈕，顏色等UI測試，但其實是通過界面UI來驗證系統業務邏輯
原理：通過腳本語言或者工具，模擬用戶行為操作，最接近用戶真實場景，實現對web/app自動測試
真實價值：代替大量的UI重復操作，讓測試用例重復使用，縮短反饋周期，為企業減少了時間和勞力成本。因為從測試的行為本質上看，人工UI測試和自動化UI測試沒有區別，唯一的區別是一個由人來執行點擊，一個由代碼或者工具執行
UI自動化的痛點-ATP的優勢：
不過我感覺到，大家極度關心的UI自動化測試離我們越來越遠。因為在實踐中，經常是這樣的畫面：
熟悉某套自動化測試框架花了多久
熟悉某個組織用例和代碼的框架花多少天
寫完一大推自動化用例代碼后，多人協作，項目如何整合
各種運行環境依賴，如何可持續集成
行成完整的UI自動化體系耗時很長...
我們先看一個簡單web端自動化測試用例，
如圖所示：
以上僅是一個測試用例，未涉及到數據、版本、項目整合、持續集成等，何況還有移動端UI自動化，選擇的自動化測試框架可能又不同.......
想要做好UI自動化，基于擁有一些經驗豐富,熟悉一門開發語言和主流自動化測試框架的測試工程師的前提下。?這也是為什么UI自動化測試是處于測試金字塔最上層，因為它確實投入成本大，專業性要求高
所以，當你還糾結選擇用什么開發語言，用什么測試框架來進行UI自動化的時候，越糾結，ATP研發對UI自動化測試的解決方案想法越是強烈，下面分析下倆者的利弊：
換句話說，用ATP進行UI自動化測試，“低投入，高回報”。
說出來你還有可能不相信，ok，接下來，我們就來了解一下ATP的一些設計思想、實現過程以及功能效果展示，看它是如何來進行web和app的UI自動化測試，然后快速上手吧
ATP對于UI自動化前后端交互架構設計：
整體框架采用的是前后端分離：
前端：vue.js+elementUI
服務端：flask
數據庫：mysql，Redis
UI自動化框架：web端-seleniunm? 移動端automator2
ATP對于UI自動化一些設計思想：
測試環境與測試用例分離
測試用例與被測頁面對象分離
頁面元素管理采用POM模型
用例管理：項目→系統→模塊(1~n)→用例集→測試用例
用例相互串聯：UI與UI用例，UI與接口用例串聯，實現業務串場景需求
web運行環境：Selenium grid分布式用戶本地瀏覽器 ；chrome的headless模式、基于Docker的selenium/hub鏡像容器
app運行環境：用atx-serve對測試安卓真機進行集群管理,僅需要知道測試機的ip，無需連接數據線，就可以進行真機自動化了
用例組織框架：unittest
測試報告：HTMLTestRunner庫
用例實時推送日志：前后端建立WebSocket連接，在線調試與實時日志
測試計劃：linux中Crontab命令觸發，批量定時執行用例
ATP平臺UI自動化核心功能：
測試用例增刪改查
用例支持(xmind、excel)導入/導出
頁面元素對象采用POM模型
用例批量復制
UI用例與UI用例之間可相互進行業務調用
UI用例與接口用例之間可相互調用
app可掃描用戶在ATP上傳的二維碼圖片
用例支持分布式用戶本地/服務器運行/真機運行
支持用例批量運行
測試結果報告展示，附帶錯誤操作截圖
測試計劃，定時執行，發送email警告郵件
功能介紹和開發思路：
1.用例運行如何區分Web/App-環境與用例分離:
ATP是同時支持web端/app端的UI自動化測試，所以第一步先配置環境信息：被測系統的類型、URL/APP包名
思路：分別定義運行web/app倆個測試類，運行用例時前端調用一個run接口，根據前端請求參數中系統類型，然后添加相應的測試類至unittest.TestSuite然后運行,
如圖所示：設置系統類型web，錄入網站的url
2.眾多的頁面對象元素如何管理-POM模式：
UI自動化原理是模擬用戶操作頁面上各種元素，換句話說首先得定位元素，因此第二步配置被測頁面的元素，ATP支持常見8種定位元素方法，先了解一下POM以及xpath定位控件
POM （Page Object Modle）: 頁面根據系統來管理，而元素對象根據頁面來管理，可以將測試用例與被測頁面對象分離，頁面元素與系統分離
POM優勢：頁面元素對象根據系統統一管理，可重復利用；易于維護。例如，前端某個按鈕或名稱修改，所有操作到該按鈕的測試用例不需要修改，僅修改按鈕的元素值
思路：前端配置好頁面對象，以key-value的方式存儲于數據庫表中。當用例的操作步驟用到該頁面對象，將對象屬性作為參數，去調用一個返回webElement的公共方法，此時就可進行click、move、send_keys等操作
靈活運用xpath：xpath雖可通過瀏覽器開發者工具直接復制，但是復制的往往是絕對路徑而且不穩定。所以我們可以根據Dom節點屬性、文本值等方式相對路徑定位；把復雜的位置描述封裝到一條短短的字符串里面，靈活、穩定且萬能
例如：同一元素，前者是復制的xpath,后者是寫的相對路徑xpath；這樣寫讓用例穩定且容易閱讀
如圖所示：配置某被測系統頁面元素，該系統下的用例就可直接引用這些對象，進行點擊、輸入操作
3.用例信息何如管理-以一個字典存儲,運行時再加載
配置系統環境和頁面對象之后，第三步就可新增測試用例；也證實上文提到的設計思想：測試環境、被測頁面對象都和測試用例分離，用例主要包括：
基本信息：添加用例標題，描述信息等
前置操作：初始化數據，數據庫操作、執行其它前置UI用例，讓用例更靈活，串聯成一些流程場景
操作步驟：支持元素點擊、鍵盤輸入、鼠標移動、執行javascript(例如滑動滾動條，切換窗口)、切換frame、執行接口測試用例、app掃描二維碼等等
預期結果：當前元素在頁面可見/不可見，可見的次數、元素可操作/不可操作、數據庫校驗等
實現思路：將前端配置好的測試用例所有信息以字典列表(因為可能批量執行用例)的形式存儲于數據庫表中，運行用例的時候再去組裝和加載用例信息，再調用unittest中subTest方法和selenium API去執行用例
如圖所示：就是配置測試用例的過程
配置完成后，將直接以表格的形式展現整個用例的操作過程，一目了然，這個用例what to do,，仔細一看其就是一個功能測試用例，因為ATP已將功能測試用例和UI自動化用例合二為一:
如圖所示：就是一個登錄用例的過程
4 .用例運行環境(web端)-本地瀏覽器grid/headless
ok，所有配置工作都已就緒，我們就可在線執行UI自動化測試了，有點躍躍欲試！
如圖所示：可知被測系統類型是web端，它的URL，
點擊執行用例按鈕，會自動彈出一個瀏覽器，當然如果你只關心運行結果，可以選擇不彈出本地瀏覽器，它會在服務器上默默的運行，而且測試報告每步操作都附帶截圖
思路：運行環境本地瀏覽器grid/無頭模式headless
本地瀏覽器：使用Selenium Grid，遠程操作瀏覽器。服務器作為hub，用戶本地瀏覽器作為運行Node,
hub: 參數值表示管理中心的url地址
Node:連接hub進行節點注冊
通過SeleniumGrid可控制多臺機器多瀏覽器執行測試用例,如圖所示我在一臺機器上注冊5個瀏覽器node
也可選擇瀏覽器無UI界面在后臺運行：
chrome的headless模式
如圖所示：ATP在loading中，正在本地執行測試用例，然后自動彈出瀏覽器，打開了快遞100網站登錄
用例執行完成后：ATP loading完成，瀏覽器自動關閉，然后會顯示一個查看測試報告的按鈕
5.測試失敗如何在報告加截圖-HTMLTestRunner
測試報告使用第三方庫HTMLTestRunner
思路：使用selenium中get_screenshot_as_base64方法， 獲取頁面截圖的base64編碼
點擊顯示截圖按鈕：可循環查看操作過程，如圖所示，登錄測試用例，第一步：輸入了用戶名,
6.app用例如何在線運行-集群管理
app測試用例的配置與web測試用例配置完全一樣
實現思路：將測試機用atx-serve進行集群管理，再遠程控制手機界面。
在服務器上啟動rethinkdb，再將測試機進行初始化：
$ rethinkdb --http-port 8090? ??
$python -m uiautomator2 init? 服務器 ip
這時打開url：測試機ip地址:7912/remote 就能訪問手機遠程控制界面
如圖所示：點擊運行按鈕，可選需要運行的測試機
點擊確定運行，自動進入遠程控制測試真機界面，運行了被測APP，且實時查看app的運行狀態
7.app如何進行掃描操作-二維碼push至手機sd卡
在編輯測試用例時，操作步驟選擇方式為：掃描二維碼，然后上傳本地圖片，即可掃描二維碼
實現思路：用戶在前端上傳被掃描的二維碼圖片，后端儲存于服務器，再推送至測試手機sd卡的指定文件夾下
app掃描時從相冊中去選擇，該指定文件夾下用戶上傳的二維碼圖片，實現掃描，之后再刪除圖片，保證每次該文件夾是用戶最新上傳的二維碼
8.如何定時測試計劃-Crontab命令
測試用例不僅可在線運行，可定時執行冒煙測試、測試計劃，然后發送郵件測試報告
思路：通過linux中Crontab命令觸發定時批量執行
如圖所示：每周1-5中午12點半，定時執行某個系統下的自動化測試用例
了解這些功能和效果展示后，對于ATP的UI自動化測試是不是能快速上手，不僅在項目交付中實現UI自動化測試，且將UI自動化用例與功能測試用例已合二為一
未來規劃路線：
IOS移動端UI自動化
移動端app多維度的性能測試
用例多線程、并發執行，提高效率
支持視頻回放操作，快速定位出錯原因
結語：
ATP一體化測試平臺，讓接口和UI測試用例變得更簡單，讓QA更專注于測試用例本身的設計
這次的推文后，ATP已經介紹了接口測試方案，UI自動化測試，APP自動化，然而ATP遠不止這些功能，還有接口壓測、基準測試等等，請繼續關注我們，不要吝嗇你們的需求和建議，我們會不斷的完善優化。
整理了一份216頁軟件測試大廠面試題，以及2020推薦最新的簡歷模板，送給小伙伴們，關注公眾號程序員一凡回復【簡歷】自行領取，和一些小伙伴建立一個技術交流群，一起探討技術，分享技術資料，旨在共同學習進步，如果感興趣就加入我們吧！
視頻課相關資料加群1079636098獲取，還可領取更多軟件測試面試題資料和Python自動化/測試開發學習資料。
