搞測試這些年我最大的感受是測試環(huán)境這東西平時沒人當回事一旦出問題全組人都得停下來等它。項目排期里最容易被砍的也是測試環(huán)境搭建但真正吃過虧的人都知道環(huán)境不穩(wěn)定測試結(jié)果就是一堆廢數(shù)據(jù)缺陷漏到線上返工代價成倍往上翻。所以這篇不是教你怎么裝某個工具而是把測試環(huán)境搭建與管理這件事從頭到尾捋一遍。我挑了兩種最常見的場景來展開一是移動端App自動化測試環(huán)境怎么搭二是4G儀表環(huán)境下天線性能測試能測哪些項目、環(huán)境怎么搭。前者是軟件側(cè)后者是硬件側(cè)表面上看不搭邊但背后的搭建思路、管理方法和排查邏輯其實高度一致。剛轉(zhuǎn)測試的新人、被困在環(huán)境問題里的測試開發(fā)、需要接觸天線測試的硬件工程師都能在里面找到對自己有用的東西。1. 測試環(huán)境的核心邏輯先想清楚“測什么”再動手搭1.1 測試環(huán)境不是一堆機器而是“可復(fù)現(xiàn)的驗證載體”很多人一提到測試環(huán)境第一反應(yīng)就是“申請幾臺服務(wù)器、裝個被測系統(tǒng)、連上數(shù)據(jù)庫就完事了”。硬件側(cè)更直接覺得“把儀器開機、天線接上、軟件打開”就算搭好了。但實際上測試環(huán)境的本質(zhì)是一個能讓你穩(wěn)定復(fù)現(xiàn)測試結(jié)果、隔離干擾變量的驗證載體。為什么“可復(fù)現(xiàn)”排在第一位你想想同一個用例今天跑是綠的明天跑是紅的第一反應(yīng)肯定是查代碼查半天發(fā)現(xiàn)是環(huán)境變了數(shù)據(jù)庫連接串被改了、配置文件被覆蓋了、某個后臺服務(wù)重啟后沒有自動拉起。這種情況下你再多的自動化腳本、再詳細的用例設(shè)計都白搭因為環(huán)境本身就是最大的不確定因素。軟件測試環(huán)境和硬件測試環(huán)境在這一點上是相通的。App自動化測試要復(fù)現(xiàn)“用戶操作某個界面”的行為前提是設(shè)備狀態(tài)、應(yīng)用版本、服務(wù)端接口返回都必須可控天線性能測試要復(fù)現(xiàn)“天線在某頻段下的輻射指標”前提是儀表配置、線纜損耗、屏蔽箱內(nèi)部環(huán)境都必須一致。環(huán)境控不住數(shù)據(jù)就沒有可信度。1.2 動手搭建前先拆三層被測對象、依賴鏈、數(shù)據(jù)流我見過太多人拿到需求就開干裝完環(huán)境才發(fā)現(xiàn)測不了又回頭補。其實搭建前花半小時做一次靜態(tài)拆解后面能省一天的排錯時間。拆什么拆三層。第一層被測對象。你到底在測誰的什么行為是測App的登錄流程還是測服務(wù)端的接口兼容是測天線模組的無源性能還是測整機的有源OTA指標被測對象決定了環(huán)境的主體是什么、關(guān)鍵指標是什么。測App主體是設(shè)備和應(yīng)用測天線主體是天線和儀表。第二層依賴鏈。被測對象不是孤立的。App要跑起來依賴后端接口、數(shù)據(jù)庫、第三方SDK、網(wǎng)絡(luò)環(huán)境天線要測出指標依賴綜測儀、射頻線纜、屏蔽箱、夾具、轉(zhuǎn)臺。把依賴鏈一條條列出來每條依賴都問一句我這里有沒有版本對不對接口通不通這一步做完環(huán)境的基本藍圖就有了。第三層數(shù)據(jù)流。測試數(shù)據(jù)從哪里來、到哪里去、需不需要偽造App自動化需要固定的賬號和測試數(shù)據(jù)而且不能污染生產(chǎn)數(shù)據(jù)天線測試需要已知的參考天線和標準校準數(shù)據(jù)作為比對基準。數(shù)據(jù)流定義清楚后面寫初始化腳本、做數(shù)據(jù)清理才有依據(jù)。1.3 環(huán)境配置版本化別讓“環(huán)境債”拖垮項目測試環(huán)境另一個讓人頭疼的地方是“環(huán)境債”。你今天手工改了一個配置文件調(diào)通了用例結(jié)果沒記錄下周環(huán)境掛了要重建所有人都不記得改過什么只能重新踩一遍坑。正經(jīng)做法是把環(huán)境配置當代碼管起來。軟件側(cè)用Docker鏡像或虛擬機快照把環(huán)境整體固化成模板配置文件入庫初始化腳本放到代碼倉庫里任何人拉下來都能在半小時內(nèi)重建一套一模一樣的環(huán)境。硬件側(cè)沒法用容器但同樣可以建立“硬件環(huán)境基線”記錄儀器的型號、固件版本、校準日期、線纜編號、接頭扭矩、屏蔽箱型號以及儀表里存好的測試設(shè)置文件。每次搭建環(huán)境時先對照基線清單逐項核驗而不是憑記憶操作。這一步很像給環(huán)境“做備份”。備份本身不產(chǎn)生價值但環(huán)境出問題時它是你唯一的救命稻草。2. App自動化測試環(huán)境搭建一步一步說清楚2.1 架構(gòu)先落地設(shè)備層、驅(qū)動層、腳本層、報告層的職責(zé)劃分移動端App自動化測試環(huán)境說復(fù)雜可以很復(fù)雜說簡單其實就是一個四層結(jié)構(gòu)。設(shè)備層是真正執(zhí)行操作的地方可以是Android真機、iOS真機也可以是模擬器。設(shè)備層要解決的是“設(shè)備可用性”連接正常、系統(tǒng)版本正確、USB調(diào)試打開、屏幕解鎖、應(yīng)用安裝好。驅(qū)動層負責(zé)和設(shè)備通信Android上用ADBiOS上用WebDriverAgent。腳本層是測試用例的實現(xiàn)用Python、Java或者JavaScript去驅(qū)動自動化框架比如Appium執(zhí)行點擊、滑動、輸入等操作。報告層把執(zhí)行結(jié)果收集起來生成測試報告方便后續(xù)分析和CI集成。很多團隊搭環(huán)境失敗不是因為技術(shù)水平不行而是因為沒把這四層分開想。比如腳本層報“找不到元素”其實是設(shè)備層的應(yīng)用沒啟動報“會話創(chuàng)建失敗”其實是驅(qū)動層和設(shè)備版本不匹配。分層想清楚了問題定位就能精準很多。2.2 從零開始的環(huán)境清單與安裝順序以最常見的Appium加Python這套開源方案為例完整的清單大概是JDK1.8或11看項目需要Android SDK重點是platform-tools里面包含ADBNode.jsLTS版本Appium Server需要Appium Server2.x版本UiAutomator2 DriverAndroid的自動化驅(qū)動Python3和pip以及Appium-Python-Client庫一臺Android真機或模擬器Appium Inspector用于查看元素定位信息排查問題特別有用安裝順序有講究。我的習(xí)慣是先裝JDK和Node再裝Android SDK然后裝Appium最后再連設(shè)備。每裝一步就當場驗證一步不要全部裝完再去查哪里不行。驗證命令很直接。裝完JDK終端敲java -version能看到版本號才算過裝完Android SDK敲adb version裝完Node敲node -v裝完Appium敲appium --version。如果哪一步命令提示找不到那一定是環(huán)境變量沒配好優(yōu)先去查JDK和Android SDK的PATH配置。2.3 關(guān)鍵參數(shù)與常見配置項大多數(shù)問題的根源都在這里App自動化報錯的時候很多人第一反應(yīng)是查腳本但實測下來大部分問題出在環(huán)境配置上。特別是Appium連接設(shè)備時用到的Capabilities配置那是重災(zāi)區(qū)。以Android端為例最常用的幾個參數(shù)platformName固定寫AndroidplatformVersion設(shè)備系統(tǒng)版本比如12或13必須和設(shè)備實際版本一致deviceName設(shè)備名稱直接用adb devices里的序列號最穩(wěn)appPackage和appActivity被測App的包名和啟動Activity用adb shell查不要靠猜automationNameAndroid端建議用UiAutomator2noReset設(shè)為true避免每次執(zhí)行都清掉應(yīng)用的登錄狀態(tài)還有一個容易被忽略的如果設(shè)備連著多個而Capabilities里指定了錯誤的udidAppium會直接連錯設(shè)備或者創(chuàng)建會話失敗。所以多設(shè)備環(huán)境里一定要顯式指定udid。另外Appium Server默認監(jiān)聽的端口是4723。如果你同一臺機器上起了多個Appium服務(wù)或者端口被占了會話就起不來。排查方法很簡單lsof -i:4723看端口占用或者換一個端口啟動。這種問題看起來像是“環(huán)境壞了”實際上就是一個端口沖突。2.4 最小腳本跑通一條用例先讓鏈路通起來再說新環(huán)境搭完,別急著寫復(fù)雜的用例先跑一個最小腳本把鏈路打通。這個腳本做的事情很簡單啟動App等一個元素出現(xiàn)點擊一下斷言頁面發(fā)生了變化。鏈路通了后面的事情才有意義。以Python為例核心寫法是這樣from appium import webdriver from appium.options.android import UiAutomator2Options caps { platformName: Android, platformVersion: 13, deviceName: emulator-5554, appPackage: com.example.app, appActivity: .MainActivity, automationName: UiAutomator2, noReset: True, } options UiAutomator2Options().load_capabilities(caps) driver webdriver.Remote(http://localhost:4723, optionsoptions) driver.find_element(byid, valuecom.example.app:id/button_login).click() result driver.find_element(byid, valuecom.example.app:id/tv_welcome).text assert 歡迎 in result driver.quit()這個腳本里webdriver.Remote的地址指向Appium Server的地址和端口。如果腳本能跑通說明設(shè)備層、驅(qū)動層、腳本層之間的鏈路已經(jīng)沒問題了。如果在這一步就報錯不要馬上懷疑腳本先回頭檢查Appium日志和ADB連接多半是環(huán)境配置的問題。3. 4G儀表環(huán)境下天線性能測試哪些項目能測出天線性能3.1 4G儀表測試環(huán)境由什么組成和App自動化測試環(huán)境不同4G儀表環(huán)境測的是硬件實物的射頻性能所以它是一套看得見摸得著的物理系統(tǒng)主要包括綜測儀、屏蔽箱或暗室、夾具、射頻線纜、參考天線以及被測天線和配套設(shè)備。綜測儀是核心常見的有羅德與施瓦茨的CMW500、安立MT8820/MT8821這類支持LTE制式和對應(yīng)頻段。它在測試里扮演兩個角色一是產(chǎn)生4G下行信號模擬基站行為二是測量被測天線接收到信號后的各項指標。屏蔽箱或暗室的作用則是把外部環(huán)境的無線信號隔離開否則周圍的路由器、手機信號、基站信號都會混進測試數(shù)據(jù)里結(jié)果根本沒法看。夾具和線纜容易被忽略但它們直接決定測試的重復(fù)性。天線放歪了一毫米方向圖測試結(jié)果可能就差好幾個dB射頻線纜接頭沒擰緊駐波比指標就會異常。所以硬件側(cè)的準備工作本質(zhì)上是把每一個物理環(huán)節(jié)固定住、記錄下來。3.2 哪些測試項目能測出天線性能每個指標背后的物理含義這是硬件側(cè)最常被問到的問題4G儀表環(huán)境下到底哪些測試項目能真實反映出天線性能的好壞直接給結(jié)論常用且有效的測試項目可以分成兩類無源指標和有源指標。無源指標里最基礎(chǔ)的是回波損耗和電壓駐波比VSWR。這個指標反映的是天線和射頻前端之間的匹配程度。如果天線在某頻段的駐波比偏高說明信號在饋電口反射回去白白浪費了能量。在看4G天線時重點考察LTE的工作頻段內(nèi)駐波比是否小于2正常來說1.5以下算優(yōu)秀。這個指標最直接也最容易在儀表環(huán)境下測出來。接下來是無源增益和方向圖。增益是天線在某個方向集中輻射信號的能力方向圖則描述這個能力在空間各方向上的分布。用綜測儀配一臺可旋轉(zhuǎn)的轉(zhuǎn)臺讓天線在水平面或垂直面上轉(zhuǎn)一圈就能畫出方向圖。全向天線要求方向圖盡量接近一個圓定向天線則要求在最大輻射方向上有明顯的主瓣。輻射效率也很關(guān)鍵。它衡量的是天線輸入口進來的射頻能量有多少真正輻射到了空間中去。匹配再好如果天線結(jié)構(gòu)本身損耗太大效率一樣上不去。輻射效率一般需要在暗室里用無源測試方法測量因為要區(qū)分輻射功率和反射功率。有源指標里最核心的是TRP和TIS這兩個也是4G手機等整機產(chǎn)品入網(wǎng)和運營商驗收時最看重的OTA指標。TRP總輻射功率反映的是天線在發(fā)射方向上的綜合表現(xiàn)它把傳導(dǎo)功率、天線匹配、輻射效率全串在一起。在儀表環(huán)境下測TRP儀表作為接收端通過測試天線接收被測設(shè)備在4G頻段上發(fā)出的功率然后按球面積分算出總輻射功率。同一臺設(shè)備換成不同天線模組TRP數(shù)值會出現(xiàn)明顯差異所以它是判斷天線發(fā)送性能的硬指標。TIS總?cè)蜢`敏度則是從接收端角度衡量天線性能。儀表向被測設(shè)備發(fā)射4G信號被測設(shè)備接收并反饋解調(diào)結(jié)果逐漸降低儀表發(fā)射功率直到設(shè)備靈敏度達到臨界點以此算出整個球面的平均靈敏度。天線接收效率差、方向圖有覆蓋盲區(qū)TIS數(shù)值就會掉。有源指標還能補充測試吞吐量和誤碼率。在特定4G頻段下固定發(fā)射功率記錄下行吞吐量。天線性能差會導(dǎo)致信道質(zhì)量下降、重傳率上升最終反映在吞吐量數(shù)據(jù)上。它雖然不是直接測天線輻射但可以作為整機端天線性能的輔助驗證手段。3.3 搭建與校準的關(guān)鍵控制點數(shù)據(jù)準不準全靠這一步硬件測試環(huán)境搭好后直接測出來的數(shù)據(jù)往往是偏的因為線纜、接頭、夾具都會引入額外損耗。所以正式測試之前必須先做校準。第一步是路徑損耗校準。把綜測儀的輸出端直接用一根高質(zhì)量的射頻線纜連到測試天線端不開無線鏈路讓儀表測得一個基準功率值這個值和理論值之間的差值就是線纜和接頭的路徑損耗。后續(xù)測試結(jié)果要自動加上這個補償值。第二步是參考天線校準。放一根已知增益、已知性能的標準天線到測試位置測一遍各項指標把這些數(shù)據(jù)作為基準。之后測被測天線時結(jié)果和參考天線對比就能判斷被測天線是偏優(yōu)還是偏劣。第三步是環(huán)境底噪確認。在屏蔽箱里不放任何天線和被測件儀表掃描一遍LTE頻段的底噪電平。如果底噪太高說明屏蔽隔離沒做好或者有外部干憂源這時候測出來的TIS數(shù)據(jù)會虛高或虛低。底噪不達標的測試數(shù)據(jù)沒有意義。還有一個經(jīng)常出問題的點夾具對天線性能的影響。天線附近一旦出現(xiàn)金屬物體、吸波材料、塑料外殼它的匹配和輻射特性都會變化。所以夾具的材料選擇要避開金屬固定天線的位置要穩(wěn)定每次安放時盡量讓天線處于相同姿態(tài)。我遇到過方向圖測試重復(fù)性差最后發(fā)現(xiàn)就是天線在夾具上每次放的位置差了那么一兩毫米。4. 測試環(huán)境的日常管理與維護4.1 環(huán)境基線壞了不可怕怕的是不知道“原來是什么樣”測試環(huán)境早晚會壞這是常態(tài)真正可怕的是環(huán)境壞了之后大家都不知道正常的基線是什么樣子。所以團隊里一定要有一份環(huán)境基線文檔把環(huán)境的健康狀態(tài)記下來。軟件環(huán)境基線包含操作系統(tǒng)版本、JDK版本、Node版本、Appium版本、Android SDK版本、被測App的版本和安裝包路徑、數(shù)據(jù)庫初始化狀態(tài)、關(guān)鍵配置文件內(nèi)容。硬件環(huán)境基線包含儀表型號和固件版本、校準有效期、線纜編號和損耗值、屏蔽箱編號、參考天線的增益曲線。每次環(huán)境變更后更新基線記錄這樣下次環(huán)境出問題時對照基線逐項查很快就能找出差異點。4.2 多項目并行時的資源隔離不要讓A項目把B項目的環(huán)境搞亂測試環(huán)境最典型的沖突就是多個項目共用一套環(huán)境。A項目改了接口mock配置B項目跑用例發(fā)現(xiàn)全掛了。解決思路是隔離。軟件層面端口要分開數(shù)據(jù)庫要建獨立schema緩存服務(wù)要用不同的key前綴配置通過環(huán)境變量區(qū)分。硬件層面儀器設(shè)備要建立預(yù)約機制一套儀表同一時間只允許一個項目使用線纜、夾具、天線也要按項目固定配好不要今天拆明天裝。隔離做不到絕對但要確保變更可視化誰在什么時間改了什么都不能含糊。4.3 數(shù)據(jù)清理與快照回滾讓環(huán)境能“還原”才敢隨便折騰環(huán)境日常使用中會積累大量臟數(shù)據(jù)測試賬號越建越多、數(shù)據(jù)庫表越堆越滿、日志文件撐爆磁盤。如果不定期清理環(huán)境會變得越來越慢測試結(jié)果也會被臟數(shù)據(jù)干擾。我的做法是每周做一次數(shù)據(jù)清理清理前先備份清理后記錄清理范圍。容器化環(huán)境下可以直接用快照功能在環(huán)境狀態(tài)良好時打一個快照出問題后一鍵回滾。硬件環(huán)境雖然沒有快照但可以把儀表設(shè)置導(dǎo)出成文件保存環(huán)境亂了直接導(dǎo)入恢復(fù)。5. 常見問題與排查技巧實錄5.1 App自動化環(huán)境問題速查表實際運行中常見的環(huán)境問題我整理了一張速查表現(xiàn)象大概率原因排查命令/方法解決方式adb devices 看不到設(shè)備USB調(diào)試沒開、驅(qū)動問題adb devices重新插拔開啟USB調(diào)試會話創(chuàng)建超時端口占用、設(shè)備版本不匹配lsof -i:4723換端口或關(guān)掉沖突服務(wù)元素定位失敗App啟動太慢、頁面未加載在腳本前增加顯式等待調(diào)整等待策略用WebDriverWait報“UiAutomator2 server”錯誤驅(qū)動版本和Android版本不兼容appium driver check升級或回退UiAutomator2 Driver版本模擬器卡頓嚴重分配的內(nèi)存不夠、無硬件加速檢查模擬器配置增加RAM開啟硬件加速5.2 天線測試環(huán)境問題速查表硬件側(cè)的測試環(huán)境問題排查思路也類似現(xiàn)象大概率原因排查方法解決方式同一根天線兩次測TRP差異過大天線放置位置不一致檢查夾具標記測量位置偏移固定天線定位工裝駐波比在高頻段異常偏高接頭松動或線纜損壞用校準線纜對照測重新擰緊接頭檢查線纜彎折TIS數(shù)值虛高屏蔽箱底噪過高無被測件時掃描底噪檢查屏蔽箱屏蔽性能排除干擾源方向圖出現(xiàn)非對稱凹陷測試環(huán)境存在金屬反射體目視檢查天線周圍移除附近金屬物件清理暗室5.3 排查方法論先把“變量”控制在最小范圍不管是軟件環(huán)境還是硬件環(huán)境排查問題的大原則是一樣的一次只改一個變量。很多人排查環(huán)境問題時喜歡同時改好幾個參數(shù)結(jié)果問題解決了但根本不知道是哪個改動生效的下次照樣踩坑。我會把問題按層級拆開。軟件側(cè)從底往上排查設(shè)備層有沒有連接ADB通不通驅(qū)動服務(wù)有沒有啟動再到腳本層有沒有寫錯。硬件側(cè)從信號鏈路往后排查儀表輸出正不正常線纜通不通夾具和天線接沒接好每查一層確認無誤了再往上走。這個方法聽著樸素但比瞎猜效率高得多。排查過程中日志是最可靠的線索。Appium的日志會明確告訴你會話創(chuàng)建到哪一步失敗儀表界面的報錯信息會告訴你鎖定信號失敗還是測量超時。先看日志再看代碼永遠不要跳過日志直接改配置。6. 最后再分享幾個實際用過的土辦法踩的坑多了有些土辦法比文檔管用得多。第一新環(huán)境第一次搭建完成后別急著上線先花半天時間把“環(huán)境快速驗證清單”完整跑一遍。清單里寫清楚每一步應(yīng)該看到什么結(jié)果比如ADB能數(shù)出設(shè)備、Appium能創(chuàng)建會話、綜測儀能鎖定信號、參考天線測出的數(shù)據(jù)在預(yù)期范圍內(nèi)。這張清單以后每次環(huán)境變更后都跑一遍能擋住八成環(huán)境問題。第二硬件測試前先測一遍參考天線。參考天線的性能是已知的如果它測出來的數(shù)據(jù)都漂了那被測天線的數(shù)據(jù)也不用看。這是一個非常便宜又有效的儀表和環(huán)境健康檢查手段。第三給環(huán)境里的關(guān)鍵設(shè)備貼上標簽拍照存檔。儀器背后的線纜哪個接哪個端口時間長了沒人記得記錄在文檔里也沒人看但貼在設(shè)備旁邊的標簽不僅方便別人也能省掉你自己重新理線的功夫。測試環(huán)境這件事說到底就是一個“把不確定性變成確定性”的過程。環(huán)境穩(wěn)定了測試結(jié)果才可信自動化腳本才有意義團隊才能把精力花在真正該花的地方。希望這篇內(nèi)容能幫你在搭環(huán)境的時候少走點彎路。