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