做鴻蒙開發(fā)的人應(yīng)該都經(jīng)歷過這種狀態(tài)功能改完了要驗證流程結(jié)果同一套點擊、滑動、輸入在真機上手動點了一遍又一遍。后來我把這套重復(fù)工作交給HDC命令行工具的模擬操作一句命令代替一個手指動作配合腳本能跑完整條鏈路。這篇就是我在鴻蒙設(shè)備上折騰HDC模擬操作的完整記錄包括每條指令的用法、連設(shè)備時踩過的坑以及常見的失效排查方法適合剛接觸鴻蒙開發(fā)或者想把手動測試自動化的人參考。1. HDC模擬操作是什么解決了什么真實問題1.1 從ADB時代過來的聯(lián)想早年做安卓開發(fā)時我已經(jīng)習(xí)慣用ADB調(diào)試設(shè)備。第一次接觸鴻蒙的HDC我第一反應(yīng)是翻命令清單發(fā)現(xiàn)它和ADB的很多思路是共通的。HDC全稱是HarmonyOS Device Connector本質(zhì)是電腦與鴻蒙設(shè)備之間的調(diào)試橋。它負責把電腦上的命令送到設(shè)備執(zhí)行也能把設(shè)備日志、狀態(tài)回傳回來。對開發(fā)者來說最常用的功能無非是安裝HAP、列出設(shè)備、進入Shell、模擬輸入操作等。我特別想強調(diào)一點HDC不是ADB的簡單改名。鴻蒙的設(shè)備協(xié)議、權(quán)限模型和應(yīng)用安裝機制都有自己的一套邏輯。比如安裝包是HAP拉起Ability用aa start很多命令參數(shù)跟Android不完全一樣。所以你不能想當然地把ADB命令直接套過來最好的方式是先看一遍HDC支持的完整命令列表再針對性使用。模擬操作就是其中讓我覺得價值最大的一塊。它的本質(zhì)很簡單讓設(shè)備系統(tǒng)接收一個輸入事件比如坐標點擊、滑動手勢、物理按鍵、文本輸入。對App來說這些事件跟在屏幕上用手指操作沒有本質(zhì)區(qū)別。應(yīng)用并不感知是誰在點只感知到觸摸事件流。這也就意味著你可以在不侵入應(yīng)用代碼的前提下用一個外部命令行工具驅(qū)動整個界面流程非常適合回歸測試、演示錄屏、批量驗證。1.2 HDC能模擬哪些操作我在實際項目里最常用的模擬能力包括這幾類點擊指定屏幕坐標模擬一次手指按下和抬起。滑動從起點滑到終點支持設(shè)置時長也能模擬長按。按鍵模擬返回鍵、Home鍵、音量鍵、電源鍵等物理按鍵。文本輸入向當前焦點輸入框發(fā)送ASCII文本。屏幕相關(guān)亮屏、息屏、鎖屏狀態(tài)切換。配合輔助截圖、查看當前窗口、獲取布局信息等。這些能力單獨看都不復(fù)雜但組合起來能完成很多事。比如我剛接手一個鴻蒙應(yīng)用時需要在不同賬號下跑一遍完整的用戶路徑。手動操作一次大概三分鐘十幾個賬號就是快一個小時而且人很容易點錯。用HDC模擬操作之后我把賬號信息放進循環(huán)跑一組大約十分鐘就能完事中途還能去做別的事。1.3 它和你手動操作有什么區(qū)別最大的區(qū)別是“狀態(tài)感知能力”。人手點界面時眼睛能看到界面變化知道該等頁面加載完再點下一步。HDC模擬操作沒有眼睛它只管發(fā)指令不管界面是否已經(jīng)響應(yīng)。所以你用HDC做模擬操作時必須自己負責節(jié)奏控制等待、延時、校驗頁面狀態(tài)。這也是新手最常翻車的地方。另一個區(qū)別是“坐標系”。人眼看到的是一個控件手指點的是控件中間。HDC不知道控件在哪只認識屏幕上的像素坐標。所以你要先把“我想點那個按鈕”翻譯成“屏幕橫向第540像素、縱向第1200像素的位置”。這就引出后續(xù)坐標獲取和動態(tài)計算的問題。我的結(jié)論是HDC模擬操作是一個極其好用的“假手指”但它不是“智能大腦”。它勝在輕量、穩(wěn)定、不受應(yīng)用代碼限制適合做流程性、重復(fù)性的操作模擬。如果你需要智能斷言、元素識別、復(fù)雜邏輯應(yīng)該上自動化測試框架但那套體系要維護的東西也多得多。兩者不是替代關(guān)系是互補關(guān)系。2. 搭建環(huán)境HDC下載、連接設(shè)備與版本血淚坑2.1 HDC從哪里來HDC不是系統(tǒng)自帶的命令行工具需要單獨準備。最常見的來源有兩個一個是安裝DevEco Studio時隨IDE一起提供的一般在SDK目錄下另一個是華為開發(fā)者官網(wǎng)提供的Command Line Tools包。我建議開發(fā)機直接把 hdc 所在路徑加進系統(tǒng)環(huán)境變量否則每次都得帶著全路徑敲命令時間長了非常煩躁。Windows下我記得默認路徑類似C:\Program Files\Huawei\DevEco Studio\sdk\default\openharmony\toolchains\hdc.exemacOS下一般是*/sdk/default/openharmony/toolchains/hdc。裝好后在終端里敲hdc -v能看到版本號就說明路徑?jīng)]問題。這里有個小提醒命令行工具包分不同平臺Windows、macOS、Linux各有對應(yīng)版本別下錯。Linux環(huán)境如果提示權(quán)限不足記得先chmod x hdc。2.2 USB連接和設(shè)備發(fā)現(xiàn)有線連接仍然是最可靠的連接方式。首先在鴻蒙手機上開啟開發(fā)者模式打開“設(shè)置”應(yīng)用進入“關(guān)于本機”或者“關(guān)于手機”找到HarmonyOS版本號連續(xù)點擊多次直到系統(tǒng)提示“已進入開發(fā)者模式”。然后進入“開發(fā)者選項”打開“USB調(diào)試”。用數(shù)據(jù)線把設(shè)備和電腦連起來在終端執(zhí)行hdc list targets如果輸出里出現(xiàn)了一串設(shè)備序列號說明連接成功。如果列表為空我一般按這個順序排查先確認數(shù)據(jù)線是不是只能充電不能傳數(shù)據(jù)盡早換一根原裝線或品牌線再檢查開發(fā)者選項里的“USB調(diào)試”是否確實打開最后看電腦的驅(qū)動有沒有識別到設(shè)備。Windows下如果系統(tǒng)提示“未知設(shè)備”需要安裝設(shè)備驅(qū)動很多第三方助手工具也能順手裝驅(qū)動但注意別裝捆綁軟件。我實測下來USB連接最隱蔽的坑其實是鎖屏。設(shè)備息屏鎖著HDC雖然能識別設(shè)備但部分操作會不響應(yīng)最好在調(diào)試期間把鎖屏方式改為“無”或者“滑動解鎖”或者至少在跑模擬操作前手動亮屏解鎖一次。2.3 無線連接的兩種姿勢調(diào)試自動化時我不能一直插著線所以無線連接用得越來越多。鴻蒙的HDC無線連接有個讓我一開始繞暈的地方它有兩種路徑。第一種是先用USB連接電腦在設(shè)備上確認無線調(diào)試端口后執(zhí)行hdc tconn 192.168.1.100:5555執(zhí)行成功后可以拔掉USB線后續(xù)命令都走局域網(wǎng)。第二種是設(shè)備已經(jīng)開啟了“無線調(diào)試”選項界面會顯示一個IP和端口直接在電腦上執(zhí)行hdc tconn 設(shè)備IP:端口。只要電腦和設(shè)備在同一個局域網(wǎng)一般都能連上。無線連接有個前提防火墻別攔著端口。Windows電腦偶爾會出現(xiàn)connect failed的報錯關(guān)掉第三方防火墻或者加白名單就能解決。另外無線環(huán)境不如USB穩(wěn)定跑長時間自動化時如果出現(xiàn)掉線可以寫一個簡單的重連邏輯發(fā)現(xiàn)hdc list targets結(jié)果為空就再執(zhí)行一次hdc tconn。2.4 版本不匹配的坑版本問題是我這次要重點說的。HDC和鴻蒙系統(tǒng)之間有嚴格的版本適配關(guān)系舊版HDC連新版系統(tǒng)經(jīng)常出現(xiàn)莫名其妙的怪問題。最典型的表現(xiàn)有設(shè)備能識別但hdc shell input tap執(zhí)行后無響應(yīng)。部分命令提示unknown command或者invalid parameter。安裝HAP時報錯但應(yīng)用在設(shè)備上明明能正常安裝。我之前踩過一次很典型的坑電腦里裝過一個較老版本的HDC連上一臺新版本的鴻蒙設(shè)備tap命令一直沒反應(yīng)但list targets和shell都正常。折騰很久才意識到是版本問題換成與設(shè)備匹配的新版HDC后立刻恢復(fù)。所以我的建議是盡量從官方渠道下載和鴻蒙系統(tǒng)版本配套的HDC別為了圖方便用歷史遺留的舊版本也別從第三方渠道隨意拿。命令行工具這種基礎(chǔ)組件踩坑成本遠高于下載成本。3. 模擬操作四大金剛tap、swipe、keyevent、text3.1 tap點坐標而不是點控件最基本的模擬點擊命令是這樣hdc shell input tap 540 1200這條命令的含義是在屏幕橫坐標540、縱坐標1200的位置執(zhí)行一次點擊。坐標系以屏幕左上角為原點單位是物理像素。你需要知道目標控件在屏幕上的大概位置而不是它的控件ID。獲取坐標的方法有很多。最原始但在調(diào)試階段最有效的一種是先用HDC截一張圖然后在圖片工具里查看目標位置坐標。HDC截圖命令是hdc shell snapshot_display -f /data/local/tmp/screen.png hdc file recv /data/local/tmp/screen.png ./screen.png截圖之后用系統(tǒng)自帶畫圖工具打開鼠標放在想點的位置就能看到像素坐標。這個辦法笨但管用。鴻蒙的開發(fā)者選項里也有“指針位置”功能開啟后屏幕上會實時顯示手指觸摸的坐標這也是一種輔助獲取坐標的方式。值得注意的是tap 命令發(fā)出去之后沒有任何回顯。它不會告訴你“點擊成功”或“點擊失敗”所以你必須在點擊之后自己驗證界面變化。我一般會在關(guān)鍵操作后用hdc shell snapshot_display再截一張圖對比前后差異。3.2 swipe滑動和長按都靠它滑動手勢用這條命令hdc shell input swipe x1 y1 x2 y2 duration前四個參數(shù)是起始點和結(jié)束點的坐標最后一個可選參數(shù)是滑動持續(xù)時間單位毫秒。它不只是用來翻頁拖動進度條、下拉刷新、長按圖標這些手勢都能靠它模擬。舉幾個我實際用過的場景模擬下拉刷新從屏幕中間偏上位置滑到偏下位置例如hdc shell input swipe 540 800 540 1800 200。拖動滑塊亮度條或者視頻播放進度條可以從起點滑塊位置滑到目標位置時間放長到500毫秒以上動作更接近真人。長按操作比如長按桌面圖標進入編輯模式用同一坐標作為起點和終點把duration設(shè)置為1000毫秒以上。長按其實就是swipe的一個特殊情況這點容易被人忽略。我最早還以為長按需要單獨的命令后來才發(fā)現(xiàn)只要把起點和終點設(shè)成同一個點再拉長執(zhí)行時間即可。3.3 keyevent按鍵也能模擬按鍵模擬的命令格式hdc shell input keyevent 4數(shù)字4代表返回鍵。除了數(shù)字編碼有些HDC版本也支持直接傳按鍵名稱比如hdc shell input keyevent BACK。我用過一段時間的常用KeyCode整理成表格方便查閱KeyCode含義說明3HOME鍵回到桌面4BACK鍵返回上一級26電源鍵亮屏/息屏切換82菜單鍵打開上下文菜單85播放/暫停多媒體控制87下一曲多媒體控制111ESC鍵退出當前操作220亮度調(diào)低部分設(shè)備支持221亮度調(diào)高部分設(shè)備支持keyevent 的用法和真實按鍵幾乎等價。比如我想回到桌面再重新進入應(yīng)用就可以先hdc shell input keyevent 3再執(zhí)行hdc shell aa start -b 包名 -a Ability名。這種方式比模擬滑動手勢更穩(wěn)定因為不依賴坐標任何時候執(zhí)行都會觸發(fā)系統(tǒng)返回行為。這里提一個容易踩的坑不同鴻蒙版本對某些按鍵的映射可能存在差異。比如菜單鍵在部分版本上不響應(yīng)音量鍵的KeyCode在不同設(shè)備上也可能不一樣。建議在真機上先手動執(zhí)行一遍確認行為符合預(yù)期再寫進腳本。3.4 text輸入中文的特殊處理文本輸入命令是這樣的hdc shell input text hello這條命令的核心限制是默認只支持ASCII字符不支持中文、日文、韓文等多字節(jié)語言。如果你直接往命令里塞中文大概率會失敗或者輸入亂碼。另外空格也不能直接傳需要用%s代替比如hdc shell input text hello%sWorld如果確實需要輸入中文怎么辦我實踐下來的可行方案有兩個方向。方向一把要輸入的內(nèi)容放到系統(tǒng)剪貼板然后在輸入框里長按點擊“粘貼”。但HDC本身沒有標準的剪貼板寫入命令所以這個方案依賴額外工具不是開箱即用。方向二換用支持ADB/HDC輸入中文的第三方輸入法或測試輸入法這類輸入法一般自帶監(jiān)聽通道能把文本通過特殊協(xié)議塞進輸入框。文本輸入還有一個細節(jié)焦點問題。input text只往當前獲得焦點的輸入框發(fā)送內(nèi)容如果界面上沒有輸入框獲得焦點命令執(zhí)行了也白執(zhí)行。所以我在一套操作里會先點一下目標輸入框等一秒再發(fā) text 命令。3.5 獲取真實坐標的輔助手段模擬操作的坐標是最容易出問題的地方所以我單獨說一塊。除了截圖看坐標還有兩個命令很有用hdc shell wm size hdc shell wm density第一條輸出當前屏幕的物理分辨率比如Physical size: 1080x2340第二條輸出像素密度比如Physical density: 480。這兩個值能幫我做坐標比例換算。假設(shè)我寫腳本時用的基準設(shè)備是1080x2340點擊位置是540x1200現(xiàn)在換到一臺720x1600的設(shè)備簡單按比例縮放就能得到新設(shè)備的點擊坐標新x 540 * 720 / 1080 360新y 1200 * 1600 / 2340 ≈ 821這個比例換算不是絕對精確因為不同的屏幕比例和系統(tǒng)欄高度會影響最終點中的位置但至少能把“完全點歪”變成“大概正確”后續(xù)微調(diào)就快很多。如果有條件還可以嘗試hdc shell uiautomator dump導(dǎo)出當前界面的控件樹然后解析XML里每個控件的bounds屬性從而拿到目標控件的中心點坐標。不過這類命令在鴻蒙不同版本上的支持程度不一樣有些版本路徑和格式有差異。我一般在開發(fā)調(diào)試階段用截圖和指針位置在寫腳本階段用wm size做動態(tài)換算控件樹只在有空的時候用。4. 組合起來才是真本事還原一個真實業(yè)務(wù)場景4.1 場景設(shè)計與前置準備前面全是單條命令的拆解但實際工作里沒人會只敲一條。我拿一個真實場景來說驗證一個鴻蒙應(yīng)用的“登錄-首頁-退出”流程。前置條件有幾個一是應(yīng)用已經(jīng)安裝到設(shè)備上我一般用hdc install xxx.hap安裝二是有一個測試賬號注意不要用真實敏感賬號因為自動化腳本里可能會明文記錄密碼三是設(shè)備保持解鎖狀態(tài)最好關(guān)閉自動鎖屏。在執(zhí)行模擬操作之前我會先手動進一次應(yīng)用記住登錄頁的幾個關(guān)鍵坐標賬號輸入框坐標、密碼輸入框坐標、登錄按鈕坐標。這次手動操作花不了幾分鐘但能省下腳本調(diào)試階段反復(fù)猜測坐標的時間。4.2 完整命令串演一遍下面是這個場景的完整命令串我用的是bash環(huán)境Windows下可以放進.bat腳本# 檢查設(shè)備在線 hdc list targets # 安裝應(yīng)用如果已經(jīng)安裝可以跳過 hdc install ./demo.hap # 啟動應(yīng)用包名和Ability名根據(jù)實際替換 hdc shell aa start -b com.example.demo -a MainAbility # 等待應(yīng)用啟動 sleep 3 # 點擊賬號輸入框 hdc shell input tap 540 1100 # 輸入賬號 hdc shell input text testuser01 # 點擊密碼輸入框 hdc shell input tap 540 1300 # 輸入密碼僅ASCII hdc shell input text Passw0rd # 點擊登錄按鈕 hdc shell input tap 540 1600 # 等待首頁加載 sleep 5 # 模擬返回鍵退出到桌面 hdc shell input keyevent 4這串命令每一步都有注釋核心邏輯就是“點、等、輸入、點”。執(zhí)行完之后我再截一張圖確認最終狀態(tài)hdc shell snapshot_display -f /data/local/tmp/result.png hdc file recv /data/local/tmp/result.png ./result.png打開截圖看到首頁元素出現(xiàn)說明整條流程跑通了。如果發(fā)現(xiàn)卡在中間某一步我會在對應(yīng)步驟前后各加一次截圖快速定位是哪一步?jīng)]生效。4.3 延時與等待不要裸奔執(zhí)行在上面命令串里我反復(fù)用了sleep這不是隨便寫的而是模擬操作最容易被低估的點。真實用戶點擊登錄按鈕之后眼睛會看到加載動畫等到頁面跳轉(zhuǎn)完才進行下一步。但HDC命令是按順序執(zhí)行的上一秒點完登錄下一秒可能直接發(fā)返回鍵結(jié)果應(yīng)用還沒來得及跳轉(zhuǎn)返回鍵就把應(yīng)用退了。我的經(jīng)驗是不同操作之間必須給足緩沖時間。啟動應(yīng)用后至少等3秒頁面跳轉(zhuǎn)至少等3到5秒網(wǎng)絡(luò)請求頻繁的場景建議等更久。更穩(wěn)妥的方式是輪詢。比如想確認登錄后的首頁是否出現(xiàn)可以寫一個循環(huán)每隔1秒查一次當前頂層窗口直到出現(xiàn)目標頁面或者超時。例如可以嘗試這樣的思路用hdc shell hidumper -s WindowManager查看當前窗口信息在循環(huán)里解析關(guān)鍵字段匹配到目標頁面就繼續(xù)超時就報錯退出。這種方式比固定sleep更可靠但代碼量會大一些。我個人的習(xí)慣是腳本前期用固定sleep快速跑通流程流程穩(wěn)定后再把關(guān)鍵節(jié)點改成輪詢等待提高整條自動化鏈路的穩(wěn)定性。5. 模擬操作失效時我的排查鏈路5.1 命令返回錯誤碼但沒有具體提示最讓人頭疼的情況是命令執(zhí)行了可是界面紋絲不動。這時候我第一步會檢查HDC是不是還連著設(shè)備。無線連接偶爾會悄悄斷開但命令仍然能下發(fā)設(shè)備卻沒響應(yīng)。先跑一下hdc list targets如果輸出為空執(zhí)行hdc tconn 設(shè)備IP:端口重連再跑一次。如果設(shè)備在線接著檢查設(shè)備是不是熄屏了?？蓜e笑我至少有兩三次在設(shè)備息屏狀態(tài)下跑自動化命令全部“成功”了但屏幕一直是黑的后來才意識到是設(shè)備自動鎖屏。檢查方法也很簡單執(zhí)行hdc shell power-shell wakeup讓設(shè)備亮屏然后重新解鎖再跑。這個問題暴露了模擬操作的盲區(qū)它只會發(fā)事件不會等待屏幕狀態(tài)變化所以你在腳本里要主動管理亮屏狀態(tài)。5.2 點擊了但界面沒反應(yīng)如果設(shè)備在線、屏幕亮著、命令也執(zhí)行了但頁面沒有預(yù)期變化我一般懷疑三個原因。第一個原因是點擊位置被其他元素遮擋。常見的遮擋源是系統(tǒng)彈窗、懸浮球、下拉通知欄。尤其是懸浮球很多設(shè)備開著三指截屏或懸浮導(dǎo)航透明觸控層會在某些區(qū)域吃掉點擊事件。我調(diào)試時習(xí)慣把這類輔助功能全部關(guān)掉。第二個原因是控件實際響應(yīng)區(qū)域和視覺位置不一致。有些自定義控件、WebView里的元素視覺上在上方實際可點擊區(qū)域卻在另一個位置。遇到這種情況我會用開發(fā)者選項里“指針位置”功能手動點一次目標看系統(tǒng)上報的坐標是多少再對比HDC里填的坐標就知道偏差了多少。第三個原因是時序問題。點擊真的發(fā)出去了但當時頁面還在加載目標控件還沒渲染出來點擊落在了空白區(qū)域。這種問題很好判斷把點擊前的sleep加長或者改成輪詢等待頁面元素出現(xiàn)而不是等固定秒數(shù)。5.3 坐標漂移換個設(shè)備就偏固定坐標的腳本換個分辨率設(shè)備就跑偏這是坐標模擬的天生弱點。前面我提到過用hdc shell wm size做比例換算這里再補充一個細節(jié)比例換算對設(shè)備的“可用顯示區(qū)域”很敏感。有些設(shè)備的屏幕比例是19.5:9有些是20:9單單按分辨率等比縮放底部導(dǎo)航欄、狀態(tài)欄的高度占比不一樣導(dǎo)致?lián)Q算后的坐標在豎屏頁面上接近正確但頁面偏下部分的按鈕會發(fā)生明顯偏移。我在項目里給過一條曲線救國的方案先在同一型號設(shè)備上寫死基準坐標用腳本啟動時自動讀取當前設(shè)備分辨率只對同一比例范圍的設(shè)備做換算如果相差太大干脆用單獨一套坐標配置。5.4 系統(tǒng)限制安全輸入、鎖屏和隱私保護不是所有操作都能用HDC模擬搞定這一點必須提前知道。鴻蒙和所有主流移動操作系統(tǒng)一樣對敏感輸入有保護機制。典型例子是鎖屏密碼、支付密碼這類安全輸入框系統(tǒng)會攔截來自非物理輸入設(shè)備的模擬輸入。我測試過在鎖屏密碼界面用input text輸入數(shù)字事件可以發(fā)出但密碼框根本收不到這是系統(tǒng)層面的安全策略不是命令寫錯了。另外一個容易踩的坑是應(yīng)用自行實現(xiàn)的“防自動化”邏輯。有些金融、風(fēng)控類應(yīng)用會檢測觸摸事件的來源如果發(fā)現(xiàn)輸入事件不是來自真實屏幕觸摸會彈出安全提示或踢出登錄狀態(tài)。遇到這種情況HDC模擬操作就不是合適的工具應(yīng)該考慮使用官方提供的自動化測試框架通過系統(tǒng)授權(quán)的方式完成輸入。排查完這些之后我一般會重新讀一遍自己腳本的每個動作設(shè)備狀態(tài)檢查、亮屏喚醒、屏幕解鎖、點擊、等待、校驗。這套鏈路上任何一個環(huán)節(jié)斷開都可能導(dǎo)致“命令成功但實際沒操作”。6. 從單條命令到自動化腳本把模擬操作變成生產(chǎn)力6.1 用批處理/Shell串起來模擬操作要真正提升效率必須從“手工敲”變成“腳本跑”。最簡單的形式就是Shell腳本把命令串成一串。我在Shell里習(xí)慣先定義一個公共函數(shù)避免到處重復(fù)function tap() { hdc shell input tap $1 $2 sleep 1 } function type_text() { hdc shell input text $1 sleep 1 } tap 540 1100 type_text testuser01這樣做的價值有兩個一是統(tǒng)一處理延時不會漏寫sleep二是如果以后命令變了只需要改函數(shù)內(nèi)部不用滿世界找命令。Windows下的.bat腳本也差不多不過語法更受限我建議Windows用戶直接裝一個Git Bash或者使用Python跨平臺。腳本跑起來之后建議在關(guān)鍵節(jié)點加上日志輸出比如echo [$(date)] 點擊登錄按鈕。自動化腳本一旦跑得時間長沒有日志就完全不知道執(zhí)行到哪一步掛了加日志雖然土但排查效率翻倍。6.2 用Python的subprocess統(tǒng)一管理當腳本變得復(fù)雜判斷分支變多Shell腳本就不太好維護了我一般切到Python。Python的優(yōu)勢是異常處理、數(shù)據(jù)解析、循環(huán)和重試都更好寫。調(diào)用HDC的命令很直接import subprocess import time def hdc(*args): 統(tǒng)一執(zhí)行hdc命令返回stdout文本 result subprocess.run( [hdc, *args], capture_outputTrue, textTrue, encodingutf-8 ) return result.stdout.strip() def tap(x, y): hdc(shell, input, tap, str(x), str(y)) time.sleep(1) def is_device_online(): targets hdc(list, targets) return bool(targets) if not is_device_online(): print(設(shè)備不在線開始重連...) hdc(tconn, 192.168.1.100:5555) time.sleep(2) tap(540, 1100)這個封裝的好處是以后換命令、加重試都只改函數(shù)不用動業(yè)務(wù)流程。我甚至?xí)趖ap函數(shù)里加一個簡單的重試邏輯點擊后截圖對比前后像素差異判定是否需要再點一次。這種“點擊-截圖-校驗”的模式能讓自動化腳本穩(wěn)定不少不過實現(xiàn)復(fù)雜度也高一些適合需要長時間跑回歸的場景。6.3 結(jié)合控件樹讓坐標不再硬編碼如果說HDC模擬操作有什么讓我覺得可惜的那就是純坐標驅(qū)動太脆UI一變?nèi)?。后來我嘗試把它和控件樹結(jié)合起來才算稍微緩解了這個問題。思路是在執(zhí)行模擬操作前先導(dǎo)出當前界面的控件樹XML然后在XML里找到目標文本比如“登錄按鈕”讀取它的bounds屬性算出中心點坐標再調(diào)用tap。這樣就算按鈕在界面上移動了位置只要文本文案不變腳本也能找到新坐標。實現(xiàn)大致是hdc shell uiautomator dump導(dǎo)出的XML可能在不同鴻蒙版本上路徑不同我用的時候會先執(zhí)行一次看輸出路徑再用hdc shell cat 對應(yīng)路徑查看內(nèi)容。解析XML用Python的xml.etree.ElementTree或者正則都行。這個方法不是萬能的有些自繪控件、Canvas渲染的界面不會暴露標準控件樹那就只能退回坐標方案。但它確實能處理很大一部分常規(guī)按鈕、文本框值得一試。6.4 真實自動化中的幾個小習(xí)慣最后聊幾個我在長期實踐中沉淀下來的習(xí)慣都不是什么高級技巧但能實實在在減少踩坑次數(shù)。第一腳本開頭一定要寫設(shè)備與分辨率校驗。很多自動化跑掛不是用例寫錯了而是連接設(shè)備變了或者分辨率變了。先確認環(huán)境再開始執(zhí)行能省下一半的排錯時間。第二危險操作前加日志和確認。比如腳本要刪除數(shù)據(jù)、退出登錄、或者執(zhí)行頻率很高的循環(huán)我都會在日志里打印當前執(zhí)行位置必要時在執(zhí)行前加一個人工確認的交互。第三敏感信息不要硬編碼在腳本里。測試賬號和密碼最好從環(huán)境變量或單獨的配置文件中讀取腳本本身可以提交到代碼倉庫但敏感信息不要跟著提交。第四每個關(guān)鍵動作后給足等待時間但也不要為了追求穩(wěn)妥把所有sleep都拉滿。我通常先用3到5秒的sleep跑通流程穩(wěn)定后再逐步減小等待時間優(yōu)化到“剛好夠用”的程度。第五跑完自動化一定要留證據(jù)。至少截一張最終屏幕圖有條件就錄屏。這樣出了問題回看證據(jù)比猜原因高效得多。這些習(xí)慣讓我的HDC模擬操作腳本從“能跑一次”進化到“每天跑幾輪也不容易掛”這才是自動化真正產(chǎn)生價值的地方。