做軟件這行的早晚會(huì)碰上一個(gè)沒法“手測(cè)”的項(xiàng)目。我印象最深的就是那套包含宏系統(tǒng)和 PTZ 云臺(tái)控制的相機(jī)聯(lián)動(dòng)平臺(tái)宏命令能錄能播PTZ 控制有絕對(duì)定位、相對(duì)移動(dòng)、連續(xù)調(diào)速、預(yù)置位兩者一疊加輸入組合瞬間變成幾千種。這時(shí)候再靠“點(diǎn)點(diǎn)點(diǎn)”去回歸不光是費(fèi)人而是根本沒有能力覆蓋。所以我一直覺得pytest 這類自動(dòng)化測(cè)試框架的價(jià)值不在于它能把用例批量跑起來而在于它讓“復(fù)雜狀態(tài)系統(tǒng)”的測(cè)試變成一種可重復(fù)、可度量、可交接的工程活動(dòng)。這也是為什么我堅(jiān)持把這個(gè)項(xiàng)目里最難的模塊——宏系統(tǒng)執(zhí)行引擎和 PTZ 狀態(tài)控制——全部納入 pytest 的測(cè)試體系。動(dòng)不動(dòng)就幾十條用例跑一遍跑完還能清楚告訴你哪一步掛了、當(dāng)前狀態(tài)是什么、期望值與實(shí)際值差多少。這篇文章我就拿這個(gè)項(xiàng)目當(dāng)例子把軟件測(cè)試為什么不可或缺、pytest 在實(shí)戰(zhàn)里到底解決了什么問題、以及我自己踩過的坑一起講清楚。適合正在做攝像頭、嵌入式、機(jī)器人控制這類“狀態(tài)密集型”系統(tǒng)的測(cè)試工程師也適合準(zhǔn)備軟件測(cè)試面試題或想積累軟件測(cè)試項(xiàng)目實(shí)戰(zhàn)經(jīng)驗(yàn)的朋友——宏系統(tǒng)和 PTZ 控制是非常經(jīng)典的狀態(tài)機(jī)與并發(fā)測(cè)試案例面試聊這個(gè)比聊“登錄功能怎么測(cè)”有說服力得多。1. 先說透一件事宏系統(tǒng)和 PTZ 控制為什么這么難測(cè)1.1 宏系統(tǒng)表面上很“簡(jiǎn)單”實(shí)際上繞不開狀態(tài)與時(shí)間宏系統(tǒng)是什么通俗說就是讓用戶把一串操作錄下來之后一鍵回放。比如“把云臺(tái)轉(zhuǎn)到預(yù)置位 1等 2 秒放大到 30%再轉(zhuǎn)到預(yù)置位 2”。聽起來邏輯清晰不就是一條條命令順序執(zhí)行嗎但落地到工程里問題全藏在細(xì)節(jié)里。第一條命令剛發(fā)出去云臺(tái)還在轉(zhuǎn)第二條命令就來了這時(shí)候是排隊(duì)還是打斷宏運(yùn)行到一半用戶手動(dòng)操作了云臺(tái)狀態(tài)已經(jīng)和錄制時(shí)不一樣后面的相對(duì)移動(dòng)按什么基準(zhǔn)算宏里某一步失敗了是繼續(xù)往下走還是中止單步暫停、單步執(zhí)行、循環(huán)播放、嵌套宏每一種模式都是新的狀態(tài)分支。還有更隱蔽的時(shí)間問題一個(gè)“等待 500 毫秒”的步驟真的要精確等 500 毫秒嗎云臺(tái)運(yùn)動(dòng)是物理過程發(fā)送目標(biāo)位置指令后設(shè)備移動(dòng)到位的實(shí)際耗時(shí)受負(fù)載、溫度、電機(jī)速度曲線影響可能比理論值長(zhǎng)得多。如果宏引擎在設(shè)備還沒到位時(shí)就執(zhí)行下一步整個(gè)位置邏輯就全亂了。所以宏引擎里經(jīng)常要有一個(gè)“運(yùn)動(dòng)到位確認(rèn)”的機(jī)制要么輪詢?cè)O(shè)備狀態(tài)要么固定等待一個(gè)安全時(shí)長(zhǎng)。而這個(gè)機(jī)制本身就是對(duì)時(shí)序最敏感、最難測(cè)的代碼。這些問題的本質(zhì)是宏系統(tǒng)不是一個(gè)“命令列表處理器”而是一個(gè)帶狀態(tài)的執(zhí)行引擎。狀態(tài)的影響因子包括當(dāng)前預(yù)置位、當(dāng)前位置坐標(biāo)、當(dāng)前變焦倍率、上一步執(zhí)行結(jié)果、用戶是否介入、運(yùn)行模式等。哪怕宏內(nèi)容完全一樣執(zhí)行兩次初始狀態(tài)不同結(jié)果就可能不同。這種“同樣的輸入、不同輸出”的特性正是人工測(cè)試最容易忽略、自動(dòng)化測(cè)試最能兜住的場(chǎng)景。1.2 PTZ 控制命名上叫“云臺(tái)”測(cè)試上卻像“狀態(tài)機(jī)”PTZ 是 Pan-Tilt-Zoom 的縮寫控制三個(gè)維度水平旋轉(zhuǎn)、垂直俯仰、變焦。硬件上它由電機(jī)、限位開關(guān)、編碼器、通信總線組成軟件層的核心職責(zé)是把用戶的指令翻譯成設(shè)備能執(zhí)行的協(xié)議幀并維護(hù)設(shè)備當(dāng)前狀態(tài)的鏡像。把 PTZ 控制當(dāng)成狀態(tài)機(jī)來理解很多設(shè)計(jì)決策就說得通了。設(shè)備有物理邊界水平旋轉(zhuǎn)通常有正負(fù) 170 度的限位垂直方向有俯仰角范圍變焦倍率有上下限。指令到達(dá)邊界后的行為是一個(gè)狀態(tài)遷移分支是直接拒絕還是擅自裁剪到邊界值還是原地報(bào)錯(cuò)“越界之后怎么辦”這種邊界問題必須靠測(cè)試明確固化否則不同開發(fā)者的實(shí)現(xiàn)可能不一致。更麻煩的是命令本身就依賴狀態(tài)。絕對(duì)定位的目標(biāo)位置是固定的好測(cè)相對(duì)移動(dòng)是在當(dāng)前基礎(chǔ)上增加偏移量它的最終結(jié)果完全取決于執(zhí)行前的位置。比如用戶云臺(tái)當(dāng)前在 100 度發(fā)一個(gè)“相對(duì)移動(dòng) 80 度”最終落到 180 度還是被限位剪到 170 度這個(gè)結(jié)果跟執(zhí)行時(shí)刻的狀態(tài)強(qiáng)綁定寫用例時(shí)必須顯式設(shè)置前置狀態(tài)再進(jìn)行斷言。并發(fā)問題同樣藏在這里。用戶按搖桿、宏系統(tǒng)自動(dòng)執(zhí)行、另一個(gè)線程在做巡航掃描三個(gè)來源同時(shí)發(fā)指令誰優(yōu)先是加鎖排隊(duì)還是搶占超時(shí)的指令重發(fā)多少次這些不是“測(cè)一下就完事”的問題而是要建立完整的并發(fā)控制模型再用測(cè)試去覆蓋每一個(gè)沖突路徑。可以說PTZ 控制代碼量不大但測(cè)試復(fù)雜度在同等代碼規(guī)模里算是相當(dāng)高的。1.3 人工回歸的四個(gè)死穴為什么手測(cè)在這里不靠譜我在這類項(xiàng)目上做過一次比較正式的人工回歸花了一整天跑了六十多個(gè)手寫步驟的用例結(jié)果發(fā)現(xiàn)四個(gè)問題每一種都足以讓手工測(cè)試方案徹底出局。第一個(gè)是時(shí)序不可控。PTZ 云臺(tái)從一點(diǎn)轉(zhuǎn)到另一點(diǎn)需要幾百毫秒到幾秒不等手測(cè)時(shí)人眼判斷“到位了沒有”本身就帶誤差。宏系統(tǒng)的 WAIT 步驟要求等 500 毫秒手測(cè)根本等不了那么精確。人的反應(yīng)速度、視覺判斷、注意力波動(dòng)都會(huì)成為結(jié)果差異的來源。第二個(gè)是狀態(tài)難以重置。測(cè)完一個(gè)用例后云臺(tái)停在某個(gè)隨機(jī)角落宏回放一半被中斷下一個(gè)用例開始前必須把所有狀態(tài)恢復(fù)。手工恢復(fù)狀態(tài)既慢又容易漏漏一次后面所有用例的結(jié)果都失真但你根本不知道是哪一步出了問題。第三個(gè)是覆蓋不可量化。手測(cè)無法回答“這個(gè)功能測(cè)試覆蓋率是多少”這個(gè)問題。宏系統(tǒng)的分支條件有幾十個(gè)每種分支至少 3 到 5 條路徑手測(cè)只能憑記憶挑重點(diǎn)路徑。今天測(cè)了 A 路徑明天可能就漏了。覆蓋率這兩個(gè)字在手工流程里根本無從談起。第四個(gè)是回歸不可持續(xù)。開發(fā)改一行協(xié)議解析代碼整個(gè)宏系統(tǒng)與 PTZ 的行為都可能受影響。人工回歸跑一天開發(fā)一天能改三輪測(cè)試永遠(yuǎn)追不上生產(chǎn)代碼的速度。等到發(fā)布前臨時(shí)抱佛腳漏測(cè)是必然的。這四個(gè)死穴疊加在一起結(jié)論很清楚對(duì)這種系統(tǒng)測(cè)試不做自動(dòng)化等于功能開發(fā)完就進(jìn)入了“無人區(qū)”。這也是為什么現(xiàn)在軟件測(cè)試流程里自動(dòng)化測(cè)試框架的使用權(quán)重越來越高pytest 自動(dòng)化測(cè)試框架幾乎成了 Python 技術(shù)棧項(xiàng)目的標(biāo)配。2. 測(cè)試設(shè)計(jì)的大方向先把“測(cè)什么”想清楚再動(dòng)手寫 pytest 用例之前最重要的工作不是去查 pytest 語法而是把被測(cè)系統(tǒng)的模型想清楚。我習(xí)慣先回答三個(gè)問題系統(tǒng)有什么狀態(tài)狀態(tài)之間怎么遷移遷移由什么事件觸發(fā)這三個(gè)問題想透徹用例設(shè)計(jì)就是水到渠成的事。2.1 測(cè)試模型的三個(gè)關(guān)鍵詞狀態(tài)、時(shí)序、并發(fā)先說狀態(tài)。我拿宏系統(tǒng)舉例宏執(zhí)行器至少包含這些狀態(tài)空閑、解析中、執(zhí)行中、暫停、中止、完成、失敗。每個(gè)狀態(tài)對(duì)應(yīng)一組允許的事件比如只有“執(zhí)行中”才接受“暫?！敝挥小皶和！辈沤邮堋盎謴?fù)”。用 pytest 去測(cè)狀態(tài)機(jī)本質(zhì)上是給每一對(duì)當(dāng)前狀態(tài)輸入事件寫一個(gè)用例斷言遷移后的狀態(tài)和副作用。這樣一組用例寫完?duì)顟B(tài)機(jī)的覆蓋率立刻就能做到相當(dāng)高。時(shí)序是第二個(gè)關(guān)鍵詞。宏里的 WAIT 步驟要等多久PTZ 指令發(fā)出后多久應(yīng)該收到設(shè)備的 ACK收到 ACK 但設(shè)備實(shí)際還沒動(dòng)完怎么辦這類用例需要真實(shí)的時(shí)間基準(zhǔn)我會(huì)用 time.monotonic() 而不是 time.time()。原因很簡(jiǎn)單系統(tǒng)校時(shí)、時(shí)區(qū)切換、NTP 同步都可能讓 wall clock 發(fā)生跳變而 monotonic 時(shí)鐘只增不減專門用來測(cè)量時(shí)間間隔不會(huì)受這些因素干擾。并發(fā)是第三個(gè)關(guān)鍵詞。宏執(zhí)行過程中用戶通過 UI 點(diǎn)擊“停止”本質(zhì)上是兩個(gè)線程同時(shí)訪問控制器的狀態(tài)。pytest 里我會(huì)用 threading.Thread 模擬并發(fā)操作配合 threading 事件對(duì)象做同步專門測(cè)競(jìng)態(tài)條件下系統(tǒng)是否還保持一致。這一塊是手工測(cè)試幾乎無法穩(wěn)定復(fù)現(xiàn)的但恰恰是現(xiàn)場(chǎng)用戶最容易遇見的故障來源。2.2 真實(shí)硬件還是模擬器分層策略是性價(jià)比的關(guān)鍵一開始我犯過一個(gè)錯(cuò)誤所有用例都對(duì)著真實(shí) PTZ 設(shè)備跑。結(jié)果測(cè)試速度極慢一執(zhí)行就占用一套設(shè)備而且硬件抖動(dòng)導(dǎo)致用例偶發(fā)失敗根本分不清是代碼 bug 還是設(shè)備問題。那時(shí)候我每天都在處理“重跑一遍看看”這種毫無意義的動(dòng)作浪費(fèi)了大量時(shí)間在噪聲排查上。后來我把測(cè)試分成三層整個(gè)局面完全不同了。最底層是協(xié)議層測(cè)試完全 mock 掉硬件。用 unittest.mock 模擬串口或網(wǎng)絡(luò)傳輸驗(yàn)證協(xié)議幀的構(gòu)造、字段填充、校驗(yàn)計(jì)算、超時(shí)重試邏輯。這一層跑得最快毫秒級(jí)并且由于沒有物理依賴失敗時(shí)定位非常精準(zhǔn)。中間層是控制層測(cè)試用“虛擬 PTZ 設(shè)備”。我寫了一個(gè)內(nèi)存中的設(shè)備模擬器能響應(yīng)指令、更新坐標(biāo)、模擬電機(jī)運(yùn)動(dòng)耗時(shí)但完全運(yùn)行在 Python 進(jìn)程里?？刂茖拥臓顟B(tài)管理邏輯、宏引擎的時(shí)序調(diào)度都在這一層測(cè)。這一層執(zhí)行速度仍然很快而且可以精確控制設(shè)備的每個(gè)行為制造真實(shí)設(shè)備上很難復(fù)現(xiàn)的異常。頂層才是真實(shí)硬件的冒煙測(cè)試只有一套用例數(shù)量很少用于發(fā)布前的最終驗(yàn)證。因?yàn)樗某杀咀罡?、最不穩(wěn)定我只讓它驗(yàn)證“協(xié)議能通、基本指令能執(zhí)行”這個(gè)最低限度的功能。這個(gè)分層結(jié)構(gòu)讓 95% 的用例可以在 CI 里快速跑只有那幾條真正需要硬件的用例保留在發(fā)布流程里。開發(fā)改代碼后跑一遍中間層和底層測(cè)試已經(jīng)是常態(tài)不再需要等硬件環(huán)境。2.3 測(cè)試金字塔在宏系統(tǒng)項(xiàng)目里的實(shí)際配比按經(jīng)驗(yàn)宏系統(tǒng)項(xiàng)目里我會(huì)把測(cè)試用例按金字塔配比分配底層協(xié)議與單元測(cè)試約 60%控制層與狀態(tài)機(jī)測(cè)試約 30%端到端冒煙測(cè)試約 10%。比例本身不是教條它反映的是執(zhí)行速度、穩(wěn)定性和成本之間的平衡。單元測(cè)試毫秒級(jí)執(zhí)行出了失敗能精確定位到函數(shù)端到端測(cè)試要秒級(jí)失敗時(shí)還要人工確認(rèn)是不是環(huán)境問題。把大多數(shù)邏輯驗(yàn)證放在金字塔底座是讓測(cè)試“能跑、跑得快、出錯(cuò)了能看懂”的關(guān)鍵。這個(gè)配比也直接影響 pytest 的用法。底層用例量大、邏輯獨(dú)立非常適合參數(shù)化和并行執(zhí)行控制層用例涉及狀態(tài)與時(shí)間需要精心組織 fixture 保證隔離端到端用例數(shù)量少更適合放在發(fā)布流水線的最后一步。沒有這個(gè)思路直接套 pytest很容易把代碼寫成一鍋粥。3. pytest 不是“另一個(gè)斷言工具”四個(gè)特性決定它的不可替代性說實(shí)話pytest 剛出現(xiàn)時(shí)我有點(diǎn)無所謂覺得不過是又一個(gè) unittest 換皮。用多了之后才明白fixture、參數(shù)化、斷言內(nèi)省和插件生態(tài)這幾個(gè)設(shè)計(jì)直接改變了測(cè)試代碼的組織方式和維護(hù)成本。它不是一個(gè)“能跑測(cè)試的框架”而是一個(gè)把測(cè)試當(dāng)作工程產(chǎn)品來打磨的基礎(chǔ)設(shè)施。3.1 fixture把環(huán)境準(zhǔn)備從測(cè)試邏輯里徹底剝出來沒有 fixture 之前unittest 風(fēng)格的 setUp 和 tearDown 很笨重。宏系統(tǒng)測(cè)試的初始化環(huán)境復(fù)雜要啟動(dòng)模擬器、連接控制器、加載宏腳本、設(shè)置起始位置。如果每個(gè)測(cè)試類都寫一套重復(fù)的初始化維護(hù)成本高到讓人不想寫測(cè)試。fixture 改變了這件事它可以按依賴關(guān)系組裝環(huán)境并且按函數(shù)級(jí)、模塊級(jí)、會(huì)話級(jí)自動(dòng)管理生命周期。宏引擎依賴 PTZ 控制器控制器依賴傳輸層。pytest fixture 的依賴注入讓這個(gè)鏈條在測(cè)試?yán)锉磉_(dá)得非常自然測(cè)試函數(shù)只需要聲明 macro_engine 參數(shù)pytest 自動(dòng)把 controller、transport 全部裝配好。這種“聲明需要什么就能得到什么”的方式讓測(cè)試代碼的可讀性和可維護(hù)性都大幅提升。更重要的是作用域控制。協(xié)議層測(cè)試?yán)锬M設(shè)備不需要每個(gè)用例重建session 級(jí) fixture 一次創(chuàng)建所有用例共享測(cè)試速度大幅提升。而宏引擎的測(cè)試需要每個(gè)用例干凈的狀態(tài)就用 function 級(jí) fixture 提供。這種按需控制生命周期、按需決定隔離粒度的能力是 unittest 很難做到的。我在項(xiàng)目里把 fixture 作用域當(dāng)作一項(xiàng)性能優(yōu)化手段來用效果立竿見影。還有一個(gè)細(xì)節(jié)fixture 不只是在 setup 階段注入對(duì)象它還支持 teardown。用 yield 關(guān)鍵字把測(cè)試執(zhí)行夾在中間測(cè)試結(jié)束后自動(dòng)釋放資源。PTZ 控制器的連接、宏引擎的停止、虛擬設(shè)備的回收全都可以在 fixture 內(nèi)部?jī)?yōu)雅處理。這讓每個(gè)測(cè)試函數(shù)都不用關(guān)心“用完之后怎么收拾殘局”。3.2 參數(shù)化一份測(cè)試邏輯跑遍所有 PTZ 型號(hào)與宏腳本宏系統(tǒng)項(xiàng)目里最消耗時(shí)間的不是寫用例而是數(shù)據(jù)準(zhǔn)備。PTZ 有多個(gè)型號(hào)每個(gè)型號(hào)的限位不同、協(xié)議版本不同、支持的變焦倍率不同。宏腳本有成千上萬條如果每個(gè)組合都單獨(dú)寫一個(gè)測(cè)試函數(shù)代碼量會(huì)爆炸而且邏輯重復(fù)會(huì)直接擊垮維護(hù)意愿。pytest.mark.parametrize 把數(shù)據(jù)和邏輯分離這是它最實(shí)用、最不可替代的特性之一。我用 JSON 文件維護(hù)一份“型號(hào)-參數(shù)”表測(cè)試函數(shù)從參數(shù)化數(shù)據(jù)里讀取一千條宏腳本配五個(gè)型號(hào)就是五千個(gè)測(cè)試用例測(cè)試代碼只有幾十行。而且參數(shù)化讓失敗信息里直接包含參數(shù)值看到失敗就知道是哪一條數(shù)據(jù)出了問題不需要再手動(dòng)推理“這個(gè)用例是在測(cè)什么東西”。參數(shù)化的另一個(gè)玩法是組合。宏執(zhí)行模式和中斷方式可以兩兩組合成矩陣比如“單步執(zhí)行 第 3 步中斷”“循環(huán)執(zhí)行 第 1 步失敗”“嵌套宏 子宏取消”每種組合就是一條獨(dú)立用例。手動(dòng)寫這種組合測(cè)試幾乎不可能堅(jiān)持但參數(shù)化讓它變得極其自然。最終測(cè)的路徑數(shù)比手工方案多一個(gè)數(shù)量級(jí)。3.3 斷言內(nèi)省與插件生態(tài)失敗現(xiàn)場(chǎng)的質(zhì)量決定排查速度pytest 里 assert 失敗時(shí)不只是告訴你“斷言為假”而是會(huì)把兩邊的實(shí)際值展開出來。比如斷言設(shè)備位置等于期望值時(shí)失敗輸出會(huì)清楚顯示當(dāng)前 pan、tilt、zoom 到底是多少。對(duì)一個(gè) PTZ 控制項(xiàng)目來說這種細(xì)節(jié)決定你能不能在三分鐘內(nèi)定位問題而不是對(duì)著日志猜半天。斷言內(nèi)省機(jī)制看起來是個(gè)小功能實(shí)際上是把排查成本從“小時(shí)級(jí)”降到了“分鐘級(jí)”。插件生態(tài)的價(jià)值更大。pytest-timeout 給每條用例加超時(shí)保護(hù)避免宏引擎死鎖時(shí)測(cè)試卡死pytest-xdist 用多進(jìn)程并行跑參數(shù)化用例千條用例幾分鐘跑完pytest-cov 統(tǒng)計(jì)覆蓋率pytest-html 輸出報(bào)告給團(tuán)隊(duì)成員看“我們到底測(cè)了什么、什么時(shí)候跑的、哪條掛了”。這些插件配置一次就能長(zhǎng)期受益而且組合使用不會(huì)互相打架這是 pytest 生態(tài)成熟度的重要標(biāo)志。真正讓我徹底認(rèn)可 pytest是它把這些高級(jí)能力做成了“默認(rèn)配置”而不是“專門搭建的框架”。一個(gè)普通 Python 工程師只要會(huì)寫 assert就能快速上手團(tuán)隊(duì)協(xié)作成本極低。這也是我給別人推薦軟件測(cè)試工具鏈時(shí)總是把 pytest 排在第一位的原因。3.4 與 CI 和項(xiàng)目流程的融合讓測(cè)試成為開發(fā)節(jié)奏的一部分自動(dòng)化測(cè)試最大的敵人不是寫用例而是“寫完后沒人跑”。如果測(cè)試只能在本機(jī)手動(dòng)執(zhí)行那它的價(jià)值至少打五折。pytest 在這方面和 CI 系統(tǒng)配合得異常流暢配置文件 pytest.ini 里可以設(shè)定測(cè)試路徑、忽略規(guī)則、超時(shí)參數(shù)Jenkins 或 GitLab CI 只需要一行 pytest 命令就能把整套用例拉起來跑。在宏系統(tǒng)項(xiàng)目里我把 CI 集成分成了幾個(gè)階段。第一個(gè)階段是代碼提交后的快速檢查只跑協(xié)議層和單元測(cè)試耗時(shí)控制在兩分鐘以內(nèi)保證開發(fā)節(jié)奏不被拖慢。第二個(gè)階段是合并前的完整測(cè)試跑全部用例包含控制層狀態(tài)機(jī)和并發(fā)場(chǎng)景。第三個(gè)階段是發(fā)布前的硬件冒煙測(cè)試需要真實(shí)設(shè)備單獨(dú)配置一個(gè)手動(dòng)觸發(fā)的任務(wù)。三個(gè)階段各司其職測(cè)試不再是發(fā)布前的一次性活動(dòng)而是融入了日常開發(fā)節(jié)奏。我常跟同事說測(cè)試的價(jià)值要在“開發(fā)改代碼”的那一刻體現(xiàn)而不是在“發(fā)布前一天”才被想起。pytest 讓這個(gè)理念落地成了一行命令這才是它不可替代性的最終體現(xiàn)。4. 實(shí)戰(zhàn)記錄一套可運(yùn)行的 pytest 測(cè)試代碼是怎么落地的講完理念直接貼一段我自己項(xiàng)目里真實(shí)的測(cè)試代碼結(jié)構(gòu)給大家一個(gè)可以直接改改用的骨架。所有代碼都是經(jīng)過簡(jiǎn)化但保留核心邏輯的版本命名盡量貼近實(shí)際項(xiàng)目。4.1 項(xiàng)目骨架與依賴清單測(cè)試目錄長(zhǎng)這樣tests/ ├── conftest.py ├── requirements-dev.txt ├── test_macro_parser.py ├── test_macro_engine.py ├── test_ptz_protocol.py ├── test_ptz_state.py ├── test_concurrency.py └── data/ ├── ptz_models.json └── macros_samples.txtrequirements-dev.txt 里的核心依賴就幾個(gè)pytest、pytest-timeout、pytest-xdist、pytest-cov。再加一個(gè)自己寫的虛擬 PTZ 設(shè)備模擬器代碼量不大但對(duì)穩(wěn)定性的提升是關(guān)鍵性的。pytest.ini 我一般這樣配置[pytest] testpaths tests markers slow: 需要較長(zhǎng)時(shí)間運(yùn)行的用例 hw: 需要真實(shí)硬件的案例 addopts -ra --strict-markers --timeout30這里有兩個(gè)細(xì)節(jié)值得說。--timeout30 是全局超時(shí)保護(hù)任何用例超過 30 秒直接判失敗防止宏引擎死鎖把 CI 拖死。--strict-markers 強(qiáng)制注冊(cè) marker拼寫錯(cuò)誤會(huì)直接報(bào)錯(cuò)避免 marker 名字打錯(cuò)卻沒人發(fā)現(xiàn)的坑。這兩個(gè)配置是我在踩過多次坑之后才加上的。4.2 fixture 搭建宏引擎與 PTZ 控制器的測(cè)試環(huán)境conftest.py 里的 fixture 是整個(gè)測(cè)試體系的基石。先定義一個(gè)虛擬設(shè)備這個(gè)設(shè)備模擬了真實(shí) PTZ 的限位和變焦能力。import pytest from fake_ptz import FakePTZDevice from ptz_controller import PTZController from macro_engine import MacroEngine pytest.fixture(scopesession) def fake_ptz_device(): device FakePTZDevice( modelPTZ-200, pan_limit(-170, 170), tilt_limit(-30, 90), max_zoom240, ) device.start() yield device device.stop()然后基于它構(gòu)造控制器和宏引擎。注意這里的作用域選擇是刻意的虛擬設(shè)備用 session 級(jí)整個(gè)測(cè)試會(huì)話只創(chuàng)建一次控制器用 function 級(jí)因?yàn)檫B接狀態(tài)必須每個(gè)用例重置。pytest.fixture def ptz_controller(fake_ptz_device): ctrl PTZController(device_idfake_ptz_device.uri()) ctrl.connect() yield ctrl ctrl.disconnect() pytest.fixture def macro_engine(ptz_controller): engine MacroEngine(controllerptz_controller) engine.start() yield engine engine.stop()測(cè)試函數(shù)里只要寫上 macro_engine 參數(shù)環(huán)境就自動(dòng)到位了。這就是 fixture 依賴注入的價(jià)值底層對(duì)象的創(chuàng)建、依賴關(guān)系、資源釋放全都被隔離在 conftest.py 里測(cè)試函數(shù)只關(guān)心業(yè)務(wù)邏輯。這里我要強(qiáng)調(diào)一個(gè)容易忽略的點(diǎn)fixture 的 teardown 階段一定要做到“資源徹底釋放”。我曾經(jīng)在 fixture 里忘了 disconnect導(dǎo)致測(cè)試跑完 PID 還在、端口被占用后面所有用例全部失敗。用 yield 結(jié)構(gòu)把釋放放在 yield 之后并且用 try/finally 包一層能保證即使測(cè)試中途斷言失敗資源也能被回收。4.3 參數(shù)化驅(qū)動(dòng)宏解析與邊界測(cè)試宏解析器的測(cè)試用參數(shù)化最直接。解析器負(fù)責(zé)把宏文本拆成步驟列表測(cè)試關(guān)注的是步驟數(shù)和異常處理。import pytest from macro_parser import MacroParser, MacroParseError pytest.mark.parametrize(macro_text, expected_steps, [ (PRESET 1; WAIT 2000; ZOOM 30, 3), (, 0), (PRESET 1; * 128, 128), (;.join([WAIT 0] * 50), 50), (INVALID_COMMAND, None), ]) def test_macro_parser_returns_expected_step_count(macro_text, expected_steps): parser MacroParser() if expected_steps is None: with pytest.raises(MacroParseError): parser.parse(macro_text) else: assert len(parser.parse(macro_text).steps) expected_steps這個(gè)用例表面上看只是測(cè)了解析器實(shí)際上它在固話兩個(gè)關(guān)鍵行為空宏應(yīng)該被解析成零步而不是報(bào)錯(cuò)超過一百步的長(zhǎng)宏也應(yīng)該是合法輸入這個(gè)邊界是產(chǎn)品經(jīng)理一開始都沒提過的。數(shù)據(jù)驅(qū)動(dòng)邏輯帶來的直接好處是后續(xù)新增一條宏腳本就是新增一行參數(shù)測(cè)試意圖一目了然。我還從 data/macros_samples.txt 里讀取真實(shí)用戶產(chǎn)生的宏腳本再動(dòng)態(tài)生成參數(shù)化用例。這一步讓我在測(cè)試覆蓋真實(shí)使用場(chǎng)景的同時(shí)不用維護(hù)兩份數(shù)據(jù)集。def _load_real_macros(): with open(tests/data/macros_samples.txt, encodingutf-8) as f: return [line.strip() for line in f if line.strip()] pytest.mark.parametrize(real_macro, _load_real_macros()) def test_real_user_macro_parses_successfully(real_macro): parser MacroParser() parsed parser.parse(real_macro) assert len(parsed.steps) 1 assert parsed.validate()這里有個(gè)細(xì)節(jié)真實(shí)宏數(shù)據(jù)文件更應(yīng)該放在版本控制里面而不是本地路徑。文件一旦變更用例數(shù)量自動(dòng)變化這也是參數(shù)化動(dòng)態(tài)生成的優(yōu)勢(shì)之一。4.4 協(xié)議層與狀態(tài)時(shí)序的 mock 測(cè)試協(xié)議層測(cè)試不碰真實(shí)硬件而是用 mock 驗(yàn)證指令幀的正確性。拿 PTZ 的絕對(duì)移動(dòng)指令舉例我要驗(yàn)證的是控制層構(gòu)造的協(xié)議幀是否包含正確的命令 ID 和坐標(biāo)參數(shù)。from unittest.mock import MagicMock def test_absolute_move_builds_correct_protocol_frame(): transport MagicMock() controller PTZController(transport) controller.goto(pan45.0, tilt10.0, zoom12) sent_frame transport.send.call_args[0][0] assert sent_frame.command_id 0x03 assert sent_frame.pan 45.0 assert sent_frame.tilt 10.0 assert sent_frame.zoom 12這種 mock 測(cè)試最大的優(yōu)勢(shì)是速度極快且不依賴任何外部環(huán)境。協(xié)議構(gòu)造邏輯出了問題這個(gè)用例第一時(shí)間就能暴露。而狀態(tài)時(shí)序測(cè)試則更多依賴虛擬設(shè)備斷言的是“調(diào)用預(yù)置位后狀態(tài)機(jī)是否同步更新”。這類用例必須注意浮點(diǎn)容差問題。def test_preset_recall_updates_position_state(ptz_controller): ptz_controller.save_preset(HOME, pan0, tilt0, zoom30) ptz_controller.goto_preset(HOME) state ptz_controller.get_state() assert abs(state.pan - 0) 1e-6 assert abs(state.tilt - 0) 1e-6 assert abs(state.zoom - 30) 1e-6這里有一個(gè)我反復(fù)強(qiáng)調(diào)的實(shí)踐狀態(tài)斷言一律允許微小容差。浮點(diǎn)運(yùn)算本身有誤差加上設(shè)備模擬器的位置更新算法可能做插值嚴(yán)格相等必然導(dǎo)致偶發(fā)失敗。容差取多少我一般按設(shè)備精度的十分之一來定而不是隨便拍腦袋。更重要的是一類比“正常路徑”更有價(jià)值的測(cè)試指令越界。PTZ 控制的最關(guān)鍵邊界是限位。用例要斷言發(fā)送超出物理限位的位置時(shí)控制層要么拒絕、要么裁剪但絕不能把非法值直接發(fā)給硬件。def test_pan_going_beyond_limit_is_clamped(ptz_controller): # 當(dāng)前在 0 度目標(biāo) 180 度超出上限 170 ptz_controller.goto(pan180, tilt0, zoom10) state ptz_controller.get_state() assert state.pan 170.0這類用例一旦寫出來硬件保護(hù)邏輯的回歸成本就永久降下來了。以后不管是重構(gòu)協(xié)議層還是修改坐標(biāo)換算這條用例都會(huì)提醒你邊界不能被破壞。4.5 并發(fā)、中斷與超時(shí)場(chǎng)景的用例設(shè)計(jì)并發(fā)場(chǎng)景我專門用一個(gè)文件收集用例數(shù)量不多但每一條都值得用心寫。宏執(zhí)行到一半用戶發(fā)來中斷是最典型的并發(fā)問題。import threading import time def test_abort_macro_mid_execution_stops_engine(macro_engine): macro_engine.load(PRESET 1; WAIT 2000; PRESET 2; WAIT 2000; ZOOM 50) result {} def run(): try: macro_engine.run() result[status] done except MacroAborted: result[status] aborted t threading.Thread(targetrun) t.start() time.sleep(0.3) macro_engine.abort() t.join(timeout5) assert not t.is_alive() assert result[status] aborted assert macro_engine.get_state() idle這個(gè)用例測(cè)的不是“宏能不能跑完”而是“執(zhí)行過程中被打斷后引擎是否能恢復(fù)到安全狀態(tài)并釋放資源”。人工測(cè)試時(shí)很難精確抓住“執(zhí)行到一半”這個(gè)時(shí)機(jī)線程加 sleep 的寫法讓時(shí)機(jī)基本可控。斷言里 t.join(timeout5) 是雙保險(xiǎn)如果 abort 處理失效主線程最多等五秒用例判失敗而不是卡死。超時(shí)場(chǎng)景同樣重要。PTZ 指令發(fā)出后設(shè)備沒有響應(yīng)控制層應(yīng)該定時(shí)重試并最終拋出異常。用 mock 模擬連續(xù)超時(shí)是最快的驗(yàn)證方式。def test_command_timeout_triggers_retry_then_error(): transport MagicMock() transport.send.side_effect [TimeoutError, TimeoutError, TimeoutError] controller PTZController(transport, retry_count2, timeout_ms100) with pytest.raises(PTZTimeoutError): controller.goto(pan1, tilt1, zoom1) assert transport.send.call_count 3這里斷言的不是“恰好失敗”而是重試次數(shù)和最終錯(cuò)誤類型。它確?？刂茖蛹炔粫?huì)因?yàn)橐淮纬瑫r(shí)就崩潰也不會(huì)無限重試導(dǎo)致系統(tǒng)卡死。call_count 等于 3看起來是細(xì)節(jié)實(shí)際上把“重試策略”這個(gè)需求像釘子一樣釘在了測(cè)試?yán)锶魏稳硕几牟坏簟?. 踩坑實(shí)錄與問題排查速查表最后這部分是我最想寫的這些坑沒有真實(shí)跑過項(xiàng)目是總結(jié)不出來的。每次踩坑都是代價(jià)換來的經(jīng)驗(yàn)寫出來能幫大家少走不少彎路。5.1 偶發(fā)失敗先查測(cè)試自己穩(wěn)定性建議我在項(xiàng)目里遇到最頭疼的事是同一套用例上一條跑過、下一條就失敗。最開始我懷疑被測(cè)試代碼有 bug查了一整天才發(fā)現(xiàn)問題是測(cè)試之間狀態(tài)互相污染。原因很簡(jiǎn)單我用了一個(gè) session 級(jí)的 fixture 復(fù)用 PTZ 設(shè)備但前一個(gè)用例執(zhí)行到一半中止設(shè)備還停留在某個(gè)奇怪的位置后一個(gè)用例的起始狀態(tài)就不是預(yù)期值。解決辦法有兩個(gè)。一是確保每個(gè)用例執(zhí)行前測(cè)試代碼把系統(tǒng)狀態(tài)重置到初始值比如在 fixture 里調(diào)用 controller.reset()。二是對(duì)于狀態(tài)敏感的系統(tǒng)不要盲目追求 session 級(jí) fixture必要時(shí)用 function 級(jí) fixture 保證每個(gè)用例的獨(dú)立環(huán)境。穩(wěn)定性和速度相比前者必須優(yōu)先一條不穩(wěn)定用例對(duì)團(tuán)隊(duì)信心的傷害遠(yuǎn)大于多跑幾秒的代價(jià)。還有一個(gè)連老手都會(huì)犯的錯(cuò)誤把測(cè)試數(shù)據(jù)和被測(cè)系統(tǒng)的共享對(duì)象放在同一個(gè)可變數(shù)據(jù)結(jié)構(gòu)里。參數(shù)化的元組或列表如果在用例內(nèi)部被修改后面的用例數(shù)據(jù)就被“污染”了。解決方案是永遠(yuǎn)不要修改參數(shù)數(shù)據(jù)必要時(shí)在用例里做深拷貝。5.2 時(shí)間敏感用例的改造經(jīng)驗(yàn)宏引擎里 WAIT 步驟的測(cè)試極容易不穩(wěn)定。我的第一個(gè)版本直接斷言執(zhí)行用時(shí)不少于 500 毫秒結(jié)果偶爾失敗。原因是 CI 機(jī)器負(fù)載波動(dòng)、進(jìn)程被隨機(jī)調(diào)度、系統(tǒng)時(shí)鐘服務(wù)調(diào)整都會(huì)讓 run() 的返回值出現(xiàn)誤差嚴(yán)格的下限斷言在真實(shí)環(huán)境里等于定時(shí)炸彈。后來我把斷言改成區(qū)間判斷給下限留出 50 毫秒容差同時(shí)在上限也做約束防止實(shí)現(xiàn)“假裝等待但實(shí)際上直接睡大覺”的假通過。def test_wait_step_enforces_minimum_duration(macro_engine): start time.monotonic() macro_engine.load(WAIT 500) macro_engine.run() elapsed time.monotonic() - start assert 0.45 elapsed 2.0容差的尺度怎么定我用了一個(gè)很簡(jiǎn)單的方法同一個(gè)用例連續(xù)跑十次記錄實(shí)際耗時(shí)的最小值和最大值然后取一個(gè)比最小值稍小的值作為下限。這樣既不會(huì)過于嚴(yán)格也保留了防假通過的約束。這個(gè)方法可以推廣到所有時(shí)間敏感斷言包括 PTZ 運(yùn)動(dòng)到位確認(rèn)、宏步驟間延時(shí)等場(chǎng)景。5.3 從 pytest 報(bào)告反推項(xiàng)目健康度的幾個(gè)信號(hào)跑測(cè)試不只是看紅綠更要看數(shù)據(jù)的變化趨勢(shì)。我總結(jié)出幾個(gè)信號(hào)對(duì)版本規(guī)劃和重構(gòu)決策都有幫助參數(shù)化用例數(shù)在增長(zhǎng)但執(zhí)行時(shí)間增長(zhǎng)更快的模塊往往有狀態(tài)污染或過度等待的問題需要優(yōu)化 fixture 作用域。同一個(gè)用例在多次執(zhí)行中偶爾失敗的比例超過 1%優(yōu)先檢查時(shí)間敏感斷言和共享狀態(tài)而不是查功能邏輯。覆蓋率數(shù)字增長(zhǎng)停滯的時(shí)候說明新增代碼大多是難以測(cè)試的部分要考慮重構(gòu)了。覆蓋率不是目標(biāo)但停滯是一個(gè)值得警惕的信號(hào)。失敗用例集中在少數(shù)幾個(gè)文件里說明那幾個(gè)模塊的復(fù)雜度可能已經(jīng)超出團(tuán)隊(duì)維護(hù)閾值應(yīng)該拆分了。這些信號(hào)配合 pytest-xdist 生成的分段耗時(shí)報(bào)告和 pytest-cov 的覆蓋率報(bào)告能讓測(cè)試數(shù)據(jù)真正變成項(xiàng)目管理決策的輸入。5.4 常見問題速查表我把項(xiàng)目里遇到的高頻問題整理成一張表方便大家排查。問題現(xiàn)象最可能的原因排查與處理辦法用例偶發(fā)失敗重跑即通過測(cè)試間狀態(tài)污染、時(shí)間斷言過緊檢查 fixture 作用域、調(diào)整容差、增加狀態(tài)重置并發(fā)用例掛起直到超時(shí)死鎖或事件等待條件不滿足調(diào)低 timeout、檢查線程退出條件、確認(rèn) abort 事件是否被處理mock 后用例全部失敗mock 對(duì)象沒有正確掛到被測(cè)模塊確認(rèn) mock 的是被測(cè)代碼實(shí)際引用的符號(hào)而不是同名符號(hào)參數(shù)化用例報(bào)錯(cuò)但數(shù)據(jù)正確fixture 數(shù)據(jù)被用例修改參數(shù)化數(shù)據(jù)按不可變數(shù)據(jù)使用禁止在用例內(nèi)部修改CI 上跑不過本機(jī)卻通過環(huán)境差異依賴版本、系統(tǒng)時(shí)間、負(fù)載用鎖文件固定依賴、檢查系統(tǒng)時(shí)區(qū)與時(shí)鐘服務(wù)、給時(shí)間用例加容差覆蓋率上升但 bug 仍出現(xiàn)用例斷言太弱只走流程不驗(yàn)結(jié)果檢查是否對(duì)狀態(tài)和副作用做了斷言而不只是調(diào)用成功從最初手工回歸跑一整天到后來一套 pytest 用例在 CI 上幾分鐘跑完一千多條這個(gè)項(xiàng)目的測(cè)試體驗(yàn)變化非常大。我個(gè)人的體會(huì)是軟件測(cè)試的核心價(jià)值不在于“證明程序沒有錯(cuò)”而在于讓“變化”變得可控。宏系統(tǒng)和 PTZ 控制這類項(xiàng)目恰恰是變化最多、狀態(tài)最多、回歸成本最高的地方。pytest 的不可替代性說到底就是它把狀態(tài)復(fù)雜、時(shí)序敏感、并發(fā)高頻的系統(tǒng)變成了可以用數(shù)據(jù)驅(qū)動(dòng)、可重復(fù)執(zhí)行、失敗信息可讀的工程對(duì)象。如果你也在類似的系統(tǒng)上做測(cè)試我的建議是別急著寫用例先把狀態(tài)模型和 fixture 邊界設(shè)計(jì)好剩下的體力活交給 pytest 就好。